南光集团的贸易管理系统需要存储海量订单和库存数据，如何设计分库分表策略？请说明分片键的选择、数据倾斜问题的解决方法，以及跨库事务的处理方案。
南光(集团)有限公司信息技术类难度：中等
答案
1) 【一句话结论】
分库分表需基于业务逻辑选择分片键（如订单ID哈希、库存商品ID范围），通过哈希/范围分片实现数据水平扩展，用复合分片键或虚拟键解决数据倾斜，跨库事务采用分布式事务框架（如Seata AT模式）保证一致性，同时配置读写分离提升性能，并设计动态调整机制应对库表数量变化。
2) 【原理/概念讲解】
分库分表的核心是“分片键”作为数据路由依据，将大表拆分为多个小表实现水平扩展。
- 分片键：是数据分库分表的依据，如订单表按订单ID的哈希值分片，库存表按商品ID的区间分片。
- 数据倾斜：热点数据集中到某分片，导致负载不均。解决方法：复合分片键（如订单ID+下单时间取模）、虚拟分片键（如订单ID%4+时间取模）。
- 跨库事务：多个库表操作需原子性，传统事务无法跨库，需分布式事务（如Seata AT模式），通过全局事务协调器管理事务，确保要么全部成功，要么全部回滚。
（简短类比：分片键是“货物分类规则”，数据倾斜是“某个小仓库堆满货物”，跨库事务是“多个小仓库同时操作货物需同步”。）
3) 【对比与适用场景】
| 分片方式 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 哈希分片 | 根据分片键的哈希值取模，均匀分布数据 | 数据分布均匀，等概率访问 | 订单ID、用户ID等无序数据，访问概率均等 | 需全局唯一ID，热点数据可能集中（需复合键） |
| 范围分片 | 根据分片键的区间（如时间、ID范围）划分 | 数据有序，适合时间序列或有序数据 | 库存表按商品ID范围、订单表按下单时间范围 | 热点数据可能集中在某个区间（需虚拟键） |
4) 【示例】
假设订单表order_table（字段：order_id、user_id、order_time），库存表stock_table（字段：product_id、stock_num、product_name）。
- 分片策略：
- 订单表按
order_id的哈希值（取模库表数量，如库表数4，order_id % 4）分片到order_table_0/order_table_1等； - 库存表按
product_id区间（如0-1000为库表0，1001-2000为库表1）分片。
- 订单表按
- 动态调整：当库表数量从4增加到8时，分片键改为
order_id % 8，迁移数据到新库表（如order_table_4等），通过中间件路由规则更新。 - 跨库事务：订单创建扣减库存，用Seata AT模式，全局事务ID关联操作，确保原子性。
- 读写分离：主库写，从库读，通过中间件（如ShardingSphere）配置读写分离路由。
- 全表查询：用ShardingSphere的查询路由工具，统一查询所有分片数据。
（伪代码示例：插入订单时，计算分片键，路由到对应库表；扣减库存时，通过分布式事务协调器同步操作。）
5) 【面试口播版答案】
“针对南光集团贸易管理系统的分库分表设计，核心是结合业务逻辑选分片键，解决数据倾斜和跨库事务。首先分片键：订单表按订单ID哈希（如order_id % 库表数）分片，库存表按商品ID区间（如0-1000为库表0）分片，这样均匀分布数据。但订单ID可能热点（如某用户频繁下单），导致倾斜，用复合分片键（order_id + 下单时间取模）或虚拟分片键（order_id%4+时间取模）解决。跨库事务方面，订单创建扣减库存需原子性，用Seata AT模式，全局事务ID关联操作，确保要么全部成功要么回滚。另外，分库分表后要配置读写分离（主从复制+中间件），提升性能。当库表数量增加时，动态调整分片键（如库表数从4到8，分片键改为order_id % 8），迁移数据到新库表，避免业务中断。”
6) 【追问清单】
- 问：为什么选择订单ID作为分片键？如果未来需要按用户分库怎么办？
答：订单ID全局唯一，哈希分片均匀，若按用户分库，扩展为复合分片键（user_id + 时间取模）。 - 问：如何检测数据倾斜？
答：监控各分片数据量、QPS，若某分片远大于其他，则倾斜，需调整分片键。 - 问：跨库事务的最终一致性如何保证？
答：Seata AT模式通过本地事务+补偿事务，补偿机制超时自动执行。 - 问：分库分表后，查询全量数据的方案？
答：用ShardingSphere的查询路由工具，或MyBatis-Plus插件，统一查询。 - 问：分片键选时间戳是否可行？
答：时间戳分片适合时间序列，但热点数据（如某个时间段订单集中）会导致倾斜，需结合时间取模，避免单点压力。
7) 【常见坑/雷区】
- 分片键选业务ID未考虑增长，导致未来分片数量不足，迁移困难；
- 数据倾斜未解决，导致某分片性能下降，影响整体系统；
- 跨库事务选锁表方案，导致其他库表无法操作，性能低下；
- 分片键选时间戳未处理时区问题，导致数据分布不均；
- 未考虑读写分离，导致分库分表后读写性能下降。