目标
- 学习中间件：消息队列
介绍消息队列
-
消息队列(MQ):指保存消息的一个容器，本质是个队列。但这个队列呢，需要支持高吞吐，高并发，并且高可用。
-
消息队列的前世今生
- TIB，诞生于1985年，服务于金融机构和新闻机构。
- IBM MQ/WebSphere，诞生于1993年，商业消息队列平台市场主要玩家。
- MSMQ，微软发布于1997年。
- JMS，诞生于2001年本质上是一套Java API。
- AMQP/RabbitMQ，规范发布于2004年，同年，RabbitMQ面市。
- Kafka，2010年由Linked开源。
- RocketMQ，2011年阿里中间件团队自研。
- Pulsar，2012年诞生于Yahoo内部。
-
业界消息队列比较
- Kafka: 分布式的、分区的、多副本的日志提交服务，在高吞吐场景下发挥较为出色
- RocketMQ: 低延迟、强一致、高性能、高可靠、万亿级容量和灵活的可扩展性，在一些实时场景中运用较广
- Pusr: 是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体，采用存算分离的架构设计
- BMQ: 和Pulsar架构类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群
-
消息队列Kafka
-
使用场景： 搜索服务、直播服务、订单服务、支付服务、用户行为（搜索、点赞、评论、收藏）、日志信息
-
如何使用： 创建集群 → 新增Topic → 编写生产者逻辑 → 编写消费者逻辑
-
基本概念：
-
Topic: 逻辑队列，不同Topic可以建立不同的Topic
-
Cluster: 物理集群，每个集群中可以建立多个不同的Topic
-
Producer: 生产者，负责将业务消息发送到Topic中
- 批量发送： 批量发送可以减少IO次数，从而加强发送能力
- 数据压缩： 通过压缩，减少消息大小，目前支持Snappy、Gzip、LZ4、ZSTD压缩算法
-
Consumer: 消费者，负责消费Topic中的消息
-
ConsumerGroup: 消费者组，不同组Consumer消费进度互不干涉
-
Offset: 消息在partition内的相对位置信息，可以理解为唯一lD,在partition内部严格递增。
-
Replica： 每个分片有多个Replica,Leader Replica将会从ISR中选出。
-
Broker：
-
采用顺序写的方式进行写入，以提高写入效率
-
如何找到消息： Consumer通过发送FetchRequest请求消息数据，Broker会将指定Offset处的消息，按照时间窗口和消息大小窗口发送给Consumer,那么是如何寻找到细节的呢：
- 二分找到小于目标offset的最大文件
- 二分找到小于目标offset的最大索引位置
- 二分找到小于目标时间戳最大的索引位置，再通过寻找offset的方式找到最终数据。
-
-
-
缺点
- 运维成本高。
- 对于负载不均衡的场景，解决方案复杂。
- 没有自己的缓存，完全依赖Page Cache。
- Controller 和 Coordinator和Broker 在同一进程中，大量 I0会造成其性能下降。
-
-
BMQ
- BMO兼容Kaka协议，存算分离，云原生消息队列，初期定位是承接高吞的离线业务场景，逐步替换掉对应的Kaka集群。
-
RocketMQ
- 数据流通过Producer发送给Broker集群，再由Consumer进行消费。
- Broker节点有Master和Slave的概念。
- NameServer为集群提供轻量级服务发现和路由。
- 高级特性： 事务消息、重试和死信队列、延迟队列。
- 架构如图
总结
- 认识到业内很多有名的消息队列
- 学到了消息队列使用的场景，了解到消息队列之间也有不同的优势和缺点
- 会在以后的开发业务中使用消息队列，尝试自己实践去理解
引用
- ppt:走进消息队列 副本.pptx - 飞书云文档 (feishu.cn)
- 其他优秀的掘金文章
