题目
Redis集群动态扩缩容场景下的数据迁移与请求路由优化
信息
- 类型：问答
- 难度：⭐⭐⭐
考点
Redis集群分片原理,数据迁移机制,请求路由优化,高可用性设计
快速回答
在Redis集群动态扩缩容场景中，需要解决的核心问题包括：
- 数据迁移策略：使用
MIGRATE命令进行槽位数据迁移，确保原子性和一致性 - 请求重定向优化：通过
MOVED/ASK响应和客户端缓存减少重定向开销 - 扩缩容流程：遵循添加节点→迁移槽位→更新配置→删除节点的顺序
- 高可用保障：迁移期间保持主从复制，监控槽位覆盖率和节点状态
1. Redis集群核心原理
Redis集群采用16384个哈希槽（slot）分片机制，每个键通过CRC16校验后取模分配到具体槽位。节点通过Gossip协议维护集群状态，客户端根据MOVED重定向响应更新路由缓存。
2. 动态扩缩容数据迁移流程
扩容步骤：
- 添加新节点：
redis-cli --cluster add-node new_host:port existing_host:port - 迁移槽位：
redis-cli --cluster reshard existing_host:port \ --cluster-from node-id1 --cluster-to node-id2 --cluster-slots 1000 - 槽位迁移内部使用
MIGRATE命令原子化迁移键值对
缩容步骤：
- 将待删除节点的槽位迁移到其他节点
- 执行节点删除：
redis-cli --cluster del-node host:port node-id
3. 关键问题与解决方案
3.1 数据迁移原子性保障
MIGRATE命令工作流程：
- 源节点序列化键值对
- 目标节点创建临时键并恢复数据
- 目标节点返回ACK后源节点删除键
- 迁移期间阻塞客户端请求（可配置非阻塞）
3.2 请求路由优化
重定向类型：
MOVED：槽位已永久迁移，客户端应更新路由表ASK：槽位迁移中临时重定向，不更新路由表
优化策略：
- 客户端缓存槽位-节点映射（如Jedis的
ClusterSlots） - 批量操作时优先根据槽位分组到相同节点
- 使用
hash_tag确保相关键在同一槽位（如{user1000}.profile和{user1000}.orders）
3.3 高可用设计
- 迁移前确保目标节点有从节点
- 监控槽位覆盖率：
CLUSTER SLOTS检查所有槽位是否被覆盖 - 设置
cluster-require-full-coverage no允许部分槽位不可用
4. 最佳实践与常见错误
最佳实践：
- 分批迁移槽位（每次100-500个槽）减少阻塞时间
- 迁移期间避免执行
FLUSHDB等危险操作 - 使用
CLUSTER SETSLOT手动管理迁移状态
常见错误：
- 错误1：未迁移完槽位就删除节点 → 导致数据丢失
解决方案：通过CLUSTER NODES确认节点无槽位后再删除 - 错误2：客户端未处理
ASK重定向 → 请求失败
解决方案：实现完整的重定向逻辑（如Jedis的askRedirect） - 错误3：迁移期间网络分区 → 脑裂风险
解决方案：设置合理cluster-node-timeout（默认15秒）
5. 扩展知识
- 迁移限流：通过
config set migrate-throttle 100限制带宽（单位KB/s） - 跨机房迁移：使用
--cluster-use-empty-masters避免空节点干扰 - 自动化工具：Redis Enterprise的
rladmin或开源方案redis-trib.rb - 槽位计算优化：自定义
hash_function应对数据倾斜（需修改Redis源码）
