背景

最近遇到一些问题，比如一个服务，需要在请求的客户端上做路由。这时就需要

获取服务端在哪几个服务器的进程上，
需要自行实现路由，
需要针对服务端某一些节点上下线做自动更新。

还有一种场景。我有一个监控服务，读取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);  
    }