Redis简单介绍3-事务&管道（pipeline）

1. redis事务（没有回滚，原子性要看场景）

1.1 redis事务定义

可以一次执行多个命令，本质就是一组命令的集合。一个事务中的所有命令都会序列化，按顺序地串行化执行而不会被其他命令插入，不许加塞。

1.2 redis事务命令

1.2.1 discard 取消事务，放弃执行事务块内的所有命令

1.2.2 exec 执行所有事务块内的命令

1.2.3 multi 标记一个事务块的开始

1.2.4 watch key 监视一个或多个key，如果在事务执行之前这个（或这些）key被其他命令锁改动，那么事务将被打断

1.2.5 unwatch 取消watch命令对所有key的监视

1.3 redis事务命令示例

1.3.1 正常执行事务

1.3.2 放弃事务

1.3.3 命令非事务执行和事务执行的区别

有些命令前期语法都没错，到真正执行时才会报错。

1.3.4 命令语法错误，一个事务中的多个命令都不会执行

1.3.4 命令语法没有错，在执行时报错，这时候一个事务中的多个命令，对的会执行，错的不会执行

1.3.5 watch 监控key，开启事务后，若key被其他redis-cli修改，则事务执行都不会

redis使用watch来提供乐观锁定，类似cas（check and set）

1.3.5.1 不开启watch监控时，事务中的key被修改不影响事务的执行

开启两个redis-cli

• 第一个redis-cli执行：
  
• 第二个redis-cli执行：
  
• 第一个redis-cli执行事务，所有命令都成功：
  

1.3.5.1 开启watch监控时，事务中的key被修改影响事务的执行

• 第一个redis-cli执行：
  

• 第二个redis-cli执行：
  

• 第一个redis-cli执行：
  

• 结果：由于在redis-cli中的key k1被watch监控，另一个redis客户端修改k1后，再执行事务修改k1，则整个事务中的所有命令都不会执行

1.3.6 unwatch 取消监控key

• 第一个redis-cli执行：
  

• 第二个redis-cli执行：
  

• 第一个redis-cli执行：
  

• 第一个redis-cli执行：
  

• 第二个redis-cli执行：
  

• 第一个redis-cli执行：
  

2. redis pipelining（管道）

2.1 redis支持每秒钟八万的写操作和十万的读操作

如何优化频繁命令往返造成的性能瓶颈-管道

2.2 管道的由来

• 问题
  
• 解决思路
  

2.3 管道定义

pipeline是为了解决RTT太大，仅仅将命令打包一次性发送，对整个redis的执行不造成其他任何影响；
批处理命令变种优化，就是说有点类似redis原生批处理命令（mget和mset）

2.4 案例演示 cat redis_pipe.txt | redis-cli -a 111111 -p 6379 --raw 2>/dev/null

将多个命令写在一个文件中，使用管道一次执行

2.5 redis管道小总结

2.5.1 pipeline与原生批量命令对比

1. 原生批量命令是原子性（例如mset, mget）的，pipeline是非原子性
2. 原生批量命令是一次只能执行一种命令，pipeline支持批量执行不同命令
3. 原生批量命令是服务端实现，而pipeline是需要服务端和客户端共同实现

2.5.2 pipeline与事务对比

1. 事务具有原子性，管道不具有原子性
2. 管道一次性将多条命令发送到服务器，事务是一条一条的发，事务只有在接收到exec命令后才会执行，管道不会
3. 执行事务时会阻塞服务端对其他命令的执行，而执行管道中的命令不会

2.5.3 使用pipeline注意事项

1. pipeline缓冲的指令只是会依次执行，不保证原子性，如果执行中指令发生异常，将会继续执行后续的指令
   

2. 使用pipeline组装的命令个数不能太多，不然数据量过大客户端阻塞的时间可能太久，同时服务端此时也被迫回复一个队列答复，占用很多内存，如果服务器端要处理很长时间，这个回复就会一直不释放直到回复成功（命令越多，回复也就越多）

3. redis 发布订阅 - 使用stream实现，一般发布订阅功能都是使用专业的mq，这里不做研究