1. 项目概述为什么我们需要Redis集群如果你用过Redis大概率会为它的速度着迷。但单机Redis再快也有它的天花板内存容量有限、单点故障风险、网络带宽瓶颈。当你的应用从一个小型博客成长为一个日活百万的平台缓存击穿、雪崩、单点宕机这些问题就会像定时炸弹一样冒出来。这时候Redis集群Redis Cluster就不再是一个“可选项”而是一个“必选项”。简单来说Redis集群是一种将数据自动分片Sharding到多个Redis节点并提供高可用性High Availability的分布式解决方案。它允许你横向扩展用多台机器的内存和计算资源来承载更大的数据量和更高的并发请求。今天我就结合自己多次在生产环境搭建和维护Redis集群的经验从零开始手把手带你走一遍Redis集群的完整部署、配置和核心运维流程。无论你是运维工程师、后端开发还是对分布式系统感兴趣的技术人这篇万字长文都能让你对Redis集群有一个透彻的理解并能独立完成部署。2. 集群架构核心原理与设计选型在动手之前我们必须先搞清楚Redis集群是怎么工作的。这决定了我们后续的配置和运维思路。2.1 数据分片与哈希槽Hash Slot这是Redis集群最核心的设计。集群将整个数据空间划分为16384个槽slot编号从0到16383。每个键key通过一个CRC16校验和算法计算出一个16位的值然后对这个值取模16384来决定它属于哪个槽。为什么是16384个槽这是一个经典的权衡。槽的数量需要足够多以保证数据能相对均匀地分布到大量节点上同时节点间需要同步每个槽的映射信息即哪个槽在哪个节点上。槽的数量越多这个映射信息就越大节点间心跳包携带集群状态的体积就越大。1638416K个槽在压缩后其状态信息可以控制在一个合理的大小内同时也能满足绝大多数场景的分片需求。集群中的每个主节点Master负责处理一部分哈希槽。例如在一个三主三从的集群中可能这样分配主节点A负责槽 0 - 5460主节点B负责槽 5461 - 10922主节点C负责槽 10923 - 16383客户端连接集群时会获取一份“槽位-节点”映射表。当它要操作一个key时会先计算槽位然后直接连接到对应的主节点进行操作。如果客户端连接错了节点比如key的槽位在B节点但客户端连到了A节点A节点会返回一个“MOVED”重定向错误并告知正确的节点地址客户端会更新本地映射并重试。成熟的客户端驱动如Jedis、Lettuce都自动处理了这个过程对开发者透明。2.2 主从复制与高可用光有分片还不够如果某个主节点宕机它负责的那部分数据就不可用了。因此Redis集群为每个主节点配置了一个或多个从节点Slave。从节点通过异步复制的方式同步其主节点的数据。当某个主节点发生故障时集群会发起故障转移Failover集群中的其他主节点会检测到该节点下线。该主节点对应的从节点会竞选成为新的主节点。集群会更新槽位分配信息将故障主节点负责的槽位转移到新的主节点上。客户端在收到重定向错误后会连接到新的主节点。这个过程是自动的旨在保证服务的可用性。但需要注意由于复制是异步的在故障切换的瞬间可能会有少量数据丢失主节点宕机前未来得及同步到从节点的数据。2.3 集群总线Cluster Bus与Gossip协议集群节点之间并非孤立它们通过一个额外的TCP端口通常是服务端口10000如6379端口对应16379端口进行通信这个通道称为集群总线。节点间通过Gossip协议来传播集群的元数据包括各个节点的状态在线、下线、疑似下线。当前集群的槽位配置。故障转移的信息。每个节点都维护着整个集群的视图并通过定期PING/PONG消息来检测其他节点的存活状态。这种去中心化的 Gossip 协议使得集群具有很好的扩展性和容错性但也会带来一定的网络开销。注意在配置防火墙时必须同时开放服务端口如6379-6384和集群总线端口如16379-16384否则节点间无法通信集群将无法组建。这是新手搭建时最容易踩的坑。3. 环境准备与节点部署实操理论清楚了我们进入实战环节。我会在一个测试环境单台服务器模拟6个节点上演示生产环境只需将IP和端口分布到不同服务器即可。3.1 服务器与软件准备服务器规划为了演示方便我们在一台IP为10.1.11.64的CentOS 7服务器上创建6个Redis实例端口从6379到6384组成三主三从集群。软件准备我们需要Redis源码包。建议使用稳定版本这里以redis-6.2.6为例。# 进入常用软件目录下载Redis cd /opt wget http://download.redis.io/releases/redis-6.2.6.tar.gz3.2 编译安装RedisRedis是C写的需要编译。首先安装编译依赖。# 安装GCC等基础编译工具 yum -y install gcc-c centos-release-scl # 安装较新版本的GCC工具集Redis 6.x 可能需要更高版本的GCC yum -y install devtoolset-9-gcc devtoolset-9-gcc-c devtoolset-9-binutils # 临时启用新版本GCC scl enable devtoolset-9 bash # 永久生效可选建议在编译完成后恢复避免影响系统其他组件 echo source /opt/rh/devtoolset-9/enable /etc/profile source /etc/profile接下来解压并编译安装Redis。# 解压 tar -zxvf redis-6.2.6.tar.gz -C /opt/ cd /opt/redis-6.2.6 # 编译这个过程可能需要几分钟 make # 安装会将redis-server, redis-cli等可执行文件复制到/usr/local/bin/ make install为了方便使用可以创建软链接到/usr/bin/下。ln -s /opt/redis-6.2.6/src/redis-server /usr/bin/redis-server ln -s /opt/redis-6.2.6/src/redis-cli /usr/bin/redis-cli3.3 准备集群节点配置文件我们不希望6个实例的配置文件混在一起最好为每个节点建立独立目录。这是生产环境的最佳实践便于管理和维护。# 创建集群总目录和各个节点目录 mkdir -p /opt/redis-cluster cd /opt/redis-cluster mkdir node-6379 node-6380 node-6381 node-6382 node-6383 node-6384现在我们需要一个基础的redis.conf模板。从源码包中复制一份默认配置并在此基础上修改。cp /opt/redis-6.2.6/redis.conf /opt/redis-cluster/编辑这个模板文件或者直接使用以下关键配置创建一个新的。我们重点关注集群相关的配置项。# 创建并编辑基础配置文件 cat /opt/redis-cluster/redis-base.conf EOF # 守护进程运行 daemonize yes # 关闭保护模式允许远程连接生产环境应结合bind和密码使用 protected-mode no # 绑定IP0.0.0.0表示监听所有网卡。生产环境建议绑定内网IP。 bind 0.0.0.0 # 服务端口这个值每个节点需要不同我们后续会动态设置 port 6379 # 设置访问密码所有节点建议使用相同密码 requirepass YourStrongPassword123 # 如果是从节点需要用它来连接主节点进行认证 masterauth YourStrongPassword123 # 启用集群模式 cluster-enabled yes # 集群节点配置文件由Redis自动生成和维护无需手动创建 cluster-config-file nodes.conf # 集群节点超时时间毫秒超时则认为节点下线 cluster-node-timeout 15000 # 集群从节点延迟迁移的最小因子保持默认即可 cluster-migration-barrier 1 # 内存淘汰策略当内存不足时 maxmemory-policy allkeys-lru # 日志文件路径 logfile /opt/redis-cluster/node-6379/redis.log # 数据持久化RDB文件名称 dbfilename dump.rdb # 数据目录 dir /opt/redis-cluster/node-6379/ # 进程ID文件 pidfile /var/run/redis_6379.pid EOF接下来为每个节点生成最终的配置文件。关键点在于修改port、logfile、dir、pidfile这几个与实例相关的路径。cd /opt/redis-cluster # 使用一个循环来生成6个节点的配置 for port in {6379..6384}; do # 复制基础配置到节点目录 cp redis-base.conf node-${port}/redis.conf # 使用sed命令替换端口和路径 sed -i s/port 6379/port ${port}/g node-${port}/redis.conf sed -i s|node-6379|node-${port}|g node-${port}/redis.conf sed -i s|redis_6379|redis_${port}|g node-${port}/redis.conf done现在检查一下node-6380的配置确认替换是否正确。cat /opt/redis-cluster/node-6380/redis.conf | grep -E port |logfile|dir|pidfile应该看到输出类似port 6380 logfile /opt/redis-cluster/node-6380/redis.log dir /opt/redis-cluster/node-6380/ pidfile /var/run/redis_6380.pid3.4 启动所有Redis节点配置文件准备好后逐个启动6个Redis实例。cd /opt/redis-cluster for port in {6379..6384}; do redis-server node-${port}/redis.conf done使用ps命令检查进程是否都正常启动。ps -aux | grep redis-server | grep -v grep你应该能看到6个redis-server进程分别监听不同的端口。实操心得启动后务必查看每个节点的日志文件确认没有报错。常见的错误包括端口被占用、目录权限不足、配置文件语法错误。日志是排查问题的第一手资料。tail -f /opt/redis-cluster/node-6379/redis.log4. 组建Redis集群与验证现在我们有6个独立的Redis实例在运行但它们还是“散兵游勇”我们需要用redis-cli的集群管理命令把它们组织成一个集群。4.1 使用create-cluster命令组建集群Redis 5.0之后redis-cli提供了--cluster create命令可以一键创建集群。命令会自动分配主从关系。我们需要指定所有节点的地址和端口以及副本因子--cluster-replicas 1表示每个主节点带1个从节点。redis-cli -a YourStrongPassword123 --cluster create \ 10.1.11.64:6379 10.1.11.64:6380 10.1.11.64:6381 \ 10.1.11.64:6382 10.1.11.64:6383 10.1.11.64:6384 \ --cluster-replicas 1执行这条命令后redis-cli会给出一个它规划好的主从分配方案。务必仔细看它会显示类似下面的信息 Performing hash slots allocation on 6 nodes... Master[0] - Slots 0 - 5460 Master[1] - Slots 5461 - 10922 Master[2] - Slots 10923 - 16383 Adding replica 10.1.11.64:6383 to 10.1.11.64:6379 Adding replica 10.1.11.64:6384 to 10.1.11.64:6380 Adding replica 10.1.11.64:6382 to 10.1.11.64:6381 ... Can I set the above configuration? (type yes to accept):这里清晰地展示了三个主节点6379, 6380, 6381分别负责一段哈希槽。三个从节点6383是6379的从6384是6380的从6382是6381的从。 确认无误后输入yes并回车。集群就会开始创建节点间会开始握手、分配槽位、建立主从复制关系。4.2 验证集群状态创建完成后我们可以用几个命令来验证集群是否健康。1. 检查集群节点信息redis-cli -a YourStrongPassword123 -c -p 6379 cluster nodes-c参数表示以集群模式连接会自动处理重定向。这条命令会输出所有节点的详细信息包括节点ID、IP端口、角色master/slave、负责的槽位、连接状态等。一个健康的集群所有节点的connected状态都应该是正常的。2. 检查集群状态redis-cli -a YourStrongPassword123 -c -p 6379 cluster info重点关注cluster_state:ok和cluster_slots_assigned:16384。前者表示集群状态正常后者表示16384个槽位都已分配完毕。3. 进行简单的数据读写测试# 连接集群任一节点 redis-cli -a YourStrongPassword123 -c -p 6379 # 在CLI中设置几个值观察重定向 127.0.0.1:6379 set key1 value1 - Redirected to slot [9189] located at 10.1.11.64:6380 OK 10.1.0.64:6380 set key2 value2 - Redirected to slot [4998] located at 10.1.11.64:6379 OK 10.1.0.64:6379 get key1 - Redirected to slot [9189] located at 10.1.11.64:6380 value1你可以看到客户端根据key计算的槽位自动跳转到了正确的节点上执行命令。4.3 防火墙配置关键步骤如果你的服务器开启了防火墙如firewalld必须放行Redis的服务端口和集群总线端口。# 放行Redis服务端口范围 firewall-cmd --permanent --add-port6379-6384/tcp # 放行集群总线端口范围服务端口10000 firewall-cmd --permanent --add-port16379-16384/tcp # 重新加载防火墙规则 firewall-cmd --reload重要提示很多人在单机测试时没问题一到多机部署就发现集群组建失败根本原因就是集群总线端口被防火墙阻断节点间无法进行Gossip通信。这是跨服务器部署时必须检查的一步。5. 集群管理与运维核心操作集群搭建起来只是开始日常运维才是重头戏。下面这些命令和场景你必须熟悉。5.1 节点管理查看集群节点信息前面已经用过cluster nodes这是最常用的命令。添加新主节点假设我们要添加一个端口为6385的新主节点。启动新的Redis实例配置cluster-enabled yes。使用--cluster add-node命令将其加入集群此时它是一个“空节点”不持有任何槽。redis-cli -a YourStrongPassword123 --cluster add-node 10.1.11.64:6385 10.1.11.64:6379为新节点重新分片Reshard从现有节点中迁移一部分槽给它。redis-cli -a YourStrongPassword123 --cluster reshard 10.1.11.64:6385命令会交互式地询问你要迁移多少槽、从哪些节点迁移、目标节点ID等。添加新从节点假设我们要为端口6385的主节点添加一个端口为6386的从节点。redis-cli -a YourStrongPassword123 --cluster add-node 10.1.11.64:6386 10.1.11.64:6379 --cluster-slave --cluster-master-id 目标主节点的ID目标主节点的ID可以通过cluster nodes命令查看。移除节点移除一个节点前必须确保它是空的不持有任何槽。对于从节点可以直接移除对于主节点需要先将其槽位迁移到其他节点。redis-cli -a YourStrongPassword123 --cluster del-node 10.1.11.64:6379 要删除的节点ID5.2 槽位迁移与重新平衡随着数据增长可能会出现某个主节点负载过高的情况。这时需要手动进行槽位迁移使数据分布更均匀。redis-cli -a YourStrongPassword123 --cluster rebalance 10.1.11.64:6379 --cluster-threshold 1--cluster-threshold 1表示只要节点间槽位数量差异超过1个就触发平衡。执行后集群会自动计算并执行槽位迁移计划。你也可以使用--cluster reshard进行更精细的手动迁移指定源节点、目标节点和迁移槽的数量。5.3 故障模拟与恢复高可用是集群的核心价值我们来模拟一下主节点宕机。模拟主节点故障我们手动 kill 掉端口6379的主节点进程。# 找到6379的进程ID并杀死 kill -9 cat /var/run/redis_6379.pid观察故障转移等待大约15秒cluster-node-timeout设置的时间然后检查集群状态。redis-cli -a YourStrongPassword123 -c -p 6380 cluster nodes | grep -E (6379|6383)你会发现原来作为6379从节点的6383节点其角色role已经从slave变成了master。而6379节点的状态可能变为fail。恢复旧主节点重新启动6379节点。redis-server /opt/redis-cluster/node-6379/redis.conf检查节点状态再次查看节点信息你会发现6379节点重新加入集群但它的角色变成了6383的从节点slave。这是因为故障转移后6383晋升为主节点当旧主6379恢复时会自动成为新主6383的从节点。这是符合预期的行为保证了数据的一致性。实操心得故障转移后原主节点“降级”为从节点这在生产环境是正常且安全的。如果你希望恢复原有的主从结构可以手动进行“故障恢复”Failover在6383节点上执行CLUSTER FAILOVER命令需要连接其从节点6379来执行但这会引发一次主从切换需在业务低峰期进行。6. 客户端连接与生产环境最佳实践集群搭好了最终是要给应用程序用的。这里有几个关键点。6.1 客户端连接配置不要再用连接单机Redis的方式了。以Java的Lettuce客户端为例# Spring Boot 配置示例 spring: redis: cluster: nodes: - 10.1.11.64:6379 - 10.1.11.64:6380 - 10.1.11.64:6381 - 10.1.11.64:6382 - 10.1.11.64:6383 - 10.1.11.64:6384 max-redirects: 3 # 最大重定向次数 password: YourStrongPassword123 lettuce: pool: max-active: 8 max-idle: 8 min-idle: 0客户端只需要配置集群中部分节点的地址即可启动后它会自动获取完整的集群拓扑。密码只需配置一个要求所有节点密码一致。6.2 生产环境配置建议内存规划为主节点配置maxmemory。不要用光所有物理内存留出一些给操作系统和其他进程。maxmemory-policy根据业务选择缓存场景常用allkeys-lru或volatile-lru。持久化集群模式下RDB和AOF持久化依然重要它们用于节点重启后的数据恢复。建议同时开启RDB和AOFappendonly yes。注意从节点的持久化配置应与主节点一致。安全一定要设置强密码requirepass和masterauth。生产环境应将bind绑定到内网IP而非0.0.0.0。考虑使用SSL/TLS加密传输Redis 6.0支持。监控使用redis-cli --cluster info和redis-cli --cluster check定期检查集群健康度。集成专业的监控系统如Prometheus Grafana使用redis_exporter监控内存、连接数、命中率、延迟、集群状态等关键指标。备份定期对集群进行备份。可以备份每个节点的RDB和AOF文件或者使用redis-cli --cluster backup命令需结合第三方工具或脚本。6.3 集群的限制与注意事项Redis集群并非银弹它有自己的限制不支持多数据库集群模式下只能使用db 0。事务限制事务MULTI/EXEC中的命令必须落在同一个节点即同一个哈希槽否则会报错。可以使用哈希标签Hash Tag来强制多个key分配到同一个槽。批量操作限制像MSET、MGET这样的批量命令也要求所有key在同一个槽。同样可以用哈希标签解决。Lua脚本脚本中操作的所有key也必须位于同一个节点。键的批量迁移对于已存在的、分布在不同节点的海量数据迁移到集群比较麻烦通常需要借助redis-cli --cluster import或编写迁移脚本。哈希标签的使用示例假设我们想将user:1000:profile和user:1000:orders这两个key存储到同一个节点以便在事务中一起操作。我们可以使用花括号{}来定义标签只有花括号内的部分会被用于计算槽位。# 这两个key都会被计算 {user:1000} 的哈希值从而分配到同一个槽。 set {user:1000}:profile xxx set {user:1000}:orders yyy7. 常见问题排查与实战技巧最后分享一些我踩过的坑和解决问题的思路。7.1 集群组建失败症状执行--cluster create时卡住或报错提示Waiting for the cluster to join超时。排查检查防火墙这是最常见的原因。确保所有节点的服务端口和集群总线端口10000都在所有节点间的防火墙上双向开放。检查节点配置确认每个节点的redis.conf中cluster-enabled设为yesbind地址正确protected-mode根据网络环境设置内网可关公网必须开且配密码。检查节点进程确保所有节点都已成功启动无报错。查看各自的日志文件。清理旧数据如果之前创建集群失败各节点目录下会生成nodes.conf和dump.rdb等文件。再次创建前最好停止所有节点删除这些文件尤其是nodes.conf再重新启动节点和创建集群。7.2 客户端读写报错症状客户端报MOVED或ASK错误或者直接报CLUSTERDOWN。排查MOVED错误是正常的重定向说明客户端缓存的槽位映射过期了成熟的客户端驱动会自动处理。如果频繁出现检查客户端驱动版本是否过旧。ASK错误发生在槽位迁移过程中是临时重定向客户端也应能处理。CLUSTERDOWN表示集群状态异常。立即用cluster info检查cluster_state。如果不是ok说明有主节点下线且没有可用的从节点接替导致部分槽位不可用。需要检查节点状态手动介入恢复。7.3 内存不足与性能问题症状响应变慢或出现OOM command not allowed when used memory maxmemory错误。处理监控分析使用redis-cli --bigkeys分析大Key使用redis-cli --memkeys分析内存消耗模式。大Key如一个Hash里有百万字段会严重阻塞集群因为Redis是单线程的。优化数据结构拆分大Key使用更高效的数据结构。调整淘汰策略根据业务场景调整maxmemory-policy。如果是纯缓存用allkeys-lru如果数据有持久化需求用volatile-lru并给Key设置TTL。扩容如果数据量持续增长考虑增加新的主节点并进行槽位迁移分摊内存和CPU压力。7.4 主从同步延迟症状主节点写入后从节点读取不到最新数据。理解Redis主从复制是异步的存在毫秒到秒级的延迟这是为了性能做的权衡。在故障转移时这部分延迟内的数据可能会丢失。应对对数据一致性要求极高的场景可以考虑使用Redis的WAIT命令但它会牺牲性能。更常见的做法是在业务层面对“最终一致性”有容忍度或者通过其他机制如消息队列来补偿。搭建和维护一个健壮的Redis集群远不止执行几条命令那么简单。它要求你对分布式原理有清晰的认识对运维细节有十足的耐心。从节点的规划、配置的标准化、监控告警的建立到故障预案的演练每一步都至关重要。希望这篇从原理到实战的长文能成为你构建稳定缓存体系的一块坚实基石。在实际操作中多看日志多用cluster nodes和cluster info命令观察状态遇到问题先理清脉络大部分难题都能迎刃而解。
Redis集群部署与运维实战：从原理到高可用架构搭建
发布时间：2026/6/17 23:44:32
1. 项目概述为什么我们需要Redis集群如果你用过Redis大概率会为它的速度着迷。但单机Redis再快也有它的天花板内存容量有限、单点故障风险、网络带宽瓶颈。当你的应用从一个小型博客成长为一个日活百万的平台缓存击穿、雪崩、单点宕机这些问题就会像定时炸弹一样冒出来。这时候Redis集群Redis Cluster就不再是一个“可选项”而是一个“必选项”。简单来说Redis集群是一种将数据自动分片Sharding到多个Redis节点并提供高可用性High Availability的分布式解决方案。它允许你横向扩展用多台机器的内存和计算资源来承载更大的数据量和更高的并发请求。今天我就结合自己多次在生产环境搭建和维护Redis集群的经验从零开始手把手带你走一遍Redis集群的完整部署、配置和核心运维流程。无论你是运维工程师、后端开发还是对分布式系统感兴趣的技术人这篇万字长文都能让你对Redis集群有一个透彻的理解并能独立完成部署。2. 集群架构核心原理与设计选型在动手之前我们必须先搞清楚Redis集群是怎么工作的。这决定了我们后续的配置和运维思路。2.1 数据分片与哈希槽Hash Slot这是Redis集群最核心的设计。集群将整个数据空间划分为16384个槽slot编号从0到16383。每个键key通过一个CRC16校验和算法计算出一个16位的值然后对这个值取模16384来决定它属于哪个槽。为什么是16384个槽这是一个经典的权衡。槽的数量需要足够多以保证数据能相对均匀地分布到大量节点上同时节点间需要同步每个槽的映射信息即哪个槽在哪个节点上。槽的数量越多这个映射信息就越大节点间心跳包携带集群状态的体积就越大。1638416K个槽在压缩后其状态信息可以控制在一个合理的大小内同时也能满足绝大多数场景的分片需求。集群中的每个主节点Master负责处理一部分哈希槽。例如在一个三主三从的集群中可能这样分配主节点A负责槽 0 - 5460主节点B负责槽 5461 - 10922主节点C负责槽 10923 - 16383客户端连接集群时会获取一份“槽位-节点”映射表。当它要操作一个key时会先计算槽位然后直接连接到对应的主节点进行操作。如果客户端连接错了节点比如key的槽位在B节点但客户端连到了A节点A节点会返回一个“MOVED”重定向错误并告知正确的节点地址客户端会更新本地映射并重试。成熟的客户端驱动如Jedis、Lettuce都自动处理了这个过程对开发者透明。2.2 主从复制与高可用光有分片还不够如果某个主节点宕机它负责的那部分数据就不可用了。因此Redis集群为每个主节点配置了一个或多个从节点Slave。从节点通过异步复制的方式同步其主节点的数据。当某个主节点发生故障时集群会发起故障转移Failover集群中的其他主节点会检测到该节点下线。该主节点对应的从节点会竞选成为新的主节点。集群会更新槽位分配信息将故障主节点负责的槽位转移到新的主节点上。客户端在收到重定向错误后会连接到新的主节点。这个过程是自动的旨在保证服务的可用性。但需要注意由于复制是异步的在故障切换的瞬间可能会有少量数据丢失主节点宕机前未来得及同步到从节点的数据。2.3 集群总线Cluster Bus与Gossip协议集群节点之间并非孤立它们通过一个额外的TCP端口通常是服务端口10000如6379端口对应16379端口进行通信这个通道称为集群总线。节点间通过Gossip协议来传播集群的元数据包括各个节点的状态在线、下线、疑似下线。当前集群的槽位配置。故障转移的信息。每个节点都维护着整个集群的视图并通过定期PING/PONG消息来检测其他节点的存活状态。这种去中心化的 Gossip 协议使得集群具有很好的扩展性和容错性但也会带来一定的网络开销。注意在配置防火墙时必须同时开放服务端口如6379-6384和集群总线端口如16379-16384否则节点间无法通信集群将无法组建。这是新手搭建时最容易踩的坑。3. 环境准备与节点部署实操理论清楚了我们进入实战环节。我会在一个测试环境单台服务器模拟6个节点上演示生产环境只需将IP和端口分布到不同服务器即可。3.1 服务器与软件准备服务器规划为了演示方便我们在一台IP为10.1.11.64的CentOS 7服务器上创建6个Redis实例端口从6379到6384组成三主三从集群。软件准备我们需要Redis源码包。建议使用稳定版本这里以redis-6.2.6为例。# 进入常用软件目录下载Redis cd /opt wget http://download.redis.io/releases/redis-6.2.6.tar.gz3.2 编译安装RedisRedis是C写的需要编译。首先安装编译依赖。# 安装GCC等基础编译工具 yum -y install gcc-c centos-release-scl # 安装较新版本的GCC工具集Redis 6.x 可能需要更高版本的GCC yum -y install devtoolset-9-gcc devtoolset-9-gcc-c devtoolset-9-binutils # 临时启用新版本GCC scl enable devtoolset-9 bash # 永久生效可选建议在编译完成后恢复避免影响系统其他组件 echo source /opt/rh/devtoolset-9/enable /etc/profile source /etc/profile接下来解压并编译安装Redis。# 解压 tar -zxvf redis-6.2.6.tar.gz -C /opt/ cd /opt/redis-6.2.6 # 编译这个过程可能需要几分钟 make # 安装会将redis-server, redis-cli等可执行文件复制到/usr/local/bin/ make install为了方便使用可以创建软链接到/usr/bin/下。ln -s /opt/redis-6.2.6/src/redis-server /usr/bin/redis-server ln -s /opt/redis-6.2.6/src/redis-cli /usr/bin/redis-cli3.3 准备集群节点配置文件我们不希望6个实例的配置文件混在一起最好为每个节点建立独立目录。这是生产环境的最佳实践便于管理和维护。# 创建集群总目录和各个节点目录 mkdir -p /opt/redis-cluster cd /opt/redis-cluster mkdir node-6379 node-6380 node-6381 node-6382 node-6383 node-6384现在我们需要一个基础的redis.conf模板。从源码包中复制一份默认配置并在此基础上修改。cp /opt/redis-6.2.6/redis.conf /opt/redis-cluster/编辑这个模板文件或者直接使用以下关键配置创建一个新的。我们重点关注集群相关的配置项。# 创建并编辑基础配置文件 cat /opt/redis-cluster/redis-base.conf EOF # 守护进程运行 daemonize yes # 关闭保护模式允许远程连接生产环境应结合bind和密码使用 protected-mode no # 绑定IP0.0.0.0表示监听所有网卡。生产环境建议绑定内网IP。 bind 0.0.0.0 # 服务端口这个值每个节点需要不同我们后续会动态设置 port 6379 # 设置访问密码所有节点建议使用相同密码 requirepass YourStrongPassword123 # 如果是从节点需要用它来连接主节点进行认证 masterauth YourStrongPassword123 # 启用集群模式 cluster-enabled yes # 集群节点配置文件由Redis自动生成和维护无需手动创建 cluster-config-file nodes.conf # 集群节点超时时间毫秒超时则认为节点下线 cluster-node-timeout 15000 # 集群从节点延迟迁移的最小因子保持默认即可 cluster-migration-barrier 1 # 内存淘汰策略当内存不足时 maxmemory-policy allkeys-lru # 日志文件路径 logfile /opt/redis-cluster/node-6379/redis.log # 数据持久化RDB文件名称 dbfilename dump.rdb # 数据目录 dir /opt/redis-cluster/node-6379/ # 进程ID文件 pidfile /var/run/redis_6379.pid EOF接下来为每个节点生成最终的配置文件。关键点在于修改port、logfile、dir、pidfile这几个与实例相关的路径。cd /opt/redis-cluster # 使用一个循环来生成6个节点的配置 for port in {6379..6384}; do # 复制基础配置到节点目录 cp redis-base.conf node-${port}/redis.conf # 使用sed命令替换端口和路径 sed -i s/port 6379/port ${port}/g node-${port}/redis.conf sed -i s|node-6379|node-${port}|g node-${port}/redis.conf sed -i s|redis_6379|redis_${port}|g node-${port}/redis.conf done现在检查一下node-6380的配置确认替换是否正确。cat /opt/redis-cluster/node-6380/redis.conf | grep -E port |logfile|dir|pidfile应该看到输出类似port 6380 logfile /opt/redis-cluster/node-6380/redis.log dir /opt/redis-cluster/node-6380/ pidfile /var/run/redis_6380.pid3.4 启动所有Redis节点配置文件准备好后逐个启动6个Redis实例。cd /opt/redis-cluster for port in {6379..6384}; do redis-server node-${port}/redis.conf done使用ps命令检查进程是否都正常启动。ps -aux | grep redis-server | grep -v grep你应该能看到6个redis-server进程分别监听不同的端口。实操心得启动后务必查看每个节点的日志文件确认没有报错。常见的错误包括端口被占用、目录权限不足、配置文件语法错误。日志是排查问题的第一手资料。tail -f /opt/redis-cluster/node-6379/redis.log4. 组建Redis集群与验证现在我们有6个独立的Redis实例在运行但它们还是“散兵游勇”我们需要用redis-cli的集群管理命令把它们组织成一个集群。4.1 使用create-cluster命令组建集群Redis 5.0之后redis-cli提供了--cluster create命令可以一键创建集群。命令会自动分配主从关系。我们需要指定所有节点的地址和端口以及副本因子--cluster-replicas 1表示每个主节点带1个从节点。redis-cli -a YourStrongPassword123 --cluster create \ 10.1.11.64:6379 10.1.11.64:6380 10.1.11.64:6381 \ 10.1.11.64:6382 10.1.11.64:6383 10.1.11.64:6384 \ --cluster-replicas 1执行这条命令后redis-cli会给出一个它规划好的主从分配方案。务必仔细看它会显示类似下面的信息 Performing hash slots allocation on 6 nodes... Master[0] - Slots 0 - 5460 Master[1] - Slots 5461 - 10922 Master[2] - Slots 10923 - 16383 Adding replica 10.1.11.64:6383 to 10.1.11.64:6379 Adding replica 10.1.11.64:6384 to 10.1.11.64:6380 Adding replica 10.1.11.64:6382 to 10.1.11.64:6381 ... Can I set the above configuration? (type yes to accept):这里清晰地展示了三个主节点6379, 6380, 6381分别负责一段哈希槽。三个从节点6383是6379的从6384是6380的从6382是6381的从。 确认无误后输入yes并回车。集群就会开始创建节点间会开始握手、分配槽位、建立主从复制关系。4.2 验证集群状态创建完成后我们可以用几个命令来验证集群是否健康。1. 检查集群节点信息redis-cli -a YourStrongPassword123 -c -p 6379 cluster nodes-c参数表示以集群模式连接会自动处理重定向。这条命令会输出所有节点的详细信息包括节点ID、IP端口、角色master/slave、负责的槽位、连接状态等。一个健康的集群所有节点的connected状态都应该是正常的。2. 检查集群状态redis-cli -a YourStrongPassword123 -c -p 6379 cluster info重点关注cluster_state:ok和cluster_slots_assigned:16384。前者表示集群状态正常后者表示16384个槽位都已分配完毕。3. 进行简单的数据读写测试# 连接集群任一节点 redis-cli -a YourStrongPassword123 -c -p 6379 # 在CLI中设置几个值观察重定向 127.0.0.1:6379 set key1 value1 - Redirected to slot [9189] located at 10.1.11.64:6380 OK 10.1.0.64:6380 set key2 value2 - Redirected to slot [4998] located at 10.1.11.64:6379 OK 10.1.0.64:6379 get key1 - Redirected to slot [9189] located at 10.1.11.64:6380 value1你可以看到客户端根据key计算的槽位自动跳转到了正确的节点上执行命令。4.3 防火墙配置关键步骤如果你的服务器开启了防火墙如firewalld必须放行Redis的服务端口和集群总线端口。# 放行Redis服务端口范围 firewall-cmd --permanent --add-port6379-6384/tcp # 放行集群总线端口范围服务端口10000 firewall-cmd --permanent --add-port16379-16384/tcp # 重新加载防火墙规则 firewall-cmd --reload重要提示很多人在单机测试时没问题一到多机部署就发现集群组建失败根本原因就是集群总线端口被防火墙阻断节点间无法进行Gossip通信。这是跨服务器部署时必须检查的一步。5. 集群管理与运维核心操作集群搭建起来只是开始日常运维才是重头戏。下面这些命令和场景你必须熟悉。5.1 节点管理查看集群节点信息前面已经用过cluster nodes这是最常用的命令。添加新主节点假设我们要添加一个端口为6385的新主节点。启动新的Redis实例配置cluster-enabled yes。使用--cluster add-node命令将其加入集群此时它是一个“空节点”不持有任何槽。redis-cli -a YourStrongPassword123 --cluster add-node 10.1.11.64:6385 10.1.11.64:6379为新节点重新分片Reshard从现有节点中迁移一部分槽给它。redis-cli -a YourStrongPassword123 --cluster reshard 10.1.11.64:6385命令会交互式地询问你要迁移多少槽、从哪些节点迁移、目标节点ID等。添加新从节点假设我们要为端口6385的主节点添加一个端口为6386的从节点。redis-cli -a YourStrongPassword123 --cluster add-node 10.1.11.64:6386 10.1.11.64:6379 --cluster-slave --cluster-master-id 目标主节点的ID目标主节点的ID可以通过cluster nodes命令查看。移除节点移除一个节点前必须确保它是空的不持有任何槽。对于从节点可以直接移除对于主节点需要先将其槽位迁移到其他节点。redis-cli -a YourStrongPassword123 --cluster del-node 10.1.11.64:6379 要删除的节点ID5.2 槽位迁移与重新平衡随着数据增长可能会出现某个主节点负载过高的情况。这时需要手动进行槽位迁移使数据分布更均匀。redis-cli -a YourStrongPassword123 --cluster rebalance 10.1.11.64:6379 --cluster-threshold 1--cluster-threshold 1表示只要节点间槽位数量差异超过1个就触发平衡。执行后集群会自动计算并执行槽位迁移计划。你也可以使用--cluster reshard进行更精细的手动迁移指定源节点、目标节点和迁移槽的数量。5.3 故障模拟与恢复高可用是集群的核心价值我们来模拟一下主节点宕机。模拟主节点故障我们手动 kill 掉端口6379的主节点进程。# 找到6379的进程ID并杀死 kill -9 cat /var/run/redis_6379.pid观察故障转移等待大约15秒cluster-node-timeout设置的时间然后检查集群状态。redis-cli -a YourStrongPassword123 -c -p 6380 cluster nodes | grep -E (6379|6383)你会发现原来作为6379从节点的6383节点其角色role已经从slave变成了master。而6379节点的状态可能变为fail。恢复旧主节点重新启动6379节点。redis-server /opt/redis-cluster/node-6379/redis.conf检查节点状态再次查看节点信息你会发现6379节点重新加入集群但它的角色变成了6383的从节点slave。这是因为故障转移后6383晋升为主节点当旧主6379恢复时会自动成为新主6383的从节点。这是符合预期的行为保证了数据的一致性。实操心得故障转移后原主节点“降级”为从节点这在生产环境是正常且安全的。如果你希望恢复原有的主从结构可以手动进行“故障恢复”Failover在6383节点上执行CLUSTER FAILOVER命令需要连接其从节点6379来执行但这会引发一次主从切换需在业务低峰期进行。6. 客户端连接与生产环境最佳实践集群搭好了最终是要给应用程序用的。这里有几个关键点。6.1 客户端连接配置不要再用连接单机Redis的方式了。以Java的Lettuce客户端为例# Spring Boot 配置示例 spring: redis: cluster: nodes: - 10.1.11.64:6379 - 10.1.11.64:6380 - 10.1.11.64:6381 - 10.1.11.64:6382 - 10.1.11.64:6383 - 10.1.11.64:6384 max-redirects: 3 # 最大重定向次数 password: YourStrongPassword123 lettuce: pool: max-active: 8 max-idle: 8 min-idle: 0客户端只需要配置集群中部分节点的地址即可启动后它会自动获取完整的集群拓扑。密码只需配置一个要求所有节点密码一致。6.2 生产环境配置建议内存规划为主节点配置maxmemory。不要用光所有物理内存留出一些给操作系统和其他进程。maxmemory-policy根据业务选择缓存场景常用allkeys-lru或volatile-lru。持久化集群模式下RDB和AOF持久化依然重要它们用于节点重启后的数据恢复。建议同时开启RDB和AOFappendonly yes。注意从节点的持久化配置应与主节点一致。安全一定要设置强密码requirepass和masterauth。生产环境应将bind绑定到内网IP而非0.0.0.0。考虑使用SSL/TLS加密传输Redis 6.0支持。监控使用redis-cli --cluster info和redis-cli --cluster check定期检查集群健康度。集成专业的监控系统如Prometheus Grafana使用redis_exporter监控内存、连接数、命中率、延迟、集群状态等关键指标。备份定期对集群进行备份。可以备份每个节点的RDB和AOF文件或者使用redis-cli --cluster backup命令需结合第三方工具或脚本。6.3 集群的限制与注意事项Redis集群并非银弹它有自己的限制不支持多数据库集群模式下只能使用db 0。事务限制事务MULTI/EXEC中的命令必须落在同一个节点即同一个哈希槽否则会报错。可以使用哈希标签Hash Tag来强制多个key分配到同一个槽。批量操作限制像MSET、MGET这样的批量命令也要求所有key在同一个槽。同样可以用哈希标签解决。Lua脚本脚本中操作的所有key也必须位于同一个节点。键的批量迁移对于已存在的、分布在不同节点的海量数据迁移到集群比较麻烦通常需要借助redis-cli --cluster import或编写迁移脚本。哈希标签的使用示例假设我们想将user:1000:profile和user:1000:orders这两个key存储到同一个节点以便在事务中一起操作。我们可以使用花括号{}来定义标签只有花括号内的部分会被用于计算槽位。# 这两个key都会被计算 {user:1000} 的哈希值从而分配到同一个槽。 set {user:1000}:profile xxx set {user:1000}:orders yyy7. 常见问题排查与实战技巧最后分享一些我踩过的坑和解决问题的思路。7.1 集群组建失败症状执行--cluster create时卡住或报错提示Waiting for the cluster to join超时。排查检查防火墙这是最常见的原因。确保所有节点的服务端口和集群总线端口10000都在所有节点间的防火墙上双向开放。检查节点配置确认每个节点的redis.conf中cluster-enabled设为yesbind地址正确protected-mode根据网络环境设置内网可关公网必须开且配密码。检查节点进程确保所有节点都已成功启动无报错。查看各自的日志文件。清理旧数据如果之前创建集群失败各节点目录下会生成nodes.conf和dump.rdb等文件。再次创建前最好停止所有节点删除这些文件尤其是nodes.conf再重新启动节点和创建集群。7.2 客户端读写报错症状客户端报MOVED或ASK错误或者直接报CLUSTERDOWN。排查MOVED错误是正常的重定向说明客户端缓存的槽位映射过期了成熟的客户端驱动会自动处理。如果频繁出现检查客户端驱动版本是否过旧。ASK错误发生在槽位迁移过程中是临时重定向客户端也应能处理。CLUSTERDOWN表示集群状态异常。立即用cluster info检查cluster_state。如果不是ok说明有主节点下线且没有可用的从节点接替导致部分槽位不可用。需要检查节点状态手动介入恢复。7.3 内存不足与性能问题症状响应变慢或出现OOM command not allowed when used memory maxmemory错误。处理监控分析使用redis-cli --bigkeys分析大Key使用redis-cli --memkeys分析内存消耗模式。大Key如一个Hash里有百万字段会严重阻塞集群因为Redis是单线程的。优化数据结构拆分大Key使用更高效的数据结构。调整淘汰策略根据业务场景调整maxmemory-policy。如果是纯缓存用allkeys-lru如果数据有持久化需求用volatile-lru并给Key设置TTL。扩容如果数据量持续增长考虑增加新的主节点并进行槽位迁移分摊内存和CPU压力。7.4 主从同步延迟症状主节点写入后从节点读取不到最新数据。理解Redis主从复制是异步的存在毫秒到秒级的延迟这是为了性能做的权衡。在故障转移时这部分延迟内的数据可能会丢失。应对对数据一致性要求极高的场景可以考虑使用Redis的WAIT命令但它会牺牲性能。更常见的做法是在业务层面对“最终一致性”有容忍度或者通过其他机制如消息队列来补偿。搭建和维护一个健壮的Redis集群远不止执行几条命令那么简单。它要求你对分布式原理有清晰的认识对运维细节有十足的耐心。从节点的规划、配置的标准化、监控告警的建立到故障预案的演练每一步都至关重要。希望这篇从原理到实战的长文能成为你构建稳定缓存体系的一块坚实基石。在实际操作中多看日志多用cluster nodes和cluster info命令观察状态遇到问题先理清脉络大部分难题都能迎刃而解。
相关文章
深入UDS诊断会话控制(0x10) ———— 从Default到Extended的切换艺术
1. 为什么需要诊断会话切换？ 第一次接触汽车诊断协议的朋友，可能会好奇：为什么要有这么多会话模式？直接用一个模式搞定所有功能不就好了吗？这个问题我也曾经困惑过，直到在实际项目中踩了几个坑才明白其中的…
角色动画设计实战：从关键帧到动作捕捉的完整工作流
1. 项目概述：从“艾莉练剑”看角色驱动的专项技能训练 最近在和一些做游戏角色设计、动作捕捉的朋友聊天，以及看到不少独立游戏开发者和动画爱好者在社区里讨论，大家常常会聚焦于一个具体而微的场景：如何让一个虚拟角色࿰…
深入解析SCI串行通信接口：从波特率生成到多机通信实战
1. 项目概述：深入理解异步串行通信的基石在嵌入式系统开发中，设备间的数据交换是永恒的主题。无论是微控制器与传感器对话，还是两块电路板之间传递指令，一种经典、可靠且被广泛采用的通信方式就是异步串行通信。而实现这一通信协议…
【前端手撕】call
call是改变this指向的方法，传入的参数是要指向的对象和函数需要的参数序列。改变this指向还可以用apply和bind，区别如下：方法传参方式执行时机返回值call参数序列（逐个传入）立即执行函数执行的结果apply参数数组&#…
Navicat密码解密终极指南：如何快速找回遗忘的数据库密码
Navicat密码解密终极指南：如何快速找回遗忘的数据库密码 【免费下载链接】navicat_password_decrypt 忘记navicat密码时,此工具可以帮您查看密码 项目地址: https://gitcode.com/gh_mirrors/na/navicat_password_decrypt 你是否曾经面临这样的尴尬时刻&#…
3步快速解决华硕笔记本色彩配置文件丢失问题：G-Helper免费修复指南
3步快速解决华硕笔记本色彩配置文件丢失问题：G-Helper免费修复指南 【免费下载链接】g-helper Lightweight Armoury Crate alternative for Asus laptops with nearly the same functionality. Works with ROG Zephyrus, Flow, TUF, Strix, Scar, ProArt, Vivobook,…
实例分享：三种算法的实际应用
一般来说，每种算法都有着复杂的理论背景，但实现起来却相对简单，它们在实际应用中也具有广泛的应用价值。K-Means它可以用来帮助市场制定营销策略，进行市场划分；又或是图像分割、文本聚类。快速傅里叶变换算法它可以用于…
四旋翼无人机仿真simulink仿真四旋翼自抗扰 姿态控1(设计源文件+万字报告+讲解)（支持资料、图片参考_相关定制）_文章底部可以扫码
四旋翼无人机仿真simulink仿真四旋翼自抗扰 姿态控1(设计源文件万字报告讲解)（支持资料、图片参考_相关定制）_文章底部可以扫码 四旋翼无人机仿真simulink仿真四旋翼自抗扰 姿态控制仿真模型 提供报告
【无人机控制】基于matlab LQR和PSO的无人机舰队分散控制系统设计【含Matlab源码 15634期】含报告
💥💥💥💥💥💥💞💞💞💞💞💞💞💞欢迎来到海神之光博客之家💞💞💞Ὁ…
Java毕设选题推荐：基于 Spring Boot 的个人随笔博客运维管理系统的设计与实现 基于 Spring Boot 的用户原创博客分享社区【附源码、mysql、文档、调试+代码讲解+全bao等】
博主介绍：✌️码农一枚 ，专注于大学生项目实战开发、讲解和毕业🚢文撰写修改等。全栈领域优质创作者，博客之星、掘金/华为云/阿里云/InfoQ等平台优质作者、专注于Java、小程序技术领域和毕业项目实战 ✌️技术范围：&am…
【IC】【Low Power】从功耗构成到设计实践：CMOS低功耗技术全景解析
1. CMOS电路功耗构成解析 在芯片设计中，功耗就像汽车的油耗指标，直接影响着设备的续航能力和发热表现。想象一下你的手机如果功耗控制不好，可能用不了半天就得充电，还会烫得像暖手宝。CMOS电路的功耗主要来自两个"耗电大户&q…
跨平台音乐播放神器：LX Music桌面版一站式解决多平台音乐聚合难题
跨平台音乐播放神器：LX Music桌面版一站式解决多平台音乐聚合难题 【免费下载链接】lx-music-desktop 一个基于 Electron 的音乐软件 项目地址: https://gitcode.com/GitHub_Trending/lx/lx-music-desktop 你是否厌倦了在不同音乐平台间来回切换？…
音乐文件解锁实战指南：3个场景解决你的播放困境
音乐文件解锁实战指南：3个场景解决你的播放困境 【免费下载链接】unlock-music 在浏览器中解锁加密的音乐文件。原仓库： 1. https://github.com/unlock-music/unlock-music ；2. https://git.unlock-music.dev/um/web 项目地址: https://git…
从Landsat到高分系列：手把手教你选择适合自己项目的遥感卫星数据
遥感卫星数据选型实战指南：从参数解析到场景化应用当面对GEE、PIE-Engine等云平台上数十种遥感数据源时，许多研究者常陷入选择困难——Landsat的历史连续性、Sentinel-2的红边波段优势、高分系列的亚米级分辨率各有千秋。本文将打破常规参数罗列式对比&a…
MC68302 AutoBaud技术：硬件级串口波特率自动检测原理与实现
1. 项目概述：MC68302 AutoBaud技术深度解析在嵌入式系统开发，尤其是那些需要与外部设备进行串口通信的场景里，最让人头疼的环节之一就是波特率匹配。想象一下，你设计了一个数据采集终端，需要连接来自不同厂家、不同年代…
Zotero Duplicates Merger：5步彻底清理文献库重复条目
Zotero Duplicates Merger：5步彻底清理文献库重复条目 【免费下载链接】ZoteroDuplicatesMerger A zotero plugin to automatically merge duplicate items 项目地址: https://gitcode.com/gh_mirrors/zo/ZoteroDuplicatesMerger 还在为文献库中堆积如山的重…
利用随机有限集理论对蜂群的ILQR和MPC控制研究附Matlab代码
✅作者简介：热爱科研的Matlab仿真开发者，擅长数据处理、建模仿真、程序设计、完整代码获取、论文复现及科研仿真。🍎 往期回顾关注个人主页：Matlab科研工作室🍊个人信条：格物致知,完整Matlab代码及仿真咨询…
为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因
更多请点击： https://intelliparadigm.com 第一章：为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因 Gemini邮件的客户转化效率（CTE）显著偏低，根本原因常被误判为…