探讨 | 深入探讨Redis管道

Redis消息交互

当我们使用客户端对Redis进行一次操作时，客户端会把请求传送给服务器，服务器处理完成以后，再把响应恢复给客户端，这要花费一个网络数据包的来回时间。如果要连续执行多条指令，那就会花费多个网络数据包来回的时间，如图所示回到客户端代码里，客户端经历了写-读-写-读四个操作完整的执行了两条指令。

writer  ->  read   ->  write  -> read

现在如果我们调整读写顺序，改成写 - 写 - 读 - 读 这两个指令同样可以正常完成。如图所示

write ->  write  -> read  -> read

两个连续的写操作和两个联系的读操作总共只会花费一次网络来回，就好像连续的写操作合并了，连续的读操作也合并了、如图所示这便是管道的本质，服务器根本没有任何区别对待，还是走着收到一条消息，执行一条消息，回复一条消息的正常流程，客户端通过对管道中的指令列表改变读写顺序就可以大幅的节省IO时间，管道中的指令越多，效果越好。

管道压力测试

Redis自带了一个压力测试工具，redis-benchmark使用这个工具，可以对管道进行测试。首先对一个set指令进行压力测试

> redis-benchmark -t set -q
set 51975.05 requests per second

这次加上-p 参数，表示单个管道内的并行的请求数量，如下所示，当 p = 2 时，QPS达到了 9w/s

> redis-benchmark -t set - P 2 -q
SET: 91240.88 requests per second

此时如果继续提升p参数，会发现已经提升不起来了。原因：因为在这里，CPU参数已经达到了瓶颈，Redis单线程CPU消耗已经达到了100%，无法继续飙升了。

深入理解管道本质

如图所示，是一个完整的交互流程图用文字描述一段流程

1. 客户端进程调用write 把消息写到操作系统内核为套接字分配的发送缓冲send buffer 中

2. 客户端操作系统内核把发送缓冲的内容发送到网卡，网卡硬件把数据通过网际路由送到服务器的网卡。

3. 服务器操作系统内核把网卡的数据放到内核为套接字分配的接受缓冲recvbuffer 中。

4. 服务器进程调用read从接收缓冲中取出消息进行处理。

5. 服务器进程调用write把响应消息写入到内核为套接字分配的发送缓冲send buffer中。

6. 服务器操作系统内核把要发送的缓冲的内容发送到网卡，网卡硬件把数据通过网际路由送到客户端的网卡。

7. 客户端操作系统内核把万科数据放入到内核，为套接字分配的接收缓冲recvbuffer中。

8. 客户端进程调用read从接收缓冲中取出消息返回给上层业务逻辑处理。

9. 结束。

我这里准备了一些

【Java核心技术资料】

【JAVA核心总结】

【524页中高级程序员必备知识】

【《JavaGuide面试突击》v3.0肝出来了！】

【Java高级笔试宝典覆盖近3年Java笔试中98%高频知识点吊打100家大厂面试官】

【Java大厂面试题】

【阿里架构师花近十年时间整理出来的Java核心知识pdf（Java岗）】

【524页《Java中高级程序员必备核心知识》总结，令人犹如醍醐灌顶】

 

等一系列的Java架构资料 需要的话扫一扫免费获取无套路