day3
BMQ
简介：兼容kafka协议，存算分离，云原生消息队列
架构图：
与kafka区别：加入了Proxy Cluster 并且Controller 和Coordinator被独立出来被进行部署，底层新增了一个分布式存储系统 Meta Storage 相当于kafka的zookeeper
运维操作对比：
从这里可以看出BMQ相对于kafka来说运维成本更低，原因是Proxy和Broker都是无状态的
写入流程：
数据校验->判断参数是否合法->把数据放入buffer中->Writer Thread异步写入
读取文件Proxy
Fetch Request->Wait流程->Cache（kafka用的pagecache）如果存在我们想要的数据则直接返回，如果没有，再开始去Storage当中寻找，首先会Open这个文件， 然后通过Index找到数据所在的具体位置，从这个位置开始读取数据，即Open File Seek Read
wait干什么用的？比如有一个Topic, 如果一直没有数据写入，consumer就会一直发送Fetch Request，如果Consumer数量过多，server端是扛不住的，故设置一个等待机制
多机房部署：
为什么需要呢？
高可用服务除了要防止单机故障以外，还要防止机房级故障
高级特性：
泳道消息：
字节内部术语：BOE PPE
BOE: Bytedance Offline Environment,是一套完全独立的线下机房环境，多个人同时测试，需要等待上一个人测试完成
PPE: Product Preview Environment,即产品预览环境，对于PPE的消费者来说，资源没有生产环境多，所以无法承受生产环境的流量
泳道相当于发消息时加了一个标识，解决了主干泳道流量隔离问题以及泳道资源重复创建问题。
Databus:
原生SDK的问题：
1.客户端配置较为复杂 2.不支持动态配置，更改配置需要停掉服务 3.对于latency不是很敏感的业务，batch 效果不佳
Data解决了该问题
其优点：
1 简化消息队列客户端复杂度 2 解耦业务与Topic 3 缓解集群压力，提高吞
Mirror:
解决了跨region读写问题
Index:
通过写入的Logld等业务字段等进行消息的查询，可以直接在BMQ中将数据结构化，配置索引DDL，异步构建索引后，通过Index Query服务读出数据来
总结：
BMQ相比kafka加了许多新的东西，使得架构更加合理，在实际开发中我们也要发现问题，想办法解决问题。同时也应该考虑更多可能发生的问题并加以解决。
引用：图片来自juejin.cn/course/byte…
