|
前言
数据库分库分表除了使用中间件来代理请求分发之外，另外一种常见的方法就是在客户端层面来分库分表 —— 通过适当地包装客户端代码使得分库分表的数据库访问操作代码编写起来也很方便。本文的分库分表方案基于 MyBatis 框架，但是又不同于市面上常用的方案，它们一般都是通过编写复杂的 MyBatis 插件来重写 SQL 语句，这样的插件代码会巨复杂无比，可能最终只有插件的原作者自己可以完全吃透相关代码，给项目的维护性带来一定问题。本文的方案非常简单易懂，而且也不失使用上的便捷性。它的设计哲学来源于 Python —— Explicit is better than Implicit，也就是显式优于隐式，它不会将分库分表的过程隐藏起来。
很多分库分表的设计在实现上会尽量将分库分表的逻辑隐藏起来，其实这是毫无必要的。使用者必须知道背后确实进行了分库分表，否则他怎么会无法进行全局的索引查找？他怎么会无法随意进行多表的 join 操作。如果你真的将它当成单表来用，到上线时必然会出大问题。
项目名称叫：shardino，项目地址：https://github.com/pyloque/shardino
接下来我们来看看在本文的方案之下，数据库操作代码的形式是怎样的帖子表一共分出来 64 个表，不同的记录会各自分发到其中一个表，可以是按 hash 分发，也可以按照日期分发，分发逻辑由用户代码自己来决定。在不同的环境中可以将分表数量设置为不同的值，比如在单元测试下分表设为 4 个，而线上可能需要设置为 64 个。
帖子表又会被分配到多个库，这里就直接取模分配。假设有 4 个帖子库，帖子表总共分出来 64 个表，分别是 post_0、post_1、post_2 一直到 post_63。那么 post_0、post_4、post_8 等分配到 0 号库，post_1、post_5、post_9 等分配到 1 号库，post_2、post_6、post_10 等分配到 2 号库，post_3、post_5、post_11 等分配到 4 号库。
从配置文件中构建 MySQLGroupStore 数据库组对象，这个对象是我们执行 MySQL 操作的入口，通过它可以找到具体的物理的 MySQL 主从数据源。
配置文件 application.properties 如下
这里的数据库组是由多个对等的 Master-Slaves 对构成，每个 Master-Slaves 是由一个主库和多个不同权重的从库构成，Master-Slaves 对的数量就是分库的数量。
mysqlgroup 还有一个特殊的配置选项 slaveEnabled 来控制是否需要从库，从而关闭读写分离，默认是关闭的，这样就不会去构建从库实例相关对象。
post_k 这张表后缀 k 我们称之为 partition number，也就是后续代码中到处在用的 partition 变量，表明当前的记录被分配到对应物理数据表的序号。我们需要根据记录的内容计算出 partition number，再根据 partition number 决定出这条记录所在的物理表属于那个物理数据库，然后对这个物理数据库进行相应的读写操作。
在本例中，帖子表按照 userId 字段 hash 出 64 张表，平均分配到 2 对物理库中，每个物理库包含一个主库和2个从库。
有了 MySQLGroupStore 实例，我们就可以尽情操纵所有数据库了。 | 
转播
