经过对多个有关事件总线模式的文档介绍的阅读，对事件总线模式有了一定的了解，并作出如下总结：
一、 事件总线模式主要是处理事件，包括4个主要组件：事件源、事件监听器、通道和事件总线。消息源将消息发布到事件总线上的特定通道上。侦听器订阅特定的通道。侦听器会被通知消息，这些消息被发布到它们之前订阅的一个通道上。
使用场景：安卓开发、通知服务
优点：新的发布者、订阅者和连接可以很容易地添加。对高度分布式的应用程序有效。
缺点：可伸缩性可能是一个问题，因为所有消息都是通过同一事件总线进行的。
二、基于事件驱动的分布式异步架构模式多用于构建高可伸缩的反应式应用程序，适用于各种从简单到复杂的应用场景。它的核心思想是去耦合，将消息的发送和接收分开，实现异步处理消息事件。
事件总线是实现基于事件驱动模式的方式之一，或者可以将其称为“Broker Topology”。事件发送者将事件消息发送到一个中心 broker 上，事件订阅者向中心 broker 订阅和接收事件，然后再处理接收到的事件。当然，订阅者不仅可以接收和消费事件，它们本身也可以创建事件，并将它们发送到事件总线上。下面列出了 4 种事件总线的实现方式，并对它们的优缺点进行了总结。
1. 向所有的订阅者发送事件
.png)
事件总线直接将输入事件（红色箭头）发送给订阅者（蓝色方块）
参与者
事件总线、订阅者（事件处理器）、事件创建者
实现
事件创建者向事件总线发送事件，事件总线将收到的事件发送给所有的订阅者。订阅者既可以处理接收到的事件，也可以创建新事件，然后把它们发送给事件总线。事件总线不关心订阅者是否成功接收到消息。
功能需求
通知、订阅、退订。
优势
实现起来很简单。
不足
事件总线需要将每一个事件消息复制一份给订阅者，也就是说，如果有1000个订阅者，每一个事件都会有1000份拷贝，这样会占用大量的内存。
事件总线不保证消息传递的可靠性，它会尝试给订阅者发送消息，而且只会尝试一次，如果出现错误，比如网络连接错误，订阅者可能就会收不到消息。
另外，事件总线不负责过滤消息，所以订阅者需要自己实现过滤逻辑。
2. 向所有订阅者发送事件影子
.png)
事件总线和事件存储及事件观察者
参与者
事件总线、事件创建者、订阅者、事件存储（Event Store）、事件观察者（Event Watcher）
实现
事件总线在收到事件创建者发送过来的事件后，把事件保存到事件存储里，然后将事件影子（Event Shadow，也就是对原始事件的引用）发送给所有的订阅者。订阅者根据事件影子从事件存储里获取事件数据，再对数据进行处理。
事件总线为每一个事件创建一个事件观察者，观察者持有订阅者列表，当所有的订阅者都接收到消息后，观察者负责把事件从事件存储里删除。
事件总线仍然不保证订阅者一定会收到所有事件影子。如果有订阅者接收消息失败，相应的观察者就会被标记为“skipped”。
功能需求
通知、订阅、退订、保存/删除/获取、标记完成/跳过
优势
因为事件消息被保存在事件存储里，发送给订阅者的只是事件引用，所以占用内存会小很多。
不足
订阅者需要调用额外的方法，比如在收到事件影子之后要调用方法去获取事件数据，在处理完事件后还要调用方法通知事件总线已完成处理，或者通知事件总线跳过某个事件。另外，在事件总线端还要实现事件存储和事件观察者。这个对事件存储的实现要求比较高，如果订阅者数量很多，事件存储的读负载会很重，而且在写入事件时是阻塞式的。
这种实现方式仍然不会为订阅者过滤事件，所以订阅者还是需要自己实现事件过滤。
3. 向经过过滤的订阅者发送事件影子
第三种实现方式与第二种是一样的，只不过不是将事件影子发送给所有订阅者，而是发送给经过过滤的订阅者，也就是说只发送给其中的一部分订阅者。事件总线需要记录订阅者感兴趣的主题，在这里可以使用正则过滤器为订阅者过滤主题。
这种方式的优势与不足和第二种也是一样的，只是多了事件过滤功能。
4. 按顺序传递
为了保证顺序传递，可以对事件进行分区。关于如何通过分区来保证顺序传递，可以参考Kafka的论文，基本原理是让消费者消费属于自己的分区。
不足
动态增加分区或减少分区会变得很困难，而且需要自己实现分区器，消费者的实现也很复杂。