继上一篇文章出摊啊消息队列，介绍Kafka，这篇文章主要介绍BMQ和RocketMQ，这两个Kafka的后继者及他们解决了Kafka什么痛点。
BMQ
- 兼容Kafka协议
- 存算分离
- 云原生消息队列
基础结构和优缺点
为兼容Kafka协议，整体架构看起来还是和Kafka类似，生产者产生消息，消费者取用消息，不同消费者可组成不同组。消息队列中由Controller和Coordinator统一调度索引，不同的Cluster来存储消息。但增加了一个Proxy Cluster，更加灵活。 因为存算分离，底部有分布式存储系统。
所以BMA的重启、替换、扩容、缩容方面都远比Kafka要快，可以在秒级完成这些操作。
Broker-Partition 状态机
保证对于任意分片，在同一时刻只能在一个Broker上存活。
写文件流程
- 在收到信息后，首先进行数据校验，保证数据传输的准确性
- 随后校验参数，验证其是否合法。
- 何时返回给服务器数据读写成功的信息可以自由定义，在Buffer读写处完成可以快速吞吐，而在真实读写完成后再返回则是更看重可靠性。
- 数据写入需要Flush到硬盘上，之后建立索引和检查点。
如果写文件Failover，比如节点挂了导致写文件失败，需要单独处理，寻找可用节点完成segment复制。
高级特性
泳道消息：解决主干泳道流量隔离问题以及泳道资源重复创建问题Databus：直接使用原生SDK客户端配置复杂，不支持动态配置，而且对于latency不敏感的业务，batch效果不佳。 ……
rocketMQ
RocketMQ既可为分布式应用系统提供异步解耦和削峰填谷的能力，同时也具备互联网应用所需的海量消息堆积、高吞吐、可靠重试等特性。 相比于Kafka，提供新的“Yag”消息标签，二级消息类型，用来进一步区分某个Topic下的消息分类。
