Redis的Sentinel模式基本介绍

主从模式介绍
主从模式存在的问题:

  • 一旦主节点宕机,从节点晋升为主节点,同时需要修改应用方的主节点地址,还需要命令所有从节点去复制新的主节点,整个过程需要人工干预。
  • 主节点的写能力受到单机的限制。
  • 主节点的存储能力受到单机的限制。

针对主从模式存在的问题,提供了Sentinel模式:
Sentinel的作用:

  • 监控:不断检查主服务器和从服务器是否正常运行。
  • 通知:当被监控的某个 Redis 服务器出现问题,Sentinel 通过 API 脚本向管理员或者其他应用程序发出通知。
  • 自动故障转移:当主节点不能正常工作时,Sentinel 会开始一次自动的故障转移操作,它会将与失效主节点是主从关系的其中一个从节点升级为新的主节点,并且将其他的从节点指向新的主节点,这样人工干预就可以免了。
  • 配置提供者:在 Redis Sentinel 模式下,客户端应用在初始化时连接的是 Sentinel 节点集合,从中获取主节点的信息。

Sentinel的基本介绍:

  1. sentinel也是一个Redis结点,该结点的不同之处在于不存储数据,只用来做sentinel相关的事情。

  2. sentinel一般不会是单点的。一个是可用性考虑;另一个是提高选举新主库时的正确率。

  3. 搭建:
    通过在配置文件中配置 sentinel monitor [主库别名] [主库ip:端口] [主库被判客观下线需要同意的sentinel结点数] 。配置后,Sentinel就可以监控到主库以及它下面的从库了。

    启动sentinel结点:

  • 通过 redis-sentinel redis.conf

  • 通过redis-server redis.conf --sentinel

    查看sentinel信息:
    使用 info sentinel 命令,可以查看到当前Sentinel拓扑中的结点分布,即有几个sentinel,主库信息,主库的从库。

  1. Sentinel的部署:
  • Sentinel的个数应该是大于等于3。因为选举投票时,需要半数以上的Sentinel同意才可以。如果是2个,则至少需要2票,若挂掉一个剩下那个也没法使用了。
  • 关于一个sentinel集合关联一个主库还是多个主库的选择:
    关联一个易于维护,但内存占用较高。
    关联多个则难于维护,尤其是多个主库的业务性质不同。
    建议:尽量使用关联一个,如果几个主库的业务属于同一业务下,也可以关联在在同一个sentinel集合下。

5. Sentinel客户端:
Sentinel其中一个作用就是解决当主节点切换后,Redis的客户端不用修改连接的配置信息。
以前主从模式下,客户端连接的是主节点的ip与端口。现在Sentinel模式下,客户端配置的是一个Sentinel集合与主节点的名称。因为Sentinel是最了解整个sentinel拓扑中的节点的,指定主节点名称则是区分当前Sentinel集合管理的多个主节点。

猜你喜欢

转载自blog.csdn.net/qq_40728028/article/details/106593604