一. BMQ简介
兼容Kafka协议，存算分离，云原生消息队列
二. HDFS写文件流程
随机选择一定数量的DataNode进行写入
三. BMQ文件结构
在BMQ集群中，因为对于单个副本来讲，是随机分配到不同的节点上面的，因此不会存在Kafka的负载不均问题
四. Broker-Partition状态机
Controller做好分片的分配之后，如果在该Broker分配到了Broker, 首先会start这个分片，然后进入Recover状态，这个状态主要有两个目的获取分片写入权利，也就是说，对于hdfs来讲，只会允许我一个分片进行写入，只有拿到这个权利的分片我才能写入，保证对于任意分片在同一时刻只能在一个Broker上存活，第二个目的是如果上次分片是异常中断的，没有进行save checkpoint，这里会重新进行save checkpoint,然后就进入了正常的写流程状态，创建文件，到一定大小之后又开始建立新的文件进行写入
五. Broker-写文件流程
数据校验->参数是否合法->会把数据放入Buffer中->Writer Thread
六. Broker-写文件Failover
如果我们挑选节点中有一个出现了问题，导致不能正常写入了，可以重新找正常的节点创建新的文件进行写入，这样也就保证了写入的可用性
七. 读取文件Proxy
Fetch Request->Wait流程，有一个Topic, 如果一直没有数据写入，consumer就会一直发送Fetch Request，如果Consumer数量过多，server端是扛不住的，故设置一个等待机制->Cache去找是否有存在我们想要的数据，如果有直接返回，如果没有，再开始去存储系统当中寻找，首先会Open这个文件， 然后通过Index找到数据所在的具体位置，从这个位置开始读取数据，即
- Open File
- Seek
- Read
八. 多机房部署
防止机房级故障所带来的影响
九. BMQ-高级特性
9.1 泳道消息
开发流程
开发->BOE->PPE->Prod
BOE: Bytedance Offline Environment,是一套完全独立的线下机房环境，多个人同时测试，需要等待上一个人测试完成
PPE: Product Preview Environment,即产品预览环境，对于PPE的消费者来说，资源没有生产环境多，所以无法承受生产环境的流量
9.2 Databus
9.2.1解决问题：
- 客户端配置较为复杂
- 不支持动态配置，更改配置需要停掉服务
- 对于latency不是很敏感的业务，batch 效果不佳
9.2.2优点：
- 简化消息队列客户端复杂度
- 解耦业务与Topic
- 缓解集群压力，提高吞吐
9.3. Mirror
使用Mirrr通过最终一致的方式， 解决跨Region 读写问题
9.4 Index
通过写入的Logld、 Userld或者其他的业务字段进行消息的查询，可以直接在BMQ中将数据结构化，配置索引DDL，异步构建索引后，通过Index Query服务读出数据
9.5 Parquet
Apache Parquet是Hadoop生态圈中一种新型列式存储格式，它可以兼容Hadoop生态圈中大 多数计算框架(Hadoop、Spark等)，被多种查询引擎支持(Hive、Impala、 Drill等) 直接在BMQ中将数据结构化，通过Parquet Engine,可以使用不同的方式构建Parquet格式文件
十. 个人感悟
- 一个事物的提出通常是要解决某一特定实际问题的，多去思考
- 多敲代码
