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

消息队列组件在大数据技术生态系统中发挥着重要作用。归根结底，它们很重要，因为它们有需求，可以满足特定场景中的消息处理需求。在哪些特定场景中需要使用消息队列？今天的大数据开发学习，我们来谈谈消息队列应用场景。

当您需要使用消息队列时，首先需要考虑其必要性。有许多情况下可以使用消息队列。最常见的是app的松散耦合、异步处理模式、发布和订阅、最终一致性、峰值流控制和日志缓冲。

相反，如果需要强一致性，并且考虑到业务逻辑的处理结果，则RPC更合适。

1.异步处理

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

消息队列通常具有内置的高效通信机制，因此它们也可以用于简单的消息通信，例如点对点消息队列或聊天室。

应用案例：网站用户注册成功后，将发送电子邮件确认或短信。

2.系统解耦

系统耦合不强。消息接收者可以随意添加，而无需修改消息发送者的代码。

消息发送方的成功并不取决于消息接收方（例如，一些银行接口不稳定，但调用方不需要依赖这些接口）。

它并不强烈依赖于系统的核心流程。对于非核心流程，可以将其放入消息队列中，让消息使用者按需消费，而不影响核心主流程。

3.最终一致性

最终一致性不是消息队列的强制特征，但可以依靠它来实现最终一致性：

在操作前写入消息。确保在操作完成后修改消息状态。定时任务补偿机制实现了消息的可靠发送和接收以及业务操作的可靠执行。应注意消息重复和幂等性的设计。

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

对于像Kafka这样的设计，在设计级别可能会丢失消息（例如定期磁盘刷新，如果断电，则会丢失消息）。即使只有千分之一的信息丢失，企业也必须使用其他手段确保结果正确。

4.广播

生产者/消费者模型只需要关心消息是否被传递到队列。至于谁想订阅，谁需要消费，这是下游的事情，这无疑大大减少了开发和联合调试的工作量。

5.流量削峰和流量控制

当上游和下游系统的处理能力之间存在差距时，消息队列被用作流量限制控制的一般“漏斗”。当下游能够处理时，它将被分发。

例如，在支付系统成功结算后，订单系统将通过短信系统向用户推送扣费通知。

由于短板效应（每秒数百个请求），SMS系统可能会卡在网关中，这与前端的并发数量级不同。因此，支付系统和SMS系统的处理能力是不同的。

然而，当用户在晚上大约半分钟收到短信时，通常没有什么大问题。如果没有消息队列，两个系统之间的协商和滑动窗口等复杂方案并非不可能。

然而，随着系统复杂性的指数级增长，它必然会存储在上游或下游，并处理时序和拥塞等一系列问题。

每当处理能力出现缺口时，就需要单独开发一套逻辑来维持这套逻辑。

因此，使用中间系统转储两个系统的通信内容，然后在下游系统能够处理这些消息时处理这些消息是一种相对常见的方式。

应用案例：

消息队列在一定程度上被用作消息堆叠的可靠临时存储场所。

定期传递消息，例如模拟用户的秒杀访问，并对系统性能进行压力测试。

6.日志处理

消息队列用于日志处理，如Kafka的app，以解决大量日志传输和缓冲的问题。

应用案例：集中收集PV计算日志、用户行为分析