刘皇叔说Java的博客

零拷贝（Zero-Copy）是一种高效的数据传输技术，它允许数据在不需要CPU参与拷贝的情况下，直接从存储设备传输到网络接口卡（NIC）。在传统的数据传输过程中，数据需要在用户空间和内核空间之间多次拷贝，而零拷贝技术可以显著减少这些不必要的拷贝操作。

一个分区的所有副本集合称为AR，即Kafka为主题分区分配的所有副本。

包含，做到开箱即用。

两者在性能上的差异通常不大，因为Spring Kafka底层仍然是使用原生客户端。Spring Kafka增加的主要是便利性抽象层，而不是处理逻辑。在大多数应用中，这种微小的性能差异可以忽略不计。在实际项目中，有时会组合使用两者 - 主要使用Spring Kafka的便利特性，但在需要特别定制的地方直接使用原生API。是在Spring环境中的高级封装，选择哪个取决于你的项目需求和技术栈。

例如：Topic有3个分区，消费者组有3个消费者，则每个消费者负责1个分区，实现完全并行。例如：一个Topic有10个分区，消费者组最多可以用10个消费者达到最大吞吐。，同时确保消息在组内消费者之间的合理分配。例如：订单消息同时被「库存系统」和「物流系统」两个消费者组消费。注意：不同分区之间的消息顺序无法保证。建议：分区数 ≥ 消费者数。Kafka消费者组的本质是。

Pulsar = Kafka + RabbitMQ + 云原生能力的融合体性能强、功能全、架构现代，是下一代消息平台的有力选择。

死信队列是用来接收那些无法被正常消费的消息。当消息因某些原因被拒绝、过期或投递失败，它将被发送到对应的死信队列，便于后续排查或补偿。

JMS（Java Message Service）即 Java 消息服务应用程序接口，是一个 Java 平台中关于面向消息中间件（MOM）的 API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。Java 消息服务是一个与具体平台无关的 API，绝大多数 MOM 提供商都对JMS 提供支持。简短来说，JMS 是一种与厂商无关的 API，是 sun 公司为了统一厂商的接口规范，而定义出的一组api接口，用来访问消息收发系统消息。

前端可以使用 MQTT.js 库，通过 WebSocket 连接到 ActiveMQ 服务器并接收消息。生产者将消息发布到 MQTT 主题，前端通过 MQTT over WebSocket 连接到 ActiveMQ 并订阅相应的主题，以接收并显示消息。生产者将消息发送到 ActiveMQ 队列，消费者从队列中接收消息并通过 WebSocket 将消息传递给前端，前端通过 WebSocket 接收并显示消息。ActiveMQ 也支持 MQTT 协议，可以使用 MQTT 协议将数据推送到前端。

1.1事务机制：发送消息前，开启事务（channel.txSelect()）,然后发送消息，如果发送过程中出现什么异常，事务就会回滚（channel.txRollback()）,如果发送成功则提交事务（channel.txCommit()）。需要注意的是，事务机制会对性能产生一定的影响，因为它需要进行额外的操作来维护事务的一致性。使用事务机制时，可以在发送消息之前开启一个事务，在事务内发送消息并进行确认提交，以确保消息被正确地发送到 RabbitMQ 中。确认可以是单条消息的确认，也可以是批量消息的确认。

RabbitMQ是⼀个高可用的消息中间件，支持多种协议和集群扩展。并且支持消息持久化和镜像队列，适用于对消息可靠性较高的场合官网https://www.rabbitmq.com/getstarted.html。

RabbitMQ是实现AMQP（高级消息队列协议）的消息中间件的一种，最初起源于金融系统，用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，反之亦然.RabbitMQ本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。同时实现了一个经纪人(Broker)构架，这意味着消息在发送给客户端时先在中心队列排队。

在 RabbitMQ 中，可以通过消费者端限流（Consumer Prefetch）来控制消费端处理消息的速度，以避免消费端处理能力不足或处理过慢而导致消息堆积。消费者端限流的主要目的是控制消费者每次从 RabbitMQ 中获取的消息数量，从而实现消息处理的流量控制。RabbitMQ 提供了一种 QOS(服务质量保证)功能，即在非自动确认消息的前提下，如果一定数目的消息还未被消费确认，则不进行新消息的消费。RabbitMQ 为我们提供了三种机制● 对内存和磁盘使用量设置阈值。

单机没有高可用可言，高可用都对集群来说的集群部署：将消息队列系统部署为集群，包含多个节点（Broker），节点之间可以相互备份和负载均衡。通过集群部署，可以提高系统的容错能力和可扩展性，确保在单个节点故障时系统仍能正常运行。数据复制：消息队列系统通常支持消息数据的复制机制，可以将消息数据同步到多个节点上，以实现数据的冗余存储和故障恢复。通过数据复制，可以保证即使某个节点发生故障，消息数据依然可靠地保存在其他节点上。

MQ的消费模式可以大致分为两种，一种是推Push，一种是拉PullPush是服务端主动推送消息给客户端，Pull是客户端需要主动到服务端轮询获取数据。推优点是及时性较好，但如果客户端没有做好流控，一旦服务端推送大量消息到客户端时，就会导致客户端消息堆积甚至崩溃。拉优点是客户端可以依据自己的消费能力进行消费，但是频繁拉取会给服务端造成压力，并且可能会导致消息消费不及时。

生产者发送消息到指定的 Topic，消费者订阅 Topic 并以一定规则接收消息，Broker 负责将消息分发给相应的消费者实例，从而实现了消息的分发和消费。在这个示例中，我们创建一个消费者，订阅名为 test_topic 的 Topic，并设置消费模式为集群模式。在这个示例中，我们创建一个消费者，订阅名为 test_topic 的 Topic，并设置消费模式为广播模式。在 RocketMQ 中，可以通过设置消费者的消费模式来实现消息的分发。RocketMQ 提供了两种主要的消费模式：广播模式和集群模式。

1.产生背景： 生产者投递消息的速率与我们消费者消费的速率完全不匹配。2.生产者投递消息的速率>消费者消费的速率导致我们消息会堆积在我们 mq 服务器端中，没有及时的被消费者消费 所以就会产生消息堆积的问题3.注意的是：rabbitmq 消费者我们的消息消费如果成功的话 消息会被立即删除（自动ack）kafka 或者 rocketmq 消息消费如果成功的话，消息是不会立即被删除。4.解决办法：A.提高消费者消费的速率；（对我们的消费者实现集群）

解决思路：将需要保证先后顺序的消息放到同一个队列，只用一个消费者去消费该队列。即保证入队有序，出队后的顺序交给消费者自己保证大多数的项目是不需要保证 mq 消息顺序一致性的问题，只有在一些特定的场景可能会需要，比如 MySQL 与 Redis 实现异步同步数据；所有消息需要投递到同一个 mq 服务器，同一个分区模型中存放，最终被同一个消费者消费，核心原理：设定相同的消息 key，根据相同的消息 key 计算 hash 存放在同一个分区中。

阿里系下开源的一款分布式、队列模型的消息中间件，原名Metaq，3.0版本名称改为RocketMQ，是阿里参照kafka设计思想使用java实现的一套mq。同时将阿里系内部多款mq产品（Notify、metaq）进行整合，只维护核心功能，去除了所有其他运行时依赖，保证核心功能最简化，在此基础上配合阿里上述其他开源产品实现不同场景下mq的架构，目前主要多用于订单交易系统。RocketMQ 是一款分布式、队列模型的消息中间件，Apache Alibaba RocketMQ 是一个消息中间件。

文章目录概述RocketMQ架构Broker 高可用集群刷盘策略概述RocketMQ一个纯java、分布式、队列模型的开源消息中间件，前身是MetaQ，是阿里研发的一个队列模型的消息中间件，后开源给apache基金会成为了apache的顶级开源项目，具有高性能、高可靠、高实时、分布式特点。RocketMQ是阿里开源的分布式消息中间件，跟其它中间件相比，RocketMQ的特点是纯JAVA实现；集群和HA实现相对简单；在发生宕机和其它故障时消息丢失率更低。RocketMQ架构● Producer：

订单30分钟未支付自动取消怎么实现日常开发中，我们经常遇到这种业务场景，如：外卖订单超 30 分钟未支付，则自动取订单；用户注册成功 15 分钟后，发短信息通知用户等等。这就延时任务处理场景。在电商，支付等系统中，一设都是先创建订单（支付单）,再给用户一定的时间进行支付，如果没有按时支付的话，就需要把之前的订单（支付单）取消掉。这种类以的场景有很多，还有比如到期自动收货，超时自动退款，下单后自动发送短信等等都是类似的业务问题。

Apache RocketMQ在4.3.0版中已经支持分布式事务消息，采用了2PC（两阶段提交）+ 补偿机制（事务状态回查）的思想来实现了提交事务消息，同时增加一个补偿逻辑来处理二阶段超时或者失败的消息，如下图所示。总的来说，RocketMQ 事务消息在确保消息可靠传递的同时，也需要开发者按照一定的规范来设计和实现本地事务执行器，以及处理可能的回查请求，这些都是在使用 RocketMQ 事务消息时需要考虑和遵循的限制。事务消息的生产者 ID 不能与其他类型消息的生产者 ID 共享。

Apache Kafka 是分布式发布 - 订阅消息系统，在 kafka 官网上对 kafka 的定义：一个分布式发布 - 订阅消息传递系统。Kafka 最初由 LinkedIn 公司开发，Linkedin 于 2010 年贡献给了 Apache 基金会并成为顶级开源项目。Kafka 的主要应用场景有：日志收集系统和消息系统。

Apache Kafka 是分布式发布 - 订阅消息系统，在 kafka 官网上对 kafka 的定义：一个分布式发布 - 订阅消息传递系统。Kafka 最初由 LinkedIn 公司开发，Linkedin 于 2010 年贡献给了 Apache 基金会并成为顶级开源项目。Kafka 的主要应用场景有：日志收集系统和消息系统。

Kafka是分布式消息系统，需要处理海量的消息，Kafka的设计是把所有的消息都写入速度低容量大的硬盘，以此来换取更强的存储能力，但实际上，使用硬盘并没有带来过多的性能损失。如果要读写数据，必须找到数据对应的扇区，这个过程就叫寻址。页缓存：kaka将其数据存储在磁盘中，但在访问数据时，它会先将数据加载到操作系统的页缓存中，并在页缓存中保留一份副本，从而实现快速的数据访问。kak将其数据存储在磁盘中，但在访问数据时，它会先将数据加载到操作系统的页缓存中，并在页缓存中保留一份副本，从而实现快速的数据访问。

消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能，成为异步RPC的主要手段之一。当今市面上有很多主流的消息中间件，如老牌的ActiveMQ、RabbitMQ，炙手可热的Kafka，阿里巴巴自主开发RocketMQ等。

一般用在较为重要的业务队列中，确保未被正确消费的消息不被丢弃，一般发生消费异常可能原因主要有由于消息信息本身存在错误导致处理异常，处理过程中参数校验异常，或者因网络波动导致的查询异常等等，当发生异常时，当然不能每次通过日志来获取原消息，然后让运维帮忙重新投递消息。先把订单消息设置好 15 分钟过期时间，然后过期后队列将消息转发给我们设置好的 DLX-Exchange，DLX-Exchange 再将分发给它绑定的队列，我们的消费者再消费这个队列中的消息，就做到了延时十五分钟消费。

生产者保证不丢消息（消息重试,开启消息确认机制）存储端不丢消息（持久化存储、同步刷盘和异步刷盘）消费者不丢消息（消息确认机制手动ack等）集群部署（主从复制、镜像模式）持久化存储：消息队列通常会将消息持久化存储在硬盘上，以防止在消息传递过程中出现故障导致消息丢失。即使消息被接收后还未被处理，也能够在重启后重新发送。消息确认机制：消息队列支持消息确认机制，确保消息被正确地发送和接收。