读写分离&分库分表

一、读写分离

1. 何为读写分离
   读写分离主要是为了将对数据库的读写操作分散到不同的数据库节点上。

2. 读写分离会带来什么问题？如何解决？
   主库和从库的数据存在延迟，比如你写完主库之后，主库的数据同步到从库是需要时间的，这个时间差就导致了主库和从库的数据不一致性问题。这也就是我们经常说的 主从同步延迟 。

   解决办法：

   1.强制将读请求路由到主库处理。
   比如 Sharding-JDBC 就是采用的这种方案。通过使用 Sharding-JDBC 的 HintManager 分片键值管理器，我们可以强制使用主库。

   HintManager hintManager = HintManager.getInstance();
   hintManager.setMasterRouteOnly();
   // 继续JDBC操作
   

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

   2.延迟读取。

3. 如何实现读写分离？

   部署多台数据库，选择一种的一台作为主数据库，其他的一台或者多台作为从数据库。

   保证主数据库和从数据库之间的数据是实时同步的，这个过程也就是我们常说的主从复制。

   系统将写请求交给主数据库处理，读请求交给从数据库处理。

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

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

   2.组件方式

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

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

4. 主从复制原理了解么？

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

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

   Redis 也是通过主从复制实现的读写分离。

   MySQL 主从复制是依赖于 binlog 。另外，常见的一些同步 MySQL 数据到其他数据源的工具（比如 canal）的底层一般也是依赖 binlog 。

二、分库分表

何为分库？
分库 就是将数据库中的数据分散到不同的数据库上。

下面这些操作都涉及到了分库：

你将数据库中的用户表和用户订单表分别放在两个不同的数据库。
由于用户表数据量太大，你对用户表进行了水平切分，然后将切分后的 2 张用户表分别放在两个不同的数据库。
何为分表？
分表 就是对单表的数据进行拆分，可以是垂直拆分，也可以是水平拆分。

何为垂直拆分？

简单来说，垂直拆分是对数据表列的拆分，把一张列比较多的表拆分为多张表。

举个例子：我们可以将用户信息表中的一些列单独抽出来作为一个表。

何为水平拆分？

简单来说，水平拆分是对数据表行的拆分，把一张行比较多的表拆分为多张表。

举个例子：我们可以将用户信息表拆分成多个用户信息表，这样就可以避免单一表数据量过大对性能造成影响。

什么情况下需要分库分表？

遇到下面几种场景可以考虑分库分表：

单表的数据达到千万级别以上，数据库读写速度比较缓慢（分表）。
数据库中的数据占用的空间越来越大，备份时间越来越长（分库）。
应用的并发量太大（分库）。

分库分表会带来什么问题呢？

join 操作 ： 同一个数据库中的表分布在了不同的数据库中，导致无法使用 join 操作。这样就导致我们需要手动进行数据的封装，比如你在一个数据库中查询到一个数据之后，再根据这个数据去另外一个数据库中找对应的数据。

事务问题 ：同一个数据库中的表分布在了不同的数据库中，如果单个操作涉及到多个数据库，那么数据库自带的事务就无法满足我们的要求了。

分布式 id ：分库之后， 数据遍布在不同服务器上的数据库，数据库的自增主键已经没办法满足生成的主键唯一了。我们如何为不同的数据节点生成全局唯一主键呢？这个时候，我们就需要为我们的系统引入分布式 id 了。

分库分表有没有什么比较推荐的方案？

ShardingSphere 项目（包括 Sharding-JDBC、Sharding-Proxy 和 Sharding-Sidecar）是当当捐入 Apache 的，目前主要由京东数科的一些巨佬维护。

ShardingSphere 绝对可以说是当前分库分表的首选！ShardingSphere 的功能完善，除了支持读写分离和分库分表，还提供分布式事务、数据库治理等功能。

另外，ShardingSphere 的生态体系完善，社区活跃，文档完善，更新和发布比较频繁。

分库分表后，数据怎么迁移呢？

分库分表之后，我们如何将老库（单库单表）的数据迁移到新库（分库分表后的数据库系统）呢？

比较简单同时也是非常常用的方案就是停机迁移，写个脚本老库的数据写到新库中。比如你在凌晨 2 点，系统使用的人数非常少的时候，挂一个公告说系统要维护升级预计 1 小时。然后，你写一个脚本将老库的数据都同步到新库中。

如果你不想停机迁移数据的话，也可以考虑双写方案。双写方案是针对那种不能停机迁移的场景，实现起来要稍微麻烦一些。具体原理是这样的：

我们对老库的更新操作（增删改），同时也要写入新库（双写）。如果操作的数据不存在于新库的话，需要插入到新库中。 这样就能保证，咱们新库里的数据是最新的。

在迁移过程，双写只会让被更新操作过的老库中的数据同步到新库，我们还需要自己写脚本将老库中的数据和新库的数据做比对。如果新库中没有，那咱们就把数据插入到新库。如果新库有，旧库没有，就把新库对应的数据删除（冗余数据清理）。

重复上一步的操作，直到老库和新库的数据一致为止。

想要在项目中实施双写还是比较麻烦的，很容易会出现问题。我们可以借助上面提到的数据库同步工具 Canal 做增量数据迁移（还是依赖 binlog，开发和维护成本较低）。