在 Celery 中，除了远程控制之外，还有一个元素可以让我们对分布式中的任务的状态有所掌控，而且从实际意义上来说，这个元素对 Celery 更为重要，这就是在本文中将要说到的 Event。
在 Celery 中，注册了很多的 Event，这些 Event 将会在 Task/Worker 的状态发生变化的时候被发出，然后被绑定的 Event 消费者（Receiver）所接受，绑定的 Event 消费者可以是一连串的回调函数，相信细心的同学在前面的源码解析过程中也有发现一些关于 event 的蛛丝马迹，但是，我都是忽略了先，下面就正式得给大家介绍 Event。
Event 有什么用前面说了，Celery 在 Task/Worker 的状态发生变化的时候就会发出 Event，所以，一个很明显的应用就是监控 Event 的状态，例如 Celery 大家所熟知的基于 WebUI 的管理工具 flower 就用到了 Event，但是，这也是一个比较明显的应用，除此之外，我们还可以利用 Event 来给 Task 做快照，甚至实时对 Task 的状态转变做出响应，例如任务失败之后触发报警，任务成功之后执行被依赖的任务等等，总结一下，其实就是：
对 Task 的状态做快照
对 Task 的状态做实时处理
监控 Celery（Worker/Task） 的执行状态
Event 的实现了解完 Event 的功能之后，我们这里直接跳过了 Event 的使用实例，因为这个可以不用实例，而是我们根据前面的介绍，然后我们就明白了需要了解一下：
Event 是如何产生的
Event 的传递机制是如何实现的
Event 的处理机制如何
我也将遵循这几个问题的顺序对 Celery 的实现进行一个总结。
Event 是如何产生的现在我们已经知道了 Event 是 Task/Worker 产生的，所以出处必然在这些实现中，这就毫无难度了。不妨，我们就从最简单的地方出发，看看 Worker 的 Event 是如何产生的，据我所知，现在 Worker 拥有的 Event 有三个：
worker-online
worker-heartbeat
worker-offline
对于 worker-online 那么应该就是在 Worker 的启动过程中，所以我们还是回到第一篇文章中的介绍，看看里面有什么可以参考的。如果你回去看了的话，肯定会发现 Consumer 这个 Blueprint 里面有一个叫做 Event 的 Bootstep，这里很可疑，不妨去看看：
well，这里看上去没啥有意思的，但是，看 Line 26 我们可以肯定的一点是 Event 是否可用还会取决于我们是否允许 gossip，这个是啥我们还不知道，但是无妨，先继续看下去，这里还有一个东西值得我们关注，那就是 event_dispatcher，但是这里还没啥可看的，毕竟是 None 嘛。
我们只是看到了冰山一角，继续看看 start 又在干嘛：
这里第一句上来就是 close，有点蒙蔽啊，啥都不知道你就先上来 close 了，是不是很被动，没关系，我告诉你这里是干啥的，这里就是清除 Celery 之前的 event_dispatcher，然后将之前的 event_dispatcher 返回回来，返回来干啥？在 Line 47 会根据之前的配置设置新的 event_dispatcher 啊，至于你先知道 event_dispatcher 是啥，看 Line 36 就知道啦，可以看到这就是一个 Dispatcher 的对象，所以我们需要关注一下这个对象了。
但是由于 Dispatcher 这个类太复杂，我就不一一摊开讲了，不妨看看我们需要面对的几个方法，第一个是 extend_buffer，看看：
这里的 _outbound_buffer 是一个 deque，所以我们可以知道其实就是将旧的 event 继承过来，替别人背一下锅。继续看看 flush 在干些啥：
哟，这个稍微复杂点了，但是无妨，还是要看看，Line 204 这里只是简单得将 deque 转换为 list，然后 Line 207 、208 这里有点意思啦，这里就是发送 Event 了！！！难道我们已经完成任务了？已经发现了如何产生消息了？但是，马上我们在后面又发现了还有一个 groups 的东西，这里发送消息又不一样？不管了，先来看看 _publish 干啥：