消息队列
消息队列是一种用于在分布式系统中进行异步通信的重要工具。它允许系统内的不同组件之间通过发送和接收消息进行通信。消息队列提供了解耦、异步和削峰三大队特性，使得系统更灵活、可扩展、可靠。
异步通信
异步通信是消息队列的一项重要特性。在同步通信中，请求方等待响应方的处理完成，而在异步通信中，请求方可以继续执行其他任务，而不必等待响应。使用场景：
电商订单支付
在电商系统中，用户完成订单支付后，系统可能需要进行一系列异步操作，例如发送订单确认邮件、更新库存、生成发货单等。通过使用消息队列，订单支付服务可以将支付成功的消息发送到消息队列中，而其他服务（如邮件服务、库存服务、发货服务）可以异步地监听消息队列，处理相应的业务逻辑，实现系统的解耦和异步处理。
削峰
削峰是指在系统面临突发流量时，通过消息队列缓冲和控制流量，防止系统崩溃。消息队列可以充当缓冲区，暂时保存流入系统的请求，使系统能够按自身处理能力逐渐消化这些请求。使用场景：
秒杀活动
在秒杀活动中，瞬时可能涌入大量用户请求。通过使用消息队列，可以将用户的秒杀请求先放入队列中，然后按照系统的处理能力逐步消费，防止瞬时的大量请求直接冲击到后端服务，导致系统崩溃。
解耦
解耦是指系统中的各个模块之间减少直接的依赖关系。通过消息队列，模块之间不直接调用对方的接口，而是通过消息进行通信，从而降低模块之间的耦合度。使用场景：
日志处理
在一个大型分布式系统中，各个服务生成的日志可能需要被集中处理，例如存储到统一的日志存储系统中。通过使用消息队列，每个服务可以将自己的日志异步地发送到消息队列中，而日志处理服务则监听消息队列，将日志进行集中处理。这种方式降低了各个服务对日志处理服务的直接依赖，实现了解耦。
比较常用的消息队列有ActiveMQ、RabbitMQ、RocketMQ、Kafka等，本文主要讲的是
RabbitMQ和Kafka
RabbitMQ
RabbitMQ 是一个开源的消息中间件，实现了高级消息队列协议（AMQP）。它设计用于支持分布式系统之间的消息传递、解耦和异步通信。
核心概念
- Producer（生产者）： 发送消息的应用程序。
- Consumer（消费者）： 接收和处理消息的应用程序。
- Message（消息）： 传递给 RabbitMQ 的数据单元。
核心特性
- 支持多种消息传递模式： RabbitMQ 提供了不同的消息传递模式，包括点对点、发布、订阅、路由、主题等，以满足各种消息通信需求。
- 可靠性： RabbitMQ 提供了消息的持久化、投递确认和事务等机制，确保消息的可靠性传递。
- 灵活的消息路由： RabbitMQ 支持灵活的消息路由机制，通过交换机（Exchange）和队列（Queue）的绑定，可以将消息路由到指定的消费者。
- 消息队列持久化： RabbitMQ 允许将队列和消息进行持久化，确保在服务器重启后消息不丢失。
工作原理
- Producer 发送消息到 Exchange（交换机）： 生产者将消息发送到 Exchange，Exchange 根据消息的路由规则将消息发送到一个或多个队列。
- Exchange 将消息路由到 Queue： Exchange 根据预定的路由规则将消息路由到与之绑定的队列。
- Consumer 从队列中接收消息： 消费者从队列中接收消息，并进行处理。
- 消息确认机制： 消费者接收到消息后，可以通过消息确认机制告知 RabbitMQ 是否成功处理消息。
个人比较常用的路由机制是
Direct和topic
Direct 交换机
- 特点： Direct 交换机是最简单的交换机类型之一。它将消息路由到与消息的路由键（Routing Key）完全匹配的队列中。
- 用途： Direct 交换机适用于一对一的消息路由，当生产者发送消息时，可以通过指定一个具体的路由键，确保消息只会被路由到与该路由键完全匹配的队列中。
- 示例场景： 在一个日志系统中，可以使用 Direct 交换机将不同级别的日志消息（如"info"、“warning”、“error”）分别路由到对应级别的队列中。
Topic 交换机
-
特点： Topic 交换机允许更复杂的消息路由。它根据通配符匹配规则将消息路由到一个或多个队列。
-
通配符规则：
*（星号）：匹配一个单词。#（井号）：匹配零个或多个单词。
-
示例场景： 在一个新闻系统中，可以使用 Topic 交换机将不同类型的新闻消息路由到不同的队列中，例如，使用路由键"news.sports"匹配所有与体育相关的新闻。
Kafka
Kafka是一个开源的流处理平台和消息系统，设计目标是构建一个分布式、持久性、高吞吐量的发布/订阅系统，适用于处理实时数据流和大规模数据集。
核心概念
- Topic（主题）： 数据发布和订阅的类别，Kafka 中的消息被发布到特定的主题中。
- Producer（生产者）： 负责将消息发布到 Kafka 的 Topic 中。
- Consumer（消费者）： 订阅 Topic 并处理生产者发布的消息。
- Broker（代理）： Kafka 集群中的每个服务器节点都被称为 Broker，负责存储和处理消息。
- Partition（分区）： 每个 Topic 可以分为多个分区，分区是 Kafka 实现高吞吐量的关键。
- Offset（偏移量）： 为每个消息分配的唯一标识，用于跟踪消费者的读取位置。
主要特性
- 高吞吐量： Kafka 是为高吞吐量设计的，能够处理大量数据的读写。
- 持久性： Kafka 将消息持久化到磁盘，确保消息在发布后不会丢失。
- 水平扩展性： Kafka 允许在集群中添加新的 Broker，并能够水平扩展以满足不断增长的负载。
- 容错性： Kafka 具有分布式特性，提供多个副本和分区，以保证系统的容错性。
工作流程
- Producer 发送消息： 生产者将消息发送到指定的 Topic。
- Broker 存储消息： Broker 将消息存储到 Topic 的一个或多个分区中。
- Consumer 订阅消息： 消费者订阅 Topic，并从指定的分区读取消息。
- 消息持久化： 消息被持久化到磁盘，以保证消息的可靠性。
- 水平扩展： 可以在集群中添加新的 Broker 来实现水平扩展。
在 Kafka 中，Consumer Group（消费者组）的概念对消息的处理方式有着重要的影响。
同一用户组情况下：
- 消息分发： 如果多个消费者属于同一用户组（Consumer Group），那么它们会共同消费一个主题（Topic）中的消息，也就是如果topic有一个分区，里面有十个消息，且这个用户组在监听这个分区，则该用户组内所有consumer都会消费这十个消息。（默认情况下监听0分区）
- 分区分配： Kafka 会将主题中的分区（Partitions）均匀地分配给 Consumer Group 中的各个消费者。每个分区只能被一个消费者组内的一个消费者消费。
- 负载均衡： 当有新的消费者加入或旧的消费者离开用户组时，Kafka 会自动进行重新平衡，确保每个分区被消费者组内的一个消费者消费。这样做的目的是实现负载均衡，使每个消费者都能处理大致相同数量的消息。
- 并行处理： 处于同一用户组的多个消费者可以并行地处理消息，提高整体的消费能力。
不同用户组情况下：
- 相互独立： 不同用户组的消费者相互独立。每个用户组内的消费者共同消费消息，但不同用户组之间的消费者不共享分区。
- 全量消费： 处于不同用户组的消费者，即使主题相同，也会独立消费所有分区的消息。
- 不受影响： 一个用户组内的消费者的消费进度不会影响到其他用户组内的消费者。每个用户组内的消费者都有自己的偏移量（Offset），独立进行消息的消费。
- 适用场景： 不同用户组通常用于实现不同的业务逻辑或应用场景。它们之间不会相互干扰，因此适用于并行处理不同任务的场景。
选择
RabbitMQ 和 Kafka 都是消息中间件，但它们在设计和适用场景上有一些不同。
- 如果你的应用场景更注重消息传递、消息可靠性和实时性，以及需要更灵活的消息路由，那么 RabbitMQ 可能是更好的选择。
- 如果你的应用场景更侧重于大规模数据处理、高吞吐量、持久性存储、日志处理和流式处理，那么 Kafka 可能更适合。
RabbitMQ 的适用场景：
- 消息传递： RabbitMQ 是一个经典的消息传递系统，适用于点对点和发布/订阅模式。它支持多种消息传递模式，包括直接交换机、主题交换机和扇出交换机等。
- 实时性要求较高的场景： RabbitMQ 提供了低延迟的消息传递，适用于对实时性要求较高的系统。
- 可靠性消息传递： RabbitMQ 支持消息的可靠性传递，通过确认机制（acknowledgments）确保消息可靠性投递，适用于需要确保消息不丢失的场景。
- 灵活的消息路由： RabbitMQ 具有灵活的消息路由和消息过滤功能，可以根据不同的业务需求进行定制。
Kafka 的适用场景：
- 高吞吐量： Kafka 被设计为高吞吐量、低延迟的分布式消息系统，适用于大量数据的高效传输。
- 日志和事件处理： Kafka 是一个分布式日志系统，适用于日志聚合、事件溯源和大数据处理。
- 发布/订阅模式： Kafka 支持发布/订阅模式，适用于多个消费者对相同主题的订阅。
- 持久性存储： Kafka 将消息持久化到磁盘，适用于需要长期存储和回溯的场景。
- 流式处理： Kafka 具有流处理能力，适用于流式处理任务，如实时分析、流式 ETL 等。
4362
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
