1 简介

韧性从多个维度诠释了软件持续提供业务服务的能力，核心目标是提升软件的平均无故障时间(Mean Time Between Failure,MTBF)。

从架构设计上，韧性包括服务异步化能力、重试/限流/降级/熔断/反压、主从模式、集群模式、AZ内的高可用、单元化、跨region容灾、异地多活容灾等。

这里介绍保障业务韧性的一个经典方法，主从模式。

当业务上线后，最不能接受的就是业务不可用，让用户无法正常使用软件，影响体验和收入。

当软件所依赖的软硬件组件出现各种异常时，软件就需要表现出抵御能力，这些异常通常包括硬件故障、硬件资源瓶颈(如CPU/网卡带宽耗尽)、业务流量超出软件设计能力、影响机房工作的故障和灾难、软件bug、黑客攻击等对业务不可用带来致命影响的因素。

这时候主从模式的读写分离就可以保障一定的业务韧性了，先介绍其三个数据同步方式，然后介绍主从同步mysql的binlog记录的三个方式，最后介绍图形解读binlog的在内部的同步过程，并做小结。

1 同步技术

1.1 全同步

• 定义

用户请求更新数据时，主数据库必须要同步到备用数据库才可用返回给用户，如果主数据库没有同步到备数据库，用户的更新操作一直阻塞

• 特点

保证了数据的强一致性，吸收了系统可用性

• 场景

适用于分布式数据库主备场景或对数据一致性有严格要求的场合，比如金融，交易场景

1.2 半同步

• 定义

数据更新时，主数据库执行写操作，并给备数据库发送同步请求，主数据库可用等等一部分从数据库响应，即返回给用户

• 方案

多个备用数据库其中一个返回，超过一半结点包括主数据库回复成功后，即可返回给用户。

• 场景

多数分布式系统都采用半同步，兼顾性能和数据保护

• 框架

    MySQL，Zookeeper，Ercd，Oracle等        
  

1.3 异步

• 定义

数据更新时，主数据库处理完请求后直接给用户响应，不必等备数据库完成同步，备数据库将异步执行数据同步，用户更新操作不会因为备数据库未完成而阻塞

• 特点

保证可用性，牺牲了一些数据一致性

• 场景

适用于用户请求响应时延要求高的场景

2 主从复制的方式

主从复制使用binlog模式进行数据备份的三种binlog模式：

① 基于SQL语句的复制，

每一条更新的语句（insert、update、delete）都会记录在binlog中，进而同步到从库的relaylog中，被从库的SQL线程取出来，回放执行。

优点是：binlog的日志量可能会比较少，比如一个涉及行数为1000行的update语句：同步这一个语句，就同步了1000行的数据。

缺点是：同步的SQL语句里如果含有绑定本地变量的函数、关键字时，可能造成主从不一致的情况。比如SQL语句中有time函数，如果主从数据库的服务器时间不是精确相等，就会造成结果不一致。

② 基于行的复制，

不记录SQL语句，只记录了哪个记录更新前和更新后的数据，可以保证主从之间数据绝对相同。缺点是：1条SQL更新1000行的数据无法再偷懒，必须原原本本同步1000行的数据量。

③ 混合复制：

以上两种模式的混合，选取两者的优点。对于有绑定本地特性、评估可能造成主从不一致的SQL语句，则自动选用基于行的复制，其他的情况则选择基于SQL语句的复制。

3 主从复制的binlog数据同步过程

主从复制过程：从库发起同步请求，数据传导过程如下：

Master->存储引擎->binlog->dump线程(读取binlog) ->从库I/O线程(将接到的日志信息存放到relaylog)->relaylog(读取relay的日志信息)->SQL线程(将数据库事件在存储引擎执行)->存储引擎

从库请求主库同步过程如下：

1  从库连接主库请求同步
2 Dump线程读取binlog
3 发送binlog中的日志
4 将binlog日志存储到relay log
5 SQL线程读取relay log
6 在存储引擎执行数据更新事件

使用图形表示如下：

上图详细描述了Mysql的主从数据同步步骤。在主从(Master-Slave)模式，主组件接收客户端的服务请求，它将工作划分给从组件，然后合并、解释、总结或整理从组件的响应。

当主组件没有对从组件分配工作时，从组件处于空闲(Idle)状态，并会在新的任务分配时被重新激活，
主从模式由主操作重配置状态图描述，其中包含两个正交的图，即主操作状态图和主从配置状态图，主操作状态图定义了主组件的操作状态，主从配置状态图描述了主组件如何安排重配置的过程。

4 小结

目前大部分的主流数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新同步到另一台服务器上。网站利用数据库的这一功能，实现数据库读写分离，从而改善数据库负载
压力。

现在对数据库的直接操作一般是因为一部分对缓存的读操作比如缓存访问未命中，缓存过期和全部写操作都需要访问数据库，应用服务器再写数据库。应用写数据时，访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库，这样当应用服务器读数据的时候，就可以通过从数据库获得数据。

为了便于应用程序访问读写分离后的数据库，通常在应用服务器端使用专门的数据访问模块，使数据库读写分离对应用透明。主从模式通常为经典的业务韧性保障机制。