导读
这一切可能是假的。
整体来讲，这个结构是符合金融级架构，如果你也在做金融级的MySQL方案，或是涉及到多DC的处理，也可以参考一下。
一、 架构直接上图:
结构说明：
1、数据库对外提供服务，是基于Zookeeper对外提供服务；
2、利用分布式监控（类似于Redis的哨兵结构监控）做MySQL的Master故障切换，从库故障下线，恢复后自动上线。
两个M之间使用增强半同步复制；其它从库使用异步复制；
假设M1故障，把写切换到M2上，M1降级为故障的从库，等待修复后自动上线为从库，如下：
基本上所有的压力主要打在主库上；
从库提供一些不重要的读的工作， 其它IDC里的从库用于一些就近的读取工作。
二、 一些细节
在该结构中，现在各大公司这种类似的结构比较多，在切换中很多公司是借助于MHA实现， 在使用GTID的环境中，这类结构切换非常容易。
复制本身因为硬件故障，或是异常重启可能会造成Binlog传输丢失，还有一些场景属于MySQL自身的Bug问题可能会造成数据的不一致。 复制不是绝对的数据一致，包括增强半同步，这里有一些场景会造成Binlog顺序乱掉，也会出错。所以金融环境中有一个数据校验机制，而且尽量单一存储引擎，不要混合使用。
数据校验上，可以使用pt-table-checksum，也可以考虑基于业务的，精确的每个小时的校验。
三、结论可以说这个结构在互联网中已经存在6年多，作者分享时也说到，现在已经是MySQL处理的一个变革的年代，技术必须要转变。 作者也在探究使用MySQL的 MGR 来替代现有的方案，同时也感觉MySQL的MGR也是技术转变的一个未来方向。
加入知数堂技术交流QQ群
（群号：579036588）
