场景题：如果组长要求你主导项目中的分库分表，大致的实施流程是？

明确目标
- 解决单库单表性能瓶颈（如查询延迟、写入吞吐不足）。
- 支持未来3-5年的业务增长（预估数据量、并发量）。
- 是否需要支持高可用、弹性扩容？
评估业务场景
- 核心业务表：确定需拆分的表（如订单表、用户表）。
- 访问模式：高频查询字段（如用户ID、订单ID）、关联查询场景（如JOIN操作）。
- 事务要求：是否涉及跨库事务？是否需要强一致性？
选择分库分表策略
- 垂直分库：按业务模块拆分（如用户库、订单库）。
- 水平分表：按规则拆分单表（如按用户ID取模）。
- 组合策略：先垂直分库，再水平分表（如订单库按用户ID分表）。
确定分片键
- 优先选择高频查询字段（如用户ID、时间）。
- 避免热点问题（如自增ID连续递增）。
- 示例：
  - 订单表按 user_id % 4 分表（4个分表）。
  - 日志表按 create_time 按月分表（如 logs_2025_01）。
设计数据路由逻辑
- 客户端模式（如 ShardingSphere）：在应用层实现路由。
- Proxy模式（如 MyCAT）：通过中间件代理查询。
冗余与索引设计
- 冗余字段：为跨分片查询预存必要字段（如订单表冗余用户ID）。
- 索引优化：在分表中单独创建索引，避免跨表JOIN。

中间件选择
- 开源中间件：ShardingSphere（Java生态）、MyCAT（通用）。
- 商业方案：阿里云DRDS、腾讯云TDSQL。
分布式事务方案
- 强一致性：Seata（AT模式）、TCC（补偿事务）。
- 最终一致性：消息队列（如 RocketMQ）异步补偿。
全局ID生成器
- Snowflake：Twitter开源算法（时间戳+机器ID+序列号）。
- Leaf：美团开源（号段模式+Snowflake）。
监控与运维工具
- 数据一致性校验：脚本定时比对新旧表数据。
- 性能监控：Prometheus + Grafana 监控QPS、延迟。

迁移步骤
1. 双写阶段：
  - 新旧系统并行运行，增量数据同时写入旧表和新表。
  - 使用 Kafka 或 Binlog 工具（如 Canal）同步历史数据。
2. 数据校验：
  - 全量校验：随机抽取新旧表数据对比（如 user_id=1000）。
  - 增量校验：定时任务比对新旧表差异（如 create_time > '2025-07-01'）。
3. 切换流量：
  - 逐步将读请求切换到新表，最后切换写请求。
4. 下线旧表：
  - 确认无残留读请求后，删除旧表。
风险控制
- 回滚预案：若迁移失败，立即切换回旧系统。
- 限流降级：迁移期间限制写入流量，避免雪崩。

应用代码改造
- 分片键注入：在SQL中显式传递分片键（如 user_id）。
- 查询优化：避免跨分片JOIN（改用冗余字段或ES聚合）。
- 事务处理：使用Seata或TCC框架管理分布式事务。
测试验证
- 单元测试：验证分库分表逻辑（如 user_id=100 路由到 db_0.user_0）。
- 压测测试：模拟高并发场景（如 1000 TPS 的订单写入）。
- 异常测试：模拟网络故障、分片键缺失等异常场景。

灰度发布
- 先在部分用户中启用分库分表，观察性能与数据一致性。
- 逐步扩大流量比例，直至全量切换。
监控与告警
- 核心指标：
  - 缓存命中率（Buffer Pool Hit Rate）。
  - 分片负载均衡（各分片QPS、磁盘使用率）。
  - 分布式事务成功率。
- 告警规则：
  - 某分片QPS超过阈值（如 5000 QPS）。
  - 数据不一致告警（如校验脚本发现差异）。
扩容与缩容
- 扩容：增加新分片时，需迁移历史数据（如从4分片扩到8分片）。
- 缩容：合并低负载分片，需确保数据一致性。

问题	解决方案
分片键选择不当	重新设计分片键（如从时间字段改为用户ID），或引入一致性哈希。
跨分片查询性能差	使用ES聚合、冗余字段，或业务层分页后合并结果。
数据迁移不一致	通过Binlog工具（如Canal）实时同步，或人工校验关键字段。
分布式事务冲突	改用最终一致性方案（如消息队列异步补偿），或优化事务边界。
扩容时数据迁移中断	使用双写策略，先迁移部分数据，再逐步完成全量迁移。

核心原则：
- 简单优先：先水平分表，再考虑垂直分库。
- 渐进式改造：小范围试点，逐步推广。
- 自动化运维：通过脚本和工具降低人工成本。
典型实施周期：
- 需求分析：1-2周。
- 开发与测试：3-4周。
- 迁移与上线：2-3周。

通过以上流程，可以系统性地完成分库分表的改造，兼顾性能提升与系统稳定性。

THE END