您好,登录后才能下订单哦!
这篇文章主要讲解了“java消息队列应用场景是什么”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“java消息队列应用场景是什么”吧!
队列(Queue)是一种常见的数据结构,其最大的特点就是先进先出(First In First Out),作为最基础的数据结构,队列应用很广泛。比如火车站排队买票等等。可以用下图表示队列:
其中a1、a2、an表示队列中的数据。数据从队尾入队列,然后从队头出队列。
消息队列(Message Queue)是一种使用队列(Queue)作为底层存储数据结构,可以用于解决不同进程与应用程序之间通讯的分布式消息容器,也可以称为消息中间件。
目前比较常用的消息队列有ActiveMQ、RabbitMQ、Kafka、RocketMQ、Redis等。
消息队列和队列有什么区别呢?
唯一的区别在于入队列的时候称为生产者,出队列的时候称为消费者。
消息队列应用场景非常广泛,下面我们列举比较常见的几个场景
一般我们写的程序都是按照顺序执行的(即同步的方式)。比如电商系统中订单的例子,其执行顺序如下:
用户提交订单。订单完成以后增加积分。发生积分变动的短信通知。
可以用下面的流程图表示:
如果按照上面的顺序执行,假如每个服务都需要花费一秒,那么客户端就要花费3秒的时间。对于用户来说,3秒的时间显然是不能忍受的,那么我们该如何解决呢?我们可以使用异步的方式来解决这个问题,看下面一张流程图:
按照这种方式,积分服务和短信服务使用线程异步的方式进行操作,那么客户端只需要花费1秒的时间就可以完成了。但是,这种异步的方式会带来另外的问题:并发量降低。因为积分服务和短信服务都需要在订单服务里面开启线程,开启的线程多了,会导致客户端访问订单服务的并发量降低,可能导致客户端提交订单的实际时间会超过1秒钟。那么如何解决异步带来的问题呢?那就是使用消息队列,看下面的流程图:
在上面的流程中,我们增加了一个消息队列的角色,首先由客户端提交订单,然后把订单写入到消息队列,积分服务和短信服务同时去消费消息队列里面的消息,这种方式不需要订单服务在额外的开启异步线程,客户端可以实现真正的耗时1秒。
我们还是以电商系统为例进行讲解,先看下面的流程图:
上图的业务逻辑:客户端发起一个创建订单的请求,创建订单的时候,我们要先获取库存,然后在去扣减库存,这样订单系统和库存系统就形成了非常紧密的依赖关系。假如这时候库存系统发生了宕机,由于订单系统依赖于库存系统,这时候订单系统将不能使用。那么如何解决呢?
看下面使用消息队列的流程图:
在上面的流程中,我们加入了消息队列。首先客户端发起创建订单的请求,订单的消息写入到消息队列里面,然后库存系统去消息队列里面订阅消息,最后异步的去更新库存系统。如果库存系统发生了宕机,由于订单系统不直接依赖于库存系统,所以订单系统可以正常的响应客户端的请求。这样就实现了应用解耦。
对于高并发的系统来说,在访问高峰时,突发的流量就像洪水般涌向应用系统,尤其是一些高并发写操作,随时会导致数据库服务器瘫痪,无法继续提供服务。
而引入消息队列则可以减少突发流量对应用系统的冲击。消费队列就像“水库”一样,拦截上游的洪水,削减进入下游河道的洪峰流量,从而达到减免洪水灾害的目的。
在这方面最常见的例子就是秒杀系统,一般秒杀活动瞬间流量很高,如果流量全部涌向秒杀系统,会压垮秒杀系统,通过引入消息队列,可以有效缓冲突发流量,达到“削峰”的作用。
我们使用秒杀的场景来描述流量削峰,先看下面一张流程图:
在上面的流程中,我们把秒杀服务称为上游服务,订单服务、库存服务、余额服务统称为下游服务。客户端发起秒杀的请求,秒杀服务收到客户端发送的请求以后,创建订单,修改库存,扣减余额,这是秒杀的基本业务场景。
假如下游服务只能同时处理1000个并发请求,上游服务可以处理10000个并发请求,而客户端发起了10000个请求,超出了下游服务可以处理的并发量,所以会导致下游服务发生宕机。这时就可以加入消息队列来解决宕机的问题。看下面加入消息队列的流程图:
我们在上面的流程图中加入了消息队列,描述服务接收到客户端发送的10000个请求以后,把所有的请求都写入到消息队列中,然后下游服务去订阅消息队列里面的秒杀请求,然后在去执行自己的业务逻辑操作。
我们举个简单的例子,上游服务还是能处理10000个并发请求,下游服务还是只能处理1000个并发请求,那么这时候我们在消息队列里面会允许存1000个并发请求。上游的秒杀服务接收到10000个并发请求,而消息队列里面只能存1000个请求,多余的请求就不会存入到消息队列里面,直接返回给客户端提示“系统繁忙,请稍后!”。这就是所谓的流量削峰场景。这是由下游服务可以处理的并发量决定的。由于下游服务只能处理1000个并发请求,所以消息队列里面只能存1000个秒杀,多余的秒杀请求全部返回客户端提示。这样就保证了下游服务的正常响应,不会导致下游服务发生宕机,提高了系统的可用性。
为了程序的健壮性,我们一般会在程序中添加各种记录日志的功能,比如错误日志、操作日志等等,看下面一张流程图:
上面的流程图是同步记录日志的流程。使用同步记录日志的流程,会使得整个流程花费的时间增多,而且也会容易造成业务系统宕机(如果数据库损坏了,向数据库记录日志的操作将会产生错误)。我们可以使用消息队列的方式优化日志的传输。看下面的流程图:
加入了消息队列以后,可以缩短系统花费的时间,而且也可以达到应用系统解耦的功能。
消息队列最主要功能是收发消息,其内部有高效的通讯机制,因此非常适合用于消息通讯。
我们可以基于消息队列开发点对点的聊天系统,也可以开发广播系统,用于将消息广播给大量接收者。
感谢各位的阅读,以上就是“java消息队列应用场景是什么”的内容了,经过本文的学习后,相信大家对java消息队列应用场景是什么这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是亿速云,小编将为大家推送更多相关知识点的文章,欢迎关注!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。