走进消息队列 | 青训营笔记

1 消息队列的应用场景

在学习的过程中，想要了解一个东西，最直观的方式就是在我们日常生活中，或者在计算机启动流程中，这个东西该如何去使用

场景一：对用户进行搜索的记录、点击行为的记录进行存储的时候，服务器崩溃，这时候会发生什么？

解决方式：解耦，将用户的行为记录先放入消息队列，然后再进行服务器的存储

场景二：一个热门的话题（商品），同时有大量的用户发起请求，但是服务器只能同时处理10个请求，其余请求该如何处理？

解决方式：削峰，用户和服务器中间加一个消息队列，多的请求存储在消息队列中。

场景三：用户发起一个订单，会经过库存-1，订单+1，通知商家等一系列操作，链路耗时长，如何给用户快速响应？

解决方式：异步，用户的请求放入消息队列中，即可给用户进行响应，后续的存储等行为异步执行。

2 消息队列的概念

消息队列（MQ）：指保存消息的一个容器，本质是个队列。但这个队列呢，需要支持高吞吐，高并发，并且高可用。

3 常见消息队列

• RabiitMQ：2007年发布，是一个在AMQP(高级消息队列协议)基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。

• Kafka：分布式的、分区的、多副本的日志提交服务，在高吞吐场景下发挥较为出色。

• RocketMQ：低延迟、强一致、高性能、高可靠、万亿级容量和灵活的可扩展性，在一些实用场景中运用较广。

• Pulsar：是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体、采用存算分离的架构设计。

• BMQ: 字节产品，和Pulsar架构类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群。

4 Kafka

​ Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。 这种动作是在现代网络上的许多社会功能的一个关键因素。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。

Kafka是一种高吞吐量的分布式发布订阅消息系统，有如下特性：

• 通过O(1)的磁盘数据结构提供消息的持久化，这种结构对于即使数以TB的消息存储也能够保持长时间的稳定性能。（文件追加的方式写入数据，过期的数据定期删除）
• 高吞吐量：即使是非常普通的硬件Kafka也可以支持每秒数百万的消息
• 支持通过Kafka服务器和消费机集群来分区消息
• 支持Hadoop并行数据加载

Kafka相关概念：

• Broker：Kafka集群包含一个或多个服务器，这种服务器被称为broker[5]

• Topic：每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）

• Partition：Parition是物理上的概念，每个Topic包含一个或多个Partition.

• Producer：负责发布消息到Kafka broker

• Consumer：消息消费者，向Kafka broker读取消息的客户端。

• Consumer Group：每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。

一般应用在大数据日志处理或对实时性（少量延迟），可靠性（少量丢数据）要求稍低的场景使用。

5 BMQ

​ BMQ是一个兼容Kafka协议，存算分离，云原生消息队列，他的初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群。主要就是为了分担一部分Kafka集群的功能，减轻Kafka的压力，用于离线计算

BMQ相关概念：

• Topic:逻辑队列，不同Topic可以建立不同的Topic
• Cluster:物理集群，每个集群中可以建立多个不同的Topic
• Producer:生产者，负责将业务消息发送到Topic中
• Consumer:消费者,负责消费Topic中的消息
• ConsumerGroup:消费者组，不同组Consumer消费进度互不干涉

6 RocketMQ

​ RocketMQ是阿里开源的消息中间件，纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。RocketMQ思路起源于Kafka，但并不是简单的复制，它对消息的可靠传输及事务性做了优化