《架构师之路：架构设计中的100个知识点》9.数据库高可用与一致性架构实践上一篇聊了数据库架构设计中的scalability实践，并没有解决availability与consistency的问题。

数据库架构设计的过程中，如何折衷高可用与一致性的问题呢？

前面的文章聊过，高可用的核心方法论是：冗余（replication）+ 故障自动转移（fail-over）。

最容易想到的，是数据库主从集群，每份数据都进行复制，每个实例都独享DISK/MEM/CPU资源，避免实例之间的资源竞争。

如上图所示：（1）把整体数据存储分复制了N份，每份之间数据都一样；（2）每份数据的DISK/MEM/CPU都在一个DBMS进程内，部署在一台服务器上；（3）每份数据的资源之间的没有竞争；理想很丰满，现实很骨感，思路没问题，但实际执行“复制”的过程中，会碰到一些问题。以MySQL为例，有3种常见的复制方式：（1）异步复制；（2）半同步复制；（3）组复制；第一种，异步复制（Asynchronous Replication）又叫主从复制（Primary-Secondary Replication），是互联网公司用的最多的数据复制与数据库集群化方法，它的思路是，从库执行串行化后的主库事务。

其核心原理如上图所示：（1）第一条时间线：主库时间线；- 主库执行事务- 主库事务串行化binlog- binlog同步给从库- 主库事务提交完成（2）第二条/第三条时间线：从库时间线；- 收到relay log- 执行和主库一样的事务- 生成自己的binlog（还可以继续二级从库）- 从库事务提交完成从这个时间线可以看到：（1）主库事务提交；（2）从库事务执行；是并行执行的，主库并不能保证从库的事务一定执行成功，甚至不能保证从库一定收到相关的请求，这也是其称作“异步复制”的原因。第二种，半同步复制（Semi-synchronous Replication）为了解决异步复制中“不能保证从库一定收到请求”等问题，对异步复制做了升级。

其核心原理如上图所示：（1）第一条时间线：主库时间线；- 主库执行事务- 主库事务串行化binlog- binlog同步给从库-等从库确认收到请求，主库事务才提交完成（2）第二条/第三条时间线：从库时间线；- 收到relay log-执行和主库一样的事务，并给主库一个确认- 生成自己的binlog（还可以继续二级从库）- 从库事务提交完成从这个时间线可以看到：（1）主库收到从库的ACK，才会提交；（2）从库收到请求后，事务提交前，会给主库一个ACK；半同步复制存在什么问题呢？（1）主库的性能，会受到较大的影响，事务提交之前，中间至少要等待2个主从之间的网络TTL；（2）从库仍然有延时，主从之间数据仍然不一致；（3）主从角色有差异，主节点仍然是单点；大数据量，高并发量的互联网业务，一般不使用“半同步复制”，更多的公司仍然使用“异步复制”的模式。最后是MySQL5.7里，新提出的MySQL组复制。第三种，组复制（MySQL Group Replication，MGR）MGR有一些帅气的能力：（1）解决了单点写入的问题，一个分组内的所有节点都能够写入；（2）最终一致性，缓解了一致性问题，可以认为大部分实例的数据都是最新的；（3）高可用，系统故障时（即使是脑裂），系统依然可用；

如上图所示：（1）首先，分组内的MySQL实例不再是“主从”关系，而是对等的“成员”关系，故每个节点都可以写入；（2）其次，增加了一个协商共识的认证（certify）环节，多数节点达成一致的事务才能提交；画外音：Garela也是此类机制。结尾稍作总结，为了折衷数据库高可用，一致性，性能等架构设计要素，一般有三类常见复制方式：（1）异步复制，传统主从，互联网公司最常用；（2）半同步复制，从库确认，主库才提交；（3）组复制，MySQL 5.7的新功能，核心在于分布式共识算法；知其然，知其所以然。思路比结论更重要。