Redis 集群与分片

Redis 集群架构

在实际运维中我会使用 Redis 集群来应对超大规模的数据量和高并发请求。Redis 集群由多个 Redis 节点组成，每个节点负责存储一部分数据，并通过内部协议互相通信实现数据路由和故障转移。通常我会为每个主节点配置至少一个从节点，用于数据备份与主节点故障后的快速提升。当有查询或写入请求时，任意节点接收到请求后会根据键的哈希槽计算出数据应位于的目标节点，从而实现自动的数据路由分配。

节点角色

在我部署 Redis 集群时，会以主从架构为基础构建高可用环境。主节点直接存储并处理数据，而从节点用来复制主节点的数据并在主节点故障时无缝接管。集群会将数据拆分到固定数量的槽中（默认 16384 个），各个主节点按比例分配这些槽，当需要扩容时可新增节点并在不停机的条件下将部分槽迁移给新加入的节点。

数据分片机制

我在实践中发现 Redis 集群通过对键计算哈希值并映射到固定数量的槽上，再将槽分散给各节点。这样可以实现水平扩展，当数据量增加时我会添加更多节点以分担槽的管理。Redis 集群采用 CRC16 哈希算法将键映射到槽中，从而确保在集群中的数据分布相对均匀。

故障转移与高可用性

在生产中主节点可能因网络或硬件故障不可用，Redis 集群通过内部通信和投票机制自动检测故障并触发故障转移，将对应从节点提升为主节点，并广播更新后的拓扑信息给集群中所有节点。在我实际使用中，如果在搭建集群前为每个主节点分配充足的从节点，就能在故障转移时快速恢复数据访问，从而提高服务可用性。

创建与管理集群的步骤

在实际部署中我会先为每个节点安装并配置 Redis，将 cluster-enabled 设置为 yes，为每个节点指定唯一端口并为集群指定配置文件位置。完成初始化后，启动所有节点使其互相联通，然后使用 redis-cli 的集群创建命令指定节点列表和副本数量。创建完成后可使用 cluster info 和 cluster nodes 命令检查状态。如果需要在线扩容，我会在运行中通过 add-node 指令添加新节点，然后使用 reshard 操作将部分槽迁移到新节点上。
在此过程中我会确保网络可靠和节点时钟同步，以减少数据分片和迁移时出现不一致或超时的可能。

# 创建集群示例
redis-cli --cluster create 192.168.0.10:7000 192.168.0.11:7000 192.168.0.12:7000 192.168.0.13:7000 192.168.0.14:7000 192.168.0.15:7000 --cluster-replicas 1

# 检查集群配置
redis-cli --cluster check 192.168.0.10:7000

# 添加新节点
redis-cli --cluster add-node 192.168.0.16:7000 192.168.0.10:7000

# 重新分片
redis-cli --cluster reshard 192.168.0.10:7000

数据迁移与扩容实践

实际运维中，当数据量增长或节点故障时需对槽进行再平衡。使用 redis-cli 或 redis-trib 工具可以平稳地将槽从原节点迁移到新加入的节点上。这样我在扩容时无需停机，即使在高并发场景下也能动态水平扩展。

# 槽迁移命令示例
redis-trib.rb reshard 192.168.0.10:7000

负载均衡与客户端访问

在集群模式下，客户端需支持 cluster 模式才能正确处理来自不同节点的数据。实际使用中我一般选择兼容集群协议的客户端驱动，让客户端自动重定向请求到正确节点。如果客户端不支持集群协议，我会考虑使用代理层，例如 Twemproxy，以实现透明的请求路由和负载均衡。

监控与维护

为确保集群高效稳定运行，我会定期使用 cluster info 和 cluster nodes 命令检测各节点状态，并在出现故障时迅速定位问题。日常运维中我会检查日志、监控指标、网络连接质量，并在必要时对数据进行备份。在扩容和数据迁移时，我倾向于在业务低峰期进行操作，以减少对在线服务的影响。

# 检查集群状态
redis-cli -c -h 192.168.0.10 -p 7000 cluster info
redis-cli -c -h 192.168.0.10 -p 7000 cluster nodes

最佳实践示例表格

下表列出我在实际生产环境中总结的 Redis 集群最佳实践，以便在部署和维护时快速参考

实践	内容	好处
使用等量槽分配策略	初始化时为主节点平均分配槽	数据分布均衡减少热点
为每个主节点提供从节点	确保故障转移快速进行	减少服务中断时间
使用支持集群的客户端驱动	客户端自动重定向请求	避免路由错误与额外逻辑
定期检查集群状态	使用 cluster info 监控运行情况	及时发现故障与延迟问题
扩容时平稳迁移槽	使用 reshard 在低峰期进行	减少业务影响