RabbitMQ6种常用业务场景分析

为什么80%的码农都做不了架构师？>>>   

RabbitMQ是一个消息代理，从“生产者”接收消息并传递消息至“消费者”，期间可根据规则路由、缓存、持久化消息。“生产者”也即message发送者以下简称P，相对应的“消费者”乃message接收者以下简称C，message通过queue由P到C，queue存在于RabbitMQ，可存储尽可能多的message，多个P可向同一queue发送message，多个C可从同一个queue接收message。

场景1：单发送单接收

使用场景：简单的发送与接收，没有特别的处理。

场景2：单发送多接收

使用场景：一个发送端，多个接收端，如分布式的任务派发。为了保证消息发送的可靠性，不丢失消息，使消息持久化了。同时为了防止接收端在处理消息时down掉，只有在消息处理完成后才发送ack消息。

场景3：Publish/Subscribe

使用场景：发布、订阅模式，发送端发送广播消息，多个接收端接收。

场景4：Routing (按路线发送接收)

使用场景：发送端按routing key发送消息，不同的接收端按不同的routing key接收消息。

场景5：Topics (按topic发送接收)

使用场景：发送端不只按固定的routing key发送消息，而是按字符串“匹配”发送，接收端同样如此。

场景6.RPC

1. 当客户端启动时，创建一个匿名的回调队列。
2. 客户端为RPC请求设置2个属性：replyTo，设置回调队列名字；correlationId，标记request。
3. 请求被发送到rpc_queue队列中。
4. RPC服务器端监听rpc_queue队列中的请求，当请求到来时，服务器端会处理并且把带有结果的消息发送给客户端。接收的队列就是replyTo设定的回调队列。
5. 客户端监听回调队列，当有消息时，检查correlationId属性，如果与request中匹配，那就是结果了。
   由于RPC模式不怎么常用，在这里附上测试用例代码
   服务端：
   
   客户端：
   

转载于:https://my.oschina.net/VILLE/blog/1057718