Redis是建立在TCP协议基础上的CS架构，客户端client对redis server采取请求响应的方式交互。
redis 乐观锁：也可理解为版本号比较机制，主要是说在读取数据逇时候同时读取其版本号，然后在写入的时候，进行版本号比较，如果一致，则表明此数据在监听期间未被改变，可以写入，如果不一致说明此数据被修改过，不能写入，否则会导致数据不一致的问题。
一般来说客户端从提交请求到得到服务器相应，需要传送两个tcp报文。
设想这样的一个场景，你要批量的执行一系列redis命令，例如执行100次get key，这时你要向redis请求100次+获取响应100次。如果能一次性将100个请求提交给redis server，执行完成之后批量的获取相应，只需要向redis请求1次，然后批量执行完命令，一次性结果，性能是不是会好很多呢？
答案是肯定的，节约的时间是客户端client和服务器redis server之间往返网络延迟的时间。这个时间可以用ping命令查看。
网络延迟高：批量执行，性能提升明显
网络延迟低（本机）：批量执行，性能提升不明显
某些客户端（java和python）提供了一种叫做pipeline的编程模式用来解决批量提交请求的方式。
这里我们用python客户端来举例说明一下。
1、pipeline
网络延迟
client与server机器之间网络延迟如下，大约是30ms。
测试用例
分别执行其中的try_pipeline和without_pipeline统计处理时间。
结果分析
try_pipeline平均处理时间：0.04659
without_pipeline平均处理时间：0.16672
我们的批量里有5个操作，在处理时间维度上性能提升了4倍！
网络延迟大约是30ms，不使用批量的情况下，网络上的时间损耗就有0.15s（30ms*5）以上。而pipeline批量操作只进行一次网络往返，所以延迟只有0.03s。可以看到节省的时间基本都是网路延迟。
2、pipeline与transation（事务）
pipeline不仅仅用来批量的提交命令，还用来实现事务transation。
这里对redis事务的讨论不会太多，只是给出一个demo。详细的描述你可以参见这篇博客。redis事务
细心的你可能发现了，使用transaction与否不同之处在与创建pipeline实例的时候，transaction是否打开，默认是打开的。
