1、一主多从
适用场景：数据实时性要求不高，读多写少。
实现方式：扩展slave数量，将读压力分散到多台slave机器上，以此解决数据库端的读性能瓶颈。
在实际应用场景中，MySQL复制90%以上都是一个Master复制到一个或者多个Slave的架构模式，主要用于读压力比较大的应用的数据库端廉价扩展解决方案。因为只要Master和Slave的压力不是太大（尤其是Slave端压力）的话，异步复制的延时一般都很少很 少。尤其是自从Slave端的复制方式改成两个线程处理之后，更是减小了Slave端的延时问题。而带来的效益是，对于数据实时性要求不是特别Critical的应用，只需要通过廉价的pcserver来扩展Slave的数量，将读压力分散到多台Slave的机器上面，即可通过分散单台数据库服务器的读压力来解决数据库端的读性能瓶颈，毕竟在大多数数据库应用系统中的读压力还是要比写压力大很多。这在很大程度上解决了目前很多中小型网站的数据库压力瓶颈问题，甚至有些大型网站也在使用类似方案解决数据库瓶颈。
但是，当slave增加到一定数量时，slave对master的负载以及网络带宽都会成为一个严重的问题。
2、级联复制架构 Master-Slaves-Slaves
在有些应用场景中，可能读写压力差别比较大，读压力特别的大，一个Master可能需要上10台甚至更多的Slave才能够支撑注读的压力。这时候，Master就会比较吃力了，因为仅仅连上来的SlaveIO线程就比较多了，这样写的压力稍微大一点的时候，Master端因为复制就会消耗较多的资源，很容易造成复制的延时。
3、Mysql Cluster
可用性高、数据一致性好
安装配置管理繁琐，适合场景局限
总体不推荐
4、双主复制
心跳监测和资源接管。在指定的时间没有收到对方发送的报文，就认为对方失效，这时需启动资源接管模块来接管运行在对方主机上的资源或服务。
5、DRBD
DRBD 是途过网络来实现块设备的数据镜像同步的一款开源 Cluster 软件，它自动完成网络中两个不同服务器上的磁盘同步，相对于 binlog 日志同步，它是更底层的磁盘同步，理论上 DRDB 适合很多文件型系统的高可用。
6、Lvs+Keepalived+双主复制
7、MariaDB Galera
参考资料：
1、http://blog.csdn.net/hguisu/article/details/7325124/
2、mycat_1.5.2.pdf