持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第 22 天，点击查看活动详情
1 前言
在前文中已经分享了 sharding-jdbc 分库分表的策略和算法，在本文中将继续继续分库分表的实战操作，主要教书分库分表的配置已经读写分离，强制读主库的配置。
2 sharding-jdbc 配置
使用 sharding-jdbc, 需要先引入其依赖，这里采用的是最新的版本，数据库使用的是 mysql， orm 框架使用的是 mysbatis-plus, 关于多数据源的依赖使用 dynamic-datasource。
关于数据源的配置，如下图所示，这里采用了主从的模式，两个主库和两个从库。默认的数据库为主库 db0。在配置中体现了分库分表和主从分离的配置，db0 和 db1 为两个主数据库，slave0 和 slave1 为两个从数据库。
以下配置的是数据库的主从配置策略以及数据库表的主键生成测了，另外还有就是打开数据库 sql 的展示，有了这一项配置可以展示数据库的逻辑 sql 和真实 sql 的执行情况，在开发阶段是非常有必要的。
此外在图中展示的有具体的分库分表算法的配置，这里使用的是精确分片算法。
3 分库分表算法实现
分库的算法如下图所示，这里使用到了 guava 的 range 方法进行计算以及分库的区间划分。
这里需要处理一个分片键为特殊值的情况，这个在业务中是必须的，尤其是在业务的重构过程中，旧数据库中的值不一定每个都符合新的数据库的标准。
关于分库的设计，需要预估一下每个数据库表的存储数量，在本例中，每个数据库的存储数量上上限为 4000w, 当数据库表中的分片键为 0-4kw,则存储在 0 号库中，4kw-8kw 则存储在 1 号库中。
以上是分库的策略算法，关于分表的算法就比较复杂一点儿。在分表的算法中，需要考虑数据的增长，比如用户的订单数据，不仅需要按照用户来划分表，而且需要按照年份还划分。这样操作的好处就是可以实现数据按照年份划分，从而数据的冷热分离。
关于分表的算法，需要预估业务的总数据量，然后计算每个表的数据量，然后推算出一年需要多少表来承接这些数据，最后考虑到业务的扩展性，系统建成后，需要多久再进行系统的建设。
在本例中设计的是每个库中数据库表数量为 10，单张表的数据存储量时 400w。
4 数据库读写分离
项目中如果按照 sharding-jdbc 的读写分离配置，就可以实现写主库，读从库。但是在实际的业务中，需要考虑强制读主库的情况。其配置也比较简单，如下所示，在需要走强主的查询前面加上如下代码即可：
// 强制走主库设置
HintManager.clear();
HintManager.getInstance().setMasterRouteOnly();
5 多数据源的配置
如果项目中除了分库分表的情况，还要多数据源，那么其数据库配置文件需要改写，具体如下所示：
按照以上的配置，便可以实现多数据源的切换，在操作的方法上需要加上数据源的注解，如下图所示即可实现数据源的切换：
6 总结
通过以上的配置操作，即可实现分库分表、读写分离以及数据源的切换，数据库的分库分表配置操作起来也是很简单的，没有想象中的那么复杂，最核心的部分也就是分库分表时的分片算法。在后续的文章中将继续基于此项目进行其它业务的分享。
