disconf相关问题总结-结合issue，官方文档
disconf相关问题总结-结合issue，官方文档
- disconf-web
创建最新配置时，只会把配置数据落到mysql,并不会马上把数据推到zk上，而需要监听该节点的disconf-client实例启动时，如果还没有创建zk节点，则由客户端创建节点并注册watch.所以启动流程中可能遇到的问题：
image.png
- 配置文件类、配置项所在的类、回调函数类 都必须是JavaBean，并且它们的”scope” 都必须是singleton的。
- 本系统实现的注解方案具有些局限性，具体如下:
- 用户标注配置时略有些不习惯。目前注解是放在get方法之上的，而不是放在域上。
- 注解放在get方法上，一般情况下是没有问题的。但是对于”call self”的方法调用，AOP无法拦截得到，这样就无法统一处理这些配置。一旦出现这种情况，“非一致性读问题”就会产生。
- 配置“不一致性读“ 问题:应用系统的配置更新过程，它会涉及到多个配置项的更新，它不是一个原子过程。如果在配置更新的过程中，应用程序去读取配置，这里可能存在些“时间窗口”，从而导致不一致性读问题。
对于Web系统：
要实现统一读取，可以使用ThreadContext+AOP来实现。
ThreadContext的使用方式有以下几种：
解决方法一：提供ThreadContext包，在每次请求一开始时都复制系统里的所有配置缓存(复制过程要与配置更新Sync互斥)，从而保证每次会话的数据的一致性。
解决方法二：提供ThreadContext包，每次请求都绑定一个版本号，如果读取时版本号不一致则报错，需要重新请求。
解决方法三：方法二的加强版，添加一个注解定义，标注它是需要强一制性的，每次会话读取时只复制这些强一制性配置(复制过程要与配置更新Sync互斥)。
解决方法四：提供ThreadContext包，系统内保存有多个配置缓存层，读取时统一读取某个版本的缓存。每当配置更新时，缓存层增加。
第一种方法，代价太大。第二种方法，严重增加用户负担，第三种还是需要用户关心这个事情。我们将采用第四种方法。
对于非Web项目：
比较难解决非一致性读取的问题。因为它没有了会话这样一个概念。Apache的FileChangedReloadingStrategy Reload配置文件的方案也没有解决此问题。所以，我们打算放弃这方面的解决。但是，我们还是会提供一个简单却Ugly的解决方案：提供函数来标识用户读取配置的边界。用户可以放弃使用这个方案，但是我们不保证不会发生“不一致读’问题。
- disconf-web的ZK异常处理
disconf-web可以完全保证在任何情况下，与ZK集群的自动连接。
服务启动前，zk连接不上： - 开始连接不上：
- apache ZK client自身会自动(永久）去连接ZK server. 但是一直连接不上。
- 因此，web上所有操作均会失败，抛大异常，请求失败，只会重试一次，不会重试多次
- 后面突然连接上了：
- apache ZK client 收到server SyncConnected消息。
- 这时所有操作均成功
- 后面又突然连接不上了：
- apache ZK client 收到server Disconnected 消息。
- 这时，apache ZK client自身会自动(永久）去连接ZK server. 但是一直连接不上。
- 这时 web 上 所有操作均会失败，抛大异常，请求失败，只会重试一次，不会重试多次
- 后面突然连接上了：
- apache ZK client 收到server Expired 消息。
- 这时表示会话丢失啦，apache ZK client 自动断开与Server的连接，表示此时让你来处理，因为它不知道应该如何处理。
- 这时，disconf-core会reconnect zkserver，重新建立会话。
- 成功后，apache ZK client 收到server SyncConnected 消息。表示连接成功
- 后面又突然连接不上了：
- apache ZK client 收到server Disconnected 消息。
- 这时，apache ZK client自身会自动(永久）去连接ZK server. 但是一直连接不上。
- 这时 web 上 所有操作均会失败，抛大异常，请求失败，只会重试一次，不会重试多次
服务启动前，zk连接上了：
- 开始连接：
- apache ZK client 收到server SyncConnected消息。
- 这时所有操作均成功功
- 后面又突然连接不上了…… （与上面分析一样，此不再赘述）
注意
ZK一般需要以集群的形式提供出来。假设有N台ZK，
- 只要至少有一台ZK存活，disconf-web就可以正常工作。而且永远不会收到 server Expired 的消息。
- 只要有一台ZK死亡，disconf-web就会收到 Disconnected 消息。但是系统仍可以继续工作。
- 如果所有zk都死亡，那么disconf-web会收到 Disconnected 消息。只要有一台存活，disconf-web就会收到
** * disconf-client的ZK异常处理
disconf-client可以完全保证: 如果在启动程序时保证ZK集群是可用的，那么，就可以保证在任何情况下，与ZK集群的自动连接。
下面按情况进行分析：
程序启动前，zk连接不上
这时disconf-client无法在ZK上注册信息。这是必须禁止发生的情况。也是disconf-client无法支持的情况。
一旦发生这种情况，请先恢复ZK集群，再启动你的程序。
程序启动前，zk连接上了：
如果在程序启动过程中，ZK是正常的，那么，disconf-client可以保证与ZK连接的自动性。
- 只要集群有一台还存活着，你的程序配置还是受disconf托管。
- 如果集群所有机器均死亡，这时你的程序将游离于disconf之外。只要集群中有任何一台ZK机器重新开启，那么 你的程序将重新 由disconf进行托管。
@Override
public void process(WatchedEvent event) {
//
// 结点更新时
//
if (event.getType() == EventType.NodeDataChanged) {
try {
LOGGER.info("============GOT UPDATE EVENT " + event.toString() + ": (" + monitorPath + "," + keyName
+ "," + disConfigTypeEnum.getModelName() + ")======================");
// 调用回调函数, 回调函数里会重新进行监控
callback();
} catch (Exception e) {
LOGGER.error("monitor node exception. " + monitorPath, e);
}
}
//
// 结点断开连接，这时不要进行处理，表示已经断开了和zk的连接
//
if (event.getState() == KeeperState.Disconnected) {
if (!debug) {
LOGGER.warn("============GOT Disconnected EVENT " + event.toString() + ": (" + monitorPath + ","
+ keyName + "," + disConfigTypeEnum.getModelName() + ")======================");
} else {
LOGGER.debug("============DEBUG MODE: GOT Disconnected EVENT " + event.toString() + ": (" +
monitorPath +
"," +
keyName +
"," + disConfigTypeEnum.getModelName() + ")======================");
}
}
//
// session expired，需要重新关注哦
//
if (event.getState() == KeeperState.Expired) {
if (!debug) {
LOGGER.error("============GOT Expired " + event.toString() + ": (" + monitorPath + "," + keyName
+ "," + disConfigTypeEnum.getModelName() + ")======================");
// 重新连接
ZookeeperMgr.getInstance().reconnect();
callback();
} else {
LOGGER.debug("============DEBUG MODE: GOT Expired " + event.toString() + ": (" + monitorPath + ","
+ "" + keyName + "," + disConfigTypeEnum.getModelName() + ")======================");
}
}
}注意
disconf-client必须保证在程序在启动时，ZK集群的可用性。