订阅发布道Redis渐行渐远（redis订阅发布断开）

自从Redis的发布/订阅功能推出以来，它成为了许多应用程序实现实时消息传递的首选方式。市面上的许多实时交互式应用程序，如在线聊天和股票市场报价等，都使用Redis作为其实时消息传递中心。然而，随着云计算和微服务的兴起，Redis的订阅发布模式正在逐渐退出历史舞台。

Redis订阅发布模式

Redis发布/订阅模式通过将订阅者绑定到一个频道来实现发布和订阅消息。发布者可以向某个频道发布消息，而所有订阅该频道的订阅者都可以接收到该消息。例如，在一个聊天室应用程序中，当一个用户发送一条消息时，它将通过Redis发布到适当的频道，所有连接到该聊天室的订阅者都会立即接收到消息。

使用Redis实现发布订阅可以实现高效的实时消息传递，Redis的性能优秀、可靠性高，非常适用于网络应用程序中消息传递的场景。

Redis订阅发布的问题

虽然Redis发布订阅功能在分布式应用程序中实时消息传递方面有很好的效果，但在大规模和复杂度更高的微服务和云计算应用程序中，Redis订阅发布的问题也日益明显。

Redis的订阅发布模式需要频道名称预定义，这意味着在订阅者向通道订阅新的消息类型时需要更新应用程序代码。在订阅频道前必须运行代码或配置文件，这是不利于一个动态变化的云环境。

另外，Redis发布订阅模式只支持单个频道的订阅者，在复杂的应用程序中需要监视的频道数量可能会非常大。如果一个订阅者需要监视多个频道，那么它将需要一直保持活跃状态，这将导致高水平的资源消耗。

Redis的订阅发布模式不适合用于现代微服务和云计算应用程序中的实时消息传递场景。在这些应用程序中，更适合使用构建在事件总线之上的消息传递系统。

事件总线的优势

事件总线是一个分布式架构模式，在应用程序中被用于高吞吐量、实时数据传输、复杂事件处理等场景。事件总线允许许多应用程序分别发布和订阅事件，这些事件可以在整个架构中自由传递。

相对于Redis的订阅发布模式，事件总线提供了许多优势。事件总线可以收集、过滤和传递大量事件，它允许发布者发布事件，而无需知道哪些订阅者将接收到该事件，并且所有的事件都可以自由传播。

事件总线架构允许发布者将事件发送到任意数量的订阅者，而不需要在订阅者和事件之间建立固定的关系。

在事件总线模式下，发布者和订阅者之间的消息传递模式更加灵活，同时更具可靠性。如果订阅者无法处理接收到的事件，它们可以将事件重新发送到事件总线中，而不是阻塞所有频道。

使用RabbitMQ实现事件总线

RabbitMQ是一个典型的实现事件总线能力的消息代理系统。RabbitMQ允许发布者将消息推送到队列中，而订阅者则可以在队列中接收这些消息。由于采用了消息队列的方式，订阅者可以按照自己的速度消费消息，这也就保证了可靠性和效率。

使用RabbitMQ实现事件总线的流程如下：

1. 建立连接对象，建立队列并设置相应的路由规则；

2. 对所有需要发布的消息进行序列化，并将其发送到队列中去；

3. 订阅者连接并监听队列，从队列中读取消息并进行反序列化；

4. 订阅者处理完毕消息后，可以向其它队列发送相应的事件，以便其它订阅者能够接收到相应的事件。

结语

随着云计算和微服务的快速发展，使用Redis作为发布/订阅模式的消息中心已经逐渐退役，事件总线成为了更为适用的解决方案。RabbitMQ作为一个优秀的消息代理系统，实现了事件总线所需的所有功能，同时具有高效、可靠等优势，已经成为了越来越多企业的选择。