消息队列BMQ：more than Kafka | 青训营笔记

这是我参与「第五届青训营」伴学笔记创作活动的第10天。本篇为第五届字节跳动青训营-寒假专场-后端基础课程的笔记。

Kafka 的 劣势：

1. kafka 的升级，替换，扩缩容流程很繁琐——运维成本高
   1. kafka 只能单台重启，同时重启后还要进行数据同步与 leader 回调
2. 对于负载不均衡的场景，解决方案复杂
3. 没有自己的缓存，完全依赖 Page Cache
4. Controller和Coordinator和Broker在同一进程中，大量IO会造成其性能下降

BMQ 是字节跳动出品的消息队列产品，解决了 Kafka 在实际应用中的诸多问题。

BMQ架构的特点

• 兼容kafka协议，producer和consumer
• 存算分离：broker上存储的数据单独利用文件系统（比如：HDFS等）存储

1. 独立的Controller和Coordinaror部署。
2. 采用 proxy cluster
   1. 读取直接由proxy向分布式系统读取，且不需要数据复制
      • 因为不需要数据复制：重启，替换，扩容，缩容等操作相较于Kafka 时间大大降低
   2. 写操作则不做处理直接传给Broker Cluster
   3. 采用缓存机制

读写过程

1. 数据校验参数；（比如CRC校验）
2. 校验完成后，会把数据放入 Buffer 中；
3. 通过异步的 Write 线程将数据最终写入到底层的存储系统。
   1. 返回策略可以自定义：是要在落盘前还是落盘后返回信息？（数据的一致性？最终一致性？）
   2. 隔一段时间 Flush（写入磁盘）
   3. 然后构建数据的 index
   4. 同时创建检查点，防止出错不可用

HDFS写入的过程： 随机选择一些 data node 进行写入操作。 这样可以尽可能让数据分布均匀。

如果node 节点失效如何？ 不要长时间等待，换个节点试试看。

Proxy 工作流程

1. 捕获请求
2. 等待
3. 访问缓存
4. 如果miss 访问存储系统
5. 最终返回数据

多机房部署问题？？

如果A机房的Broker发生故障，那么此时触发Rebalance机制，让其他Broker恢复。

在 Kafka的学习中我们了解了消费中的协调者机制（其协调的底层逻辑正是rebalance）：

• 协调者机制：选举消费组中的一个作为协调者（基于某些机制来重新分配partion）
  • Rebalance机制

    1. 找broker中的coordinator（find request）

    2. 在consumer group 中选举一个consumer leader

    3. consumer group向coordinator发送sync请求，其中leader会额外发送携带分配方案的请求

    4. coordinator通过心跳机制监控consumers是否宕机，如果宕机出发rebalance

Mirror 机制

如果region过多（cn ，美洲...) 我们还能直接进行多机房部署吗？（跨机房访问的成本极大！！！延迟极高）

mirror就是一个解决方案。

当然这是有所放弃的，通过mirror，好像能够获得一个低延迟返回的结果，不过这个结果的时效性较差（但是可以接受的范围内），因此也算是解决了跨级房读取的高延迟问题。

跨地域场景下，如何解决分布式系统的一致性？-阿里云开发者社区 (aliyun.com)

Index 机制

如果希望通过写入数据内容进行item的搜索，MQ怎么办？

直接在BMQ种将数据结构化，配置索引DDL，异步构建索引，通过 Index query 服务读出数据。（有点像数据库了...）

Parquet

Parquet是面向分析型业务的列式存储格式，由Twitter和Cloudera合作开发，2015年5月从Apache的孵化器里毕业成为Apache顶级项目。

parquet学习总结 - 简书 (jianshu.com)

除了传统的index方案，也可以使用parquet的存储方案（use engine），这样可以提高某些场景下的查询速率。