这是我参与「第五届青训营 」笔记创作活动的第5天

消息队列

简介

消息队列是一个高性能、高并发、高可用的队列

常见如下：

• Kafka：分布式的、分区的、多副本的日志提交服务，在高吞吐场景下发挥较为出色。
• Pulsar：下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体、采用存算分离的架构设计。
• BMQ：和Pulsar架构类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群。
• RocketMQ：低延迟、强一致、高性能、高可靠。万亿级容量和灵活的可拓展性，在一些实时场景中运用较广。

Kafuka

创建集群 >>新增Topic >>编写生产者逻辑 >>编写消费者逻辑

基本概念

• Topic：逻辑队列，不同Topic可以建立不同的Topic
• Cluster:物理集群，每个集群中可以建立多个Topic
• Producer：生产者，负责将业务消息发送到Topic中
• Consumer：消费者，负责消费Topic中的消息
• ConsumerGroup：消费者组，不同组Consumer消费进度互不干涉
• Partition：Topic的分区，多个分区可以并发处理，提高吞吐率

每一个partition相当于一个独立的队列，offset表示消息在partition内的相应位置信息（偏移量），可以理解为唯一ID，在partition内部严格递增。

数据复制

每个partition还有多个Replica（副本），存储在不同的机器上用于容灾。leader Replica（每次宕机后重启）将会从ISR（In-Sync Replicas）中选出，用于对外输入和读取。follower不断从leader拉去数据，保持数据一致。如果Follwer与leader的差距过大，将被踢出ISR。

ZooKeeper

Zookeeper组件位于集群上层，存储集群元数据信息、分区分配信息、消费到的位点信息等。

Kafka为什么有高吞吐

• 多个消息形成batch，批量发送减少IO次数从而加强发送能力。
• 对batch进行压缩，减少带宽需求。

Broker读写磁盘

所有副本都会被记录成日志，borker将日志写入磁盘。

移动磁头找到对应磁道，磁盘转动找到对应扇区，最后读写。寻道成本比较高，因此顺序写可以减少寻道所带来的时间成本。

读取时需要找到offset==k的文件。使用二分查找，找到小于k的最大文件（例如找到k-a）。通过这个索引可以找到从k-a开始的全部文件。此时顺序寻找到k，然后开始读取。

如果通过时间戳寻找文件，则会先使用时间戳找到offset再进行后续操作。

Broker数据拷贝时直接再内核空间中从read buffer拷贝到网卡内存，而不是从用户态读取read buffer，然后将数据传到socket，再从socket传入网卡。

Consumer

1. 通过手动进行分配，开启前确定消费者组中每一个消费者要从哪些partition中读取数据。如果某一消费者挂掉，其对应的数据将无法读取。每次增加消费者都需要重新配置partition，可能存在消费者的停止与重启。
2. 自动分配:

首先消费者组向broker集群发送读取请求。根据负载，broker会返回集群中的一台机器作为协调者。协调者之后会帮消费者分配partition。

消费者向协调者发起第二轮请求，协调者收到请求后确定一个消费者作为leader。将leader信息告诉消费者组。

消费者组知道leader后会再次向协调者发出信息，确认自己已经知道leader。

消费者不断发出心跳包，如果有消费者挂掉，协调者就能知道并重新分配消费者。

kafka的问题

1. 复制内容时间成本高：kafka通过副本进行容灾，达到高可用。而重启必须顺序重启。需要使用大量时间。
2. 负载均衡难以设计。如果IO过高希望减少IO，可以将部分partition迁出broker，而迁出broker也需要IO读写。

BMQ

兼容Kafka协议，存算分离，云原生消息队列。

生产者、消费者与Kafka等同。而与Broker之间加入了Proxy。底层新增分布式文件存储系统。生产者生产消息后，proxy转交给broker写入；消费者读取消息时，proxy转发给分布式存储系统读取。

对于重启、替换、扩容、缩容，Kafka至少需要分钟级别，BMQ实现秒级。

RocketMQ

高级特性

• 事务场景
• 事务消息
• 延迟发送
• 延迟消息
• 处理失败
• 消费重试
• 死信队列

引用

青训营学习资料

消息队列|青训营笔记