1 简介

在遇到大并发的请求场景时。采用主从同步+读写分离，去实现数据的读写加速是主流的操作，那么分析一下业务，适合哪个同步模式（全同步，半同步，异步）就非常必要了，比如有如下问题：

遇到单点故障，服务不可用
无法处理大量的并发数据请求，数据丢失将会造成很大损失

如何解决？

2 方案

增加MySQL数据库服务器，对数据进行备份，形成主备，确保主备MySQL数据库服务器数据是一样的。

主服务器宕机了，备份服务器继续工作，数据有保障，MySQL主从复制与读写分离是密切相关的。

通过主从复制的方式来同步数据，再通过读写分离来提升数据库的并发负载能力。

使用代理同步：

一个以MySQL为底层数据存储，并对应用提供MySQL协议接口的proxy，外号变形虫(Amoeba)
读取请求发送给从服务器时，采用轮询调度算法.主服务器挂掉，采用MHA解决。

这将涉及到的账号权限：

	主从同步账号
	节点服务器开放调度账号
	Amoeba代理账号

注意点：

1 主服务器需要开一个主从复制权限账户， 第一个账户

2 代理服务把写的操作给master，读的操作给slave，轮询从数据库服务

3 读写分离账户，第二个账户

4 client 照amoeba进行访问，访问amoeba账号

2.1 主从复制类型

基于语句的复制（默认）

    在主服务器上执行的语句，从服务器执行同样的语句

基于行的复制

把改变的内容复制到从服务器

混合类型的复制

一旦发现基于语句无法精确复制时，就会采用基于行的复制

2.2 主从同步过程：

先找位置，匹配到位置后I/o线程去找二进制日志，进行读取更新，再写入中继日志，从服务器读取中继日志，从而进行相对应操作.

• 操作步骤：

    1 关闭防火墙
    2 建立时间同步环境
    3 编译安装mysql
    4 配置mysql 主服务器
    5 配置两个从服务器
    6 测试
  

• 读写分离

在表Myisam或行innodb被锁定时，
只能读不能写，或者只能写不能读都需要读写分离。

读写分离就是主服务写，从服务读
数据库复制被用来把事务性查询变更同步到集群的从数据库。

主从同步+读写分离 全同步，半同步，异步 

2.3 强同步

数据实时性要求高，不能丢失使用全同步，服务器的要求比较高，全部slave返回。

master在执行完更新操作后立即向slave复制数据，slave接受到数据并执行完后才向master返回成功的信息，master必须接收到slave的成功信息后再向应用程序响应。

因master向slave复制数据是同步进行的，master每次更新操作都需要保证slave也成功执行，因此强同步复制能最大限度保障主从数据的一直性。

但因每次master更新操作都强依赖于slave的返回，因此slave如果仅此一台，它不可用将极大影响master上的正常操作。

某些(腾讯)云数据库MySQL强同步复制采用一主两从的架构，仅需其中一台slave成功执行即可返回，避免了单台slave不可以用影响master上操作的问题，提高了强同步复制集群的可用性。

2.4 半同步

数据可有一定延时，不能丢失，只需某一个slave返回即可。

应用发起数据更新（含insert、update、delete操作）请求，master在执行完更新操作后立即向slave复制数据，slave接收到数据并写到relaylog中（不需要执行）后才向master返回成功的信息。

master必须在接收到slave的成功信息后再向应用程序返回响应。

仅在数据复制发生异常（slave节点不可以用或者数据复制所用的网络发生异常）的情况下，master会暂停（MySQL默认10s左右）对应用的响应，将复制方式降为异步复制。

当数据复制恢复正常，将恢复为半同步复制。（腾讯云数据库MySQL半同步复制采用一主一从的架构）

2.5 异步，数据可延迟同步，丢失可找回，有较高的性能。

应用发起CRUD请求，master在执行完更新操作后立即向应用程序返回响应，然后master在向slave同步数据。

数据更新过程中master不需要等待slave的响应，因此异步复制的数据库实例通常具有较高的性能，且slave不可以用并不影响master对外提供服务。

但因数据并不是实时同步到slave，而master在slave有延迟的情况下发生故障则有较小的概率会引起数据不一致。

3 小结

如果需要考虑主从分库，并且细致地考虑同步的方式，可以参考这些内容。