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

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

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

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

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、获取配置更新同步流程

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

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支持配置变化时调用用户脚本。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

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

图片转存中…(img-DwW3sP22-1715366021358)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

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