推荐部署哨兵节点增加可用性 ， 节点数量至少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
