数据主从同步的由来
互联网的很多业务,特别是在高并发的场景下,基本都是读远远大于写,如果数据库读和写的压力都同在一台主机上,这显然不太合理。
于是,把一台数据库主机分为单独的一台写主库(主要负责写操作),而把读的数据库压力分配给读的从库,而且读从库可以变为多台,这就是读写分离的典型场景如下:
为了进一步的降低数据库端的压力(高并发的瓶颈),这个时候也会在业务层部署分布式缓存集群(redis、memcached)等,把读的压力转移给应用服务器端,其实与数据主从的设计是遵循同一个原则,降低后端数据库的压力。
问题:
读写分离提高了资源的利用效率的同时也引出了一个问题,就是由于延时(网络传输,操作)而引起的数据库主从不一致的问题,以下会详细谈相关的数据一致性解决方案。
数据同步一致性解决方案
1.半同步复制
办法就是等主从同步完成之后,等主库上的写请求再返回,这就是常说的“半同步复制”。
实现方案
mysql的半同步复制方案,下面我以mysql为例介绍。
MySQL半同步复制
MySQL的Replication默认是一个异步复制的过程,从MySQL5.5开始,MySQL以插件的形式支持半同步复制,我先谈下异步复制,这样可以更好的理解半同步复制。
1)异步复制
MySQL默认的复制是异步的,主库在执行完客户端提交的事务后会立即将结果返给给客户端,并不关心从库是否已经接收并处理,这样就会有一个问题,主如果crash掉了,此时主上已经提交的事务可能并没有传到从库上。
2)半同步复制
介于异步复制和全同步复制之间,主库在执行完客户端提交的事务后不是立刻返回给客户端,而是等待至少一个从库接收到并写到relay
log中才返回给客户端。相对于异步复制,半同步复制提高了数据的安全性,同时它也造成了一定程度的延迟,这个延迟最少是一个TCP/IP往返的时间。所以,半同步复制最好在低延时的网络中使用。
半同步复制原理:
事务在主库写完binlog后需要从库返回一个已接受,才放回给客户端
mysql5.5版本以后,以插件的形式存在,需要单独安装
确保事务提交后binlog至少传输到一个从库
不保证从库应用完成这个事务的binlog
性能有一定的降低
网络异常或从库宕机,卡主库,直到超时或从库恢复
该方案优点:
利用数据库原生功能,比较简单
该方案缺点:
主库的写请求时延会增长,吞吐量会降低
2.数据库中间件
流程:
1)所有的读写都走数据库中间件,通常情况下,写请求路由到主库,读请求路由到从库
2)记录所有路由到写库的key,在主从同步时间窗口内(假设是500ms),如果有读请求访问中间件,此时有可能从库还是旧数据,就把这个key上的读请求路由到主库。
3)在主从同步时间过完后,对应key的读请求继续路由到从库。
相关的中间件有:
1)canal:是阿里巴巴旗下的一款开源项目,纯Java开发,基于数据库增量日志解析,提供增量数据订阅&消费,目前主要支持了MySQL。
2)otter:也是阿里开源的一个分布式数据库同步系统,尤其是在跨机房数据库同步方面,有很强大的功能。它是基于数据库增量日志解析,实时将数据同步到本机房或跨机房的mysql/oracle数据库。
两者的区别在于:
otter目前嵌入式依赖canal,部署为同一个jvm,目前设计为不产生Relay Log。
otter目前允许自定义同步逻辑,解决各类需求。
该方案优点
能保证绝对一致
该方案缺点:
数据库中间件的成本较高
缓存记录写key法
写流程:
1)如果key要发生写操作,记录在cache里,并设置“经验主从同步时间”的cache超时时间,例如500ms
2)然后修改主数据库
读流程:
1)先到缓存里查看,对应key有没有相关数据
2)有相关数据,说明缓存命中,这个key刚发生过写操作,此时需要将请求路由到主库读最新的数据。
3)如果缓存没有命中,说明这个key上近期没有发生过写操作,此时将请求路由到从库,继续读写分离。
该方案优点:
相对数据库中间件,成本较低
该方案缺点:
为了保证“一致性”,引入了一个cache组件,并且读写数据库时都多了缓存操作。
以上就是数据库主从同步一致性方案详解,更加详细深入的视频讲解,请点击查看MySQL数据库专题合集
———————