参考
阿里多活
苏宁多活
采用方案
项目背景
公司项目主要是做支付和商城的，因此可以参考阿里和苏宁的实现
资源划分
- multi zone资源：以会员作为分片依据，对会员数据以及会员业务链路上的数据做多活，业务收敛在本zone内，数据在本zone进行读写
- global资源：商家数据和商品数据等作为全局zone，放主数据中心，单写多读
- 用户的注册等操作，为了避免数据冲突，也应该回到主数据中心进行。而用户登录鉴权就做成多活，因为注册操作和登录鉴权操作对比，后者会多得多，而如果同步存在延时，分片中查不到已注册的用户信息，可以根据session或者token中的信息，短时间内允许降级回主数据中心进行登录鉴权。路由错误跑到别的zone也一样，可以二次查询回到对应的zone。
- 库存等会导致数据冲突的资源，统一放主数据中心做管理，可参考苏宁的竞争Proxy服务的实现，每次从主数据中心中请求一批资源放到本zone，用完再向数据中心拿，减少跨机房调用的次数
路由
- 用户标识和zone之间存在对应关系，可动态改变
- 在cdn层或者增加一层api router层，根据用户标识计算sharding key，把流量转发到对应的zone
数据同步
- multi zone中的资源异步复制到主数据中心，再由主数据中心分发到各个zone，保证所有数据中心的最终一致性
- 主数据中心的变更同步到各个从数据中心
- 数据中心之间异步同步，保证可用性，牺牲一致性，但是问题不大，因为用户业务都是收敛在本zone内的，这部分是强一致的
容灾
由于所有数据中心都拥有全量数据，出现故障后，只需要人工修复少量来不及同步的数据然后切换流量，即可恢复服务
