一文读懂分库分表架构的 21 条法则

本文介绍了关于分库分表架构的21个通用概念，有一定的了解之后，接下来我们将进入更深度的内容，包括读写分离、数据脱敏、分布式主键、分布式事务、配置中心、注册中心、Proxy服务等实战案例的讲解和源码分析。

（一）好好的系统，为什么要分库分表？

咱们先介绍下在分库分表架构实施过程中，会接触到的一些通用概念，了解这些概念能够帮助理解市面上其他的分库分表工具，尽管它们的实现方法可能存在差异，但整体思路基本一致。因此，在开始实际操作之前，我们有必要先掌握这些通用概念，以便更好地理解和应用分库分表技术。

我们结合具体业务场景，以t_order表为例进行架构优化。由于数据量已经达到亿级别，查询性能严重下降，因此我们采用了分库分表技术来处理这个问题。具体而言，我们将原本的单库分成了两个库，分别为DB_1和DB_2，并在每个库中再次进行分表处理，生成t_order_1和t_order_2两张表，实现对订单表的分库分表处理。

数据分片

通常我们在提到分库分表的时候，大多是以水平切分模式（水平分库、分表）为基础来说的，数据分片它将原本一张数据量较大的表 t_order 拆分生成数个表结构完全一致的小数据量表（拆分表） t_order_0、t_order_1、···、t_order_n，每张表只存储原大表中的一部分数据。

数据节点

数据节点是数据分片中一个不可再分的最小单元（表），它由数据源名称和数据表组成，例如上图中 DB_1.t_order_1、DB_2.t_order_2 就表示一个数据节点。

逻辑表

逻辑表是指具有相同结构的水平拆分表的逻辑名称。

比如我们将订单表t_order 分表拆分成 t_order_0 ··· t_order_9等10张表，这时我们的数据库中已经不存在 t_order这张表，取而代之的是若干的t_order_n表。

分库分表通常对业务代码都是无侵入式的，开发者只专注于业务逻辑SQL编码，我们在代码中SQL依然按 t_order来写，而在执行逻辑SQL前将其解析成对应的数据库真实执行的SQL。此时 t_order 就是这些拆分表的逻辑表。

业务逻辑SQL

复制

select * from t_order where order_no='A11111'

• 1.

真实执行SQL

复制

select * from DB_1.t_order_n where order_no='A11111'

• 1.

真实表

真实表就是在数据库中真实存在的物理表DB_1.t_order_n。

广播表

广播表是一类特殊的表，其表结构和数据在所有分片数据源中均完全一致。与拆分表相比，广播表的数据量较小、更新频率较低，通常用于字典表或配置表等场景。由于其在所有节点上都有副本，因此可以大大降低JOIN关联查询的网络开销，提高查询效率。

需要注意的是，对于广播表的修改操作需要保证同步性，以确保所有节点上的数据保持一致。

广播表的特点：

• 在所有分片数据源中，广播表的数据完全一致。因此，对广播表的操作（如插入、更新和删除）会实时在每个分片数据源中执行一遍，以保证数据的一致性。
• 对于广播表的查询操作，仅需要在任意一个分片数据源中执行一次即可。
• 与任何其他表进行JOIN操作都是可行的，因为由于广播表的数据在所有节点上均一致，所以可以访问到任何一个节点上的相同数据。

什么样的表可以作为广播表呢？

订单管理系统中，往往需要查询统计某个城市地区的订单数据，这就会涉及到省份地区表t_city与订单流水表DB_n.t_order_n进行JOIN查询，因此可以考虑将省份地区表设计为广播表，核心理念就是避免跨库JOIN操作。