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

消息队列原理与实战 | 青训营笔记

前世今生

定义：消息队列是支持高吞吐、高并发、高可用的队列容器

业内使用

消息队列kafka

如何使用

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

Topic：逻辑队列，不同业务创建不同Topic
Cluster:物理集群，每个集群可以建立多个不同Topic
Producer:生产者，负责将业务消息发送到Topic中
Consumer:消费者，负责消费Topic中消息
ConsumerGroup:消费者组，不同consumer消费进度互不干涉
Partition:分区，不同分区可并发处理
Offset:消息在partition内的相对位置，可以理解为唯一ID，在partition内严格递增
Replica：每个分区有多个副本。分为leader和follower，生产消费都与leader交互，follower与leader进行同步。具有选举机制
Broker：服务代理节点。对于 Kafka 而言，Broker 可以简单地看作一个独立的 Kafka 服务节点或 Kafka 服务实例。大多数情况下也可以将 Broker 看作一台 Kafka 服务器，前提是这台服务器上只部署了一个 Kafka 实例。一个或多个 Broker 组成了一个 Kafka 集群。一般而言，我们更习惯使用首字母小写的 broker 来表示服务代理节点。

Broker

磁盘上采用顺序写提高写入效率，写之前使用批处理和数据压缩

偏移量索引文件：二分找到小于目标offset的最大索引位置
时间戳索引文件：在offset上层加一个二级索引，二分找到小于目标时间戳最大的索引位置

零拷贝:数据读到内存空间后通过sync field发送给网卡，再发送给消费者进程，避免了传统数据拷贝的三次拷贝

Consumer

使用coordinator（由broker承担）为consumer group中的consumer动态分配partition
coordinator制定consumer group中第一机器当leader来制定分配方案
使用心跳机制确认consumer是否离线

小结：哪些帮助kafka提高吞吐或者稳定性

Producer: 批量发送、数据压缩
Broker: 顺序写、消息索引、零拷贝
Consumer： Rebalance

kafka存在的问题

数据复制问题，运维成本高
负载不均衡的场景解决方案复杂
没有自己的缓存，完全依赖Page Cache
Controller和Coordinator和Broker（意思是controller和coordinator选的同一个broker）在同一进程中，大量IO造成性能下降，一旦broker挂了，影响controller和coordinator

消息队列BMQ

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