这是我参与「第五届青训营 」伴学笔记创作活动的第 15 天
本堂课主要内容是消息队列，下面是我个人听课时的一些笔记。本文是上一篇笔记的续篇，主要关于Kafka的弊端以及BMQ在相应方面所做的提升。
个人笔记
Kafka
-
Kafka数据复制问题：
由一些特殊场景下的节点大量【重启/替换/扩容/缩容】（Kafka集群的这类运维操作都会导致节点的变动，都会有数据复制带来的时间成本问题）引发的，会使某个Broker承载大量帮其他节点进行数据同步的时间开销
-
Kafka负载不均衡：
场景：
这个场景当中，同一个Topic有4个分片，两副本（因为Partition分布在两个Broker上，即两个机器上），可以看到，对于分片1来说，数据量是明显比其他分片要大的，当我们机器IO达到瓶颈的时候，可能就需要把第一台Broker上面的Partition3迁移到其他负载小的Broker上面，但这个为了降低Broker1的IO，平衡副本之间负载的迁徙操作同样是数据复制操作，同样会引起Broker1的IO升高。所以就需要权衡IO设计出一个极其复杂的负载均衡策略。
-
Kafka问题总结：
-
运维成本高
-
对于负载不均衡的场景，解决方案复杂
-
没有自己的缓存，完全依赖Page Cache
-
Controller和Coordinator和Broker在同一进程中，大量IO会造成其性能下降
【Controller是整个集群的大脑，负责对副本和Broker进行分配】
【Coordinator的作用就是帮助Consumer Group进行分片的分配，也叫做分片的rebalance】
-
BMQ
兼容Kafka协议，存算分离，云原生消息队列
-
BMQ架构
特点：
-
兼容Kafka，所以Producer和Consumer都兼容
-
加入Proxy Cluster和Broker Cluster，且Controller和Coordinator被独立出来进行部署
-
存算分离，可以在底层用另外的分布式存储系统Distributed Storage System进行
-
Meta Storage System类似Kafka中的Zoo Keeper，用于存储集群的元数据信息，比如副本的分配信息等等，Controller计算好的方案都会放到这个地方
-
读写分离（类似数据库）：Proxy Cluster处理读请求，Broker Cluster处理写请求
得益于存算分离+读写分离，Proxy和Broker都是无状态的，不会存数据，没有数据复制，降低了运维成本：
-
-
HDFS写文件流程：
通过前面的介绍，我们知道了，同一个副本是由多个segment组成，我们来看看BMQ对于单个文件写入的机制是怎么样的，首先客户端写入前会选择一定数量的DataNode，这个数量是副本数，然后将一个文件写入到这三个节点上， 切换到下一个segment之后，又会重新选择三个节点进行写入。这样一来，对于单个副本的所有segment来讲，会随机的分配到分布式文件系统的整个集群中
-
BMQ不会出现Kafka中的负载不均问题：
和Kafka比较：
对于Kafka分片数据的写入，是通过先在Leader上面写好文件，然后同步到Follower上，所以对于同一个副本的所有Segment都在同一台机器上面。这样就会存在之前我们所说到的单分片过大导致负载不均衡的问题。
但在BMQ集群中，因为对于单个副本来讲，segment是随机分配到不同的节点上面的，因此不会存在Kafka的负载不均问题。
参考
- 字节内部课 —【走进消息队列】
