REDIS设计与实现之sentinel.docx

? ? REDIS设计与实现之sentinel ? ? ????redis主从复制可将主节点数据同步给从节点，一旦主节点宕机，从节点作为主节点的备份可以随时顶上来。这个过程如果人工介入，效果肯定没有自动的高可用机制好。sentinel 哨兵机制就是为了解决这个问题。是redis的高可用HA方案：有一个或多个Sentinel实例（instance）组成的Sentinel系统（system）可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。 ?? 启动并初始化sentinel?启动一个 Sentinel 可以使用命令： $ redis-sentinel /path/to/your/sentinel.conf$ redis-server /path/to/your/sentinel.conf --sentinel这两个命令都能启动Sentinel，效果都是一样的。 Sentinel启动后，会有五个步骤： 初始化服务器。将普通 Redis 服务器使用的代码替换成 Sentinel 专用代码。初始化 Sentinel 状态。根据给定的配置文件， 初始化 Sentinel 的监视主服务器列表。创建连向主服务器的网络连接。下面分别展开。 初始化服务器Sentinel的本质是一个运行在特殊模式下的Redis服务器，因此启动时必须对其进行初始化，但是由于Sentinel与普通的服务器不同，它的初始化需要执行的操作也不同。 创建连向主服务器的网络连接这一步是创建连向被监视主服务器的网络连接，Sentinel将成为主服务器的客户端，可以向主服务器发送命令，并从命令回复中获取相关的信息。 每个被Sentinel监视的主服务器，Sentinel会创建两个连向主服务器的异步网络连接： 命令连接，用于向主服务器发送命令，并接收命令回复订阅连接，用于订阅主服务器的 __sentinel__:hello 频道 为什么有两个连接？ 在 Redis 目前的发布与订阅功能中， 被发送的信息都不会保存在 Redis 服务器里面， 如果在信息发送时， 想要接收信息的客户端不在线或者断线， 那么这个客户端就会丢失这条信息。 因此， 为了不丢失?__sentinel__:hello?频道的任何信息， Sentinel 必须专门用一个订阅连接来接收该频道的信息。 而另一方面， 除了订阅频道之外， Sentinel 还又必须向主服务器发送命令， 以此来与主服务器进行通讯， 所以 Sentinel 还必须向主服务器创建命令连接。 并且因为 Sentinel 需要与多个实例创建多个网络连接， 所以 Sentinel 使用的是异步连接。 接下来的一节将介绍 Sentinel 是如何通过命令连接和订阅连接来与被监视主服务器进行通讯的。 ? ?获取主服务器信息????Sentinel 默认每十秒一次，通过命令连接向被监视的主服务器发送 INFO 命令，并通过分析 INFO 命令回复来获取主服务器当前信息。两方面信息： 关于服务器本身的信息??????包括 run_id 域记录的服务器运行ID，以及 role 域记录的服务器角色 关于主服务器属下的所有从服务器信息????????每个从服务器都由一个“slave”字符串开头的行记录，每行的 ip= 域记录了从服务器的IP地址, port= 域记录了从服务器的端口号。根据这些IP地址和端口号，Sentinel无须用户提供从服务器的地址信息，就可以自动发现从服务器。 ???根据 run_id 域和 role 域的信息，Sentinel将对主服务器的实例结构进行更新。而主服务器返回的从服务器信息，将会被用于更新主服务器实例结构的 slaves 字典(记录了属下从服务器的名单)。 ???Sentinel 分析 INFO 命令中包含的从服务器信息时，会检查从服务器对应的实例结构是否已经存在于 slaves 字典： 如果存在，就对从服务器的实例结构进行更新，如果不存在(表明这个从服务器是新发现的从服务器)，Sentinel会在 slaves 字典中为这个从服务器创建一个新的实例结构。 书上给了图，这里略过。注: 主服务器实例结构的?flags?值为?SRI_MASTER,从服务器是?SRI_SLAVE主服务器实例结构的?name?由用户使用Sentinel配置文件设置，从服务器的name?是由Sentinel根据服务器ip+port自动设置的四??获取从服务器信息??当Sentinel发现主服务器有新的服务器出现时，除了会为这个新从服务器创建相应的实例结