消息队列之BMQ、RocketMQ ｜ 青训营笔记

陌路森
206 阅读5分钟

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

一、本堂课重点内容

  1. 消息队列-BMQ
  2. 消息队列-RocketMQ

二、详细知识点介绍

BMQ

简介

BMQ兼容Kafka协议，存算分离，云原生消息队列，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群

运维操作对比

image.png

HDFS写文件流程

首先客户端写入前会选择一定数量的DataNode，这个数量是副本数，然后将一个文件写入到这三个节点上，切换到下一个segment之后，又会重新选择三个节点进行写入。这样一来，对于单个副本的所有segment来讲，会随机的分配到分布式文件系统的整个集群中

BMQ文件结构

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

Broker-Partition状态机

保证对于任意分片在同一时刻只能在一个 Broker上存活

Broker-写文件流程

数据校验：CRC , 参数是否合法 校验完成后，会把数据放入Buffer中 通过一个异步的Write Thread线程将数据最终写入到底层的存储系统当中

Broker-写文件 Failover

如果 DataNode节点挂了或者是其他原因导致我们写文件失败，可以重新找正常的节点创建新的文件进行写入，这样也就保证了我们写入的可用性

Proxy

首先Consumer发送一个Fetch Request，然后会有一个Wait流程，经过我们的wait流程后，我们会到我们的Cache里面去找到是否有存在我们想要的数据，如果有直接返回，如果没有，再开始去存储系统当中寻找，首先会Open这个文件，然后通过Index找到数据所在的具体位置，从这个位置开始读取数据

多机房部署

对于一个高可用的服务，除了要防止单机故障所带来的的影响意外，也要防止机房级故障所带来的影响，比如机房断点，机房之间网络故障等等。

Proxy -> Broker -> Meta -> HDFS

高级特性

泳道 -> Databus -> Mirror -> Index -> Parquet

泳道消息

开发 -> BOE -> PPE -> Prod

  • BOE: Bytedance Offline Environment，是一套完全独立的线下机房环境
  • PPE:Product Preview Environment，即产品预览环境

Databus

原生SDK的问题:

  • 客户端配置较为复杂
  • 不支持动态配置，更改配置需要停掉服务
  • 对于latency不是很敏感的业务，batch效果不佳

Databus优势：

  • 简化消息队列客户端复杂度
  • 解耦业务与Topic
  • 缓解集群压力，提高吞吐

Mirror

使用Mirror通过最终一致的方式，解决跨Region读写问题。

Index

如果希望通过写入的Logld、Userld 或者其他的业务字段进行消息的查询，直接在BMQ 中将数据结构化，配置索引DDL，异步构建索引后，通过Index Query 服务读出数据。

Parquet

Apache Parquet是Hadoop生态圈中一种新型列式存储格式，它可以兼容Hadoop生态圈中大多数计算框架(Hadoop、Spark等)，被多种查询引擎支持(Hive、Impala、Drill等)。

直接在BMQ中将数据结构化，通过 Parquet Engine，可以使用不同的方式构建Parquet格式文件。

RocketMQ

基本概念

image.png

Producer，Consumer，Broker这三个部分，Kafka和RocketMQ是一样的，而Kafka中的Partition概念在这里叫做ConsumerQueue，

RocketMQ架构

image.png 数据流也是通过Producer发送给Broker集群，再由Consumer进行消费 Broker节点有Master和Slave的概念 NameServer为集群提供轻量级服务发现和路由

存储模型

对于一个Broker来说所有的消息的会append到一个CommitLog上面，然后按照不同的Queue，重新Dispatch到不同的Consumer中，这样Consumer就可以按照Queue进行拉取消费，但需要注意的是，这里的ConsumerQueue所存储的并不是真实的数据，真实的数据其实只存在CommitLog中，这里存的仅仅是这个Queue所有消息在CommitLog上面的位置，相当于是这个Queue的一个密集索引

高级特性-事务消息

image.png

高级特性-延迟发送

image.png

高级特性-消费重试死信队列

image.png

三、实践练习例子

  1. 手动搭建一个Kafka集群。
  2. 完成Hello World的发送与接收。
  3. 关闭其中一个Broker，观察发送与接收的情况，并写出，在关闭一个Broker后，Kafka集群会做哪些事情?

四、课后个人总结

BMQ前景非常广阔，在不远的将来很有可能替代kafka，但网上相关资料较少，我对其中的Partition状态机、failover、Proxy、Parquet等知识掌握还不够好，还需要进一步学习，RocketMQ也是开发过程中非常常用的消息队列，需要我仔细学习。

avatar
文章
阅读
粉丝