这是我参与「第五届青训营」伴学笔记创作活动的第 13 天
一、本堂课重点内容
本节课程主要分为五个方面：
- 消息队列的前世今生
- 消息队列-Kafka
- 消息队列-BMQ
- 消息队列-RocketMQ
- 最佳实践
二、详细知识点介绍
1 消息队列概述
-
解决的问题：解耦、削峰、异步、日志处理。
-
概念：消息队列指保存消息的一个容器，本质是队列，需要支持高吞吐、高并发、高可用。
-
业内消息队列对比
2 消息队列-Kafka
-
使用Kafka
- 创建集群
- 新增Topic，并设置好分片数量
- 编写生产者逻辑：引入对应语言的SDK，配置好参数，初始化生产者。
- 编写消费者逻辑：同上。
-
整体架构及概念
- Broker：Kafka 集群中的一台或多台服务器统称为 Broker。
- Topic：每条发布到 Kafka 的消息都有一个类别，这个类别被称为 Topic 。
- Partition：Topic 物理上的分组，一个 Topic 可以分为多个 Partition ，每个 Partition 是一个有序的队列。Partition 中的每条消息都会被分配一个有序的 id。
- Producer：消息和数据的生产者，可以理解为往 Kafka 发消息的客户端。
- Consumer：消息和数据的消费者，可以理解为从 Kafka 取消息的客户端。
- Consumer Group ： 消费者组，由多个consumer组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。 所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。
-
存在的问题
- 运维成本高。
- 对于负载不均衡的场景，解决方案复杂。
- 没有自己的缓存，完全依赖 Page Cache。
- Controller和Coordinator和Broker在同一进程中，大量IO会造成其性能下降。
3 消息队列-BMQ
-
整体架构
-
文件结构对比
- Kafka分片数据的写入，是先在Leader上面写好文件，然后同步到Follower上。所以同一个副本的所有Segmenti都在同一台机器上面，就会有单分片过大负载不均衡的问题。
- 在BMQ集群中，对于单个副本来讲，是随机分配到不同的节点上面的，因此不会存在Kafka的负载不均问题。
4 消息队列-RocketMQ
-
使用场景：低延时，针对电商业务线和业务峰值时刻。
-
基本概念：类似于Kafka，多出标签、生产者集群的概念。
-
整体架构
