基于zookeeper管理redis集群，实现消息路由(一)

Redis作为时下比较常用的内存数据库有其几个优势，性能高，稳定强，操作简单，提供多种语言且丰富API，集群部署简便等。目前很多企业用Redis集群主要用于缓存数据（设置与应用与数据库之间中间层），如TOP10排序，全局序号生产等，能较大提升用户响应时间。本文主要介绍如何用ZooKeeper维护Redis集群系统，已经如何实现基于Redis订阅发布功能实现消息路由功能。

ZooKeeper介绍不多说，网上资料有很多。Zookeeper有两个重要概念就znode和Watcher，znode是一个跟Unix文件系统路径相似的节点，可以往这个节点存储或获取数据。Watcher可由用户实现，用户监听znode状态变化，如子节点增加/修改/更新事件，监听父节点也可以监听到子节点的变化如增加和删除。这方便可以参考ZooKeeper官方手册。关于ZooKeeper部署，节点数目最好是基数，原因大致如下：

zookeeper有这样一个特性：集群中只要有过半的机器是正常工作的，那么整个集群对外就是可用的。也就是说如果有2个zookeeper，那么只要有1个死了zookeeper就不能用了，因为1没有过半，所以2个zookeeper的死亡容忍度为0；同理，要是有3个zookeeper，一个死了，还剩下2个正常的，过半了，所以3个zookeeper的容忍度为1；同理你多列举几个：2->0;3->1;4->1;5->2;6->2会发现一个规律，2n和2n-1的容忍度是一样的，都是n-1，所以为了更加高效，不必要的多增加一个zookeeper。

如果Redis集群有很多，如何进行高效的管理？ZooKeeper是一个不错的选择。通过ZooKeeper维持一个全局Redis运行信息，达到监控整个集群的目的。同时可以把Redis和ZooKeeper API进行二次开发，开发人员即可透明的访问Redis，无需关注Redis集群运行状态。分两步考虑问题：

1.开发RedisMonitor，用于定时监控Redis集群状态，保存诸如Redis Master/Slave信息，运行状态，数据量大小等。具体实现：

1）主进程定期发命令检查所有节点状态，目前有API可以查询到所有redis集群状态，再调用ZooKeeper API修改znode信息

2）znode状态变化触发通知和相关切换

附件提供相关RedisMonitor和HA源码

2.结合ZooKeeper和Redis API开发通用API。本篇准备论述一下如何实现基于Redis的消息路由。由于Redis自带消息订阅和发布功能，可以说是一个很不错的功能。发布订阅(pub/sub)是一种消息通信模式，主要的目的是解耦消息发布者和消息订阅者之间的耦合。订阅发布在如下场景应用广泛，如消息推送，消息路由，事件驱动告警与诊断等，对于开发来说，订阅和发布能大大减少系统之间的耦合。在设计模式中，发布订阅也是一个程序员必须掌握的模式。发布/订阅模型使发布者和订阅者之间不需要直接通讯（如远程接口调用RMI）就可保证消息的传送，有效解决系统间耦合问题（当然有这个中介），还有就是提供了一对一、一对多的通讯方式，比较灵活。订阅者可以通过subscribe和psubscribe命令向Redis订阅自己感兴趣的消息类型，Redis将消息类型称为通道(channel)。当发布者通过publish命令向Redis发送特定类型的消息时。订阅该消息类型的全部client都会收到此消息。这里消息的传递是多对多的。一个client可以订阅多个
channel,也可以向多个channel发送消息。

那么问题来了，在一个Redis集群中，如何对外提供可靠的消息路由功能，既保证了可靠性有保证了负载均衡。这里提供了一个简单的思路，读者可以进一步实现。订阅者在订阅channel时要进行相关判断，保持当前各个Redis Server负载基本均衡（选择一个负载最轻的server），同时，发布责发送时也要遵循此原则。可以采用ZooKeeper保持这些channel信息，以及Redis负载情况等等，信息越完善越能做出更合理的决策。还需要解决的一个问题是热切换。当某一台Redis集群挂掉之后，要求能自动切换到其他Redis
Server。以上操作对用户透明。后续会补上源码和流程图