主从架构-读写分离
什么是主从架构
一台数据库作为主库,负责写.
N台数据库作为从库,负责读.
因为互联网大部分业务场景都是读多写少的,比如电商服务,读和写的请求对比会差几个数量级,这时为了不让数据库的读成为业务瓶颈,同时保证写库的成功率,这时候可以把访问的压力从主库转移到从库,特别是单机数据库无法支撑并发读写,并且业务请求大部分为读操作的情况下.
主从复制核心原理
核心依赖于binlog,它记录了MySQL的所有变化并且用二进制形式保存在磁盘上.
复制的过程就是将binlog中的数据从主库传输到从库上,这个过程是异步的,主库执行事务操作的线程不会等待复制binlog的线程同步完成.
主要分为3个阶段:
- 写入binlog: 主库写binlog日志,提交事务,并更新本地存储数据
- 同步binlog: 把binlog复制到所有从库上,每个从库把binlog写到暂存日志中
- 回访binlog: 回访binlog,并更新存储数据
详细来说:
- MySQL主库收到客户端提交事务请求后,会先写入binlog,再提交事务,更新存储引擎中的数据
- 从库创建一个IO线程,连接主库的logdump线程,来接受主库的binlog日志,再把binlog信息写入relaylog的中继日志中,返回给主库复制成功的响应
- 从库创建一个用户回访binlog的SQL线程,去读relaylog中继日志,然后回访binlog更新存储引擎中的数据,最终实现主从的数据一致性
完成主从复制后,可以在写数据时只写主库,读数据时只读从库,这样就算写请求会锁表或者锁记录,也不会影响读操作.
主从复制有哪些模型
- 同步模型: 事务线程等待所有从库的复制成功响应
- 异步模型: 事务线程完全不等待从库的复制成功响应
- 半同步复制: MySQL5.7之后增加的复制方式,事务线程不用等待 所有从库复制成功响应,只需要一部分复制成功响应回来就行
主从复制延迟怎么解决
因为主从是两个不同的数据源,复制过程会有一个延时存在,特别是高并发的场景,刚写入主库的数据是不能马上在从库中获取的,要等待几十毫秒或上百毫秒后才可以.
某些一致性要求高的业务场景,这种主从导致的延迟会引起一些业务问题,比如订单支付,付款完成,主库更新了数据,但从库读数据时出现订单未支付,在业务中无法接受.
敏感业务强制读主库
有部分业务需要写库后实时读数据,这一类操作可以通过强制读主库来解决.
但是这种方案使用的时候要谨慎一点,提前明确查询数据量是不大的,否则主库压力会比较大
实现方案一般是两种:
- 提前把数据源配置在项目中,每个数据源对应一个主库或从库,然后在代码逻辑中进行判断,将SQL语句发送到某一个制定的数据源来处理.
- 优点: 简单比较容易实现
- 缺点: 复杂工程中代码维护难度有点高,侵入太强了
- 独立部署代理中间件,比如MyCat或ShardingSphere-JDBC,可以代理多个数据库
- 优点: 隔离底层数据库与上次应用的访问复杂度
- 缺点: 所有SQL语句都要跨两次网络传输,有一定性能损耗,运维也有一定难度
关键业务不进行读写分离
对一致性高的业务不进行读写分离,避免延迟导致的问题
使用数据冗余
在调用查询接口时,不仅仅发送查询参数,而是发送所需要的所有数据,避免在从库中重新查询.
但是注意参数大小,过大的消息会占用网络贷款和通信时间.
使用缓存解决
可以在写入数据主库的同时,将数据写到Redis缓存里,这样其他线程来获取数据时,会优先查询缓存,也可以保证数据的一致性.
但这种方式会带来缓存和数据库一致性的问题,和使用数据冗余相比的方案各有利弊