MQ & RPC 消息队列与RPC的区别与使用场景

MQ：

区别：面向数据、生产者与消费者、有缓冲节点、异步、系统级/模块级通信

选型：RabbitMQ、ActiveMQ/Apollo、ZeroMQ、memcacheQ、Redis、MSMQ、kafka/jafka

场景：

• 消息的发送者和消费者需要解耦的情况
• 发送者并不明确谁是消费者
• 发送者并不关心谁来消费消息
• 各个消费者可以从不同的角度入手处理消息
• 消费者的处理结果也不返回给发送者
• 消息的发送和处理是异步的
• 消息的关注者不止一个

举例：

在一个由多个微服务构成的大系统中，会有一些非关键服务，用来执行一些不需要立刻得到结果的计算。而且它们的计算结果并不会返回给消息的发送者。

这个时候就应该使用MQ。

比如在一个ERP系统中有一些日志服务、业务监控服务等。这些服务会发布一些系统事件，针对这些事件可能有多个应用关注。

对于日志服务，当系统出现某些异常情况时需要浏览日志，查找问题的根源；也可以在分析系统运行的瓶颈时提供关键数据。

对于业务监控系统，例如货物入仓出仓的消息，可以被报表系统关注，生成报表；也可以被配货系统关注，及时补足所需库存。

RPC：

区别：面试动作、请求响应模式、同步、对象级/函数级通信

场景：

1. 客户端调用哪个服务器比较明确
2. 调用需要立即得到返回结果
3. 架构简单

举例：在一个由多个微服务构成的大系统中，某些关键服务间的调用应当在较短的时间内返回，而且各个微服务的专业化程度较高，同一个请求的关注者只有个。

这个时候就应该用RPC。

比如在一个ERP系统中，有一个管理仓储的微服务，以及一个负责订单的微服务。新建订单时需要查知当前的存货是否充足，如果不充足就通知用户；

提交订单时预订指定数量的货物，如果此时货物不错，也要终止订单的提交，并通知用户。显然在这种场景下是不允许较大的延迟，否则会影响用户体验。

所以应该使用RPC，及时返回仓储情况。

MQ&RPC共同点：

选型：ZBus（MQ+RPC）