RocketMQ如何保证消息的可靠性传递❓

RocketMQ 通过一系列的机制来保证消息的可靠性传递，确保在面对各种异常和故障情况时，消息系统能够稳定地处理和传递消息。以下是 RocketMQ 保证可靠性传递的关键机制：

1. 同步双写机制 (Synchronous Write Mechanism):

RocketMQ的同步双写机制通过操作系统的页缓存、同步刷盘和CommitLog的持久化操作，为消息的可靠性传递提供了坚实的基础。在生产环境中，根据实际需求可以适度调整相关配置，以平衡性能和可靠性。

1.1 同步双写机制工作流程：

  1. 消息生产：当生产者发送消息到RocketMQ时，消息首先被写入操作系统的页缓存。
  2. 同步刷盘（Sync Flush）：RocketMQ会在消息写入页缓存后进行同步刷盘操作。这意味着将消息从页缓存刷写到磁盘的存储介质，确保消息已经被持久化。
  3. CommitLog持久化：一旦消息成功同步刷盘，RocketMQ将消息写入 CommitLog。CommitLog是消息的物理存储，包含了所有已发送的消息。
  4. 返回成功响应：一旦消息被成功写入CommitLog，生产者收到成功响应，可以认为消息已经被成功持久化。

1.2 同步双写机制流程：

  • 消息发送：
    • 生产者将消息发送到 RocketMQ 主节点。
  • 主节点写入消息存储文件（Master CommitLog）：
    • 主节点负责将消息写入自身的 CommitLog 文件，保证消息在主节点的存储文件中持久化。
  • 主节点同步消息到从节点：
    • 主节点将刚刚写入的消息同步到所有配置的从节点。
    • 同步可以采用不同的方式，如同步、异步或半同步，这取决于 RocketMQ 的配置。
  • 从节点写入消息存储文件（Slave CommitLog）：
    • 从节点接收到主节点的同步消息后，将消息写入自身的 CommitLog 文件。
  • 从节点确认消息同步完成：
    • 从节点向主节点发送确认消息已成功同步的信号。
    • 主节点收到所有从节点的确认后，认为消息在从节点的同步操作已经完成。
  • 消息标记为可投递：
    • 一旦消息在主节点和所有从节点的 CommitLog 文件中都成功写入，消息被标记为可投递状态。
    • 这意味着消息已经在多个节点上得到了持久化。
  • 消息可供消费者消费：
    • 消费者可以消费已被确认写入的消息，保证消息在多节点之间的同步。
1.2.2 流程图：

1.2 关键概念：

  1. 页缓存（Page Cache）：操作系统中用于存储文件系统缓存的内存区域。RocketMQ通过将消息首先写入页缓存，实现了消息在内存中的持久化。
  2. 同步刷盘（Sync Flush）：是指将内存中的数据同步刷写到磁盘。RocketMQ确保消息在被发送后，首先在内存中得到持久化，然后再刷写到磁盘，从而防止数据的丢失。
  3. CommitLog：是RocketMQ中消息的物理存储结构，包含了所有已发送的消息。CommitLog的持久化保证了即使在异常情况下，如Broker宕机，消息也能够被恢复。

1.3 为什么使用同步双写机制？

  1. 提高持久化可靠性：同步双写机制确保了消息在写入磁盘之前已经在内存中得到持久化，从而提高了消息的可靠性。
  2. 防止数据丢失：在异常情况下，如机器宕机，通过同步刷盘机制可以避免数据在写入磁盘之前丢失。
  3. 加速消息的发送速度：同步双写机制实际上将消息发送和持久化的操作异步化，提高了消息发送的吞吐量。

1.4 配置同步双写机制：

在RocketMQ的配置文件中，可以通过配置 isolateDiskReadAndWrite 参数为 true 来启用同步双写机制。该配置项在broker.conf中配置：

# broker配置文件中启用同步双写机制的配置
isolateDiskReadAndWrite=true

这样的配置将确保消息的同步刷盘机制被启用，提高了消息持久化的可靠性。

2. 主从复制机制 (Master-Slave Replication):

RocketMQ采用主从复制机制来提高系统的可用性。每个Broker都有一个主Broker和若干个从Broker。主Broker负责消息的读写，而从Broker用于备份和容灾。如果主Broker发生故障，RocketMQ能够迅速切换到从Broker以提供服务，确保消息的持久化和传递。

2.1 主从复制的工作原理：

  1. 角色定义： 在 RocketMQ 的 Broker 集群中，每个 Broker 都有主 Broker 和若干个从 Broker。主 Broker 负责消息的读写，而从 Broker 用于备份和容灾。
  2. 主节点写入消息： 当生产者发送消息时，消息首先被写入主节点的 CommitLog 中。
  3. 同步复制到从节点： 主节点将写入的消息同步复制到所有从节点。这确保了从节点具有与主节点相同的消息副本。
  4. 从节点备份： 从节点保存了主节点的消息备份，以备主节点宕机或发生故障时使用。
  5. 切换到从节点： 当主节点发生故障或宕机时，RocketMQ 能够快速切换到某个从节点，并确保消息服务的持续性。切换后，从节点成为新的主节点。

2.2 主从复制的配置：

在 RocketMQ 的配置文件中，可以通过配置 brokerRole 参数来指定 Broker 的角色，即是主节点还是从节点。以下是一个简化的配置示例：

# broker配置文件中的master配置
brokerClusterName=MyBrokerCluster
brokerName=broker-a
brokerId=0
listenPort=10911
namesrvAddr=localhost:9876
brokerRole=ASYNC_MASTER
# broker配置文件中的slave配置
brokerClusterName=MyBrokerCluster
brokerName=broker-a
brokerId=1
listenPort=10912
namesrvAddr=localhost:9876
brokerRole=SLAVE

在这个配置中，brokerRole 参数指定了 Broker 的角色，主节点使用 ASYNC_MASTER，从节点使用 SLAVE。

2.3 关键概念：

  • 主 Broker（Master Broker）： 负责消息的读写和写入 CommitLog。
  • 从 Broker（Slave Broker）： 用于备份主 Broker 的消息，确保在主 Broker 故障时可以顺利切换。
  • 同步复制： 主节点将消息同步复制到所有从节点，确保从节点具有相同的消息副本。
  • 切换（Failover）： 在主节点发生故障时，从节点可以快速切换为新的主节点，确保消息服务的持续性。

2.4 为什么使用主从复制机制？

  1. 提高可用性： 主从复制机制提高了系统的可用性，即使主节点发生故障，从节点可以迅速切换为主节点，保障消息服务的持续性。
  2. 容灾备份： 从节点充当主节点的备份，确保在主节点宕机或发生故障时，仍能够提供服务。
  3. 负载均衡： 主从复制机制支持在多个节点之间分摊消息读写的负载，提高系统的整体性能。

2.5 配置主从复制机制：

在配置文件中通过设置 brokerRole 参数，可以指定 Broker 的角色。主节点使用 ASYNC_MASTER，从节点使用 SLAVE。通过合理配置主从节点的数量和位置，可以优化系统的性能和可靠性。

3. 消息拉取和消费确认机制 (Message Pull and Consumer Acknowledgment):

消费者在拉取消息时，RocketMQ记录每条消息的消费状态。消费者在处理完消息后，会向Broker提交消息的消费确认。Broker将这些消费确认的信息持久化到CommitLog中。这确保了消息在被成功消费后会被正确地持久化，而且在消费者或者Broker出现问题时，能够根据这些记录进行恢复。

3.1 消息拉取机制：

在 RocketMQ 中，消费者通过拉取（Pull）的方式获取消息。这种机制相对于推送（Push）的方式更为灵活，允许消费者按照自己的速度主动拉取消息。消息拉取的流程如下：

  1. 消费者向 Broker 发起拉取消息的请求。
  2. Broker 返回一批消息给消费者。
  3. 消费者处理拉取到的消息。

3.2 消费确认机制：

在 RocketMQ 中，消费者在成功消费一条消息后，需要向 Broker 发送消费确认。这个机制确保了消息被成功消费，并避免消息在消费者宕机或发生其他故障时被重复消费。消费确认的流程如下：

  1. 消费者成功处理一条消息后，向 Broker 发送消费确认。
  2. Broker 接收到消费确认后，将消息的消费状态记录在 CommitLog 中。
  3. 消费者定期向 Broker 发送消费进度，以便 Broker 知晓消费的最新状态。

3.3 消费确认的两种模式：

RocketMQ 提供了两种消费确认模式：

  1. 自动确认（Auto Acknowledge）： 消费者在成功消费消息后，会自动向 Broker 发送消费确认，无需手动处理。适用于那些不需要精确控制消费确认的场景。
  2. 手动确认（Manual Acknowledge）： 消费者需要手动调用确认接口，显式地告知 Broker 消息已经被成功消费。这种模式更为灵活，适用于需要精确控制消费确认的场景，例如在事务消息中。

3.4 防止消息重复消费：

RocketMQ 通过消费确认机制防止消息重复消费。即使在消息推送和拉取的情况下，一旦消息被成功消费，消费者向 Broker 发送确认后，Broker 将记录消息的消费状态，防止消息被重复消费。

3.5 代码示例（Java）：

// RocketMQ消费者示例代码
DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("example_group");
consumer.setNamesrvAddr("localhost:9876");
consumer.subscribe("example_topic", "*");consumer.registerMessageListener((List<MessageExt> messages, ConsumeConcurrentlyContext context) -> {for (MessageExt message : messages) {// 处理消息的业务逻辑// 手动确认消息已经被消费consumer.acknowledge(message.getMsgId());}return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
});consumer.start();
System.out.println("Consumer Started.");

在这个示例中，消费者注册了消息监听器，对拉取到的消息进行处理，并使用 consumer.acknowledge() 手动确认消息的消费。这种手动确认的方式可以确保消息在被成功处理后才发送确认，防止消息重复消费。

3.6 消息拉取和消费确认机制流程：

3.6.1 流程说明：

1）消费者订阅主题和标签：

消费者通过调用 subscribe 方法订阅对应的主题和标签。

调用的组件：DefaultMQPushConsumer（消费者实例）

源码示例：

DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("consumer_group");
consumer.setNamesrvAddr("localhost:9876");
consumer.subscribe("topic", "tag");

2）拉取消息：

消费者通过调用 poll 或者注册消息监听器，并启动消息消费线程。

消费者主动向 RocketMQ 服务器发起拉取消息的请求。

调用的组件：MQClientAPIImpl（RocketMQ 客户端 API 实现）

源码示例：

PullResult pullResult = pullMessageSync(queue, subExpression, expressionType,nextOffset, pullBatchSize, sysFlag, commitOffset, brokerAddr);

3）服务器返回消息：

RocketMQ 服务器收到拉取消息请求后，从消息队列中获取消息，并将消息返回给消费者。

调用的组件：MessageQueue（消息队列）

源码示例：

MessageExt msg = queueMessageList.get(i);

4）消费者处理消息：

消费者收到消息后，执行消息的业务处理逻辑。

消费者可以在业务逻辑中判断消息是否处理成功。

5）确认消息消费：

如果消息处理成功，消费者调用 acknowledge 方法确认消息已被成功消费。

如果消息处理失败，消费者可以选择不确认消息，以触发消息的重新投递。

调用的组件：ConsumeMessageService（消息消费服务）

源码示例：

this.consumeMessageService.submitConsumeRequest(msgs,processQueue,messageQueue,dispathToConsume);

6）服务器更新消费进度：

消费者确认消息后，RocketMQ 服务器更新消费者的消费进度。

消费进度用于记录消费者在消息队列中的消费位置，以便下次拉取消息时从正确的位置开始。

调用的组件：ConsumerOffsetManager（消费者位移管理器）

源码示例：

this.consumerOffsetManager.commitOffset(consumerGroup,clientid,messageQueue,offset);

7）消费者定时发送心跳：

消费者定时向 RocketMQ 服务器发送心跳，以保持与服务器的连接。

调用的组件：HeartbeatProducer（心跳生产者）

源码示例：

this.heartbeatProducer.sendHeartbeatToAllBrokerWithLock();

8）消息拉取轮询：

消费者定期发起消息拉取请求，获取新的消息。

消费者拉取的频率可以根据业务需求和性能调优进行配置。

调用的组件：DefaultMQPushConsumerImpl（消费者实现）

源码示例：

this.mQClientAPIImpl.pullMessage(brokerAddr,requestHeader,timeoutMillis,communicationMode,pullCallback);

9）重复以上流程：

消费者将不断重复以上流程，持续从 RocketMQ 服务器拉取消息并进行消费。

整个流程是在 DefaultMQPushConsumer 内部进行的，包含了对 MQClientAPIImpl、ConsumeMessageService、ConsumerOffsetManager 等多个组件的调用

3.7 为什么使用消息拉取和消费确认机制？

  1. 灵活性： 消息拉取机制使得消费者可以按照自己的速度主动拉取消息，适用于不同业务场景的需求。
  2. 可靠性： 消费确认机制确保了消息被成功消费后才进行确认，防止消息在异常情况下被重复消费。
  3. 控制权： 消费者可以通过手动确认的方式更加灵活地控制消息的消费进度，适用于需要更细粒度控制的场景。

4. 消息的重新投递机制 (Message Redelivery Mechanism):

RocketMQ支持消息的重新投递机制。当消息发送失败或者消费失败时，RocketMQ会根据预设的重试策略将消息重新投递给消费者。这包括了设置最大重试次数和重试间隔时间，以确保消息在遇到短暂故障后能够尽快被重新处理。

4.1 工作原理：

  1. 消息发送失败： 当消息发送到 Broker 时，如果发生发送失败，RocketMQ 将对该消息进行重新投递。
  2. 消息消费失败： 当消费者处理消息时发生失败，消费者可以选择将消息标记为重新投递。这通常发生在消息处理的业务逻辑出现异常或者无法处理当前消息的情况下。
  3. 重试次数控制： RocketMQ 允许设置消息的最大重试次数，即消息最多被重新投递的次数。超过重试次数后，消息将被标记为死信消息，不再重新投递。
  4. 重试间隔控制： 为了避免短时间内频繁地重试，RocketMQ 支持设置消息的重试间隔时间。在每次重新投递时，消息将等待一定的时间再次被尝试。

4.2 代码示例（Java）：

生产者端：
DefaultMQProducer producer = new DefaultMQProducer("example_group");
producer.setNamesrvAddr("localhost:9876");
producer.start();Message message = new Message("example_topic", "TagA", "Hello, RocketMQ".getBytes());// 发送消息，并指定最大重试次数和重试间隔时间
SendResult sendResult = producer.send(message, (m, ex, retryTimes) -> {if (retryTimes < 2) { // 最多重试两次// 返回重新投递的策略return ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT;} else {// 不再重试，消息将被标记为死信消息return ConsumeOrderlyStatus.SUCCESS;}
}, 3, 3000);System.out.println("Message ID: " + sendResult.getMsgId());producer.shutdown();
消费者端：
DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("example_group");
consumer.setNamesrvAddr("localhost:9876");
consumer.subscribe("example_topic", "*");consumer.registerMessageListener((List<MessageExt> messages, ConsumeConcurrentlyContext context) -> {for (MessageExt message : messages) {try {// 处理消息的业务逻辑// 如果处理失败，可以选择重新投递消息if (someBusinessLogic(message)) {return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;} else {// 返回重新投递的策略，RocketMQ 将根据配置进行重试return ConsumeConcurrentlyStatus.RECONSUME_LATER;}} catch (Exception e) {// 异常情况也可以选择重新投递return ConsumeConcurrentlyStatus.RECONSUME_LATER;}}return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
});consumer.start();
System.out.println("Consumer Started.");

在这个示例中，生产者通过 producer.send() 方法发送消息，并通过 SendCallback 设置了消息发送失败后的处理逻辑。消费者在 MessageListener 中处理消息的业务逻辑，并根据处理结果返回不同的消费状态，以决定是否重新投递消息。

4.3 为什么使用消息的重新投递机制？

  1. 处理瞬时故障： 在分布式系统中，瞬时故障是难以避免的。可能由于网络抖动、服务暂时不可用等原因导致消息发送失败或者消费失败。重新投递机制能够帮助系统在这些短暂的故障发生后，通过重新尝试来最终成功地将消息发送或者处理。
  2. 提高消息处理成功率： 在一些场景下，消息的处理可能涉及到复杂的业务逻辑、依赖外部服务，或者受到临时资源限制等。第一次处理时可能由于各种原因失败，但通过重新投递机制，系统有机会在稍后重新尝试，从而提高消息的最终成功率。
  3. 应对消费端问题： 消费端可能由于程序bug、处理逻辑错误或者依赖服务故障等原因导致消息处理失败。通过重新投递，系统有机会在修复问题后重新处理这些消息。
  4. 系统的自愈能力： 重新投递机制使得系统在遇到短期故障或处理失败的情况下，能够自动尝试修复问题，降低了对人工干预的依赖，提高了系统的自愈能力。
  5. 降低手动处理成本： 对于某些失败的消息，人工介入可能是昂贵的，尤其在大规模系统中。通过自动的重新投递机制，系统能够更加高效地处理这些失败的消息，降低了手动处理的成本。
  6. 避免消息丢失： 在一些异常情况下，如网络分区、服务器故障等，消息可能在发送或者消费的过程中丢失。通过重新投递机制，系统有机会在这些异常恢复后重新处理消息，避免消息的永久丢失。

5. 事务消息机制 (Transactional Message Mechanism):

RocketMQ提供了事务消息的支持，用于处理分布式事务。在事务消息中，生产者发送半消息（half message），然后等待事务的执行结果。最终，根据事务的结果，生产者提交或回滚这条消息。这个机制保证了在分布式事务场景中消息的一致性。

5.1 工作原理：

  1. 事务消息发送： 事务消息发送分为两个阶段。首先，生产者发送半消息（Half Message），该消息处于预提交状态，但尚未提交到 CommitLog 中。
  2. 本地事务执行： 生产者在发送半消息后，会执行本地事务。本地事务可能成功、失败或者状态不确定。
  3. 事务消息状态回查： RocketMQ 定期进行事务消息的状态回查。对于处于预提交状态的半消息，RocketMQ 会向生产者发送回查请求。
  4. 生产者处理回查请求： 生产者收到回查请求后，需要根据本地事务的执行结果来确定如何处理该消息。如果本地事务成功，则提交该消息；如果本地事务失败，则回滚该消息。
  5. 消息提交或回滚： 在回查后，生产者根据本地事务的执行结果提交或回滚事务消息。如果提交，消息变为可投递状态；如果回滚，消息将被删除。
  6. 消息可投递： 一旦事务消息提交，RocketMQ 将允许该消息被消费者消费。

5.2 事务消息机制流程：

5.2.1 流程描述：
  1. 半消息发送： 生产者发送半消息（Half Message）到 RocketMQ 服务器。
  2. 消息状态为 Prepared： 半消息的状态被设置为 "Prepared"，表示消息处于预提交状态。
  3. 本地事务执行： 生产者执行本地事务逻辑，可能是数据库操作、文件写入等。
  4. 事务消息状态回查： RocketMQ 定期进行事务消息的状态回查，向生产者询问半消息的本地事务执行结果。
  5. 生产者处理回查请求： 生产者根据本地事务的执行结果，可能是提交、回滚或保持不变，返回相应的事务状态。
  6. 消息提交或回滚： 如果本地事务成功，生产者将消息状态设置为 "Commit"，表示提交；如果本地事务失败，生产者将消息状态设置为 "Rollback"，表示回滚。
  7. 消息可投递或删除： 如果消息状态为 "Commit"，RocketMQ 允许该消息被消费者消费；如果消息状态为 "Rollback"，该消息将被删除。

5.2.2 流程图：

5.3 代码示例（Java）：

事务消息生产者：
TransactionMQProducer producer = new TransactionMQProducer("transaction_producer_group");
producer.setNamesrvAddr("localhost:9876");// 设置事务监听器
producer.setTransactionListener(new TransactionListener() {@Overridepublic LocalTransactionState executeLocalTransaction(Message msg, Object arg) {// 执行本地事务逻辑，返回事务执行状态// 可能是 COMMIT_MESSAGE、ROLLBACK_MESSAGE、UNKNOW// 具体返回值要根据本地事务的执行结果来确定}@Overridepublic LocalTransactionState checkLocalTransaction(MessageExt msg) {// 回查本地事务状态，返回事务执行状态// 可能是 COMMIT_MESSAGE、ROLLBACK_MESSAGE、UNKNOW// 具体返回值要根据本地事务的执行结果来确定}
});producer.start();// 发送事务消息
Message message = new Message("transaction_topic", "TagA", "Hello, RocketMQ".getBytes());
SendResult sendResult = producer.sendMessageInTransaction(message, null);System.out.println("Transaction Send Result: " + sendResult.getSendStatus());producer.shutdown();
事务消息消费者：
DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("transaction_consumer_group");
consumer.setNamesrvAddr("localhost:9876");
consumer.subscribe("transaction_topic", "*");consumer.registerMessageListener((List<MessageExt> messages, ConsumeConcurrentlyContext context) -> {for (MessageExt message : messages) {// 处理事务消息的业务逻辑// 注意：由于事务消息的状态可能是 UNKNOW，所以需要确保消息的幂等性}return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
});consumer.start();
System.out.println("Transaction Consumer Started.");

5.4 为什么使用事务消息机制？

  1. 确保消息的一致性： 事务消息机制允许生产者和消费者参与到分布式事务中，确保消息在发送和消费的过程中的一致性。
  2. 处理本地事务： 生产者可以在发送半消息后执行本地事务。如果本地事务成功，生产者提交该消息；如果本地事务失败，生产者回滚该消息。
  3. 状态回查： RocketMQ 定期回查半消息的状态，以确保在网络分区、节点故障等情况下，能够最终处理事务消息的状态。
  4. 消息的幂等性： 由于事务消息可能经历多次状态回查，消费者需要确保消息的处理是幂等的，以避免因为重复处理消息而引发的问题。
  5. 消息的可靠性： 事务消息机制提供了一种可靠的消息传递方式，特别适用于要求事务一致性的场景，如订单支付、库存扣减等。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.rhkb.cn/news/216843.html

如若内容造成侵权/违法违规/事实不符，请联系长河编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

Windows汇编调用printf

Windows汇编调用printf

VS2022 汇编 项目右键 生成依赖项 生成自定义 勾选masm 链接器 高级 入口点 main X86 .686 .model flat,stdcall option casemap:none includelib ucrt.lib includelib legacy_stdio_definitions.libEXTERN printf:proc.data szFormat db %s,0 szStr db hello,0.code main…
阅读更多...
2.操作符详解

2.操作符详解

1.10进制转二进制方法 所以125的二进制就是1111101 2.2进制转8进制: 从2进制序列中右边最低位开始向左每3个2进制位换算为一个8进制位&#xff0c;剩余不够3个2进制位的直接换算 例:01101011转为01 101 011 即1 5 3 即8进制的153 还原回去的话: 将3化为011放最右边,5化…
阅读更多...
使用 React 和 ECharts 创建地球模拟扩散和飞线效果

使用 React 和 ECharts 创建地球模拟扩散和飞线效果

在本博客中&#xff0c;我们将学习如何使用 React 和 ECharts 创建一个酷炫的地球模拟扩散效果。我们将使用 ECharts 作为可视化库&#xff0c;以及 React 来构建我们的应用。地球贴图在文章的结尾。 最终效果 准备工作 首先&#xff0c;确保你已经安装了 React&#xff0c;并…
阅读更多...
oracle数据恢复—Oracle报错“system01.dbf需要更多的恢复来保持一致性”的数据恢复案例

oracle数据恢复—Oracle报错“system01.dbf需要更多的恢复来保持一致性”的数据恢复案例

oracle数据库恢复环境&故障&#xff1a; 一台Windows server操作系统的服务器上部署Oracle数据库。 服务器意外断电导致oracle数据库报错&#xff0c;报错信息&#xff1a;“system01.dbf需要更多的恢复来保持一致性”。由于该oracle数据库并没有备份&#xff0c;仅有一些断…
阅读更多...
多维时序 | MATLAB实现TSOA-TCN-Multihead-Attention多头注意力机制多变量时间序列预测

多维时序 | MATLAB实现TSOA-TCN-Multihead-Attention多头注意力机制多变量时间序列预测

多维时序 | MATLAB实现TSOA-TCN-Multihead-Attention多头注意力机制多变量时间序列预测 目录 多维时序 | MATLAB实现TSOA-TCN-Multihead-Attention多头注意力机制多变量时间序列预测预测效果基本介绍模型描述程序设计参考资料 预测效果 基本介绍 MATLAB实现TSOA-TCN-Multihead-…
阅读更多...
【Python】数据分析原来这么简单？一文总结清楚！

【Python】数据分析原来这么简单？一文总结清楚！

前言 在当今信息爆炸的时代&#xff0c;海量的数据源源不断地被生成、收集和存储。这些数据蕴藏着无限的可能性&#xff0c;但要从中提取有用的信息和洞见&#xff0c;却需要数据分析这门至关重要的技能。Python&#xff0c;作为一门强大而灵活的编程语言&#xff0c;为数据分…
阅读更多...
Proxmox创建CentOS虚拟机

Proxmox创建CentOS虚拟机

文章目录 下载ISO安装文件上传创建虚拟机启动虚拟机设置DNS CentOS配置国内安装源备份原有安装源下载更新国内源清理yum缓存制作新配置文件缓存 下载ISO安装文件 下载地址&#xff1a;https://www.xitongzhijia.net/ 也可去官网进行下载 上传 下面介绍直接通过页面上传&…
阅读更多...
YOLOv8算法改进【NO.93】使用resnet18网络作为主干特征提取网络

YOLOv8算法改进【NO.93】使用resnet18网络作为主干特征提取网络

前 言 YOLO算法改进系列出到这&#xff0c;很多朋友问改进如何选择是最佳的&#xff0c;下面我就根据个人多年的写作发文章以及指导发文章的经验来看&#xff0c;按照优先顺序进行排序讲解YOLO算法改进方法的顺序选择。具体有需求的同学可以私信我沟通&#xff1a; 第一…
阅读更多...
【学习笔记】V8垃圾回收策略

【学习笔记】V8垃圾回收策略

V8 V8是一款主流的JavaScript执行引擎V8采用即时编译,速度比较快V8内存设限,64位操作系统中上限为1.5G,32位系统中不超过800M V8垃圾回收策略 采用分代回收的思想内存分为新生代\老生代针对不同对象采用不同算法 v8常用的GC算法: 分代回收、空间复制、标记清除、标记整理、…
阅读更多...
docker学习（七、搭建mysql8.2主从）

docker学习（七、搭建mysql8.2主从）

一、主库搭建 1.构建主库镜像 # 运行mysql镜像&#xff0c;配置端口3307为主库 docker run -p 3307:3306 --name mysql-master --privilegedtrue -v /mydata/mysql-master/log:/var/log/mysql -v /mydata/mysql-master/data:/var/lib/mysql -v /mydata/mysql-master/conf:/etc…
阅读更多...
STM32-固件打包部署

STM32-固件打包部署

STM32-固件打包部署 Fang XS.1452512966qq.com STM32固件输出 工程上使用Keil开发STM32软件&#xff1b;在调试过程中&#xff0c;可直接编译下载&#xff1b;例如bootloader和APP&#xff0c;在调试时&#xff0c;可以直接下载2次&#xff1b;但是工程上&#xff0c;需要大…
阅读更多...
TMTS汽车电子仿真及测试研讨会笔记请查收！

TMTS汽车电子仿真及测试研讨会笔记请查收！

11月29日&#xff0c;德思特2023年度TMTS汽车电子仿真及测试研讨会圆满结束。感谢大家的观看与支持&#xff01; 在直播间收到一些观众的技术问题&#xff0c;我们汇总了热点问题并请讲师详细解答&#xff0c;在此整理分享给大家&#xff0c;请查收&#xff01; 面向汽车T-BOX…
阅读更多...
EasyRecovery2024苹果电脑mac破解版安装包下载

EasyRecovery2024苹果电脑mac破解版安装包下载

EasyRecovery是一款操作安全、价格便宜、用户自主操作的非破坏性的只读应用程序&#xff0c;它不会往源驱上写任何东西&#xff0c;也不会对源驱做任何改变。它支持从各种各样的存储介质恢复删除或者丢失的文件&#xff0c;其支持的媒体介质包括&#xff1a;硬盘驱动器、光驱、…
阅读更多...
CSS中神奇的filter属性

CSS中神奇的filter属性

CSS是Web开发中不可或缺的一部分&#xff0c;它可以帮助开发者在页面上添加各种各样的样式和效果。其中一个比较神奇的CSS属性就是filter&#xff0c;它可以让我们实现各种有趣的图形处理效果。 一、filter属性的基础 filter属性是CSS中用于对元素进行图形效果处理的属性之一…
阅读更多...
java-集合的补充

java-集合的补充

常见基础集合汇总 数据结构&#xff1a;栈 数据结构分为&#xff1a; &#xff08;1&#xff09;逻辑结构 &#xff1a;--》思想上的结构--》卧室&#xff0c;厨房&#xff0c;卫生间 ---》线性表&#xff08;数组&#xff0c;链表&#xff09;&#xff0c;图&#xff0c;树&…
阅读更多...
stm32F407-GPIO的使用——点亮LED并且讲解各个寄存器

stm32F407-GPIO的使用——点亮LED并且讲解各个寄存器

stm32F407-GPIO的使用——点亮LED并且讲解各个寄存器 本文为stm32GPIO的介绍与使用&#xff0c;例子是简单的LED点亮。 一、 GPIO GPIO&#xff08;General Purpose I/O Ports&#xff09;意思为通用输入/输出端口&#xff0c;通俗地说&#xff0c; 就是一些引脚&#xff0c;可…
阅读更多...
十个Vue3实用但是冷门的API

十个Vue3实用但是冷门的API

文章目录 一、前言二、readonly三、shallowRef四、shallowReactive五、toRef & toRefs5.1、 toRef5.2、toRefs 六、toRaw & markRaw & unref6.1、toRaw6.2、markRaw6.3、unref 七、effectScope & onScopeDispose7.1、收集副作用7.2、全局状态管理 八、provide …
阅读更多...
HTML面试题---专题一

HTML面试题---专题一

文章目录 一、前言二、 HTML5 中 <header> 和 <footer> 标签的用途是什么&#xff1f;三、如何在 HTML 中嵌入 SVG&#xff08;可缩放矢量图形&#xff09;文件&#xff1f;四、解释 contenteditable 属性的用途五、如何创建随屏幕尺寸缩放的响应式图像&#xff1f…
阅读更多...
3 文本分类入门finetune：bert-base-chinese

3 文本分类入门finetune：bert-base-chinese

项目实战&#xff1a; 数据准备工作 bert-base-chinese 是一种预训练的语言模型&#xff0c;基于 BERT&#xff08;Bidirectional Encoder Representations from Transformers&#xff09;架构&#xff0c;专门用于中文自然语言处理任务。BERT 是由 Google 在 2018 年提出的一…
阅读更多...
迅腾文化助力企业品牌创新，加快增强品牌发展新动能

迅腾文化助力企业品牌创新，加快增强品牌发展新动能

迅腾文化助力企业品牌创新&#xff0c;加快增强品牌发展新动能 随着市场竞争的日益激烈&#xff0c;品牌创新已成为企业持续发展的关键。为了在市场中脱颖而出&#xff0c;许多企业纷纷寻求外部合作伙伴以加快品牌发展。广州迅腾文化传播有限公司拥有13年品宣经验的企业&#…
阅读更多...
最新文章
推荐文章

Copyright @ 2022~2023