请求/响应协议和RTT
Redis是一种基于客户端-服务端模型以及请求/响应协议的TCP服务；
这意味着通常情况下会遵循以下步骤：
1.客户端向服务端发送一条查询请求，并监听Socket返回，通常是以阻塞模式，等待服务端响应；
2.服务端处理命令，并将结果返回给客户端；
redis的数据包从客户端到达服务端，在从服务端到达客户端，这个时间被称之为RTT(round trip time-往返时间)。
问题：假设RTT时间是250毫秒，即使服务器每秒能处理100k的请求数据，但是我们每秒只能处理4个请求；
解决方法：Redis管道（Pipelining）
管道的概念：在一次请求/响应中，服务端能实现处理新的请求即使旧的请求没有响应，这样就可以将多个命令发送到服务端，而不用等待回复，到最后一起回复；
使用管道的技术，就可以在一个RTT时间内，处理更多的请求；
注意的问题：使用管道发送命令时，服务端会返回一个队列，占用很多内存；所以，如果你需要发送大量的命令，最好分批处理；
管道（Pipelining） VS 脚本（Scripting）
大量 pipeline 应用场景可通过 Redis 脚本（Redis 版本 >= 2.6）得到更高效的处理，后者在服务器端执行大量工作。脚本的一大优势是可通过最小的延迟读写数据，让读、计算、写等操作变得非常快（pipeline 在这种情况下不能使用，因为客户端在写命令前需要读命令返回的结果）。
应用程序有时可能在 pipeline 中发送 EVAL 或 EVALSHA 命令。Redis 通过 SCRIPT LOAD 命令（保证 EVALSHA 成功被调用）明确支持这种情况。