消息总线重构之EventBus

最新推荐文章于 2024-08-10 08:00:00 发布

vinoYang

最新推荐文章于 2024-08-10 08:00:00 发布

阅读量8.4k

点赞数 2

分类专栏：【消息总线】【Java编程】基于RabbitMQ的消息总线文章标签：消息总线 java eventbus RabbitMQ

本文链接：https://blog.csdn.net/yanghua_kobe/article/details/46699205

版权

本文介绍了如何在消息总线重构中使用EventBus，包括改进广播通知和用事件驱动替代责任链模式。EventBus作为观察者模式的实现，用于在应用程序组件间实现解耦与通信。在广播通知方面，通过EventBus进行二次转发，解决了原有设计的问题。而在责任链模式的替代方案中，使用同步事件驱动方式，通过定义事件处理器按顺序执行业务逻辑，解决了原有递归链可能导致的资源占用问题。

摘要由CSDN通过智能技术生成

本人博客文章如未特别注明皆为原创！如有转载请注明出处：http://blog.csdn.net/yanghua_kobe/article/details/46699205

最近花了不少时间对消息总线进行了重构。重构的重点是在消息总线中加入了Guava的EventBus，并应用于以下两个场景：

（1）改进广播通知

（2）业务逻辑串联，用事件驱动替代责任链模式

EventBus简介

EventBus是Google的开源项目Guava里的一个组件，有兴趣的人可以看我前不久的一篇博文解读。总得来说，EventBus是观察者模型的实现，利用它你既可以实现观察者模型的业务场景，还可以基于它的事件驱动机制来实现应用程序内组件之间的解耦与通信。

改进广播通知

广播通知是消息总线提供的功能之一。在重构之前，客户端接收广播通知是通过消息总线客户端SDK的一个API来实现的：

public void setNotificationListener(IMessageReceiveListener notificationListener);

但之前的广播通知设计并不合理。它受限于之前的基于RabbitMQ的树形路由拓扑模型：

这个拓扑结构中有些只发送不接受的“虚拟队列”并不是真实存在的队列。这些消息生产者无法接收消息，这是非常大的一个缺陷。我一直在想办法重新设计它，之前的关注点都集中在RabbitMQ上，想在MQ上找到一种解决方案，但这很难，除非摈弃“虚拟队列”的设计。于是，我将关注点转移到消息总线中另一个可以提供pub/sub的组件上（后称之为pubsuber），该组件目前可以是redis也可以是zookeeper。因为每个client（更准确得说是每个创建client的pool）都会以长连接的方式挂在pubsuber上。所以，它本身就是一个很不错的广播渠道，并且因为它脱离RabbitMQ单独实现，跟虚拟队列的设计不相冲突。

上面的思路没有问题，但语义与实现上并不对等。通知的收发从语义上来说应该是Client API级别的。而PubSuber接收到的广播事件却是Pool级别的，并不依赖client（Pool创建PubSuber以及Client࿰