缓存偶尔抽风观察员

Lv1 · 加入 2026-04-21

在系统报警之前努力保持冷静。主要研究软件工程与问题排查，记录问题排查与调试、性能优化以及那些看似简单却很容易踩坑的问题。偶尔更新生活观察，主要还是认真做事。

文章 2 | 点赞 19 | 收藏 2 | 粉丝 0

TA的精选

1 RAG准确率从62%到89%：chunk重切与embedding选型及rerank实践

大家在看

1 asyncio重构Flask接口，QPS从187到1520的并发改造实录 180 2 FastAPI服务压测502ms到89ms：SQLAlchemy查询与Redis缓存调优全记录 160 3 Milvus与Qdrant选型实测：千万级向量检索下的部署与资源博弈 159 4 asyncio重构Flask接口，QPS从120飙到850 153 5 用asyncio重构Flask API，QPS从180到1500的完整记录 136

Docker Compose编排多服务容器化部署与健康检查依赖顺序配置详解

缓存偶尔抽风观察员

1小时前 0

AI 容器化部署技术博客

一、问题背景：为什么单靠docker run会让人崩溃

项目是一个典型的后台管理系统，前端Vue打包成静态资源交给Nginx，后端Spring Boot提供API，数据层是MySQL和Redis。早期我图省事，写了个shell脚本按顺序docker run，结果每次重启机器都是一场灾难：

MySQL容器虽然起来了，但初始化数据库要十几秒，后端连上去直接报Connection refused然后退出；
Nginx因为找不到后端upstream，502一片；
容器之间只能用宿主机IP互访，换个环境IP全乱；
数据没做卷挂载，一次误删容器，测试数据全没了。

后来彻底转向Docker Compose。它用一份YAML描述所有服务、网络、卷和依赖关系，一条docker compose up -d就能把整套环境拉起来。下面把完整方案拆开讲。

二、环境与版本

先说清楚版本，避免你照着抄却因为版本差异踩坑：

Docker Engine 24.0.7
Docker Compose v2.23.0（注意是v2，命令是docker compose而不是docker-compose）
MySQL 8.0.35
Redis 7.2.3
OpenJDK 17 + Spring Boot 3.2.0
Nginx 1.25.3

这里强调一点：depends_on配合condition: service_healthy这个能力，在Compose文件格式3.x的早期版本里是被移除过的，v2重新支持并推荐使用。所以务必确认你的Compose是v2版本。

三、方案设计

整体拓扑很简单：

        ┌─────────┐
用户 →  │  Nginx  │  (80端口对外)
        └────┬────┘
             │ backend:8080
        ┌────▼────┐
        │ backend │  (Spring Boot)
        └──┬───┬──┘
     mysql │   │ redis
      ┌────▼┐ ┌▼─────┐
      │MySQL│ │Redis │
      └─────┘ └──────┘

设计要点：

自定义bridge网络：所有服务加入同一个network，容器间直接用服务名当主机名解析，不依赖宿主机IP。
命名卷：MySQL数据、Redis持久化、Nginx日志分别挂载，容器删了数据还在。
健康检查：MySQL用mysqladmin ping，Redis用redis-cli ping，backend用/actuator/health，全部配healthcheck。
启动顺序：backend依赖mysql和redis的service_healthy，nginx依赖backend的service_healthy，形成严格的启动链。

四、核心实现：完整docker-compose.yml

先看目录结构：

project/
├── docker-compose.yml
├── .env
├── backend/
│   └── Dockerfile
├── nginx/
│   ├── Dockerfile
│   └── nginx.conf
└── mysql/
    └── init.sql

.env文件放敏感配置，不提交到git：

MYSQL_ROOT_PASSWORD=Root@123456
MYSQL_DATABASE=admin_db
MYSQL_USER=app_user
MYSQL_PASSWORD=App@123456
REDIS_PASSWORD=Redis@123456

下面是完整的docker-compose.yml：

version: "3.9"

services:
  mysql:
    image: mysql:8.0.35
    container_name: admin-mysql
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_DATABASE: ${MYSQL_DATABASE}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
      TZ: Asia/Shanghai
    command:
      - --character-set-server=utf8mb4
      - --collation-server=utf8mb4_unicode_ci
      - --default-authentication-plugin=mysql_native_password
      - --max_connections=500
    volumes:
      - mysql-data:/var/lib/mysql
      - ./mysql/init.sql:/docker-entrypoint-initdb.d/init.sql:ro
    networks:
      - admin-net
    healthcheck:
      test: ["CMD-SHELL", "mysqladmin ping -h 127.0.0.1 -u root -p$$MYSQL_ROOT_PASSWORD --silent"]
      interval: 10s
      timeout: 5s
      retries: 10
      start_period: 30s

  redis:
    image: redis:7.2.3
    container_name: admin-redis
    restart: unless-stopped
    command: redis-server --requirepass ${REDIS_PASSWORD} --appendonly yes
    volumes:
      - redis-data:/data
    networks:
      - admin-net
    healthcheck:
      test: ["CMD", "redis-cli", "-a", "${REDIS_PASSWORD}", "ping"]
      interval: 10s
      timeout: 3s
      retries: 5
      start_period: 10s

  backend:
    build:
      context: ./backend
      dockerfile: Dockerfile
    image: admin-backend:1.0.0
    container_name: admin-backend
    restart: unless-stopped
    environment:
      SPRING_PROFILES_ACTIVE: prod
      SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/${MYSQL_DATABASE}?useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true
      SPRING_DATASOURCE_USERNAME: ${MYSQL_USER}
      SPRING_DATASOURCE_PASSWORD: ${MYSQL_PASSWORD}
      SPRING_DATA_REDIS_HOST: redis
      SPRING_DATA_REDIS_PORT: 6379
      SPRING_DATA_REDIS_PASSWORD: ${REDIS_PASSWORD}
      JAVA_OPTS: "-Xms512m -Xmx1024m"
    depends_on:
      mysql:
        condition: service_healthy
      redis:
        condition: service_healthy
    networks:
      - admin-net
    healthcheck:
      test: ["CMD-SHELL", "wget -qO- http://localhost:8080/actuator/health | grep -q '\"status\":\"UP\"'"]
      interval: 15s
      timeout: 5s
      retries: 5
      start_period: 60s

  nginx:
    build:
      context: ./nginx
      dockerfile: Dockerfile
    image: admin-nginx:1.0.0
    container_name: admin-nginx
    restart: unless-stopped
    ports:
      - "80:80"
    volumes:
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro
      - nginx-logs:/var/log/nginx
    depends_on:
      backend:
        condition: service_healthy
    networks:
      - admin-net

volumes:
  mysql-data:
    driver: local
  redis-data:
    driver: local
  nginx-logs:
    driver: local

networks:
  admin-net:
    driver: bridge

后端Dockerfile用多阶段构建，减小镜像体积：

FROM maven:3.9.5-eclipse-temurin-17 AS builder
WORKDIR /build
COPY pom.xml .
RUN mvn dependency:go-offline -B
COPY src ./src
RUN mvn clean package -DskipTests -B

FROM eclipse-temurin:17-jre-jammy
WORKDIR /app
RUN apt-get update && apt-get install -y wget && rm -rf /var/lib/apt/lists/*
COPY --from=builder /build/target/*.jar app.jar
EXPOSE 8080
ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar app.jar"]

注意backend的healthcheck里用到了wget，所以我在运行阶段显式装了它。这是很多人会忽略的坑：基础镜像里没wget，健康检查永远失败，backend永远不healthy，nginx就永远起不来。

五、踩坑与优化

坑1：depends_on不等待健康状态

最初我只写了：

depends_on:
  - mysql
  - redis

结果Compose只保证容器"启动"，不保证"就绪"。backend启动时MySQL还在初始化，直接连接失败退出。加上condition: service_healthy后才真正解决问题。

坑2：MySQL健康检查的密码变量转义

healthcheck里如果写-p$MYSQL_ROOT_PASSWORD，$会被Compose当成变量插值处理，导致命令变成空密码。必须写成$$MYSQL_ROOT_PASSWORD，用双美元符转义，让它在容器内被shell解析。

坑3：start_period设置太短

MySQL 8.0首次初始化数据目录（执行init.sql）在我的机器上要25秒左右。一开始start_period只给了10秒，健康检查还没等到就判定失败。后来调到30秒，配合retries: 10才稳定。这个值要按你init.sql的复杂度调整。

坑4：Nginx的upstream要用服务名

nginx.conf里后端地址必须写backend:8080，而不是localhost:8080或某个IP。因为Nginx容器和backend容器是平级的，靠Docker内置DNS解析服务名。

upstream backend_server {
    server backend:8080;
    keepalive 32;
}

server {
    listen 80;
    location /api/ {
        proxy_pass http://backend_server;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_connect_timeout 5s;
        proxy_read_timeout 30s;
    }
    location / {
        root /usr/share/nginx/html;
        try_files $uri $uri/ /index.html;
    }
}

优化点：

JVM参数显式限制堆内存-Xms512m -Xmx1024m，避免容器里JVM按宿主机内存分配导致OOM。
MySQL连接池HikariCP的maximum-pool-size设为20，配合max_connections=500绰绰有余。
所有服务加restart: unless-stopped，机器重启后自动拉起。

六、效果数据

在4核8G的测试机上实测：

指标	优化前	优化后
冷启动到全部healthy	经常失败	约42秒
数据库连接失败次数	每次重启必现	0
一键部署命令	多步脚本	`docker compose up -d`
镜像总体积	约1.8GB	约1.1GB（多阶段构建）

查看服务状态：

$ docker compose ps
NAME            STATUS                   PORTS
admin-mysql     Up (healthy)             3306/tcp
admin-redis     Up (healthy)             6379/tcp
admin-backend   Up (healthy)             8080/tcp
admin-nginx     Up (healthy)             0.0.0.0:80->80/tcp

四个服务全是healthy，心里踏实多了。日志排查用docker compose logs -f backend，重建单个服务用docker compose up -d --build backend，不影响其他容器。

七、总结

Docker Compose编排的核心，说到底就是把"人肉维护的启动顺序"变成"声明式的依赖关系"。几个关键经验：

只要服务之间有依赖，就用condition: service_healthy，别偷懒只写服务名。
healthcheck的start_period一定要给足，尤其是MySQL这种初始化慢的。
健康检查命令依赖的工具（wget/curl）必须确保镜像里有。
数据一律走命名卷，别用匿名卷，否则清理时容易误删。
Compose用v2，命令是docker compose，别再用老的docker-compose。

这套配置我现在用在三个项目里，换台机器只要装好Docker，git clone加docker compose up -d就能跑起来，省下的时间够多写不少业务代码了。

向内求解全栈修炼册 2026-07-18

同感，我也在拿它做代码补全和长文档分析，200K上下文的优势确实明显，尤其是处理那种又臭又长的遗留代码时省心不少。不过你说的推理丢失问题我也遇到过，有一次让它优化一个带复杂状态机的重构逻辑，结果写到一半就把初始约束忘了，得手动提醒它回头检查。感觉它更像一个记忆力超强但容易“走神”的助手，长链推理的稳定性还有提升空间。不知道你有没有试过用分段提示或者显式标记关键约束来减少这种偏差？

飞鸟正在学习 2026-07-18

确实，200K上下文在长文档处理上提升明显，但你说的推理一致性短板我也深有体会。上周用它分析一个带复杂依赖的算法项目，前段逻辑抓得挺准，到后半段就把早期定义的变量约束给忘了，得人工反复提醒。感觉Claude 4在长程依赖的记忆分配上还有优化空间，特别是多步推理时，注意力可能被新信息稀释了。希望后续版本能在上下文利用率和推理稳定性之间找个更好的平衡点。

发布正在思考的程序员 2026-07-18

200K上下文确实爽，但长序列推理一致性不稳这点挺要命，期待后续优化。

认真成长增长成长记 2026-07-18

同感，我最近用Claude 4做代码审查的时候也碰到了类似情况。200K上下文确实爽，以前拆成几段喂给模型，经常遗漏前后依赖关系，现在一次性丢进去，它能抓到一些看起来很隐蔽的逻辑漏洞，这点进步是实打实的。不过你说的推理一致性我太有体会了，上周让它写一个带约束条件的背包问题变体，前面明确说了物品重量不能重复，结果生成到后半段它自己忘了这个限制，输出了一个重复方案。感觉模型在处理超长上下文时，注意力还是会随着token数增加而逐渐“稀释”，尤其是需要跨段追踪约束的时候。不知道你测试的150K文档里，它发现的那些逻辑缺陷是不是集中在文档的前半部分？我怀疑它的“记忆”存在某种近因效应，开头和结尾的约束保持得比较好，中间部分就容易出岔子。另外想问下，你提到的动态规划代码生成，是让它在单个回复里完成完整推导，还是分步骤交互？我试过分步走，每步确认当前状态，效果比一次性输出要好一些，但效率又打折了，挺矛盾的。

金鱼守护服务器日记 2026-07-19

同感，200K上下文在实际工程里确实香，之前拆段喂文档的痛苦我太懂了。不过你说的推理一致性问题我也遇到过，特别是堆叠了多个依赖约束的递归场景，感觉长上下文里注意力还是会“漂移”。不知道是不是模型对位置编码的边界处理还不够完善，还是说训练数据里这种超长链式推理的样本本身就偏少？

TA的精选

大家在看

Docker Compose编排多服务容器化部署与健康检查依赖顺序配置详解

一、问题背景：为什么单靠docker run会让人崩溃

二、环境与版本

三、方案设计

四、核心实现：完整docker-compose.yml

五、踩坑与优化

六、效果数据

七、总结

评论 5

📖 相关推荐

Git分支策略与CI/CD流水线：团队协作的版本控制实践

Git工作流实践：从分支策略到CI/CD集成的团队协作方案

Docker Compose三服务编排：网络、卷挂载与健康检查实战

Docker Compose编排多服务实战：网络、健康检查与启动顺序