大道至简
图片
左图展示了一个强调一致性（C）和分区容忍性（P）的系统。在这种系统中，当网络分区（Partition）发生错误时，系统可能会拒绝操作以保持数据的一致性，牺牲了一部分可用性。例如，如果节点N1和N2无法通信（分区容忍性问题），系统可能会选择停止操作，确保任何读取都是一致的，即使这意味着某些操作不能完成。
右图展示的是一个强调可用性（A）和分区容忍性（P）的系统。在这种系统中，即使发生了分区错误，每个节点（N1和N2）仍会尽力响应用户的请求，保证服务的可用性。这可能导致数据的不一致，因为两个分区可能会独立响应并导致数据状态不同步。
异地多活架构设计的本质是平衡CAP定理中的“可用性（A）”和“分区容忍性（P）”，而通常在必要的情况下对“一致性（C）”做出一定程度的妥协。
大道至深 - CAP
粒度：
CAP 关注的粒度是数据，而不是系统，需要根据不同业务的数据特点来设计
异地多活。
延迟：
CAP 是忽略网络延迟的 ，但工程落地不可能做到零延迟。
分区容忍：
C和A只能取1个是在发生分区的时候，正常运行情况下，可以同时满足 CA。
补救：
放弃 != 无为，需要为分区恢复后做准备，包括人工修复数据。
原则1 - 只保证核心业务
图片
不同业务的数据特性不同，无法全部做到异地多活。
原则2 - 只能做到最终一致性
图片
复制肯定有时间窗，抛弃实时一致性的幻想
原则3 - 只能保证绝大部分用户
图片
异地多活设计步骤
1.业务分级：
将业务按照某个维度进行优先级排序，优先保证TOP3 业务异地多活。
2.数据分类：
分析 TOP3 中的每个业务的关键数据特点，将数据分类。
3.数据同步
针对不同的数据分类设计不同的数据同步方式。
4.异常处理
针对极端异常的情况，考虑如何处理，可以是技术手段或非技术手段。
步骤1 – 业务分级
访问量：
登录 > 注册 > 修改密码
核心场景：
聊天 > 朋友圈 > 摇一摇
收入来源：
订单 > 搜索 > 编辑
步骤2 – 数据分类
数据的修改量：
数据被修改的数量和频率，包括新增、删除、修改。
一致性：
数据的一致性要求，例如：强一致性（余额、库存）、最终一致性（动态、兴趣）。
唯一性：
数据的唯一性要求，例如：全局唯一（用户 ID）、可重复（昵称）
可丢失性：
数据是否可丢失，例如：不可丢失（账户余额）、可丢失（微博、密码）。
可恢复性：
数据是否可恢复，例如：用户恢复（微博）、系统提供恢复（密码找回）、内部恢复（例如编辑和运营重发）。
步骤3 – 数据同步
图片
多管齐下，“不择手段”，不要局限于存储系统同步！
步骤3 – 数据同步技巧
步骤4 –异常处理
业务兼容：
体验不好 优于 无法体验。
1. 数据短时间不一致：业务有损，例如微博、朋友圈；
2. 数据无法获取：转账申请，支付核对中。
事后补偿：
少量用户损失，用钱解决。
1. 礼包、红包；
2. 礼物、物品（暴雪炉石回档补偿）；
3. 保险赔偿。
人工修正：
尽力而为，减少损失。
1. 人工订正数据，达到最终一致性；
2. 重要事情说三遍：日志、日志、日志。
5大技巧1 - 消息队列同步
适合全局唯一的数据，因为可以覆盖；不适合余额之类的数据，因为数据修改无法做到幂等性。
5大技巧2 - 库存拆分
余额这么拆分可以吗？
通常会有一个中央权威的账户管理系统来处理余额，而不是在各个数据中心分别处理。这样可以简化一致性和同步的复杂性，尽管这可能牺牲一些响应时间和可用性
5大技巧3 - 事务合并
图片
例如：游戏玩家异地充值100，消费60，即使 IDC-B 的业务服务器不知道玩家的实际余额（在 IDC-A 的数据库中），业务也是可以继续处理的，具体实现逻辑如下：
1. 正常情况下通过数据库同步来同步余额，对应上图的 IDC-A 到 IDC-B 的“余额同步”；
2. 异常情况下，IDC-A 机房挂掉，余额同步中断，可能会导致 IDC-A 和 IDC-B 的数据不同步，例如图中两个余额表的余额，IDC-A 是 30，IDC-B 是65；
3. 玩家到 IDC-B 想消费60块，无论 IDC-B 的余额表中是大于还是小于60，都不能直接消费，因为无法判断这个余额数据是否一致；
4. 玩家到 IDC-B 先充值100块，再消费60块，无论 IDC-B 的余额表中是大于还是小于60，都是允许的，此时 IDC-B 在临时事务表中记录两个事务；
5. IDC-A 恢复后，IDC-B 将临时事务表中的事务发给 IDC-A，IDC-A 进行合并，合并后的真实余额是70元，然后再通过“余额同步”这个通道将70元余额同步给 IDC-B 的余额表。
5大技巧4 - 实时改异步
图片
5大技巧5 - 适当容忍
图片
业务上稍微放开一些约束，例如：电话会议系统允许欠费也能发起会议。
总结：
图片
