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