1、used_memory
used_memory：给Redis分配的内存总字节数
used_memory_human：以更易读懂的格式给出相同的值
用于判断是否由于内存交换引起的性能问题
如果used_memory超过了操作系统总可用内存，操作系统将开始进行内存交换，旧的内存部分将被写入磁盘，从磁盘写读写数据的速度比从内存中读写数据的速度慢了5个数量级，如果内存交换发生在Redis进程上，Redis的性能以及依赖Redis的任何应用程序性能将受到严重的影响。
跟踪内存使用情况，以解决性能问题
如果没有开启RDB，那么Redis可以使用的内存总量超过可用内存的95%。
如果开启了RDB，那么如果Redis使用超过45%的可用内存，就会变得有风险了。当然，这个比例也不是绝对的，如果Redis实例写比读的执行频率高很多，则需要尽可能保证这个比例。如果读比写频率高很多，那可以适当调高这个比例。
如何减少Redis内存占用？
- 如果规划要存储的数据小于4GB，请使用32位的Redis实例，因为32位的指针大小是64位的一半，其内存占用小多了；
- 为键设置过期时间；
- 通过将maxmemory设置为可用内存的45%(未开启RDB则为95%)，并通过选择volatile-ttl或者allkey-lru等作为驱逐策略，如非必要，避免使用noeviction，可用严格限制Redis的内存使用，以确保不会产生内存交换。
2、total_commands_processed
处理的命令数，可以通过该指标来诊断延迟。
例如，如果处理的命令激增，并且导致Redis处理不过来，那么就会导致Redis响应变慢，该指标值突然增加；或者如果正在执行一个复杂度很高的命令，导致Redis被阻塞住，那么同样会导致Redis响应变慢，该指标值下降或者停滞了。
可以设置一个脚本来定期记录total_commands_processed指标，并测量延迟。如果观测到指标相比之前有所增加，可能是突然接受了一大批命令，并且在排队等待执行，此时可能导致Redis处理不过来导致响应延迟；如果观测到指标相比之前有所减少，可能是有几个阻塞系统的慢命令在执行。
如何解决大批命令排队或者慢命令导致的延迟问题？
- 通过使用多参数命令，如MGET，MSET，LPUSH， RPUSH等，把一批数据一次性传递给Redis，而不是循环一个一个命令的传递，这可以减少命令数量；
- 使用pipeline，将多个命令一起发送给Redis，这样可以减少由于网络开销导致的延迟；
- 避免使用bigkey，避免使用复杂度高的命令；
3、Latency
Latency，延迟，衡量Redis服务器响应所需的平均时间，次指标无法通过Redis info命令获得，可以通过以下命令得到：
1 | ➜ ~ redis-cli -p 6379 --latency |
如何诊断和解决Redis延迟问题？
一旦您确定延迟是一个问题，可以采用以下措施来诊断和解决相关性能问题：
-
**使用慢日志识别慢命令：**通过查看Redis慢日志，可以快速识别超过用户指定执行时间的命令；
1
2
3
4
5
6➜ ~ redis-cli -p 6379
127.0.0.1:6379> slowlog get
(empty array)
# 通过以下命令设置慢日志的阈值
127.0.0.1:6379> config set slowlog-log-slower-than 5000
OK -
**监控客户端连接：**由于Redis是单线程的，随着客户端连接数量增加，分配给每个客户端的资源百分比就会减少，导致每个客户端花费越来越多的时间等待Redis服务器执行操作和响应。监控客户端连接数很重要，因为应用程序可能无法有效关闭未使用的连接：
1
2
3
4
5
6
7
8
9
10127.0.0.1:6379> info clients
# Clients
connected_clients:3
cluster_connections:0
maxclients:10000
client_recent_max_input_buffer:48
client_recent_max_output_buffer:0
blocked_clients:0
tracking_clients:0
clients_in_timeout_table:0 -
**限制客户端连接：**Redis 2.6以及更高版本可以在redis.conf中或者redis-cli中配置Redis服务器的最大连接数maxclients，你应该设置maxclients为预期峰值的110~150%；
-
**改善内存管理：**需要重点监控内存是否够用。
4、Fragmentation Ratio
碎片率，可以通过mem_fragmentation_ratio指标得到内存碎片率。
mem_fragmentation_ratio = used memory rss / used memory
used_memory_rss：操作系统分配给Redis实例的内存大小，表示Redis进程占用的物理内存大小；
used_memory：Redis使用其分配器分配的内存大小。
什么时候碎片化严重？
mem_fragmentation_ratio < 1 表示Redis内存分配超出了物理内存，操作系统正在进行内存交换；
mem_fragmentation_ratio > 1 合理的指标值；
mem_fragmentation_ratio > 1.5 表示Redis消耗了实际需要物理内存的150%以上，其中50%是内存碎片率。
如果这个值超过1.5(50%)了，说明碎片化还是比较严重的，需要进行优化了。
5、Evictions
evicted_keys 指标给出了已被驱逐(删除)的key数量。
如果evicted_keys增长比较快，说明部分CPU用来回收key了。
您可以通过将 maxmemory-policy 设置为 volatile-lru 或 volatile-ttl 等选择不同的驱逐算法。
如果您的 evicted_keys 始终高于0，可能会导致命令延迟的增加，因为此时Redis除了处理客户端命令请求之外，还需要处理频繁的驱逐工作。但是驱逐并不像内存交换那样对性能具有更大的杀伤力。
如何减少Redis驱逐的影响?
这里有两种方法可以减少Redis的驱逐次数：
- 增加maxmemory限制，但是要注意，不要让内存不足导致进行内存交换；
- 对您的实例进行分区。
6、其他更多指标[1]
- keyspace_misses：key值查找未命中缓存的次数，如果出现次数太多，则要考虑是否有缓存穿透问题，或者是否被恶意攻击；
- blocked_clients：等待阻塞调用的客户端数量(BLPOP、BRPOP、BRPOPLPUSH、BLMOVE、BZPOPMIN、BZPOPMAX)；
- instantaneous_ops_per_sec：每秒处理的命令数；
- total_commands_processed：服务器处理的命令总数；
- total_connections_received：服务器接受的链接总数；
- expired_stale_perc：可能已过期的key的百分比；
- used_cpu_sys：Redis服务器消耗的系统CPU，是服务进程所有线程的消耗系统CPU之和；
- used_cpu_sys_main_thread：Redis服务器主线程消耗的系统CPU；
- used_cpu_user_main_thread：Redis服务器主线程消耗的用户CPU…
如何快速得到Redis服务器的性能？
Redis 包含redis-benchmark[2]模拟 N 个客户端同时发送 M 个查询执行的运行命令的实用程序。
可以通过redis-benchmark命令对Redis进行性能测试：
./redis-benchmark -c 100 -n 5000
对应为100个连接，执行5000次请求的性能结果。
以上就是Redis相关的内容，由于Redis的思维导图比较大，所以没有在文章中放完整的截图，感兴趣的朋友可以到Java架构杂谈公众号回复 Redis 获取思维导图文件。
