这是我参与「第三届青训营 -后端场」笔记创作活动的的第2篇笔记
消息队列
- Kafka：分布式的、分区的、多副本的日志提交服务，在高吞吐场景下发挥较为出色
- RocketMQ：低延迟、强一致、高性能’高可靠、万亿级容量和灵活的可扩展性，在一些实时场景中运用较广
- Pulsar：是下一代云原生分布式消息流平台，集消息‘存储’轻量化函数式计算为一体、采用存算分离的架构设计
- BMQ：和Pulsar架构类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群
Kafka
- 创建集群
- 新增Topic
- 编写生产者逻辑
- 编写消费者逻辑
Topic：逻辑队列
Offset：消息在partition内的相对位置消息，可以理解为唯一ID，在partition内严格递增
每个分片有多个Replica，Leader Replica将会从ISR(In-Sync Replicas)中选出
数据复制
Kafka架构
Producer 数据压缩
通过压缩，减少消息大小，提高吞吐量
Broker-数据的存储
- 文件结构
顺序写
时间戳索引查询
传统数据拷贝，会有多次数据拷贝
零拷贝，使用sendfile系统调用，降低数据拷贝
Consumer-消息的接收端
- 通过手动分配，哪一个Consumer消费哪一个Partition完全由业务决定。
- 自动分配，Rebalance，Coordinator
Consumer Rebalance
自动分配的机制
问题总结
- 运维成本高
- 对于负载不均衡的场景，解决方案复杂
- 没有自己的缓存，完全依赖Page Cache
- Controller和Coordinator和Broker在同一进程中，大量IO会造成其性能下降
消息队列-BMQ
兼容Kafka协议，存算分离，云原生消息队列
文件结构
每个DataNode会随机存储三个分片
Broker-Partition状态机
保证对于任意分片在同一时刻只能在一个Broker上存活
BMQ-高级特性
泳道消息
BOE：Bytedance Offline Environment, 是一套完全独立的线下机房环境
PPE：Product Preview Environment, 即产品预览环境
开发 -> BOE -> PPE -> Prod
Databus
- 简化消息队列客户端复杂度
- 解耦业务与Topic
- 缓解集群压力，提高吞吐
