redis cluster monitoring tool setinel
http://www.cnblogs.com/LiZhiW/p/4851631.html
Redis's setinel is also a software that needs to be installed. It has a master-slave cluster. After installation, you only need to create a configuration file in the root directory of the installation to indicate the software to be monitored (ip+port is to determine the software)
Most setinels decide to migrate the master before they migrate, (here, this kind of cluster with master and slave only needs to monitor the master, and the master has the information of the slave)
General software has an alarm script mechanism
Each sentinel can vote, and finally the master setinel transfers the master, monitors the monitoring list and slave information of the client or master after the reids master, and the subsequent switching data changes (master changes) will be dynamically maintained by themselves (starting configured as starting point maintenance)
Redis-sentinel is a monitoring management, notification, and instance failover service for Redis instances, and is a management tool for Redis clusters. In a general distributed central node database, the role of Redis-sentinel is the work of the central node, monitoring the work of each other node and performing fault recovery to improve the high availability of the cluster.
Redis-sentinel was completed by antirez, the author of Redis, in June this year. Because of the application of Redis instances in various large companies, each company needs a Redis cluster management tool and is forced to write its own management tools to manage Redis clusters. Antirez Taking into account the urgent needs of the community, it took a few weeks to write Redis-sentinel.
Three major functions of Redis-sentinel: monitoring, notification, and automatic failure recovery. First, Redis-sentinel needs to establish a list of monitored masters, and then obtain sentinels and slaves that monitor it for each master in the master list for future failure recovery.
Automatic discovery of sentinel and slave
The monitoring master of a sentinel instance is specified in the configuration file. For example, sentinel A specifies the managed master ip:port list in the configuration file, and specifies parameters such as the connection failure timeout time and whether it can be recovered from failure. In this way, sentinel A establishes a list of monitored masters.
Sentinel A acts as a client to establish a pub/sub connection and a command transmission connection to monitor master 1. The purpose of the pub/sub connection is to obtain all sentinels monitoring master 1 through message passing by subscribing to the "sentinel:hello" channel , and this channel publishes its own host information, so that all sentinels monitoring master 1 obtain information about other sentinels by subscribing to master 1's "sentinel:hello" channel. Sentinel A creates a list of sentinels for master 1. Sentinel A also obtains the slave list of master 1 through the intermittent info command. If the connection times out or fails, it will enter the failure processing routine.
Prepare for failback
Redis-sentinel defines two states of the failed master, O_DOWN (objectively) and S_DOWN (subobjectively). When sentinel A fails to connect to master 1, sentinel A determines that master 1 is in the subobjectively state, and then sentinel A checks the determination of sentinels monitoring master 1. Because sentinels will establish connections and continuously initiate info command queries and responses, after sentinel A identifies master 1 S_DOWN, sentinel A continuously obtains the identification of other sentinels through the SENTINEL IS-MASTER-DOWN-BY-ADDR command. If there are more than quorum (specified in the configuration) sentinel that master 1 has been DOWN, then determine that master 1 is O_DOWN. Then sentinel A must have the can failover permission of master 1, which is also specified in the configuration file. Next, sentinel A needs to know the leader sentinel of master 1, and the leader will perform error recovery of master 1.
master 1的leader sentinel由选举产生，每个监控master 1的，并且具有错误恢复权限的sentinel都需要进行一次叫做subjective leader判断，也就是sentinel自己认定的leader，然后sentinel之间通过SENTINEL IS-MASTER-DOWN-BY-ADDR命令交流leader的认定情况，然后最终得到一个共识。
然后由这个master 1的leader sentinel来启动错误恢复例程。
故障处理
sentinel A作为master 1的leader，会选取一个master 1的slave作为新的master。slave的选取是根据一个判断DNS情况的优先级来得到，优先级相同通过runid的排序得到，但目前优先级设定还没实现，所以直接获取runid排序得到slave 1。
然后发送命令slaveof no one来取消slave 1的slave状态来转换为master。当其他sentinel观察到该slave成为master后,就知道错误处理例程启动了。sentinel A然后发送给其他slave slaveof new-slave-ip-port 命令，当所有slave都配置完后，sentinel A从监测的masters列表中删除故障master，然后通知其他sentinels。
总结
Redis-sentinel作为一个集群管理工具，基本满足了要求。但是Redis集群的需求却仍然存在。Redis集群作为分区结果，分区的配置仍然需要客户端或者代理协议实现，Redis集群作为一个整体还需要更长的路。Redis-cluster的草案早于出炉，但是实现却已经停留了很久。antriez承诺在Redis 3.0推出Redis-cluster功能。
参考：
Redis集群管理工具Redis-sentinel原理分析
http://os.51cto.com/art/201303/385437.htm
http://www.cnblogs.com/LiZhiW/p/4851631.html