记录一次有关redis缓存服务器挂掉的生产故障
记录一次有关redis缓存服务器挂掉的生产故障
就在上个星期，生产环境，由于redis主机挂掉，业务受阻差不多30分钟，导致甲方损失差不多300万，甲方一天的收入大概一个亿左右。 后来回顾发生此故障的原因是，虽然生产环境redis集群配置的是主从模式，并且每个主（master）节点都有3个 从（slave）部署在不同的服务器上，但是这只是解决了读写分离和数据备份的问题，并没有保障redis缓存集群的高可用性，在主从模式下，主节点故障，集群则无法进行工作，从节点升主节点需要人工手动干预！也就是无法在redis主节点挂掉以后，不能进行主从切换和选举！ 后来在平台组的介入下，我们将生产环境的redis集群做了高可用的方案，redis主从模式+Sentinel（哨兵）-架构图如下： Sentinel 哨兵是 redis 官方提供的高可用方案，可以用它来监控多个 Redis 服务实例的运行情况。Redis Sentinel 是一个运行在特殊模式下的 Redis 服务器。Redis Sentinel 是在多个Sentinel 进程环境下互相协作工作的。Sentinel 系统有三个主要任务：
监控：Sentinel 不断的检查主服务和从服务器是否按照预期正常工作。
提醒：被监控的 Redis 出现问题时，Sentinel 会通知管理员或其他应用程序。 自动故障转移：监控的主 Redis 不能正常工作，Sentinel 会开始进行故障迁移操作。将一个从服务器升级新的主服务器。让其他从服务器挂到新的主服务器。同时向客户端提供新的主服务器地址。
如果当初在架构设计的时候，就采用主从模式+哨兵的高可用方案，可能就不会出现上个星期的生产事故！被动的等到出了问题时候补救的方式，远远不如主动的思考目前我们当下所采用的的架构设计是不是存在某些隐患！防范于未然才是最重要的！
