Redis到底为啥总出问题，老是莫名其妙跑死让人头大

综合了多位运维工程师、后端开发者在知乎、CSDN、V2EX等技术社区分享的真实案例和个人博客中的经验总结）

Redis这东西，用起来是真爽，快得飞起，但有时候也真是让人头疼得要命，动不动就撂挑子不干了，给你来个“跑死”，很多时候问题出得莫名其妙，表面上看风平浪静，但服务就是卡住了，或者直接挂掉，查起原因来像破案一样，我根据网上很多同行的血泪史，总结了几种最常见、最让人头大的情况。

第一种，内存不够用，直接撑爆了。 这是最经典也是最常见的问题，很多人刚开始用Redis，觉得它就是个缓存，使劲往里塞数据，也不设置过期时间，结果就是内存占用率一点点涨，直到100%，这时候Redis就开始“自救”了，它会根据你设定的淘汰策略（比如LRU，最近最少使用）去删掉一些数据，腾出空间，但如果你的写入速度远远大于淘汰速度，或者你设置的策略是“不淘汰”（这是默认设置！），那Redis就没办法了，只能眼睁睁看着内存爆掉，接下来的情况就是，任何写操作都会失败，报错“OOM command not allowed when used memory > ‘maxmemory’”，更可怕的是，如果Redis还开启了持久化（比如RDB快照），在内存爆满的情况下做持久化，很容易因为内存不足导致fork子进程失败，进而引发整个Redis进程崩溃，很多人遇到的情况是，服务器监控看着CPU和网络都正常，但Redis就是没响应了，一查日志，很可能就是内存爆满引发的连锁反应。（来源：多位运维在知乎问题“Redis内存满了怎么办”下的回答）

第二种，持久化操作惹的祸，尤其是RDB。 Redis为了把内存里的数据保存到硬盘上，防止重启后数据丢失，提供了RDB和AOF两种方式，RDB是拍个快照，AOF是记录所有写操作命令，问题经常出在拍快照的时候，Redis为了不阻塞主线程，会用fork系统调用创建一个子进程来专门负责写RDB文件，这个fork操作本身，在数据量大的时候，可能会很耗时，这还不要命，要命的是，fork采用的是“写时复制”机制，也就是说，fork出来的子进程和父进程（主线程）一开始共享同一块内存数据，只有当主线程要修改某块数据时，操作系统才会把这块数据复制一份出来，让子进程去读旧的数据，如果这时候你的Redis实例内存很大，而且写操作非常频繁，那就会发生大量内存页的复制，这个复制过程会消耗额外的内存和CPU，如果服务器本身内存就不太富裕，这个操作很可能直接导致机器内存吃紧，触发系统本身的OOM Killer（内存溢出杀手），这个“杀手”可不管你是谁，可能直接把Redis进程给杀掉了，表现出来的现象就是，Redis在定时生成RDB文件的时候，或者手动执行bgsave命令的时候，服务器负载飙升，然后Redis突然就没了。（来源：CSDN博客文章《一次诡异的Redis崩溃排查经历》）

第三种，坑爹的慢查询堵死了路。 Redis是单线程模型的，它一次只能处理一个命令，这意味着什么？意味着如果有一个命令执行得特别慢，比如不小心用了KEYS *去匹配几百万个key，或者对一个很大的hash表执行HGETALL，这个命令就会一直霸占着Redis，后面所有的命令都得排队等着，整个服务就跟卡死了一样，有时候可能不是故意的，而是业务代码里不小心写了个循环，在循环里不停地调Redis，或者用了某些时间复杂度很高的命令，等线上流量一大，这个慢查询的“毒性”就发作了，你看监控，Redis的CPU可能不高，因为它在傻傻地执行那个慢命令，网络流量也几乎没了，因为请求都堵住了，这种情况特别有欺骗性，因为资源使用率看起来不高，但服务就是不可用。（来源：V2EX讨论帖“Redis突然无响应，求教可能原因”中的高赞回复）

第四种，网络问题或者连接数爆棚。 Redis的性能虽然高，但它的网络处理能力也不是无限的，如果客户端连接数太多，比如好几千甚至上万个连接同时保持着，而其中很多又是空闲连接，这会消耗Redis的资源（每个连接都需要文件描述符和内存），更重要的是，如果遇到网络波动，或者某个客户端出现bug，疯狂地向Redis发送请求，甚至形成网络风暴，就会把Redis的网络IO队列打满，Redis单线程既要处理网络请求，又要执行命令，网络IO一堵，整个服务也就停滞了，如果客户端配置不当，没有正确的连接池管理，频繁地创建和关闭连接，也会给Redis带来不必要的压力。（来源：某公司技术团队博客分享的“一次因客户端连接池泄漏导致的Redis雪崩”故障复盘）

第五种，配置不当留下的隐患。 很多人用Docker部署Redis，但忘了给容器配置足够的内存限制，或者没有正确设置maxmemory参数，导致Redis在容器内可能耗尽所有宿主机的内存，还有比如timeout参数设得太小，导致连接被频繁断开重连；或者tcp-keepalive设得不合理，无法及时发现死掉的连接，这些配置上的小疏忽，在平时可能没事，一旦遇到流量高峰或者异常情况,就会成为压垮骆驼的最后一根稻草。

所以你看，Redis跑死的原因五花八门，很少是Redis本身代码的bug（当然也有，但概率低），绝大多数都是使用姿势不对，要么是资源（内存）没管好，要么是命令用得太奔放，要么是部署配置太随意，解决这些问题没啥银弹，就是得做好监控（内存、慢查询、连接数），制定好使用规范（禁止危险命令、给key设置TTL），并且充分理解Redis的工作原理，不然，它时不时给你来个“惊喜”,真的会让人头大如斗。