Elastic-Job项目源码分析5 -- 事件追踪

距离上次源码分析，隔了很长时间，今天终于有时间和大家继续分享EJ中事件追踪的设计思路。

白手起家

如果让你设计一个追踪job执行状态的事件流，你怎么做？

你可能会这样设计，在Job执行前插入DB，异常时插入DB，执行完时插入DB记录。主题思路是没有问题，但是，这里涉及到如何不影响Job执行流程，让追踪过程对Job无侵入性。这就是今天的重点

知识点

线程池

观察者模式

Guava中

EventBus

AsyncEventBus

源码分析

总体流程

关键点已用红色框标出，这里是异步的，来看看代码

总体模块

event相关的模块都在这里，包括DB操作都在这里

初始化

这里传递了一个jobEventConfig，实际上就是rdb相关的配置；我们来看下初始化JobEventBus构造函数



看到箭头指的内容没有，群里好多朋友在问，事件执行器启动了多少个线程，默认情况下是

CPU

个数的两倍。

这里创建了一个事件总线EventBus，同时使用了异步总线，这样就不会影响主流程的执行。关于AsyncEventBus的相关内容，请自行参考Guava相关示例或google。总线创建好了，这时我们就需要注册监听器了



这里创建Listener时，会初始化DB相关脚本，这就是你们为什么没有找到sql文件的原因了







OK，很简单吧，我们来看下这个Listener，是不是只是简单的接口定义



重点：

@Subscribe

@AllowConcurrentEvents

，这时guava中提供的，用来执行Listener中的方法，只要带上

@Subscribe

就会被扫描到。

触发

这是低层次API；高层次API由

LiteJobFacade

、

CloudJobFacade

进行装饰后调用



包括

AbstractElasticJobExecutor

中的

jobFacade.post*

都是触发相关事件