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

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

Client: INCR XServer: 1Client: INCR XServer: 2Client: INCR XServer: 3Client: INCR XServer: 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 XClient: INCR XClient: INCR XClient: INCR XServer: 1Server: 2Server: 3Server: 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