关于在Redis中使用Pipelining加速查询的问题

Client: INCR X
Server: 1
Client: INCR X
Server: 2
Client: INCR X
Server: 3
Client: INCR X
Server: 4

现在我们不需要为每次要求付出RTT的消耗了，而是一次性发送三个操作命令。为了便于直观的理解，或者拿之前的说明，使用pipelining技术该的实现顺序以下：

划重点（敲黑板）：当client使用pipelining发送操作命令时，server端将强迫使用内存来排列响应结果。所以在使用pipelining发送大量的操作命令的时候，最好肯定一个公道的命令条数，一批一批的发送给Server端，比如发送10k个操作命令，读取响应结果，再发送10k个操作命令，以此类推…虽然说耗时近乎相同，但是额外的内存消耗将是这10k操作命令的排列响应结果所需的最大值。（为避免内存耗尽，选择一个公道的值）

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在一个物理机上也是如此：

毕竟Redis进程和测试基准benchmark在相同的机器上运行，并且这是没有任何实际的延迟和真实的网络参与，不就是消息通过内存从一个地方拷贝到另外一个地方么？ 缘由是进程在操作系统中其实不是一直运行。真实的情形是系统内核调度，调度到进程运行，它才会运行。比如测试基准benchmark被允许运行，从Redis Server中读取响应内容（与最后一次履行的命令相关），并且写了一个新的命令。这时候命令将在回环网络的套接字中，但是为了被Redis Server读取，系统内核需要调度Redis Server进程（当前正在系统中挂起），循环往复。所以由于系统内核调度的机制，就算是在回环网络中，依然会触及到网络延迟。 简言之，在网络服务器中衡量性能时，使用回环网络测试其实不是一个明智的方式。应当避免使用此种方式来测试基准。

思考

换一种测试方式

参考

• redis.io/topics/pipe…

到此这篇关于在Redis中使用Pipelining加速查询的文章就介绍到这了,更多相关Redis加速查询内容请搜索之前的文章或继续浏览下面的相关文章希望大家以后多多支持！