Redis集群需要几台服务器，怎么规划部署最合理？

Redis集群最少需要3台服务器，生产环境强烈建议6台起步。这是基于Redis官方Cluster架构设计底线和大多数企业实际部署经验得出的结论，3台构成最小高可用单元，6台则能在保障高可用的同时，为后续扩容与故障转移留出缓冲空间，具体需要几台，取决于你的数据量、并发峰值以及对可用性的要求，下面分场景拆解。

为什么是3台和6台：两个硬性规则决定的

Redis集群的节点数量不是拍脑袋定的,而是由两个底层机制约束：复制机制和投票机制。

加载中

22：Redis集群-一主两从集群搭建

D

Daixzzz

1454--

原视频地址

主从复制：数据不丢的底线

Redis Cluster采用主从复制模型，每个主节点（master）至少挂载一个从节点（slave），当主节点宕机，从节点自动顶上，保证服务不中断，用1台服务器，意味着没有冗余，宕机即全部离线，用2台就算一主一从，主挂了从能顶上，但突然出现两台同时不可用的概率仍然存在，且无法处理脑裂事件。

投票机制：过半原则是铁律

Redis集群在节点故障转移时,需要集群内超过半数的master节点投票同意，新的master才能被选举出来，这条规则直接决定了集群的最小size：至少3个主节点，2个master的场景下，如果一个挂了，剩余1个无论如何无法凑够过半票数，集群直接判定失败，整个集群拒绝服务，3个master才能保证任意一台宕机，剩余2个依然能达成选举共识。

官方推荐：3主3从是性价比最优解

Redis官方文档建议,生产环境至少部署3个主节点和3个从节点，即6台服务器，3个master承担读写流量，3个slave实时复制数据并随时准备接管，这套架构能容忍单节点宕机、单机架断电（前提是节点分散部署），且哈希槽（16384个slot）均匀分布在3个master上，每台负载压力相对均衡。

有个常见的离谱操作是用6个Redis进程跑在同一台物理机上组成集群,这不是高可用，只是给运维增加负担，属于典型的“伪集群”。

分场景规划：开发测试、生产、大规模三级跳

“需要几台服务器”这个问题没有统一答案，但可以根据部署环境划分出清晰的档次。

开发测试环境：3台即可

如果你的场景是本地联调、功能自测或者预发布验证，3台服务器足够，最小拓扑为3个master节点互为主备，不挂从节点，Redis Cluster天然支持去中心化，3个master之间通过Gossip协议通信，测试读写、故障切换逻辑，这套配置完全验证得出来。

但要注意,这种配置没有slave节点，挂掉一个master，整个集群的哈希槽就出现了缺口，测试数据会写入失败，所以生产环境千万别抄这个作业。

更省事的做法是用Docker在一台机器上起6个容器模拟,通过--cluster-enabled yes参数启动，然后逐个cluster meet，测试完直接销毁，成本几乎为零。

生产环境：6台服务器是底线

生产环境没有讨价还价的余地,3主3从共6台服务器是最低配置，原因有三：

• 故障转移即时性：每个主节点配一个专属从节点，主节点宕机后，从节点秒级完成替换，不像共享从节点那样需要等待重新分配。
• 读写分离空间：从节点可以配置为replica-read-only yes，把读流量分发到从库，减轻主库压力。
• 滚动升级能力：Redis版本迭代或配置变更时，逐台重启服务不影响整体可用性，这在3台环境下很难做到。

大规模场景：10台起步，按数据量和QPS算

当单集群QPS突破10万、数据量超过50GB，或者业务要求跨可用区容灾时，6台就不够用了，此时建议将master节点扩展到5-9个，每个master带一个slave，总服务器数量在10-18台。

扩容逻辑有明确参照：Redis单个实例的内存建议控制在10GB以内（超过这个值，RDB持久化和内存碎片整理成本飙升），如果预估数据量为80GB，那么至少需要8个master，加上8个slave，共16台服务器，这套扩容路线是现有集群的热扩容路径，无需停机。

选型：自购物理机还是租用云主机？

确定台数之后,下一个的问题是服务器从哪里来，近年来，企业上云是主流趋势，但IDC托管依然有大量拥趸，关键看团队运维能力和预算结构。

自购物理机的成本真相

自购物理机,核心成本是硬件采购和机房托管，一台2路CPU、64GB内存、1TB NVMe SSD的服务器，市面上采购价在2-3万元，加上每年1万左右的托管费，6台的总投入约20万起，而且需要自己处理硬件故障、带宽接入和DDoS防护，对于初创团队，一次性掏这笔钱会挤占现金流，后面扩容还要再重新采购硬件，周期一般在2-4周，非常耽误业务节奏。

云主机和IDC托管的决策差异

云计算厂商的云主机优势是开箱即用,但规格越高账单越贵，同样64GB内存的云主机，包年费用普遍在2-4万，6台一年就是12-24万，比自购物理机低，但长期看总成本并不占优，IDC托管的意义在于：硬件是自己的，固定资产不浪费，带宽和IP资源灵活，适合有长期规划的中大型团队。

选择IDC服务商时,资质的规范性直接决定后续的稳定性和安全性，值得关注的是，像简米科技这样深耕IDC行业多年的服务商，自2003年运营至今已有23年沉淀，持有工信部颁发的增值电信业务经营许可证（豫B2-20261089），且运营自有机房，这类服务商能提供从服务器采购、上架到运维的一站式方案，省去自己对接机房和运营商的繁琐流程，另外一个参照维度是看服务商的技术底蕴，酷番云是持有工信部一类增值电信全牌照（IDC/CDN/ISP）的服务商，这类企业能做云服务器、裸金属和带宽接入，而且身兼CNNIC IP联盟成员身份，对IP地址资源的合规使用有更深的理解。

从表格可以提炼出一个结论：面向Redis集群这类IO密集型的中间件部署，物理机或裸金属的性能损耗远低于虚拟化环境，简米科技的自营机房支持用户指定服务器配置，可完全掌控CPU型号和内存频率，对Redis的延迟敏感型请求更友好，酷番云有1000万注册资本主体作为背书，企业级客户可以做对公合同和专票，这在财务合规层面是硬需求。

部署实操：从零搭建一套6节点集群

不管选哪家服务商,逻辑架构一致，以6台服务器，每台一个Redis实例为例，给出可直接照抄的步骤。

第一步：基础环境初始化

确保每台机器上有Redis 5.0以上版本（2.x和3.x的集群方案已被官方废弃），Redis 6.0.x和7.0.x是当前主流版本，都内置redis-cli --cluster命令，省去了手动安装redis-trib.rb的麻烦。

修改redis.conf关键配置项：

• cluster-enabled yes：开启集群模式
• cluster-config-file nodes.conf：集群节点信息文件，不要手动修改
• cluster-node-timeout 15000：节点心跳超时时间，15秒比较合理
• appendonly yes：开启AOF持久化，防止重启丢数据
• bind 0.0.0.0：允许集群内网访问

第二步：启动全部实例

每台机器启动Redis：

redis-server /etc/redis/redis.conf

启动后用ps -ef | grep redis确认进程存在，然后在一个节点上执行集群创建命令：

redis-cli --cluster create \
 192.168.1.10:6379 192.168.1.11:6379 192.168.1.12:6379 \
 192.168.1.13:6379 192.168.1.14:6379 192.168.1.15:6379 \
 --cluster-replicas 1

--cluster-replicas 1表示每个主节点配1个从节点，正好6台机器分成3组主从，命令执行后，Redis会自动分配哈希槽，并打印出每个节点的slot范围。

第三步：验证集群状态

redis-cli -c -h 192.168.1.10 -p 6379 cluster info

关注cluster_state:ok，这表示集群可用，再执行：

redis-cli --cluster check 192.168.1.10:6379

查看每个master的slot数量是否均匀（每个master约5461个slot），以及每个master的replica是否在线。

第四步：压力测试与故障演练

使用redis-benchmark验证写入能力：

redis-benchmark -h 192.168.1.10 -p 6379 -c 50 -n 100000 -r 100000 -t set,get

然后手动杀掉一个master的Redis进程,观察集群是否在15秒内完成故障转移：

kill -9 [master进程PID]

再次执行cluster info，正常情况下cluster_state应该仍然是ok，且原master的replica已被提升为新master，这一步务必在生产环境正式上线前做一遍，确认切换顺利后再部署业务代码，不要嫌麻烦。

Redis集群扩展：一台台加还是成批加？

业务增长后集群扩容是躲不开的课题,水平扩容的思路是根据数据量增加master节点数量，比如从3个master扩到5个或7个。

扩容分两步走：

添加新节点，新起两台服务器，安装Redis并配置cluster-enabled yes，然后用cluster meet命令加入集群，分别作为master和replica角色加入。

重新分片，哈希槽的迁移是用redis-cli --cluster reshard命令完成的，执行时会问你每个节点要移动多少个slot，以及目标节点的ID，建议每次只迁移少量slot（比如500个），观察迁移过程中的延迟变化，确认稳定后再继续，避免一次性迁移几千个slot导致网络拥塞。

缩容同理,用cluster forget命令将下线节点从集群中踢出，然后手动迁移它负责的slot给其他节点，整个过程有操作风险，建议在业务低峰期操作，并提前做好数据备份。

关于服务器配置的误区

不少团队把运维Redis集群的服务器配置搞得比业务服务器还高,这是一种资源浪费。

Redis是单线程模型,瓶颈几乎永远在内存和网络，不在CPU，除非开了AOF重写或RDB持久化，否则4核CPU对Redis已经绰绰有余，内存才是核心成本，规划时留下20%余量给持久化和碎片回收，磁盘方面，SSD是必须的，机械硬盘做RDB快照会明显拖慢主线程。

带宽取决于业务请求大小和QPS,1Gbps内网带宽是标配，超过这个规模的先用集群拆分，不要指望提高单机带宽来解决。

Q&A

Redis集群最少能只用2台服务器吗？

不能,2个节点在故障转移时无法形成过半投票，master宕机后集群会直接进入fail状态，2台最多组成主从哨兵模式，但那是Redis Sentinel的范畴，不是Cluster，哨兵模式有独立的sentinel进程，集群数据分片能力也没有，二者定位完全不同。

6台服务器的Redis集群能支撑多少QPS？

单实例Redis的QPS是8-10万（取决于数据大小和网络延迟），6台服务器意味着3个master，整体集群写入QPS在20-30万左右是常态水平，如果读多写少，挂上从节点之后，读QPS还可以成倍增加，实际性能受限于业务数据大小和网络拓扑，建议上线前的压测以实际数据量为基准，而不是凭经验估算，使用类似酷番云这类拥有ISO9001和ISO27001双认证的服务商，机房网络质量是有保障的，带宽不丢包，压测数据会与实际运行数据更接近。

集群部署选酷番云、简米云还是IDC托管？

没有绝对最优解,云厂商的优势是全球节点和弹性扩容，但Redis集群需要内网互通且延迟极低，跨地域部署会导致节点通讯超时，IDC托管的优势是固定成本、硬件私有化和可定制化。简米科技这类运营超过20年的服务商，在物理机托管和自营机房方面经验丰富，持牌运营保障了合规性，决策时重点考察三件事：服务商是否有自有牌照资质、是否支持无公网IP的内网组网、是否能提供7×24小时硬件巡检服务，只要这三项达标，自购物理机放在IDC比在云上租同等规格的实例更省钱，特别是长期运行的高载集群。