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

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

环境配置，这样在各个目录都可以执行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命令](https://img-blog.csdnimg.cn/20210625000414241.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNjU4NjEyMA==,size_1,color_FFFFFF,t_70#pic_center)

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

![测试qconf命令](https://img-blog.csdnimg.cn/2021062500045038.png#pic_center)


#### 5、Qconf配置文件


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


![qconf配置文件](https://img-blog.csdnimg.cn/20210625000515489.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNjU4NjEyMA==,size_1,color_FFFFFF,t_70#pic_center)


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


![agent.conf](https://img-blog.csdnimg.cn/20210625000552124.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNjU4NjEyMA==,size_1,color_FFFFFF,t_70#pic_center)  
 `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`是使用哪个集群呢？）：


![idc.conf](https://img-blog.csdnimg.cn/20210625000729403.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNjU4NjEyMA==,size_1,color_FFFFFF,t_70#pic_center)


（3）localidc，指定qconf当前使用的zk集群环境：  
 ![localidc](https://img-blog.csdnimg.cn/20210625000757181.png#pic_center)


### 三、SDK获取配置


`Qconf`支持c/c++, shell, php, python, lua, java, go, node等语言获取配置，这里只介绍java方式，其他方式可参考[官方文档](https://bbs.csdn.net/topics/618545628)：

qconf-client qconf-client 1.2.2

// 导包
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整体架构](https://img-blog.csdnimg.cn/20210625000854972.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNjU4NjEyMA==,size_1,color_FFFFFF,t_70#pic_center)


从下往上说，`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`的本地缓存对外提供服务。  
 ![qconf_agent架构](https://img-blog.csdnimg.cn/20210625000929572.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNjU4NjEyMA==,size_1,color_FFFFFF,t_70#pic_center)


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


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


![获取配置更新同步流程](https://img-blog.csdnimg.cn/20210625001000272.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNjU4NjEyMA==,size_1,color_FFFFFF,t_70#pic_center)


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


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


**（1）单点写**


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


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


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


**（2）读验证**


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


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


#### 6、qconf\_agent线程分工


![qconf_agent中线程分工](https://img-blog.csdnimg.cn/20210625001044378.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNjU4NjEyMA==,size_1,color_FFFFFF,t_70#pic_center)


（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的角色，来监控所有服务的存活：


![qconf简单实现服务发现](https://img-blog.csdnimg.cn/20210625001112208.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNjU4NjEyMA==,size_1,color_FFFFFF,t_70#pic_center)


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


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


### 五、要点总结



![img](https://img-blog.csdnimg.cn/img_convert/c75f2b85f827d6875919304db218a586.png)
![img](https://img-blog.csdnimg.cn/img_convert/669521c5373d069cee8f0daf5718f6e6.png)

**网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**

**[需要这份系统化资料的朋友，可以戳这里获取](https://bbs.csdn.net/topics/618545628)**


**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**

...(img-vHRjaRNv-1715003125819)]

**网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**

**[需要这份系统化资料的朋友，可以戳这里获取](https://bbs.csdn.net/topics/618545628)**


**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**