【开源周荐】分布式配置管理神器Qihoo360/QConf入门指北（部署、配置、使用、架构原理）

文章目录

一、前言
二、部署和配置
- 1、部署ZooKeeper
- 2、连接zookeeper客户端
- 3、部署Qconf
- 4、测试获取配置
- 5、Qconf配置文件
三、SDK获取配置
四、架构与原理
- 1、QConf的特点
- 2、整体架构
- 3、QConf客户端qconf_agent
- 4、获取配置更新同步流程
- 5、QConf如何保证数据正确性
- 6、qconf_agent线程分工
- 7、QConf简单实现服务发现
五、要点总结

一、前言

在日常开发中，会涉及到很多配置信息，如数据库配置（ip、port、username、passwaord、最大连接数等），日志配置（输出路径、清理时间、level），以及自定义配置等，这些配置可能经常发生变化，如果写死在代码里，每次变更都需要修改到代码，并且提交、编译、上线等一套操作极其复杂，且容易出错。

所以将可变部分解耦，放到配置文件里（.yml、.xml），如springboot、springmvc等项目里会有一个resources目录，该目录下可以放一些配置文件，编译打包时可以和源码一起打包成一个jar，此时有改配置也不需要修改到源码，但是还是需要重新打包上线。也有一些配置直接放在机器本地，通过绝对路径读取，一个服务可能部署在多台机器，一份配置可能分布在不同机器，同步和修改都加大了运维成本。

QConf就是为了解决以上问题而诞生的。QConf是Qihoo360的开源项目，其致力于将配置内容从代码中完全解耦，并提供可靠高效的配置访问和更新服务。QConf在360内部主要承担配置管理和服务注册发现的角色，基本覆盖了公司大大小小业务，上万台机器，稳定运行至今。

二、部署和配置

学一门技术，首先就是用起来。QConf依赖ZooKeeper存储配置，需要先部署ZooKeeper，因为二者都是开箱即用的工具，所以部署过程很简单。

1、部署ZooKeeper

一般情况ZooKeeper、QConf等工具安装在/usr/local/目录下。顺序执行如下命令即可安装ZooKeeper：

cd /usr/lcoal
mkdir zookeeper
cd zookeeper
# 下载zookeeper，可访问https://mirrors.cnnic.cn/apache/zookeeper获取不同版本的下载链接
wget https://mirrors.cnnic.cn/apache/zookeeper/zookeeper-3.7.0/apache-zookeeper-3.7.0-bin.tar.gz
# 解压
tar -zxvf apache-zookeeper-3.7.0-bin.tar.gz
# cp一份配置
cd apache-zookeeper-3.7.0-bin/conf && cp zoo_sample.cfg zoo.cfg
# 启动zookeeper 默认启动端口2181，单机版
cd ../bin && sh zkServer.sh start
# 指定配置启动
sh zkServer.sh start /usr/local/zookeeper/apache-zookeeper-3.7.0-bin/conf/zoo-3.cfg
# 指定配置重启
sh zkServer.sh restart /usr/local/zookeeper/apache-zookeeper-3.7.0-bin/conf/zoo-3.cfg
# 其他可行命令
stop、status、help  ...

需要注意：

ZooKeeper运行需要JDK环境。
如果个人资源有限，只有一台服务器的话，可以部署伪集群ZooKeeper，奇数，至少3个实例。

2、连接zookeeper客户端

ZooKeeper安装完毕后，需要加一些测试数据，同时也可以验证下刚才是否安装成功：

# 连接客户端，默认连接2181
sh zkCli.sh
# 指定服务端连接
sh zkCli.sh -server 127.0.0.1:2191

连接客户端后，如果显示CONNECTED，就说明安装成功了。

执行如下命令，创建一些测试数据：

create /demo demo
create /demo/confs confs
create /demo/confs/conf1 111111111111111111111
create /demo/confs/conf2 222222222222222222222
create /demo/confs/conf3 333333333333333333333

3、部署Qconf

Qconf的部署方式有两种，一种源码方式，一种是下载已经编译好的rpm包，后者更简单。这里只介绍rpm方式：

访问该链接，获取最新rpm包https://github.com/Qihoo360/QConf/releases，顺序执行如下命令进行安装：

cd /usr/lcoal
mkdir qconf
cd qconf
# 下载
wgethttps://github.com/Qihoo360/QConf/releases/download/1.2.1/QConf-1.2.1-1.el6.x86_64.rpm
# 安装
rpm -ivh QConf-1.2.1-1.el6.x86_64.rpm
# 启动qconf-agent
cd /usr/local/qconf
cd bin && sh agent-cmd.sh start
# 环境配置，这样在各个目录都可以执行qonf的命令
vim /etc/profile
# 将如下配置复制到profile最后面即可
#qconf
QCONF_HOME=/usr/local/qconf
PATH=$QCONF_HOME/bin:$PATH
export QCONF_HOME
export PATH

4、测试获取配置

Qconf提供了如下可选命令：

qconf get_conf xxx ，获取xxx的配置内容。
qconf get_batch_keys xxx，批量获取xxx的子项目。
qconf get_host和qconf get_allhost 和服务发现有关。

qconf get_conf /demo/confs/conf1
qconf get_batch_keys /demo/confs

5、Qconf配置文件

Qconf的配置比较少也相对简单：

（1）agent.conf，qconf_agent的配置：

qconf_agent启动时会自动给zk注册一个临时节点（register_node_prefix=/qconf/__qconf_register_hosts），qconf_agent停止了，对应的zk临时节点也会自动清除，所以可以根据这个特性，判断qconf_agent是否存活。

基本逻辑是，定时获取zk/qconf/__qconf_register_hosts下hostname列表和现有的hostname列表进行对比，不在/qconf/__qconf_register_hosts里则认为该机器上的qconf_agent未运行。

（2）idc.conf，配置zk集群（这里配置了两个集群环境，一个test，一个dev，那Qconf是使用哪个集群呢？）：

（3）localidc，指定qconf当前使用的zk集群环境：

三、SDK获取配置

Qconf支持c/c++, shell, php, python, lua, java, go, node等语言获取配置，这里只介绍java方式，其他方式可参考官方文档：

<dependency><groupId>qconf-client</groupId><artifactId>qconf-client</artifactId><version>1.2.2</version>
</dependency>

// 导包
import net.qihoo.qconf.Qconf;
import net.qihoo.qconf.QconfException;// 方法
// get configure value
String value = Qconf.getConf("demo/confs");
// get all children nodes'key
ArrayList keys = Qconf.getBatchKeys("demo/confs");
// get all children nodes' key and value
Map<String, String> confs = Qconf.getBatchConf("demo/confs");
//... ...

注意：

网上mvn仓库好像下载不到qconf-client。如有需要，可通过如下百度网盘链接获取：

链接：https://pan.baidu.com/s/1bATv3Bqo2P5Ly3RfLPafjg
提取码：yyds

四、架构与原理

QConf一开始对配置管理的定位，就是解耦配置和代码，让配置更简单高效，使得整个架构非常简单，且容易部署和使用。

QConf使用ZooKeeper服务器存储所有的配置信息。众所周知，ZooKeeper的存储是树状的，类似于文件目录的形式，所以QConf配置名为ZooKeeper的节点名，配置项的值为ZooKeeper的节点值。

而主要选择ZooKeeper作为配置存储的原因是，ZooKeeper的监听回调机制。客户端可以向ZooKeeper服务端注册感兴趣的事件监听(watcher)，这些事件包括：节点被创建(ZOO_CREATED_EVENT)、节点被删除(ZOO_DELETED_EVENT)、节点值改变(ZOO_CHANGED_EVENT)、子节点变化(ZOO_CHILD_EVENT)、客户端断开或重新连接(ZOO_SESSION_EVENT)等，一旦这些事件发生，ZooKeeper服务端就会通知客户端，执行客户端注册的回调函数。

QConf就是利用ZooKeeper的监听回调机制，实现配置及时更新和同步。

1、QConf的特点

因为QConf的定位和技术选型，它具备以下特点：

单条配置不宜太大，受ZooKeeper节点限制，最大为1MB。
读取配置低延迟，性能高。
配置更新，可以几秒内同步更新到所有机器。
适合读多写少场景。
安装部署方便，使用简单。
支持c/c++、shell、php、python、lua、java、go、node 等语言。

2、整体架构

如下图，是QConf实际生产中的基本架构，包括顶端的QConf管理端、部署Zookeeper的服务端，以及QConf的客户端。

从下往上说，QConf客户端，已开源，基本无需改造，就是上面部署的qconf_agent。主要负责与ZooKeeper服务端交互，比如获取配置，监听配置更新缓存等。QConf服务端，就是ZooKeeper集群了，至少3台实例，保证高可用和数据强一致性（CP）。

QConf的管理端，现开源的管理端比较简陋，可以根据实际情况自行开发，主要功能包括：配置的增删改查以及QConf客户端的监控。配置可以双写Mysql和ZooKeeper，配置的修改可以加版本控制（发布单），按流程发布更新配置，有问题就回滚，实现配置的平滑管理。同时管理端还需要提供HTTP获取配置的方式，使配置的使用更方便。（qconf_agent获取配置只能本机获取）

3、QConf客户端qconf_agent

ZooKeeper对外提供的接口非常原生简单，所以qconf_agent主要封装了对ZooKeeper的交互，监听配置更新同步，同时为了提高容错和性能，加了一层本地缓存（配置信息在共享内存里以哈希表的形式存储），使得配置获取为内存级别的访问速度。每次获取配置如果本地缓存中有就直接返回，没有才向ZooKeeper发网络请求获取配置（这个过程也是异步的），并更新到共享内存，这样大大降低了ZooKeeper的压力。即使网络中断，ZooKeeper集群故障不可用，也可以短时间内读取QConf的本地缓存对外提供服务。

4、获取配置更新同步流程

业务进程调用某一种语言的QConf接口，从共享内存(Share Memory)中查找需要的配置信息。
如果存在，直接获取，否则会向消息队列(Message Queue)中加入该配置key。
qconf_agent从消息队列中感知需要获取的配置key。
qconf_agent向ZooKeeper查询数据并注册监听。
qconf_agent将获得的配置value序列化后放入共享内存。
业务进程等待，直到共享内存里出现所要读取的配置，然后从共享内存中获得最新值返回。

5、QConf如何保证数据正确性

qconf_agent读写配置缓存是无锁的，那如何保证多线程下数据正确性呢？

（1）单点写

qconf_agent涉及更新配置缓存的场景有：

用户进程获取配置缓存中没有，将配置key放到消息队列。
ZooKeeper配置修改删除等触发Watcher通知，需更新缓存。
防止Watcher丢失造成数据不一致，需要定时对共享内存中所有配置重新注册Watcher，此时可能会更新缓存。
发生qconf_agent重启、网络中断、ZooKeeper会话过期等异常情况，需重新拉数据，此时可能需要更新缓存。（数据落盘，应对断网情况下共享内存被清空的状况）

写操作基本属于内部异步触发，并发不是很大，可以将所有的写操作放到一个队列里，让一个线程去执行，保证写操作的顺序性和原子性。这样会牺牲一些性能，但问题不大，用户基本不会感知。

（2）读验证

无锁的读写方式，会存在读到未写入完全数据的危险，但考虑到在绝对的读多写少环境中这种情况发生的概率较低，所以允许其发生，通过读操作时验证来尽量避免。

配置在序列化存储到共享内存时会计算md5值，业务进程读取配置时，利用预存的md5值验证数据是否正确。由于计算md5开销比较大，所以最新实现方法对于将要放入共享内存的数据，如果小于某一值（当前设置为1500）就将数据本身复制一份作为验证码，如果大于设定值还是采用md5。

6、qconf_agent线程分工

（1）Send线程：ZooKeeper线程，处理网络数据包，进行协议包的解析与封装，并将Zookeeper的事件加入WaitingEvent队列等待处理。

（2）Event线程：ZooKeeper线程，依次获取WaitingEvent队列中的事件，并进行相应处理，这里只需要关注节点删除、节点值修改、子节点变化、会话过期等事件。以节点值修改为例，qconf_agent序列化该节点key，并将其加入到WaitingWriting队列，等待Main线程处理。

（3）Main线程：共享内存的唯一写入线程，从Zookeeper获得数据写入共享内存，维护共享内存中的内容。

（4）Msq线程：用户进程从共享内存中找不到配置时，会向消息队列中加入该配置key，Msq线程便是负责从消息队列中获取配置key，加入到WaitingWriting队列发送给Main线程；

（5）Scan线程：扫描共享内存中的所有配置，发现与Zookeeper不一致的情况时，将key值加入WaitingWriting队列。Scan线程会在ZooKeeper重连或轮询期到达时进行上述操作；

（6）Trigger线程：该线程负责一些周边逻辑的调用，包括：

dump操作：将共享内存的内容同步一份到本地，QConf采用的是gdbm。
feedback操作：QConf支持更新反馈的功能，可向用户指定web服务以一定的格式发送反馈。
script操作：在某些情况下，业务希望当配置变化时，做一些自定义的操作，QConf支持配置变化时调用用户脚本。

7、QConf简单实现服务发现

QConf除了配置管理的基本功能外，还提供了一套简单的服务发现功能，该功能允许业务在QConf上配置一组服务，QConf会监控其服务的存活。当业务进程调用获取服务的接口时，会根据用户需求，返回全部可用服务（get_allhost），或某一可用服务（get_host）。

结构上多了一个Monitor的角色，来监控所有服务的存活：

开源的Monitor仅仅是通过查看服务端口的存活来判断的，实际生产环境中，判断因素较复杂，比如服务监控，异常数，流量等。

实际生产中可以利用Qconf提供的简单服务发现功能基础上进行改造，也可以自行实现监控服务判活的服务，依然用QCconf的简单配置，服务发现的集群标识解析成一个目录，这个目录下包含该集群的所有ip:port，可作为配置key，服务的状态作为配置value。

五、要点总结

QConf是一个不错的配置管理工具，容易部署，使用简单。其架构设计理念有很多值得学习的地方：

QConf使用ZooKeeper服务器存储所有的配置信息，配置名为zk的节点名，配置项的值为zk的节点值。
QConf利用ZooKeeper的监听回调机制，注册感兴趣的事件监听(watcher)，实现配置及时更新和同步。
QConf高效和高可用设计思路体现在很多地方，比如无锁化读写、共享缓存、消息队列等。业务进程读取配置不会直接和zk或者qconf_agent进行交互，完全异步，全权交由qconf_agent的异步线程做配置监听和更新操作。
无锁的读写方式，会存在读到未写入完全数据的危险，为了保证数据正确性，qconf_agent采用了两个措施：单点写，集中一个线程做写操作，保证写顺序性和原子性；读验证，共享内存数据在序列化时会带其md5值，业务进程从共享内存中读取时，利用预存的md5值验证是否正确读取。

因为QConf是C语言写的，暂时看不懂源码，所以很多原理概念都是理解官方文档后整理，同时官方文档有些措辞上不太通顺，部署文档中给的安装包较旧，文档较乱、冗杂，所以通读后整理，有些地方写的很好，很精炼，就直接摘抄过来了，所有关于原理的图片均来自官方文档。非常感谢Qihoo360/QConf，学到很多优秀的架构理念。

官方文档：

https://github.com/Qihoo360/QConf
从配置文件到分布式配置管理QConf

如若文章有错误理解，欢迎批评指正，同时非常期待你的评论、点赞和收藏。