两个服务器共用一个Redis，核心方案是部署Redis集群模式（Cluster）或主从复制架构，让多个服务器共享同一份缓存数据，而非各自独立运行Redis实例。
现实中不少团队把Redis装在两台机器上各管各的,结果缓存命中率低、数据不一致，排查问题时两头跑，本文从架构选型到实际配置，讲清楚两个服务器怎么正确共用一个Redis。
两个服务器共用一个Redis的三种主流架构
两个服务器共用Redis,不是简单改配置文件就能搞定的事，需要根据业务场景选择合适架构，行业共识认为，绝大多数双服务器场景下，以下三种方案可以覆盖九成需求。
Redis主从复制架构
主从复制是最常用的方案,一台服务器运行Redis主节点负责写操作，另一台运行从节点实时同步主节点数据，读操作可以在从节点完成。
适合场景：读多写少、需要高可用保障的业务，当主节点宕机，从节点可以手动或自动提升为主节点，保证服务不中断。
架构特点：
- 数据实时单向同步,从节点不会反向写入主节点。
- 部署简单,不需要额外组件。
- 从节点可以做持久化备份,不阻塞主节点性能。
- 需要配置哨兵（Sentinel）实现自动故障转移。
Redis Cluster集群模式
Cluster模式将数据分片存储在两个服务器的多个Redis节点上,每个节点负责一部分数据槽位，两个服务器共用一个Redis集群，数据在服务器间分布存储，读写请求路由到对应节点。
适合场景：数据量大、写并发高、需要水平扩展的业务，Cluster模式天然支持多主多从，两个服务器上可以分别部署主节点和从节点交叉冗余。
架构特点：
- 数据自动分片,每个节点只存一部分数据。
- 每个主节点至少配一个从节点,交叉部署在两台服务器上。
- 客户端自动路由到正确节点,支持在线扩缩容。
- 只支持0号数据库,不支持多库操作。
跨服务器共享Redis网络方案
除上述两种,还有通过TCP/IP网络直接让两台应用服务器连接同一个Redis实例的方案，比如服务器A部署Redis绑定内网IP，服务器B的应用程序直接连接服务器A的Redis地址，这也是”两个服务器怎么用一个Redis”最朴素的做法，但单点风险较高，不建议生产环境直接使用。
两台服务器怎么连同一个Redis：配置步骤详解
以下以主从复制架构为例,演示两台服务器共享一个Redis的完整配置流程，假设服务器A内网IP为192.168.1.10，服务器B内网IP为192.168.1.11，Redis版本为6.x或7.x。
主节点服务器A配置
主节点负责写入数据,配置相对简单，在服务器A上下载并解压Redis源码包，执行make编译安装，安装完成后修改redis.conf文件：
- bind改为0.0.0.0或内网IP，确保服务器B能访问。
- protected-mode设为no，或在bind指定IP时保持默认。
- port保持6379不变,确认防火墙放行该端口。
- appendonly设为yes,开启AOF持久化防止数据丢失。
完成配置后启动Redis服务,用redis-cli ping验证运行状态，返回PONG即正常，主节点不需要额外配置从节点地址，从节点会主动来找主节点同步数据。
从节点服务器B配置
服务器B上同样安装Redis,配置方式更关键，在redis.conf中追加一行核心配置：
replicaof 192.168.1.10 6379
这是两个服务器共用Redis的关键一步,它告诉从节点去连接主节点的IP和端口，配置完成后重启Redis服务，登录redis-cli执行info replication，看到role是slave且master_link_status为up，说明主从同步已建立。
验证数据同步时,在主节点执行set test_key test_value，再到从节点执行get test_key，能拿到对应值说明同步正常。
连接Redis的应用程序配置
应用层面,服务器A上的应用如果走本机Redis，连接地址保持localhost或127.0.0.1，服务器B上的应用配置需要指向服务器A的IP：
spring.redis.host=192.168.1.10
spring.redis.port=6379
如果应用具备读写分离能力（比如使用Redis的Lettuce客户端），可以在从节点服务器B配置读请求连接192.168.1.10，写请求也指向主节点，多数框架如Spring Boot通过RedisSentinel配置自动识别主从角色。
Redis主从复制配置的常见参数解析
两台服务器共用一个Redis时,主从同步参数直接决定数据一致性表现。
复制缓冲区配置
主从复制通过复制积压缓冲区（repl-backlog-size）保持数据同步，建议值设为32MB至64MB，网络抖动时从节点能快速追平数据，过小会导致全量同步频繁发生，消耗服务器资源。
断线重连机制
repl-disable-tcp-nodelay设为no，默认开启TCP优化，减少同步延迟，网络波动时，主从会自动重试连接，合理设置repl-timeout为60秒，超过该时间主节点判定从节点断线。
从节点只读设置
replica-read-only默认yes，从节点只处理读请求，如果误设为no，从节点可写入数据但不会同步回主节点，产生脏数据，生产环境务必保持默认只读。
生产环境中双服务器共用Redis的进阶注意事项
配置跑通只是起点,生产环境中的稳定性、可观测性和故障恢复才是关键考量，尤其是新手容易踩坑。
数据一致性与延迟
主从复制是异步模式,主节点写入后不等待从节点确认返回，网络正常时延迟在毫秒级别，但高并发下从节点可能短暂落后，强一致性需求下应使用Redis Cluster的WAIT命令。
故障切换与高可用
单纯主从复制在主节点宕机时不会自动切换,需要额外部署Redis Sentinel哨兵集群，Sentinel监控主从节点状态，当主节点不可用时自动将从节点提升为主节点，两个服务器上至少部署3个Sentinel进程才能避免脑裂问题。
相关的常见问题：服务器A挂了怎么办？由Sentinel自动完成切换，服务器B上的从节点升级为主节点，等服务器A恢复后作为从节点重新加入集群。
监控与性能调优
用redis-cli –stat实时观察两节点的读写指标，内存不足时配置maxmemory为物理内存的70%左右，并设置allkeys-lru淘汰策略，建议将RDB保存策略调整为一小时一次，配合AOF的everysec写入模式平衡性能与恢复速度，当Redis响应变慢时，排查方向包括大key阻塞、持久化fork阻塞、慢查询，以及服务器B到服务器A的网络往返延迟。
两个服务器共用Redis的服务器配置估算
双服务器部署Redis时,硬件选型不能只按照单机标准配置，需要预留一定的冗余空间，以下配置参数仅供参考（按8核CPU、服务器B同时运行应用和Redis从节点的场景估算）：
- 内存：单机Redis数据量两倍以上，建议预留至少4GB给Redis进程，从节点内存配置与主节点相同规格，否则无法承载全量数据。
- 带宽：内网至少千兆网络，两机之间的Redis同步流量和业务流量共用同一链路，高峰时观察丢包率。
- CPU：Redis单线程处理命令，4核以上足够支撑日常业务，复杂的Lua脚本和持久化操作需要更多CPU核数，如果服务器B上同时运行应用和Redis从节点，需要把应用对CPU的占用计算在阈值内。
两台服务器的技术选型与成本存在关联,不能只看单台的价格因素，想进一步了解具体配置的成本细节，可以咨询相关的价格参数对比，结合业务压测结果决定最终规模。
双服务器Redis方案怎么选：主从还是集群
很多人在选型时纠结,这里给出明确的选择路径，先看数据量，单机物理内存放得下且QPS在十万以下，优先主从复制加哨兵，数据量超出单机内存或写并发极高，直接上Redis Cluster，同时兼顾应用本身对事务和Lua脚本的支持需求，Redis Cluster对多key操作有槽位限制，需要保证key落在同一槽位。
部署运维能力也是关键变量,主从架构简单，哨兵配置成熟，出现问题容易排查，Cluster模式节点较多，数据迁移、槽位分配、故障恢复逻辑更复杂，需要团队具备一定的运维功底，小型团队推荐先做主从复制，将数据量预留充足，未来需要扩展时平滑迁移到集群。
常见疑问解答
两个服务器怎么连同一个Redis，直接用同一个IP端口就行吗
主从复制架构下,应用程序直接连接Redis主节点的IP和端口，与主机部署无关，从节点的IP和端口主要用于同步备份和故障切换，应用通常不直接感知从节点地址，Sentinel接入后，应用连接Sentinel地址，由Sentinel动态返回当前主节点，确保无论Redis实例在哪台服务器上运行，应用层始终不感知切换过程。
Redis主从复制会导致数据丢失吗
主节点返回写入成功时,从节点可能尚未同步完成，此时主节点宕机会丢失这部分增量数据，增加从节点数量和优化同步参数可以降低风险，但无法完全避免，对数据零丢失有硬性要求的业务，建议使用Redis Cluster的同步写机制或引入Redis Enterprise等行业方案。
两个服务器地理位置不在同一机房，怎么配置Redis
跨地域部署时网络延迟会直接影响同步效率,十毫秒内延迟可接受主从复制，云厂商的内网专线可以满足，距离较远时选择多机房Cluster部署，通过设置合理的cluster-node-timeout容纳高延迟，异地机房场景建议优先使用云厂商提供的托管Redis服务解决高可用问题，自建方案需要承担较大的网络和运维复杂度。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/717647.html
