技巧4：只保证绝大部分用户的异地多活，及银行"转账申请"式设计

前三个技巧解决方案里都留了一个尾巴：密码没同步导致部分用户登录不了、用户信息没同步导致部分用户看到旧数据，这些损失该怎么办？这背后是又一个思维误区：”我要保证业务100%可用”。答案很直接：做不到，也没有巧妙的方案能绕开这一点——光速和网络传播速度、硬盘读写速度、各种极端异常情况的不可控性，这些都是物理规律决定的硬限制，异地多活理论上就不可能做到100%可用。面对这个思维误区，正确的心态是”忍”——接受一小部分用户或业务上的损失，因为如果非要为了保住最后0.01%用户的可用性去做一个”完美”方案，反而可能因为方案本身过于复杂脆弱，结果连99.99%的用户都保证不了。对实时强一致性要求高的业务，受影响的用户比例甚至可能更高——以银行转账为例，如果假设北京和上海两个业务中心都支持”实时转账”式的异地多活，某个异常场景下小明明明只有1万元存款，却可能在北京转给张三1万元的同时又在上海转给李四1万元，两笔都转账成功，这种漏洞一旦被利用后果严重，所以银行转账这类业务根本不能做”实时转账”式的异地多活。但可以换一种业务手段变相实现异地多活：除了”实时转账”，再提供一个”转账申请”通道——用户在上海提交转账申请后，上海中心不立即执行，而是先记录下这个申请，再异步向北京发起真正的转账操作；如果此时北京中心不可用，申请就先排队等待重试；等北京中心恢复了再去真正执行转账，如果那时候余额已经不够了，这笔申请就失败，用户登录后会看到”余额不足”的失败提示。这种”转账申请”方式确实是拿用户体验换来的——原本一次操作的事，现在拆成了”提交申请”和”确认结果”两步。但为了让用户少受这个体验损失，可以配合一些安抚和补偿手段：挂公告说明情况（不方便说明原因时，用”技术哥哥正在紧急处理”这类轻松说法也可以）；事后给受影响用户补偿代金券、小礼包这类实惠；针对具体体验损失点做补充体验优化（比如转账申请成功或失败后直接发短信通知结果，用户就不用反复登录确认）。综合前面四个技巧，异地多活设计的核心思想可以归纳为一句话：采用多种手段，保证绝大部分用户的核心业务异地多活。

结构图：

flowchart TB
  A["100%可用是物理规律决定的不可能任务<br/>态度：忍受一小部分损失，而非追求完美方案"]
  A --> B["实时强一致性业务(如银行转账)<br/>影响用户比例可能更高，不能做实时多活<br/>(例：两地各转一次同一笔钱→透支)"]
  B --> C["变通方案：'转账申请'两段式"]
  C --> C1["提交申请：先记录，后台异步真正转账"]
  C1 --> C2["目标中心恢复后执行：<br/>余额够则成功，不够则'余额不足'失败"]
  C2 --> D["代价：体验被拆成两步(提交+确认)"]
  D --> E["安抚/补偿手段"]
  E --> E1["挂公告说明情况"]
  E --> E2["事后补偿(代金券/小礼包)"]
  E --> E3["补充体验(如短信直接告知结果，无需反复登录确认)"]
  E1 --> F["核心思想：采用多种手段，<br/>保证绝大部分用户的核心业务异地多活"]
  E2 --> F
  E3 --> F