Spring Boot + MongoDB服务应对数据库不可用的韧性提升方案

• 本地磁盘持久化兜底
  当数据库写入失败时，立刻把回调数据序列化（比如转成JSON或Protobuf格式）写入本地指定的专属目录，文件名用[订单号]_[时间戳]命名，避免重复或覆盖。启动一个后台定时线程，每隔固定时间扫描这个目录，读取文件内容尝试写入数据库，成功后就删除对应文件。要注意加文件锁防止多线程重复处理，同时监控目录占用的磁盘空间，防止数据积压撑爆磁盘。这种方案不需要额外中间件，是队列方案失效时的终极兜底手段。

• 数据库连接池优化+智能重试

  • 调整连接池参数：增大maxIdle和maxActive的数值，配置validationQuery（比如MySQL用SELECT 1），开启testOnBorrow校验，确保每次获取的连接都是可用的，减少因连接失效导致的写入失败。
  • 实现指数退避重试：针对数据库写入操作，遇到连接超时、临时不可用这类可重试异常时，按1s、2s、4s…的指数间隔重试（最多5次左右），避开瞬时故障窗口。但必须保证支付回调的幂等性——比如用订单号作为数据库唯一索引，即使重试也不会生成重复数据。

• 多数据源冗余写入
  配置主备数据库或者同城灾备库，当主库写入失败时，自动切换到备库写入数据。后续主库恢复正常后，要启动数据同步校验任务，把备库中暂存的回调数据同步到主库，保证数据最终一致。这种方案适合对数据可靠性要求极高的金融支付场景，能有效应对主库长时间宕机的情况。

• 回调请求异步处理+主动触发重发

  • 接收到支付网关回调时，先返回202 Accepted的临时响应，不用等数据库写入成功再返回200，避免网关因超时重复发送回调。
  • 把回调数据同时存入本地内存缓存（比如Guava Cache）和本地文件，后台异步线程负责尝试写入数据库。
  • 如果异步写入多次失败，主动调用支付网关的订单查询接口，获取最新的支付详情补充本地数据，然后重试写入。同时要和网关约定重发规则，确保网关在未收到200响应时，会按策略重发回调请求，这时服务要做好幂等处理，避免重复入库。

• 状态跟踪+补偿任务
  给每个回调请求设置状态：待处理、处理中、成功、失败。状态数据可以存在本地文件或更稳定的轻量存储（比如Redis）。后台启动补偿任务，每隔一段时间扫描标记为“失败”的请求，自动重试写入数据库。另外提供手动补偿的接口，方便运维人员在极端场景下介入处理。

内容的提问来源于stack exchange，提问作者ananda