尚硅谷rabbitmq2024 集群篇仲裁队列 第52节 答疑

我们希望创建一个队列,队列分布在各个节点上,仲裁队列很好的解决了这个问题.那么在仲裁队列之前,创建一个队列,队列不是分布在各个节点上的吗?


在RabbitMQ中,默认情况下创建的队列是“普通队列”,这些队列并不会自动分布在多个节点上。默认的普通队列是由一个单一节点来管理的,这意味着如果该节点出现故障,队列和其消息将不可用。这种单节点管理的队列在高可用性方面存在一定的局限性。

仲裁队列(Quorum Queues)是RabbitMQ 3.8引入的一种新的队列类型,专门为高可用性和数据一致性而设计。仲裁队列使用Raft共识算法来确保消息在多个节点上复制和存储,从而提高了队列的可用性和数据的安全性。

### 普通队列与仲裁队列的区别

1. **普通队列**:
   - 由一个单一节点管理。
   - 如果该节点失败,队列和消息将不可用,除非手动恢复或使用镜像队列。

2. **仲裁队列**:
   - 使用Raft共识算法在多个节点上复制消息。
   - 提供更高的可用性和数据一致性。
   - 自动处理节点故障,确保队列和消息在集群中依然可用。

### 创建普通队列和仲裁队列的示例

**普通队列**:
```java
import org.springframework.amqp.core.Queue;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class RabbitMQConfig {

    @Bean
    public Queue myQueue() {
        return new Queue("myQueue", true); // true表示队列持久化
    }
}
```

**仲裁队列**:
```java
import org.springframework.amqp.core.Queue;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

import java.util.HashMap;
import java.util.Map;

@Configuration
public class RabbitMQConfig {

    @Bean
    public Queue myQuorumQueue() {
        Map<String, Object> args = new HashMap<>();
        args.put("x-queue-type", "quorum");
        return new Queue("myQuorumQueue", true, false, false, args);
    }
}
```

在这个示例中,通过设置`x-queue-type`为`quorum`,我们创建了一个仲裁队列。这个队列会自动在多个节点上复制和存储消息,从而提供更高的可用性。

希望这些信息能帮助你理解普通队列和仲裁队列之间的区别以及如何创建它们。如果有其他问题,随时问我!
===========
1. **普通队列**:
   - 由一个单一节点管理。
   - 如果该节点失败,队列和消息将不可用,除非手动恢复或使用镜像队列。

没有仲裁队列能搭建集群吗?搭建了集群,是每个节点上队列都是一样的?然后一个节点坏了集群就不可用了?那这种集群还有什么意义呢?


----
在RabbitMQ中,除了仲裁队列(Quorum Queues),还有另一种机制来实现高可用性,这就是镜像队列(Mirrored Queues)。虽然普通队列默认情况下是由单一节点管理的,但通过配置镜像队列,可以在多个节点上复制队列和消息,从而提高系统的容错性和可用性。

### 镜像队列(Mirrored Queues)

镜像队列通过在多个节点上复制队列来实现高可用性。你可以配置一个队列,使其在集群中的多个节点上都有副本(镜像)。如果管理队列的主节点发生故障,RabbitMQ会自动将队列的管理切换到一个镜像节点,从而确保队列和消息的可用性。

### 集群的意义

即使没有仲裁队列,RabbitMQ集群仍然具有以下几个重要的意义:

1. **负载均衡**:
   集群可以分散消息的发布和消费负载,防止单一节点成为瓶颈。

2. **高可用性**:
   通过使用镜像队列,可以在多个节点上复制队列和消息,从而提高系统的容错性。

3. **扩展性**:
   集群可以通过添加更多节点来扩展系统的处理能力和存储容量。

### 镜像队列配置示例

可以通过策略来配置镜像队列。例如,使用RabbitMQ的管理插件(如`rabbitmqctl`或Web管理界面)来设置策略:

```bash
rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all"}'
```

这个命令会将所有队列设置为镜像队列,并在所有节点上复制。

### 镜像队列与仲裁队列的对比

- **镜像队列**:
  - 可以在多个节点上复制队列和消息。
  - 使用经典的主-从复制机制。
  - 需要手动配置策略。

- **仲裁队列**:
  - 使用Raft共识算法在多个节点上复制消息。
  - 提供更高的一致性和自动化的故障恢复。
  - 适用于需要高可用性和数据一致性的场景。

### 总结

即使没有仲裁队列,通过镜像队列机制,RabbitMQ集群仍然可以提供高可用性和负载均衡。镜像队列确保了即使一个节点发生故障,队列和消息仍然可用,从而提高系统的可靠性。

如果你需要更高的一致性和自动化的故障恢复,可以考虑使用仲裁队列。希望这些信息能帮助你理解RabbitMQ集群的意义和高可用性机制。如果有其他问题,随时问我!


=========
所以搭建一个集群。我用了haproxy,还将节点加入了               集群,但是如果没有配置镜像或者仲裁队列的话,这个集群也不可用吗?


---
如果你已经搭建了一个RabbitMQ集群并使用了HAProxy进行负载均衡,但没有配置镜像队列或仲裁队列,那么默认情况下,队列和消息将只存在于创建它们的单个节点上。这种情况下,集群的高可用性特性将无法充分发挥作用。

### 集群在没有镜像或仲裁队列的情况下的行为

1. **单节点故障**:
   - 如果一个节点故障,所有在该节点上创建的队列和消息将不可用,直到该节点恢复。
   - 其他节点上的队列和消息不受影响,但如果这些队列和消息对你的应用来说是关键的,系统的部分功能可能会中断。

2. **负载均衡**:
   - HAProxy可以均衡消息发布和消费的负载,但不会自动处理队列的高可用性。
   - 即使负载均衡,队列和消息仍然依赖于单个节点。

### 如何确保高可用性

为了确保你的RabbitMQ集群在节点故障时仍然可用,你需要配置镜像队列或使用仲裁队列。以下是如何配置这两种队列的概要:

#### 配置镜像队列

通过策略配置镜像队列,使队列在多个节点上复制:

```bash
rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all"}'
```

这个命令会将所有队列设置为镜像队列,并在所有节点上复制。

#### 配置仲裁队列

创建时指定队列类型为“quorum”:

```java
import org.springframework.amqp.core.Queue;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

import java.util.HashMap;
import java.util.Map;

@Configuration
public class RabbitMQConfig {

    @Bean
    public Queue myQuorumQueue() {
        Map<String, Object> args = new HashMap<>();
        args.put("x-queue-type", "quorum");
        return new Queue("myQuorumQueue", true, false, false, args);
    }
}
```

### 总结

如果你没有配置镜像队列或仲裁队列,那么即使你搭建了RabbitMQ集群并使用了HAProxy进行负载均衡,集群的高可用性特性仍然无法充分发挥作用。在这种情况下,单个节点的故障会导致该节点上的队列和消息不可用。

为了确保高可用性,建议你配置镜像队列或使用仲裁队列。这样可以确保队列和消息在多个节点上复制,从而在节点故障时仍然可用。如果有其他问题或需要进一步的帮助,随时问我!

========
那我就先说在没有镜像或者仲裁队列的情况下,集群是什么情况,haproxy负载均衡了之后,发送一个3个消息到某个队列上,是每个节点上都有3个消息,还是每个节点上有一个1个消息?是每个节点上都有3个消息,和广播有什么区别?如果每个节点上有一个1个消息,不就是仲裁队列的效果了吗?


在没有配置镜像队列或仲裁队列的情况下,RabbitMQ集群的行为如下:

### 消息分配和存储

1. **队列的创建和存储**:
   - 队列是创建在某个具体的节点上的,并且默认情况下不会自动复制到其他节点。
   - 如果你通过HAProxy发送消息到一个队列,该队列仍然只存在于一个节点上。

2. **消息的发送**:
   - 当你发送消息到某个队列时,消息会被存储在该队列所在的节点上。
   - 消息不会自动分发到集群中的其他节点。

### 负载均衡的行为

HAProxy的负载均衡仅影响客户端连接和请求的分配,而不改变RabbitMQ队列和消息的存储机制。具体来说:

- 如果你通过HAProxy连接到RabbitMQ集群,HAProxy会根据配置将你的连接分配到不同的节点。
- 但是,消息仍然会被发送到你指定的队列,而该队列只存在于创建它的节点上。

### 具体情况分析

假设你有一个RabbitMQ集群,包含节点A、B和C,并且你通过HAProxy发送消息到一个名为`myQueue`的队列:

1. **队列创建**:
   - `myQueue`在节点A上创建。

2. **消息发送**:
   - 你发送3条消息到`myQueue`。
   - 这3条消息将全部存储在节点A上,因为`myQueue`只存在于节点A。

### 没有镜像或仲裁队列的情况下的集群行为

- **每个节点上都有3个消息**:这种情况不会发生,因为默认情况下队列和消息不会自动复制到其他节点。
- **每个节点上有一个消息**:这种情况也不会发生,因为消息是发送到队列所在的节点上,而不是分散到不同的节点。
- **每个节点上都有3个消息,与广播的区别**:在默认配置下,消息不会广播到所有节点。广播是一种特殊的消息传递模式,不适用于默认的队列行为。

### 总结

在没有配置镜像队列或仲裁队列的情况下:

- 队列和消息是单节点存储的。
- HAProxy可以均衡客户端连接,但不会改变队列和消息的存储位置。
- 发送到某个队列的消息只会存储在该队列所在的节点上,不会自动分发到其他节点。

为了实现高可用性和消息复制,你需要配置镜像队列或使用仲裁队列。希望这些信息能帮助你理解RabbitMQ集群在不同配置下的行为。如果有其他问题,随时问我!

==========
一般haproxy负载均衡到集群中每个节点,比如3个节点 a b c, a b c上都有队列q1,而只有a上有q2,然后我发3个消息到q1,根据负载均衡,不是a b c上各有一个消息,还不同,a上第一个消息,b上第二个消息。。而发送3个消息到q2队列是不是 所有消息都到a上了?但是根据负载均衡,应该第一个消息发到a了,后面两个发送到b和c,由于找不到队列,就丢失到    死信队列了.是这样吗?不然能怎样?


在RabbitMQ集群中,HAProxy负载均衡主要用于分配客户端连接到不同的节点,而不是直接用于消息的分发和存储。因此,理解RabbitMQ集群在没有配置镜像队列或仲裁队列的情况下的行为非常重要。

### RabbitMQ集群中的队列和消息存储

1. **队列的创建和存储**:
   - 队列是创建在某个具体的节点上的,并且默认情况下不会自动复制到其他节点。
   - 如果你通过HAProxy发送消息到一个队列,该队列仍然只存在于一个节点上。

2. **消息的发送**:
   - 当你发送消息到某个队列时,消息会被存储在该队列所在的节点上。
   - 消息不会自动分发到集群中的其他节点。

### 负载均衡的行为

HAProxy的负载均衡仅影响客户端连接和请求的分配,而不改变RabbitMQ队列和消息的存储机制。具体来说:

- 如果你通过HAProxy连接到RabbitMQ集群,HAProxy会根据配置将你的连接分配到不同的节点。
- 但是,消息仍然会被发送到你指定的队列,而该队列只存在于创建它的节点上。

### 具体情况分析

假设你有一个RabbitMQ集群,包含节点A、B和C,并且你通过HAProxy发送消息到一个名为`q1`的队列,而`q1`在每个节点上都存在,但`q2`只存在于节点A:

1. **队列创建**:
   - `q1`在节点A、B和C上都存在。
   - `q2`只在节点A上存在。

2. **消息发送**:
   - 你发送3条消息到`q1`。
   - 根据HAProxy的负载均衡策略,客户端连接可能会被分配到节点A、B和C中的任意一个。
   - 假设HAProxy将每个消息的发送请求分配给不同的节点,那么消息会被发送到`q1`


### 负载均衡和消息分发的具体情况

#### 发送消息到存在于所有节点上的队列(例如 `q1`)

假设 `q1` 队列在节点 A、B 和 C 上都存在,并且你通过 HAProxy 发送 3 条消息到 `q1`:

1. **HAProxy 负载均衡**:
   - HAProxy 会根据其配置的负载均衡策略(如轮询、最少连接等)将客户端连接分配给不同的节点。
   - 假设 HAProxy 使用轮询策略,3 条消息的发送请求会依次分配给节点 A、B 和 C。

2. **消息存储**:
   - **消息 1**:通过 HAProxy 被分配到节点 A,存储在节点 A 的 `q1` 队列中。
   - **消息 2**:通过 HAProxy 被分配到节点 B,存储在节点 B 的 `q1` 队列中。
   - **消息 3**:通过 HAProxy 被分配到节点 C,存储在节点 C 的 `q1` 队列中。

因此,每个节点上的 `q1` 队列各自存储了一条消息。

#### 发送消息到只存在于一个节点上的队列(例如 `q2`)

假设 `q2` 队列只存在于节点 A 上:

1. **HAProxy 负载均衡**:
   - HAProxy 会将客户端连接分配给不同的节点,但由于 `q2` 只存在于节点 A 上,只有通过节点 A 的连接才能成功发送消息到 `q2`。

2. **消息存储**:
   - **消息 1**:通过 HAProxy 被分配到节点 A,成功存储在节点 A 的 `q2` 队列中。
   - **消息 2**:通过 HAProxy 被分配到节点 B,由于节点 B 上没有 `q2` 队

好的,继续讨论发送消息到只存在于一个节点上的队列(例如 `q2`)的情况。

### 发送消息到只存在于一个节点上的队列(例如 `q2`)

假设 `q2` 队列只存在于节点 A 上:

1. **HAProxy 负载均衡**:
   - HAProxy 会将客户端连接分配给不同的节点,但由于 `q2` 只存在于节点 A 上,只有通过节点 A 的连接才能成功发送消息到 `q2`。

2. **消息存储**:
   - **消息 1**:通过 HAProxy 被分配到节点 A,成功存储在节点 A 的 `q2` 队列中。
   - **消息 2**:通过 HAProxy 被分配到节点 B,由于节点 B 上没有 `q2` 队列,消息发送失败。
   - **消息 3**:通过 HAProxy 被分配到节点 C,由于节点 C 上没有 `q2` 队列,消息发送失败。

### 消息发送失败的处理

在 RabbitMQ 中,当消息发送失败时,可以采取以下几种处理方式:

1. **丢弃消息**:
   - 如果没有配置任何处理机制,消息发送失败后将被丢弃。

2. **返回给生产者**:
   - 可以配置 RabbitMQ 将发送失败的消息返回给生产者。生产者可以选择重新发送消息或进行其他处理。

3. **死信队列(Dead Letter Queue)**:
   - 可以配置死信队列,将发送失败的消息路由到死信队列进行后续处理。

### 配置死信队列的示例

以下是一个配置死信队列的示例:

#### 声明死信交换机和死信队列

```java
import org.springframework.amqp.core.DirectExchange;
import org.springframework.amqp.core.Queue;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class RabbitMQConfig {

    @Bean
    public DirectExchange deadLetterExchange() {
        return new DirectExchange("deadLetterExchange");
    }

    @Bean
    public Queue


==============
那用了仲裁队列,我  写springboot程序,连接集群,还要把每个节点的ip都写上吗?redis和elasticsearch好像不是这样吧?而且一个rabbitmq节点                        宕机了,虽然                     还能收发消息,但是java程序里面                好像会报个错?

是的,使用仲裁队列(Quorum Queues)可以提高RabbitMQ集群的高可用性和数据一致性,但在连接和配置方面确实需要注意一些细节。

### 连接RabbitMQ集群

在Spring Boot应用程序中连接RabbitMQ集群时,确实需要提供集群中所有节点的IP地址,以便在一个节点宕机时,客户端能够自动切换到其他可用节点。这与Redis和Elasticsearch的行为类似,尽管它们的客户端可能会隐藏一些配置细节。

### Spring Boot中的连接配置

在Spring Boot中,可以使用`spring.rabbitmq.addresses`属性来配置集群节点的地址。这个属性允许你指定一个逗号分隔的节点列表。

```yaml
spring:
  rabbitmq:
    addresses: amqp://user:password@node1:5672,amqp://user:password@node2:5672,amqp://user:password@node3:5672
    username: user
    password: password
```

### 自动重连和错误处理

RabbitMQ客户端(如Spring AMQP和RabbitMQ Java客户端)通常会处理连接的自动重连,但在某些情况下,仍然可能会遇到错误或异常。这些错误通常是暂时性的,并且客户端会尝试重新连接到集群中的其他节点。

#### 处理连接错误

在Spring Boot中,可以通过配置连接工厂的属性来调整重连策略。例如,可以设置连接超时、重试间隔等参数。

```java
import org.springframework.amqp.rabbit.connection.CachingConnectionFactory;
import org.springframework.amqp.rabbit.connection.ConnectionFactory;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class RabbitMQConfig {

    @Bean
    public ConnectionFactory connectionFactory() {
        CachingConnectionFactory connectionFactory = new CachingConnectionFactory();
        connectionFactory.setAddresses("node1:5672,node2:5672,node3:5672");
        connectionFactory.setUsername("user");
        connectionFactory.setPassword("password");
        connectionFactory.setConnectionTimeout(30000); // 30秒连接超时
        connectionFactory.setRequestedHeartBeat(

### 处理连接错误和自动重连

在Spring Boot中,可以通过配置连接工厂的属性来调整重连策略。例如,可以设置连接超时、重试间隔等参数。以下是一个详细的配置示例:

#### 配置连接工厂

```java
import org.springframework.amqp.rabbit.connection.CachingConnectionFactory;
import org.springframework.amqp.rabbit.connection.ConnectionFactory;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class RabbitMQConfig {

    @Bean
    public ConnectionFactory connectionFactory() {
        CachingConnectionFactory connectionFactory = new CachingConnectionFactory();
        connectionFactory.setAddresses("node1:5672,node2:5672,node3:5672");
        connectionFactory.setUsername("user");
        connectionFactory.setPassword("password");
        connectionFactory.setConnectionTimeout(30000); // 30秒连接超时
        connectionFactory.setRequestedHeartBeat(30); // 30秒心跳间隔
        connectionFactory.setPublisherConfirms(true); // 启用发布确认
        connectionFactory.setPublisherReturns(true); // 启用发布返回
        return connectionFactory;
    }
}
```

#### 配置重试机制

可以通过配置Spring Retry来处理连接失败后的重试逻辑。以下是一个示例:

```java
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.amqp.rabbit.retry.RepublishMessageRecoverer;
import org.springframework.amqp.rabbit.retry.RepublishMessageRecoverer;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.retry.backoff.ExponentialBackOffPolicy;
import org.springframework.retry.policy.SimpleRetryPolicy;
import org.springframework.retry.support.RetryTemplate;

@Configuration
public class RabbitMQRetryConfig {

    @Bean
    public RabbitTemplate rabbitTemplate(ConnectionFactory connectionFactory) {
        RabbitTemplate template = new RabbitTemplate(connectionFactory);
        template.setRetryTemplate(retryTemplate());
        return template;
    }

    @Bean
    public RetryTemplate retryTemplate() {
        RetryTemplate retryTemplate = new RetryTemplate();

        // 配置重试策略策略
        SimpleRetryPolicy = new SimpleRetryPolicy();
        retryPolicy.setMaxAttempts(5); // 最大重试次数
        retryTemplate.setRetryPolicy(retryPolicy);

        // 配置退避策略
        ExponentialBackOffPolicy backOffPolicy = new ExponentialBackOffPolicy();
        backOffPolicy.setInitialInterval(1000); // 初始间隔时间(毫秒)
        backOffPolicy.setMultiplier(2.0); // 每次重试间隔的倍数
        backOffPolicy.setMaxInterval(10000); // 最大间隔时间(毫秒)
        retryTemplate.setBackOffPolicy(backOffPolicy);

        return retryTemplate;
    }
}
```

### 总结

1. **连接配置**:在Spring Boot中,通过`spring.rabbitmq.addresses`属性配置RabbitMQ集群的所有节点地址,以确保客户端能够在一个节点宕机时自动切换到其他可用节点。
2. **自动重连**:RabbitMQ客户端通常会处理自动重连,但可以通过配置连接工厂的属性来调整重连策略,例如连接超时、心跳间隔等。
3. **重试机制**:使用Spring Retry配置重试策略和退避策略,以处理连接失败后的重试逻辑。

通过这些配置,可以确保你的Spring Boot应用在连接RabbitMQ集群时具备更高的可用性和容错性。如果有其他问题或需要进一步的帮助,随时问我!
 

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

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

相关文章

Oracle T5-2 ILOM配置

ILOM管理口ip地址配置 连接控制器&#xff08;SP&#xff09;串口&#xff08;RJ45)&#xff0c;进行系统设置 (缺省&#xff1a;9600&#xff0c;8-n-1&#xff0c;root/changeme) …………………. ORACLESP-AK02566506 login: root Password: Detecting screen size; pl…

EditText的inputType 详解

EditText的inputType属性用于指定EditText接受的输入类型&#xff0c;它可以通过XML布局文件或代码来设置。‌ 该属性决定了EditText在键盘弹出时的样式和功能&#xff0c;例如是否显示数字键盘、是否允许输入特殊字符等。通过设置不同的InputType&#xff0c;可以限制用户输入…

Axure重要元件三——中继器

亲爱的小伙伴&#xff0c;在您浏览之前&#xff0c;烦请关注一下&#xff0c;在此深表感谢&#xff01; 本节课&#xff1a;中继器 课程内容&#xff1a;认识中继器、中继器基本操作、中继器案例 应用场景&#xff1a;高级表单交互 一、认识中继器 我们不从理论视角去展示…

MySQL InnoDB Buffer Pool空间不足导致查询变慢

问题现象 前端调用后台服务查询接口响应很慢&#xff0c;查看 MySQL 的日志&#xff0c;有如下日志&#xff1a; [Warning] InnoDB: Difficult to find free blocks in the buffer pool (13430 search iterations)! 13430 failed attempts to flush a page! Consider increas…

Android Framework AMS(05)startActivity分析-2(ActivityThread启动到Activity拉起)

该系列文章总纲链接&#xff1a;专题总纲目录 Android Framework 总纲 本章关键点总结 & 说明&#xff1a; 说明&#xff1a;本章节主要解读AMS通过startActivity启动Activity的整个流程的整个流程的第二阶段&#xff1a;从ActivityThread启动到Activity拉起。 第一阶段文…

【Vue】Vue(八)Vue3.0 使用ref 和 reactive创建响应式数据

ref 创建&#xff1a;基本类型的响应式数据 **作用&#xff1a;**定义响应式变量。语法&#xff1a;let xxx ref(初始值)。**返回值&#xff1a;**一个RefImpl的实例对象&#xff0c;简称ref对象或ref&#xff0c;ref对象的value属性是响应式的。注意点&#xff1a; JS中操作…

《拿下奇怪的前端报错》:1比特丢失导致的音视频播放时长无限增长-浅析http分片传输核心和一个坑点

问题背景 在一个使用MongoDB GridFS实现文件存储和分片读取的项目中&#xff0c;同事遇到了一个令人困惑的问题&#xff1a;音频文件总是丢失最后几秒&#xff0c;视频文件也出现类似情况。更奇怪的是&#xff0c;播放器显示的总时长为无限大。这个问题困扰了团队成员几天&…

Java项目-基于Springboot的应急救援物资管理系统项目(源码+说明).zip

作者&#xff1a;计算机学长阿伟 开发技术&#xff1a;SpringBoot、SSM、Vue、MySQL、ElementUI等&#xff0c;“文末源码”。 开发运行环境 开发语言&#xff1a;Java数据库&#xff1a;MySQL技术&#xff1a;SpringBoot、Vue、Mybaits Plus、ELementUI工具&#xff1a;IDEA/…

工业自动化为什么依赖光耦隔离器 --- 腾恩科技

光耦合器隔离器在工业自动化中必不可少&#xff0c;可确保信号传输&#xff0c;同时保护敏感电子设备和人员免受高压影响。选择合适的光耦合器隔离器取决于对操作环境和隔离要求的了解。本文将重点介绍在为工业应用选择光耦合器隔离器时需要考虑的关键因素。 光耦合器隔离器在工…

上传图片到github上,生成链接在Typora中使用(解决Typora的md文件在分享时的丢失问题)

上传图片到github上,生成链接在Typora中使用(解决Typora的md文件在分享时的丢失问题) 在GitHub上从操作 创建一个 GitHub 仓库: 登录 GitHub,创建一个新的仓库来存储图片。 生成 GitHub 令牌: 在 GitHub 中,前往“Settings” > “Developer settings” > “Pers…

AUTOSAR_EXP_ARAComAPI的5章笔记(12)

☞返回总目录 5.4.6 方法 骨架侧的服务方法是抽象方法&#xff0c;必须由继承骨架的服务实现子类进行重写。让我们来看一下我们服务示例中的 Adjust 方法&#xff1a; /*** 对于所有输出和非空返回参数* 生成一个包含非空返回值和/或输出参数的封装结构。*/ struct AdjustOu…

docker网络连接模式详解

五种模式对比 bridge/桥接网络&#xff1a;适用于大多数单主机场景&#xff0c;提供基本的网络隔离和通信。 HOST/主机网络&#xff1a;适用于需要高性能和直接网络访问的场景。 NONE/无网络&#xff1a;适用于不需要网络访问的容器&#xff0c;增加安全性。 container/容器网…

UE4 材质学习笔记08(雨滴流淌着色器/雨水涟漪着色器)

一.雨滴流淌着色器 法线贴图在红色通道和绿色通道上&#xff0c;那是法线的X轴和Y轴&#xff0c;在蓝色通道中 我有个用于雨滴流淌的蒙版&#xff0c;在Alpha通道中&#xff0c;有个时间偏移蒙版。这些贴图都是可以在PS上制作做来的&#xff0c;雨滴流淌图可以直接用笔刷画出来…

永恒之蓝漏洞

MS17-010是微软于2017年3月发布的一个安全补丁&#xff0c;旨在修复Windows操作系统中的一个严重漏洞&#xff0c;该漏洞被称为“永恒之蓝”&#xff08;EternalBlue&#xff09;。这个漏洞影响了Windows的Server Message Block&#xff08;SMB&#xff09;协议&#xff0c;允许…

Java集合剖析3】ArrayList

目录 拓展 1. 在面试时如何讲解一个集合的底层&#xff1f; 2. IDEA如何查看底层源码&#xff1f; 一、ArrayList底层数据结构 二、插入方法的具体实现 三、ArrayList底层原理总结 拓展 1. 在面试时如何讲解一个集合的底层&#xff1f; 底层的数据结构。插入方法的具体实现。…

vue综合指南(六)

​&#x1f308;个人主页&#xff1a;前端青山 &#x1f525;系列专栏&#xff1a;Vue篇 &#x1f516;人终将被年少不可得之物困其一生 依旧青山,本期给大家带来Vuet篇专栏内容:vue综合指南 目录 101、Vue 框架怎么实现对象和数组的监听&#xff1f; 102、Proxy 与 Object.d…

10 分钟使用豆包 MarsCode 帮我搭建一套后台管理系统

以下是「 豆包MarsCode 体验官」优秀文章&#xff0c;作者把梦想揉碎。 十分钟使用豆包 MarsCode 搭建后台管理项目 在这个快节奏的时代&#xff0c;开发者们总是希望能够快速、高效地完成项目的搭建与开发工作。无论是初创企业还是大型公司&#xff0c;后台管理系统都是必不可…

SpringBoot1~~~

目录 快速入门 依赖管理和自动配置 修改自动仲裁/默认版本号 starter场景启动器 自动配置 修改默认扫描包结构 修改默认配置 读取application.properties文件 按需加载原则 容器功能 Configuration Import ​编辑 Conditional ImportResource 配置绑定Configur…

要在 Git Bash 中使用 `tree` 命令,下载并手动安装 `tree`。

0、git bash 安装 git(安装,常用命令,分支操作,gitee,IDEA集成git,IDEA集成gitee,IDEA集成github,远程仓库操作) 1、下载并手动安装 tree 下载 tree.exe 从 tree for Windows 官方站点 下载 tree 的 Windows 可执行文件。tree for Window&#xff1a;https://gnuwin32.source…

鸿蒙应用开发:全面认识鸿蒙系统

前言 随着智能设备的普及和物联网的发展&#xff0c;对操作系统的需求也越来越多样化。鸿蒙操作系统作为一款面向全场景的分布式操作系统&#xff0c;其适用范围非常广泛&#xff0c;从智能手机到家用电器&#xff0c;再到工业设备&#xff0c;都能找到应用场景。特别是在智能…