FastAPI Agent生产部署：Nginx+Uvicorn+Redis全链路交付实战

1. 这不是“上线”而是“交付闭环”：Agent Service 部署的本质是什么

你点开这个标题，大概率正卡在某个深夜——本地跑通的 FastAPI Agent 服务，在服务器上死活不响应；或者刚配好 Redis，redis-cli ping返回PONG，但 FastAPI 日志里却疯狂报ConnectionRefusedError；又或者 Nginx 转发后接口返回 502，查了一圈发现是uvicorn进程根本没起来。别急，这不是你技术不行，而是绝大多数人把“部署上线”误解成了“复制粘贴命令”，而它真实面目是一条横跨开发、运维、网络、安全四层的交付流水线。

Agent Service 的核心价值从来不在代码本身，而在它能否稳定、低延迟、可扩展地响应外部请求。一个没经过生产级部署的 Agent，就像一辆没上过高速的赛车——引擎再强，也跑不出赛道。FastAPI 是它的动力系统，Redis 是它的短期记忆中枢，Nginx 是它的交通调度员，Linux 环境是它的底盘和悬挂。这四个模块任何一个参数松动，整辆车就会跑偏、抖动甚至抛锚。我见过太多团队花三周写完智能体逻辑，却用两周反复重装 Redis、调试 Nginx 超时、排查 SELinux 权限，最后上线时间一拖再拖。问题不在工具，而在对“部署”这件事的认知偏差：它不是开发的终点，而是服务生命周期的真正起点。

所以本章不讲“怎么把代码扔到服务器”，而是带你亲手构建一条可验证、可回滚、可监控的交付链路。你会看到：为什么pip install redis在 Windows 上能跑通，放到 CentOS 8 就报ModuleNotFoundError；为什么redis-server命令能执行，但 FastAPI 却连不上localhost:6379；为什么 Nginx 配置了proxy_pass http://127.0.0.1:8000，浏览器却提示502 Bad Gateway。每一个报错背后，都是操作系统、网络栈、进程管理、权限模型四者在暗中博弈。我们不绕开这些博弈，而是把它们摊开、拆解、实测，让你下次遇到Connection refused时，第一反应不是重启服务，而是打开ss -tuln | grep 6379查端口监听状态。

关键词里的linux deploy 操作环境更新错误不是偶然——它直指痛点：Linux 发行版差异、Python 版本兼容性、系统级依赖缺失。fastapi redis组合看似简单，实则埋着三道深坑：第一道是 Redis 的持久化策略与 Agent 状态缓存的语义冲突；第二道是 FastAPI 异步事件循环与 Redis 连接池的生命周期绑定；第三道是 Nginx 反向代理下 WebSocket 升级头（Upgrade, Connection）的透传配置。这些坑不会在本地开发环境暴露，只会在生产流量压上来时集中爆发。所以本章所有操作，都基于真实压测场景设计：我们用wrk -t4 -c100 -d30s http://localhost/agent/chat模拟并发请求，观察 Redis 内存增长曲线、Uvicorn 进程 CPU 占用、Nginx upstream 失败率三者的实时联动。这才是部署该有的样子——不是“能跑”，而是“跑得稳、看得清、调得准”。

2. 部署架构设计：为什么必须用 Nginx + Uvicorn + Redis 三层结构

2.1 单进程模式的致命缺陷：从uvicorn main:app --reload到生产环境的断崖式落差

很多开发者第一次部署 FastAPI，习惯性地把开发命令uvicorn main:app --reload --host 0.0.0.0 --port 8000直接丢进服务器后台运行。这就像开着敞篷跑车去跑拉力赛——表面看没问题，实际每过一个坑洼，底盘都在报警。--reload参数依赖文件系统 inotify 机制，在 Docker 容器或某些 Linux 发行版（如 Alpine）中默认禁用；--host 0.0.0.0暴露所有网卡，若未配防火墙规则，等于把服务直接挂在公网；更关键的是，单个 Uvicorn 进程无法利用多核 CPU，当并发请求超过 200，响应延迟会呈指数级上升。我实测过：在 4 核 8G 的云服务器上，纯 Uvicorn 进程处理 300 并发时，P95 延迟从 80ms 暴涨到 1.2s，且内存占用持续攀升至 2.1G 后 OOM 被 kill。

提示：--reload仅用于开发阶段。生产环境必须关闭，改用进程管理器（如 systemd 或 supervisor）实现自动重启，否则文件监控会消耗大量系统资源，且无法优雅处理 SIGTERM 信号。

真正的生产架构必须分层：Uvicorn 专注处理 HTTP 请求解析与 ASGI 协议转换，Nginx 承担 SSL 终止、静态文件服务、负载均衡、请求限流、日志聚合等通用能力，Redis 独立承担状态缓存与消息队列。这种分离不是为了炫技，而是为了解耦故障域。当 Agent 业务逻辑出现死循环导致 Uvicorn 进程卡死时，Nginx 仍能返回 503 服务不可用页面，并通过健康检查自动将流量切到备用实例；当 Redis 因内存不足触发 LRU 驱逐时，FastAPI 层可通过降级策略（如返回缓存副本或空结果）避免雪崩。三层之间用明确的协议边界隔离：Uvicorn 与 Nginx 通过 HTTP/1.1 通信，Uvicorn 与 Redis 通过 RESP 协议通信，各层可独立升级、扩容、监控。

2.2 Redis 选型深度解析：为什么不用 SQLite 做缓存？为什么不用 Memcached？

看到redis关键词堆砌，很多人下意识认为“缓存就用 Redis”。但 Agent Service 对缓存的需求远超基础 KV 存储。我们来对比三个典型场景：

• 会话状态同步：多个 Uvicorn 实例需共享用户对话上下文。SQLite 是文件锁模型，多进程写入必然阻塞；Memcached 不支持数据持久化，机器重启后所有会话丢失；Redis 的SET key value EX 3600命令天然支持带过期时间的分布式锁，配合INCR原子计数器，可精确控制每个用户的并发请求数。

• 任务队列解耦：Agent 执行耗时操作（如调用大模型 API）时，不能阻塞 HTTP 请求线程。Redis 的LPUSH/BRPOP命令构成轻量级任务队列，Uvicorn 接收请求后立即LPUSH agent:queue {"task_id": "xxx", "prompt": "..."}，后台 worker 进程BRPOP监听队列并异步执行，再将结果SET agent:result:xxx "response"。整个过程无外部依赖，比 RabbitMQ 部署简单 10 倍。

• 发布订阅广播：当 Agent 配置更新时，需通知所有在线实例刷新本地缓存。Redis 的PUBLISH config:update '{"version": "2.1"}'命令可让所有订阅config:*通道的 Uvicorn 进程实时收到通知，避免轮询数据库带来的性能损耗。

注意：Redis 默认配置极度危险！bind 127.0.0.1必须改为bind 127.0.0.1 ::1支持 IPv6；protected-mode yes开启保护模式防止未授权访问；requirepass必须设置强密码（至少 16 位含大小写字母+数字+符号），否则黑客可通过redis-cli -h your-server flushall一键清空所有数据。

2.3 Nginx 配置的隐藏陷阱：为什么proxy_pass http://127.0.0.1:8000会失败？

Nginx 配置看似简单，但proxy_pass指令背后藏着五个关键参数，缺一不可：

1. proxy_set_header Host $host;：不加此行，Uvicorn 收到的request.url.hostname会变成127.0.0.1，导致生成的绝对 URL（如 Webhook 回调地址）错误；
2. proxy_set_header X-Real-IP $remote_addr;：获取真实客户端 IP，否则所有请求日志显示为127.0.0.1；
3. proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;：处理多层代理时的 IP 追踪；
4. proxy_set_header X-Forwarded-Proto $scheme;：告诉后端当前是 HTTP 还是 HTTPS，避免重定向循环；
5. proxy_http_version 1.1;：启用 HTTP/1.1 持久连接，减少 TCP 握手开销。

更隐蔽的坑在超时配置。Agent Service 常有长耗时操作（如流式响应大模型输出），若proxy_read_timeout默认 60 秒，用户等待 61 秒就会收到 Nginx 的 504 Gateway Timeout。正确做法是根据业务 SLA 设置：proxy_connect_timeout 5s; proxy_send_timeout 300s; proxy_read_timeout 300s;。同时必须配置proxy_buffering off;关闭缓冲，否则流式响应会被 Nginx 缓存直到整个响应结束才吐给前端。

3. 全流程实操：从零搭建高可用 Agent Service 部署环境

3.1 Linux 环境初始化：CentOS 8 与 Ubuntu 22.04 的关键差异处理

部署第一步不是写代码，而是驯服操作系统。不同发行版的包管理、默认 Python 版本、SELinux 策略差异巨大，必须针对性处理：

CentOS 8（已 EOL，但企业仍在用）：

# 关闭 firewalld（避免端口拦截干扰） sudo systemctl stop firewalld sudo systemctl disable firewalld # 安装 EPEL 源（提供最新 Python 包） sudo dnf install epel-release -y # 安装 Python 3.9（CentOS 8 默认 3.6，不支持 FastAPI 0.100+） sudo dnf module install python39 -y # 创建虚拟环境（强制指定 Python 解释器路径） python3.9 -m venv /opt/agent-env source /opt/agent-env/bin/activate # 升级 pip（避免 wheel 构建失败） pip install --upgrade pip

Ubuntu 22.04：

# 更新系统并安装基础依赖 sudo apt update && sudo apt upgrade -y sudo apt install python3.10-venv python3.10-dev build-essential libpq-dev -y # 创建虚拟环境（注意 Python 版本号） python3.10 -m venv /opt/agent-env source /opt/agent-env/bin/activate # 安装编译依赖（否则 uvloop 编译失败） sudo apt install libffi-dev libssl-dev -y

实操心得：永远不要用系统自带的python3命令创建虚拟环境！CentOS 8 的python3指向 3.6，Ubuntu 22.04 指向 3.10，版本错配会导致pip install fastapi报ERROR: Could not find a version that satisfies the requirement pydantic<2.0,>=1.8.2。必须显式指定python3.9或python3.10。

3.2 Redis 部署：从源码编译到生产级配置加固

Windows 用户常通过redis-x64-5.0.14.msi一键安装，但 Linux 生产环境必须源码编译，原因有三：第一，官方预编译二进制可能含旧版 OpenSSL 漏洞；第二，可自定义编译选项（如启用 TLS）；第三，便于统一管理启动脚本。以下是 CentOS 8 编译步骤：

# 下载 Redis 7.2.4（最新稳定版） cd /tmp curl -O https://download.redis.io/releases/redis-7.2.4.tar.gz tar xzf redis-7.2.4.tar.gz cd redis-7.2.4 # 编译（启用 TLS 支持，禁用测试套件节省时间） make BUILD_TLS=yes MALLOC=libc # 安装到 /usr/local/bin sudo make install # 创建配置目录 sudo mkdir -p /etc/redis /var/lib/redis /var/log/redis # 生成生产配置文件 /etc/redis/redis.conf cat << 'EOF' | sudo tee /etc/redis/redis.conf bind 127.0.0.1 ::1 protected-mode yes port 6379 tcp-backlog 511 timeout 0 tcp-keepalive 300 daemonize yes supervised systemd pidfile /var/run/redis_6379.pid loglevel notice logfile /var/log/redis/redis.log databases 16 always-show-logo no set-proc-title yes proc-title-template "{title} {listen-addr} {server-mode}" stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes dbfilename dump.rdb rdb-del-sync-files no dir /var/lib/redis replica-serve-stale-data yes replica-read-only yes repl-diskless-sync no repl-diskless-sync-delay 5 repl-disable-tcp-nodelay no replica-priority 100 acllog-max-len 128 lazyfree-lazy-eviction no lazyfree-lazy-expire no lazyfree-lazy-server-del no replica-lazy-flush no lazyfree-lazy-user-del no oom-score-adj no oom-score-adj-values 0 200 800 disable-thp yes appendonly no appendfilename "appendonly.aof" appendfsync everysec no-appendfsync-on-rewrite no auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb aof-load-truncated yes aof-use-rdb-preamble yes lua-time-limit 5000 slowlog-log-slower-than 10000 slowlog-max-len 128 latency-monitor-threshold 0 notify-keyspace-events "" hash-max-ziplist-entries 512 hash-max-ziplist-value 64 list-max-ziplist-size -2 list-compress-depth 0 set-max-intset-entries 512 zset-max-ziplist-entries 128 zset-max-ziplist-value 64 hll-sparse-max-bytes 3000 stream-node-max-bytes 4096 stream-node-max-entries 100 activerehashing yes client-output-buffer-limit normal 0 0 0 client-output-buffer-limit replica 256mb 64mb 60 client-output-buffer-limit pubsub 32mb 8mb 60 hz 10 dynamic-hz yes aof-rewrite-incremental-fsync yes rdb-save-incremental-fsync yes requirepass your_strong_password_here EOF # 创建 systemd 服务文件 sudo tee /etc/systemd/system/redis.service << 'EOF' [Unit] Description=Redis In-Memory Data Store After=network.target [Service] Type=notify User=redis Group=redis ExecStart=/usr/local/bin/redis-server /etc/redis/redis.conf ExecStop=/usr/local/bin/redis-cli -h 127.0.0.1 -p 6379 shutdown Restart=always RestartSec=10 LimitNOFILE 65535 ReadWriteDirectories=/var/lib/redis /var/log/redis [Install] WantedBy=multi-user.target EOF # 创建 redis 用户并授权 sudo useradd -r -s /bin/false redis sudo chown -R redis:redis /var/lib/redis /var/log/redis /etc/redis sudo chmod 755 /var/lib/redis # 启动服务 sudo systemctl daemon-reload sudo systemctl enable redis sudo systemctl start redis # 验证 redis-cli -a your_strong_password_here ping # 应返回 PONG

注意：requirepass密码必须用单引号包裹，否则 bash 会解析特殊字符；ReadWriteDirectories必须显式声明，否则 SELinux 会阻止 Redis 写入日志目录。

3.3 FastAPI Agent 服务部署：Uvicorn + Gunicorn 的黄金组合

单用 Uvicorn 无法应对突发流量，必须搭配 Gunicorn 做进程管理。Gunicorn 负责 fork 多个工作进程，Uvicorn 作为 worker 处理具体请求，两者结合既保证并发能力，又避免单点故障：

# 激活虚拟环境 source /opt/agent-env/bin/activate # 安装核心依赖 pip install fastapi uvicorn gunicorn redis python-dotenv # 创建项目目录 sudo mkdir -p /opt/agent-service sudo chown $USER:$USER /opt/agent-service cd /opt/agent-service # 创建 .env 文件（敏感信息外置） cat << 'EOF' > .env REDIS_URL=redis://:your_strong_password_here@127.0.0.1:6379/0 AGENT_ENV=production LOG_LEVEL=INFO EOF # 创建主应用文件 main.py cat << 'EOF' > main.py from fastapi import FastAPI, HTTPException, Depends from pydantic import BaseModel import redis import json import os from typing import Optional app = FastAPI(title="Agent Service", version="1.0") # 从环境变量读取 Redis 配置 redis_url = os.getenv("REDIS_URL") if not redis_url: raise RuntimeError("REDIS_URL not set in environment") # 初始化 Redis 连接池 redis_client = redis.from_url(redis_url, decode_responses=True, socket_connect_timeout=5, socket_timeout=5) class ChatRequest(BaseModel): user_id: str message: str class ChatResponse(BaseModel): response: str status: str = "success" @app.post("/agent/chat", response_model=ChatResponse) async def chat_endpoint(request: ChatRequest): try: # 模拟 Agent 处理逻辑（实际替换为你的 LLM 调用） cache_key = f"chat:{request.user_id}" cached_response = redis_client.get(cache_key) if cached_response: return ChatResponse(response=cached_response) # 生成响应（此处为模拟） response_text = f"Hello {request.user_id}! You said: {request.message}" redis_client.setex(cache_key, 3600, response_text) # 缓存 1 小时 return ChatResponse(response=response_text) except redis.ConnectionError as e: raise HTTPException(status_code=503, detail=f"Redis connection failed: {str(e)}") except Exception as e: raise HTTPException(status_code=500, detail=f"Internal server error: {str(e)}") @app.get("/health") def health_check(): try: redis_client.ping() return {"status": "healthy", "redis": "connected"} except Exception as e: return {"status": "unhealthy", "redis": "disconnected", "error": str(e)} EOF # 创建 Gunicorn 配置文件 gunicorn.conf.py cat << 'EOF' > gunicorn.conf.py import multiprocessing import os # 绑定配置 bind = "127.0.0.1:8000" bind_address = "127.0.0.1:8000" bind_port = 8000 backlog = 2048 # 工作进程 workers = multiprocessing.cpu_count() * 2 + 1 worker_class = "uvicorn.workers.UvicornWorker" worker_connections = 1000 max_requests = 1000 max_requests_jitter = 100 # 超时设置 timeout = 300 keepalive = 5 graceful_timeout = 30 # 日志配置 accesslog = "/var/log/agent/access.log" errorlog = "/var/log/agent/error.log" loglevel = "info" access_log_format = '%(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%(a)s"' # 进程管理 daemon = False pidfile = "/var/run/agent.pid" umask = 0o007 user = "www-data" group = "www-data" tmp_upload_dir = "/tmp" # 安全配置 secure_scheme_headers = {"X-FORWARDED-PROTO": "https"} forwarded_allow_ips = "*" EOF # 创建 systemd 服务文件 sudo tee /etc/systemd/system/agent.service << 'EOF' [Unit] Description=Agent Service After=network.target redis.service [Service] Type=simple User=www-data Group=www-data WorkingDirectory=/opt/agent-service EnvironmentFile=/opt/agent-service/.env ExecStart=/opt/agent-env/bin/gunicorn -c /opt/agent-service/gunicorn.conf.py main:app Restart=always RestartSec=10 LimitNOFILE=65535 StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target EOF # 创建日志目录 sudo mkdir -p /var/log/agent sudo chown www-data:www-data /var/log/agent # 启动服务 sudo systemctl daemon-reload sudo systemctl enable agent sudo systemctl start agent # 验证 curl http://127.0.0.1:8000/health # 应返回 JSON 健康状态

实操心得：worker_class = "uvicorn.workers.UvicornWorker"是关键！它让 Gunicorn 使用 Uvicorn 的 ASGI worker，而非默认的 sync worker，这样才能发挥 FastAPI 异步优势。max_requests = 1000防止内存泄漏累积，graceful_timeout = 30确保进程优雅退出。

3.4 Nginx 反向代理配置：支持 HTTPS 与 WebSocket 的完整方案

Nginx 配置必须覆盖三大场景：HTTP/HTTPS 流量转发、WebSocket 连接升级、静态资源托管。以下是/etc/nginx/conf.d/agent.conf完整内容：

upstream agent_backend { server 127.0.0.1:8000; # 若有多台服务器，可添加 backup 选项 # server 192.168.1.101:8000 backup; } server { listen 80; server_name your-domain.com; # HTTP 重定向到 HTTPS return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; server_name your-domain.com; # SSL 证书（使用 Let's Encrypt） ssl_certificate /etc/letsencrypt/live/your-domain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem; ssl_trusted_certificate /etc/letsencrypt/live/your-domain.com/chain.pem; # SSL 安全配置 ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers off; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; # HSTS（强制 HTTPS） add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; # 日志配置 access_log /var/log/nginx/agent_access.log; error_log /var/log/nginx/agent_error.log; # 根路径代理 location / { proxy_pass http://agent_backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Host $server_name; proxy_set_header X-Forwarded-Port $server_port; # 超时设置 proxy_connect_timeout 5s; proxy_send_timeout 300s; proxy_read_timeout 300s; # 缓冲区设置（关键！） proxy_buffering off; proxy_buffer_size 128k; proxy_buffers 4 256k; proxy_busy_buffers_size 256k; # WebSocket 支持 proxy_set_header Sec-WebSocket-Key $http_sec_websocket_key; proxy_set_header Sec-WebSocket-Extensions $http_sec_websocket_extensions; proxy_set_header Sec-WebSocket-Version $http_sec_websocket_version; } # 健康检查端点（不走代理，直接返回） location /health { return 200 '{"status":"ok"}'; add_header Content-Type application/json; } # 静态文件（如 Swagger UI） location /static { alias /opt/agent-service/static/; expires 1h; add_header Cache-Control "public, immutable"; } }

提示：proxy_buffering off;必须开启！否则 FastAPI 的流式响应（如 Server-Sent Events）会被 Nginx 缓存，直到整个响应结束才发送给前端，彻底失去流式意义。proxy_set_header Upgrade $http_upgrade;和Connection "upgrade";是 WebSocket 升级的关键，缺少任一都会导致WebSocket connection to 'wss://...' failed: Error during WebSocket handshake。

4. 常见问题与排查技巧实录：那些让你熬夜到凌晨三点的真问题

4.1 Redis 连接失败的五层排查法

当redis-cli -a password ping返回PONG，但 FastAPI 日志却报ConnectionRefusedError: [Errno 111] Connection refused，问题一定出在连接路径上。按以下顺序逐层验证：

实操心得：永远用sudo -u www-data模拟服务用户执行命令！因为redis-cli默认以当前用户运行，而 Agent 服务以www-data用户运行，权限差异会导致连接成功但代码失败。

4.2 Nginx 502 Bad Gateway 的根因分析表

502 错误本质是 Nginx 无法从 upstream 获取有效响应。以下是高频原因及验证方法：

注意：proxy_pass http://127.0.0.1:8000;中的127.0.0.1必须与gunicorn.conf.py的bind地址完全一致。若 Gunicorn 绑定0.0.0.0:8000，Nginx 可用proxy_pass http://localhost:8000;，但localhost会触发 DNS 解析，增加毫秒级延迟，生产环境务必用127.0.0.1。

4.3 FastAPI 启动失败的典型错误速查

4.4 性能瓶颈定位实战：用 wrk + Redis Monitor 定位慢查询

当用户反馈接口变慢，不要盲目重启服务。用标准工具链精准定位：

步骤一：用 wrk 模拟真实流量

# 安装 wrk sudo apt install wrk # Ubuntu # 或 sudo dnf install wrk # CentOS # 模拟 100 并发，持续 30 秒 wrk -t4 -c100 -d30s --latency http://localhost/agent/chat -s post.lua

其中post.lua文件内容：

wrk.method = "POST" wrk.body = '{"user_id":"test123","message":"hello"}' wrk.headers["Content-Type"] = "application/json"

步骤二：实时监控 Redis 命令执行在另一个终端运行：

redis-cli -a your_password monitor | grep -E "(SET|GET|LPUSH|BRPOP)"

观察是否有大量GET命令堆积（说明缓存命中率低），或BRPOP长时间无响应（说明 worker 进程卡死）。

步骤三：分析 Uvicorn 进程状态

# 查看进程 CPU 占用 top -p $(pgrep -f "gunicorn.*main:app") # 查看线程数（应接近 workers * 2） ps -T -p $(pgrep -f "gunicorn.*main:app") \| wc -l

我的经验：90% 的性能问题源于 Redis 连接池耗尽。当redis_client实例被全局复用，但未设置max_connections，高并发下会创建无数连接直至 Redis 拒绝新连接。解决方案是在redis.from_url()中添加max_connections=20参数，并在 FastAPI 依赖注入中管理生命周期。

5. 部署后必做的五项验证与监控

5.1 健康检查自动化脚本

创建/opt/agent-service/health-check.sh，每日定时执行：

#!/bin/bash # 检查 Redis 状态 REDIS_PING=$(redis-cli -a your_password ping 2>/