我跟同事之间一次关于“架构设计”的嘴炮，大家一起听听...

一、前情提示

上一篇文章《百亿级流量的系统架构该怎么设计，今天就来教会你！》分析了一下如何利用消息中间件对系统进行解耦处理。

同时，我们也提到了使用消息中间件还有利于一份数据被多个系统同时订阅，供多个系统来使用于不同的目的。

目前的一个架构如下图所示。

在这个图里，我们可以清晰的看到，实时计算平台发布的一份数据到消息中间件里，接着，会进行如下步骤：

1. 数据查询平台，会订阅这份数据，并落入自己本地的数据库集群和缓存集群里，接着对外提供数据查询的服务
2. 数据质量监控系统，会对计算结果按照一定的业务规则进行监控，如果发现有数据计算错误，则会立马进行报警
3. 数据链路追踪系统，会采集计算结果作为一个链路节点，同时对一条数据的整个完整计算链路都进行采集并组装出来一系列的数据计算链路落地存储，最后如果某个数据计算错误了，就可以立马通过计算链路进行回溯排查问题

因此上述场景中，使用消息中间件一来可以解耦，二来还可以实现消息“Pub/Sub”模型，实现消息的发布与订阅。

这篇文章，咱们就来看看，假如说基于RabbitMQ作为消息中间件，如何实现一份数据被多个系统同时订阅的“Pub/Sub”模型。

---

二、基于消息中间件的队列消费模型

上面那个图，其实就是采用的RabbitMQ最基本的队列消费模型的支持。

也就是说，你可以理解为RabbitMQ内部有一个队列，生产者不断的发送数据到队列里，消息按照先后顺序进入队列中排队。

接着，假设队列里有4条数据，然后我们有2个消费者一起消费这个队列的数据。

此时每个消费者会均匀的被分配到2条数据，也就是说4条数据会均匀的分配给各个消费者，每个消费者只不过是处理一部分数据罢了，这个就是典型的队列消费模型。

如果有同学对这块基于RabbitMQ如何实现有点不太清楚的话，