最终参数优化调整如下（主库）：
repl-backlog-size 512mbrepl-timeout 120client-output-buffer-limit normal 000client-output-buffer-limit slave 000client-output-buffer-limit pubsub 32mb8mb60
架构问题，其实早在报表高峰期读取问题出现的初期，大数据的同事就提出增加redis从库实例，做负载均衡的想法了。鉴于redis是单线程模型，只能用到一个cpu核心，多增加几个实例可以多利用到几个cpu核心这个想法确实也没错。当时由于从库物理机有富余的内存资源，所以临时新增了三个从库实例，并添加haproxy轮询访问后端4个redis实例。整体架构变为1主4从 haproxy做从库负载均衡。但是我始终认为，cpu高主要还是跟具体的业务查询有关，架构扩展应该是在单实例优化到最佳之后才考虑的。这就好比在mysql当中，有大量慢查询导致cpu过高，你光靠扩展从库而不去先优化SQL，扩展到什么时候是个头呢？
慢查询问题：某个促销活动的晚上，大数据报表果然又准时出现打开慢的现象。redis依然是cpu占用率爆满。话不多说进入redis ，slowlog get 50 , 发现慢查询中基本都是keys xxx* 这样的查询，这。。。我几乎肯定cpu占用率跟这种慢查询有很大关系了。执行时间在0.5秒左右，0.5秒对于redis来说应该是非常慢了。如果这样的查询比较多的话，那么redis确实很可能出现阻塞，在看了下value值的大小，应该还好不算大。redis slowlog默认只保存在内存，只保留当前的128条，所以这也算是个小小的麻烦，不太好统计慢查询发生的频率
持久化策略： rdb持久化：每次都是全量的bgsave，具体策略下面说。 缺点： 1、非实时 2、全量持久化 3、每次保存RDB的时候，Redis都要fork()出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时，fork()可能会非常耗时，造成服务器在某某毫秒内停止处理客户端
aof持久化：每秒写aof文件，实时性较高，增量写，顺序记录语句，便于误操作恢复 缺点： 1、bgrewrite重写，fork进程，短暂阻塞 2、重写时fork进程可能导致swap和OOM（预留1半内存）
简单介绍完两种持久化策略之后，最后给出我实际优化后的策略： 主/从业务库关闭rdb和aof持久化，新增一台从库（不参与业务）单独做rdb持久化，该从库持久化配置：save 900 1 也就是900秒做一次bgrewrite，最多丢失15分钟数据
连接数问题，这块目前来说由于做了负载均衡，高峰期看haproxy入口的连接最大也就去到500-600，还是有阻塞的情况下，每个redis实例connected_clients最多也就到100左右，排除连接数的问题
结论：优化主要避免了持久化，以及频繁主从全量同步带来的性能影响。但是实际主要瓶颈还是在慢查询，如果keys xxx*这种查询不能避免，那么一定会造成阻塞
