1.redis-server

除了启动Redis外，还有一个--test-memory选项。redis-server-test-memory可以用来检测当前操作系统能否稳定地分配指定容量的内存给 Redis，通过这种检测可以有效避免因为内存问题造成Redis崩溃

2.redis-benchmark

redis-benchmark可以为Redis做基准性能测试，它提供了很多选项帮助开 发和运维人员测试Redis的相关性能，下面分别介绍这些选项。

1.-c

-c（clients）选项代表客户端的并发数量（默认是50）。

2.-n<requests>

-n（num）选项代表客户端请求总量（默认是100000）。

例如redis-benchmark-c100-n20000代表100各个客户端同时请求Redis，一 共执行20000次。redis-benchmark会对各类数据结构的命令进行测试，并给出性能指标：

例如上面一共执行了20000次get操作，在0.27秒完成，每个请求数据量 是3个字节，99.11%的命令执行时间小于1毫秒，Redis每秒可以处理 73529.41次get请求

3.-q

-q选项仅仅显示redis-benchmark的requests per second信息，例如：

$redis-benchmark -c 100 -n 20000 -q

4.-r

在一个空的Redis上执行了redis-benchmark会发现只有3个键：

5.-P

-P选项代表每个请求pipeline的数据量（默认为1）。

6.-k<boolean>

-k选项代表客户端是否使用keepalive，1为使用，0为不使用，默认值为1

7.-t

-t选项可以对指定命令进行基准测试。

redis-benchmark -t get,set -q 

SET: 98619.32 requests per second 

GET: 97560.98 requests per second

8.--csv

--csv选项会将结果按照csv格式输出，便于后续处理，如导出到Excel等

redis-benchmark -t get,set --csv 

"SET","81300.81" 

"GET","79051.38"

3.1　Pipeline概念

Redis客户端执行一条命令分为如下四个过程：

1）发送命令

2）命令排队

3）命令执行

4）返回结果

其中1）+4）称为Round Trip Time（RTT，往返时间）。

Redis提供了批量操作命令（例如mget、mset等），有效地节约RTT。但 大部分命令是不支持批量操作的，例如要执行n次hgetall命令，并没有 mhgetall命令存在，需要消耗n次RTT

例如客户端在北京，Redis服务端在上海，两地直线距离约为 1300公里，那么1次RTT时间=1300×2/（300000×2/3）=13毫秒（光在真空中 传输速度为每秒30万公里，这里假设光纤为光速的2/3），那么客户端在1秒 内大约只能执行80次左右的命令，这个和Redis的高并发高吞吐特性背道而驰。

Pipeline（流水线）机制能改善上面这类问题，它能将一组Redis命令进 行组装，通过一次RTT传输给Redis，再将这组Redis命令的执行结果按顺序返回给客户端

redis-cli的--pipe选项实际上就是使用Pipeline机制，例如下面操作将set hello world和incr counter两条命令组装：

echo -en '*3\r\n$3\r\nSET\r\n$5\r\nhello\r\n$5\r\nworld\r\n*2\r\n$4\r\nincr\r\ n$7\r\ncounter\r\n' | redis-cli --pipe

3.2　最佳实践

Pipeline虽然好用，但是每次Pipeline组装的命令个数不能没有节制，否 则一次组装Pipeline数据量过大，一方面会增加客户端的等待时间，另一方 面会造成一定的网络阻塞，可以将一次包含大量命令的Pipeline拆分成多次 较小的Pipeline来完成。

Pipeline只能操作一个Redis实例，但是即使在分布式Redis场景中，也可 以作为批量操作的重要优化手段