消息队列高手课-李玥（学习笔记）

概述

1.RabbitMQ

Erlang语言编写，支持AMQP协议，轻量级。

和其他消息队列不同的是，它在生产者（Producer）和队列（Queue）之间增加了一个 Exchange 模块，你可以理解为交换机。这个 Exchange 模块的作用和交换机也非常相似，根据配置的路由规则将生产者发出的消息分发到不同的队列中。

对消息堆积的支持并不好。性能差。Erlang学习曲线非常陡峭。

2.RocketMQ

阿里巴巴开源项目，有着不错的性能，稳定性和可靠性，非常活跃的中文社区。Java开发。对在线业务的响应时延做了很多优化，毫秒级响应。

作为国产的消息队列，相比国外的比较流行的同类产品，在国际上还没有那么流行，与周边生态系统的集成和兼容程度要略逊一筹。

3.kafka

Kafka 使用 Scala 和 Java 语言开发，设计上大量使用了批量和异步的思想，这种设计使得 Kafka 能做到超高的性能。

可靠性、稳定性和功能特性等方面都可以满足绝大多数场景的需求。Kafka 与周边生态系统的兼容性是最好的没有之一，尤其在大数据和流计算领域，几乎所有的相关开源软件系统都会优先支持 Kafka。

同步收发消息的响应时延比较高，因为当客户端发送一条消息的时候，Kafka 并不会立即发送出去，而是要等一会儿攒一批再发送，当你的业务场景中，每秒钟消息数量没有那么多的时候，Kafka 的时延反而会比较高。所以，Kafka 不太适合在线业务场景。

总结：

如果说，消息队列并不是你将要构建系统的主角之一，你对消息队列功能和性能都没有很高的要求，只需要一个开箱即用易于维护的产品，我建议你使用 RabbitMQ。

如果你的系统使用消息队列主要场景是处理在线业务，比如在交易系统中用消息队列传递订单，那 RocketMQ 的低延迟和金融级的稳定性是你需要的。

如果你需要处理海量的消息，像收集日志、监控信息或是前端的埋点这类数据，或是你的应用场景大量使用了大数据、流计算相关的开源产品，那 Kafka 是最适合你的消息队列。

概念

1.队列模型

多个消费者接收同一个队列的消息，这些消费者之间实际上是竞争的关系，每个消费者只能收到队列中的一部分消息，也就是说任何一条消息只能被其中的一个消费者收到。

2.发布 - 订阅模型

消息的发送方称为发布者（Publisher），消息的接收方称为订阅者（Subscriber），服务端存放消息的容器称为主题（Topic）。每份订阅中，订阅者都可以接收到主题的所有消息。

仔细对比一下这两种模型，生产者就是发布者，消费者就是订阅者，队列就是主题，并没有本质的区别。它们最大的区别其实就是，一份消息数据能不能被消费多次的问题。

3.RabbitMQ 的消息模型

Exchange 位于生产者和队列之间，生产者并不关心将消息发送给哪个队列，而是将消息发送给 Exchange，由 Exchange 上配置的策略来决定将消息投递到哪些队列中。

4.RocketMQ 的消息模型

RocketMQ 只在队列上保证消息的有序性，主题层面是无法保证消息的严格顺序的。

丢消息的原因大多是由于消费位置处理不当导致的

5.Kafka 的消息模型

和 RocketMQ 是完全一样。唯一的区别是，在 Kafka 中，队列这个概念的名称不一样，Kafka 中对应的名称是“分区（Partition）”，含义和功能是没有任何区别的。

消息积压

直接原因，一定是系统中的某个部分出现了性能问题，来不及处理上游发送的消息，才会导致消息积压。

不需要太关注消息队列本身的性能。因为对于绝大多数使用消息队列的业务来说，消息队列本身的处理能力（单个节点每秒钟处理几万至几十万条消息的水平）要远大于业务系统的处理能力（单个节点每秒钟可以处理几百到几千次请求，已经可以算是性能非常好）。

在设计系统的时候，一定要保证消费端的消费性能要高于生产端的发送性能，这样的系统才能健康的持续运行。