背景
最近遇到一些问题，比如一个服务，需要在请求的客户端上做路由。这时就需要
- 获取服务端在哪几个服务器的进程上，
- 需要自行实现路由，
- 需要针对服务端某一些节点上下线做自动更新。
还有一种场景。我有一个监控服务，读取DB的数据，当DB中需要监听的进程达到上千时，频率要求10秒1次，这时一台机器的监听已经不足以承载。需要扩展到多进程部署。
思考
以上问题均可以使用zk的curator通知机制来实现。
归纳一下问题。
- 需要通知服务上下线机制；
- 需要热更新，类似rehash的过程。
解决
针对场景一种的，路由+维持DubboRef方式，可以监听zk下的dubbo路径，dubbo的上下线均会通知过来，这时将服务进行上下线处理即可。问题是，在切换的过程中，部分服务不可用。因为zk延迟，切换也有成本。
针对场景二种，可以在启动进程时，注册zk节点，根据自行创建的节点取模获取不同的监控任务。这是任务分发，用以支持多进程扩展。
同时如果期望做到HA，高可用的话，可以先对数据进行分发，再对分发的任务进行备份。例如1，2，3数据，分别给a,b,c,d,e,f进程执行。a,b,c分配到1,2,3执行。d,e,f也分配到1,2,3，但是会监听zk节点，如果非活动时。可以随时代替挂掉的节点。这样就实现了HA高可用。
思考点
- 扩展性，体现在能否数据量上来后，是否有简洁的扩展能力；
- 可用性，体现在节点挂掉后，服务是否有部分/全部不可用的状态。
curator监听zk
private void setDubboRemoteListenter(CuratorFramework client) throws Exception{
PathChildrenCache childrenCache = new PathChildrenCache(client, ZkParams.servicePath, true);
PathChildrenCacheListener childrenCacheListener = new PathChildrenCacheListener() {
@Override
public void childEvent(CuratorFramework client, PathChildrenCacheEvent event) throws Exception {
ChildData data = event.getData();
switch (event.getType()) {
case CHILD_ADDED:
case CHILD_UPDATED:
update(data.getPath(), false);
break;
case CHILD_REMOVED:
update(data.getPath(), true);
break;
default:
break;
}
}
};
childrenCache.getListenable().addListener(childrenCacheListener);
childrenCache.start(StartMode.POST_INITIALIZED_EVENT);
}
总结
zk有多种玩法，可用来玩共享锁，主要还是用来服务发现，通知。缺陷是支持的并发略低，通知延迟服务状态不可用。
如果需要共享锁，使用redis setnx更为合适。redis setnx介绍
