消息队列原理与实战｜ 青训营笔记

xYx
98 阅读6分钟

这是我参与「第五届青训营 」伴学笔记创作活动的第 12 天

1.主要内容

  1. 消息队列是什么
  2. 消息队列的发展
  3. 主流消息队列介绍

2.课程详细内容

消息队列发展

消息队列是什么

消息队列，指保存消息的一个容器，本质是个队列。但是这个队列需要支持高吞吐、高并发、高可用。

  • 系统崩溃，使用消息队列进行解耦
  • 服务处理能力有限，使用消息队列进行削峰
  • 链路耗时长尾，使用消息队列进行异步
  • 消息队列处理日志问题

消息队列的发展

  • TIB: 用于高盛，用于解决金融交易。于是发布订阅模式（PubSub）诞生了，同时还诞生了世界上第一个现代消息队列软件：Teknekron的The Information Bus（TIB）
  • IBM MQ: 在20世纪80年代后期，IBM开始研究开发自己的消息队列软件，实际开发工作始于1990年，三年后，消息队列服务器软件IBM MQ产品系列面世。17年后，MQ系列进化成了WebSphere MQ并统治着商业消息队列平台市场
  • MSMQ：微软消息队列
  • JMS ：本质上是一套Java API，JMS试图通过提供公共Java API的方式，隐藏单独MQ产品供应商提供的实际接口，从而跨越了壁垒和解决了互通问题。从技术上讲，Java应用程序只需针对JMS API编程，选择合适的MQ驱动即可。JMS会打理好其他部分。
  • AMQP/RabbitMQ ：开放标准，任何人都可以执行这一标准，同年RabbitMQ问世
  • Kafka ： kafka的诞生，是为了解决linkedin的数据管道问题，研发的消息传递系统
  • RocketMQ ：Kafka的特殊的日志通道定位，是不能完全满足阿里巴巴高频的在线交易场景，为此团队设计并研发了新一代消息引擎 RocketMQ。国内一些中大型规模的公司普遍部署了两套消息引擎，一套选择 Apache RocketMQ 用在交易，数据分发等核心链路上，一套选择 Apache Kafka 用在大数据等在线、离线分析链路上。毫无疑问，Kafka 目前在大数据生态建设这块，确实具备一定的先发优势。

主流消息队列

  • Kafka ：分布式、分区、多副本的日志提交服务，高吞吐场景下发挥出色
  • RocketMQ ：低延迟、强一致、高性能、高可靠、万亿级容量和灵活的可扩展性，在实时场景中运用较广
  • Pulsar ：下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体，采用存算分离的架构设计
  • BMQ ：和Pulsar架构类似，存算分离，初期定位是承高吞吐离线业务场景逐步替换掉Kafka集群

消息队列-Kafka

使用场景

  • 各个服务的日志信息
  • Metrics数据
  • 用户行为

Kafka简介

Kafka使用流程

  1. 首先创建Kafka集群
  2. 在集群中创建一个Topic，并设置好分片数量
  3. 引入对应语言的SDK，配置好集群和Topic等参数，初始化一个生产者，调用Send方法，将你的信息发出去
  4. 初始化一个消费者，调用Poll方法，将收到信息

基本概念

  • Topic：Kafka中的逻辑队列，理解为每一个不同业务场景就是一个不同的Topic，对于这个业务来说，所有的数据都存储在这个Topic中
  • Cluster：Kafka的物理集群，每个集群中可以新建多个不同的Topic
  • Producer：生产者，消息的生产端，负责将业务消息发送到Topic中
  • Consumer：消费者，消息的消费端，负责消费已经发送到Topic中的消息
  • ConsumerGroup：消费者组，不同组的Consumer消费进度互不干涉
  • Partition：通常Topic会有多个分片，不同分片直接消息并发处理，可以提高单个Topic的吞吐
  • Offset：消息在partition内的相对位置信息，可以理解为唯一ID，在partition内部严格递增
  • Replica：分片的副本，分布在不同的机器上，可以容灾，每个分片有多个Replica，Leader将会从ISR中选出。Leader对外服务，Follower异步去拉取Leader的数据进行同步，如果Leader挂了，可以将Follower提成Leader再进行服务
  • ISR：同步中的副本，对于Follower来说，始终和Leader是有差距的，但是这个差距较小时，就可以将这个Follower副本加入到ISR中，不在ISR中的副本是不可以提成Leader的
  • Broker：Kafka的结点，集群中有一个Broker会同时扮演Controller的角色
  • Controller：集群大脑，负责对副本和Broker进行分配
  • ZooKeeper：存储集群的元数据信息，例如副本的分配信息等等，Controller计算好的方案会放在这

Kafka提高吞吐、稳定性

Producer：

  • 批量发送：减少IO次数，加强发送能力
  • 数据压缩：减少消息大小

Broker：

  • 顺序写：采用顺序写的方式进行写入，以提高写入效率
  • 消息索引：偏移量索引文件，时间戳索引文件
  • 零拷贝：Consumer从Broker中读取数据，通过sendfile方式，将磁盘读到os内核缓冲区后，直接转到socket buffer进行网络发送

Consumer：

  • Low Level：手动分配
  • High Level：自动分配，在Broker集群中，对于不同的Consumer Group来讲，都会选取一台Broker当Corrdinator来帮助Consumer Group进行分片的分配，也叫做分片的rebalance

Kafka的问题

  1. 运维成本高
  2. 对于负载不均衡的场景，解决方案十分复杂
  3. 没有自己的缓存，全部依赖Page Cache
  4. Controller和Coordinator和Broker在同一进程中，大量的IO会造成其性能下降

消息队列- RocketMQ

使用场景

电商业务线，需要保证数据准确性，如订单、注册、库存、物流等；也有业务峰值，如秒杀活动、周年庆、定期特惠。

架构

  • Producer，Consumer，Broker三部分和Kafka一样，Kafka的Partition在这里叫ConsumerQueue
  • Tag

高级特性

  • 事务场景
  • 延迟发送
  • 延迟消息
  • 消费重试和死信队列

3.字节BMQ实践

BMQ

兼容Kafka协议，存算分离，云原生消息队列

BMQ介绍

架构：Producer - Consumer - Proxy - Broker - HDFS - Controller - Coordinator - Meta
运维：重启、替换、扩容、缩容相较于Kafka的需要数据复制，时间较长，BMQ可以直接对外服务，秒级完成

BMQ读写流程

  • Failover机制
  • 写入状态机

BMQ高级特性

  • 泳道消息
  • DataBus：简化消息队列客户端复杂度，解耦业务与Topic，缓解集群压力，提高吞吐
  • Mirror
  • Index：直接在BMQ中将数据结构化，配置索引DDL，异步构建索引后，通过Index Query服务读出数据
  • Parquet：直接在BMQ中将数据结构化，通过Parquet Engine，可以使用不同的方式构建Parquet文件

4.课后总结

  • 消息队列是重要组件
  • Kafka的大数据应用场景是后续发展的重要支撑
  • 字节的BMQ属于面向云原生时期的消息队列组件
  • 课后还需了解各个组件的具体使用方法

5.引用

字节内部课：消息队列原理与实战
稀土掘金-后端学习资料

avatar
文章
阅读
粉丝