公司的项目中,因为是需要部署多台服务,使用了 zookeeper 作为配置中心,但是吧所有的配置都放到 zk 中是不是对 zk 的乱用,如果是的话,那么能够介绍少下哪些数据适合放在 zk 当中,哪些不适合
1
yuchenyang1994 2018-02-06 18:58:45 +08:00 1
我觉得不是,本来就应该集中管理配置
|
2
soli 2018-02-06 19:05:33 +08:00
你说乱用,那至少举个例子吧。
我可以说个不适合的,那就是 zookeeper 节点的地址。 这个要么写死在代码中,要么应该放到本地配置文件。 |
3
whileFalse 2018-02-06 19:39:00 +08:00
|
4
NUT 2018-02-06 19:51:06 +08:00
zk 我们通用的做法是在整个配置中心 作为 通知版本更新角色 。每一个配置的每一次修改都会产生一个版本号。而真正的版本是通过 http 请求的。 这样尽可能的避免 zk 的错误导致配置不用。 具体参考下 disconf。
|
5
owenliang 2018-02-06 20:14:15 +08:00 via Android
读 zk 取配置肯定不是啥好事,毕竟业务 value 可能还挺大的。
但是单纯作为通知机制,也需要考虑数据更新后,zk 触发动作失败,一般也只能靠客户端定时拉来补偿。 |
6
Rickkkkkkk 2018-02-06 20:26:34 +08:00
这是 zk 的典型应用啊...
|
7
EmdeBoas 2018-02-06 21:00:30 +08:00
ZAB 的论文里面提到了 znode 存储 meta 属性的大小对性能影响是很大的(印象里面是最大,第二是 watch 数),如果修改不频繁的话可能还好,毕竟本地 session 有缓存。但一般都不会把配置文件直接丢进 znode 吧.....
|
8
xuxueli 2018-02-06 21:48:50 +08:00 via Android
zk 来维护配置数据没问题的。
1、数据体积:一个 node 维护一条配置,作为配置数据不会太大的,可以看下现有的 prop 文件。 2、配置数量:单机 watch 节点三千,阿里的测试报告 tps 可以跑到八九千。可以用除法简单计算下可以支撑的机器数。而且,zk 可以很方便的做集群。 http://www.xuxueli.com/xxl-conf/#/ |
9
billlee 2018-02-06 22:03:19 +08:00
没什么问题,kafka 0.9 以前还直接把 offset 往 zookeeper 里面存呢
|
10
metrxqin 2018-02-06 23:46:31 +08:00 via Android
zk metadata 最大 1M,建议放入少量数据,如果配置文件 URL 而不是完整配置信息。
|
11
PureWhite 2018-02-06 23:49:02 +08:00
没毛病,参考 k8s 和 etcd
|
12
vebuqi 2018-02-07 00:01:25 +08:00
见过把 zk 当数据库用的吗
|
13
rrfeng 2018-02-07 08:36:05 +08:00 via Android
没什么毛病,但是以后可能遇到问题。
|
14
seancheer 2018-02-07 10:00:42 +08:00
zookeeper 适用于读多写少的场景,写都是通过 leader 往里面写,写多的话肯定效率很差,这么用应该也没问题,但是分布式有专门的分布式配置管理工具,没必要一定要用 zookeeper
|
15
lybuestc 2018-02-07 15:44:56 +08:00
配置要确保通知到,且要比较及时。同时要满足两者还是客户端长轮询拉取靠谱。量小怎么用都没事,支持的客户端多了就不能这样用了
|
16
cominghome 2018-02-07 16:34:09 +08:00
@owenliang 不用实时更新到客户端,基本上启动的时候取一次就可以了,非要动态获取的话做个轮询,后端集群不太大情况下 ZK 还是没什么压力的
|
17
linsage186 2018-02-14 14:58:34 +08:00
@xuxueli 已 star,1.3.1 版本有更新计划么,maven 还是 1.3.0 的,希望能支持 spring boot 结合
|
18
xuxueli 2018-02-14 16:05:32 +08:00 via Android
|