Redis主从哨兵怎么搭配用，保证Game服务器不卡不掉线的那些事儿

根据网络游戏开发者社区分享、运维经验贴以及部分技术博客关于Redis高可用在游戏场景应用的讨论综合整理）

Redis主从哨兵这套东西,说白了就是为了让游戏服务器能一直转下去，别动不动就卡住或者让玩家掉线，你可以把它想象成一个给游戏数据上的“保险”，游戏运行的时候，玩家的等级、装备、背包里的东西、当前在哪个位置，这些关键数据都得随时存随时取，Redis就是干这个活的，因为它特别快，但如果只有一个Redis实例，那就好比整个游戏的数据就放在一个篮子里，这个篮子万一掉了，比如那台服务器断电了或者网络出问题了，整个游戏就瘫了，所有玩家数据都可能乱套或者丢失，那绝对是灾难性的。

不能只有一个,这时候就需要“主从”出场了，主从的意思就是，弄一个主要的Redis服务器，我们叫它“主库”，它负责处理所有的写操作，比如玩家升级了、捡到装备了，这些数据变化都写到主库里，再配一个或者多个“从库”，这些从库就像主库的跟班，实时地从主库那里把数据复制一份过来，保持和主库一模一样，这样一来，好处就多了：第一，读操作（比如查看背包、查询玩家信息）可以分摊到从库上去做，减轻主库的压力，主库就能更专心地处理写操作，这样游戏响应就更及时，不容易卡，第二，即使主库突然宕机了，至少从库那里还有一份完整的数据备份，不至于数据全丢，这就有了挽回的余地。

光有主从还不够智能,因为如果主库真的挂了，虽然数据在从库有备份，但游戏服务器自己不知道啊，它可能还在傻乎乎地试图往那个已经挂了的主库写数据，结果肯定是失败，玩家还是会卡住掉线，这就轮到“哨兵”登场了，哨兵是一个或者一组独立的进程，它的任务就是像个尽职尽责的保安，7x24小时不停地盯着主库和从库们的“死活”，哨兵会定期向所有Redis实例发送心跳检测，问问“你还活着吗？”。

一旦哨兵发现主库失联了,它就会自动触发一套流程：多个哨兵会互相沟通，确认主库是不是真的挂了，而不是网络偶尔抖一下造成的误判（这叫客观下线，避免误杀），确认主库确实不行了之后，哨兵们就会开会投票，从剩下的从库里面选出一个新的主库来，选举的标准包括从库复制的数据是否够新、网络连接状况等等，选好之后，哨兵会做两件关键事：一是通知被选中的从库“你升职了，现在你是老大了”，让它切换成主库的角色；二是通知游戏服务器（也就是客户端）“喂，换老板了，新的主库地址是XXX，以后数据都往这里写”，这个过程就是所谓的“故障自动切换”。

对于游戏服务器来说,它不需要自己去判断主库在哪，只需要一开始配置好哨兵的地址就行，游戏服务器会从哨兵那里查询当前真正的主库地址，这样，无论后台的Redis主从架构怎么切换，游戏服务器都能通过哨兵拿到正确的地址，从而持续进行读写操作，玩家几乎感知不到后台发生了故障切换，最多可能就是感觉网络稍微顿了一下，但不会卡死或者掉线。

具体怎么搭配才能让游戏服务器更稳呢？主从和哨兵本身不能放在同一台机器上，否则那台机器一挂，全完蛋，最好是主、从、哨兵分别部署在不同的物理服务器或者虚拟机上，这样能避免单点故障，哨兵本身最好也是奇数个，比如3个或者5个，分布在不同机器上，这样投票的时候才能形成多数意见，避免僵局，游戏服务器在代码里要实现与哨兵集成的逻辑，即连接时先连哨兵，获取主库信息，并且要监听哨兵发布的主库切换消息，及时更新自己的连接，这样一套组合拳下来，Redis的可用性就大大提高了。

Redis主从负责数据备份和读写分离,让服务更快更稳；哨兵负责监控和自动故障切换，保证服务持续可用，两者加起来，就是为了确保游戏的核心数据服务高可用，最大程度地减少因为后台数据存储问题导致的游戏卡顿和玩家掉线，给玩家一个流畅稳定的游戏体验，没有方案是百分百完美的，这套架构也需要日常的监控和维护，但确实是目前非常成熟且有效的一种实践。 融合了来自CSDN、知乎技术专栏、GitHub上相关项目Wiki以及部分云服务商（如阿里云、腾讯云）文档中关于Redis高可用方案的通俗化解释，并特别针对游戏服务器应用场景进行了侧重描述。）