受網(wǎng)絡(luò)和運(yùn)行環(huán)境影響，應(yīng)用程序可能遇到暫時(shí)性故障，如瞬時(shí)網(wǎng)絡(luò)抖動(dòng)、服務(wù)暫時(shí)不可用、服務(wù)繁忙導(dǎo)致超時(shí)等。
自動(dòng)重試機(jī)制可大幅避免此類(lèi)故障，保障操作成功執(zhí)行。
1 引發(fā)暫時(shí)性故障的原因1.1 故障觸發(fā)了高可用機(jī)制
云 redis 支持節(jié)點(diǎn)健康狀態(tài)監(jiān)測(cè)，當(dāng)監(jiān)測(cè)到實(shí)例中的主節(jié)點(diǎn)不可用時(shí)，會(huì)自動(dòng)觸發(fā)主備切換，例如將主節(jié)點(diǎn)和從節(jié)點(diǎn)進(jìn)行互換，保障實(shí)例的高可用性。此時(shí)，客戶端可能會(huì)遇到下列暫時(shí)性故障：秒級(jí)的連接閃斷。30 秒內(nèi)的只讀狀態(tài)（用于避免主備切換引起潛在的數(shù)據(jù)丟失風(fēng)險(xiǎn)和雙寫(xiě)）。
更多參見(jiàn)：主備切換（https://help.aliyun.com/zh/redis/user-guide/master-replica-switchovers#concept-2025502）
1.2 慢查詢引起了請(qǐng)求堵塞
執(zhí)行時(shí)間復(fù)雜度為 O (N) 的操作，引發(fā)慢查詢和請(qǐng)求的堵塞，此時(shí)，客戶端發(fā)起的其他請(qǐng)求可能出現(xiàn)暫時(shí)性失敗。
1.3 復(fù)雜的網(wǎng)絡(luò)環(huán)境
由于客戶端與 Redis 服務(wù)器之間復(fù)雜網(wǎng)絡(luò)環(huán)境引起，可能出現(xiàn)偶發(fā)的網(wǎng)絡(luò)抖動(dòng)、數(shù)據(jù)重傳等問(wèn)題，此時(shí)，客戶端發(fā)起的請(qǐng)求可能會(huì)出現(xiàn)暫時(shí)性失敗。
2 推薦的重試準(zhǔn)則2.1 僅重試冪等的操作
由于超時(shí)可能發(fā)生在下述任一階段：該命令由客戶端發(fā)送成功，但尚未到達(dá) Redis。命令到達(dá) Redis，但執(zhí)行超時(shí)。命令在 Redis 中執(zhí)行結(jié)束，但結(jié)果返回給客戶端時(shí)發(fā)生超時(shí)。如果執(zhí)行重試可能導(dǎo)致某個(gè)操作在 Redis 中被重復(fù)執(zhí)行，因此不是所有操作均適合設(shè)計(jì)重試機(jī)制。通常推薦僅重試冪等的操作，例如 SET操作，即多次執(zhí)行 SET a b命令，那么 a 的值只可能是 b 或執(zhí)行失敗；如果執(zhí)行 LPUSH mylist a則不是冪等的，可能導(dǎo)致 mylist 中包含多個(gè) a 元素。
2.2 適當(dāng)?shù)闹卦嚧螖?shù)與間隔
根據(jù)業(yè)務(wù)需求和實(shí)際場(chǎng)景調(diào)整適當(dāng)?shù)闹卦嚧螖?shù)與間隔，否則可能引發(fā)下述問(wèn)題：如果重試次數(shù)不足或間隔太長(zhǎng)，應(yīng)用程序可能無(wú)法完成操作而導(dǎo)致失敗。如果重試次數(shù)過(guò)大或間隔過(guò)短，應(yīng)用程序可能會(huì)占用過(guò)多的系統(tǒng)資源，且可能因請(qǐng)求過(guò)多而堵塞在服務(wù)器上無(wú)法恢復(fù)。常見(jiàn)的重試間隔方式包括立即重試、固定時(shí)間重試、指數(shù)增加時(shí)間重試、隨機(jī)時(shí)間重試等。
2.3 避免重試嵌套
避免重試嵌套，否則可能會(huì)導(dǎo)致重復(fù)的重試且無(wú)法停止。
2.4 記錄重試異常并打印失敗報(bào)告
在重試過(guò)程中，建議在 WARN 級(jí)別上打印重試錯(cuò)誤日志，同時(shí)，僅在重試失敗時(shí)打印異常信息。
3 Jedis
建議使用 Jedis 4.0.0 及以上版本，推薦使用最新的 Jedis 版本，以下代碼為 Jedis 5.0.0 的重試示例。
3.1 添加 Jedis 的 Pom 依賴<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
<version>5.0.0</version>
</dependency>
3.2 重試實(shí)戰(zhàn)① 標(biāo)準(zhǔn)架構(gòu)實(shí)例或集群架構(gòu)代理（Proxy）模式
使用 JedisPool 模式。
該示例會(huì)將 SET 命令自動(dòng)重試 5 次，且總重試時(shí)間不超過(guò) 10s，每次重試之間等待類(lèi)指數(shù)間隔的時(shí)間，如果最終不成功，則拋出異常。
PooledConnectionProvider provider = newPooledConnectionProvider(HostAndPort.from("127.0.0.1:6379"));
intmaxAttempts = 5; // 最大重試次數(shù)
Duration maxTotalRetriesDuration = Duration.ofSeconds(10); // 最大的重試時(shí)間
UnifiedJedis jedis = newUnifiedJedis(provider, maxAttempts, maxTotalRetriesDuration);
try{
System.out.println("set key: "+ jedis.set("key", "value"));
} catch(Exception e) {
// 表示嘗試maxAttempts次或到達(dá)了最大查詢時(shí)間maxTotalRetriesDuration仍舊沒(méi)有訪問(wèn)成功。
e.printStackTrace;
}
② 集群架構(gòu)直連模式
使用 JedisCluster 模式。
可以通過(guò)配置 maxAttempts 參數(shù)來(lái)定義失敗情況下的重試次數(shù)，默認(rèn)值為 5，如果最終不成功，則拋出異常。
HostAndPort hostAndPort = HostAndPort.from("127.0.0.1:30001");
intconnectionTimeout = 5000;
intsoTimeout = 2000;
intmaxAttempts = 5;
ConnectionPoolConfig config = newConnectionPoolConfig;
JedisCluster jedisCluster = newJedisCluster(hostAndPort, connectionTimeout, soTimeout, maxAttempts, config);
try{
System.out.println("set key: "+ jedisCluster.set("key", "value"));
} catch(Exception e) {
// 表示嘗試maxAttempts之后仍舊沒(méi)有訪問(wèn)成功。
e.printStackTrace;
}
4 Redisson
Redisson 客戶端提供了兩個(gè)參數(shù)來(lái)控制重試邏輯：
- retryAttempts：重試次數(shù)，默認(rèn)為 3。
- retryInterval：重試間隔，默認(rèn)為 1,500 毫秒。
重試示例如下：
Config config= new Config;
config.useSingleServer
.setTimeout(1000)
.setRetryAttempts(3)
.setRetryInterval(1500) //ms
.setAddress("redis://127.0.0.1:6379");
RedissonClient connect = Redisson.create(config);
5 StackExchange.Redis
StackExchang.Redis 客戶端目前僅支持重試時(shí)連接，重試示例如下：
varconn = ConnectionMultiplexer.Connect("redis0:6380,redis1:6380,connectRetry=3");
說(shuō)明
如需實(shí)現(xiàn) API 級(jí)別的重試策略，請(qǐng)參見(jiàn) Polly。
6 Lettuce
Lettuce 客戶端未提供在命令超時(shí)后重試的參數(shù)，但是您可以通過(guò)下述參數(shù)來(lái)實(shí)現(xiàn)命令重試策略：
- at-most-once execution：命令最多執(zhí)行 1 次，即 0 次或 1 次，如果連接斷開(kāi)并重新連接，命令可能會(huì)丟失。
- at-least-once execution（默認(rèn)）：最少成功執(zhí)行 1 次，即可能會(huì)在執(zhí)行時(shí)進(jìn)行多次嘗試，保障最少成功執(zhí)行 1 次。使用此策略時(shí)，如果 TAIr 實(shí)例發(fā)生了主備切換，此時(shí)客戶端可能累積了較多的重試命令，主備切換完成后可能會(huì)引發(fā) Tair 實(shí)例的 CPU 使用率激增。
說(shuō)明
更多信息，請(qǐng)參見(jiàn) Client-Options（ https://Github.com/lettuce-io/lettuce-core/wiki/Client-Options） 和 Command execution reliability（ https://github.com/lettuce-io/lettuce-core/wiki/Command-execution-reliability）。
重試示例：
clientOptions.isAutoReconnect? Reliability.AT_LEAST_ONCE: Reliability.AT_MOST_ONCE;
參考：
-
https://help.aliyun.com/zh/redis/use-cases/retry-mechanisms-for-redis-clients
-
通過(guò)客戶端程序連接 Redis
-
客戶端程序 TLS（SSL）加密連接 Redis
END
