国内某大型支付系统MySQL架构

导读

这一切可能是假的。 内容来自于一个技术大会的猜想，作者不愿意公开分享PPT，所以也没有原版PPT可以供大家核对。这里我也是根据自已听的，重现一下。

整体来讲，这个结构是符合金融级架构，如果你也在做金融级的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也是技术转变的一个未来方向。