使用层面
1、操作复杂比如聚合等操作不要再server上做
2、操作bigKey内存释放与申请都影响
3、有关，如果某一个时间有大量过期，过期也是主线程操作，这个也会影响客户端的响应，可以使用命令查看，可以把过期时间打散，如果4.0以上版本可以把内存放在后台
4、淘汰机制，内存达到maxmemory，导致写慢，需要先淘汰再写，所以也慢了，不要有bigKey选择合适淘汰策略，一般用LRU.也可以痴爱分实列分摊压力
5、rehash策略，现象是写一部分抖动一下，这个有可能是在扩容，达到上限翻倍扩容期间慢。有时候申请内存的时候又正好出发了maxmemory则很有可能卡住。6.0以上版本优化了这个问题
运维层面
1、fork持久化，fork子进程时候主线程不能写入，子线程拷贝信息，所以单个实列控制在10G以下；slave节点进行备份，避免对主节点影响；关闭/AOF rewirte也就不会有fork；不要部署在虚拟机；避免全量同步：适当调大 reply-back-size(这个词儿不精准)
2、内存大页
3、AOF，磁盘IO有问题会影响AOF进而影响redis主线程。rewrite配置no-appendfsync-on-rewrite = yes不刷盘;如果其他应用占用也要排查
4、绑定CPU，redis绑定CPU可以提高性能，主线程处理请求，后台线程处理一部AOF刷盘、lazyfree/异步释放fd；子进程/AOF rewrite。子线程在这种模式下也会争抢CPU，可以通过绑定多个CPU核心尽量用物理核，4.0之后可以指定绑定的CPU对应哪个。
5、swap,所有请求都变慢了，服务基本不可用，内存数据被换到磁盘，直接从磁盘读取数据了，所以要预留足够内存，可以通过命令查看内存以及swap空间可以采用预警机制
6、内存碎片整理，如果内存增长很快，4.0之后开启了内存碎片整理但是打开后也有可能影响性能，这个也是主线程整理碎片，可以配置超过多少M在开启碎片整理，配置合理阈值等
7、网阔带宽过载，现场redis运行很久之后突然开始变慢切持续网络带宽报警，排查热点实例、扩容迁移、网络带宽监控预警
8、监控，监控不能掉以轻心，
9、其他，尽量使用长链接使用redis不要不停的三次握手四次挥手操作，其余的也注意cpu/内存、网络、IO等都会影响redis
10、copy on write/内存大页等redis运维知识点
从资源角度
cpu:复杂度过高、数据持久化
内存：bigkey申请内存、释放、数据过期、淘汰、内存大页、copy on write
磁盘 数据持久化、、AOF
网络：短链接、流量过载
计算机 cpu结构
操作系统：内存大页
一、应用建议
key尽量短，节省内存
避免bigkey 10K以下
聚合命令放在客户端
O(N) 小于300
避免集中过期
maxmemory
rehash
二、运维建议
隔离部署
单个实例10G以下
salve节点做备份
纯缓存可关闭AOF
实例不部署在虚拟机
关闭内存大页
AOF配置为everysec
谨慎绑定CPU
监控