Skip to content
MengDe Li edited this page Jul 26, 2017 · 16 revisions

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.gzhttp://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集群只要有一半以上的机器存活就能正常提供服务。

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