JCSprout 数据库水平垂直拆分实战指南分表策略、分布式 ID 与事务一致性方案【免费下载链接】JCSprout Java Core Sprout : basic, concurrent, algorithm项目地址: https://gitcode.com/gh_mirrors/jc/JCSprout当业务数据量达到千万级甚至亿级之后单库单表往往会成为整个系统的瓶颈此时对数据库进行水平拆分与垂直拆分就是最直接的扩容手段。本篇文章以 JCSprout 知识库中 数据库水平垂直拆分 一文为核心骨架结合仓库内 一次分表踩坑实践的探讨、分布式 ID 生成器 与 一致性 Hash 算法原理 的实战经验系统讲解取模分表、时间分表、范围分表、垂直拆分的具体做法以及拆分后分布式事务两段提交、最终一致性 MQ 补偿的落地思路。读完本文你将掌握一套可落地的何时拆、怎么拆、拆完怎么保证数据一致的完整方案。何时需要拆分DB 成为系统瓶颈的判断依据拆分不是银弹过早拆分反而会增加复杂度。JCSprout 原文档给出的判断标准非常明确当数据库量非常大的时候DB 已经成为系统瓶颈时才考虑进行水平垂直拆分。具体到生产环境可以参考 一次分表踩坑实践的探讨 中的真实案例当单表数据量突破亿级、每天保持 200W 增量且存在关联查询和报表统计业务时一个查询功能甚至需要跑好几分钟同时 MySQL 所在主机内存占用高、整体负载居高不下读写吞吐量明显下降。这些信号都表明单表已经不堪重负。需要注意的是拆分之前应该先排查技术债该实战案例中正是因为表中缺少可排序索引导致无法快速筛选历史数据整个优化过程被严重拖慢。这给我们的启示是——每张表都应该保留一个可用于排序查询的字段自增 ID、创建时间这是后续任何归档、迁移、拆分操作的前提。水平拆分同构不同数据的多表扩展水平拆分的核心思想是将一张表的数据拆到多张表中每张表的表结构完全相同但存储的数据不同。通常根据表中的某一字段通常是主键 ID取模处理来完成路由。三种主流分表策略按照 数据库水平垂直拆分 的归纳水平拆分有以下三种策略策略做法优点缺点ID 取模index hash(sharding字段) % 分表数量数据分布均匀、查询路由简单扩容困难取模基数改变后需数据重分布时间分表如每月生成一张表改动简单、历史数据易迁移热点数据集中在近期表范围分表一张表只存0~1000W超过则分新表扩展灵活存在热点数据ID 取模分表是最常见的做法。拆分之后查询、修改、删除同样要经过取模路由。以新增数据为例需要先生成 ID再根据生成的 ID 取模计算出具体写入哪张表。由于分表后不能再依赖单表自增这里就可以引入分布式 ID 生成器来生成全局唯一且趋势递增的 ID。时间分表适用于只关心近期数据的业务。在 一次分表踩坑实践的探讨 中对于业务上只查询近三个月数据的场景作者选择了按照月份拆分查询时只需要拼接好表名即可改动简单且历史数据也好迁移。范围分表如0~1000W一张表扩展灵活但新写入的数据总是集中在最新的一张表上容易形成热点需要结合业务评估。哈希取模分表的实战细节在生产实践中哈希分表有两个关键细节值得注意第一sharding 字段的选择至关重要。实战案例中的业务是物联网应用所有数据都包含设备唯一标识 IMEI该字段天然保持唯一性且大多数业务都基于它查询因此被选为 sharding 字段。由于 IMEI 本身是唯一整型直接用它做mod运算即可省去了哈希过程int index sharding字段 % 分表数量 ; select xx from busy_ index where sharding字段 xxx;这实际上就是在 JDBC 层自行实现了计算表名 → 路由查询的分片逻辑避免了集成sharding-jdbc现 ShardingSphere的复杂度。但自研方案没有代理数据库查询方法无法像 ShardingSphere 那样完成SQL解析 → SQL路由 → 执行SQL → 合并结果的完整流程每个涉及分表的底层查询方法都需要手动改造属于在现有技术条件下快速实现达成效果的折中方案。第二分表数量要选 2 的 N 次方。实战案例最终拆分为 64 张表2^6。这样做的原因是在取模分表方式下即便今后还需要再次分表受影响的数据范围也会尽量小。此外为了验证分表改造是否遗漏作者采用了一个巧妙的办法——将原表表名加后缀改名如_190416bak这样测试时如果某个查询仍走原表就会立即报错便于提前发现问题。水平拆分后的查询约束分表之后查询不可避免地变复杂。原文档明确给出两条约束不建议join一般做法是做两次查询在应用层完成数据组装非 sharding 字段的查询会导致全表扫描遍历所有分表这是所有分片方案都会遇到的问题。针对第二条一次分表踩坑实践的探讨 给出了几个实战处理建议排查每个分表查询方法是否走了 sharding 字段没有的话评估是否可以调整业务对于报表统计这类必须全量聚合的需求可以利用多线程并行查询各分表后汇总统计对于千万表中某一特殊类型数据只占几千上万条的独立分页查询场景如投诉消息逐条处理建议单独建一张表维护避免与大数据量数据混合分片后难以分页和 like 查询。分表后的数据迁移与上线分表改造只是需求的 80%数据迁移是上线前必须解决的问题。实战经验是额外准备一个迁移程序将老表数据按照分片规则复制到新的 64 张表中。由于生产数据已上亿且老表缺少create_time索引迁移耗时非常长最终只能与产品协商告知用户旧数据短期内可能查询不到只能在凌晨迁移白天会影响数据库负载。这也再次印证了表结构设计时预留可排序字段的重要性。垂直拆分字段过多时的纵向切分与水平拆分不同垂直拆分的对象是字段。当一张表的字段过多时可以按字段的使用频率拆分主表存放使用频次较高的字段扩展表存放其余字段。例如订单表可以拆分为订单主表订单号、用户 ID、金额、状态等高频字段与订单扩展表收货地址、备注、发票信息等低频字段通过主键关联。与水平拆分后的查询建议一致垂直拆分后的多表查询同样不建议使用join依然建议做两次查询在应用层合并结果。拆分之后的核心难题分布式事务拆分后一张表变成多张表、一个库变成多个库最突出的问题就是事务如何保证。原来依赖单库ACID的本地事务现在横跨多个数据库节点无法再用单一事务边界来保证原子性。两段提交2PC两段提交Two-Phase Commit是分布式事务的经典方案分为准备阶段和提交阶段准备阶段协调者向所有参与者发送准备请求各参与者执行本地事务但暂不提交并返回可以提交或准备失败提交阶段协调者根据各参与者的反馈决定全局提交或回滚——全部成功则广播提交任一失败则广播回滚。两段提交能够保证强一致性但代价是阻塞准备阶段参与者需要一直持有资源锁等待协调者的最终指令协调者宕机时参与者会长时间阻塞系统可用性受影响。因此两段提交更适合对一致性要求极高、并发量可控的场景。最终一致性面向高可用的补偿方案如果业务对强一致性要求不高最终一致性是更合适的方案。核心思想是允许系统在某个时间窗口内存在短暂的不一致但通过补偿机制保证最终达到一致状态。原文档给出了一个典型场景业务 A 调用 B两个执行成功才算最终成功。当 A 成功之后B 执行失败如何通知 A 进行回滚常见做法是A 执行成功 → 调用 B 失败 → B 通过 MQ 发送消息给 A → A 消费消息后执行回滚![最终一致性补偿流程]A 成功后 B 失败B 通过 MQ 通知 A 回滚A 的回滚操作必须幂等防止 B 重复发消息导致重复回滚。这里有一个关键前提A 的回滚操作必须是幂等的。因为 MQ 消息存在重试与重复投递的可能如果 B 重复发送消息A 重复执行回滚非幂等操作如重复扣减、重复发券就会产生错误。幂等可以通过唯一业务流水号、状态机校验、乐观锁等手段实现。配套基础设施分布式 ID 生成器水平拆分后单表自增失效全局唯一且趋势递增的 ID 成为刚性需求。JCSprout 的 分布式 ID 生成器 一文系统对比了四种方案这里直接给出结论方案优点缺点适用场景MySQLauto_increment全局唯一、趋势递增强依赖 DBDB 挂了就不可用低并发、可容忍 DB 单点多库自增水平扩展A 库 0,2,4,6 / B 库 1,3,5,7提高可用性、趋势递增扩容困难、仍强依赖 DB可接受的中间态方案本地 UUID本地生成、效率高、无网络消耗无序、字符串不适合做主键不要求排序的非主键 IDTwitter Snowflake 雪花算法全局唯一、趋势递增、本地生成效率高依赖机器时钟时钟回拨需处理分布式系统主键 ID 的主流选择取模分表与分布式 ID 的配合逻辑是先由 ID 生成器产出全局 ID再用ID % 分表数量计算路由保证同一条数据能稳定落在同一张表从而支持后续的查询、修改、删除。更深一层取模分表的演进——一致性哈希取模分表hash(key) % N的致命弱点是扩容困难当节点数量 N 变化时几乎所有 key 都需要重新计算路由数据迁移成本极高。这与 一致性 Hash 算法原理 中分析的 hash 取模容错性与扩展性差的缺陷完全一致。一致性哈希通过将哈希值构造成0 ~ 2^32-1的环形空间让数据节点与数据 key 都映射到环上按顺时针方向就近路由。这样增删节点时只影响相邻少部分数据。对于数据库分库分表或分布式缓存等需要频繁扩缩容的场景一致性哈希比朴素取模更合适。这也解释了为什么实战案例中强调分表数量取 2 的 N 次方——它本质上是在用幂次基数降低未来二次拆分时的数据迁移影响面。总结与最佳实践综合 数据库水平垂直拆分 与仓库内各篇实战文档可以沉淀出如下最佳实践拆分时机要果断但前置条件要补齐单表过亿、负载持续高位时就要规划拆分同时保证每张表都有可排序字段自增 ID / 创建时间分表策略必须结合业务选型只查近期数据选时间分表全量数据可能被查询选哈希分表sharding 字段必须是业务查询的高频且唯一字段分表数量选 2 的 N 次方为未来二次拆分预留空间水平、垂直拆分后一律避免join用两次查询 应用层组装替代拆分后的事务按一致性要求分级强一致用两段提交接受阻塞代价弱一致用最终一致性 MQ 补偿且补偿操作必须幂等上线前必须完成数据迁移验证可通过原表改名 观察报错的方式提前发现路由遗漏。需要进一步深入学习的读者可以在仓库中继续阅读 MySQL 索引原理理解大表查询慢的根因、SQL 优化拆分前的兜底手段、分布式缓存设计 以及 分布式 ID 生成器形成从单库优化 → 拆分扩容 → 一致性保障的完整知识闭环。【免费下载链接】JCSprout Java Core Sprout : basic, concurrent, algorithm项目地址: https://gitcode.com/gh_mirrors/jc/JCSprout创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
JCSprout 数据库水平垂直拆分实战指南分表策略、分布式 ID 与事务一致性方案【免费下载链接】JCSprout Java Core Sprout : basic, concurrent, algorithm项目地址: https://gitcode.com/gh_mirrors/jc/JCSprout当业务数据量达到千万级甚至亿级之后单库单表往往会成为整个系统的瓶颈此时对数据库进行水平拆分与垂直拆分就是最直接的扩容手段。本篇文章以 JCSprout 知识库中 数据库水平垂直拆分 一文为核心骨架结合仓库内 一次分表踩坑实践的探讨、分布式 ID 生成器 与 一致性 Hash 算法原理 的实战经验系统讲解取模分表、时间分表、范围分表、垂直拆分的具体做法以及拆分后分布式事务两段提交、最终一致性 MQ 补偿的落地思路。读完本文你将掌握一套可落地的何时拆、怎么拆、拆完怎么保证数据一致的完整方案。何时需要拆分DB 成为系统瓶颈的判断依据拆分不是银弹过早拆分反而会增加复杂度。JCSprout 原文档给出的判断标准非常明确当数据库量非常大的时候DB 已经成为系统瓶颈时才考虑进行水平垂直拆分。具体到生产环境可以参考 一次分表踩坑实践的探讨 中的真实案例当单表数据量突破亿级、每天保持 200W 增量且存在关联查询和报表统计业务时一个查询功能甚至需要跑好几分钟同时 MySQL 所在主机内存占用高、整体负载居高不下读写吞吐量明显下降。这些信号都表明单表已经不堪重负。需要注意的是拆分之前应该先排查技术债该实战案例中正是因为表中缺少可排序索引导致无法快速筛选历史数据整个优化过程被严重拖慢。这给我们的启示是——每张表都应该保留一个可用于排序查询的字段自增 ID、创建时间这是后续任何归档、迁移、拆分操作的前提。水平拆分同构不同数据的多表扩展水平拆分的核心思想是将一张表的数据拆到多张表中每张表的表结构完全相同但存储的数据不同。通常根据表中的某一字段通常是主键 ID取模处理来完成路由。三种主流分表策略按照 数据库水平垂直拆分 的归纳水平拆分有以下三种策略策略做法优点缺点ID 取模index hash(sharding字段) % 分表数量数据分布均匀、查询路由简单扩容困难取模基数改变后需数据重分布时间分表如每月生成一张表改动简单、历史数据易迁移热点数据集中在近期表范围分表一张表只存0~1000W超过则分新表扩展灵活存在热点数据ID 取模分表是最常见的做法。拆分之后查询、修改、删除同样要经过取模路由。以新增数据为例需要先生成 ID再根据生成的 ID 取模计算出具体写入哪张表。由于分表后不能再依赖单表自增这里就可以引入分布式 ID 生成器来生成全局唯一且趋势递增的 ID。时间分表适用于只关心近期数据的业务。在 一次分表踩坑实践的探讨 中对于业务上只查询近三个月数据的场景作者选择了按照月份拆分查询时只需要拼接好表名即可改动简单且历史数据也好迁移。范围分表如0~1000W一张表扩展灵活但新写入的数据总是集中在最新的一张表上容易形成热点需要结合业务评估。哈希取模分表的实战细节在生产实践中哈希分表有两个关键细节值得注意第一sharding 字段的选择至关重要。实战案例中的业务是物联网应用所有数据都包含设备唯一标识 IMEI该字段天然保持唯一性且大多数业务都基于它查询因此被选为 sharding 字段。由于 IMEI 本身是唯一整型直接用它做mod运算即可省去了哈希过程int index sharding字段 % 分表数量 ; select xx from busy_ index where sharding字段 xxx;这实际上就是在 JDBC 层自行实现了计算表名 → 路由查询的分片逻辑避免了集成sharding-jdbc现 ShardingSphere的复杂度。但自研方案没有代理数据库查询方法无法像 ShardingSphere 那样完成SQL解析 → SQL路由 → 执行SQL → 合并结果的完整流程每个涉及分表的底层查询方法都需要手动改造属于在现有技术条件下快速实现达成效果的折中方案。第二分表数量要选 2 的 N 次方。实战案例最终拆分为 64 张表2^6。这样做的原因是在取模分表方式下即便今后还需要再次分表受影响的数据范围也会尽量小。此外为了验证分表改造是否遗漏作者采用了一个巧妙的办法——将原表表名加后缀改名如_190416bak这样测试时如果某个查询仍走原表就会立即报错便于提前发现问题。水平拆分后的查询约束分表之后查询不可避免地变复杂。原文档明确给出两条约束不建议join一般做法是做两次查询在应用层完成数据组装非 sharding 字段的查询会导致全表扫描遍历所有分表这是所有分片方案都会遇到的问题。针对第二条一次分表踩坑实践的探讨 给出了几个实战处理建议排查每个分表查询方法是否走了 sharding 字段没有的话评估是否可以调整业务对于报表统计这类必须全量聚合的需求可以利用多线程并行查询各分表后汇总统计对于千万表中某一特殊类型数据只占几千上万条的独立分页查询场景如投诉消息逐条处理建议单独建一张表维护避免与大数据量数据混合分片后难以分页和 like 查询。分表后的数据迁移与上线分表改造只是需求的 80%数据迁移是上线前必须解决的问题。实战经验是额外准备一个迁移程序将老表数据按照分片规则复制到新的 64 张表中。由于生产数据已上亿且老表缺少create_time索引迁移耗时非常长最终只能与产品协商告知用户旧数据短期内可能查询不到只能在凌晨迁移白天会影响数据库负载。这也再次印证了表结构设计时预留可排序字段的重要性。垂直拆分字段过多时的纵向切分与水平拆分不同垂直拆分的对象是字段。当一张表的字段过多时可以按字段的使用频率拆分主表存放使用频次较高的字段扩展表存放其余字段。例如订单表可以拆分为订单主表订单号、用户 ID、金额、状态等高频字段与订单扩展表收货地址、备注、发票信息等低频字段通过主键关联。与水平拆分后的查询建议一致垂直拆分后的多表查询同样不建议使用join依然建议做两次查询在应用层合并结果。拆分之后的核心难题分布式事务拆分后一张表变成多张表、一个库变成多个库最突出的问题就是事务如何保证。原来依赖单库ACID的本地事务现在横跨多个数据库节点无法再用单一事务边界来保证原子性。两段提交2PC两段提交Two-Phase Commit是分布式事务的经典方案分为准备阶段和提交阶段准备阶段协调者向所有参与者发送准备请求各参与者执行本地事务但暂不提交并返回可以提交或准备失败提交阶段协调者根据各参与者的反馈决定全局提交或回滚——全部成功则广播提交任一失败则广播回滚。两段提交能够保证强一致性但代价是阻塞准备阶段参与者需要一直持有资源锁等待协调者的最终指令协调者宕机时参与者会长时间阻塞系统可用性受影响。因此两段提交更适合对一致性要求极高、并发量可控的场景。最终一致性面向高可用的补偿方案如果业务对强一致性要求不高最终一致性是更合适的方案。核心思想是允许系统在某个时间窗口内存在短暂的不一致但通过补偿机制保证最终达到一致状态。原文档给出了一个典型场景业务 A 调用 B两个执行成功才算最终成功。当 A 成功之后B 执行失败如何通知 A 进行回滚常见做法是A 执行成功 → 调用 B 失败 → B 通过 MQ 发送消息给 A → A 消费消息后执行回滚![最终一致性补偿流程]A 成功后 B 失败B 通过 MQ 通知 A 回滚A 的回滚操作必须幂等防止 B 重复发消息导致重复回滚。这里有一个关键前提A 的回滚操作必须是幂等的。因为 MQ 消息存在重试与重复投递的可能如果 B 重复发送消息A 重复执行回滚非幂等操作如重复扣减、重复发券就会产生错误。幂等可以通过唯一业务流水号、状态机校验、乐观锁等手段实现。配套基础设施分布式 ID 生成器水平拆分后单表自增失效全局唯一且趋势递增的 ID 成为刚性需求。JCSprout 的 分布式 ID 生成器 一文系统对比了四种方案这里直接给出结论方案优点缺点适用场景MySQLauto_increment全局唯一、趋势递增强依赖 DBDB 挂了就不可用低并发、可容忍 DB 单点多库自增水平扩展A 库 0,2,4,6 / B 库 1,3,5,7提高可用性、趋势递增扩容困难、仍强依赖 DB可接受的中间态方案本地 UUID本地生成、效率高、无网络消耗无序、字符串不适合做主键不要求排序的非主键 IDTwitter Snowflake 雪花算法全局唯一、趋势递增、本地生成效率高依赖机器时钟时钟回拨需处理分布式系统主键 ID 的主流选择取模分表与分布式 ID 的配合逻辑是先由 ID 生成器产出全局 ID再用ID % 分表数量计算路由保证同一条数据能稳定落在同一张表从而支持后续的查询、修改、删除。更深一层取模分表的演进——一致性哈希取模分表hash(key) % N的致命弱点是扩容困难当节点数量 N 变化时几乎所有 key 都需要重新计算路由数据迁移成本极高。这与 一致性 Hash 算法原理 中分析的 hash 取模容错性与扩展性差的缺陷完全一致。一致性哈希通过将哈希值构造成0 ~ 2^32-1的环形空间让数据节点与数据 key 都映射到环上按顺时针方向就近路由。这样增删节点时只影响相邻少部分数据。对于数据库分库分表或分布式缓存等需要频繁扩缩容的场景一致性哈希比朴素取模更合适。这也解释了为什么实战案例中强调分表数量取 2 的 N 次方——它本质上是在用幂次基数降低未来二次拆分时的数据迁移影响面。总结与最佳实践综合 数据库水平垂直拆分 与仓库内各篇实战文档可以沉淀出如下最佳实践拆分时机要果断但前置条件要补齐单表过亿、负载持续高位时就要规划拆分同时保证每张表都有可排序字段自增 ID / 创建时间分表策略必须结合业务选型只查近期数据选时间分表全量数据可能被查询选哈希分表sharding 字段必须是业务查询的高频且唯一字段分表数量选 2 的 N 次方为未来二次拆分预留空间水平、垂直拆分后一律避免join用两次查询 应用层组装替代拆分后的事务按一致性要求分级强一致用两段提交接受阻塞代价弱一致用最终一致性 MQ 补偿且补偿操作必须幂等上线前必须完成数据迁移验证可通过原表改名 观察报错的方式提前发现路由遗漏。需要进一步深入学习的读者可以在仓库中继续阅读 MySQL 索引原理理解大表查询慢的根因、SQL 优化拆分前的兜底手段、分布式缓存设计 以及 分布式 ID 生成器形成从单库优化 → 拆分扩容 → 一致性保障的完整知识闭环。【免费下载链接】JCSprout Java Core Sprout : basic, concurrent, algorithm项目地址: https://gitcode.com/gh_mirrors/jc/JCSprout创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
