两台Redis服务器实现数据一致，核心方案是主从复制加哨兵（Sentinel）机制：主库负责写，从库负责读，数据实时同步，哨兵负责监控和自动故障切换。 但两台机器这个特殊场景，有一个致命陷阱哨兵数量不够时，主库挂了会没人敢切换，因为哨兵自己也会“脑裂”,本文直接给你可落地的部署思路和排坑指南。
两台Redis服务器实现数据一致性，先搞清楚主从复制的底层逻辑
主从复制是Redis数据同步的基石，简单说，一台当主节点（Master），一台当从节点（Slave），主节点每次写入数据，都会把写操作同步给从节点，这个同步过程分成两个阶段：全量同步和增量同步。
全量同步发生在从节点刚接入时，主节点会生成一份完整的RDB快照文件发给从节点，从节点加载这份快照，就能拿到主节点的全部历史数据，之后主节点有新写入，就通过复制积压缓冲区把增量命令推送给从节点，这就是增量同步，整个过程是异步的，意味着从节点数据可能会有秒级延迟，但在绝大多数业务场景下,这个延迟可以接受。
行业共识认为，主从复制解决的是“数据冗余”和“读写分离”问题，但它本身不解决“自动故障切换”问题，主库宕机了，从库不会自己上位，需要哨兵来做这件事，所以两台Redis服务器要做到真正的高可用,必须主从复制和哨兵配合使用。
两台Redis服务器做数据同步，配置命令要这样写
在从节点的redis.conf里，找到replicaof配置项,写入主节点的IP和端口：
replicaof 192.168.1.10 6379如果你用的是Redis 5.0之前的版本，这个配置项叫slaveof，写法一样，改完配置重启从节点，执行info replication命令，看到role:slave、master_link_status:up,就说明主从关系建立成功了。
这里有个关键细节：主节点要开启持久化，至少开启AOF，否则主库一重启数据全丢，从库跟着把空数据同步过去，两台一起归零，建议主从都开启AOF，且appendfsync everysec每秒刷盘,兼顾性能和数据安全。
主从复制延迟怎么监控？三个命令看透状态
info replication：查看主从连接状态、复制偏移量info stats：查看total_net_repl_input_bytes，从库接收数据的字节数redis-cli -p 6379 debug sleep 1：手动制造延迟，测试主从切换的可靠性
如果从库的master_repl_offset和主库的master_repl_offset差距持续拉大，说明网络带宽或从库处理能力跟不上,需要检查是不是有慢查询或大key在拖后腿。
两台Redis服务器高可用方案，哨兵数量怎么定才是关键
很多人以为两台Redis服务器，配一个哨兵就够了。这是最危险的误解，哨兵要决定主库是否挂掉，需要征求多数哨兵的意见，如果只有一个哨兵，它和主库之间的网络闪断一下，它就会判定主库宕机，然后去切换但主库其实活得好好的，这就造成“脑裂”：业务还在往老主库写数据，新主库也在接收数据，两台机器数据分叉,再也对不齐了。
业内专家指出，哨兵集群的合理数量是奇数个且至少3个，比如3个或5个，但你的业务只有两台Redis服务器，哨兵放哪？两种常见解法：
哨兵部署在应用服务器上，不占用Redis资源
假如你有两台Redis服务器，再加两台应用服务器（比如Nginx、Tomcat所在机器），就可以把哨兵分别部署在这四台机器上，总共4个哨兵节点，这样即使一台Redis挂掉，还剩3个哨兵可以投票,超过半数就能正常切换。
两台Redis各挂一个哨兵，加一个仲裁哨兵
两台Redis服务器上各部署一个哨兵，再找一台轻量级云主机（哪怕是最便宜的1核1G）部署第三个哨兵做仲裁，三个哨兵互相监控，Redis主库挂了，三个哨兵投票决定是否切换，2票就能通过，不会出现“单人决策”的脑裂风险。
哨兵配置的三个核心参数
sentinel monitor mymaster 192.168.1.10 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 30000- 第一个
2表示至少2个哨兵同意才判定主库宕机 down-after-milliseconds 5000表示5秒内联系不上主库就标记为主观下线failover-timeout 30000表示30秒内完成故障切换
两台Redis服务器做高可用，最重要的原则是：哨兵数量必须大于1，最好部署在独立节点上。
redis主从复制和哨兵模式区别，到底该选哪个
这是很多运维新手会纠结的问题，直接说结论：
主从复制是数据同步机制，哨兵模式是故障切换机制，两者是配合关系，不是替代关系。 你只做主从复制，主库挂了业务就断；你只做哨兵不做主从,哨兵连个可切换的从库都没有。
从配置复杂度来看：
- 主从复制：改一行配置，重启服务，搞定
- 哨兵模式：要配置监控规则、投票阈值、切换策略，还要考虑哨兵自身的高可用
从故障恢复时间来看：
- 主从复制：手动执行
replicaof no one让从库转正，人工介入，恢复时间看运气 - 哨兵模式：自动感知主库故障，自动选主，通常在30秒内完成切换
所以两台Redis服务器做数据一致，最稳妥的组合是：主从复制保证数据有备份，哨兵保证主库故障时能自动切换，如果你的业务可以接受手动切换，那就只做主从复制；如果要求7×24小时不间断,哨兵必须上。
两台Redis服务器数据一致性排查指南，这些坑你迟早会遇到
数据丢失场景有哪些，怎么提前预防
主从架构下，数据丢失主要集中在两个时间点：主库宕机瞬间和脑裂恢复后，主库宕机瞬间，复制积压缓冲区里还有没发给从库的数据，这些数据就丢了，脑裂期间，老主库还在接收写入，新主库也在接收写入，恢复时老主库的数据会被清掉,这段时间的写入全丢。
缓解手段：配置min-replicas-to-write 1，意思是主库至少有一个从库连接才允许写入，否则拒绝写请求，这样即使脑裂发生，老主库没有从库连接，会自动拒绝写入,数据不会分叉。
两台Redis服务器之间网络延迟大，怎么优化
如果两台机器跨机房部署，延迟高是必然的,优化手段有三招：
- 用
repl-backlog-size调大复制积压缓冲区，从默认的1MB调到32MB甚至更大，防止网络抖动导致从库断线重连后走全量复制 - 开启
repl-disable-tcp-nodelay no，让主库尽快把数据推给从库，而不是攒一批再发 - 检查两机之间的TCP连接数，Redis对长连接依赖高，别被防火墙或安全组误杀
主从切换后，客户端连接怎么无缝感知
这是高可用方案落地的最后一公里，客户端不能写死主库IP，要用哨兵的
服务发现能力，Java的Jedis和Lettuce、Go的go-redis都支持通过哨兵节点获取当前主库地址，配置哨兵地址列表，客户端会自动跟随主库切换,不需要改代码重发。
两台Redis服务器做数据同步，全量复制风暴怎么避免
从库首次接入或断线重连，都会触发全量复制，主库要生成RDB快照、传文件、从库要加载文件，如果从库很多，主库会被拖垮，两台服务器场景相对简单，但也要注意：不要让主库的RDB生成和业务高峰期重叠。
实操建议：从库接入时间选在业务低峰期；用repl-timeout调整复制超时时间，默认60秒，网络差的地方适当调大到120秒；主库的client-output-buffer-limit replica配置适当放宽,避免大key写入时从库缓冲区溢出。
| 场景 | 全量复制 | 增量复制 |
|---|---|---|
| 从库首次接入 | ||
| 从库断线重连（未超时） | ||
| 从库断线重连（超时） | ||
| 主库重启（持久化开启） | ||
| 主库重启（持久化关闭） |
常见问题解答
两台Redis服务器必须同配置吗，不同配置会影响数据一致性吗
不需要同配置，从库内存比主库小也能工作，但会频繁触发内存淘汰，导致从库数据不完整，建议从库和主库的内存容量一致或更大，CPU和磁盘性能可以差一些,毕竟从库只承担读流量。
两台Redis服务器都在本地机房和跨云部署，一致性方案有区别吗
有区别，同机房内网延迟低，主从延迟几乎可以忽略，主从复制加哨兵足够，跨云或跨地域部署，网络延迟可能上百毫秒，主从复制会持续延迟，哨兵的down-after-milliseconds阈值也要相应调大，否则容易误判主库宕机，这种情况需要引入多活方案，但复杂度远超两台服务器场景,不建议自己搭。
两台Redis服务器的数据一致性，本质是把主从复制、哨兵监控、客户端感知三件事做扎实，主从复制保证数据不丢，哨兵保证故障自动切换，客户端动态发现保证业务不中断，记住一个核心原则：哨兵永远不要只部署一个，数据安全永远不要依赖单点。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/599449.html
