一、整体结论

本次故障期间，各组件均在正常执行自身重试机制，但由于底层网络/服务不可达，导致：

❗ 所有重试最终均失败（属于“持续性不可达”，而非短暂RDS切换）

---

核心现象

• DynamoDB：高频（2s）持续重试

• Redis：中频（5.5s）重连失败

• Druid：低频（10.5s）持续建连失败

• Quartz：低频周期检查（60s）

👉 结果：

系统处于“全栈重试但无恢复信号”的状态

---

二、各服务重试频率对比表（实测）

服务/组件	重试间隔	重试策略	是否无限重试	备注
DynamoDB (AWS SDK)	≈ 2秒	固定频率	✅ 是	SDK内置重试机制
PostgreSQL (Druid - CreateConnectionThread)	≈ 10.5秒	固定频率 + 自动建连	✅ 是	主动补连接线程
PostgreSQL (Druid - DestroyConnectionThread)	≈ 60秒	定时扫描	⚠️ 条件性	空闲连接才有效
Redis (Redisson)	≈ 5.5秒	Watchdog重连	✅ 是	当前存在参数异常
Quartz Scheduler	≈ 60秒	Misfire检查	❌ 否	非主动重试机制

---

三、Druid 连接池双线程机制

1️⃣ CreateConnectionThread（连接创建线程）

项目	内容
类型	主动修复型
功能	持续创建数据库连接
周期	≈ 10.5秒
行为	连接失败 → 继续尝试

👉 特点：

• 属于“持续补血机制”

• 不依赖业务请求

---

2️⃣ DestroyConnectionThread（连接清理线程）

项目	内容
类型	防御型
功能	清理无效/空闲连接
周期	≈ 60秒
行为	定期扫描连接池

👉 特点：

• 更偏“垃圾回收”

• 对故障恢复帮助有限

---

3️⃣ 协同行为

故障发生（DB不可达）
        ↓
CreateConnectionThread → 持续创建失败连接（10.5s循环）
DestroyConnectionThread → 定期清理（60s周期）
        ↓
连接池持续为空
        ↓
应用请求仍失败

---

四、Redis（Redisson）重试机制

项目	内容
重试间隔	≈ 5.5秒
机制	ConnectionWatchdog
策略	固定 + jitter抖动
当前问题	参数异常

---

❗ 当前关键错误

bound must be greater than origin
StacklessClosedChannelException

👉 含义：

• 延迟计算失败

• Channel 已关闭

• 重连链路异常

---

结论

Redis当前状态：

❗ “有重试机制，但无法正确执行退避策略”

---

五、DynamoDB 重试机制

项目	内容
重试间隔	≈ 2秒
策略	固定频率
行为	快速连续重试
是否指数退避	❌ 否

---

特点

• 最激进的重试组件

• 日志最密集

• 对系统压力最大

---

六、Quartz 调度器

项目	内容
检查周期	≈ 60秒
类型	Misfire检查
是否主动重试	❌ 否

---

七、统一重试行为对比

组件	重试速度	类型	稳定性
DynamoDB	快（2s）	激进重试	⚠️ 高负载
Redis	中（5.5s）	Watchdog	⚠️ 当前异常
Druid	慢（10.5s）	连接池修复	⚠️ 依赖DB恢复
Quartz	很慢（60s）	定时检查	✔️ 稳定但非实时

---

八、关键技术结论

1️⃣ 系统本质行为

所有组件在“各自独立重试”，没有统一协调机制

---

2️⃣ 恢复能力瓶颈

系统恢复速度取决于：

❗ 最慢的连接恢复组件（Druid + Redis）

---

3️⃣ 当前真实问题

不是 RDS Failover 问题，而是：

❗ 底层网络/服务不可达（192.168.20.0/24）

---

4️⃣ Redis 是当前风险点

• 重试机制存在

• 但参数错误导致不可用

---

九、最终总结（一句话版本）

当前系统在故障期间表现为“多组件独立重试机制同时运行”：DynamoDB每2秒重试、Redis每5.5秒重连、Druid每10.5秒补连接、Quartz每60秒检查，但由于底层网络持续不可达（192.168.20.0/24），所有重试均无法收敛，系统恢复完全依赖网络层恢复，而非RDS Failover本身。

---