接收器执行中的事件总线和异步

Question

我挑战自己设计和实现（在 Java 中，但仍处于设计级别）用于多线程的事件总线。未来没有计划认真使用该系统，唯一感兴趣的是挑战本身及其优化。

事件总线的设计目的是在事件触发和与其接收相关联的代码之间进行异步执行。但是，通过一个线程（EventManager）控制事件总线，我看到了两种可能的实现。

我的问题是：如果这两种实现方式哪个最好？

1) EventManager 线程调用每个订阅该事件的系统并按顺序运行其代码。 尽管在考虑发射器 - 受体时这种解决方案确实是异步的，但我们在多个受体的执行过程中仍然具有同步性。此外，如果其中一个受体功能需要时间，我们会延迟整个总线管理的执行。

2) 每个receiver系统都有自己的buffer bus，EventManager线程只把event重传给订阅的系统，成倍的使用内存（event可能同时在多个系统重写) 但解决了同步问题。

我猜在一个典型的系统（即游戏、非计算密集型软件或时间关键解决方案）中，第一个是最好的。第二个可能会占用大量内存来优化时间。

你以前有过这个问题吗？你有什么建议吗？

Answer 1

在这两者之间，您需要选择您的设计需求需要什么。

对于选项 1：

优点：

• 顺序设计（根据我的经验）更易于设计和实施
• 更易于控制和理解（因为您可以将优先级作为顺序的副作用来实现）
• 在每个受体之间传递的事件突变不需要同步，因为它是线程受限的。

缺点：

• 正如您所讨论的，如果一个受体阻断，其他串联的受体将受到影响。
• 由于顺序性，受体将无法利用并行计算。

对于选项 2：

优点：

• 受体相互独立运行（并为并行化提供更多机会）
• 只要事件一到达缓冲区就得到处理，内存就不会真正受到负面影响
• 阻塞的接收器可以使用缓冲区来存储事件以供以后处理，而不是阻塞行

缺点：

• 必须很好地协调接收器，以实施诸如事件优先级之类的事情，并确保所有接收器（即使是那些阻止并让事件排队的接收器）一起完成
• 改变事件需要客户端提交受体使用同步，以保持数据与其他受体一致

如果有的话，我个人会选择 #2 来支持性能，因为内存通常会因性能提升而受到影响。但是，如果您的目标受众不开发多线程客户端或难以执行同步，我会选择选项 #1，优先考虑安全性和可靠性。