Redis集群性能问题深度分析
参考
Redis开发与运维
https://redis.io/
http://www.redis.cn/
https://github.com/antirez/redis
https://github.com/sohutv/cachecloud
源起
优化之路永无止境，在此之前一做过一些架构优化汇总如下：
1，Redis集群3.0.7升级到3.2.9解决读从节点KEY过期不删除问题，集群有几千万KEY原来经核查3.0.7版本只有主上保存过期时间，所以需要主触发才能删除过期的KEY，默认有主动删除与惰性删除同时工作，但是KEY比较多，写的比删除的KEY，另外读从的话不能触发主动删KEY所以会有KEY没更新问题，升级3.2.X之后解决。
2，发现持久化操作时容易导致超时，后来从节点的持久化关闭，效果良好；后续计划持久化非持久化业务分开，过期时间短的与过期时间长的分开。
2，集群扩容，升级到3.2.9版本后为了均摊QPS扩容了几个节点，后续发现有2个节点内核版本比其他的高但是性能反而表现比其他差，后替换了同版本的内核。
3，Bigkeys扫描发现有几个hashkey元素过大超过几千万，单个KEY占用内存几个G后联系开发解决。
4，建立了CacheCloud监控系统，便于分析观察问题，另外Zabbix也使用Redis模版出现大故障时会报错。
5，后续优化方向转为客户端使用规划的问题，主要是解决各个量大的命令平均用时超过10微秒的问题。
6，每个Redis集群版本升级在功能与性能上都有比较大的提升，需要持久化功能的集群后续可以使用4.0.2版本，另外如果使用虚拟化不建议使用XEN、Hyper-V等，最好使用vSphere压力测试vSphere在各方面表现良好。
一，发现问题
1，慢查询
slowlog get n 默认保留128个日志执行超过10毫秒的记录，可以根据实际情况修改
2，应用报错
主要是应用邮件报超时
二，分析问题
1，内在原因
1）API或数据结构使用不合理
2）CPU饱和的问题
3）持久化相关的阻塞
2，外在原因
1）CPU竞争
2）内存交换
3）网络问题
三，解决问题之内在原因
1，API或数据结构使用不合理
1）发现慢查询
slowlog get n
慢查询日志有两个参数：
slowlog-log-slower-than: 单位微妙，指定redis执行命令的最大时间，超过将记录到慢查询日志中, 不接受负值，如果设置为0每条命令都要记录到慢查询日志中,默认10微妙。
slowlog-max-len: 设置慢查询日志长度，如果慢查询日志已经到最大值，如果有新命令需要记录，就将最老那条记录删除，默认保存128，可以在线修改，CONFIG REWRITE保存。
redis-cli
127.0.0.1:6379> config get slowlog-max-len
- "slowlog-max-len"
- "128"
127.0.0.1:6379> config set slowlog-max-len 1000
OK
127.0.0.1:6379> config rewrite
OK
2）发现大key
redis-cli --bigkeys
2，CPU饱和
1）统计Redis状态
500QPS左右，单个命令使用时间越少支持的QPS并发越大，比如平均1毫妙的支持1000QPS，平均100微妙的支持10000QPS。
redis-cli --stat
------- data ------ --------------------- load -------------------- - child -
keys mem clients blocked requests connections
5088981 6.51G 514 0 578132987 (+0) 384742
5088997 6.51G 514 0 578133573 (+586) 384742
5089018 6.51G 514 0 578134096 (+523) 384742
5089005 6.51G 515 0 578134720 (+624) 384743
5089048 6.51G 515 0 578135195 (+475) 384743
5089093 6.51G 513 0 578135829 (+634) 384743
5089117 6.51G 513 0 578136455 (+626) 384743
5089081 6.51G 512 0 578136850 (+395) 384743
5089121 6.51G 512 0 578137226 (+376) 384743
2）命令统计
时间单位为微秒
单个命令10微妙以内，尽量避免高算法复杂的命令
setex平均26
del 平均43
hmset平均229
hmget平均12
以上特别是hmset要优化，另外hgetall命令不建议使用
redis-cli info commandstats
Commandstats
cmdstat_get:calls=2814596805,usec=12130889716,usec_per_call=4.31
cmdstat_set:calls=25674338,usec=234328226,usec_per_call=9.13
cmdstat_setex:calls=910333006,usec=20767349072,usec_per_call=22.81
cmdstat_del:calls=780287520,usec=33983500560,usec_per_call=43.55
cmdstat_lpush:calls=1,usec=34,usec_per_call=34.00
cmdstat_hset:calls=145663119,usec=499130659,usec_per_call=3.43
cmdstat_hget:calls=2841141555,usec=13763160250,usec_per_call=4.84
cmdstat_hmset:calls=1452658,usec=333516295,usec_per_call=229.59
cmdstat_hmget:calls=970024532,usec=11909915205,usec_per_call=12.28
cmdstat_hdel:calls=581004,usec=3925702,usec_per_call=6.76
cmdstat_hgetall:calls=28985688,usec=555451600,usec_per_call=19.16
cmdstat_hexists:calls=262547,usec=2867627,usec_per_call=10.92
cmdstat_select:calls=1,usec=1,usec_per_call=1.00
cmdstat_expire:calls=72409493,usec=101731304,usec_per_call=1.40
cmdstat_auth:calls=1544789,usec=2890530,usec_per_call=1.87
cmdstat_ping:calls=4977672,usec=2672430,usec_per_call=0.54
cmdstat_echo:calls=697770,usec=380462,usec_per_call=0.55
cmdstat_info:calls=32700948,usec=7243085428,usec_per_call=221.49
cmdstat_config:calls=2176619,usec=31168795,usec_per_call=14.32
cmdstat_subscribe:calls=1717,usec=7283,usec_per_call=4.24
cmdstat_unsubscribe:calls=5506966,usec=21985846,usec_per_call=3.99
cmdstat_cluster:calls=696482,usec=210160284,usec_per_call=301.75
cmdstat_readonly:calls=696449,usec=437883,usec_per_call=0.63
cmdstat_client:calls=697770,usec=1869891,usec_per_call=2.68
cmdstat_slowlog:calls=2,usec=214,usec_per_call=107.00
cmdstat_command:calls=2,usec=11824,usec_per_call=5912.00
3）持久化阻塞
由于从已经关闭持久化，主要分析主的，主上只开启了RDB且10分钟一次，没有开启AOF刷盘阻塞（故不用考虑）
fork阻塞：latest_fork_usec该指标不能超过1秒，这里是275毫秒
redis-cli info stats
Stats
total_connections_received:384861
total_commands_processed:578276973
instantaneous_ops_per_sec:509
total_net_input_bytes:530863235402
total_net_output_bytes:1584445816901
instantaneous_input_kbps:668.38
instantaneous_output_kbps:838.84
rejected_connections:0
sync_full:1
sync_partial_ok:0
sync_partial_err:0
expired_keys:164683638
evicted_keys:0
keyspace_hits:193101765
keyspace_misses:12414607
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:275078 275毫秒
migrate_cached_sockets:0
另外HugePage写操作阻塞，这个内核已经关闭HugePages，方法如下
echo never > /sys/kernel/mm/transparent_hugepage/enabled
四，解决问题之外在原因
1，CPU竞争
Redis是典型的CPU密集型应用，同一台服务器不建议部署其他服务，如果需要不是多个Redis实例也建议绑定CPU。
2，内存交换
1）根据进程号cat /proc/5413/smaps |grep Swap可以查看内存交换，为了避免内存交换，首先服务器最好富余1/3-1/2内存，fork时会生成一个进程占用当前实例大小的内存，等于说内存加倍。
2）设置最大可用内存及触发内存启动lru算法（Redis版本越高该算法效率越高，因为Redis一直在进化）以防万一，方法如下：
127.0.0.1:6379> CONFIG GET maxmemory
- "maxmemory"
- "21474836480"
127.0.0.1:6379> CONFIG GET maxmemory-policy - "maxmemory-policy"
- "allkeys-lru"
3)可以降低系统使用swap的优先级，由于前面对内存做了优化这里没有对swap调优，毕竟这些都是不得已手段，需要从架构与使用上修改效果才好。
3，网络问题
1）连接拒绝
主要是网络闪断接Redis连接数超过默认的10000，可以通过监控与修改默认值规避。目前连接不多，如果连接过多服务端的timeout可以修改一个具体的值，默认是0代表永远不主动断开连接。
另外连接溢出，这个服务端与客户端都需要排查，主要是看进程限制与backlog队列是否溢出。
2）网络延迟
3）网卡软中断