大数据开发：消息队列应用场景

消息队列的组件，在大数据技术生态当中占据重要的地位，而归根结底，之所以重要，那是因为有需求，能够满足具体场景下的消息处理需求。那么具体哪些场景下，需要用到消息队列呢？今天的大数据开发学习，我们来讲讲消息队列应用场景。

当你需要使用消息队列时，首先需要考虑它的必要性。可以使用消息队列的场景有很多，最常用的几种，是做应用程序松耦合、异步处理模式、发布与订阅、最终一致性、错峰流控和日志缓冲等。

反之，如果需要强一致性，关注业务逻辑的处理结果，则使用RPC显得更为合适。

1、异步处理

非核心流程异步化，减少系统响应时间，提高吞吐量。例如：短信通知、终端状态推送、App推送、用户注册等。

消息队列一般都内置了高效的通信机制，因此也可以用于单纯的消息通讯，比如实现点对点消息队列或者聊天室等。

应用案例：网站用户注册，注册成功后会过一会发送邮件确认或者短信。

2、系统解耦

系统之间不是强耦合的，消息接受者可以随意增加，而不需要修改消息发送者的代码。

消息发送者的成功不依赖消息接受者（比如：有些银行接口不稳定，但调用方并不需要依赖这些接口）。

不强依赖于非本系统的核心流程，对于非核心流程，可以放到消息队列中让消息消费者去按需消费，而不影响核心主流程。

3、最终一致性

最终一致性不是消息队列的必备特性，但确实可以依靠消息队列来做最终一致性的事情：

先写消息再操作，确保操作完成后再修改消息状态。定时任务补偿机制实现消息可靠发送接收、业务操作的可靠执行，要注意消息重复与幂等设计。

所有不保证100%不丢消息的消息队列，理论上无法实现最终一致性。

像Kafka一类的设计，在设计层面上就有丢消息的可能（比如定时刷盘，如果掉电就会丢消息）。哪怕只丢千分之一的消息，业务也必须用其他的手段来保证结果正确。

4、广播

生产者/消费者模式，只需要关心消息是否送达队列，至于谁希望订阅和需要消费，是下游的事情，无疑极大地减少了开发和联调的工作量。

5、流量削峰和流控

当上下游系统处理能力存在差距的时候，利用消息队列做一个通用的“漏斗”，进行限流控制。在下游有能力处理的时候，再进行分发。

举个例子：用户在支付系统成功结账后，订单系统会通过短信系统向用户推送扣费通知。

短信系统可能由于短板效应，速度卡在网关上（每秒几百次请求），跟前端的并发量不是一个数量级。于是，就造成支付系统和短信系统的处理能力出现差异化。

然而用户晚上个半分钟左右收到短信，一般是不会有太大问题的。如果没有消息队列，两个系统之间通过协商、滑动窗口等复杂的方案也不是说不能实现。

但系统复杂性指数级增长，势必在上游或者下游做存储，并且要处理定时、拥塞等一系列问题。

而且每当有处理能力有差距的时候，都需要单独开发一套逻辑来维护这套逻辑。

所以，利用中间系统转储两个系统的通信内容，并在下游系统有能力处理这些消息的时候，再处理这些消息，是一套相对较通用的方式。

应用案例：

把消息队列当成可靠的消息暂存地，进行一定程度的消息堆积。

定时进行消息投递，比如模拟用户秒杀访问，进行系统性能压测。

6、日志处理

将消息队列用在日志处理中，比如Kafka的应用，解决海量日志传输和缓冲的问题。

应用案例：把日志进行集中收集，用于计算PV、用户行为分析等等。

7、消息通讯

消息队列一般都内置了高效的通信机制，因此也可以用于单纯的消息通讯，比如实现点对点消息队列或者聊天室等。

关于大数据开发，消息队列应用场景，以上就为大家做了基本的讲解了。消息队列在实际应用当中，大多是需要结合到具体场景去进行选型的，代表性的开源产品，我们接下来会继续讲解。