应用服务器性能优化 之 消息队列(MQ:Message Queue)

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/reggergdsg/article/details/51711804


一,消息队列基本概念

借用百科的一句话:消息队列就是在消息的传输过程中,保存消息的容器。



从图-1和图-2对比,可以很清晰的明白,消息队列服务器,是位于应用服务器和数据库服务器之间的一个服务器。消息队列服务器作为一个缓冲,接收应用服务器发送过来的数据库操作命令,然后按照自己的配置,依次发送给数据库服务器来执行。这种数据库执行的方式,我们称之为异步写入数据库。增加消息队列服务器有以下几点好处:

1,由于消息队列服务器的速度远远高于数据库服务器,所以能够快递处理并返回数据;

2,消息队列服务器具有更好的扩展性;

3,在高并发的情况下,延迟写入数据库,可以有效降低数据库的压力;


凡事都会有利有弊,消息队列也不例外。正所谓知己知彼,百战不怠,我们要想把消息队列用的炉火纯青,消息队列的“弊端”也要铭记于心:

1,由于消息队列是在写入消息队列服务器之后,马上返回给用户,此时数据并没有真正的写入到数据库,后续的数据库操作可能会执行失败,这显然是有问题的。我们一般的做法,是通过业务的手段来解决异步带来的不一致问题。比如我们可以稍微修改一下业务流程,在订单写入消息队列后,不立即返回订单生成成功,而是等待消息队列里的进程真正的执行完以后,再通知用户订单生成成功。


消息队列有特殊的应用场景,而作为我们程序猿或者架构师,就是要从中进行取舍,拿出一套权衡利弊之后的解决方案,解决项目中遇到的问题。


典型应用:活动期间,短时间内生成大批量的订单。如图-3


消息队列的应用场景:邮件服务、短信服务、好友动态推送服务等。我们必须要明白一点:任何需要持久化的产品,磁盘IO都是一个逃不掉的限制。消息队列只是在时间上延长了持久化的时间。

消息队列的常见应用场景:

1,流量控制和业务剥离;
由于磁盘IO的速度与内存的速度差距太大,数据库通常都会成为系统的瓶颈。并且升级硬件成本较高,所以公司通常都会采取软件的方法
来解决这类问题。还是那句话,技术是为业务服务的,没有业务,就没有技术。抢购活动、秒杀活动这一类短时间内生成大批量订单的问
题,我们通常就采用消息队列的方式来处理。
另外,从业务方面来考虑,有些用户不是很关心的业务,可以从主流程中剥离出来。比如订单系统,订单支付成功,我们一般都会发送短
信通知用户支付成功,或者返积分什么的。这个我们在平时的使用中应该也能体会到,发送短信的服务一般都是延迟发送的,少则几十
秒,多者几分钟,甚至几十分钟等等。一方面是用户不是特别关心这些问题,另一方面,短信平台的速度也是很慢的,和磁盘IO一样,都
是系统的主要瓶颈之一。并且短信的发送,受网络影响也较大,经常发生发送失败的情况。使用消息队列,一方面可以把发送短信流程从
主流程中剥离出来,降低系统的复杂性;另一方面,通过轮训消息队列的方式,可以补偿性的多发几次,直到成功为止(也就是我们经常
用到的跑批)。

2,广播(发布/订阅);
随着系统的扩大,系统的复杂性会越来越大,我们都知道,越是复杂的系统,越难维护。君不见,现在有很多老系统,维护的时间居然超
过了开发的时间。本人之前工作的老项目,是运行了五六年的老项目,大部分都是在维护,一个小功能的上线,就有可能让系统出现各种
意想不到的问题,经常通宵上线,苦不堪言。
消息队列对解决这种应用场景,也是一个不错的选择。目前国内的大公司,不管是银行、电信、还是互联网,企业内部的系统都是成百上
千,各个系统之间,通过企业总线关联成一个庞大的系统。各个系统都要调用核心接口,请求核心接口的数据,这种系统,正是通过消息
队列来实现的。企业总线不关心某个系统能否马上执行完成,而是把消息通知发送给某个系统。
消息队列的使用,还可以减少联调和开发的工作量。大公司,上线很频繁,如果每次增加新功能或者修改已有功能,都要进行接口联调的
话,那代价是很大的。


二,消息队列的具体实现(消息队列在项目中的应用)

消息队列的实现方式有很多种,消息队列服务器broker是一个应用比较广泛的系统模型。广播关系的维护,是消息队列服务中的一个重点,一般由于消息队列本身都是集群,所以都维护在公共存储上,比如Zookeeper;

1,借助nosql数据库或者Memcached实现消息队列;

2,HornetQ、Apache 的 ActiveMQ、Beansalkd、RabitMQ、IronMQ、Tibco EMS、IBM的MQSeries等等;

3,另外,还有比较熟悉的Akka、ZeroMQ等;


首先我们来看看:Apache ActiveMQ

Apache ActiveMQ是Apache软件基金会所研发的开放源码消息中间件;由于ActiveMQ是一个纯java的,所以只要操作系统支援Java虚拟机(JVM),ActiveMQ便可运行。

说到这里,我们需要了解一下JMS与ActiveMQ的关系:

1,JMS,即Java Message Service ,也就是大名鼎鼎的java消息服务API,是一个规范;

2,ActiveMQ,是JMS规范的一种实现;


如果需要自己设计消息队列服务器,我们必须要了解RPC协议,下面是百度百科的说明:

远程过程调用协议
        RPC(Remote Procedure Call Protocol)——远程过程调用协议,它是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在,如TCP或UDP,为通信程序之间携带信息数据。在OSI网络通信模型中,RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。
        RPC采用客户机/服务器模式。请求程序就是一个客户机,而服务提供程序就是一个服务器。首先,客户机调用进程发送一个有进程参数的调用信息到服务进程,然后等待应答信息。在服务器端,进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达,服务器获得进程参数,计算结果,发送答复信息,然后等待下一个调用信息,最后,客户端调用进程接收答复信息,获得进程结果,然后调用执行继续进行。

         有多种 RPC模式和执行。最初由 Sun 公司提出。IETF ONC 宪章重新修订了 Sun 版本,使得 ONC RPC 协议成为 IETF 标准协议。现在使用最普遍的模式和执行是开放式软件基础的分布式计算环境(DCE)。


展开阅读全文

没有更多推荐了,返回首页