1. 分库分表的本质与业务场景适配我第一次接触分库分表是在2015年当时负责的电商平台用户表突破了3000万条记录。某次大促期间用户登录接口响应时间从200ms飙升到5秒这就是典型的数据量超过单表承载能力的症状。分库分表本质上是通过数据分散存储来突破单机数据库的容量和性能瓶颈但不同业务场景需要不同的拆分策略。在社交类应用中用户发布的动态信息更适合按用户ID哈希分片保证同一个用户的数据落在同一分片。而在金融交易系统中按交易日期的范围分片可能更合理便于历史数据归档。我曾见过一个错误的案例某P2P平台按借款人ID分片结果发现单个借款人的投标记录集中在某个分片导致热点问题。后来调整为借款人ID投标时间联合分片键才解决问题。2. 拆分维度的黄金选择法则2.1 用户ID哈希的利与弊用户ID作为分片键的优势在于能保证同一用户的数据局部性。比如电商订单表按user_id % 64分片时用户查询自己所有订单只需要访问单个分片。但我在实际项目中踩过坑当某个KOL用户产生海量订单时其所在分片会成为性能瓶颈。这时需要在分片策略中加入时间维度比如(user_id 月份)组合分片。2.2 时间维度的特殊考量日志类数据按时间范围分片看似自然但会面临热尾效应。去年做物联网平台时设备上报数据按月份分表结果当前月份的表承受了90%的读写压力。后来我们改进为设备ID哈希按月分表的二级拆分策略设备数据先哈希分散到16个库每个库再按月份分表。2.3 地域分片的实战案例在本地生活服务类项目中我们按城市ID分库。但遇到跨城业务查询时就头疼了比如用户在北京下单购买上海的服务。最终方案是主数据按服务提供方所在城市分片同时通过ES建立全局索引。3. 分库分表后的五大挑战与破解之道3.1 分布式事务的务实选择早期我们尝试用XA协议保证跨库事务性能直接跌到每秒10TPS。现在更成熟的方案是最终一致性通过消息队列本地事务表TCC模式适合资金类业务比如我们支付系统采用的冻结-确认-取消三阶段SAGA长事务订单系统用的状态机补偿方案3.2 跨库查询的四种解法最近实施的供应链系统中商品和库存分布在不同的分片。我们是这样处理的字段冗余在商品表缓存库存数量异步更新全局表品牌、类目等维表全量同步到各分片内存聚合先按商品ID查各分片库存在应用层汇总专用查询库通过CDC将数据同步到OLAP系统3.3 分页查询的优化技巧当用户要查我的订单第5页时常规做法是在各分片取前50条假设每页10条内存排序。但我们发现当分片数达到32个时这种方案效率骤降。现在采用上次最大ID法记住当前页最后一条记录的ID下页查询时附加WHERE id ?条件。4. 扩容方案的设计艺术4.1 预分片策略去年设计IM系统时我们一开始就规划了1024个逻辑分片32库×32表但实际只部署了4个物理库。当需要扩容时通过迁移工具将部分逻辑分片转移到新数据库节点应用配置只需修改分片映射关系。4.2 动态扩容的平滑方案采用一致性哈希算法时扩容只会影响相邻两个节点的数据迁移。我们自研的迁移工具可以做到双写新旧分片增量数据同步校验数据一致性流量切换 整个过程对业务透明平均每新增一个节点只需迁移1/N的数据N为原节点数。5. 分布式ID生成的工程实践5.1 雪花算法的改造经验标准雪花算法在容器化环境会遇到workerId分配问题。我们的解决方案用ZK持久化节点分配workerId启动时检测时钟回拨优化序列号生成算法避免锁竞争 改造后单机ID生成性能从8万/秒提升到15万/秒。5.2 业务自定义ID的巧妙设计物流单号采用特殊编码年份(2位) 日期(3位) 分片ID(2位) 序列号(5位) LK2300112345这样既保证唯一性又自带路由信息还避免了ID暴增问题。6. 中间件选型的血泪史6.1 ShardingSphere的实战调优在日订单量500万的系统中我们遇到的最大坑是绑定表配置错误导致笛卡尔积查询。正确配置应该是spring: shardingsphere: sharding: binding-tables: - t_order,t_order_item tables: t_order: actual-data-nodes: ds$-{0..15}.t_order_$-{0..7} table-strategy: inline: sharding-column: order_id algorithm-expression: t_order_$-{order_id % 8}6.2 自研中间件的经验教训曾为了特殊需求自研分片中间件结果发现SQL解析是个无底洞特别是子查询和特殊函数连接池管理比想象中复杂协议兼容性测试工作量巨大 最终结论除非有非常特殊的业务需求否则不要轻易自研。7. 数据迁移的实用技巧7.1 全量迁移的优化手段最近一次迁移800亿条用户行为数据时我们采用分批次迁移按主键范围每个批次先校验再导入通过TTL控制校验数据的时效性 最终用时从预估的72小时压缩到18小时。7.2 增量同步的容错设计使用Canal监听binlog时一定要处理网络闪断后的重连机制消息堆积时的动态限流位点信息的定期持久化 我们曾因位点丢失导致数据重复后来增加了校验机制。真正实施分库分表时最难的不是技术方案而是业务适配。每次拆分前都要问这个查询场景能否接受最终一致性这个事务能否拆解这个分页需求是否真的必要记住没有完美的架构只有合适的妥协。