背景：为了解决Kafka存在的问题而产生
兼容了kafka的协议，生产者和消费者在不用变的情况下就可以对BMQ进行消费，存算分离，云原生消息队列
架构图如下：
主要区别在于：
Producer和Consumer是等同意义的，但是加了一个Proxy的Cluster，而且Controller和Coordinator被独立了出来，在底层新增了一个分布式文件存储（HDFS），实现了读写分离
不需要多次拷贝，只要Proxy修改一下路由就ok了
HDFS写文件流程
随机选择一定数量的DataNode进行写入
Broker中有一个状态机的机制，用来保证脑裂的问题，保证对于任意分片在同一时刻只能在一个Broker上存活
Recover机制可以保持真实属于和原数据一致，然后SaveCheckPoint
写文件流程
如果DataNode节点挂了，或者其他什么原因导致我们写文件失败，应该如何处理
多机房部署
将Proxy和Broker在多个机房部署，对于我们的proxy是无状态的，在每一个机房都会处理全量的分区，对于Broker会有些不一样，需要所有机房的Broker加在一起才能组成一个Topic所有分区的整个集合。
高级特性
就是在本身的基础功能之外，向外提供的应对复杂场景的功能。
泳道消息：
开发流程：开发->BOE（一套完全独立的线下机房环境）->PPE（产品预览环境）->Prod
问题所在：多个人同时测试，需要等待上一个人测试完成。
如果启用好几个，每多一个测试人员，都需要重新搭建一个相同配置的Topic，造成人力和资源的浪费
对于PPE的消费者来说，资源没有生产环境多，所以无法承受生产环境的流量
解决主干泳道流量隔离问题以及泳道资源重复创建问题
DataBus
直接使用原生SDK的问题：
1.客户端配置较为复杂 2.不支持动态配置，更改配置需要停掉服务 3对于latancy不是很敏感的业务，batch效果不佳
batabus结构：
1.简化消息队列客户端复杂度
2.解耦业务与Topic
3.缓解集群压力，提高吞吐
Mirror
我们是否可以通过多机房部署的方式，解决跨Region读写的问题？（解决高延迟的问题）
如果通过多机房的方式会有什么问题呢？
通过镜像异步拉取同步的组件
index
如果希望通过写入Logid，UserID或者其他的业务字段进行消息的查询，该怎么做？
把数据先写到BMQ中数据结构化，配置索引DDL，异步构建索引后，通过index Query服务读取数据。
Parquet
是hadoop生态圈中一种新型列式存储格式，它可以兼容hadoop生态圈中大多数计算框架（hadoop，spark）等，被多种查询引擎之支持
