FAQ

1. qconf 安装过程中遇到的 missing aclocal-1.14 的问题

• 问题现象：

在 32-bits 的机器上安装qconf的时候，会出现这样的 aclocal 版本要需要为1.14 的问题

• 问题分析：

该问题是在32-bits 机器上存在，而在 64-bits 的机器上是不存在该问题；

问题原因是qconf为了解决用户使用源码安装需要安装各种依赖包，就将当前已经稳定的依赖包源码直接包含到 deps目录下，然后在qconf源码安装的时候，就会自动将这些依赖包给安装了；但是在安装过程中，其中的一个包gdbm-1.11 的安装在 32-bits 需要aclocal 即 automake 为 1.14；

• 问题处理：

1） 使用64-bits 的机器安装

2） 在32-bits 的机器上上，可以去官网下载 automake-1.14，地址：http://ftp.gnu.org/gnu/automake/automake-1.14.tar.gz 和 http://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz

2. 使用qconf需要调整共享内存限制

• 通过 sysctl -a | grep shm 查看当前的共享内存上限的大小，如果不足2G，则进行如下操作：

修改共享内存上限，使当前正在运行的系统生效，

Mac 执行：

   sysctl kern.sysv.shmmax=2048000000

   // sysctl kern.sysv.shmall=4294967296
   // shmall 是全部允许使用的共享内存大小 但是它是控制共享内存页数 linux共享内存页大小为4kb 故应设置为 4294967296 / 4
   sysctl kern.sysv.shmall=1073741824

修改共享内存上限，使机器重启时生效，需要在 /etc/sysctl.conf 添加：

   kern.sysv.shmmax=2048000000
   kern.sysv.shmall=4294967296

linux 执行

   sysctl kernel.shmmax=2048000000
   sysctl kernel.shmall=4294967296

3. 编译时会遇到的问题 .../deps/gdb/build-aux/missing: line 81:

• 问题

3.1) aclocal-1.14: command not found
3.2) automake-1.14: command not found
3.3) makeinfo: Command not found

• 解决
  这个问题应该是由于源码编译时指定了automake的版本导致的，如果OS上找不到aclocal automake等命令可以通过yum安装一下，然后做一下软链：

ln -s /usr/bin/aclocal /usr/bin/aclocal-1.14
ln -s /usr/bin/automake /usr/bin/automake-1.14
第三个问题执行一下即可 yum install texinfo

4. QConf在cygwin下面编译

360奇虎的QConf在cygwin下面编译的心得

设计相关

采用多个znode还是一个znode放很多data？

不必担心连接数问题，多个znode会导致watcher增加，但连接数是不变的。

需要考虑的是，每个znode底下的data，必须要小，建议<1m.

zk server watcher数 = client * znode数

线上数据:单台zk机器有近二十万的，一个session没多少，最多几百吧

Q群聊天记录

lk  16:51:06
get_conf 不支持 /zknode/aaa/* 这种统配吧。 zk默认没这功能。
王康@360  17:57:53
恩，不支持
lk  18:01:26
get 一个不存在的znode
lk  18:01:50
每次都会向zk server发get命令么？
王康@360  18:02:18
是的
lk  18:02:50
哦，这种情况要是qps大，就不好玩了
lk  18:03:15
qconf没缓存，就只能靠zk了
王康@360  18:06:36
get请求最终是agent发起的，客户端接口只是丢任务给agent，这个过程会去重，所以应该比qps小一些
lk  18:08:59

lk  18:10:41
如果一个session初次调用10000个zonde的get(此时qconf还没缓存)，会不会有压力？
lk  18:10:57
不同znode
王康@360  18:15:48


王康@360  18:16:35
这个是zk的性能
油菜田  18:17:47
曲线的意思是 增加zk集群中的节点数量，整个zk集群性能越牛逼吗？
油菜田  18:18:12
还是咋滴？
lk  18:21:38
多谢多谢，好人啊
王康@360  18:33:04
随节点增加，读性能因为分摊更好，写性能因为一致性写更差

访谈摘录

Q&A

Q1：QConf客户端主要有:Agent、各种语言接口、以及连接他们的消息队列和共享内存。这样会不会客户端太重了，CPU和内存负载如何呢？

从上面的描述上可以看到，当配置不更新的时候，Agent其实是没有什么事需要做的，而数据的量一般不会太大，所以对CPU和内存，压力都不大。数据主要在共享内存，默认开128M，对单台服务器的配置量来说很充足了。而共享内存和消息队列都是操作系统维护的基础IPC。这里客户端太重可能主要体现在部署成本上，不过我们采用cmake的方式，可以使部署很方便。

Q2：如果ZooKeeper死掉一个，再添加新的ZooKeeper的时候，怎么让其他客户端知道这个新添加的？

如果IP没有变化的话没关系，新增ZooKeeper现在确实是需要重新配置的，而且ZooKeeper集群需要重启。

Q3：请问，客户端与 Agent 之间是同步还是异步？

1.是一个异步的过程，客户进程把不存在的Key放入消息队列中后，需要等Agent取，现在的做法是分100次重试，每次5ms，如果取到就返回，生产环境一般在10到15ms通常就可以取到。

2.由于一些业务对等待时间较敏感，我们也提供了不等待的方式，加入消息队列后直接返回，重试时间有上层决定，可以由特定的参数制定。

Q4:如果Agent挂了，是否无法感知?

1.Agent采用父子进程keepalive的方式，可以一定程度上避免。

2.生产环境会部署Agent的监控从外部感知这件事，并及时解决，解决的过程中，还可以访问到原始数据。

3.我们有反馈接口，可以在管理端接受这个反馈，在每次修改后确保自己的服务全都正常更新。

Q5: 配置项变更时，怎样解决客户端拉取时间差的问题？

这就是我们采取Zookeeper的一个好处，不需要客户端轮训的查询变化情况；变化后，服务端会通过Watcher通知客户端，这个时间很快，生产环境能保证是秒级，而且没有无效通讯。

Q6: 有没有办法修改QConf的目录？我看代码 貌似在链接二进制文件的时候把目录指定为prefix了，我向编译成二进制文件后，通过部署系统发布，目录可能变化。

可以的，cmake安装的时候可以指定

Q7：为啥不考虑持久化配置文件，再reload进程，可以彻底避免ipc带来的成本？

1.现在有持久化配置，采用的是gdbm，不过只有在机器重启且网络中断的情况下使用。

2.直接使用配置文件会有访问效率的问题。现在这种使用方式，业务需要每次都从QConf读数据，当读取次数比较多的时候会很影响业务进程。

3.如果我们同时维护一份内存数据的话，同样有两个版本不同步的问题，有一个是优先使用的，就像我们现在的状况，共享内存>网络>持久化配置。

Q8：服务方式可以展开下吗？提供计算服务资源什么意思？服务地址？

服务方式对QConf来说是一种特殊的配置，在Zookeeper上有一些特殊的结构来存储，服务就是ip:port，不论是dba的存储服务还是系统部的计算服务，在QConf看来是一样的，就是监控这些ip:port存活并在用户调用相关接口如get_host时返回可用的服务地址。

Q9：能否展开讲一下『管理端是业务修改配置的页面入口，配合数据库提供一些如批量导入，权限管理，版本控制等上层功能。』？

管理端是用来方便用户管理修改配置的，在内部提供了的一些如批量导入，权限管理，版本控制的功能，这些上层功能有时会需要数据库配合存一些数据，这部分目前的开源版本还没有这么完整，会在后续完善。

Q10:同样的配置，在不同的机器上有个别配置项值不同，QConf是怎么处理？

内部这种情况多发生在不同机房的情况下，我们是在每个机房都配置一套Zookeeper集群，这样就可以不同机房不同的配置取到的值不同，不知道这种可否满足。

Q11：因为相同的服务的不同实例可能有少量配置不同，为了区分这些不同的实例可能需要给每个实例分配一个id以便在管理端区别对待。QConf 中有没有遇到这种问题？是怎么处理的呢？id 是由管理端分配还是服务实例自动生成？

现在使用是不同的配置需要不同的配置项，把相同的配在一起。目前管理端没有做这种自动生成id，不过Zookeeper有类似功能，可以具体讨论下，如果比较常见的话，我们可以考虑支持的。

Q12：dump数据是怎么做的，是获取到某个时刻所有数据的镜像去dump还是边读配置边写文件？

1.dump是采用gdbm做的，所以很方便修改添加单条数据。

2.现在是每次更新或删除共享内存中的配置，就对应dump一份该条配置。

Q13：360现在Zookeeper集群的客户数达到了多大规模？之前有听说Zookeeper集群规模是有限的，到三四千个客户数就很难上去了。是这样吗？

我们总的客户端大概两三万机器，但因为每个机房都有部署Zookeeper集群，一共有51个机房，所以单个上面的压力还好，Zookeeper主要是Watcher的消耗，现在主力机房有Watcher过两万的，这些会用配置较好的实体机，一般机房虚机就够了。

Q14：Zookeeper的Znode多了会影响性能吗？配置文件是按组来存在Znode的Value中，还是说每个配置项就是一个Znode，那样会很多吧？

单个配置就是个Znode，Zookeeper在几十万的Path级别内没有性能问题，现在主力机房有Znode达到2万，没问题，不过如果Wather比较多的话会很吃内存，另外快照文件生成较多，最好定时清理。

Q15：Zookeeper丢失通知可以感知到吗？

1.Watcher触发过程中的变化，客户端感知不到，所以Agent每次收到通知都会去取数据并重新注册Watcher。

2.如果是端或者网络的问题会导致Zookeeper会话失效，重连的时候Aagent会把需要的节点都重新拉一遍。

3.其他丢失情况较小，Agent的Scan操作就是以防这种情况的，大概半个小时到一个小时一次。

Q16：监控到一个Zookeeper挂掉了，它会不会自动切换到另一个？还是要重新手动部署？

不用，zk集群只要有一半以上的机器存活就能正常提供服务。

感谢四正的记录与整理，其他多位编辑组志愿者对本文亦有贡献。更多关于架构方面的内容，请长按下面图片，关注“高可用架构”公众号，获取通往架构师的宝贵经验。