Redis pipeline与Pub/Sub

Redis pipeline与Pub/Sub

Redis全称是 remote dictionary server ，本质上是一个key value类型的内存数据库，因为是纯内存的操作，Redis的性能非常出色，每秒可以处理超过10万次读写操作。但如果没用好，每秒10万次的读写效率也是发挥不出来的。而管道技术尤为显著提高了 redis 服务的性能。

管道pipeline

什么是管道pipeline
可以将多个命令发送到服务器，而不用等待回复，最后在一个步骤中读取该答复。这就是管道（pipelining）

管道就像是流水一样把命令Push到server，可以用在缓存预热，批量设置数据的缓存等
如新上一个功能有进行活动推广，用户基数大的时候需要提前进行缓存预热，如果是一个个命令执行，执行速度、效率将会变得非常漫长

因为Redis是一种基于客户端-服务端模型，通讯协议是TCP。
每次命令请求会按照以下步骤执行：
客户端向服务端发送一个查询请求，并监听Socket返回，通常是以阻塞模式，等待服务端响应。
服务端处理命令，并将结果返回给客户端。所以每次请求都包括TCP三次握手四次挥手等网络耗时。

1. 普通的Redis操作，由于Redis执行命令是阻塞式的单线程，所以每次都是上一个key set完成后才能执行下一个Key的set操作
   
2. 使用pipeline管道技术可以把多个命令一次发送redis server服务器，即使旧的请求还未被响应。这样可以减少client与server之间通信，多次网络延迟开销减少为1次，最后在一个步骤中读取该答复
   

如单台server服务器能支撑每秒1000个请求并发请求，如果是1000个命令同时执行，每个请求都要去写Redis，每个命令执行需要50ms，所以在Redis每秒只能执行20个请求，容易造成在Redis中大量的阻塞

当然在最新版Redis6.0(最新版本6.0.1)新特性中增加了多线程，解决了网络IO的消耗，但多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程

下面来做一组对比，测试管道技术对速度的提升效果
数据量：1000条数据
环境：Redis cluster（3master 3slaver）

1. 普通set key
2. pipeline set key

结论：1000条数据在普通的插入需要耗时3000多ms，而pipeline只需要30ms, 普通的1000条数据插入需要1000次的网络耗时（TCP），开启了管道操作后，往返延时只需要一次请求/响应

问：管道pipeline执行插入的过程中出现失败的会怎样？
如果pipeline命令执行中间出现错误，不会影响前面已经执行成功的命令，也不会中断后面的命令，继续执行，最后的结果中会返回所有的执行结果
如图所示，执行的每一个结果都会在最后的响应中拼装返回

发布与订阅Pub/Sub

一般量级不大的上下游服务之间的解耦用Redis的发布订阅Pub/Sub即可满足一般的业务需求

主要解决什么问题

1. 解耦
2. 削峰填谷
3. 异步

测试：
定义channel为 testPubSub
发送的消息为msg1，msg2…

基本PUBLISH每推一条消息，SUBSCRIBE都是实时接收的
Pub/Sub的在spring提供的API操作也很灵活，包括

1. 从左入栈
2. 从左出栈 (如果列表没有元素,会堵塞到列表一直有元素或者超时为止 )
3. 从左边依次入栈
4. 从右入栈
5. 从右出栈
6. 从右边依次入栈

对比一下Message Queue 消息队列
kafka的特性高吞吐量 ：即使是非常普通的硬件Kafka也可以支持每秒数百万的消息
你项目每秒能达到百万的并发？再或者说未来数据量可能达到这个量级？
太多项目滥用MQ，任何脱离业务的组件引入都是耍流氓，引入一个组件，需要考虑这个组件能解决什么问题，合不合适

结束语：Redis虽然简单，但也包含很多小技巧，思考
1、100万的用户，但Redis只能存20万的数据，Redis会怎么处理其他数据？再或者Redis磁盘满了，新的数据插入会怎样？
2、在生产环境Redis是禁用keys * （顺丰keys *事件）导致redis堵死、flushall 丢失所有的数据、flushdb 丢失整个db的数据等，你知道还有哪些命令也是禁用的么？为什么？会出现什么问题？