嗡嗡嗡记录了用Redis怎么突然结束进程的那些事儿和操作步骤

整理自网络技术社区用户“嗡嗡嗡”的分享，主要基于其个人经验及Redis官方文档的常见问题章节。）

嗡嗡嗡在他的记录里提到，Redis服务突然结束进程，也就是大家常说的“崩了”或“意外退出”，这事儿挺让人头疼的，他遇到的也不是什么特别高深的场景，就是平常的开发测试环境，他说，Redis虽然以稳定著称，但在某些情况下，还是会“一言不合”就退出，他总结了几种常见的原因和对应的操作步骤,都不是特别复杂的概念。

第一种最常见的情况：内存用完了。

嗡嗡嗡说，这是他踩的第一个坑，Redis是内存数据库，所有数据都放在内存里，如果内存不够用了，而你又没有设置当内存满时的处理策略（或者策略设置得不合适），Redis为了自我保护，可能就会选择直接结束进程，他查了Redis的配置文件redis.conf，里面有个关键参数叫maxmemory，这个参数就是用来设置Redis能使用的最大内存量的，如果这个值设置为0，在64位系统上意味着不限制，但在32位系统上最多只能用3GB，如果设置了一个具体值，比如maxmemory 100mb，那么当内存使用达到这个上限时,就会触发配置的淘汰策略。

淘汰策略是另一个关键点，由maxmemory-policy参数控制,嗡嗡嗡记录了他看到的几种策略：

• noeviction：默认策略，当内存不足时，新写入的操作会报错，但不会淘汰旧数据，这在生产环境很危险，如果写操作频繁，可能导致服务不可用，但在某些特定配置下,也可能间接引发进程问题。
• allkeys-lru：尝试淘汰最近最少使用的键。
• volatile-lru：只从设置了过期时间的键中淘汰最近最少使用的。
• allkeys-random：随机淘汰所有键。
• volatile-random：随机淘汰设置了过期时间的键。
• volatile-ttl：淘汰即将过期的键。

嗡嗡嗡的操作步骤是：他通过命令redis-cli info memory查看当前内存使用情况，重点关注used_memory和maxmemory这两个值，判断是否真的触顶，他打开redis.conf文件，确认maxmemory设置是否合理，是否小于系统可用内存（要给系统本身留点空间），他根据业务需求调整maxmemory-policy，比如他的业务有些数据可以丢失，他就改成了allkeys-lru，修改配置后，他需要重启Redis服务使配置生效，或者如果支持的话用CONFIG SET命令动态设置。

第二种情况：持久化操作出问题。

Redis为了数据安全，提供了两种持久化方式：RDB（快照）和AOF（追加日志），嗡嗡嗡说,这两种方式在某些情况下也可能导致进程退出。

对于RDB，如果Redis配置了定时保存快照（比如save 60 10000表示60秒内有10000次写操作就保存），在生成RDB文件时，Redis会fork一个子进程来干活，如果此时Redis实例占用的内存很大，比如有20GB，那么fork操作可能需要分配同样大小的内存给子进程（虽然实际可能用写时复制技术，但极端情况下开销仍很大），如果此时系统的物理内存紧张，fork可能会失败，严重的会导致Redis主进程退出，嗡嗡嗡的检查方法是看Redis的日志文件（日志路径由logfile配置指定），里面通常会有关于fork失败的报错信息，他的操作步骤是：评估系统内存是否足够支持RDBfork操作，如果不够，要么增加内存，要么调整RDB的触发条件，比如在业务低峰期保存，或者减少单次保存的数据量（但这会影响数据完整性）。

对于AOF，嗡嗡嗡提到的是AOF重写，AOF文件会越来越大，所以Redis也会fork子进程进行重写以压缩文件，同样存在和RDBfork类似的内存问题，如果AOF文件在写入过程中损坏，Redis在启动时加载AOF文件可能会失败，从而无法启动，他处理AOF问题的方法是：检查日志中的AOF相关错误；使用Redis自带的redis-check-aof工具修复AOF文件（操作前务必备份）；或者权衡数据重要性，在极端情况下，如果允许丢失部分数据，可以临时关闭AOF（修改配置appendonly no并重启）,用RDB文件恢复数据。

第三种情况：被系统杀掉了。

嗡嗡嗡还记录了一种“冤死”的情况：Redis进程是被操作系统（比如Linux）的OOM Killer（内存溢出杀手）给杀掉的，当系统整体内存严重不足时，内核为了保住系统不崩溃，会选择一个“罪魁祸首”进程杀掉释放内存，内存占用大的Redis很容易成为目标，他排查的方法是：在Linux系统上，通过dmesg命令查看系统日志，如果看到类似"Out of memory: Kill process ... (redis-server)"这样的信息，那就真相大白了，操作步骤是：要么给服务器加内存，要么优化Redis配置和业务代码，减少Redis的内存占用，降低它被OOM Killer盯上的概率。

第四种情况：配置错误或软件缺陷。

嗡嗡嗡也提到了一些相对少见但确实会发生的情况，修改redis.conf时手误，写了错误的语法或参数值，导致Redis启动时解析配置失败而退出，他总是强调修改配置前先备份，修改后用redis-server /path/to/redis.conf --test-config命令测试配置文件语法是否正确，极少数情况下，可能是Redis软件本身的bug（尽管很罕见）或者与特定版本的兼容性问题，他的应对方法是查看详细的错误日志,并尝试升级或降级Redis版本到稳定版。

嗡嗡嗡最后总结说，处理Redis突然结束进程的问题，最关键的是要学会查看日志，日志里通常包含了退出原因的直接线索，然后根据线索，对照上面提到的几种可能性，一步步去排查和调整配置，他强调,操作前备份数据和配置文件是个好习惯。