这是我参与「第三届青训营 -后端场」笔记创作活动的第5篇笔记。

课程资料

什么是消息队列

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

topic：逻辑队列，每一个不同的业务场景就是一个不同的topic。对于每个业务来说，所有的数据都存在它对应的topic中
cluster：物理集群，每个集群中可以新建多个不同的topic
producer：消息生产端，负责将业务消息发送到topic中
consumer：消息消费端，负责消费已经发送到topic中的消息
consumergroup：消费者组，不同组consumer消费进度互不干涉
partition：分片，通常topic会有多个分片，不同分片之间消息可以并发处理，提高单个topic的吞吐
- offset：对每个partition，每一条消息都有一个唯一的offset，表示消息在partition内的相对位置，可以理解为唯一ID，并在partition内部严格递增
- replica：分片的副本，可用来容灾。每个分片有多个replica，leader replica 将会从ISR中选出
zookeeper模块：负责存储集群元信息，包括分区分配信息等，Controller计算好的方案都会放到这里

运维成本高
- 由数据复制问题导致
对于负载不均衡的场景，解决方案复杂
- 复杂的方案进行数据迁移，从而权衡IO升高的问题
没有自己的缓存，完全依赖Page Cache
Controller、Coordinator、Broker在同一进程中，Broker承载大量IO会造成Controller和Coordinator性能下降，甚至影响整个集群的可用性
字节的解决方案：BMQ

这篇笔记主要总结了“走进消息队列”一课里对消息队列的介绍，可帮助我深入了解比较流行的消息队列例如Kafka，RocketMQ和字节自研的BMQ里的基本模块、架构、与优劣势特性。