1. 环境准备与版本选型1.1 为什么还是Redis 4.0.1先交代一下背景。我在维护的某老业务系统里核心缓存层一直跑在Redis 4.0.1上。这套环境从上线到现在跑了两三年期间经历过几次主从切换、节点宕机、内存暴涨稳得很。有人可能会问Redis都出到7.x了为什么还守着4.0.1不放理由很实在。第一业务代码里用到的命令和数据结构在4.0.1上全都有覆盖升级到新版本并不会带来功能上的跃迁反而要重新做一轮兼容性测试和基准压测。第二4.0.x这个系列是Redis进入稳定成熟期的标志性版本引入了模块系统、PSYNC2等关键能力主从复制和哨兵机制都相当可靠。第三很多时候生产环境的版本升级阻力并不来自技术本身而是业务排期和风险评估没有足够收益的升级不值得冒险。所以这篇文章就以Redis 4.0.1为基底把哨兵模式的搭建过程完整走一遍。哪怕你手里是6.x、7.x核心思路和配置项也大同小异差别我会在文中标注出来。1.2 环境规划与角色分配哨兵模式Sentinel解决的痛点很明确主节点挂了怎么办没有哨兵的时候主节点宕机意味着整个缓存层在人工介入之前不可用从节点虽然在但不会自动上位。哨兵就是那个盯梢的角色它负责监控主节点的健康状态一旦发现主节点失联就牵头做主从切换把某个从节点提升为新的主节点让整个集群在几十秒内自动恢复。这次搭建我准备了三台Linux服务器全部是CentOS 7.x内核版本3.10生产环境标配。三台机器的角色规划如下节点名称IP地址模拟运行角色Redis端口Sentinel端口redis-node-1192.168.10.11Master初始主节点637926379redis-node-2192.168.10.12Slave从节点637926379redis-node-3192.168.10.13Slave从节点637926379这种一主两从加三个哨兵的布局是哨兵模式最经典的推荐配置。三个哨兵意味着判断主节点宕机需要多数派投票即至少两个哨兵达成一致才会触发故障转移这能避免网络抖动造成的误判。如果只有一个哨兵它自己说是宕机那就宕机了很容易出现单点误判的问题。另外要强调一点哨兵和Redis实例跑在同一台机器上是完全可以的生产环境也经常这么干。当然如果资源充裕把哨兵单独部署在独立节点上会更安全这样Redis所在的机器整体宕机时哨兵还能存活并在别的机器上完成切换动作。这篇是入门实操我就按照同机部署的方式走。1.3 编译环境的依赖准备安装Redis 4.0.1我习惯用源码编译的方式而不是直接yum安装。原因很简单yum仓库里的版本往往不是你想要的那个版本而且编译安装可以自定义安装路径、配置文件路径和优化参数后续维护更可控。编译工具链是必备的。gcc肯定要装另外还需要tcl因为Redis的测试套件依赖它。执行下面的命令把基础依赖一次性装齐yum install -y gcc gcc-c tcl make装完后用gcc --version确认一下版本只要不是太老基本都没问题。我这边gcc版本是4.8.5编译Redis 4.0.1完全够用。如果你用的系统比较新装了更高版本的gcc编译老版本Redis偶尔会碰到告警但一般不影响使用不用太在意。还有一点容易被忽略时间同步。哨兵判断节点是否下线严重依赖各节点的时间一致性。如果各服务器的时间差太大心跳超时判断会失真明明节点活着信号却迟迟没到导致误判。所以搭建前务必确认所有节点都配置了NTP时间同步这一步看起来不起眼实际踩坑概率极高。yum install -y chrony systemctl enable chronyd systemctl start chronyd chronyc sources -v看到输出里有^*开头的行说明时间源已经同步上了。各节点之间时间偏差控制在几百毫秒内问题就不大。2. Redis 4.0.1编译安装全流程2.1 下载与解压下载源码包我习惯放到/usr/local/src目录下统一管理。Redis官网的下载地址是公开的这里就不反复贴了。拿到的包是redis-4.0.1.tar.gz大小大概几MB下载完顺手校验一下MD5防止传输过程损坏。cd /usr/local/src wget http://download.redis.io/releases/redis-4.0.1.tar.gz tar xzf redis-4.0.1.tar.gz cd redis-4.0.12.2 编译参数选择与执行Redis的Makefile做得比较智能绝大多数情况下直接make就能编译成功不太需要额外传参。不过为了明确安装路径推荐这种方式cd /usr/local/src/redis-4.0.1 make MALLOClibc -j4 make install PREFIX/usr/local/redis这里解释两个关键点。第一MALLOClibc指定使用libc的内存分配器。Redis默认会尝试使用jemalloc它对内存碎片化有很好的优化效果内存使用率高、峰值大的场景下效果很明显。但jemalloc在某些精简系统或特定gcc版本下编译容易报错如果遇到jemalloc.h: No such file or directory这类错误用MALLOClibc绕过它是最快的解决办法。本机测试或者内存资源不紧张的场景用libc问题也不大。第二PREFIX/usr/local/redis指定安装目录。执行完之后Redis的可执行文件会出现在/usr/local/redis/bin下包括redis-server、redis-cli、redis-sentinel、redis-check-aof、redis-check-rdb这几个主要二进制文件。编译完成后建议先跑一下内置测试验证当前环境下的Redis功能是否完整make test这个测试过程耗时几分钟到十几分钟不等取决于机器性能。看到结尾输出\o/ All tests passed without errors!就说明一切正常。如果某个测试用例报错绝大多数情况和tcl版本或系统环境有关可以先确认tcl装没装再考虑换gcc版本重试。2.3 安装目录与PATH配置安装完后把Redis的bin目录加进系统的PATH同时创建好数据目录和日志目录省得后面每次都用全路径执行命令echo export PATH/usr/local/redis/bin:$PATH /etc/profile.d/redis.sh chmod x /etc/profile.d/redis.sh source /etc/profile.d/redis.sh mkdir -p /usr/local/redis/conf mkdir -p /home/redis/data mkdir -p /home/redis/logs mkdir -p /home/redis/run关于目录规划这是我个人的习惯。配置文件放/usr/local/redis/conf数据文件、日志、PID文件丢在/home/redis下统一管理。生产环境建议把所有Redis相关路径固定下来别一会儿用/var/lib/redis一会儿用/opt/redis后面维护和排查问题的成本会低很多。三个节点依次执行同样的流程把Redis装好。这一步没什么花活核心是确保三台机器上的配置目录结构一致后面同步配置时能少踩不少坑。3. 主从复制配置的落地要点3.1 redis.conf主配置文件逐项解读哨兵模式是构建在主从复制之上的所以先把主从结构搭起来这是基本功。主从关系没配置正确后面哨兵的一切操作都是空中楼阁。在三台机器上分别创建redis.conf内容如下。先在主节点上写这份配置从节点在后面再补一行slaveof指向主节点。port 6379 daemonize yes pidfile /home/redis/run/redis_6379.pid logfile /home/redis/logs/redis_6379.log dir /home/redis/data dbfilename dump_6379.rdb appendonly yes appendfilename appendonly_6379.aof appendfsync everysec requirepass redis123456 masterauth redis123456 maxmemory 2gb maxmemory-policy allkeys-lru tcp-backlog 511 timeout 0 tcp-keepalive 60 save 900 1 save 300 10 save 60 10000 protected-mode no bind 0.0.0.0挑几个生产环境必须吃透的参数展开讲。daemonize yes以守护进程方式运行。这个必须设为yes不然Redis在前台跑SSH会话一断开进程就挂了。当然如果用systemd管理的话可以不设但手工运维场景设成yes最省心。requirepass和masterauth这两个是新手最容易搞混的配置。requirepass是客户端连接Redis时需要的密码而masterauth是从节点在连接主节点进行复制时用的密码从节点的masterauth必须和主节点的requirepass一致否则从节点连上主节点后执行SYNC会被拒绝日志里疯狂刷MASTER aborted replication。这两个参数一主一从的服务角色都要配上我自己刚开始配置时就漏了masterauth结果复制关系一直建立不起来排查了半天才发现是这里的问题。appendonly yes开启AOF持久化。Redis默认用RDB快照做持久化但RDB是定期全量快照两次快照之间的数据丢了就丢了。AOF以追加日志的方式记录每次写操作再配合appendfsync everysec每秒刷一次磁盘最多丢失一秒的写入数据。对于缓存场景可能觉得够用就行但哨兵模式下主从节点都开启AOF会更稳妥因为某个从节点被提升为主节点后它自己本地的数据完整性决定了它能否马上扛起写入流量。maxmemory 2gb和maxmemory-policy allkeys-lru设置内存上限和淘汰策略。这个根据实际业务量来调我这里模拟用2GB。allkeys-lru意味着内存写满后按LRU策略淘汰最久没被访问的key这是最常用的缓存淘汰策略。如果你的业务里某些key绝对不能被淘汰那就要考虑改用noeviction或者调整maxmemory预留空间。protected-mode no和bind 0.0.0.0允许外部访问。Redis默认保护模式下只允许本机连接如果绑定127.0.0.1三台节点之间没法互相访问主从复制和哨兵通信全部失败。生产环境对外开放Redis端口有一定风险好在咱们设置了requirepass不至于裸奔。如果是内网环境也能接受这个配置。3.2 从节点配置slaveof与启动顺序主节点的redis.conf写好后启动它redis-server /usr/local/redis/conf/redis.conf然后用redis-cli加密码验证一下redis-cli -a redis123456 ping输出PONG即说明主节点正常。这里-a参数后直接跟密码会在shell历史记录里留下痕迹测试环境无所谓生产环境建议用-a的交互输入方式或者配置REDISCLI_AUTH环境变量。接着在从节点上也就是redis-node-2和redis-node-3把同样的redis.conf拷过去然后追加一行slaveof 192.168.10.11 6379注意4.0版本里这个配置项还叫slaveof到了5.0之后改名成了replicaof。如果你用的是新版Redis记得用新名字旧名字虽然兼容但已经标记为废弃。然后依次启动两个从节点redis-server /usr/local/redis/conf/redis.conf启动完成后在主节点上执行redis-cli -a redis123456 info replication正常情况下应该看到role:master connected_slaves:2 slave0:ip192.168.10.12,port6379,stateonline,offset12345,lag1 slave1:ip192.168.10.13,port6379,stateonline,offset12345,lag1看到两个从节点都是online状态主从复制链路就算通了。这里提一下offset字段它表示从节点已经同步到主节点的哪个写操作位置两个从节点的offset应该保持一致如果出现差值越来越大说明复制积压有问题通常和网络延迟或大key写入有关。3.3 数据写入验证与主从同步排查主从结构搭好后做一轮简单的写入验证。在主节点上写入一个keyredis-cli -a redis123456 set company:name demo-corp然后在任意从节点读取redis-cli -a redis123456 get company:name如果输出demo-corp说明复制正常。如果读不到先看从节点的日志/home/redis/logs/redis_6379.log这时候最常见的报错是MASTER aborted replication with error: ERR Client sent AUTH, but no password is set这个报错的意思是从节点向主节点发起了AUTH请求但主节点根本没设置密码。乍一看像是主节点没配requirepass实际排查时更常见的情况是主节点的requirepass配了但从节点的masterauth没配或配错导致认证失败。记住一条口诀主节点requirepass管外部连接从节点masterauth管复制认证两边必须对齐。另一个值得检查的点是防火墙。CentOS 7默认firewalld是开启的三台节点之间的6379和26379端口必须放行否则会出现一种很诡异的现象从节点状态显示online但数据同步断断续续日志里全是连接超时重试的记录。firewall-cmd --permanent --add-port6379/tcp firewall-cmd --permanent --add-port26379/tcp firewall-cmd --reload主从结构确认无误之后就可以进入哨兵配置环节了。4. 哨兵模式配置与启动4.1 sentinel.conf核心参数配置三台机器上都要配置sentinel.conf内容如下port 26379 daemonize yes pidfile /home/redis/run/redis-sentinel_26379.pid logfile /home/redis/logs/redis-sentinel_26379.log dir /home/redis/data sentinel monitor mymaster 192.168.10.11 6379 2 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 30000 sentinel parallel-syncs mymaster 1 sentinel auth-pass mymaster redis123456逐行拆解一下。sentinel monitor mymaster 192.168.10.11 6379 2这一行的含义是让哨兵监听一个名为mymaster的主节点它的初始地址是192.168.10.11:6379最后的数字2表示判定主节点客观下线所需的最少哨兵同意数。三哨兵架构下设置为2意味着主节点失联后需要至少两个哨兵都认为它挂了才会触发故障转移。这个数字不能大于哨兵总数也建议不要等于哨兵总数否则哨兵节点自身故障时整个系统就没有容错能力了。sentinel down-after-after-milliseconds mymaster 5000哨兵在5秒内没有收到主节点的有效响应就主观认定它下线了。这个值不要设得太小比如1000毫秒网络稍微抖动一下就触发误判也不要设得太大比如300秒那主节点真挂了业务中断五分钟后才切换体验就很差了。权衡下来5秒是一个比较均衡的起点。sentinel failover-timeout mymaster 30000故障转移的超时时间包括从选举新主节点到从节点完成复制的整个流程超过30秒视为失败。这里不能太短因为Redis的故障转移涉及多个哨兵之间的Raft协调、从节点优先级比较、复制断点续传这些动作在极端情况下确实需要一定时间。sentinel parallel-syncs mymaster 1故障转移完成后同时向几个从节点发起复制新主节点的命令。设置为1意味着逐个同步避免多个从节点同时全量复制把主节点带宽打满。从节点数量多、数据量大的场景这个值设成1最保险。sentinel auth-pass mymaster redis123456所有节点的Redis都设置了密码哨兵连接Redis时也需要认证这里的密码必须和Redis的requirepass一致。4.2 启动哨兵与状态观察配置写好后在三台机器上分别启动哨兵redis-sentinel /usr/local/redis/conf/sentinel.conf或者用redis-server以哨兵模式启动redis-server /usr/local/redis/conf/sentinel.conf --sentinel两种方式效果一样我习惯用redis-sentinel这个命令语义上更清晰。启动之后用redis-cli连上哨兵端口看看情况redis-cli -p 26379执行info sentinel重点关注master0部分的输出# Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:namemymaster,statusok,address192.168.10.11:6379,slaves2,sentinels3解读一下关键字段。statusok表示主节点处于正常状态。slaves2说明哨兵在主节点上发现了两个从节点。sentinels3说明当前哨兵网络里一共发现了三个哨兵实例这个数字等于你部署的哨兵总数说明哨兵之间的互相发现机制已经生效。如果slaves或sentinels数字不对比如sentinels2而不是3大概率是某个哨兵节点的配置文件里端口写错了或者防火墙没有放行26379端口。哨兵之间通过pub/sub机制交换信息主节点上有一个专门的__sentinel__:hello频道每个哨兵启动后都会订阅这个频道并向它发布自己的信息其他哨兵收到消息后就把对方加入自己的哨兵列表。这个过程不需要手动指定对方的IP自动发现机制帮我们搞定了。顺带说一句启动完哨兵后再去查看主节点的redis.conf你会发现文件末尾多了一段被哨兵自动追加的内容# Generated by CONFIG REWRITE dir /home/redis/data哨兵在运行过程中发现配置变化比如主节点地址变更会把新的配置写回配置文件。这就是CONFIG REWRITE机制。也是因为这个机制配置文件本身必须有写权限别手滑把文件属性改成只读否则后续故障转移时哨兵会报错。5. 故障转移实测与原理验证5.1 模拟主节点宕机验证自动切换哨兵配置完成只是第一步真正检验哨兵模式是否可靠必须做一次故障演练。演练的方式很简单把主节点Redis进程杀掉观察哨兵的反应。在redis-node-1上执行redis-cli -a redis123456 shutdown nosave这会让主节点平滑关闭。关掉之后立刻盯着哨兵日志看tail -f /home/redis/logs/redis-sentinel_26379.log日志里会依次出现这样的关键信息sdown master mymaster 192.168.10.11 6379 odown master mymaster 192.168.10.11 6379 #quorum 2/2 try-failover master mymaster 192.168.10.11 6379 vote-for-leader master mymaster 192.168.10.11 6379 failover-state-select-slave master mymaster 192.168.10.11 6379 selected-slave slave 192.168.10.12:6379 192.168.10.12 6379 failover-state-send-slaveof-noone slave 192.168.10.12:6379 192.168.10.12 6379 failover-state-wait-promotion-slave slave 192.168.10.12:6379 192.168.10.12 6379 promoted-slave slave 192.168.10.12:6379 192.168.10.12 6379 failover-state-reconf-slaves master mymaster 192.168.10.11 6379 slave-reconf-sent slave 192.168.10.13:6379 192.168.10.13 6379 slave-reconf-inprog slave 192.168.10.13:6379 192.168.10.13 6379 slave-reconf-done slave 192.168.10.13:6379 192.168.10.13 6379 failover-end master mymaster 192.168.10.11 6379 switch-master mymaster 192.168.10.11 6379 192.168.10.12 6379这一段日志把一次完整的故障转移过程讲清楚了拆开来看每一步的含义sdown到odown的过程是哨兵先主观认为主节点下线然后在多数派哨兵之间达成一致后升级为客观下线。这一步从sdown出现到odown出现正常情况下只有几秒钟。try-failover到vote-for-leader说明哨兵之间进行了一轮投票选出一个领头哨兵来主导后续的切换动作。这个领导选举机制和Raft共识算法非常相似每个哨兵都有资格参选得票超过半数就能当选。selected-slave和promoted-slave领头哨兵从所有从节点里挑了一个最优的提升为新主节点。它挑选的核心依据是从节点的优先级slave-priority配置项默认100值越小越优先、复制偏移量、run_id等。默认配置下一般会选择数据最完整的从节点上位。switch-master最后一行最关键它宣告主节点地址正式从192.168.10.11切换到了192.168.10.12。哨兵会把新的主节点地址写进自己的配置文件同时通过pub/sub消息通知所有订阅了哨兵事件的客户端让它们更新连接目标。所有从节点也会自动重新指向新的主节点无需人工干预。5.2 切换后整体状态验证故障转移完成后在新主节点上确认状态redis-cli -a redis123456 info replication输出应该变成role:master connected_slaves:1 slave0:ip192.168.10.13,port6379,stateonline,offset45678,lag1注意原来的从节点redis-node-1已经挂了所以它不在connected_slaves列表里。等redis-node-1上的Redis实例重新启动后它发现自己曾经是主节点但当前有新的主节点会自动降级为从节点并同步数据。这个自愈能力是PSYNC2在4.0版本中带来的关键改进它让断线重连的从节点可以快速恢复同步而不需要做一次全量复制。再验证一下旧主节点重启后的表现。在redis-node-1上重新启动Redisredis-server /usr/local/redis/conf/redis.conf启动后查看它的复制状态redis-cli -a redis123456 info replication输出中role字段会变成slave并且master_host指向192.168.10.12。这个自降级行为非常关键如果旧主节点重启后还把自己当主节点整个集群会出现双主脑裂数据写入会互相冲突这是必须避免的。Redis的哨兵机制通过配置文件里的CONFIG REWRITE已经把新的主从关系写回了redis.conf所以旧主节点启动时读到的配置就是“我是从节点”天然规避了脑裂问题。5.3 切换耗时与可用性评估从主节点宕机到switch-master完成我在实际测试中记录的耗时大约在10到15秒之间。这个时间分布大致是5秒主观下线判定 1秒左右客观下线投票 2秒左右从节点选举 2秒左右从节点配置更新与复制。对于大多数业务场景来说这个恢复速度是完全可以接受的但前提是应用层也要处理连接重连逻辑。如果业务代码里的Redis客户端连接池没有重连机制即使后端完成了切换应用层的旧连接依然指向已经宕机的节点照样报错。现在主流的Redis客户端库都内置了哨兵支持。以Java的Jedis为例可以通过JedisSentinelPool连接哨兵节点客户端自己感知主节点变更并重建连接池。把客户端的连接配置指向26379端口而不是6379端口就能保证故障转移对业务几乎无感知。6. 常见问题与排查技巧实录6.1 哨兵常见故障速查表在这次的搭建和测试过程中我整理了一份哨兵模式高频问题的排查对照表基本覆盖了新手期最容易踩的坑故障现象可能原因处理方法主从复制一直处于down状态masterauth未配置或密码不一致检查主节点requirepass与从节点masterauth保持一致哨兵日志频繁出现sdown又odowndown-after-milliseconds设置过小将该值调大到8000毫秒以上排除网络抖动因素info sentinel中sentinels数量不对哨兵端口未放行或配置的port不一致检查防火墙和所有哨兵配置文件的端口确保26379端口互通故障转移后旧主节点恢复后不自动变为从节点配置文件没有写权限CONFIG REWRITE失败确认配置目录和文件属主为运行Redis的用户恢复写权限哨兵启动报Cant resolve master instancesentinel monitor里的主节点地址或端口写错核对主节点实际监听地址用redis-cli -h IP -p PORT ping验证客户端连接哨兵后拿到的地址不可用哨兵配置文件里用了127.0.0.1作为主节点地址内部节点通信一律使用内网IP不要用回环地址故障转移耗时长超过30秒大量从节点同时执行全量同步带宽打满把parallel-syncs设为1逐个同步避免从节点争抢带宽主节点内存写满后哨兵误报OOM command not allowedmaxmemory-policy设成了noeviction按业务场景改用allkeys-lru或其他淘汰策略6.2 脑裂问题的预防措施脑裂Split Brain是分布式系统里最棘手的问题之一哨兵模式也不例外。最典型的脑裂场景是主节点所在机器网络拥堵但进程还活着哨兵联系不上它就切换到新主节点等网络恢复旧主节点恢复如果它的配置没有被正确改写就会出现两个写主节点同时存在的情况两边各写各的数据一合并就乱套。Redis哨兵模式从设计上尽量降低了脑裂发生的概率它的重要防御机制就是客观下线投票。只有多数派哨兵至少2个都认为主节点不可用才会触发切换单一哨兵的判断不会引发任何后果。这就保证了切换决策的集体性避免了单个哨兵因误判而擅自行动。此外还有一个容易被忽视的设计旧主节点恢复网络后会去同步新主节点的数据把自己变成新主节点的从节点。但这里有个时间窗在旧主节点完成降级之前它依然在接受写入请求这些写入数据因为没有同步到新主节点会在降级时被覆盖掉。解决思路主要有两个一是设置合理的min-slaves-to-write和min-slaves-max-lag参数让主节点在从节点失联达到一定数量时直接拒绝写入二是尽量让哨兵和Redis实例部署在不同故障域避免同时宕机。这两个参数在4.0.1里已经支持生产环境务必配置上min-slaves-to-write 1 min-slaves-max-lag 10含义是如果可用从节点少于1个或者从节点最大延迟超过10秒主节点就拒绝写入。这样一来即使主节点被错误判定为下线它在网络分区期间也无法接受写入从根源上避免了脏数据产生。6.3 哨兵配置文件被自动改写的坑最后分享一个我踩过的坑这问题极具迷惑性。有一次我在一台已经运行了哨兵模式的机器上手动去修改sentinel.conf想把down-after-milliseconds从5000改成8000。改完重启哨兵配置生效没几天再打开文件一看居然变回了5000。原因很简单哨兵在运行过程中会把它的运行时状态写回配置文件。我在文件里手动改的配置和哨兵内存里保存的配置不一致一旦触发CONFIG REWRITE内存里的旧值就把我改的新值覆盖了。正确的做法是通过redis-cli连接哨兵执行SENTINEL SET命令来动态修改配置而不是直接编辑文件。命令如下redis-cli -p 26379 sentinel set mymaster down-after-milliseconds 8000这条命令会同时修改哨兵的内存配置和磁盘配置文件下次CONFIG REWRITE时不会丢。同理要修改密码或failover-timeout也是用同样的方式。这个教训告诉我们哨兵的配置文件不能随意手工编辑它实际上是一个运行时状态的镜像。任何配置变更优先走SENTINEL SET通道命令行改不了的才考虑停机维护。6.4 日志轮转与长期运维建议哨兵长时间运行后日志文件会越来越大。如果日志目录所在的磁盘分区不够大轻则影响日志写入重则拖垮整个Redis进程。生产环境建议配置logrotate定期切割日志配置文件长这样/home/redis/logs/*.log { daily rotate 30 copytruncate compress missingok notifempty }这段配置的意思是日志每天切割一次保留30份切割后立即压缩用copytruncate模式避免重启服务。这里特别说一下copytruncate它先把日志文件复制一份再把原文件清空。如果不用这个模式直接mv日志文件Redis哨兵持有的文件句柄会指向已经被移动的文件导致新日志写到旧文件名上造成日志丢失。另外建议用systemd管理Redis和Sentinel服务而不是单纯的daemonize yes加手工启动。systemd可以自动拉起服务进程意外退出后能快速恢复。虽然这篇文章没有展开写systemd unit文件的细节但生产环境强烈推荐加上这层守护。7. 这套方案能做什么不能做什么哨兵模式解决的是主节点故障时的自动切换问题它有明确的能力边界。它能做到的是主节点宕机后自动从从节点中选举新主节点从节点自动重新指向新主节点客户端通过哨兵感知主节点变更并重新连接整个过程无需人工介入。它不能做到的是数据的水平扩展和读写分离的负载均衡。主从复制的所有写操作还是集中在单个主节点上从节点的slave-read-only默认开着只能分担读流量。如果业务量增长到单节点写入成为瓶颈需要的是Redis Cluster集群模式那是另一个话题了。另外哨兵模式也不等于数据零丢失。appendfsync everysec意味着极端情况下可能丢失最近一秒的写入数据主从复制在异步模式下也可能出现从节点数据滞后。对于缓存场景这些都不是问题但如果你拿Redis存交易数据、订单数据那就要认真考虑数据一致性方案了哨兵模式不是为强一致场景设计的。结合我个人的实操体会这套1主2从3哨兵的架构适合大多数中小规模的业务系统。它比单节点可靠得多也比Redis Cluster简单得多运维成本低很多。对于刚开始接触高可用架构的团队把哨兵模式吃透远比一上来就搞复杂集群有价值。最后再分享一个小技巧日常巡检时可以写个脚本定时检查哨兵的info sentinel输出重点盯status字段。如果某天发现status不再是ok说明最近发生过故障转移或者有节点状态异常这时候去翻哨兵日志往往能找到有价值的信息。这个习惯帮我提前发现过好几次从节点磁盘满、复制断连的隐患希望对你们也有用。