从用户触发Build cube 到build 完成触发实体"cube"广播一整个流程源码追踪。
用户提交Build cube请求
——》Kylin生成相关Job并持久化([参见Kylin Cube 构建源码分析-生成job并持久化](https://blog.csdn.net/wangxiaojing123/article/details/89060673))
——》Kylin build引擎开始执行刚刚提交的job
——》执行job中的createUpdateCubeInfoAfterBuildStep这一步
——》UpdateCubeInfoAfterBuildStep.doWork
——》cubeManager.promoteNewlyBuiltSegments(cube, segment)
——》cubeManager.updateCubeWithRetry——》CachedCrudAssist.save
——》SingleValueCache.put——》Broadcaster.announce(添加到事件队列broadcastEvents中("cube","update",本次build的cube的名称如"es_report_respnse_rate_cube"))
——》Broadcaster私有构造方法中消费事件队列
- Step1:Kylin生成相关Job并持久化:
- Step2: Kylin build引擎开始执行刚刚提交的job:
与autoMerge segments相关主要是job中createUpdateCubeInfoAfterBuildStep这一步
- Step3: cubeManager.promoteNewlyBuiltSegments
继续追踪
继续追踪
Step4: CachedCrudAssist.save方法:
- step5: cache.put方法
syncEntity:cube
type:update
key:本次build的cube的名称如"es_report_respnse_rate_cube"
cubeManger实例化代码,贴出这张图主要是交代这个缓存的实体为cube
Step6:放入事件队列
- Step7: 消费事件队列
Broadcaster的私有构造方法(单例模式),启动一个线程一直轮训事件队列,用于消费事件队列
实际就是通过http通知目的节点,调用其cacheController中的cache方法
- Step8: 目标节点的CacheController
继续追踪:cacheService.notifyMetadataChange方法
继续追踪
- Step9: 真正执行各个监听器的代码:
调用Broadcaster.notifyListener(String entity, Event event, String cacheKey, boolean includeStatic)方法
- Step10: 接下来咱们看下哪些listener注册了实体"cube"的监听,即listenerMap和staticListenerMap中key=cube的有哪些
注册了静态staticListenerMap的listener:
注册了普通staticListenerMap的listener:
通过上面两图咱们知道注册了"cube"实体的listener如下:
/*这些listner多时在tomcat启动的时候或者第一次实例化的时候放入listenerMap和staticListenerMap中,
具体可以参考 https://blog.csdn.net/wangxiaojing123/article/details/90451660 */
listenerMap: CubeSyncListener、HybridSyncListener;
staticListenerMap:cacheSyncListener(CacheService中cacheSyncListener=new Broadcaster.Listener())、HTableInfoSyncListener、CuboidRecommenderSyncListener。
找到了对应实体”cube“的监听方法,咱们只需要看这些listener对应的方法即可:接下来咱们主要看下cubeService中注册的静态listener中的cacheSyncListener.onEntityChange方法:
keepCubeRetention方法:
mergeCubeSegment方法:
后续的执行就和普通的job一样,参照调度引擎调度job执行。至此触发autoMerge segments为例的一个广播机制全部流程分析完成。