因为我们的数据是异地多份存储的,考虑到数据库的性能，我们在写入数据的时候是不能去给所有机房的这条数据上锁,也就是我们的ACID是在本地机房级别的。为了避免不同机房出现数据最终不一致的问题，我们需要限制数据的写入点,一条数据只能在一个机房写入,避免两个机房同时写一条数据导致的数据最终不一致问题。为了实现这个目的，我们需要一层数据路由。所谓数据路由,就是在程序链接数据库之前,在DAL层,或者驱动层,或者框架,ORM层,等等上面的一层路由。确保落地的数据是能落到正确的机房,以保证数据的最终一致性。
数据同步
根据我们的需求,做了基础调研以后,发现有以下几种方法可以实现我们需要的数据同步功能。
1、基于mysql的原生复制,做主主架构,两边都开启写入。
2、基于PXC类似的数据库集群方案
3、基于otter的数据同步方案
4、自己开发一套数据库同步系统
在有现有软件满足我们需求的前提下，我们是不优先考虑自己开发的。毕竟重复自造轮子的开销不小，而且需要比较长的一个时间来验证轮子的稳定性。
所以优先在前面三个方案里面做了深度调研。
OTTER:
优点:
1、两个机房的mysql独立,本地机房做维护切换架构清晰,简单.
2、如果数据同步异常的时候,推移位点可以保证数据的一致性.
3、与mysql版本无关,可实现低版本往高版本复制,方便升级.
4、在公司的汇总库中使用,已经有比较深的使用经验
缺点:
1、引进了新的技术,存在风险,需要评估风险是否可控.
MySQL原生复制:
优点:
1、原生的复制协议,大家都熟悉,可控度比较好.
缺点(未使用GTID):
1、会增加架构的复杂度,级联复制.
2、如果数据同步异常的时候,寻找同步位点比较麻烦.
3、如果其中一个master的机器坏掉,会导致同步的位点丢失.
4、三机房以后架构不支持
PXC:
优点:
1、通过Galera实现的无共享的分布式数据库。
2、使用同步复制,可以完全保证数据的一致性
3、节点自动配置
缺点:
1、PXC我们团队还没有使用案例,在核心的双活架构中使用，存在很大的不可控风险.
2、Galera对网络延时比较敏感，在跨机房应用中，这是一个很大的性能瓶颈。
综合上面的分析，我们最终选择了使用otter来作为双活机房的数据同步组件,当然基于我们的业务场景和功能，也对OTTER做了一些小的调整。
分区情况下的数据合并
在单元化与数据同步方案都确定的前提下，我们来讨论一下数据合并。比如我们有A<—>B两个机房,做了双活架构,中间使用OTTER做数据同步,每张表同时只有一个机房允许写入。当一个机房的网络断掉以后，那么就出现了分区问题。这个时候,我们有两个选择。
1、将属于这个机房的用户切换到其他机房。
2、什么也不做，不能给这部分用户提供服务。
在可能的情况下，大家肯定会选择1,将用户切换到其他机房,这个本来也是我们架构的目的。但是如果切了会出现什么问题呢？最大的问题就是,挂掉机房写入的数据还没有来得及同步到其他机房。网络就断掉了,如果把用户切换到其他机房，那么他看见的数据就存在一致性问题,这个问题是我们架构选择了最终一致性和异步同步数据导致的。
如果站在业务角度来看，就是User A在订单支付以后,他所在的机房刚好处理完,还没有把处理结果,也就是订单的支付状态及信息同步到其他机房就断网了。这个时候用户切换到其他机房,那么就会看见订单未付款，如果他联系客服还好。如果他又再支付了一次,那么问题就严重了。等故障的机房好了以后，那么数据一同步，不同机房这个用户的支付信息就不一样。出现了数据的不一致性，对于用户来说,同一个商品，他却付款了两次。这种情况就只有走人工的异常处理流程了。
对于一个大型电商网站，每秒的交易量成千上万。显然全部走人工的异常处理流程是下下之策。
这个时候大家又说，那就什么都不做吧。但是这样是不是和我们的初衷有点违背呢？其实还有解决方案,怎么解决？
现在又到了0和1之间的选择，0是不给那部分机房提供服务，1是要给那部分机房提供服务。 可是大家想过没有，我可以给那个机房提供有损服务，也就是0和1之间。如何做？
对于已有的数据,并且是已经故障的机房产生的数据是不能更新,但是对于新写入的数据是可以更新的。这个地方可以通过全局的ID生成器来判断数据的来源，根据业务时间作为时间线的参考,从而保证只对一部分数据产生影响。
如果在没有这个机制的前提下，我建议还是什么也不做把,至少我们有N-1/N的用户是可以正常服务的,N为机房数量。 这已经达到了0月1之间,而不是0。
##异地多活的case方案，虽说实现各异，但万变不离其宗。
银行之前出现过db2复制导致数据库崩溃事件，xxx银行数十小时不可用事件其根本还是保障了数据一致性，未敢提供业务连续性部分，甚至是部分可用。因为出现风险的应对审批和管控流程很复杂；而大部分情况下在同城节点等待一定时间后实行了业务恢复。而对于互联网架构，可以采取部分有损的方案，比如90%的用户可用，是不是也是可以接受的呢？某些数据不能修改，只能做大部分业务是不是也可以接受呢？互联网提供了更多开放的可能性。
