为什么废弃zookeeper，解决什么问题，怎么解决的。

[wxsong]

如题

[xuxueli]

你好，废弃ZK这个决定犹豫很久。但最终决定废弃，理由如下：

1，成本高：依赖zk，需要额外维护一套zk集群，维护成本较高。移除之后，成本大大降低。

2，横向扩展受限：依赖zk，接入方数量受限于zk集群规模。当配置数量与接入方越来越多，对zk的watch与读写压力越来越大。移除zk后，理论上可以无限水平扩展。

当然，移除zk也有缺点。

1，强一致性特性，退化成最终一致性。
2，毫秒级推送更新，退化为秒级别推送更新。

如果需要强一致性特性，可以使用 1.5.x 版本，将会持续维护。

[pengls]

1、ZK集群在大部分公司基本是标配了
2、调整过之后，依赖admin服务，后台线程一直在发http请求同步admin服务的配置信息

[xuxueli]

@pengls
1、底层http接口时 long polling 方式的，并不会频繁刷新的。而且，同步线程目的仅仅时实时监控配置变更，初次之外 XXL-CONF 的 Mirror 、LocalCache层依然存在，性能依然很高。
2、ZK确实是个好东西，不过ZK底层也存在线程不停心跳、选举的，实现逻辑相对更复杂、系统内存占用相对较高一些。新方案 long polling 监控，功能一致，也更轻量一些。

其实移除ZK之后，最重要的一个特性就是跨机房了。
旧方案ZK可能存在ZK集群脑裂问题，如果要进一步完善实现更复杂。
而新方案移除ZK之后，配置中心集群节点关系对等，跨机房实现异地多活非常方便。

[CodingOX]

@xuxueli 你好，我在当前的 master 版本中发现，缓存是通过线程每隔3秒刷新一次的。这个 long polling 体现在哪里，不是找茬，是真心求教...？

[xuxueli]

通过这行代码 long polling 监控，阻塞直至配置变更或监控超时。

XxlConfRemoteConf.monitor(localCacheRepository.keySet());