第4步：异常处理四类措施——多通道同步、同步访问结合、日志记录与用户补偿

不管[[第3步：数据同步三种方案——存储系统同步、消息队列同步与重复生成]]设计得多好，极端异常下总会出现同步延迟、数据丢失、数据不一致这类问题，异常处理要达成三个目的：问题发生时避免少量数据异常拖垮整体业务、问题恢复后修正异常数据、对受影响用户做安抚补偿。常见措施有四类。多通道同步指用多种方式并行同步数据，一条通道故障时还有另一条兜底——比如用户账号数据本来用消息队列同步，考虑到消息队列通道可能中断或严重延迟，再加一条MySQL主从同步作为备份，两条通道同时故障的概率远低于单一通道；关键设计点是通常两条通道就够（更多通道理论上更保险，但成本涨得也快）、两条通道不能共用同一条网络连接（一个走公网、一个走内网这种物理隔离才有意义）、且要求数据本身可重复覆盖（谁先到谁后到最终结果都一样，比如新建账号数据符合、密码数据就不符合）。同步和访问结合指异地机房通过接口互相调用来读取对方的数据（比如B机房本地没有A机房刚同步过来的数据，就直接调A机房接口取），关键设计点是接口访问通道不能和数据库同步通道共用同一条网络、要有路由规则判断该访问哪个机房的接口、并且要优先读本地数据、本地读不到才走接口访问以降低跨机房调用量，特别适合实时性要求非常高的数据。日志记录用于故障恢复后修数据，做法是每个关键操作前后都记一条日志、单独保存，故障恢复后拿日志和实际数据比对修复——根据要应对的故障级别不同，日志保存方式也分级：存在服务器本地能应对单台数据库故障，存在独立本地系统能应对服务器和数据库同时宕机（比如两者部署在同一机架或同一电源线路上时会一起挂），日志异地保存则能应对整个机房宕机的极端情况，方案越能应对更严重的故障，复杂度和成本也越高，需要综合权衡。用户补偿则是承认前面三类措施终究无法做到100%没有影响（双通道也可能同时故障、日志本身也可能丢），系统方案的目标是保证99.99%的用户不受影响，剩下0.01%的损失只能靠人工补偿（代金券、礼包、礼品、红包等）来弥补、培养用户忠诚度——暴雪《炉石传说》2017年回档事故就是一个真实案例：给每个受影响玩家补偿了约合人民币200元的游戏物品（1000金币+15个卡牌包），最终玩家的反应是”求暴雪再来一次回档”，充分说明了到位的补偿能把一次故障转化成正向的用户口碑。

结构图：

flowchart TB
  A["第4步：异常处理四类措施"]
  A --> B["多通道同步<br/>双通道互为备份，不共用网络连接<br/>要求数据可重复覆盖"]
  A --> C["同步和访问结合<br/>本地读不到就跨机房接口访问对端<br/>接口通道与同步通道物理隔离"]
  A --> D["日志记录<br/>关键操作前后记日志，故障后比对修复"]
  D --> D1["服务器本地保存→应对单机故障"]
  D --> D2["独立本地系统保存→应对服务器+数据库同时宕机"]
  D --> D3["异地保存→应对整个机房宕机"]
  A --> E["用户补偿<br/>系统方案保99.99%用户不受影响<br/>剩余0.01%靠人工补偿弥补"]
  E --> F["实例：炉石传说2017回档<br/>约200元补偿→玩家反而'求再来一次'"]