Fork me on GitHub

RPC(分布式远程过程调用) 和 MQ(消息队列) 的对比

发表于   |   分类于   |     |   阅读量 次

本篇介绍 RPC(分布式远程过程调用) 和 MQ(消息队列) 的对比.

RPC(分布式远程过程调用) 和 MQ(消息队列) 的 应用场景 和区别

系统结构:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
RPC系统结构：
+----------+     +----------+
| Consumer | <=> | Provider |
+----------+     +----------+
Consumer调用的Provider提供的服务。
Message Queue系统结构：
+--------+     +-------+     +----------+
| Sender | <=> | Queue | <=> | Receiver |
+--------+     +-------+     +----------+
Sender发送消息给Queue；Receiver从Queue拿到消息来处理。
  • 在架构上，RPC和Message的差异点是:
    • Message有一个中间结点Message Queue，可以把消息存储。

消息队列 的使用场景:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
（一）短信发送
短信通常都是由第三方服务商提供的服务，对于其稳定性与可靠度来说，通常也就是打90分吧。对于那些需要发送短信的应用程序来说，通常将其放入队列中去处理，而不是傻傻的等待。
（二）日志记录
不是所有的日志记录都需要使用消息队列来处理。通常只有那些同时操作一个日志文件的情况下才会使用消息队列。另外的一种情况是，需要对日志进行同步处理后分析的场景。
（三）邮件服务
邮件服务于短信发送类似，对于那些不需要即时回复和响应速度并不特别特别快的第三方应用，使用队列来处理是最大的好处。既能节省资源，又能提高用户体验，还能防止系统崩溃。
（四）通知服务
对于给用户发消息这样的业务来说，使用消息队列也是极好的，尽管几十万内的插入语句使用SQL就可以完全搞定。使用通知服务对于那些SQL不是很好的人来说，也是很好的福利。
另外，对于多应用使用缓存提高查询效率的情景，使用消息队列也是极好的。试想一下，当你更新一个用户后，使用发布/订阅者模式处理缓存，是不是比其它任何模式都要高效呢。
（五）高并发请求
是不是又想起了淘宝双11网站瘫痪，12306一票难求，京东图书大促网页打不开，消息队列尤其适用于这种超负载的场景。通过过消息队列，将短时间高并发产生的事务消息存储在消息队列中，从而削平高峰期的并发事务，改善网站系统的性能，这样可以有效地抵御促销活动刚开始就开始大量涌入的订单对系统造成的冲击 。

区别:

  • 消息机制: 用于端到端的延迟通信;

    在RPC机制下，
    用于接收数据的进程必须在数据发送时处于执行状态。
    如果在消息发送过程中，接收进程死掉了，则数据将不能再传输。

  • RPC: 用于端到端的同步通信。

相反，在消息传递机制下，
则可以在服务进程死掉后，仍然可以发送消息，而不必因为此时服务进程没有接收消息而阻塞或重发消息。
因为，基于消息机制时，消息被放置在一个消息队列中，而且服务进程可以在任何时候取得所属自己的消息。
因此，在发送消息时，服务进程是否在执行不再重要。

消息机制 和 RPC 各自特点:

  • RPC机制的特点:

提供一个较高层次上的通信抽象，更完全地隐藏应用分布的实质。
尽可能地优化客户和服务器之间的交互，因为这种机制直接的请求/应答协议支持。
客户在等待一个服务应答时，只是简单地等待。

  • 消息机制的特点:

客户在等待对方进程的应答时，可以自由的执行其他的操作。
允许对一个请求发多个应答或多个请求发一个应答。
适合具有较长交易周期的应用。
可通过以任何顺序从消息队列中取走消息、的形式，来支持优先级和负载均衡。
可支持容错。
主要用于支持大型系统和分布范围很广的分布式系统。

坚持原创技术分享，您的支持将鼓励我继续创作！