《redis in action》redis事务和管道

在之前的文章中我们大概学习了redis的安全性，主要就是持久化和夸机备份。这里我们再来学习一下redis的安全和性能问题。这块说的性能问题主要就是说客户端与服务端的通信，而不是说redis的服务器的机器的问题。

我们在之前学习了redis的事务(multi/exec)，当时我们说redis事务是没有原子性的，所有的命令都是先发送到服务端，然后缓存起来，然后再执行exec的时候才进行统一执行的，如果exec之前发生了错误，那么所有提交的命令将不会被redis执行。当然如果如果命令执行了一半之后报错了，那么已经执行的命令也不会发生回滚。而且我们当时也说过redis的事务是阻塞的，直到exec执行完毕才能进行其他客户端发来的命令。那么redis事务的问题就是操作指令是一个个发到服务端，然后缓存，在客户端调用exec的时候再进行执行。那么有没有一种方式让这些命令一次性发送到服务端，然后一起执行？答案是有得。这就是传说中的管道。

管道不是redis提供的命令，redis只是提供了事务相关的命令，管道是客户端的行为。管道分为事务管道和非事务管道，事务管道就是在管道中进行multi开启事务，非事务管道仅仅是批量执行命令。因此性能就会有差别。通过实践测试，使用管道比一般传统模式效率高4-5倍，这块和网络有关系。

了解了管道和事务的联系，我们就知道我们在项目中应该尽可能使用管道，尤其是命令比较多的时候，除此之外，对于一些具有并发特征的数据应该采用事务管道，因为事务管道具有阻塞的功能，也就是串行。

在关系型数据库中事务都是采用加锁的方式进行的，redis并没有采用那种锁的方式，为什么这样的原因是redis事务的时间是没有限制的，也不知道前一个操作何时完成，redis不想让客户端等待，而是让客户端尽早知道。另外watch的乐观锁机制也是被动的去监听，如果出现了变化，那么就尽早让客户端知道改变已经发生，然后进行相关的策略，一句话就是为了快。