业务层面和运维层面优化你的Redis( 二 ) 来源：这篇文章我们就来总结一下

推荐部署哨兵节点增加可用性，节点数量至少3个，并分布在不同机器上，实现故障自动故障转移

提前做好容量规划，一台机器部署实例的内存上限，最好是机器内存的一半，主从全量同步时会占用最多额外一倍的内存空间，防止网络大面积故障引发所有master-slave的全量同步导致机器内存被吃光

做好机器的CPU、内存、带宽、磁盘监控，在资源不足时及时报警处理， Redis使用Swap后性能急剧下降，网络带宽负载过高访问延迟明显增大，磁盘IO过高时开启AOF会拖慢Redis的性能

设置最大连接数上限，防止过多的客户端连接导致服务负载过高

单个实例的使用内存建议控制在20G以下，过大的实例会导致备份时间久、资源消耗多，主从全量同步数据时间阻塞时间更长

设置合理的 slowlog 阈值，推荐10毫秒，并对其进行监控，产生过多的慢日志需要及时报警

设置合理的复制缓冲区 repl-backlog 大小，适当调大 repl-backlog 可以降低主从全量复制的概率

设置合理的slave节点 client-output-buffer-limit 大小，对于写入量很大的实例，适当调大可以避免主从复制中断问题

备份时推荐在slave节点上做，不影响master性能

不开启AOF或开启AOF配置为每秒刷盘，避免磁盘IO消耗降低Redis性能

当实例设置了内存上限，需要调大内存上限时，先调整slave再调整master ，否则会导致主从节点数据不一致

对Redis增加监控，监控采集 info 信息时，使用长连接，频繁的短连接也会影响Redis性能

线上扫描整个实例数时，记得设置休眠时间，避免扫描时QPS突增对Redis产生性能抖动

expired_keys evicted_keys latest_fork_usec

总结以上就是我在使用Redis和开发Redis相关中间件时，总结出来Redis推荐的实践方法，以上提出的这些方面，都或多或少在实际使用中遇到过。
可见，要想稳定发挥Redis的高性能，需要在各个方面做好工作，但凡某一个方面出现问题，必然会影响到Redis的性能，这对我们使用和运维提出了更高的要求。
本文来源:微信公众号:匠心零度作者:kaito
【业务层面和运维层面优化你的Redis】本文地址:;mid=2247492243&idx=1&sn=d58605228666c719db78f9e720f3c9eb