读写分离&分库分表

1.读写分离主要是为了将数据库的读和写操作分不到不同的数据库节点上。主服务器负责写，从服务器负责读。

读写分离可以大幅提高读性能，小幅提高写的性能。因此，读写分离更适合单机并发读请求比较多的场景。

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

**读写分离会带来什么问题？**如何解决？

你写完主库之后，主库的数据同步到从库是需要时间的，这个时间差就导致了主库和从库的数据不一致性问题。这也就是我们经常说的 主从同步延迟 。

1. 强制将读请求路由到主库处理。（通过使用 Sharding-JDBC 工具）
2. 延迟读取。（既然主从同步存在延迟，那我就在延迟之后读取啊，比如主从同步延迟 0.5s,那我就 1s 之后再读取数据。）

如何实现读写分离？

1. 部署多台数据库，选择一种的一台作为主数据库，其他的一台或者多台作为从数据库。
2. 证主数据库和从数据库之间的数据是实时同步的，这个过程也就是我们常说的主从复制。
3. 系统将写请求交给主数据库处理，读请求交给从数据库处理。
4. 
   可以在应用和数据中间加了一个代理层。应用程序所有的数据请求都交给代理层处理，代理层负责分离读写请求，将它们路由到对应的数据库中。

主从复制原理了解么？

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

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

2.分库分表是为了解决由于库、表数据量过大，而导致数据库性能持续下降的问题。

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

1. 你将数据库中的用户表和用户订单表分别放在两个不同的数据库。
2. 由于用户表数据量太大，你对用户表进行了水平切分，然后将切分后的 2 张用户表分别放在两个不同的数据库。

分表 就是对单表的数据进行拆分，可以是垂直拆分，也可以是水平拆分。

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

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

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

1. join 操作 ： 同一个数据库中的表分布在了不同的数据库中，导致无法使用 join 操作。
2. 事务问题 ：同一个数据库中的表分布在了不同的数据库中，如果单个操作涉及到多个数据库，那么数据库自带的事务就无法满足我们的要求了。
3. 分布式 id ：分库之后， 数据遍布在不同服务器上的数据库，数据库的自增主键已经没办法满足生成的主键唯一了。我们如何为不同的数据节点生成全局唯一主键呢？这个时候，我们就需要为我们的系统引入分布式 id 了。

常见的分库分表工具有：sharding-jdbc（当当）、TSharding（蘑菇街）、MyCAT（基于 Cobar）、Cobar（阿里巴巴）...。 推荐使用 sharding-jdbc。 因为，sharding-jdbc 是一款轻量级 Java 框架，以 jar 包形式提供服务，不要我们做额外的运维工作，并且兼容性也很好。