Redis重试机制那些事儿，怎么设置才不会让你崩溃又高效

说到Redis，咱们很多用它的朋友都遇到过这种糟心事儿：系统跑得好好的，突然有一天，Redis不知道为啥抽风了一下，网络闪断或者服务器压力大响应变慢，你的应用就跟着报错，甚至整个服务都不可用了，这时候，一个靠谱的重试机制就显得特别重要了，它就像是给系统和Redis之间加了一个“缓冲带”或者“安全气囊”，在出现小问题时，能自己尝试恢复，避免动不动就“崩溃”给你看，这个重试机制要是没设置好，可能不仅帮不上忙，反而会添乱，比如把问题放大，甚至把Redis彻底拖垮，今天咱们就聊聊，怎么设置这个重试,才能既高效又不会让你崩溃。

（来源：基于常见的分布式系统设计和Redis客户端实践）

咱们得明白为啥要重试，原因很简单，网络是不可靠的，服务器也不是铁打的，偶尔的网络抖动、Redis服务器的瞬时高负载、短暂的GC停顿，都可能导致某一次请求失败，但这种失败往往是暂时的，过一小会儿自己就能好，如果一失败就直接给用户返回错误，体验就很差，重试就是给这次失败多一次（或几次）机会。

重试不能乱用，这里有几个关键点,你必须得注意：

第一，不是所有错误都值得重试。 这是最重要的原则，如果你从Redis收到的错误是“语法错误”（例如命令写错了），那你怎么重试都没用，因为问题出在你自己身上，应该立刻失败并记录日志，只有对于那些“暂时性”的错误，比如网络超时、连接断开、或者Redis返回的“超过最大客户端数”这类可能快速恢复的错误，才值得重试，如果你用的Redis客户端（比如Java的Jedis或Lettuce）有自动重试功能，一定要看清楚它的默认策略,最好能自定义哪些异常需要重试。

（来源：微服务设计模式以及各Redis客户端文档）

第二，重试次数和间隔是门艺术。 傻傻地不停重试是最危险的，设置成重试10次，每次间隔100毫秒，如果Redis真的因为压力大而变慢，你这个应用不断地发起重试请求，就相当于在Redis已经快跑不动的时候，还在它身后拼命催它“快点！快点！”，这很可能成为压垮骆驼的最后一根稻草，导致Redis彻底崩溃,雪球越滚越大。

那该怎么办呢？这里就要提到两种聪明的策略了：

1. 指数退避： 这是最常用的策略，意思是，重试的间隔时间不是固定的，而是随着重试次数指数级增加，第一次失败等1秒重试，第二次等2秒，第三次等4秒，第四次等8秒……这样做的妙处在于，它给了系统更长的恢复时间，如果问题很快解决了，第一次或第二次重试可能就成功了；如果问题持续存在，重试请求会迅速减少,避免对系统造成过大压力。

2. 随机抖动： 光有指数退避还不够，想象一下，如果很多个客户端同时遇到问题，都采用一样的指数退避策略（1s, 2s, 4s...），它们会在相同的时间点（第1秒、第2秒、第4秒）同时发起重试，这又会形成一个流量的波峰，可能再次冲垮刚刚恢复的Redis，更高级的做法是在指数退避的基础上加一个随机时间（抖动），比如第一次重试间隔是0.8秒到1.2秒之间的一个随机数，这样就把客户端的重试时间打散了，避免“惊群效应”。

（来源：亚马逊AWS架构最佳实践中的相关描述）

第三，设定一个最终超时时间。 无论你重试多少次，总的等待时间应该有个上限，你可以设定整个操作（包括所有重试）最多花费10秒，如果10秒后还是不行，那就果断失败，向上层返回错误，这保证了应用程序的响应性,不会因为一个Redis调用而无限期等待。

第四，考虑降级方案。 重试是尝试恢复，但如果恢复不了呢？你的应用应该有个备选方案，读数据时，如果Redis重试后依然失败，是不是可以去数据库查一下？（这可能给数据库带来压力，要慎用），或者，对于一些不重要的数据，直接返回一个默认值/空值，让页面还能正常显示，只是部分功能受限,这比整个服务挂掉要好得多。

（来源：构建弹性分布式系统的常见容错模式）

别忘了监控和日志，你要清楚地知道重试发生了多少次，是因为什么原因发生的，把这些 metrics 记录下来，能帮你发现系统的潜在风险，如果重试频率突然变高，那就是一个明确的警报，告诉你Redis集群可能出了状况,需要及时排查。

一个高效且不崩溃的Redis重试机制，核心就是：只对暂时性错误重试、采用“指数退避+随机抖动”的策略控制重试节奏、设定总超时、并准备好失败后的降级方案。 把这几点做好了，你的系统在面对不稳定时，就会从容很多，真正做到“泰山崩于前而色不变”。