这是一篇关于 Tomcat 与 Undertow 对比的文档，并附带了 Undertow 的使用教程。

🚀 Tomcat 对比 Undertow：高性能 Web 服务器的选择

Apache Tomcat 和 Undertow 都是流行的 Java Servlet 容器和 Web 服务器，它们在 Java 生态系统中扮演着关键角色。然而，它们在设计哲学、性能和功能集上有所不同。

主要特点对比

🔍 总结与选择建议

• 选择 Tomcat: 如果你的应用需要极高的稳定性、广泛的社区支持，或者你的环境是传统的 Java EE/Servlet 部署模式，并且对极高并发要求不苛刻，Tomcat 是一个安全且可靠的选择。
• 选择 Undertow: 如果你的应用是一个微服务或 Spring Boot 应用，追求极致的性能、低资源消耗，以及高并发处理能力，特别是需要充分利用 NIO/事件驱动 的优势时，Undertow 是一个优秀的、现代化的替代品。

🛠️ Undertow 使用教程：嵌入式部署（Maven + Spring Boot）

Undertow 最大的优点之一是它作为 嵌入式容器 的卓越性能和简易性。在现代 Java 开发中，尤其是在使用 Spring Boot 时，切换到 Undertow 非常简单。

1. 创建 Maven 项目

确保你的项目是一个标准的 Spring Boot 应用，并使用 Maven 或 Gradle 进行构建。

2. 移除默认的 Tomcat 依赖

在 Spring Boot 的 pom.xml 文件中，默认的 spring-boot-starter-web 会引入 Tomcat。你需要排除它，然后显式地引入 Undertow。

pom.xml 配置 (Maven)

找到 spring-boot-starter-web 依赖，并添加 <exclusions> 标签来排除 Tomcat：

1
2
3
4
5
6
7
8
9
10

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-tomcat</artifactId>
        </exclusion>
    </exclusions>
</dependency>

3. 引入 Undertow 依赖

在 pom.xml 中添加 spring-boot-starter-undertow 依赖：

1
2
3
4

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-undertow</artifactId>
</dependency>

4. 运行应用

完成上述步骤后，你的 Spring Boot 应用在启动时就会自动检测并使用 Undertow 作为其内置的 Web 服务器，而不是默认的 Tomcat。

5. 配置文件进阶（可选）

你可以通过 Spring Boot 的 application.properties 或 application.yml 文件来配置 Undertow 的线程池大小等参数，以进行性能调优。

application.properties 示例

1
2
3
4
5
6
7
8

# 设定 Undertow 的 I/O 线程数 (通常等于CPU核心数)
server.undertow.threads.io=4

# 设定工作线程数 (处理请求的线程)
server.undertow.threads.worker=200

# 设定缓冲区大小
server.undertow.buffer-size=1024

通过以上简单的配置，你就可以在 Spring Boot 应用中轻松地从 Tomcat 切换到高性能的 Undertow 服务器。

PS: 该内容由Gemini生成

微信小程序在 iOS 设备上引用字体正常，但在 安卓 设备上无法加载时，通常由 Nginx 配置问题导致。以下是具体解决方案：

Nginx配置调整

1. ‌添加跨域权限‌
   在Nginx配置文件中，针对字体文件（如.woff、.ttf等）的请求头添加跨域权限设置：

   1 2 3 4 5 6 7

   # 字体文件跨域设置 location ~* \.(ttf|woff|woff2)$ { add_header Access-Control-Allow-Origin *; expires 30d; error_log /dev/null; access_log /dev/null; }

2. ‌设置响应头参数‌
   确保响应包含以下头部信息：

   • Access-Control-Allow-Origin: *（允许所有来源跨域）
   • Cache-Control: no-cache（禁用缓存） ‌

3. ‌清理小程序缓存‌
   若配置完成后仍无法生效，需在微信开发者工具中清理小程序缓存后重新测试。 ‌

4. 完整配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

server
{
    listen 80;
    listen 443 ssl http2 ;
    server_name img.**.ruiyeclub.cn;
    index index.html index.htm default.htm default.html;
    root /www/wwwroot/img.**.ruiyeclub.cn;

    #REWRITE-START URL重写规则引用,修改后将导致面板设置的伪静态规则失效
    include /www/server/panel/vhost/rewrite/html_img.**.ruiyeclub.cn.conf;
    #REWRITE-END

    #禁止访问的文件或目录
    location ~ ^/(\.user.ini|\.htaccess|\.git|\.env|\.svn|\.project|LICENSE|README.md)
    {
        return 404;
    }

    #一键申请SSL证书验证目录相关设置
    location ~ \.well-known{
        allow all;
    }

    #禁止在证书验证目录放入敏感文件
    if ( $uri ~ "^/\.well-known/.*\.(php|jsp|py|js|css|lua|ts|go|zip|tar\.gz|rar|7z|sql|bak)$" ) {
        return 403;
    }

    # 字体文件跨域设置
    location ~* \.(ttf|woff|woff2)$ {
        add_header Access-Control-Allow-Origin *;
        expires      30d;
        error_log /dev/null;
        access_log /dev/null;
    }

    location ~ .*\\.(gif|jpg|jpeg|png|bmp|swf)$
    {
        add_header Cache-Control "public, max-age=31536000"; #my 设置静态资源的缓存时间为1年（单位：秒）

        expires      30d;
        error_log /dev/null;
        access_log /dev/null;
    }

    location ~ .*\\.(js|css)?$
    {
        expires      12h;
        error_log /dev/null;
        access_log /dev/null;
    }
    access_log  /www/wwwlogs/img.**.ruiyeclub.cn.log;
    error_log  /www/wwwlogs/img.**.ruiyeclub.cn.error.log;
}

注意事项

• 字体文件路径需与配置一致，例如存放在/www/wwwroot/***/public/static目录下。 ‌
• 不同品牌安卓手机对跨域策略的兼容性存在差异，部分机型需额外配置域名白名单或业务域名。

📝记录一下，尽管使用了同步锁甚至是分布式锁还是查询并发问题的情况。

对同一条数据进行”查询状态->更新状态”操作时，出现多次更新状态。

这个是我业务代码：

1
2
3
4
5
6
7

@Transactional(rollbackFor = Exception.class)
public void update(Long modelId) throws GseException {
    synchronized (this) {
        //业务逻辑代码
    }
}

使用redis分布式锁的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

@Transactional(rollbackFor = Exception.class)
public void update(Long modelId) throws GseException {
    RLock lock = redissonClient.getLock(REDIS_COST_MODEL_ID_LOCK + modelId);
    try {
        if (lock.tryLock(20, 2, TimeUnit.SECONDS)) {
            //业务逻辑代码
        } else {
            log.error("获取分布式锁失败");
        }
    } catch (InterruptedException e) {
        throw new RuntimeException(e);
    } finally {
        // 判断当前线程是否持有锁
        if (lock.isHeldByCurrentThread()) {
            //释放当前锁
            lock.unlock();
        }
    }
}

一、存在的问题以及原因

问题就是以上两种写法都没有生效，但是为什么呢？ 在解释这个问题之前，我们首先要弄清楚两个问题：

1. @Transactional的底层实现原理，开启事务和提交事务的时机是什么？

2. 分布式锁，和本地锁机制释放锁的时机是什么时候？3.1 @Transactional的底层实现原理，开启事务和提交事务的时机是什么？

它的底层实现原理主要依赖于 Spring 的面向切面编程（AOP）机制。 底层实现原理

• AOP 代理：当一个类或方法被 @Transactional 注解标记时，Spring 容器在初始化 Bean 时会检测到这个注解。对于使用 Spring
  的代理模式（如 JDK 动态代理或 CGLIB），Spring 会为该 Bean
  创建一个代理对象。这个代理对象会在调用实际方法前后插入事务管理相关的代码，即在方法执行前开启事务，在方法执行完毕后根据执行情况提交或回滚事务。
• 解析注解：Spring 通过扫描 Bean 定义，识别出带有 @Transactional 注解的方法或类，并配置相应的事务属性，如传播行为、隔离级别、超时时间、是否只读等。
• 事务拦截器：Spring 使用 AOP 机制中的拦截器（Interceptor）或Advice（通常为 TransactionInterceptor 或 AspectJ
  的切面），在方法调用前后织入事务处理逻辑。在方法调用前，根据事务属性设置事务的开始；在方法正常结束时提交事务，如果方法抛出未检查异常（继承自
  RuntimeException 的异常）或已检查异常（被 @Transactional 的 rollbackFor 属性指定的异常）则回滚事务。

开启事务和提交事务的时机

• 开启事务：事务通常在进入被 @Transactional 注解的方法之前立即开始。这意味着在执行业务逻辑之前，Spring
  会确保与当前环境匹配的事务上下文已经建立。这包括选择合适的事务管理器，根据事务属性配置事务的隔离级别、传播行为等，并在数据库中实际开启事务。
• 提交事务：如果被注解的方法正常执行结束，没有抛出任何异常，Spring 会在离开该方法之前提交事务
  。提交事务意味着将所有挂起的更改永久化到数据库中，使事务中的所有操作对外可见。
• 回滚事务：如果在被注解的方法执行过程中抛出了异常，并且该异常未被 @Transactional 的 noRollbackFor 属性豁免，Spring
  将在捕获到异常后立即回滚事务，撤销所有在事务中已完成但未提交的操作，保持数据的一致性。

二、分布式锁，和本地锁机制释放锁的时机是什么时候？

答案是：本地锁，如果是synchronized，看你包裹起来的范围。Lock的话 看你手动释放锁的时候。 分布式锁：看你手动释放锁的时候。

那么造成问题的原因就出来了，如下图：

也就是说最终提交事务和释放锁的顺序有问题，按照上面的代码写法，因为当只有方法执行完了，AOP切面才会提交事务，那么如果你将上锁的代码写到被@Transactional注解的方法里面，那么提交事务永远都会处于释放锁之后，那么在释放锁之后，提交事务之前的这段时间，就会有并发问题。

三、正确的写法

1. 本地锁

1
2
3
4
5
6
7
8
9
10
11
12

   public void addLock(Long modelId) throws GseException {
    synchronized (this) {
        update(modelId);
    }
}

@Transactional(rollbackFor = Exception.class)
public void xxxCopy(Long modelId) throws GseException {
    synchronized (this) {
        //业务逻辑代码
    }
}

2. 分布式锁

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

public void addLock(Long modelId) throws GseException {
  RLock lock = redissonClient.getLock(REDIS_COST_MODEL_ID_LOCK + modelId);
  try {
      if (lock.tryLock(20, 2, TimeUnit.SECONDS)) {
          update(modelId);
      } else {
          log.error("获取分布式锁失败");
      }
  } catch (InterruptedException e) {
      throw new RuntimeException(e);
  } finally {
      // 判断当前线程是否持有锁
      if (lock.isHeldByCurrentThread()) {
          //释放当前锁
          lock.unlock();
      }
  }
}

@Transactional(rollbackFor = Exception.class)
public void update(Long modelId) throws GseException {
    synchronized (this) {
        //业务逻辑代码
    }
}

这样的写法，成功避免了并发问题，被@Transactional注解的方法，在执行完毕以后，就会提交事务，然后到了调用方法里面，再去释放锁。

四、使用悲观锁和乐观锁

问题分析

1. 请求A：查询状态 → 符合条件 → 更新状态（但数据库卡顿，更新缓慢）
2. 请求B：在A完成前查询状态 → 看到的状态未被修改 → 也执行更新

这会导致：

• 数据不一致（如重复扣减库存）
• 业务逻辑错误（如订单重复支付）
• 资源超用（如优惠券被多个用户同时使用）

解决方案

1. 事务 + SELECT FOR UPDATE（推荐）

在事务中使用SELECT FOR UPDATE锁定行，确保更新操作的原子性：

1
2
3
4
5
6
7
8
9
10
11
12
13

@Transactional
public void updateWithLock(Long id) {
    // 使用SELECT FOR UPDATE锁定行
    MyData data = myDataMapper.selectForUpdate(id);

    // 检查状态
    if (data.getStatus() == TARGET_STATUS) {
        // 执行更新
        data.setStatus(NEW_STATUS);
        myDataMapper.update(data);
    }
}

SQL映射：

1
2
3
4

<!-- 使用FOR UPDATE锁定行 -->
<select id="selectForUpdate" resultType="MyData">
    SELECT * FROM my_table WHERE id = #{id} FOR UPDATE
</select>

2. 乐观锁（使用版本号）

添加版本号字段，每次更新检查版本号：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public boolean updateWithVersion(Long id) {
    MyData data = myDataMapper.findById(id);

    if (data.getStatus() != TARGET_STATUS) {
        return false;
    }

    // 带版本号的更新
    int rows = myDataMapper.updateWithVersion(
            id,
            NEW_STATUS,
            data.getVersion(),  // 当前版本
            data.getVersion() + 1 // 新版本
    );

    return rows > 0;
}

SQL映射：

1
2
3
4
5
6
7

<update id="updateWithVersion">
UPDATE my_table
SET status = #{newStatus},
version = #{newVersion}
WHERE id = #{id}
AND version = #{oldVersion}
</update>

参考文章：记录一次Redisson使用synchronized和分布式锁不生效的原因
参考文章：悲观锁、乐观锁、mybatis-plus实现乐观锁

要在 Docker 中安装并运行 Nacos 服务器并使用 MySQL 作为其数据库，您可以遵循以下步骤。Nacos 是一个更易于构建云原生应用的动态服务发现、配置和服务管理平台，它支持多种数据库作为其存储后端，包括 MySQL。

步骤 1: 安装 Docker

确保您的系统上已安装 Docker。您可以通过以下命令检查 Docker 是否已安装：

1

docker --version

如果未安装，请访问 Docker 官网 获取安装指南。

步骤 2: 启动 MySQL 容器

首先，您需要运行一个 MySQL 容器。可以使用官方的 MySQL 镜像。创建一个名为 nacos-mysql 的容器，并为它设置一些环境变量，例如 root 用户的密码和数据库名：

1

docker run --name nacos-mysql -e MYSQL_ROOT_PASSWORD=root -p 3306:3306 -d mysql:5.7

这条命令会启动一个 MySQL 5.7 容器，root 密码设置为 root，并且将容器的 3306 端口映射到宿主机的 3306 端口。

步骤 3: 创建 Nacos 所需的数据库和用户

登录到 MySQL 容器中，并创建一个数据库和用户供 Nacos 使用：

1

docker exec -it nacos-mysql mysql -uroot -p

输入密码后，执行以下 SQL 命令：

1

CREATE DATABASE nacos DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;CREATE USER 'nacos'@'%' IDENTIFIED BY 'nacos';GRANT ALL PRIVILEGES ON nacos.* TO 'nacos'@'%';FLUSH PRIVILEGES;EXIT;

步骤 4: 拉取并运行 Nacos 容器

接下来，拉取 Nacos 的官方 Docker 镜像并运行它，指定使用 MySQL 作为存储：

1

docker run --name nacos -e MODE=standalone -e MYSQL_SERVICE_HOST=nacos-mysql -e MYSQL_SERVICE_PORT=3306 -e MYSQL_SERVICE_DB_NAME=nacos -e MYSQL_SERVICE_USER=nacos -e MYSQL_SERVICE_PASSWORD=nacos -p 8848:8848 -d nacos/nacos-server:latest

这条命令会启动一个 Nacos 容器，配置为使用上面创建的 MySQL 数据库。MYSQL_SERVICE_HOST 应与 MySQL 容器的名称相同（这里是 nacos-mysql），而 MYSQL_SERVICE_PORT 是 MySQL 容器的端口（这里是 3306）。确保这些值与您在步骤 2 中设置的相匹配。

步骤 5: 验证 Nacos 是否正常运行

打开浏览器，访问 http://localhost:8848/nacos，默认用户名和密码都是 nacos。如果一切设置正确，您应该能够看到 Nacos 的管理界面。

通过以上步骤，您就可以在 Docker 中成功安装并运行 Nacos 服务器，使用 MySQL 作为其存储后端了。

在Docker环境中，容器间的通信是构建微服务架构的基础。使用容器名称进行连接相比直接使用IP地址具有显著优势。

一、为什么需要使用容器名称连接？

1. IP地址不稳定性问题：
   • 容器每次重启可能获得不同的IP地址（容器启动时会从子网中动态获取可用IP）
   • 在集群环境中IP地址变化更为频繁
   • 硬编码IP地址会导致连接失效

2. 管理复杂性降低：
   • 使用有意义的名称比记忆IP更直观
   • 无需维护IP地址映射表
   • 配置文件中使用名称更具可读性

3. 动态扩展支持：
   • 服务扩容时无需修改连接配置
   • 自动适应容器替换和迁移
   • 与负载均衡和服务发现机制更好配合

二、实现容器名称连接的核心条件

1. 必须使用自定义网络

Docker的默认bridge网络（docker0）不支持通过容器名称连接，只有自定义网络才提供内置DNS服务：

1
2

# 创建支持名称解析的自定义网络
docker network create my-app-network

2. 容器必须加入同一网络

所有需要互相通信的容器必须连接到同一个自定义网络：

1
2

docker run -d --name service-a --network my-app-network my-image
docker run -d --name service-b --network my-app-network my-image

三、实战演示：通过名称连接MySQL与应用

场景准备

假设我们需要部署一个Web应用连接MySQL数据库

步骤1：创建专用网络

1

docker network create app-network

步骤2：启动MySQL容器

1
2
3
4
5
6

docker run -d \
  --name mysql-db \
  --network app-network \
  -e MYSQL_ROOT_PASSWORD=secret \
  -e MYSQL_DATABASE=myapp \
  mysql:8.0

步骤3：启动应用容器

1
2
3
4
5
6
7

docker run -d \
  --name web-app \
  --network app-network \
  -e DB_HOST=mysql-db \
  -e DB_PASSWORD=secret \
  -p 8080:8080 \
  my-web-app

连接验证

在web-app容器中：

1
2
3
4
5
6

# 进入容器shell
docker exec -it web-app sh

# 测试连接MySQL
ping mysql-db  # 应能成功解析
nc -zv mysql-db 3306  # 检查端口连通性

四、特殊场景处理：1Panel环境下的网络集成

1Panel等管理面板会创建自己的网络（如1panel-network），需要将自定义容器加入该网络：

查看1Panel管理的MySQL网络

1

docker inspect 1Panel-mysql-Zhb7 | grep NetworkMode

将应用容器加入同一网络

1

docker network connect 1panel-network my-app-container

验证连接

1
2

# 在应用容器中测试
ping 1Panel-mysql-Zhb7

五、常见问题排查

1. 无法解析容器名：
   • 确认容器在同一自定义网络
   • 检查网络连接状态：docker network inspect <network>
   • 验证DNS解析：docker exec -it container-name nslookup target-name

2. 连接超时：
   • 检查目标服务是否监听正确端口
   • 验证防火墙/安全组设置
   • 测试基础连通性：ping和telnet

3. 1Panel环境特殊问题：
   • 确认容器已加入1panel-network
   • 检查1Panel的网络隔离策略
   • 查看1Panel的日志获取连接失败详情

六、踩坑记录

关于mysql的容器应用连接

在Java中使用Redis和RedisTemplate来统计当日访问量和访问人数（UV）是一个常见的需求。下面我将提供一个完整的实现方案。

1. 设计思路

• **访问量(PV)**：使用Redis的INCR命令统计总访问次数
• **访问人数(UV)**：使用Redis的HyperLogLog数据结构统计独立访客数
• 过期时间：设置当日24点自动过期

2. 实现代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91

import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.core.ValueOperations;
import org.springframework.stereotype.Service;

import java.time.LocalDate;
import java.time.ZoneId;
import java.time.ZonedDateTime;
import java.util.concurrent.TimeUnit;

@Service
public class VisitStatisticsService {

    private final RedisTemplate<String, String> redisTemplate;

    public VisitStatisticsService(RedisTemplate<String, String> redisTemplate) {
        this.redisTemplate = redisTemplate;
    }

    // 获取当日PV的key
    private String getTodayPVKey() {
        return "stat:pv:" + LocalDate.now().toString();
    }

    // 获取当日UV的key
    private String getTodayUVKey() {
        return "stat:uv:" + LocalDate.now().toString();
    }

    // 获取当天剩余的秒数（到24点的秒数）
    private long getRemainingSecondsToday() {
        ZonedDateTime now = ZonedDateTime.now(ZoneId.systemDefault());
        ZonedDateTime midnight = now.toLocalDate().plusDays(1).atStartOfDay(ZoneId.systemDefault());
        return midnight.toEpochSecond() - now.toEpochSecond();
    }

    /**
     * 记录访问
     * @param userId 用户ID（可以为IP地址或其他唯一标识）
     */
    public void recordVisit(String userId) {
        // 获取当天剩余的秒数
        long remainingSeconds = getRemainingSecondsToday();
        
        // 记录PV（访问量）
        ValueOperations<String, String> valueOps = redisTemplate.opsForValue();
        String pvKey = getTodayPVKey();
        valueOps.increment(pvKey);
        redisTemplate.expire(pvKey, remainingSeconds, TimeUnit.SECONDS);
        
        // 记录UV（独立访客）
        String uvKey = getTodayUVKey();
        redisTemplate.opsForHyperLogLog().add(uvKey, userId);
        redisTemplate.expire(uvKey, remainingSeconds, TimeUnit.SECONDS);
    }

    /**
     * 获取当日访问量(PV)
     */
    public Long getTodayPV() {
        String pvKey = getTodayPVKey();
        String value = redisTemplate.opsForValue().get(pvKey);
        return value == null ? 0L : Long.parseLong(value);
    }

    /**
     * 获取当日访问人数(UV)
     */
    public Long getTodayUV() {
        String uvKey = getTodayUVKey();
        return redisTemplate.opsForHyperLogLog().size(uvKey);
    }

    /**
     * 获取历史某天的访问量(PV)
     * @param date 日期
     */
    public Long getPVByDate(LocalDate date) {
        String pvKey = "stat:pv:" + date.toString();
        String value = redisTemplate.opsForValue().get(pvKey);
        return value == null ? 0L : Long.parseLong(value);
    }

    /**
     * 获取历史某天的访问人数(UV)
     * @param date 日期
     */
    public Long getUVByDate(LocalDate date) {
        String uvKey = "stat:uv:" + date.toString();
        return redisTemplate.opsForHyperLogLog().size(uvKey);
    }
}

3. 使用示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

@RestController
@RequestMapping("/api/visit")
public class VisitController {

    private final VisitStatisticsService visitStatisticsService;

    public VisitController(VisitStatisticsService visitStatisticsService) {
        this.visitStatisticsService = visitStatisticsService;
    }

    @GetMapping("/record")
    public String recordVisit(@RequestParam String userId) {
        visitStatisticsService.recordVisit(userId);
        return "Visit recorded for user: " + userId;
    }

    @GetMapping("/stats")
    public Map<String, Object> getStats() {
        Map<String, Object> result = new HashMap<>();
        result.put("pv", visitStatisticsService.getTodayPV());
        result.put("uv", visitStatisticsService.getTodayUV());
        return result;
    }
}

4. 设计说明

1. PV统计：
   • 使用简单的计数器（INCR命令）
   • 每个访问请求调用一次INCR
   • 键格式：stat:pv:yyyy-MM-dd

2. UV统计：
   • 使用HyperLogLog数据结构
   • 内存占用小（每个HyperLogLog约12KB）
   • 误差率约0.81%
   • 键格式：stat:uv:yyyy-MM-dd

3. 过期时间：
   • 自动计算到当天24点的剩余秒数
   • 设置键的过期时间
   • 避免数据无限增长

4. 扩展性：
   • 可以轻松扩展为按小时、周、月统计
   • 可以添加用户行为分析（如访问页面、停留时间等）

5. 性能优化

1. 批量操作：如果有批量记录需求，可以使用pipeline提高性能
2. 持久化：如果需要长期保存数据，可以定期将Redis数据持久化到数据库
3. 分布式：此方案天然支持分布式环境

6. 注意事项

1. HyperLogLog有约0.81%的误差率，如果要求精确计数，可以使用Set数据结构（但内存消耗更大）
2. Redis重启可能导致数据丢失，重要数据应考虑持久化方案
3. 在高并发场景下，INCR命令是原子操作，无需担心并发问题

这个实现方案简单高效，适合大多数Web应用的访问统计需求。

Cloudflare 的 5秒盾（Under Attack Mode）是网站防护的常见手段，通过 JavaScript 挑战验证访客真实性。很多网站会使用Cloudflare提供安全服务，导致爬虫的时候显示403状态。

一、解决方案及代码示例

1. 使用 cloudscraper 库

原理：模拟 Cloudflare 预期的请求特征

1
2
3
4
5

import cloudscraper

scraper = cloudscraper.create_scraper()
response = scraper.get("https://target-site.com")
print(response.text)

2. 使用 curl_cffi 库

优势：支持多浏览器指纹模拟

1
2
3
4
5
6
7

from curl_cffi import requests

response = requests.get(
    "https://target-site.com",
    impersonate="chrome110"  # 支持 chrome99-110 / edge99-110
)
print(response.text)

3. 第三方 API 服务

推荐服务：

• ScrapingBee（自带代理轮转）
• ScraperAPI
• ZenRows

1
2
3
4
5
6

import requests

API_KEY = "your_api_key"
response = requests.get(
    f"https://api.scrapingbee.com/v1/?api_key={API_KEY}&url=target-site.com"
)

4. FlareSolverr 服务

架构：基于 Puppeteer 的中间件服务

部署步骤：

1
2
3
4
5
6

docker run -d \
  --name flaresolverr \
  -p 8191:8191 \
  -e LOG_LEVEL=info \
  --restart unless-stopped \
  ghcr.io/flaresolverr/flaresolverr:latest

调用示例：

1
2
3
4
5
6
7
8

import requests

payload = {
    "cmd": "request.get",
    "url": "https://target-site.com",
    "maxTimeout": 60000
}
response = requests.post("http://localhost:8191/v1", json=payload)

二、方案对比分析

三、对抗升级建议

1. IP轮换策略：结合住宅代理使用（推荐 BrightData）
2. 指纹随机化：定期更换 User-Agent/TLS 指纹
3. 请求限速：设置 3-10 秒随机延迟
4. 头信息校验：携带完整 Accept-Encoding/Cookie 等头

RabbitMQ 常见面试题技术文档

一、基础概念

1. 什么是消息队列（Message Queue）？RabbitMQ 的核心作用是什么？

答案：
消息队列是一种异步通信机制，用于解耦生产者和消费者，实现系统间可靠的消息传递。
RabbitMQ 的核心作用包括：

• 异步处理：提升系统响应速度和吞吐量。
• 应用解耦：通过中间件隔离服务间的直接依赖。
• 流量削峰：缓冲突发流量，避免系统过载。
• 消息广播：支持一对多消息分发模式。

2. AMQP 协议是什么？RabbitMQ 如何基于 AMQP 工作？

答案：
AMQP（Advanced Message Queuing Protocol）是应用层协议，定义了消息中间件的统一通信标准。
RabbitMQ 基于 AMQP 模型：

• 生产者（Producer）发送消息到 Exchange。
• Exchange 根据路由规则（Binding Key）将消息分发到 Queue。
• 消费者（Consumer）从 Queue 中获取消息。

二、核心组件

3. RabbitMQ 的核心组件有哪些？

答案：

• Exchange：消息路由中心，决定消息如何分发到队列。
• Queue：存储消息的缓冲区，消费者从中订阅消息。
• Binding：定义 Exchange 和 Queue 之间的映射规则。
• Channel：复用 TCP 连接的轻量级通信通道。
• Virtual Host：逻辑隔离单元，类似命名空间。

4. Exchange 的四种类型及其区别？

答案：

三、消息机制

5. RabbitMQ 如何保证消息不丢失？

答案：

• 生产者确认模式（Publisher Confirm）：确保消息到达 Broker。
• 消息持久化：Exchange、Queue 和消息均设置为持久化（durable=true）。
• 消费者手动应答（Manual Acknowledgement）：消息处理完成后发送 ACK。

6. 什么是死信队列（Dead Letter Queue, DLQ）？如何触发？

答案：
死信队列用于存储无法被正常消费的消息。触发条件：

1. 消息被消费者拒绝（basic.reject 或 basic.nack）且不重新入队。
2. 消息 TTL（存活时间）过期。
3. 队列达到最大长度限制。

四、高级特性

7. 如何实现延迟队列？

答案：
RabbitMQ 原生不支持延迟队列，但可通过以下方式实现：

1. 消息 TTL + 死信队列：设置消息的 TTL，过期后转发到 DLQ。
2. 插件（如 rabbitmq-delayed-message-exchange）：使用延迟交换机。

8. 如何避免消息重复消费？

答案：

• 幂等性设计：业务逻辑天然支持重复处理（如数据库唯一约束）。
• 去重表：记录已处理消息的唯一标识（如消息 ID）。
• Redis 分布式锁：在消费前加锁。

五、可靠性与性能

9. RabbitMQ 的集群模式有哪些？

答案：

• 普通集群：队列元数据同步，但消息存储在单个节点（无高可用）。
• 镜像队列（Mirrored Queues）：队列数据跨节点复制，实现高可用。

10. 如何提升 RabbitMQ 的吞吐量？

答案：

• 批量发送（Batch Publish）。
• 多线程 Channel（避免单 Channel 阻塞）。
• 优化 ACK 机制：批量确认或异步确认。
• 调整预取数量（prefetchCount）提升消费者并发能力。

六、实战场景

11. 如何保证消息顺序性？

答案：

• 单队列单消费者：牺牲并发性保证顺序。
• 消息分组：通过 Routing Key 将需要顺序的消息路由到同一队列。

12. 设计一个秒杀系统时，如何用 RabbitMQ 应对瞬时高并发？

答案：

• 削峰填谷：将请求写入队列，后端服务按处理能力消费。
• 队列容量限制：避免内存溢出。
• 快速失败机制：队列满时直接拒绝新请求。

七、监控与管理

13. 如何监控 RabbitMQ 的运行状态？

答案：

• 管理界面：通过 Web UI 查看连接、队列、吞吐量等指标。
• 命令行工具：rabbitmqctl list_queues。
• Prometheus + Grafana：集成监控告警。

八、对比与其他中间件

14. RabbitMQ 与 Kafka 的核心区别是什么？

答案：

文档说明

本文档涵盖 RabbitMQ 的核心概念、工作机制及典型应用场景，适用于面试准备或技术方案设计参考。
持续更新建议：结合 RabbitMQ 官方文档（https://www.rabbitmq.com）和实际项目经验补充案例。

PS: 该内容由DeepSeek R1深度学习总结（deepseek牛逼！！！）

📝记录一下使用1panel作为服务器管理面板，之前基本是使用手搓命令构建服务，了解过宝塔面板，感觉太过臃肿且需要注册账户，后续考虑服务部署都是用1panel面板进行操作。

官方文档：https://1panel.cn/docs/

一、产品介绍

1Panel 是一个现代化、开源的 Linux 服务器运维管理面板。

二、安装部署

1. Ubuntu安装：

1

curl -sSL https://resource.fit2cloud.com/1panel/package/quick_start.sh -o quick_start.sh && sudo bash quick_start.sh

2. 通过访问地址和面板用户密码进行登录

三、功能使用

1. 前端页面创建网址后选择静态网址进行配置，后台选择反向代理

2. 通过网址设置配置HTTPS和设置NGINX

四、计划任务

可以通过linux定时任务自动执行shell等脚本命令

禅道项目管理工具提供了丰富的功能模块，包括任务管理、需求管理、Bug跟踪、版本控制、团队协作、项目报表等，这些功能覆盖了项目管理的各个方面。全面的功能模块使得项目团队可以在一个统一的平台上进行协同工作，无需再整合多个系统，从而提高了工作效率。

公司使用禅道来管理项目需求、进度以及Bug测试，新版禅道添加了很多功能，这里我搭建使用的是老版本12.5.3。

Docker拉取禅道镜像

1

docker pull idoop/zentao:12.5.3

运行禅道容器

1
2
3
4
5

docker run --privileged=true -d -p 8082:80 -p 3316:3306 \
        -e ADMINER_USER="admin" -e ADMINER_PASSWD="123456" \
        -v /dockerdatafile/chandao/:/opt/zbox/ \
        --name zentao-server \
        idoop/zentao:12.5.3

参数说明：

• ADMINER_USER：指定禅道管理员账号

• ADMINER_PASSWD：指定禅道管理员首次登录密码

访问禅道

浏览器访问宿主机器地址加8082端口，登录使用用户名 admin，密码 123456

使用1Panel创建网站

可通过域名进行访问