1 简介
本文章讨论了全同步、半同步和异步复制三种模式，全同步保证数据实时性但对服务器要求高，半同步允许一定延时，而异步复制牺牲实时性换取性能。
在遇到大并发的请求场景时。采用主从同步+读写分离，去实现数据的读写加速是主流的操作，那么分析一下业务，适合哪个同步模式（全同步，半同步，异步）就非常必要了，比如有如下问题：
遇到单点故障，服务不可用
无法处理大量的并发数据请求，数据丢失将会造成很大损失
2 方案
增加MySQL数据库服务器，对数据进行备份，形成主备，确保主备MySQL数据库服务器数据是一样的。
主服务器宕机了，备份服务器继续工作，数据有保障，MySQL主从复制与读写分离是密切相关的。
通过主从复制的方式来同步数据，再通过读写分离来提升数据库的并发负载能力。
使用代理同步：
一个以MySQL为底层数据存储，并对应用提供MySQL协议接口的proxy，外号变形虫(Amoeba)
读取请求发送给从服务器时，采用轮询调度算法.主服务器挂掉，采用MHA解决。
这将涉及到的账号权限：
主从同步账号
节点服务器开放调度账号
Amoeba代理账号
注意点：
1 主服务器需要开一个主从复制权限账户， 第一个账户
2 代理服务把写的操作给master，读的操作给slave，轮询从数据库服务
3 读写分离账户，第二个账户
4 client 照amoeba进行访问，访问amoeba账号
3 主从复制类型
基于语句的复制（默认）
在主服务器上执行的语句，从服务器执行同样的语句
基于行的复制
把改变的内容复制到从服务器
混合类型的复制
一旦发现基于语句无法精确复制时，就会采用基于行的复制
4 主从同步过程：
先找位置，匹配到位置后I/o线程去找二进制日志，进行读取更新，再写入中继日志，从服务器读取中继日志，从而进行相对应操作.
操作步骤：
1 关闭防火墙 2 建立时间同步环境 3 编译安装mysql 4 配置mysql 主服务器 5 配置两个从服务器 6 测试读写分离
在表Myisam或行innodb被锁定时，
只能读不能写，或者只能写不能读都需要读写分离。
读写分离就是主服务写，从服务读
数据库复制被用来把事务性查询变更同步到集群的从数据库。
主从同步+读写分离 全同步，半同步，异步
5 强同步
数据实时性要求高，不能丢失使用全同步，服务器的要求比较高，全部slave返回。
master在执行完更新操作后立即向slave复制数据，slave接受到数据并执行完后才向master返回成功的信息，master必须接收到slave的成功信息后再向应用程序响应。
因master向slave复制数据是同步进行的，master每次更新操作都需要保证slave也成功执行，因此强同步复制能最大限度保障主从数据的一直性。
但因每次master更新操作都强依赖于slave的返回，因此slave如果仅此一台，它不可用将极大影响master上的正常操作。
某些(腾讯)云数据库MySQL强同步复制采用一主两从的架构，仅需其中一台slave成功执行即可返回，避免了单台slave不可以用影响master上操作的问题，提高了强同步复制集群的可用性。
6 半同步
数据可有一定延时，不能丢失，只需某一个slave返回即可。
应用发起数据更新（含insert、update、delete操作）请求，master在执行完更新操作后立即向slave复制数据，slave接收到数据并写到relaylog中（不需要执行）后才向master返回成功的信息。
master必须在接收到slave的成功信息后再向应用程序返回响应。
仅在数据复制发生异常（slave节点不可以用或者数据复制所用的网络发生异常）的情况下，master会暂停（MySQL默认10s左右）对应用的响应，将复制方式降为异步复制。
当数据复制恢复正常，将恢复为半同步复制。（腾讯云数据库MySQL半同步复制采用一主一从的架构）
7 异步，丢失可找回
数据可延迟同步，强调的是最终一致性，有较高的性能。
应用发起CRUD请求，master在执行完更新操作后立即向应用程序返回响应，然后master在向slave同步数据。
数据更新过程中master不需要等待slave的响应，因此异步复制的数据库实例通常具有较高的性能，且slave不可以用并不影响master对外提供服务。
但因数据并不是实时同步到slave，而master在slave有延迟的情况下发生故障则有较小的概率会引起数据不一致。
8 小结
通过主从复制确保数据备份，使用代理如Amoeba进行读写操作分配，以提高并发处理能力。如果需要考虑主从分库，并且细致地考虑同步的方式，可以参考这些内容。
