我们在上文中给大家简单分析了消息队列机制的实现方法等内容,而今天我们就再来说说,消息队列机制在服务端与客户端的具体应用方法。
服务端
服务端的实现比较简单,和一般的Consumer的区别只在于需要将请求回复到replyTo指定的queue中并带上消息标识correlation_id即可
服务端的一点小优化:
超时的处理是由客户端来实现的,那服务端有没有可以优化的地方呢?
答案是有的:如果我们的服务端处理比较耗时,如何判断客户端是否还在等待响应呢?
我们可以使用passive参数去检查replyTo的queue是否存在,因为客户端声明的是内部队列,客户端如果断掉链接了这个queue就不存在了,这时服务端就无需处理这个消息了。
客户端
客户端承担了更多的工作量,包括:
声明replyTo队列(使用amq.rabbitmq.reply-to会简单很多)
维护请求和响应消息(使用的correlation_id来关联)
消费服务端的返回
处理超时等异常情况(使用BlockingQueue来阻塞获取)
好在spring已经实现了一套完备可靠的代码,我们在清楚了流程和关键点之后,可以直接使用spring提供的RabbitTemplate,无需自己实现。
使用MQ实现RPC的意义
通过MQ实现RPC看起来比客户端和服务器直接通讯要复杂一些,那我们为什么要这样做呢?或者说这样做有什么好处:
将客户端和服务器解耦:客户端只是发布一个请求到MQ并消费这个请求的响应。并不关心具体由谁来处理这个请求,MQ另一端的请求的消费者可以随意替换成任何可以处理请求的服务器,并不影响到客户端。
减轻服务器的压力:传统的RPC模式中如果客户端和请求过多,服务器的压力会过大。由MQ作为中间件的话,过多的请求而是被MQ消化掉,服务器可以控制消费请求的频次,并不会影响到服务器。
服务器的横向扩展更加容易:如果服务器的处理能力不能满足请求的频次,只需要增加服务器来消费MQ的消息即可,MQ会帮我们实现消息消费的负载均衡。
可以看出RabbitMQ对于RPC模式的支持也是比较友好地,
amq.rabbitmq.reply-to,reply_to,correlation_id这些特性都说明了这一点,再加上spring-rabbit的实现,可以让我们很简单的使用消息队列模式的RPC调用。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!