问题描述：

MySQL默认的复制是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从库上。

解决方案：

• 方案一：半同步复制

简单的说就是主库发生增删改操作的时候,会等从库同步复制完成后通知了主库, 主库返回状态给用户，才会把这个操作叫做成功.

优点：操作比较简单，保障数据一致性
缺点：主库的写请求时延会增长，吞吐量会降低

• 方案二：中间件

如果有数据库中间件，所有的数据库请求都走中间件，然后写的请求路由到主库，读的请求路由到从库，同时中间件会记录写库的一个key,在设置一个允许同步时间,假设是1s，当有一个写请求过来时候，生成一个key A ，路由马上写到主库，然后立马有一个读请求过来。 从库可能是旧数据，或者没有来得及同步。 如果时间是在1s内的，就对应的key继续路由到主库。如果在1s以后的，就路由到从库。简单说就是中间件给个同步时间，给你同步，在同步时间内，所有的请求都落在主库

优点：能保证绝对一致
缺点：数据库中间件的成本比较高

• 方案三：缓存记录写key法

1）、增删改

将某个库上的某个key要发生写操作，记录在cache里，并设置“经验主从同步时间”的cache超时时间，例如1s，然后修改数据库

2）、读

（1）先到缓存里查看，对应key有没有相关数据

（2）有相关数据，说明缓存命中，这个key刚发生过写操作，此时需要将请求路由到主库读最新的数据。

（3）如果缓存没有命中，说明这个key上近期没有发生过写操作，此时将请求路由到从库，继续读写分离。

优点：相对数据库中间件，成本较低
缺点：为了保证“一致性”，引入了一个cache组件，并且读写数据库时都多了一步cache操作