Readwrite Splitting

什么是读写分离？

读写分离主要是为了将对数据库的读写操作分散到不同的数据库节点上。 这样的话，就能够小幅提升写性能，大幅提升读性能。

一般情况下，会选择一主多从，也就是一台主数据库负责写，其他的从数据库负责读。主库和从库之间会进行数据同步，以保证从库中数据的准确性。这样的架构实现起来比较简单，并且也符合系统的写少读多的特点。

主从同步延迟

读写分离对于提升数据库的并发非常有效，但是，同时也会引来一个问题：主库和从库的数据存在延迟，比如写完主库之后，主库的数据同步到从库是需要时间的，这个时间差就导致了主库和从库的数据不一致性问题。这也就是我们经常说的 主从同步延迟 。

解决办法

  1. 强制将读请求路由到主库处理。

    既然你从库的数据过期了，那就直接从主库读取. 这种方案虽然会增加主库的压力，但是，实现起来比较简单，也是我了解到的使用最多的一种方式。

    比如 Sharding-JDBC 就是采用的这种方案。通过使用 Sharding-JDBC 的 HintManager 分片键值管理器，我们可以强制使用主库。

    对于这种方案，你可以将那些必须获取最新数据的读请求都交给主库处理。

  2. 延迟读取。

    还有一些朋友肯定会想既然主从同步存在延迟，那我就在延迟之后读取啊，比如主从同步延迟 0.5s,那我就 1s 之后再读取数据。

    不过，如果你是这样设计业务流程就会好很多：对于一些对数据比较敏感的场景，你可以在完成写请求之后，避免立即进行请求操作。比如你支付成功之后，跳转到一个支付成功的页面，当你点击返回之后才返回自己的账户。

读写分离的实现

论是使用哪一种读写分离具体的实现方案，想要实现读写分离一般包含如下几步：

  1. 部署多台数据库，选择其中的一台作为主数据库，其他的一台或者多台作为从数据库。
  2. 保证主数据库和从数据库之间的数据是实时同步的，这个过程也就是我们常说的主从复制。
  3. 系统将写请求交给主数据库处理，读请求交给从数据库处理。

落实到项目本身的话，常用的方式有两种：

  1. 代理方式

    可以在应用和数据中间加了一个代理层。应用程序所有的数据请求都交给代理层处理，代理层负责分离读写请求，将它们路由到对应的数据库中。

    提供类似功能的中间件有 MySQL Router（官方）、Atlas（基于 MySQL Proxy）、MaxScale、MyCat。

  2. 组件方式

    在这种方式中，我们可以通过引入第三方组件来帮助我们读写请求。

    这也是我比较推荐的一种方式。这种方式目前在各种互联网公司中用的最多的，相关的实际的案例也非常多。如果你要采用这种方式的话，推荐使用 sharding-jdbc ，直接引入 jar 包即可使用，非常方便。同时，也节省了很多运维的成本。

Benefits

  • 统一端点，方便维护

    如果您未开启读写分离功能，则只有在将主RDS实例和只读RDS实例的终端节点添加到应用程序中后，才能进行读写分离。开启读写分离功能后，您可以使用专属代理终端节点进行读写分离。您只需将专用代理终端节点添加到应用程序。将应用程序连接到专用代理终端节点后，数据库系统会根据主实例的读取权重将读写请求路由到主 RDS 实例和只读 RDS 实例。这降低了维护成本。还可以创建只读 RDS 实例以提高数据库系统的读取能力，而无需修改应用程序上的配置数据。

  • 本机链接可提高性能并降低维护成本

    可以在云端构建自己的代理层，实现读写分离。在这种情况下，数据需要由多个组件解析和转发，然后才能到达数据库系统。因此，响应延迟会增加。RDS生态中嵌入了读写分离功能，可降低响应延迟，提高处理速度，降低维护成本。

  • 可配置的读取权重和阈值，以确保适用于各种场景

    可以指定主RDS实例和只读RDS实例的读取权重。您还可以指定数据复制到只读 RDS 实例的延迟阈值。

  • 实例级健康检查，确保高可用性

    读写分离功能使RDS能够主动检查RDS主实例和只读RDS实例的健康状态。当只读RDS实例意外退出或数据复制延迟超过指定阈值时，RDS将停止向该实例路由读请求。RDS会将发往故障只读RDS实例的读取请求重定向到数据库系统中其他运行状况良好的RDS实例。即使单个只读 RDS 实例发生故障，也能确保服务可用性。恢复故障只读实例后，RDS恢复对该实例的路由读请求。

主从复制原理

MySQL binlog(binary log 即二进制日志文件) 主要记录了 MySQL 数据库中数据的所有变化(数据库执行的所有 DDL 和 DML 语句)。因此，我们根据主库的 MySQL binlog 日志就能够将主库的数据同步到从库中。

  • 主库将数据库中数据的变化写入到 binlog
  • 从库连接主库
  • 从库会创建一个 I/O 线程向主库请求更新的 binlog
  • 主库会创建一个 binlog dump 线程来发送 binlog ，从库中的 I/O 线程负责接收
  • 从库的 I/O 线程将接收的 binlog 写入到 relay log 中。
  • 从库的 SQL 线程读取 relay log 同步数据本地（也就是再执行一遍 SQL ）

详细过程

  • MySQL 主库在收到客户端提交事务的请求之后，会先写入 binlog，再提交事务，更新存储引擎中的数据，事务提交完成后，返回给客户端“操作成功”的响应。
  • 从库会创建一个专门的 I/O 线程，连接主库的 log dump 线程，来接收主库的 binlog 日志，再把 binlog 信息写入 relay log 的中继日志里，再返回给主库“复制成功”的响应。
  • 从库会创建一个用于回放 binlog 的线程，去读 relay log 中继日志，然后回放 binlog 更新存储引擎中的数据，最终实现主从的数据一致性。

在完成主从复制之后，你就可以在写数据时只写主库，在读数据时只读从库，这样即使写请求会锁表或者锁记录，也不会影响读请求的执行。

一般看到 binlog 就要想到主从复制。当然，除了主从复制之外，binlog 还能实现数据恢复。

拓展：

阿里开源 canal 的工具。这个工具可以实现 MySQL 和其他数据源比如 Elasticsearch 或者另外一台 MySQL 数据库之间的数据同步。很显然，这个工具的底层原理肯定也是依赖 binlog。canal 的原理就是模拟 MySQL 主从复制的过程，解析 binlog 将数据同步到其他的数据源。

另外，像常用的分布式缓存组件 Redis 也是通过主从复制实现的读写分离。

MySQL 主从复制还有哪些模型

  • 同步复制：事务线程要等待所有从库的复制成功响应。
  • 异步复制：事务线程完全不等待从库的复制成功响应。
  • 半同步复制：MySQL 5.7 版本之后增加的一种复制方式，介于两者之间，事务线程不用等待所有的从库复制成功响应，只要一部分复制成功响应回来就行，比如一主二从的集群，只要数据成功复制到任意一个从库上，主库的事务线程就可以返回给客户端。

这种半同步复制的方式，兼顾了异步复制和同步复制的优点，即使出现主库宕机，至少还有一个从库有最新的数据，不存在数据丢失的风险。

在系统设计上有哪些方案可以解决主从复制的延迟问题？

从架构上解决主从复制延迟

我们来结合实际案例设计一个主从复制延迟的解决方案。

在电商平台，每次用户发布商品评论时，都会先调用评论审核，目的是对用户发布的商品评论进行如言论监控、图片鉴黄等操作。

评论在更新完主库后，商品发布模块会异步调用审核模块，并把评论 ID 传递给审核模块，然后再由评论审核模块用评论 ID 查询从库中获取到完整的评论信息。此时如果主从数据库存在延迟，在从库中就会获取不到评论信息，整个流程就会出现异常。

主从延迟影响评论读取的实时性

这是主从复制延迟导致的查询异常，解决思路有很多，我提供给你几个方案。

  • 使用数据冗余

可以在异步调用审核模块时，不仅仅发送商品 ID，而是发送审核模块需要的所有评论信息，借此避免在从库中重新查询数据（这个方案简单易实现，推荐你选择）。但你要注意每次调用的参数大小，过大的消息会占用网络带宽和通信时间。

  • 使用缓存解决

可以在写入数据主库的同时，把评论数据写到 Redis 缓存里，这样其他线程再获取评论信息时会优先查询缓存，也可以保证数据的一致性。

不过这种方式会带来缓存和数据库的一致性问题，比如两个线程同时更新数据，操作步骤如下：

线程 A 先更新数据库为 100，此时线程 B 把数据库和缓存中的数据都更新成了 200，然后线程 A 又把缓存更新为 100，这样数据库中的值 200 和缓存中的值 100 就不一致了，解决这个问题，你可以参考 06 讲。

总的来说，通过缓存解决 MySQL 主从复制延迟时，会出现数据库与缓存数据不一致的情况。虽然它和“使用数据冗余”的方案相比并不优雅，但我还是建议你在面试中做一下补充，这样可以引出更多的技术知识，展现自己与其他人的差异。

  • 直接查询主库

该方案在使用时一定要谨慎，你要提前明确查询的数据量不大，不然会出现主库写请求锁行，影响读请求的执行，最终对主库造成比较大的压力。

当然了，面试官除了从架构上考察你对 MySQL 主从复制延迟的理解，还会问你一些扩展问题，比如：当 MySQL 做了主从分离后，对于数据库的使用方式就发生了变化，以前只需要使用一个数据库地址操作数据库，现在却要使用一个主库地址和多个从库地址，并且还要区分写入操作和查询操作，那从工程代码上设计，怎么实现主库和从库的数据访问呢？

实现主库和从库的数据库访问

一种简单的做法是：提前把所有数据源配置在工程中，每个数据源对应一个主库或者从库，然后改造代码，在代码逻辑中进行判断，将 SQL 语句发送给某一个指定的数据源来处理。

这个方案简单易实现，但 SQL 路由规则侵入代码逻辑，在复杂的工程中不利于代码的维护。

另一个做法是：独立部署的代理中间件，如 MyCat，这一类中间件部署在独立的服务器上，一般使用标准的 MySQL 通信协议，可以代理多个数据库。

该方案的优点是隔离底层数据库与上层应用的访问复杂度，比较适合有独立运维团队的公司选型；缺陷是所有的 SQL 语句都要跨两次网络传输，有一定的性能损耗，再就是运维中间件是一个专业且复杂的工作，需要一定的技术沉淀。

reference

读写分离主要应对的是数据库读并发，没有解决数据库存储问题。试想一下：如果 MySQL 一张表的数据量过大怎么办?

Database Sharding