一、读写分离如何在业务中落地

什么时候需要读写分离

互联网大部分业务场景都是读多写少的
为了不让数据库的读成为业务瓶颈，同时也为了保证写库的成功率，一般会采用读写分离的技术来保证
读写分离就是分离读库和写库操作

从 CRUD 的角度，主数据库处理新增、修改、删除等事务性操作，而从数据库处理 SELECT 查询操作

具体实现:

• 一主一从，一个主库配置一个从库
• 一主多从，也就是一个主库，但是配置多个从库

读写分离的实现是把访问的压力从主库转移到从库

特别在单机数据库无法支撑并发读写，并且业务请求大部分为读操作的情况下

如果业务特点是写多读少，比如一些需要动态更新的业务场景，应用读写分离就不合适了

由于 MySQL InnoDB 等关系型数据库对事务的支持，一般会选择更高性能的 NoSQL 等存储来实现

MySQL 主从复制技术–binlog日志

MySQLInnoDB引擎的主从复制，是通过二进制日志binlog来实现
除了数据查询语句 select 以外，binlog 日志记录了其他各类数据写入操作，包括DDL和 DML语句

binlog有三种格式：Statement、Row及Mixed

• Statement 格式，基于 SQL语句的复制
  binlog 会记录每一条修改数据的 SQL操作，从库拿到后在本地进行回放就可以
• Row 格式，基于行信息复制
  Row 格式以行为维度，记录每一行数据修改的细节，仅记录行数据的修改
  假设有一个批量更新操作，会以行记录的形式来保存二进制文件，这样可能会产生大量的日志内容
• Mixed 格式，混合模式复制
  Mixed 格式，是 Statement与 Row 的结合，在这种方式下，不同的SOL操作会区别对待
  比如一般的数据操作使用 row 格式保存，有些表结构的变更语句，使用statement来记录

主从复制过程

存在主从复制延时问题

分布式系统通过主从复制实现读写分离解决了读和写操作的性能瓶颈问题
但同时也增加了整体的复杂性
主从复制过程会存在一个延时，当主库有数据写入之后，同时写入binlog日志文件中
然后从库通过 binlog文件同步数据，由于需要额外执行日志同步和写入操作，这期间会有一定时间的延迟
在某些对一致性要求较高的业务场景中，这种主从导致的延迟会引起一些业务问题
比如订单支付，付款已经完成，主库数据更新了，从库还没有
这时候去从库读数据，会出现订单未支付的情况

<