您现在的位置是：网站首页>技术百科技术百科

分布式场景下的资损防控

小大寒2024-01-01[技术百科]博学多闻

分布式场景下的资损防控资损防控包括事中定位和事后应急两部分。事中定位通过管理变更点和高效日志排查快速发现问题；事后应急则依赖回滚和降级机制，确保最小成本解决问题。通过演练真实场景验证三道防线的有效性，提升1分钟发现、5分钟定位、10分钟止损的能力，全面保障业务资金安全。

分布式场景下的资损防控

资损的定义

资损是指在业务活动中，由于业务规则与实际资金流动不一致，导致业务参与方中任何一方或多方遭受资金损失的情况。简单来说，就是系统的某个功能出现问题（如BUG），导致用户或公司出现资金损失。例如：在营销过程中多发给某个用户10元红包，或者用户领取了10元红包却无法使用；用户支付时看到订单金额是100元，实际支付了101元或99元。这些情况都属于资损。用户支付101元时，用户资损了1元；而用户支付99元时，公司资损了1元。

为什么要重视资损防控？

资金损失金额过大会直接摧毁一个业务。例如某业务在一次运营活动中，将9折优惠券误配置成1折，并发放给数百万用户，这可能导致几千万元的资金损失。而如果业务本身并未盈利几千万，这种损失可能直接导致业务崩溃。因此，凡涉及资金流动的业务，其防控工作都尤为重要。

如何进行资损防控

资损防控需要设定明确目标，对于核心业务通常设定“1-5-10”目标，即：

1分钟内发现问题
5分钟内定位问题
10分钟内解决问题

例如，如果误发了错误折扣的优惠券，我们需要在1分钟内发现问题，5分钟内定位是配置错误还是系统BUG，10分钟内停止优惠券的发放。

资损防控的三道防线

为了实现“1-5-10”的目标，需要构建以下三道防线：

事前规避问题
事中快速定位问题
事后以最小成本解决问题

第一道防线：事前规避

通过建立编码规范和发布规范，尽量在问题发生前予以规避。

建立编码规范

根据业务需求制定相应的编码规范，以下为几个示例：

禁止使用ThreadLocal：如果系统使用线程池，线程池内的线程是共享的，使用ThreadLocal存储数据可能因异常未清理原数据，导致问题难以排查。例如，用户A的状态可能串到用户B，造成优惠券错发。
幂等控制：确保同一请求多次执行结果一致。可以设计一个幂等号，通常由业务阶段和唯一业务号（如支付单号）组成。业务阶段包括支付、退款等，幂等号的唯一性可有效防止重复执行引发的问题。
无状态服务：服务器应保持无状态。在分布式环境中，应用可能部署在多台服务器上，状态型数据需存储在统一的分布式存储中，否则请求可能因路由到不同服务器而丢失状态信息。

建立发布规范

系统发布需遵循以下三要素：

可灰度：逐步切流，观察系统运行情况。例如，优惠券活动先发给内部用户，再逐步扩展到小规模用户群，最后覆盖全部用户。
可监控：通过业务监控和系统监控及时发现异常。业务监控指标包括交易笔数、支付金额等；系统监控指标包括TPS、QPS、磁盘容量等。
可回滚：所有变更都需具备回滚能力，确保出现问题时能迅速恢复到初始状态。

第二道防线：事中定位

事中定位包括两大核心能力：

查找变更点：快速识别系统最近的配置或代码变更，缩小排查范围。
排查日志：通过系统日志分析问题来源，结合监控工具定位问题根因。

找变更点

大多数线上问题与系统变更密切相关，例如上线一个新功能或推送一项新配置。这些都属于线上变更。快速定位问题的关键是首先找到变更点，然后评估业务流量的骤增是否与该变更相关。如果一次发布包含多个变更点，可以通过发布系统管理所有变更点，实时同步变更信息到团队沟通渠道。没有发布系统时，也可要求开发人员在变更前主动在群内同步变更内容。

变更内容的同步可以包括以下信息：

变更点：例如“1002XX功能上线”
变更类型：系统变更 + SQL调整
变更系统：具体涉及的系统名称
变更人：例如“张三”
变更环境：生产环境
变更时间：开始时间和结束时间（如“10月2日12:00 - 14:00”）

排查日志

快速排查日志需要做到以下两点：管理日志级别和确保关键日志的有效打印。

管理日志级别

线上问题发生时，首先应排查系统错误日志和关键指标是否异常，判断其与问题是否相关。为了提高日志排查效率，需日常维护好日志质量。例如线上错误日志应尽可能少。若某些日志确认不是线上问题，可将其级别从ERROR调整为WARN。这样，只要出现ERROR日志，就可能是线上问题，有助于提升运维敏感度，避免"狼来了"的困境。