关于redis:在Redis中使用Pipelining提升查询速度

2次阅读

共计 2755 个字符，预计需要花费 7 分钟才能阅读完成。

Redis 是一个 client-server 模式的 TCP 服务，也被称为 Request/Response 协定的实现。这意味着通常一个申请的实现是遵循上面两个步骤：

Client 发送一个操作命令给 Server，从 TCP 的套接字 Socket 中读取 Server 的响应值，通常来说这是一种阻塞的形式
Server 执行操作命令，而后将响应值返回给 Client
举个例子：

Client: INCR X
Server: 1
Client: INCR X
Server: 2
Client: INCR X
Server: 3
Client: INCR X
Server: 4
复制代码

Clients 和 Servers 是通过网络进行连贯。网络连接可能会很快（比方本机回环网络），也可能会很慢（比方两个主机之间存在多条网络）。不论网络怎么样，一个数据包从 Client 到 Server，而后相应值又从 Server 返回 Client 都须要肯定的工夫。

这个工夫被称为 RTT(Round Trip Time)。当一个 Client 须要执行多个间断申请（比方增加许多个元素到一个 list 中，或者清掉 Redis 中许多个键值对），那么 RTT 是怎么影响到性能，这个也是很不便去计算的。如果 RTT 的工夫为 250ms（假如互联网连贯速度很常慢），即便 Server 能够每秒解决 100k 个申请，那么最多也只能承受每秒 4 个申请。

如果是本地回环网络，RTT 将会特地的短（比方作者的 localhost，RTT 的响应工夫为 40ms），然而对于执行间断屡次写操作时，也是一笔不小的耗费。

其实咱们有其余方法来升高这种场景的耗费。

Redis Pipelining
在一个 Request/Response 形式的服务中有一个个性：即便 Client 没有收到之前的响应值，也能够持续发送新的申请。这种个性咱们能够不必期待 Server 的响应，率先发送许多操作命令给 Server，再一次性读取 Server 的所有响应值。

这种形式被称为 Pipelining 技术，该技术近几十年来被宽泛的应用。比方多 POP3 协定的实现就反对这个个性，大大的晋升了从 server 端下载新的邮件的速度。

Redis 在很早的时候就反对该项技术，所以不论你运行的是什么版本，你都能够应用 pipelining 技术，比方这里有一个应用 netcat 工具的：

$ (printf "PING\r\nPING\r\nPING\r\n"; sleep 1) | nc localhost 6379
+PONG
+PONG
+PONG
复制代码

当初咱们不须要为每一次申请付出 RTT 的耗费了，而是一次性发送三个操作命令。为了便于直观的了解，还是拿之前的例子阐明，应用 pipelining 技术该例子的实现程序如下：

Client: INCR X
Client: INCR X
Client: INCR X
Client: INCR X
Server: 1
Server: 2
Server: 3
Server: 4
复制代码

当 client 应用 pipelining 发送操作命令时，server 端将强制应用内存来排列响应后果。所以在应用 pipelining 发送大量的操作命令的时候，最好确定一个正当的命令条数，一批一批的发送给 Server 端，比方发送 10000 个操作命令，读取响应后果，再发送 10000 个操作命令，以此类推…尽管说耗时近乎雷同，然而额定的内存耗费将是这 10000 操作命令的排列响应后果所需的最大值。为避免内存耗尽，尽量抉择一个正当的值。

It’s not just a matter of RTT
Pipelining 不是缩小因为 RTT 造成耗费的惟一形式，但它的确帮忙咱们极大的晋升每秒的执行命令数量。事实的假相是：从拜访相应的数据结构并且生成回答后果的状况来看，不应用 pipelining 的确代价很低；然而从套接字 socket I/ O 的状况来看，恰恰相反。因为这波及到了 read()和 write()调用，须要从用户状态切换到内核状态。这种高低切换会特地损耗工夫。

一旦应用了 pipelining 技术，很多操作命令将会从同一个 read()调用中执行读操作，大量的回答后果将会被散发到同一个 write()调用中执行写操作。基于此，随着管道的长度减少，每秒执行的查问数量最开始简直呈直线型减少，直到不应用 pipelining 技术的基准的 10 倍，如下图所示：

Some real world code example
不翻译，基本上就是说应用了 pipelining 晋升了 5 倍性能。

Pipelining VS Scripting
Redis Scripting(2.6+ 版本可用)，通过应用在 Server 端实现大量工作的脚本 Scripting，能够更加高效的解决大量 pipelining 用例。应用脚本 Scripting 的最大益处就是在读和写的时候耗费更少的性能，使得像读、写、计算这样的操作更加疾速。（当 client 须要写操作之前获取读操作的响应后果时，pepelining 就显得相形见拙。）有时候，利用可能须要在应用 pipelining 时，发送 EVAL 或者 EVALSHA 命令，这是可行的，并且 Redis 明确反对这么这种 SCRIPT LOAD 命令。（它保障可能够调用 EVALSHA 而不会有失败的危险）。

Appendix: Why are busy loops slow even on the loopback interface?
那么为什么如下的 Redis 测试基准 benchmark 会执行这么慢，甚至在 Client 和 Server 在一个物理机上也是如此：

FOR-ONE-SECOND:
    Redis.SET("foo","bar")
END
复制代码

毕竟 Redis 过程和测试基准 benchmark 在雷同的机器上运行，并且这是没有任何理论的提早和实在的网络参加，不就是音讯通过内存从一个中央拷贝到另一个中央么？起因是过程在操作系统中并不是始终运行。实在的情景是零碎内核调度，调度到过程运行，它才会运行。比方测试基准 benchmark 被容许运行，从 Redis Server 中读取响应内容，并且写了一个新的命令。这时命令将在回环网络的套接字中，然而为了被 Redis Server 读取，零碎内核须要调度 Redis Server 过程，周而复始。所以因为零碎内核调度的机制，就算是在本地回环网络中，依然会波及到网络提早。简略的说就是在网络服务器中掂量性能时，应用本地回环网络测试并不是一个理智的形式。应该防止应用此种形式来测试基准。

最初
如果你感觉这篇文章对你有点用的话，麻烦请给咱们的开源我的项目点点 star:http://github.crmeb.net/u/defu 不胜感激！

收费获取源码地址：http://www.crmeb.com

PHP 学习手册：https://doc.crmeb.com

技术交换论坛：https://q.crmeb.com

正文完