这是我参与「第四届青训营 」笔记创作活动的第10天。
消息队列概述
- 为了异步处理：异步、解耦、削峰。
- 消息队列的两种模式：点对点模式、发布/订阅模式
应用场景
MQ消息通道
- 利用异步消息传递机制集成分布式系统，通过提供消息传递和消息排队模型在分布式进程间通信，用于数据的发送和接收的通道。
EventBridge 事件总线
- 事件源：将云服务、自定义应用、SaaS应用等应用程序产生的事件消息发布到事件集。
- 事件集：存储接收到的事件消息，并根据事件规则将事件消息路由到事件目标。
- 事件目标：消费事件消息。
Data Platform流数据平台
- 提供批/流数据处理能力
- 各类组件提供各类Connect
- 提供 Streaming/Function能力
- 根据数据schema灵活的进行数据预处理
主流的消息队列
- RabbitMQ（2007）：Erlang、主从、单机吞吐量一般
- RocketMQ（2012）：Java、主从
- Kafka（2010）：Java、分布式、延迟一般
- Pulsar（2016）：Java、分布式、扩展性最高
Kafka架构
- Kafka 是一个分布式的基于发布/订阅模式的消息队列（Message Queue），主要应用于大数据实时处理领域。
基础架构
- Producer ：消息生产者，向kafka broker 发消息的客户端；
- Consumer ：消息消费者，消费kafka broker 中消息的客户端；
- Consumer Group （CG）：由多个consumer 组成的消费者组。组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。
- Broker ：一台kafka 服务器就是一个broker。一个集群由多个broker 组成。一个broker可以容纳多个topic。
- Topic ：可以理解为一个队列，生产者和消费者面向的都是一个topic。
- Partition（分区）：为了实现扩展性，一个非常大的topic 可以分布到多个broker（即服务器）上，一个topic 可以分为多个partition，每个partition 是一个有序的队列；（有利于不同的消费者并发消费）
- Replica：副本，为保证集群中的某个节点发生故障时，该节点上的partition 数据不丢失，且kafka仍然能够继续工作 kafka提供了副本机制，一个 topic的每个分区都有若干个副本，一个 leader和若干个 follower。
- leader 每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是 leader。
- follower 每个分区多个副本中的“从”，实时从 leader中同步数据，保持和 leader数据的同步。 leader发生故障时，某个 follower会成为新的 follower。
- offset是consumer position，Topic的每个Partition都有各自的offset。kafka消费者在会保存其消费的进度，也就是offset，存储的位置根据选用的kafka api不同而不同。
- 0.9版本之前offset存储在ZK：消费者需要自己保留一个offset，从kafka 获取消息时，只拉去当前offset 以后的消息。Kafka 的scala/java 版的client 已经实现了这部分的逻辑，将offset 保存到zookeeper上
- 0.9版本及之后offset存储本地：避免对zookeeper的高并发请求
工作流程
- Kafka 中消息是以 topic进行分类的，生产者生产消息，消费者消费消息，都是面向 topic的。
- topic 是逻辑上的概念，partition 是物理上的概念。每个 partition 对应于一个 log 文件，该 log 文件中存储的就是 producer 生产的数据。Producer 生产的数据会被不断追加到该log 文件末端，且每条数据都有自己的offset。消费者组中的每个消费者，都会实时记录自己消费到了哪个offset，以便出错恢复时，从上次的位置继续消费。
- 由于生产者生产的消息会不断追加到log 文件末尾，为防止log 文件过大导致数据定位效率低下，Kafka 采取了分片和索引机制，将每个partition 分为多个segment。
- 每个segment对应两个文件“.index”文件和“.log”文件。这些文件位于一个文件夹下，该文件夹的命名规则为：topic 名称+分区序号。
- 例如，first 这个topic 有三个分区，则其对应的文件夹为first-0,first-1,first-2。
- index 和log 文件以当前segment 的第一条消息的offset 命名。
- “.index”文件存储大量的 索引信息 ，“.log”文件存储大量的 数据 ，索引文件中的元数据指向对应数据文件中 message的物理偏移地址。
Pulsar基础架构
- Producer ：消息生产者客户端
- Consumer ：消息消费者客户端
- Broker：负责处理和负载均衡Producer发出的消息，并将这些消息分派给Consumer。与 Pulsar 配置存储交互来处理相应的任务，并将消息存储在BookKeeper实例中（又称 bookies）。
- BookKeeper 集群：包含一个或多个BookKeeper实例，负责消息的持久化存储。
- ZooKeeper 集群：用来处理 Pulsar 集群之间的协调任务。
Pulsar对于kafka的优势（StreamNative基准测试）
- 吞吐量：在与Kafka相同的耐久性保证下，Pulsar实现了605MB/s的发布和端到端吞吐量（与Kafka相同），以及3.5GB/s的追读吞吐量（比Kafka高3.5倍）。增加分区的数量和改变耐久性水平对Pulsar的吞吐量没有影响。然而，在改变分区数量或改变耐久性水平时，Kafka的吞吐量受到了严重影响。
- 延迟：Pul：sar提供的延迟明显优于Kafka（包括不同的订阅数量、不同的主题数量和不同的耐久性保证）。
- I/O隔离度：Pulsar提供的I/O隔离度明显优于Kafka。当有消费者追读历史数据时，Pulsar的第99百分位发布延迟保持在5毫秒左右。相比之下，Kafka的延迟受到了追读的严重影响。Kafka的第99百分位数发布延迟可以从几毫秒增加到几秒钟。
