这是我参与伴学笔记创作活动的第 4 天
一、本节课重点内容
- 消息队列是什么
- 消息队列-Kafka
- 消息队列-BMQ
- 消息队列-RocketMQ
- 最佳实践
- 消息队列在字节
本节课详细内容
0.引入
以商品秒杀和商品购买举例了高并发下遇到的问题并提供了一些解决的方案
1.消息队列的前世今生
2.业内消息队列对比
| 图标 | 名称 | 特点 |
|---|---|---|
| Kafka | 分布式的、分区的、多副本的日志提交服务,在高吞吐场景下发挥较为出色 | |
| RocketMQ | 低延迟、强一致、高性能、高可靠、万亿级容量和灵活的可扩展性,在一些实时场景中运用较广 | |
| pulsar | 是下一代云原生分布式消息流平台,集消息、存储、轻量化函数式计算为一体、采用存算分离的架构设计 | |
| BMQ | 和Pulsar架构类似,存算分离,初期定位是承接高吞吐的离线业务场景,逐步替换掉对应的Kafka集群 |
3.消息队列Kafka的使用
创建集群->新增topic->编写生产者逻辑->编写消费者逻辑
基本概念
Topic:逻辑队列,不同业务创建不同Topic
Cluster:物理集群,每个集群可以建立多个不同Topic
Producer:生产者,负责将业务消息发送到Topic中
Consumer:消费者,负责消费Topic中消息
ConsumerGroup:消费者组,不同consumer消费进度互不干涉
Partition:分区,不同分区可并发处理
Offset:消息在partition内的相对位置,可以理解为唯一ID,在partition内严格递增
Replica:每个分区有多个副本。分为leader和follower,生产消费都与leader交互,follower与leader进行同步。具有选举机制
Broker:服务代理节点。对于 Kafka 而言,Broker 可以简单地看作一个独立的 Kafka 服务节点或 Kafka 服务实例。大多数情况下也可以将 Broker 看作一台 Kafka 服务器,前提是这台服务器上只部署了一个 Kafka 实例。一个或多个 Broker 组成了一个 Kafka 集群。一般而言, 我们更习惯使用首字母小写的 broker 来表示服务代理节点。
数据复制
kafka架构
一条消息从生产到消费是如何处理的
Producer端逻辑、Broker端逻辑、Consumer端逻辑
思考
如果发送一条消息,等到其成功后再发一条会有什么问题?
会拖慢系统的执行效率。
那 Kafka是高吞吐的,如何去保证呢?
把消息做一个batch,可以减少io次数,增强发送能力
那如果带宽低但是消息多可以做一个压缩,通过压缩,减少消息大小,目前支持Snappy、Gzip、LZ4、ZSTD压缩算法
消息队列-BMQ
Kafka在使用中遇到问题
BMQ架构
BMQ各模块是如何工作的,Broker、Proxy、HDFS、MetaStorage
BMQ多机房容灾
消息队列-RocketMQ
RocketMQ使用场景
RocketMQ和Kafka对比
RocketMQ架构介绍,Producer、Broker、Nameserver、Consumer
一条消息从生产到消费是如何处理的,Producer端逻辑、Broker端逻辑、Consumer端逻辑
消息队列在字节
一些最佳实践的场景,包括数据展示
三、课后问题
- 消息队列的应用场景有哪些?
- Kafka的哪些Feature让其可以支撑大吞吐写入的场景?
- Kafka Consumer Rebalance的流程简述?
- BMQ相比较Kafka有哪些优势?
- RocketMQ有哪些特有的Feature?
- RocketMQ事务消息处理流程简述?
- 你认为MQ后面应该如何发展?(开放题)
待续