NOTE
搬运文章,原创作者:http://joshuablog.herokuapp.com/
Just for study purpose, I don’t hold the copyright, if this is affecting anyone, please let me know.
应用场景
- 信息的发送者和接收者如何维持这个连接,如果一方的连接中断,这期间的数据如何方式丢失?
- 如何降低发送者和接收者的耦合度?
- 如何让 Priority 高的接收者先接到数据?
- 如何做到 load balance?有效均衡接收者的负载?
- 如何有效的将数据发送到相关的接收者?也就是说将接收者 subscribe 不同的数据,如何做有效的 filter。
- 如何做到可扩展,甚至将这个通信模块发到 cluster 上?
- 如何保证接收者接收到了完整,正确的数据?
架构
基础
RabbitMQ Server: 也叫 broker server,它不是运送食物的卡车,而是一种传输服务。原话是 RabbitMQisn’t a food truck, it’s a delivery service. 他的角色就是维护一条从 Producer 到 Consumer 的路线,保证数据能够按照指定的方式进行传输。但是这个保证也不是 100% 的保证,但是对于普通的应用来说这已经足够了。当然对于商业系统来说,可以再做一层数据一致性的 guard,就可以彻底保证系统的一致性了。
Client P: 也叫 Producer,数据的发送方。createmessages and publish (send) them to a broker server (RabbitMQ). 一个 Message 有两个部分:payload(有效载荷)和 label(标签)。payload 顾名思义就是传输的数据。label 是 exchange 的名字或者说是一个 tag,它描述了 payload,而且 RabbitMQ 也是通过这个 label 来决定把这个 Message 发给哪个 Consumer。AMQP 仅仅描述了 label,而 RabbitMQ 决定了如何使用这个 label 的规则。
Client C: 也叫 Consumer,数据的接收方。Consumersattach to a broker server (RabbitMQ) and subscribe to a queue。把 queue 比作是一个有名字的邮箱。当有 Message 到达某个邮箱后,RabbitMQ 把它发送给它的某个订阅者即 Consumer。当然可能会把同一个 Message 发送给很多的 Consumer。在这个 Message 中,只有 payload,label 已经被删掉了。对于 Consumer 来说,它是不知道谁发送的这个信息的。就是协议本身不支持。但是当然了如果 Producer 发送的 payload 包含了 Producer 的信息就另当别论了。
Exchanges are where producers publish their messages.
Queues are where the messages end up and are received by consumers
Bindings are how the messages get routed from the exchange to particular queues.
Routing Key: 路由关键字,exchange 根据这个关键字进行消息投递。
Message acknowledgment
在实际应用中,可能会发生消费者收到 Queue 中的消息,但没有处理完成就宕机(或出现其他意外)的情况,这种情况下就可能会导致消息丢失。为了避免这种情况发生,我们可以要求消费者在消费完消息后发送一个回执给 RabbitMQ,RabbitMQ 收到消息回执(Message acknowledgment)后才将该消息从 Queue 中移除;如果 RabbitMQ 没有收到回执并检测到消费者的 RabbitMQ 连接断开,则 RabbitMQ 会将该消息发送给其他消费者(如果存在多个消费者)进行处理。
Message durability
如果我们希望即使在 RabbitMQ 服务重启的情况下,也不会丢失消息,我们可以将 Queue 与 Message 都设置为可持久化的(durable)
Exchange
生产者将消息发送到 Exchange(交换器,下图中的 X),由 Exchange 将消息路由到一个或多个 Queue 中(或者丢弃)
fanout
direct
topic
前面讲到 direct 类型的 Exchange 路由规则是完全匹配 binding key 与 routing key,但这种严格的匹配方式在很多情况下不能满足实际业务需求。topic 类型的 Exchange 在匹配规则上进行了扩展,它与 direct 类型的 Exchage 相似,也是将消息路由到 binding key 与 routing key 相匹配的 Queue 中
以上图中的配置为例,routingKey=”quick.orange.rabbit” 的消息会同时路由到 Q1 与 Q2,routingKey=”lazy.orange.fox” 的消息会路由到 Q1,routingKey=”lazy.brown.fox” 的消息会路由到 Q2,routingKey=”lazy.pink.rabbit” 的消息会路由到 Q2(只会投递给 Q2 一次,虽然这个 routingKey 与 Q2 的两个 bindingKey 都匹配);routingKey=”quick.brown.fox”、routingKey=”orange”、routingKey=”quick.orange.male.rabbit” 的消息将会被丢弃,因为它们没有匹配任何 bindingKey。
引用
作者:高广超
链接:https://www.jianshu.com/p/24f464f9161c
來源:简书
v1.5.2