请问这是不是 zookeeper 的乱用

我觉得不是，本来就应该集中管理配置

你说乱用，那至少举个例子吧。

我可以说个不适合的，那就是 zookeeper 节点的地址。
这个要么写死在代码中，要么应该放到本地配置文件。

@soli #2 我司是：
本地调试时，框架写死默认值，本地可以通过环境变量覆盖；
线上部署时，框架默认值失效，通过环境变量传入。

不过我们用的不是 zookeeper。

zk 我们通用的做法是在整个配置中心 作为 通知版本更新角色 。每一个配置的每一次修改都会产生一个版本号。而真正的版本是通过 http 请求的。 这样尽可能的避免 zk 的错误导致配置不用。 具体参考下 disconf。

读 zk 取配置肯定不是啥好事，毕竟业务 value 可能还挺大的。

但是单纯作为通知机制，也需要考虑数据更新后，zk 触发动作失败，一般也只能靠客户端定时拉来补偿。

这是 zk 的典型应用啊...

ZAB 的论文里面提到了 znode 存储 meta 属性的大小对性能影响是很大的（印象里面是最大，第二是 watch 数），如果修改不频繁的话可能还好，毕竟本地 session 有缓存。但一般都不会把配置文件直接丢进 znode 吧.....

zk 来维护配置数据没问题的。
1、数据体积：一个 node 维护一条配置，作为配置数据不会太大的，可以看下现有的 prop 文件。
2、配置数量：单机 watch 节点三千，阿里的测试报告 tps 可以跑到八九千。可以用除法简单计算下可以支撑的机器数。而且，zk 可以很方便的做集群。

http://www.xuxueli.com/xxl-conf/#/

没什么问题，kafka 0.9 以前还直接把 offset 往 zookeeper 里面存呢

zk metadata 最大 1M，建议放入少量数据，如果配置文件 URL 而不是完整配置信息。

没毛病，参考 k8s 和 etcd

见过把 zk 当数据库用的吗

没什么毛病，但是以后可能遇到问题。

zookeeper 适用于读多写少的场景，写都是通过 leader 往里面写，写多的话肯定效率很差，这么用应该也没问题，但是分布式有专门的分布式配置管理工具，没必要一定要用 zookeeper

配置要确保通知到，且要比较及时。同时要满足两者还是客户端长轮询拉取靠谱。量小怎么用都没事，支持的客户端多了就不能这样用了

@owenliang 不用实时更新到客户端，基本上启动的时候取一次就可以了，非要动态获取的话做个轮询，后端集群不太大情况下 ZK 还是没什么压力的

@xuxueli 已 star，1.3.1 版本有更新计划么，maven 还是 1.3.0 的，希望能支持 spring boot 结合

@linsage186 感谢关注哈。
1.3.1 正在 master 分支进行迭代，这次将会迭代很多新特性，预计春节发布。
springboot 预计会在 1.4 大版本引入啊。