您的位置:知识库 » 编程基础

消息队列(Message Queue)基本概念

来源: ningg.top  发布时间: 2016-01-28 12:14  阅读: 42187 次  推荐: 27   原文链接   [收藏]  

  之前做日志收集模块时,用到flume。另外也有的方案,集成kafaka来提升系统可扩展性,其中涉及到消息队列当时自己并不清楚为什么要使用消息队列。而在我自己提出的原始日志采集方案中不适用消息队列时,有几个基本问题:1. 日志文件上传过程,有个基本的生产者-消费者问题;2. 另外系统崩溃时,数据丢失的处理问题。

  今天,几位同事再次谈到消息队列这么个东西,很NB的样子,我也想弄清楚,OK,搞起。

  消息队列(Message Queue,简称MQ),从字面意思上看,本质是个队列,FIFO先入先出,只不过队列中存放的内容是message而已。其主要用途:不同进程Process/线程Thread之间通信。为什么会产生消息队列?这个问题问的好,我大概查了一下,没有查到最初产生消息队列的背景,但我猜测可能几个原因:

  • 不同进程(process)之间传递消息时,两个进程之间耦合程度过高,改动一个进程,引发必须修改另一个进程,为了隔离这两个进程,在两进程间抽离出一层(一个模块),所有两进程之间传递的消息,都必须通过消息队列来传递,单独修改某一个进程,不会影响另一个;
  • 不同进程(process)之间传递消息时,为了实现标准化,将消息的格式规范化了,并且,某一个进程接受的消息太多,一下子无法处理完,并且也有先后顺序,必须对收到的消息进行排队,因此诞生了事实上的消息队列

  不管到底是什么原因催生了消息队列,总之,上面两个猜测是其实际应用的典型场景。

  切合前一部分猜测的消息队列产生背景,其主要解决两个问题:

  • 系统解耦:项目开始时,无法确定最终需求,不同进程间,添加一层,实现解耦,方便今后的扩展。
  • 消息缓存:系统中,不同进程处理消息速度不同,MQ,可以实现不同Process之间的缓冲,即,写入MQ的速度可以尽可能地快,而处理消息的速度可以适当调整(或快、或慢)。

  下面针对系统解耦消息缓存两点,来分析实际应用消息队列过程中,可能遇到的问题。虚拟场景:Process_A通过消息队列MQ_1向Process_B传递消息,几个问题:

  • 针对MQ_1中一条消息message_1,如何确保Process_B从MQ_1中只取一次message_1,不会重复多次取出message_1?
  • 如果MQ_1中message_1已经被Process_B取出,正在处理的关键时刻,Process_B崩溃了,哭啊,我的问题是,如果重启Process_B,是否会丢失message_1?

  不要着急,阅读了下面的简要介绍后,水到渠成,上面几个问题就可以解决了。 消息队列有如下几个好处,这大都是由其系统解耦消息缓存两点扩展而来的:

  • 提升系统可靠性:
    • 冗余:Process_B崩溃之后,数据并不会丢失,因为MQ多采用put-get-delete模式,即,仅当确认message被完成处理之后,才从MQ中移除message;
    • 可恢复:MQ实现解耦,部分进程崩溃,不会拖累整个系统瘫痪,例,Process_B崩溃之后,Process_A仍可向MQ中添加message,并等待Process_B恢复;
    • 可伸缩:有较强的峰值处理能力,通常应用会有突发的访问流量上升情况,使用足够的硬件资源时刻待命,空闲时刻较长,资源浪费,而消息队列却能够平滑峰值流量,缓解系统组件的峰值压力;
  • 提升系统可扩展性:
    • 调整模块:由于实现解耦,可以很容易调整,消息入队速率、消息处理速率、增加新的Process;
  • 其他:
    • 单次送达:保证MQ中一个message被处理一次,并且只被处理一次。本质:get获取一个message后,这一message即被预定,同一进程不会再次获取这一message;当且仅当进程处理完这一message后,MQ中会delete这个message。否则,过一段时间后,这一message自动解除被预订状态,进程能够重新预定这个message;
    • 排序保证:即,满足队列的FIFO,先入先出策略;
    • 异步通信:很多场景下,不会立即处理消息,这是,可以在MQ中存储message,并在某一时刻再进行处理;
    • 数据流的阶段性能定位:获取用户某一操作的各个阶段(通过message来标识),捕获不同阶段的耗时,可用于定位系统瓶颈。
27
0
标签:消息队列

编程基础热门文章

    编程基础最新文章

      最新新闻

        热门新闻