这期内容当中的小编将会给大家带来有关redis中的哨兵模式和集群模式，以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
哨兵模式
它是一种高可用的解决方案，sentinel本身是一个独立运行的进程，可以部署在其他与Redis集群可通讯的机器中监控Redis集群。
监控：哨兵会定时监控redis是否良好运行。
提醒：如果哨兵发现某个redis节点出现状况，能够通知另一个进程（如他的客户端）
自动故障迁移：在master宕机后会进行主备切换。当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。如果master恢复了，那么会成为slave。
Redis哨兵是一个分布式系统，采用Gossip协议接收master是否下线，采用投票协议决定是否执行故障迁移（在投票数超过所配置的值时会执行，执行时还需要得到一半以上的哨兵认可后才能执行），以及选择哪个slave作为master。
主观下线：当一个哨兵进程监控master无法连接了，那么他认为master下线了。
客观下线：当收到其他哨兵进程的master信息，判断是否真实下线。
每个哨兵向master、slave、其他哨兵每秒发送ping请求。
集群模式
由于哨兵不支持平滑的扩容，增加节点，那么自己要手动迁移数据。为此，Reids官方提供Redis Cluster实现分布式解决方案。分布式集群首要解决把整个数据集按照分区规则映射到多个节点的问题，即把数据集划分到多个节点上，每个节点负责整个数据的一个子集。
我觉得跟一致性hash一样。既然计算key的hash，获取到分片，那么集群模式缺陷就是无法进行key的批量操作了。因为这个key可能在不同的redis实例上。
集群的故障发现也是通过Gossip来通知各个redis节点的，两两节点互相ping、pong。
删除、增加节点则需要数据迁移。
上述就是小编为大家分享的redis中的哨兵模式和集群模式了，如果您也有类似的疑惑，不妨碍参照上述分析进行理解。如果想了解更多相关内容，请关注创新互联网站制作公司行业资讯。
