一、来jd一年多了，大公司还是不同于之前的公司，而且所处的业务线非常的坑，可以说这一年以来，非常非常忙碌。只愿意抽时间学习，且大多数时候时间都抽不出来，所以就无暇顾及去写笔记。到年底了，回过头来看一年的收获，大约有以下几点吧。
1：学习不可图急图快。好多时候是为了完成任务而完成学习的任务。导致很多时候没有深入研究，最后的结果就是别人写什么，看到的就是什么，再加上明细感觉记忆力变差，所以效果可见一斑。
2：笔记很重要，而且记录笔记的心态也很重要，笔记一定要精髓。
3：实践实践，以及探究原理
二、进入正题：
本机装了虚拟机，本地环境连接VM redis时候需要注意的几个点
1：redis.conf里面需要把bind配置注掉，或者指定为本机的ip。
redis.conf中bind配置项要注掉
2：默认vm的防火墙对6379端口是不开放的。可以用命令看看
命令1：firewall-cmd --query-port=6379/tcp
如果防火墙对这个端口开放，则返回yes。如果没有则返回no
如果没有开放，可以通过下列命令开放这个端口
命令2：firewall-cmd --zone=public --add-port=6379/tcp --permanent #对tcp开放6379端口
命令3：firewall-cmd --reload #使命令2生效。这时候再用命令1 查看则返回yes。
3：这个时候连接是可以了，如果抛出了一个保护模式的异常，则再通过下面的命令设置关闭保护模式。
CONFIG SET protected-mode no
三、最近看了2本书，一本书是redis 4.x cookbook 一本是redis深度历险。看完后感觉好多东西都是浅尝辄止，所以想要分模块一个个的自己钻研下。所以今天就从pipeline开始。
pipeline官方介绍能大大提升redis的批量操作效率。基本的知识直接去百度，一堆一大把。我这里也写了2个demo做了测试。
测试1：用普通jdeis操作写入：
10万次操作写入
我本机500G固态，8G内存。测试5次，每次耗时都是在7.7秒左右
pipeline操作
测试5次，每次耗时在240ms左右。从效果上来看，10万次写操作，效率提升了30倍
下面测试10万次读操作
同样的代码改成10万次读操作，jedis直接get下，5次此时耗时也在7.7秒左右
用pipeline操作10万次读，平均耗时在150ms左右。
可见效率提升还是很快的。
四：为什么会这么快？
网上各种说法，总结下来有2点。第一点，省了tcp的RTT时间。第二点，省了io系统调用的时间。
关于第一点，tcp的RTT时间的解释为：redis的客户端和服务的是用tcp协议交互的。jedis普通操作，操作一次相当于发起一次tcp协议。而pipeline，是再在调用sync时候发起一次tcp请求。在sync之前都缓存到pipeline对象中。
模拟：
首先我们在虚拟机上开启一个监控： 进入redis-cli模式下，用monitor即可
模拟延时发送set命令
在监控台我们可以看到如下输出：
监控台看到的输出
由此可以看到每2秒回发送一次请求。
用pipleline模式模拟发起请求
用pipeline模拟发起请求
可以看到是几乎同时把这些命令发送过来
究竟是发起了一次tcp还是多次tcp。从这里还看不出来。这里只能证明，只有当sync才会去调用命令
那么我们深入底层的源码去分析分析二者的差异在哪里？
jedis和pipeline调用方法源码
二者首先都调用了client.set()方法。然后再return时候分别调用了不通的方法。
set方法首先将传入的参数转换成字节数组
调用了sendCommand方法
这里的outputstream是一个RedisOutputStream对象的实例。Protocol的sendCommand方法的主要作用是将命令行按照一定的组织结构写入到RedisOutputStream对象里面去。
在outputstream里面待发送的命令行组织形式为：比如set key1 value1 则转换后如下所示。 是用的RESP序列化协议。
*3\r\n$3SET\r\n$4\r\nkey1\r\n$6\r\nvalue1\r\n。
RESP协议自行百度。这里不多赘述
在往outputstream的缓冲区里写待发送的命令的时候，默认缓冲区长度是8192字节。如果待发送命令长度超过这个，就会flush一次。也就是和服务的进行一次通信。
截止到现在为止。我们只是把要执行的命令存入到了RedisOutputStream对象的缓冲区里。这也是set命令执行的结果。那返回到前面看return后执行的不同方法
jedis在调用完set方法后，调用了getStatusCodeReply方法。
直接调用了flush，底层调用了
outputstream 的flush
pipeline则是调用了getResponse
这里是缓冲了一个response对象，存放在一个linkedlist中。
这里调用了client的getall方法
在getall里调用了flush。
从这里可以看出真相。pipeline先将请求缓存到缓冲区，然后调用sync时候一次发送到服务端。而jedis是每次都发送。这里我们在看底层代码时候发现，这个缓冲区默认只有8k大小。如果一次发送的命令超过8K，则会先给服务端请求一次。这里也就包含了第二点的疑问。相当于，多次命令一次发送。这里涉及到发起一次Sockt时候计算机都做了些什么。这里不详细赘述(本人非计算机毕业，对计算机底层也看了些书，不是很得要领，所以就不装逼了)。
关于第二点，省了io系统调用。jedis发起一次tcp之后，服务的返回结果后，每一次get操作都会有一次把返回的结果从内核copy到用户空间的操作。而pipeline是等所有结果返回，或者buffer满了之后，才会进行一次上下文切换。
有些文章说过，使用pipeline时候一次发送的东西不要超过10k。这个是要区分当前使用的socket缓冲区的大小。如果使用的jedis，则不要超过8K。同样适用于其他方法。
参考书籍：
redis深度历险 redis 4.xcookbook
下一篇，一起学习下：
pipeline缓冲区的那些事
网友评论