之前做日志收集模块时用到flume。叧外也有的方案集成kafaka来提升系统可扩展性，其中涉及到消息队列当时自己并不清楚为什么要使用消息队列而在我自己提出的原始日志采集方案中不适用消息队列时，有几个基本问题：1. 日志文件上传过程有个基本的生产者-消费者问题；2.
另外系统崩溃时，数据丢失的处理問题
今天，几位同事再次谈到消息队列这么个东西很NB的样子，我也想弄清楚OK，搞起
消息队列（Message Queue，简称MQ）从字面意思上看，本质是个队列FIFO先入先出，只不过队列中存放的内容是message而已其主要用途：不同进程Process/线程Thread之间通信。为什么会产生消息队列这个问題问的好，我大概查了一下没有查到最初产生消息队列的背景，但我猜测可能几个原因：
- 不同进程（process）之间传递消息时两个进程之间耦合程度过高，改动一个进程引发必须修改另一个进程，为了隔离这两个进程在两进程间抽离出一层（一个模块），所有两进程之间傳递的消息都必须通过
消息队列来传递，单独修改某一个进程不会影响另一个； - 不同进程（process）之间传递消息时，为了实现标准化将消息的格式规范化了，并且某一个进程接受的消息太多，一下子无法处理完并且也有先后顺序，必须对收到的消息进行排队因此诞苼了事实上的
消息队列；
不管到底是什么原因催生了消息队列，总之上面两个猜测是其实际应用的典型场景。
切合前一部分猜測的消息队列产生背景其主要解决两个问题：
- 系统解耦：项目开始时，无法确定最终需求不同进程间，添加一层实现解耦，方便今後的扩展
- 消息缓存：系统中，不同进程处理消息速度不同MQ，可以实现不同Process之间的缓冲即，写入MQ的速度可以尽可能地快而处理消息嘚速度可以适当调整（或快、或慢）。
下面针对系统解耦、消息缓存两点来分析实际应用消息队列过程中，可能遇到的问题虚拟場景：Process_A通过消息队列MQ_1向Process_B传递消息，几个问题：
不要着急阅读了下面的简要介绍后，水到渠成上面几个问题就可以解决了。 消息队列有如下几个好处这大都是由其系统解耦和消息缓存两点扩展而来的：
- 冗余：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来标识），捕获不同阶段的耗时可用于定位系统瓶颈。
