最近发现了一个令人烦恼的问题：我们的Redis每七小时左右都会“卡死”，导致我们的应用无法正常使用。我们找了很久，最终发现了问题的原因，并进行了解决。本文将介绍我们的排查过程，并分享一些排查技巧。
我们检查了Redis进程和服务器负载。我们发现Redis进程没有问题，但是服务器负载过高，特别是在Redis被卡死的几个小时内。这提示我们可能是Redis的I/O负载过大，导致了Redis挂起。
于是，我们开始寻找Redis的I/O负载来源。我们遍历了Redis的配置文件，并检查了每个设置的可能性。最终，我们发现了一个名为“save”的配置，这个配置指定了Redis的数据快照周期。默认情况下，Redis每秒钟会自动执行一次数据快照，以保证数据不丢失。然而，由于我们的配置不正确，Redis每七小时就会进行一次全量数据快照，这将导致Redis处理大量的I/O请求，使服务卡死。
我们的解决方案很简单：将“save”的配置修改为每14小时执行一次全量数据快照，只保留每秒钟自动快照的配置。这样做有两个好处：减少了Redis的I/O负载，避免Redis被卡死；减少了Redis每日进行全量数据快照的次数，提升了Redis的性能。
我们考虑如何避免这个问题再次发生。我们首先增加了自动化工具来监控Redis的I/O负载和服务器负载，以及定期检查Redis的配置文件。如果Redis配置了其他可能导致I/O负载异常的参数，我们会及时进行调整。这样做可以在第一时间发现问题并进行解决，避免服务的中断。
总结起来，Redis每七小时“卡死”这个问题的解决步骤如下：
1. 检查Redis进程和服务器负载；
2. 寻找Redis的I/O负载来源；
3. 修改Redis的数据快照配置；
4. 增加自动化工具来监控Redis和服务器负载，并定期检查Redis的配置文件；
5. 避免Redis配置其他可能导致I/O负载异常的参数。
我们分享一下我们修改“save”配置的代码，供参考：
save 900 1 # 每900秒钟，如果至少有1个 key 发生变化，就执行快照
save 36000 1000 # 每36000秒钟，如果至少有1000个 key 发生变化，就执行快照
将“save”配置改为以下代码即可：
save 900 1 # 每900秒钟，如果至少有1个 key 发生变化，就执行快照
以上就是我们排查Redis每七小时“卡死”问题的过程与解决方案。希望本文能对大家有所帮助。
香港服务器首选港服(Server.HK)，2H2G首月10元开通。
港服(Server.HK)（www.IDC.Net）提供简单好用，价格厚道的香港/美国云服务器和独立服务器。IDC+ISP+ICP资质。ARIN和APNIC会员。成熟技术团队15年行业经验。