扩容触发条件
- 容量指标：磁盘使用率超过80%且预计3个月内将达到上限
- 性能指标：查询响应时间持续超过SLA阈值（如>500ms）
- 并发指标：活跃连接数长期维持在最大连接数的70%以上
- 监控报警：周期性出现CPU/IO饱和度报警
横向扩容实施步骤
1. 评估与规划阶段
- 进行容量评估，计算当前数据增长曲线
- 确定扩容比例（如增加50%节点数）
- 选择扩容策略：一致性哈希扩容或范围扩容
2. 数据迁移方案
方案A：在线迁移（推荐）
- 部署新节点并加入集群
- 配置数据同步机制（如MySQL的GTID复制）
- 分批迁移热点数据
- 切换流量验证
方案B：停机迁移
- 停止写入服务
- 全量备份现有数据
- 重新分配数据到新旧节点
- 恢复服务
3. 分片策略调整
- 重构分片键（Sharding Key）算法
- 更新路由配置（如MyCat/ShardingSphere配置）
- 测试数据均衡性
4. 应用层适配
- 更新数据源配置
- 调整连接池参数
- 修改可能受影响的SQL语句
常见挑战与解决方案
-
数据倾斜问题：
- 案例：某电商平台用户表按ID哈希分片，导致某些分片数据量是其他分片的3倍
- 解决方案：采用复合分片键（如ID+注册时间）
-
跨分片事务：
- 引入分布式事务框架（如Seata）
- 或采用最终一致性模式
-
扩容成本控制：
- 采用混部策略（SSD+HDD混合存储）
- 实施冷热数据分离
最佳实践案例
某社交平台在日活用户突破1000万时的扩容经验：
- 从8个分片扩容到12个分片
- 采用在线迁移方式，耗时72小时
- 迁移期间QPS下降控制在15%以内
- 扩容后TP99延迟从800ms降至300ms
停机扩容
方案概述
停机扩容是一种在数据库架构演进早期阶段常用的方案，适用于数据库规模较小且能够接受短暂服务中断的场景。
详细实施步骤
- 服务公告阶段：在扩容前3-5天发布维护公告
- 服务停止阶段：关闭负载均衡器流量入口，停止所有应用服务进程
- 数据迁移阶段：新增数据库实例，编写迁移脚本变更分片规则
- 配置更新阶段：更新数据库连接池配置，调整分片路由逻辑
- 服务恢复阶段：先启动数据库服务，再启动应用服务
优缺点
优势：
- 实施简单直接，技术难度低
- 不需要复杂的数据同步机制
- 一次性完成架构调整
局限：
- 必须停机操作，影响业务连续性
- 随着数据量增长，迁移时间会显著增加
- 不适合7×24小时高可用要求的业务
适用场景
- 初创企业早期数据库扩展
- 内部管理系统升级
- 能接受定时维护的ToB服务
- 数据量在TB级别以下的迁移
平滑扩容
方案概述
平滑扩容的核心思想是采用渐进式倍增策略，通过分阶段操作将数据库数量逐步增加，同时保持服务不中断。
方案特点
- 扩容比例：采用2倍扩容策略（如从2个DB节点扩展至4个节点）
- 技术要求：依赖双主复制机制实现数据同步
- 实施阶段：分测试验证和生产上线两个主要阶段
详细实施步骤
- 基础设施准备：申请新节点，确保与原有集群处于同一VPC
- 测试环境验证：搭建测试集群，校验数据一致性
- 生产环境上线：滚动部署，配置中间件逐步迁移流量
- 后续维护：部署监控，定期执行维护
优点
- 业务连续性保障：扩容过程中服务持续可用
- 团队压力缓解：时间窗口更宽松，允许分阶段执行
- 风险控制优势：实时监控，发现问题立即处理
- 性能优化效果：单库数据量减少带来显著性能提升
缺点
- 程序复杂度高：需要配置双主同步、双主双写
- 扩容成本高：运维成本激增，同步链路呈平方级增长
适用场景
- 大型网站
- 对高可用要求高的服务