一、来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缓冲区的那些事