走进消息队列

消息队列前世今生

在现代分布式系统中，消息队列（Message Queue，简称 MQ）已成为一种不可或缺的中间件，用于解耦系统组件、提高系统可靠性与扩展性。消息队列的出现和发展，与以下几个系统问题密切相关：

系统崩溃：

  • 在高并发系统中，直接处理请求可能导致系统崩溃。通过将请求先放入消息队列，系统可以避免瞬时过载，确保稳定运行，等待后端存储服务逐步处理这些请求。

服务处理能力有限：

  • 当系统的处理能力达到瓶颈时，前端请求会迅速堆积，造成系统崩溃。此时可以将请求放入消息队列，按需逐步消费，避免一瞬间的请求涌入导致服务过载。

链路耗时长尾：

  • 在一些分布式系统中，某些链路的处理时间可能会较长，导致长尾效应。通过异步方式将请求投递到消息队列中，避免长时间等待影响系统整体性能。

日志存储：

  • 在分布式系统中，日志的存储与分析是关键环节。将日志数据发送到消息队列后，后端日志分析平台可以异步获取数据，进行实时或定期分析。

什么是消息队列？

消息队列（MQ）是一个用于存储和传输消息的容器，其本质上是一个先进先出（FIFO）的队列。在分布式系统中，消息队列通常具有以下特点：

  • 高吞吐：能够处理大量的消息，确保高并发场景下的稳定性。
  • 高可用：消息队列需具备容错能力，保证数据不丢失。
  • 高并发：能够支持多个生产者和消费者并发工作。

系统中，消息生产者将消息发送到消息队列，消费者从队列中获取并处理消息。通过消息队列，可以实现系统的解耦和异步处理。

生产 ——> 消息队列 ——> 消费

业界消息队列：Kafka、RocketMQ、Pulsar、BMQ

消息队列 - Kafka

Kafka 是一个高吞吐量的分布式消息队列，广泛应用于 离线数据处理、日志收集、指标数据监控、用户行为追踪 等场景。

如何使用 Kafka

创建集群 ——> 新增 Topic ——> 编写生产者逻辑 ——> 编写消费者逻辑

​ 创建集群：部署 Kafka 集群并进行配置。

​ 新增 Topic：创建 Topic 作为消息的逻辑队列。

​ 编写生产者逻辑：将消息发送到 Kafka 集群中的指定 Topic。

​ 编写消费者逻辑：从 Kafka 中的 Topic 获取消息进行消费。

Kafka 架构

  • Producer：生产者，批量发送Batch、数据压缩，负责将消息发送到 Kafka 集群。生产者支持批量发送和消息压缩，提升吞吐量。
  • Broker：Kafka 的消息存储和转发节点。每个 Broker 存储一定数量的分区数据。顺序写、时间戳索引文件、零拷贝。
  • Consumer：消费者，负责从 Kafka 中消费消息。消费者可以是独立消费或分组消费（Consumer Group）。手动分配（Low Level）、自动分配（High Level）、Consumer Rebalance。

Topic 逻辑队列

Cluster 物理集群

Producer 生产者

Consumer 消费者

ConsumerGroup 消费者组

Kafka 核心组件

  • ZooKeeper：用于管理 Kafka 集群的元数据和节点信息。
  • Partition：Kafka 中的消息按分区存储，每个 Topic 可以有多个分区。
  • Consumer Group：消费者组，允许多个消费者协作消费同一 Topic 下的消息。

Kafka 工作原理

​ Leader 和 Follower

  • 每个 Partition 有一个 Leader 和多个 Follower，Leader 负责所有的读写操作，Follower 负责复制数据。

​ 消费者平衡（Consumer Rebalance）

  • 消费者组中的消费者通过自动或手动分配机制（Low Level / High Level）获取消息。

Kafka 的挑战与问题

​ 运维成本高：Kafka 集群的维护与管理需要较高的运维成本，尤其在集群扩容和负载均衡方面。

​ 负载不均衡：当某些分区数据量过大时，可能导致负载不均衡的问题，处理起来比较复杂。

​ 无缓存机制：Kafka 没有内建缓存机制，完全依赖操作系统的 Page Cache，可能会影响性能。

​ 多进程问题：Controller、Coordinator 和 Broker 在同一进程中，频繁的 IO 操作可能导致性能瓶颈。

消息队列 - BMQ

BMQ（字节跳动消息队列）

BMQ 是字节跳动内部开发的高性能、高可靠性的消息队列系统，旨在解决传统消息队列（如 Kafka）在高并发、大规模分布式环境下遇到的性能瓶颈和操作复杂性。BMQ 强调灵活的扩展能力、稳定性以及高效的数据流处理，支持多种高级特性来应对复杂的应用场景。

BMQ 的架构模式

BMQ 的架构设计旨在克服 Kafka 等传统消息队列系统中的一些问题：

  1. 高负载和不均衡：在 Kafka 中，负载均衡和消费者分配的管理较为复杂，且处理大量数据时容易造成节点压力过大。
  2. 性能瓶颈：Kafka 对于高吞吐量的数据写入和低延迟的处理场景有所欠缺，尤其在需要频繁更新或读取的场景下。
  3. 单点故障和高可用性：尽管 Kafka 支持分布式部署，但仍然面临因单个节点故障导致整个集群性能下降的风险。

BMQ 通过以下几个设计解决了这些问题：

  • 多机房部署：BMQ 支持跨多个数据中心和机房的部署，保证了高可用性和灾难恢复。多个机房的数据同步和负载均衡可以确保即使某一机房出现故障，消息队列仍能正常工作。
  • Partition 状态机：BMQ 采用状态机来管理消息的生命周期，从消息的生成、传输、存储到消费等各个环节都通过状态机进行高效的控制和管理。这种设计能够有效避免 Kafka 中可能出现的消息丢失、重复消费等问题。
  • Proxy 层：BMQ 的 Proxy 层位于客户端和 Broker 之间，负责消息的路由、负载均衡和流控。通过 Proxy，BMQ 可以动态地调整消息的路由规则和策略，进一步提升系统的可扩展性和容错能力。

BMQ 读写流程

BMQ 的读写流程基于 Failover 机制 和 写入状态机，确保在高并发和复杂的分布式环境下，消息可以高效、可靠地流转。

  1. 写入流程：
    • Failover 机制：BMQ 采用容错机制，保证在 Broker 节点故障时，消息能够自动路由到其他可用节点，避免消息丢失。
    • 写入状态机：每个消息在写入时都会经过状态机的管理，确保消息在存储过程中状态的正确转换。比如，消息在入队时的 “待处理” 状态，处理后进入 “已消费” 状态，避免消息丢失或重复消费。
  2. 消费流程：
    • 消费者通过订阅消息队列，按照队列的负载均衡规则，从多个队列分区中拉取消息。BMQ 的消费策略既支持单个消费者消费整个队列，也支持消费者组（Consumer Group）进行负载均衡消费。
  3. 消息的可靠性保障：
    • 消息的可靠性不仅体现在消息写入和消费过程中的状态机控制，也通过 数据镜像（Mirror） 来确保数据在多个数据中心的同步备份。BMQ 可以对消息进行多副本存储，确保数据的高可用性。

BMQ 的高级特性

BMQ 提供了一些特殊的功能和特性来满足复杂业务场景中的需求：

  1. 主干与泳道（Lane）消息：
    • 主干消息：主要负责关键业务流的高效传输，通常处理较高优先级的消息。主干消息的处理链路通常具有较低的延迟。
    • 泳道消息：用于低优先级或大批量的消息流。这些消息在主干消息流中会有独立的处理链路，并且可以异步处理。泳道设计支持消息的隔离和优先级调度。
  2. Databus（数据总线）：
    • Databus 是 BMQ 中的一种数据同步和传递机制，允许多个服务间同步传递和共享实时数据。Databus 可以帮助解决跨服务的数据传递问题，特别是在微服务架构中，Databus 提供了一种高效且低延迟的数据流传输方式。
  3. Mirror（镜像机制）：
    • 镜像机制 用于跨机房或跨数据中心的数据备份。通过将消息数据同步到不同的节点或机房，BMQ 提供了灾备功能，确保系统在某个节点故障时仍能保持服务的持续可用性。
  4. Index（索引）：
    • BMQ 支持对消息内容进行索引，可以快速定位到特定的消息。这个索引功能对于一些高并发的查询和检索操作非常有用，尤其是在日志处理或审计系统中。
  5. Parquet（列式存储格式）：
    • Parquet 是一种列式存储格式，BMQ 支持将消息存储为 Parquet 格式，这种存储方式非常适合于大规模数据分析场景。通过列式存储，BMQ 可以更加高效地存储和处理大量的日志或监控数据。

BMQ 的开发流程

BMQ 的开发和部署流程通常包括以下几个步骤：

  1. 开发阶段：
    • 开发人员编写消息生产者和消费者的逻辑，使用 BMQ 提供的 SDK 或 API 接口来实现消息的生产与消费。
  2. BOE（线下测试环境）：
    • 开发完成后，将应用部署到 BOE（测试环境）进行基础功能的验证和性能测试。此阶段主要验证消息队列的基本功能是否正常，如消息的生产、消费、消息顺序等。
  3. PPE（验证环境）：
    • 将应用部署到 PPE 环境，进行更为全面的集成测试。此阶段除了验证基础功能外，还包括高并发、大数据量场景下的性能测试，确保系统在负载下能够稳定运行。
  4. Prod（生产环境）：
    • 最终，经过验证的应用会部署到生产环境，供实际业务使用。生产环境中的消息队列需要确保高可用性、容错性和性能，BMQ 在这一阶段通过多机房部署和数据镜像来保证稳定性。

小结

1、BMQ的架构模式（解决 Kafka 存在的问题）

2、BMQ读写流程（Failover 机制，写入状态机）

3、BMQ高级特性（泳道、Databus、Mirror、Index、Parquet）

消息队列 - RocketMQ

使用场景：低延时（电商、订单、库存、物流、秒杀）

RocketMQ 是阿里巴巴开源的一款消息队列系统，特别适用于 低延时 的场景，如 电商订单、库存管理、物流调度 和 秒杀系统 等。

RocketMQ 基本概念

  • Queue：消息队列，RocketMQ 中每个消息都是存储在一个队列中的。
  • Tag：消息标签，用于对消息进行分类和过滤。

RocketMQ 底层原理

RocketMQ 采用分布式架构，通过高效的存储模型和传输协议保证低延迟和高吞吐。其底层存储模型支持顺序写入、消息压缩和零拷贝技术。

RocketMQ 高级特性

  1. 事务消息：支持事务消息的发送与回滚，用于保证消息的可靠性。
  2. 延迟发送和延迟消息：允许设置消息的延迟时间，适用于定时任务等场景。
  3. 消费失败和重试：支持消费失败的消息重试机制，保证消息不丢失。
  4. 死信队列：当消息无法正常消费时，消息会被投递到死信队列，用于后续的处理和监控。

小结

  1. BMQ 架构模式：通过多机房部署、泳道消息等方式，BMQ 提升了 Kafka 在高并发、高负载场景下的性能。
  2. BMQ 读写流程：采用 Failover 机制和写入状态机，保证消息在分布式环境中的可靠传输。
  3. RocketMQ 高级特性：支持事务消息、延迟消息、消费重试等功能，非常适合低延迟、高可靠性的场景。