Redis常用监控和优化方案

1.图形化监控

RedisLive:

1. 安装Python,要求版本2.7以上。
2. 安装依赖组件：pip install tornado；pip install python-dateutil
3. 安装Redis-Live：下载源码，编辑redis-live.conf文件增加要监控的redis server host;
4. 开启监控脚本：./redis-monitor.py –duration 120 & 开启webserver：./redis-live.py &
5. 在浏览器中输入如下地址来查看RedisLive:http://localhost:8888/index.html

---

2.命令行监控

1. INFO命令详解
   clients : 已连接客户端信息，包含以下域：
   connected_clients : 已连接客户端的数量（不包括通过从属服务器连接的客户端）
   client_longest_output_list : 当前连接的客户端当中，最长的输出列表
   client_longest_input_buf : 当前连接的客户端当中，最大输入缓存
   blocked_clients : 正在等待阻塞命令（BLPOP、BRPOP、BRPOPLPUSH）的客户端的数量
   memory : 内存信息，包含以下域：
   used_memory : 由 Redis 分配器分配的内存总量，以字节（byte）为单位
   used_memory_human : 以人类可读的格式返回 Redis 分配的内存总量
   used_memory_rss : 从操作系统的角度，返回 Redis 已分配的内存总量（俗称常驻集大小）。这个值和 top 、 ps 等命令的输出一致。
   used_memory_peak : Redis 的内存消耗峰值（以字节为单位）
   used_memory_peak_human : 以人类可读的格式返回 Redis 的内存消耗峰值
   used_memory_lua : Lua 引擎所使用的内存大小（以字节为单位）
   mem_fragmentation_ratio : used_memory_rss 和 used_memory 之间的比率
   mem_allocator : 在编译时指定的， Redis 所使用的内存分配器。可以是 libc 、 jemalloc 或者 tcmalloc 。
   在理想情况下， used_memory_rss 的值应该只比 used_memory 稍微高一点儿。
   当 rss > used ，且两者的值相差较大时，表示存在（内部或外部的）内存碎片。
   内存碎片的比率可以通过 mem_fragmentation_ratio 的值看出。
   当 used > rss 时，表示 Redis 的部分内存被操作系统换出到交换空间了，在这种情况下，操作可能会产生明显的延迟。
   Because Redis does not have control over how its allocations are mapped to memory pages, high used_memory_rss is often the result of a spike in memory usage.
   当 Redis 释放内存时，分配器可能会，也可能不会，将内存返还给操作系统。
   如果 Redis 释放了内存，却没有将内存返还给操作系统，那么 used_memory 的值可能和操作系统显示的 Redis 内存占用并不一致。

2. 用内存碎片率预测性能问题
   A.重启Redis服务器：如果内存碎片率超过1.5，重启Redis服务器可以让额外产生的内存碎片失效并重新作为新内存来使用，使操作系统恢复高效的内存管理。额外碎片的产生是由于Redis释放了内存块，但内存分配器并没有返回内存给操作系统，这个内存分配器是在编译时指定的，可以是libc、jemalloc或者tcmalloc。 通过比较used_memory_peak, used_memory_rss和used_memory_metrics的数据指标值可以检查额外内存碎片的占用。从名字上可以看出，used_memory_peak是过去Redis内存使用的峰值，而不是当前使用内存的值。如果used_memory_peak和used_memory_rss的值大致上相等，而且二者明显超过了used_memory值，这说明额外的内存碎片正在产生。 在Redis-cli工具上输入info memory可以查看上面三个指标的信息。在重启服务器之前，需要在Redis-cli工具上输入shutdown save命令，意思是强制让Redis数据库执行保存操作并关闭Redis服务，这样做能保证在执行Redis关闭时不丢失任何数据。 在重启后，Redis会从硬盘上加载持久化的文件，以确保数据集持续可用。

3. 延迟时间
   Redis的延迟数据是无法从info信息中获取的。倘若想要查看延迟时间，可以用 Redis-cli工具加–latency参数运行，如:
   Redis-cli --latency -h 127.0.0.1 -p 6379

4. 使用slowlog查出引发延迟的慢命令

5. 监控客户端的连接，Redis-cli工具中输入info clients可以查看到当前实例的所有客户端连接信息。Redis默认允许客户端连接的最大数量是10000。若是看到连接数超过5000以上，那可能会影响Redis的性能。

6. 回收key
   A. info信息中的evicted_keys字段显示的是，因为maxmemory限制导致key被回收删除的数量。回收key的情况只会发生在设置maxmemory值后，不设置会发生内存交换。可以在配置文件中设置maxmemory-policy值为“volatile-lru”或“volatile-ttl”，来确定Redis是使用lru策略还是过期时间策略。 倘若所有的key都有明确的过期时间，那过期时间回收策略是比较合适的。若是没有设置key的过期时间或者说没有足够的过期key，那设置lru策略是比较合理的，这可以回收key而不用考虑其过期状态。
   B.根据key回收定位性能问题
   跟踪key回收是非常重要的，因为通过回收key，可以保证合理分配Redis有限的内存资源。如果evicted_keys值经常超过0，那应该会看到客户端命令响应延迟时间增加，因为Redis不但要处理客户端过来的命令请求，还要频繁的回收满足条件的key。需要注意的是，回收key对性能的影响远没有内存交换严重，若是在强制内存交换和设置回收策略做一个选择的话，选择设置回收策略是比较合理的，因为把内存数据交换到硬盘上对性能影响非常大。

7. 减少回收key以提升性能
   减少回收key的数量是提升Redis性能的直接办法，下面有2种方法可以减少回收key的数量：
   （1）增加内存限制：倘若开启快照功能，maxmemory需要设置成物理内存的45%，这几乎不会有引发内存交换的危险。若是没有开启快照功能，设置系统可用内存的95%是比较合理的，具体参考前面的快照和maxmemory限制章节。如果maxmemory的设置是低于45%或95%(视持久化策略)，通过增加maxmemory的值能让Redis在内存中存储更多的key，这能显著减少回收key的数量。 若是maxmemory已经设置为推荐的阀值后，增加maxmemory限制不但无法提升性能，反而会引发内存交换，导致延迟增加、性能降低。 maxmemory的值可以在Redis-cli工具上输入config set maxmemory命令来设置。
   需要注意的是，这个设置是立即生效的，但重启后丢失，需要永久化保存的话，再输入config rewrite命令会把内存中的新配置刷新到配置文件中。
   （2）对实例进行分片：分片是把数据分割成合适大小，分别存放在不同的Redis实例上，每一个实例都包含整个数据集的一部分。通过分片可以把很多服务器联合起来存储数据，相当于增加总的物理内存，使其在没有内存交换和回收key的策略下也能存储更多的key。假如有一个非常大的数据集，maxmemory已经设置，实际内存使用也已经超过了推荐设置的阀值，那通过数据分片能明显减少key的回收，从而提高Redis的性能。 分片的实现有很多种方法，下面是Redis实现分片的几种常见方式：
   a. Hash分片：一个比较简单的方法实现，通过Hash函数计算出key的Hash值，然后值所在范围对应特定的Redis实例。
   b. 代理分片：客户端把请求发送到代理上，代理通过分片配置表选择对应的Redis实例。 如Twitter的Twemproxy，豌豆荚的codis。
   c. 一致性Hash分片
   d. 虚拟桶分片