这是我参与「第五届青训营 」伴学笔记创作活动的第15天
1.消息队列前世今生
1.1概念
消息队列(MQ)，指保存消息的一个容器，本质是个队列。但这个队列呢，需要支持高吞吐，高并发，并且高可用。消息队列可用于解耦、削峰、异步、日志处理。
1.2业内消息队列对比
- Kafka:分布式的、分区的、多副本的日志提交服务，在高吞吐场景下发挥较为出色
- RocketMQ: 低延迟、强一致、高性能、高可靠、万亿级容量和灵活的可扩展性，在一些实时场景中运用较厂
- Pulsar:是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体采用存算分离的架构设计
- BMQ: 和Pulsar架构类似。存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群
2.消息队列-Kafka
2.1使用场景
- 日志信息
- Metrics数据（搜索服务、直播服务、订单服务、支付服务）
- 用户行为（搜索、点赞、评论、收藏）
2.2如何使用Kafka
graph TD
创建集群 --> 新增topic --> 编写生产者逻辑 --> 编写消费者逻辑
2.2Kafka基本概念
- Topic:逻辑队列，不同Topic可以建立不同的Topic
- Cluster:物理集群，每个集群中可以建立多个不同的Topic
- Producer:生产者，负责将业务消息发送到Topic中
- Consumer:消费者，负责消费Topic中的消息
- ConsumerGroup: 消费者组，不同组Consumer消费进度互不干涉
- Offset:消息在partition内的相对位置信息，可以理解为唯一ID，在partition内部严格递增
2.3Kafka问题
- 运维成本高
- 对于负载不均衡的场景，解决方案复杂
- 没有自己的缓存，完全依赖Page Cache
- Controller和Coordinator和Broker在同一进程中，大量IO会造成其性能下降
3.消息队列-BMQ
3.1简介
兼容Kafka 议，存算分离，云原生消息队列
3.2运维操作对比
| Kafka和BMQ运维操作对比 | ||
|---|---|---|
| 具体操作 | Kafka | BMQ |
| 重启 | 需要数据复制，分钟级重启 | 重启后可直接对外服务，秒级完成 |
| 替换 | 需要数据复制，分钟级替换，甚至天级别 | 替换后可直接对外服务，秒级完成 |
| 扩容 | 需要数据复制，分钟级扩容，甚至天级别 | 扩容后可直接对外服务，秒级完成 |
| 缩容 | 需要数据复制，分钟级缩容，甚至天级别 | 缩容后可直接对外服务，秒级完成 |
3.3泳道消息
开发流程
graph TD
开发 --> BOE --> PPE --> Prod
- BOE:Bytedance Offline Environment，是一套完全独立的线下机房环境
- PPE:Product Preview Environment，即产品预览环境
3.4Databus
3.4.1直接使用原生 SDK 会有什么问题?
- 客户端配置较为复杂
- 不支持动态配置，更改配置需要停掉服务
- 对于latency不是很敏感的业务，batch效果不佳
3.4.2Databus优点
- 简化消息队列客户端复杂度
- 解耦业务与Topic
- 缓解集群压力，提高吞吐
3.4Mirror
使用Mirror通过最终一致的方式，解决跨Region读写问题
3.5Parquet
Apache Parquet是Hadoop生态圈中一种新型列式存储格式，它可以兼容 Hadoop生态圈中大多数计算框架(Hadoop、Spark等)，被多种查询引擎支持(Hive、Impala、Dril等)。
4.消息队列-RocketMQ
4.1应用场景
- 针对电商业务线，其业务涉及广泛，如注册、订单、库存、物流等;
- 涉及许多业务峰值时刻，如秒杀活动、周年庆、定期特惠等
4.2RocketMQ和Kafka对比
| RocketMQ和Kafka对比 | ||
|---|---|---|
| 名称 | Kafka | RocketMQ |
| 逻辑队列 | Topic | Topic |
| 消息体 | Message | Message |
| 标签 | 无 | Tag |
| 分区 | Partition | ConsumerQueue |
| 生产者 | Producer | Producer |
| 生产者集群 | 无 | Producer Group |
| 消费者 | Consumer | Consume |
| 消费者集群 | Consumer Group | Consumer Group |
| 集群控制器 | Controller | NameServer |
