1、trancaction
redis 中的事务是通过 multi 命令开启，之后的命令都会返回 QUEUED 表示命令已经入队列到redis server 被缓存起来，此时命令还没有被执行，通过执行exec 命令提交。事务是原子性的操作。但是不支持回滚操作。提供了 watch命令实现类似乐观锁，监视某个key在事务执行过程中值是否发生变化。变化则不执行。
2、pipeline
pipeline 则是客户端把命令缓存起来，最后一下提交给服务器执行。减少了RTT，往返时间。不是原子性的操作。注意中间组装的命令个数限制，不然数据量过大，一方面增加客户端的等待时间，一方面会造成网络阻塞。
RTT: 假设客户端在北京，redis服务端在上海，两地直线距离约1300KM，那么一次RTT时间=13002/（3000002/3）=13毫秒(这里假设光纤为光速的2/3速度)，那么客户端1秒内大约只能执行80次左右的命令，这个和redis的高并发高吞吐特效背道而驰。
疑惑
trancaction 执行过程中不会被别的命令打断
pipeline 执行过程中可能会被打断。
是怎么搞得。