消息队列原理与实战 | 青训营笔记这是我参与「第五届青训营」伴学笔记创作活动的第 13 天概述本节课程主要分为五个方

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

概述

本节课程主要分为五个方面：

消息队列的前世今生
消息队列-Kafka
消息队列-BMQ
消息队列-RocketMQ
最佳实践

课前部分主要罗列课程中涉及到的概念。对于不熟悉的概念，同学们可以提前查询预习；课中部分主要罗列每一部分的关键思路，帮助同学们跟上课程的进度；课后部分是一些问题，帮助同学们在课后梳理本课程的重点。

课前

消息队列的前世

消息队列应用场景
消息队列的发展历史

常见消息队列

Kafka使用场景、架构、高级特性
Pulsar使用场景、架构、高级特性
Rocket使用场景、架构、高级特性

课中

到这里以上四个场景【①系统崩溃②服务处理能力有限3链路耗时长尾4日志如何处理】就都结束了，我们现在来看看，刚刚遇到的几个问题，分别应该怎么解决

消息队列是什么

解耦
削峰
异步
日志处理

消息队列的前世今生

消息队列-Kafka

kafka使用场景，业务日志、用户行为数据、Metrics数据

使用kafka

第一步：首先需要创建一个Kafka集群，但如果你是在字节工作，恭喜你这一步消息团队的小伙伴已经帮你完成了

第二步：需要在这个集群中创建一个Topic，并且设置好分片数量

第三步：引入对应语言的SDK，配置好集群和Topic等参数，初始化一个生产者，调用Send方法，将你的Hello World发送出去

第四步：引入对应语言的SDK，配置好集群和Topic等参数，初始化一个消费者，调用Poll方法，你将收到你刚刚发送的Hello World

基本概念，Producer、Cluster、Consumer、Topic、Partition

Topic：Kakfa中的逻辑队列，可以理解成每一个不同的业务场景就是一个不同的topic，对于这个业务来说，所有的数据都存储在这个topic中

Cluster：Kafka的物理集群，每个集群中可以新建多个不同的topic

Producer：顾名思义，也就是消息的生产端，负责将业务消息发送到Topic当中

Consumer：消息的消费端，负责消费已经发送到topic中的消息

Partition：通常topic会有多个分片，不同分片直接消息是可以并发来处理的，这样提高单个Topic的吞吐

数据迁移、Offset、Partition选主

Replica：分片的副本，分布在不同的机器上，可用来容灾，Leader对外服务，Follower异步去拉取leader的数据进行一个同步，如果leader挂掉了，可以将Follower提升成leader再堆外进行服务

ISR：意思是同步中的副本，对于Follower来说，始终和leader是有一定差距的，但当这个差距比较小的时候，我们就可以将这个follower副本加入到ISR中，不在ISR中的副本是不允许提升成Leader的

下面这幅图代表着Kafka中副本的分布图。途中Broker代表每一个Kafka的节点，所有的Broker节点最终组成了一个集群。整个图表示，图中整个集群，包含了4个Broker机器节点，集群有两个Topic，分别是Topic1和Topic2，Topic1有两个分片，Topic2有1个分片，每个分片都是三副本的状态。这里中间有一个Broker同时也扮演了Controller的角色，Controller是整个集群的大脑，负责对副本和Broker进行分配

而在集群的基础上，还有一个模块是ZooKeeper，这个模块其实是存储了集群的元数据信息，比如副本的分配信息等等，Controller计算好的方案都会放到这个地方

一条消息从生产到消费是如何处理的，Producer端逻辑、Broker端逻辑、Consumer端逻辑

对于一个Consumer Group来说，多个分片可以并发的消费，这样可以大大提高消费的效率，但需要解决的问题是，Consumer和Partition的分配问题，也就是对于每一个Partition来讲，该由哪一个Consumer来消费的问题。对于这个问题，我们一般有两种解决方法，手动分配和自动分配

第一，手动分配，也就是Kafka中所说的Low Level消费方式进行消费，这种分配方式的一个好处就是启动比较快，因为对于每一个Consumer来说，启动的时候就已经知道了自己应该去消费哪个消费方式，就好比图中的Consumer Group1来说，Consumer1去消费Partition1,2,3 Consumer2，去消费456， Consumer3去消费78。这些Consumer再启动的时候就已经知道分配方案了，但这样这种方式的缺点又是什么呢，想象一下，如果我们的Consumer3挂掉了，我们的7,8分片是不是就停止消费了。又或者，如果我们新增了一台Consumer4，那是不是又需要停掉整个集群，重新修改配置再上线，保证Consumer4也可以消费数据，其实上面两个问题，有时候对于线上业务来说是致命的。

所以Kafka也提供了自动分配的方式，这里也叫做High Level的消费方式，简单的来说，就是在我们的Broker集群中，对于不同的Consumer Group来讲，都会选取一台Broker当做Coordinator，而Coordinator的作用就是帮助Consumer Group进行分片的分配，也叫做分片的rebalance，使用这种方式，如果ConsumerGroup中有发生宕机，或者有新的Consumer加入，整个partition和Consumer都会重新进行分配来达到一个稳定的消费状态

Rebalance的具体步骤

消息队列-BMQ

Kafka在使用中遇到问题

比如重启问题：举个例子来说，如果我们对一个机器进行重启首先，我们会关闭一个Broker，此时如果该Broker上存在副本的Leader，那么该副本将发生leader切换，切换到其他节点上面并且在ISR中的Follower副本，可以看到图中是切换到了第二个Broker上面。
- 而此时，因为数据在不断的写入，对于刚刚关闭重启的Broker来说，和新Leader之间一定会存在数据的滞后，此时这个Broker会追赶数据，重新加入到ISR当中。
- 当数据追赶完成之后，我们需要回切leader，这一步叫做prefer leader，这一步的目的是为了避免，在一个集群长期运行后，所有的leader都分布在少数节点上，导致数据的不均衡。
- 通过上面的一个流程分析，我们可以发现对于一个Broker的重启来说，需要进行数据复制，所以时间成本会比较大，比如一个节点重启需要10分钟，一个集群有1000个节点，如果该集群需要重启升级，则需要10000分钟，那差不多就是一个星期，这样的时间成本是非常大的。
- 有同学可能会说，老师可以不可以并发多台重启呀，问的好，不可以。为什么呢，在一个两副本的集群中，重启了两台机器，对某一分片来讲，可能两个分片都在这台机器上面，则会导致该集群处于不可用的状态。这是更不能接受的。

但我们的数据复制又会引起Broker1的IO升高，所以问题就变成了，我为了去解决IO升高，但解决问题的过程又会带来更高的IO，所以就需要权衡IO设计出一个极其复杂的负载均衡策略

我们对以上两个问题进行总结，

第一，因为有数据复制的问题，所以Kafka运维的时间成本和人力人本都不低

第二，对于负载不均衡的场景，我们需要有一个较为复杂的解决方案进行数据迁移，从而来权衡IO升高的问题

除了以上两个问题以外，Kafka自身还存在其他的问题

比如，Kafka没有自己的缓存，在进行数据读取的时候，只有Page Cache可以用，所以不是很灵活

另外在前面的介绍当中，相信大家也了解到了，Kafka的Controller和Coordinator都是和Broker部署在一起的，Broker因为承载大量IO的原因，会导致Controller和Coordinator的性能下降，如果到一定程度，可能会影响整个集群的可用性

BMQ架构

BMQ兼容Kafka协议，存算分离，云原生消息队列，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群，我们来了解一下BMQ的架构特点

Producer -> Consumer -> Proxy -> Broker

-> HDFS -> Controller -> Coordinator -> Meta

着重强调一下Proxy和Broker无状态，为下面运维比较做铺垫这里简单介绍一下存算分离，适配Kafka协议，为什么不选择Pulsar的原因

BMQ各模块是如何工作的，Broker、Proxy、HDFS、MetaStorage

通过前面的介绍，我们知道了，同一个副本是由多个segment组成，我们来看看BMQ对于单个文件写入的机制是怎么样的，首先客户端写入前会选择一定数量的DataNode，这个数量是副本数，然后将一个文件写入到这三个节点上，切换到下一个segment之后，又会重新选择三个节点进行写入。这样一来，对于单个副本的所有segment来讲，会随机的分配到分布式文件系统的整个集群中

对于Kafka分片数据的写入，是通过先在Leader上面写好文件，然后同步到Follower上，所以对于同一个副本的所有Segment都在同一台机器上面。就会存在之前我们所说到的单分片过大导致负载不均衡的问题，但在BMQ集群中，因为对于单个副本来讲，是随机分配到不同的节点上面的，因此不会存在Kafka的负载不均问题

其实对于写入的逻辑来说，我们还有一个状态机的机制，用来保证不会出现同一个分片在两个Broker上同时启动的情况，另外也能够保证一个分片的正常运行。首先，Controller做好分片的分配之后，如果在该Broker分配到了Broker，首先会start这个分片，然后进入Recover状态，这个状态主要有两个目的获取分片写入权利，也就是说，对于hdfs来讲，只会允许我一个分片进行写入，只有拿到这个权利的分片我才能写入，第二一个目的是如果上次分片是异常中断的，没有进行save checkpoint，这里会重新进行一次save checkpoint，然后就进入了正常的写流程状态，创建文件，写入数据，到一定大小之后又开始建立新的文件进行写入。

数据校验：CRC , 参数是否合法

校验完成后，会把数据放入Buffer中

通过一个异步的Write Thread线程将数据最终写入到底层的存储系统当中

这里有一个地方需要注意一下，就是对于业务的写入来说，可以配置返回方式，可以在写完缓存之后直接返回，另外我也可以数据真正写入存储系统后再返回，对于这两个来说前者损失了数据的可靠性，带来了吞吐性能的优势，因为只写入内存是比较快的，但如果在下一次flush前发生宕机了，这个时候数据就有可能丢失了，后者的话，因为数据已经写入了存储系统，这个时候也不需要担心数据丢失，相应的来说吞吐就会小一些

我们再来看看Thread的具体逻辑，首先会将Buffer中的数据取出来，调用底层写入逻辑，在一定的时间周期上去flush，flush完成后开始建立Index，也就是offset和timestamp对于消息具体位置的映射关系

Index建立好以后，会save一次checkpoint，也就表示，checkpoint后的数据是可以被消费的辣，我们想一下，如果没有checkpoint的情况下会发生什么问题，如果flush完成之后宕机，index还没有建立，这个数据是不应该被消费的

最后当文件到达一定大小之后，需要建立一个新的segment文件来写入