redis cpu占用过高排查

redis是用"单线程-多路复用io模型"来实现高性能的内存数据服务的，这种机制避免了使用锁，但是同时这种机制在进行sunion之类的比较耗时的命令时会使redis的并发下降。因为是单一线程，所以同一时刻只有一个操作在进行，所以，耗时的命令会导致并发的下降，不只是读并发，写并发也会下降。而单一线程也只能用到一个cpu核心，所以可以在同一个多核的服务器中，可以启动多个实例，组成master-master或者master-slave的形式，耗时的读命令可以完全在slave进行

我这个是redis连接数过多导致

出现cpu过高的原因有：
1、连接数过多，通过redis-cli info | grep connected_clients查看
2、慢查询，因为redis是单线程，如果有慢查询的话，会阻塞住之后的操作，通过redis日志查 
3、value值过大？比如value几十兆，当然这种情况比较少，其实也可以看做是慢查询的一种
4、aof重写/rdb fork发生？瞬间会堵一下Redis服务器

对应解决方案：
1、连接数过多解决：
1.1关闭僵尸连接
采用redi-cli登录,采用client kill ip:port(redis远程连接的ip和端口)。 
需要采用脚本批量删除多个连接
1.2修改redis timeout参数
采用redis-cli登录，采用config set timeout xx 设置redis的keepalive时间
1.3修改redis进程的文件数限制
echo -n "Max open files  3000:3000" >  /proc/PID/limits
1.4修改系统参数的最大文件数限制
/etc/security/limits.conf 
2、对慢查询进行持久化，比如定时存放到mysql之类。（redis的慢查询只是一个list，超过list设置的最大值，会清除掉之前的数据，也就是看不到历史）
3、限制key的长度和value的大小


使用redis的注意事项:
1、Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化。
2、如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。
3、为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内。
4、尽量避免在压力较大的主库上增加从库
5、为了Master的稳定性，主从复制不要用图状结构，用单向链表结构更稳定，即主从关系为：Master<--Slave1<--Slave2<--Slave3.......，这样的结构也方便解决单点故障问题，实现Slave对Master的替换，也即，如果Master挂了，可以立马启用Slave1做Master，其他不变
6、使用Redis负载监控工具：redis-monitor，它是一个Web可视化的 redis 监控程序