消息队列学习

消息队列介绍

消息总线（Message Queue） ，是一种跨进程的通信机制，就是用于在应用程序之间传递消息的中间件。它把消息存储在一个队列中，发送方将消息添加到队列中，而接收方从队列中获取消息。

在互联网架构中，消息队列是一种常见的上下游”逻辑结构+物理解藕“的消息通信服务。

[消息发送上游]-->[消息队列]-->[消息接收下游]

优点：

1、解藕：降低系统各部分之间的依赖，使得系统更易于扩展和维护。
2、异步处理：提高系统性能，减少相应时间。
3、削峰：在高并发情况下，消息队列可以暂存大量的请求。

缺点：

1、系统复杂性提高：需要考虑消息的重复消费、消息丢失、消息传递的顺序性等等问题。
2、系统可用性降低：需要额外去保证消息队列的高可用。
3、一致性问题：如果消息的真正消费者并没有正确消费消息，可能导致数据不一致的情况。

消息队列场景

【场景一：数据驱动的任务依赖】

比如，互联网公司需要进行一些数据统计任务，这些任务有一些依赖关系：

（1）task3 需要使用 task2 的输出作为输入。

（2）task2 需要使用 task1 的输出作为输入。

传统方法：根据经验给每个任务预留执行时间，依次执行。但是这样做的话，如果有个任务超过了预留的时间就会很麻烦。
消息队列方法：在任务一执行完后发送消息，让任务二订阅这个消息，当收到任务一执行完的消息后执行任务二，以此类推。

【场景二：上游不关心执行结果】

比如，58同城的很多下游需要关注“用户发布帖子”这个事件，比如招聘用户发布帖子后，招聘业务要奖励58豆，房产用户发布帖子后，房产业务要送2个置顶，二手用户发布帖子后，二手业务要修改用户统计数据。

传统方法：帖子发布服务执行完成之后，调用下游招聘业务、房产业务、二手业务，来完成消息的通知，但事实上，这个通知是否正常正确的执行，帖子发布服务根本不关注。这样不仅帖子发布流程的执行时间增加了，并且上下游依赖严重。
消息队列方法：帖子发布成功后，给消息队列发送一个消息，然后下游关注”帖子发送成功“的消息，主动去消息队列订阅。

【场景三：上游关注执行结果，但执行时间很长】

比如：微信支付，跨公网调用微信的接口，执行时间会比较长，但调用方又非常关注执行结果。

传统方法：上游调用微信接口就进入阻塞，等待响应结果的返回。
消息队列方法：上游发送请求给微信接口，当请求收到后立马返回调用成功信息。在请求中写入回调网关，让微信接口将结果返回给网关，然后将消息给到消息队列，然后上游再去订阅。

常用消息队列

RabbitMQ、ActiveMQ、RocketMQ 和 Kafka 的主要特性、优点和缺点的总结：

RabbitMQ：
- 主要特性：异步通信，解耦，削峰，支持多种消息广播类型。
- 优点：性能较好，高并发；吞吐量到万级，MQ 功能比较完备；健壮、稳定、易用、跨平台、支持多种语言、文档齐全；开源提供的管理界面非常棒，用起来很好用；社区活跃度高。
- 缺点：erlang 开发，很难去看懂源码，基本职能依赖于开源社区的快速维护和修复 bug，不利于做二次开发和维护；吞吐量会低一些，这是因为他做的实现机制比较重；需要学习比较复杂的接口和协议，学习和维护成本较高。
ActiveMQ：
- 主要特性：支持任何消息传递用例的能力和灵活性。
- 优点：单机吞吐量万级，时效性 ms 级，可用性高，基于主从架构实现高可用性，消息可靠性有较低的概率丢失数据。
- 缺点：官方社区现在对ActiveMQ 5.x维护越来越少，高吞吐量场景较少使用。
RocketMQ：
- 主要特性：高吞吐量、低延迟，适用于大规模分布式系统的消息通信。
- 优点：性能好，高吞吐量，稳定可靠，有活跃的中文社区。
- 缺点：兼容性上不是太好，社区相对较小，MQ功能简单，消息可能会重复消费影响数据精确度。
Kafka：
- 主要特性：高吞吐量、低延迟，适用于大规模分布式系统的消息通信。
- 优点：高吞吐量和低延迟，适用于对性能要求较高的场景；支持分布式部署和扩展，具备较好的可扩展性；提供了丰富的消息模式和功能，如事务消息、顺序消息等。
- 缺点：复杂性高，需要配置和管理多个节点；由于 Kafka 持久化消息到磁盘，因此它需要占用较多的存储空间，可能导致存储成本的增加；为了确保 Kafka 集群的正常运行，需要进行适当的配置和监控。