从服务和存储角度看异地多活的高可用架构

现在越来越多的数据库采用分布式数据库系统，例如Google的Spanner，阿里巴巴的PolarDB，Oceanbase，开源的Tidb和CockroachDB等，他们可实现存储层的数据一致性，其依赖Paxos或者Raft协议。把存储近似看做一个状态机，对数据每次修改都可以看做一次增量日志，事务的实现，可以在存储上套一层Paxos或者Raft协议。例如，三个节点的集群，Raft的Leader负责写，Leader的事务日志同步到follower，超过多数派（majority quorum）落盘后，再commit。这种架构对于写入的延迟明显高了，但是这种小幅的牺牲却可以保证数据强一致。而吞吐可以靠拆分解决，可以存在很多的Raft Group，数据按照Range进行分区，还可以做二级分区，这种的sharding效果等同于分库分表，而扩展性、灵活性和容灾能力更好。只要有半数以上的节点正常就能保证分布式数据库正常工作，当Leader节点故障时发起Leader election自行恢复，无需人工switch over或者failover。

在阿里云上的”金融级“RDS，其原理也是在MySQL内核上套用一个Raft状态机控制事务，保证了数据的一致性，由于分布式数据库的依赖Paxos或者Raft，所以延迟更是问题，一般部署在同地域，例如”金融级“RDS要求部署在同一个区域，依赖DTS做异地复制。

分布式数据库单Group至少3个节点，更加可靠的方案可以采用5个节点，3地3机房5副本，参考 蚂蚁金服Oceanbase的”五地三中心“架构 ，Zone1和Zone2同城双机房，Zone3和Zone4同城双机房，一个距离稍远的可以设计为仅做日志副本，节省空间，同时减少延迟带来的吞吐下降，可做到RPO=0，RTO几十秒，强一致，可抵御个别硬件故障、机房级灾难和区域级灾难。