异常重试_分布式场景下基于重试机制的一致性解决方案

导语

本文针对业务中异常场景处理问题，介绍了基于分布式调度机制的通用重试方案，该方案保证了业务的最终一致性，且大大降低了人工恢复异常数据的成本。。

背景

在分布式环境下，我们大部分的系统都不是单独存在的，系统与系统之间的相互依赖已是常态。
从宏观角度看，分布式“依赖”即增加了系统的整体复杂度，也增加了系统出现问题的概率。例如:在做下单操作时，调用支付系统成功，但是最终添加商品超时；当业务系统依赖的下游服务出现严重的系统问题时，导致在一段时间内的业务受到影响。系统问题最终都会体现到数据一致性上。而在解决一致性问题上，前辈们已经总结出通用的解决方案：分布式式一致性算法(paxos、两阶段提交、三阶段提交等)、最终一致性(重试、补偿、TCC)、对账。
采用分布式一致性算法去解决分布式一致性问题虽然是比较彻底的解决方案，但是实现太过复杂，并且根据CAP理论，这种方式会降低系统整体可用性。因此在我们的业务系统中，大部分都依赖最终一致性方案去解决分布式一致性问题。
“重试”是比较常用的最终一致性方案：

• “三次重试”：是最直接的方式，能减少偶发性的网络故障带来的异常。但是对于极端情况，三次重试不仅无效，而且还会对下游系统造成更大压力。
• 通过重试队列实现梯度重试：使用这种方式会根据重试次数的增加去延长下次重试时间(随着重试次数增加，但是重试依然不成功，说明目标系统恢复时间比较长，因此可以根据重试次数延长下次重试时间)。这种方式即能有效提高重试成功的几率，也能通过柔性化的重试避免对下游系统造成更大压力。但是实现起来比较复杂，成本比较高。
• 人工修复：人工修复也是重试，只不过需要人工操作。当走到这一步时，说明已经造成了线上事故，我们通常的处理方式就是：筛选日志->开发修复脚本->修复脚本测试->批量修复。这个流程已经相当于一个小型的需求开发，我们需要花费至少1天时间去修复。如果业务逻辑复杂，系统日志不全，需要花费更多的时间去修复。

相信做过后端开发的同学对于上述方案的痛点感同身受。因此我们开发了基于分布式调度的分布式重试系统。系统提供了多样化的重试策略；能自动探测目标系统的恢复情况，并进行数据的自动恢复；提供了可视化的操作平台，降低了人工修复数据的成本；并提供了基于异常点的监控报警机制，提高问题定位的效率。

整体介绍