针对高并发场景（如电商秒杀系统），如何设计数据库分库分表策略？请解释分库分表后的数据一致性和性能影响，并举例说明如何处理跨库事务（如订单与库存的原子性操作）。
信步科技策略采购难度：中等
答案
1) 【一句话结论】
高并发场景下，分库分表通过水平切分数据库提升性能，需结合分片策略（如哈希/范围分片）和分布式事务（如Seata）处理数据一致性与跨库原子性，核心是“数据分散+事务保障”。
2) 【原理/概念讲解】
分库分表是将海量数据水平切分到多个数据库实例（分库）或同一数据库内的多个表（分表），以缓解单库压力。分片键（如商品ID）决定数据分布规则。类比：把一个大超市（数据库）拆成多个分店（分库），每个分店再分多个货架（分表），每个分店处理自己区域的商品，查询更快。分库是跨实例，分表是同实例内切分，表结构相同，数据按规则分布。
3) 【对比与适用场景】
| 特性 | 分库（水平切分） | 分表（同库内切分） |
|---|---|---|
| 定义 | 将表数据按规则切分到多个数据库实例（库） | 将表数据按规则切分到同一数据库的多个表（表） |
| 表结构 | 相同，但实例间无关联 | 相同，库内表有逻辑关联 |
| 适用场景 | 数据量极大，单库容量/性能不足 | 单库表数据量过大，查询慢 |
| 注意点 | 需跨实例事务，数据迁移复杂 | 同库事务，但查询需处理表关联 |
4) 【示例】
假设电商秒杀系统，订单表（order）和库存表（stock）：
- 分库策略：订单表按商品ID（goods_id）哈希分库，库存表同步按goods_id哈希分库（如订单表在库1，库存表在库1）。
- 跨库事务示例（伪代码）：
说明：订单表和库存表同库（分库1），通过分布式事务框架（如Seata）保证原子性，避免超卖。def create_order(user_id, goods_id, quantity): # 1. 更新订单表（分库1） with db1.transaction(): order_id = insert_order(user_id, goods_id, quantity) # 插入订单 # 2. 调用库存服务扣减库存（分库1） stock_service.reduce_stock(goods_id, quantity) # 扣减库存 # 分布式事务（如Seata TCC模式） # TCC：Try（预留库存）、Confirm（确认扣减）、Cancel（回滚）
5) 【面试口播版答案】
针对高并发秒杀系统，分库分表的核心是通过水平切分数据库提升性能。比如订单表按商品ID哈希分库，库存表同步分库，每个库独立处理，但跨库事务需要分布式事务方案。比如订单创建时，先更新订单表（分库1），再调用库存服务扣减库存（分库1），用Seata的TCC模式，保证原子性，避免超卖。分库分表后，数据量分散，读写性能提升，需注意数据一致性，通过最终一致性（如消息队列）或强一致性（分布式事务）解决。
6) 【追问清单】
- 问题1：分片键（分片字段）如何选择？
回答要点：选业务ID（如商品ID、订单ID），避免热点数据（如时间戳）导致数据倾斜。 - 问题2：跨库事务的解决方案？
回答要点：用分布式事务框架（如Seata的TCC模式、两阶段提交），或最终一致性（消息队列+补偿机制）。 - 问题3：分表后如何处理数据一致性？
回答要点：强一致性用分布式事务，最终一致性用消息队列（如Kafka）+补偿，适用于读多写少场景。 - 问题4：分库分表后如何处理热点数据？
回答要点：对热点数据（如秒杀商品）做缓存（如Redis），或分片时结合缓存，减少数据库压力。 - 问题5：分库分表后的数据迁移？
回答要点：用分库分表工具（如ShardingSphere、MyCAT），分阶段迁移，避免业务中断。
7) 【常见坑/雷区】
- 坑1：分片键选择不当导致数据倾斜（如按时间戳分片，导致新数据集中在一个表）。
- 坑2：跨库事务处理不当导致超卖（如事务未原子性，库存扣减失败但订单已创建）。
- 坑3：分表后查询性能问题（如笛卡尔积，需加条件过滤或分库分表后调整查询逻辑）。
- 坑4：数据一致性策略错误（如强一致性场景用最终一致性，导致数据不一致）。
- 坑5：分库分表后维护复杂度（如数据迁移、备份、故障恢复，需额外工具支持）。