1、树状结构（Master，Backup-Master，Slaves）

        

        这种结构是目前Web系统用的最为通用的一种。整个系统有1个写入/更新点，即Master；Master-Backup和Slaves都是Replication的Master从库；多级Slave的原因是为了数据过滤和节省网络资源。

     2、环状结构（Master-Master，Slaves）

        

        Dual-Master结构是为了提高写吞吐而提出的，通过提高由原来一台MySQL Master服务器提供写/更新的

单点提高到2个点，从框架结构上来说就能看出此方法的提升。

        Dual-Master需要解决的问题：

        a）ID冲突问题，即对数据库中唯一ID资源的分配必须是一个统一的地方发出。

           解决办法有MySQL自带的auto_increment_increment和auto_increment_offset来实现，通过N个 Master来设置auto_increment_offset=N，每一台Master上的auto_increment_increment采用 1~N中的任意值，但是不能互相重复。如此一来即可。

           id-server: 1

           auto_increment_increment=1

           auto_increment_offset=2

           id-server: 2

           auto_increment_increment=2

           auto_increment_offset=2

           针对id-server1来说，id都是1,3,5这样；id-server2来说，id都是2,4,6这样。如此看似很美好，其实不然。在并发情况 下，id-server1上相同的表和在id-server2上的表auto_increment值是不同的，但是又需要相互同步，也就是说如果写入分布 不均的情况，就可能存在表中id会是1,3,5,7,8,9,11，etc这样的情况，id资源中间空洞太多。

           还有一种解决办法是一个独立的ID发号器。实现ID发号器的办法很多，为了让维护更加的纯粹，我们使用一个MySQL的一张表，Master-slave 这种结构的来作为一个发号器server。这样一来流程就变成了先去id发号器服务器获取id，再写入Dual-Master中去。多了一个中间环节，而 且此中间环节还是个单点，存在风险。但是思路基本这样，可以通过别的服务，基于一定分布式规则的来并行发号器。

        b）更新冲突的问题，一条范围的update语句被两台Master server都给执行了，这个时候数据就和最初设想的不一致了。

        c）死锁问题，这个在N（N>=3）个以上的环路Master中，出现异常断开后的服务器的binlog，在极端情况下会被恢复后的N-1个环路中的数据server反复执行。

    为了解决Multi-Master中的更新冲突和死锁问题，我的办法是多点Insert，但是只有一个点update这样的结构来解决以上b和c的问题。

        

    以上已经将Replication的常用的两种数据分布架构介绍清楚，下来看看另外一种，即MySQL Cluster。MySQL Cluster在一段时间内，我都认为它是相当的鸡肋，生产环境使用它的几乎没有。因为它在跨IDC和数据存储等资源消耗巨大。

    MySQL Cluster依赖的两个核心资源就是网络带宽和内存（share nothing和高一致性）。同IDC内的网络带宽还很容易达到百兆或者更高，但是跨IDC的VPN或者专线，要达到这样的速度还是有些困难。数据全部存 在内存中，这在小数据时感受不明显，但是对于爆炸式的信息增长来说未免很容易产生瓶颈。虽然新版的Cluster支持将数据写到硬盘，实际速度还有待观 察。

    Replication基本能够满足可用的需求，但是MySQL的binlog是一个单线程的，这就会在数据同步方面产生瓶颈。一般的做法是 通过写一个plugin，来提高并发能力；这个plugin既要满足性能，有要高可用。采用以下方式，通过将一些并行的App绑定在MySQL Cluster Queue上来执行，利用MySQL Cluster自身的高一致性，高可用的特点，存储消息。

    

 如此可以既能满足数据分布式，又能满足并行数据同步。