异地多活本质上是一个分布式的AP方案,并对一致性做了取舍。
1.道理

2.原则
原则1 - 只保证核心业务
原则2 - 只能做到最终一致性
原则3 - 只保证绝大部分用户
[余额 库存 转账 这种要求强一致性的场景,是没法做异地多活的]
3.步骤
第一步业务分级,其实就是对应原则1,我们要只保证核心业务的异地多活,首先要把核心业务给挑选出来。

第二步数据分类,前面我们提到CAP理论,它其实关注的是数据,那我们这个系统中有很多的数据,我们要挑选对核心业务关键的一部分数据进行设计。数据分类为了后续更好的针对不同数据做AP 或者CP方案。

第三步数据同步,挑选出来的核心数据后设计同步方案,为什么要设计同步方案呢?简单的来说单纯的使用数据库或者底层存储的设计方案是没办法满足我们在某些场景下异地多活设计方案的复制要求。

第四步异常处理,我们考虑方案做完以后有哪些异常,这些情况下用户会受到什么影响,对于这些影响我们该采用什么样的措施进行弥补,才能真正做到不抛弃不放弃用户。

网友评论