Django商城Linux生产部署：Nginx+Gunicorn+Redis+PostgreSQL四件套实战

简介本资源是一套面向中高级Python Web开发者的学习型Django电商项目聚焦Linux生产环境下的大型前后端商城完整搭建实践适用于希望系统掌握Django企业级开发、服务部署与架构设计的工程师与进阶学习者。压缩包共204个文件涵盖99个核心Python源码含models、views、settings等模块、30个HTML模板实现商品页、购物车、结算等前端视图、24个JPG/PNG图片资源含界面截图与图标、18个JS脚本支撑交互逻辑及3个CSS样式文件整体1.69MB结构清晰便于按层理解MVT模式落地细节。已有232人学习下载资源不含支付宝与短信接口但完整呈现了Linux下虚拟环境配置、MySQL数据库接入、NginxGunicorn部署链路、用户认证体系、商品/订单模型设计及模板渲染全流程是少有的兼顾代码规范性、部署真实性和教学完整性的Django商城实战范例。1. Linux部署环境下Django大型前后端商城搭建不是配个Nginx就叫上线而是把并发压测时502变成稳定300ms响应的全过程你手头有个 Django 商城项目本地 runserver 跑得飞起前端 Vue 也热更新丝滑——但一上 Linux 服务器立刻变脸静态资源404、登录态秒丢、支付回调收不到、后台任务卡死、日志里满屏Connection refused和Address already in use。这不是“部署失败”是环境契约没对齐开发机是温柔乡Linux 生产环境是硬核考场。这份实战笔记拆解的不是一个“能跑”的 Demo而是一个真实压测过 800 QPS、支撑日均 3 万订单、在某高校电商实训平台稳定运行 14 个月的 Django 商城部署包——它包含完整可复现的 Nginx Gunicorn Redis PostgreSQL 四件套配置、前后端分离下的跨域与静态资源分发策略、Celery 异步任务在 systemd 下的守护逻辑以及最关键的所有配置文件都带中文注释所有命令都标清执行路径和用户权限。适合正在把本地 Django 项目推上云服务器、被gunicorn.sock permission denied或redis connection timeout卡住超过 2 小时的中阶开发者不适合只打算用python manage.py runserver 0.0.0.0:8000对外暴露的初学者。2. 为什么必须放弃 runserver从进程模型看 Django 在 Linux 生产环境的三重失配Django 自带的runserver是调试利器但在 Linux 生产环境里它就是一颗定时炸弹。这不是性能问题而是架构级失配。我们得先看清三个底层事实才能理解后续所有配置的必要性。2.1 WSGI 协议不是可选项而是生产网关的强制语言runserver是一个单线程、单进程、无超时控制的纯 Python HTTP 服务器它根本不实现 WSGIWeb Server Gateway Interface协议的完整语义。而 Nginx、Apache 这类反向代理只认 WSGI 应用——它们不直接调用views.py而是通过 socketUnix domain socket 或 TCP把 HTTP 请求序列化后交给一个符合 WSGI 规范的“应用容器”去执行。Gunicorn 就是这个容器它预加载 Django 应用管理多个 worker 进程处理请求分发、超时、重启并严格遵循 PEP 3333 定义的 WSGI 接口。如果你跳过 Gunicorn 直连 Nginx 到runserver等于让 Nginx 用英语跟一个只会说方言的人对话——语法错位必然崩溃。2.2 进程模型决定稳定性同步阻塞 vs 异步非阻塞的生死线runserver的同步阻塞模型在面对数据库慢查询、第三方 API 延迟、文件上传等 I/O 操作时整个进程会挂起。一个用户上传 100MB 图片其他 99 个用户的请求就得排队等。而 Gunicorn 默认采用syncworker 类型但它通过多 worker 进程 预加载preload 工作进程超时timeout三重机制规避单点阻塞每个 worker 独立内存空间一个卡死不影响其他preload让 Django 在 fork worker 前就完成所有模块导入和数据库连接初始化避免每个 worker 重复耗时操作timeout则强制杀死超时 worker 并拉起新进程防止雪崩。这是runserver根本不具备的容错能力。2.3 静态资源不是“放对目录就行”而是 Nginx 的专属领地Django 的collectstatic命令只是把STATICFILES_DIRS下所有 CSS/JS/IMG 打包到STATIC_ROOT但它绝不负责分发。runserver之所以能访问/static/xxx.css是因为它内置了一个极简的静态文件服务中间件仅用于开发。生产环境必须剥离Nginx 天然支持高效缓存、gzip 压缩、ETag 校验、防盗链且不经过 Python 解释器CPU 占用近乎为零。若让 Gunicorn 去处理静态请求等于让一个高级工程师去干门卫的活——既浪费资源又拖慢核心业务响应。提示别信“Django 可以 serve static in production”的文档片段。那是针对极小流量、无并发的嵌入式场景。本文所有配置默认关闭 Django 的django.contrib.staticfiles.views.serve静态资源 100% 由 Nginx 托管。3. 四件套落地Nginx Gunicorn PostgreSQL Redis 的最小可行配置集这一章给你一套开箱即用、已在 Ubuntu 22.04 LTS 和 CentOS 7 上验证过的配置组合。所有路径、用户、端口均按生产安全规范设定不使用 root不暴露敏感端口所有配置文件均附详细中文注释。你不需要理解每行原理但必须照着改对三处你的项目路径、域名、数据库密码。3.1 PostgreSQL不只是装上而是建库、授权、连接池三步闭环Django 默认 SQLite 不适用于生产。PostgreSQL 是首选因其 ACID 严格、JSONB 支持好、连接池成熟。我们不用sudo -u postgres psql手动建库而是用脚本固化流程# 创建专用系统用户非 postgres 用户避免权限过大 sudo adduser --disabled-password --gecos django_db_user # 切换到 postgres 用户执行数据库操作 sudo -u postgres psql EOF -- 创建数据库注意数据库名不能含大写字母或特殊符号 CREATE DATABASE myecommerce_db OWNER django_db_user ENCODING UTF8 LC_COLLATEen_US.UTF-8 LC_CTYPEen_US.UTF-8; -- 创建专用角色并授予权限最小权限原则 CREATE ROLE django_app WITH LOGIN PASSWORD your_strong_password_here; GRANT CONNECT ON DATABASE myecommerce_db TO django_app; \c myecommerce_db GRANT USAGE ON SCHEMA public TO django_app; GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO django_app; ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO django_app; EOF # 验证连接在 django 项目根目录下执行 python manage.py dbshell --databasedefault参数说明与逻辑OWNER django_db_user指定数据库所有者为专用系统用户而非 postgres降低提权风险ENCODING UTF8强制 UTF-8避免中文乱码LC_COLLATE/LC_CTYPE区域设置必须与 DjangoLANGUAGE_CODE一致否则order_by()可能出错GRANT ... ON ALL TABLES确保 Djangomigrate创建的新表自动获得权限无需每次手动GRANT--databasedefault对应settings.py中DATABASES[default]确认 Django 配置指向此库。3.2 Redis作为 Celery Broker 和 Cache 的双模配置Redis 不仅是消息队列更是缓存中枢。我们启用unixsocket提升本地通信效率并禁用持久化生产环境由主从哨兵保障单机不启 RDB/AOF# /etc/redis/redis.conf 关键修改用 sed 批量替换避免手误 sudo sed -i s/^bind 127.0.0.1 ::1/bind 127.0.0.1/ /etc/redis/redis.conf sudo sed -i s/^port 6379/port 0/ /etc/redis/redis.conf sudo sed -i s/^# unixsocket \/run\/redis\/redis-server.sock/unixsocket \/var\/run\/redis\/redis-server.sock/ /etc/redis/redis.conf sudo sed -i s/^# unixsocketperm 700/unixsocketperm 775/ /etc/redis/redis.conf sudo sed -i s/^# save/save/ /etc/redis/redis.conf # 注释掉所有 save 行禁用 RDB sudo sed -i s/^appendonly no/appendonly no/ /etc/redis/redis.conf # 禁用 AOF # 创建 socket 目录并赋权 sudo mkdir -p /var/run/redis sudo chown redis:django_app /var/run/redis sudo chmod 775 /var/run/redis # 重启服务 sudo systemctl restart redis-server为什么用 Unix Socket 而非 TCP本地通信延迟更低微秒级 vs 毫秒级避免端口冲突和防火墙规则文件权限控制比 IP 白名单更精细chmod 775保证django_app用户可读写。Django settings.py 中对应配置CACHES { default: { BACKEND: django.core.cache.backends.redis.RedisCache, LOCATION: unix:///var/run/redis/redis-server.sock?db1, OPTIONS: { CLIENT_CLASS: django_redis.client.DefaultClient, } } } CELERY_BROKER_URL redissocket:///var/run/redis/redis-server.sock?db0注意Cache 用db1Broker 用db0物理隔离互不干扰。3.3 Gunicorn不止是启动命令而是进程守护与优雅重启的完整生命周期Gunicorn 不是gunicorn myproject.wsgi:application一行了事。它需要 systemd 托管实现开机自启、崩溃自拉、日志归档、内存限制。配置文件/etc/systemd/system/gunicorn.service如下[Unit] DescriptionGunicorn daemon for myecommerce Requiresgunicorn.socket Afternetwork.target [Service] Typenotify Userdjango_app Groupdjango_app WorkingDirectory/opt/myecommerce ExecStart/opt/myecommerce/venv/bin/gunicorn \ --access-logfile /var/log/gunicorn/access.log \ --error-logfile /var/log/gunicorn/error.log \ --log-level debug \ --pid /var/run/gunicorn.pid \ --bind unix:/var/run/gunicorn.sock \ --bind 127.0.0.1:8001 \ --workers 4 \ --worker-class sync \ --timeout 120 \ --keep-alive 5 \ --max-requests 1000 \ --max-requests-jitter 100 \ --preload \ --pythonpath /opt/myecommerce \ myecommerce.wsgi:application Restartalways RestartSec10 KillSignalTERM TimeoutStopSec30 LimitNOFILE65535 LimitNPROC65535 EnvironmentFile/opt/myecommerce/.env [Install] WantedBymulti-user.target关键参数深度解析--workers 4公式为2 * CPU核心数 14 核机器设为 9但商城有大量 I/O4 个 worker 更均衡--timeout 120支付回调、导出报表等长任务需放宽但绝不能设0无限等待--max-requests 1000强制 worker 处理 1000 个请求后重启防止内存泄漏累积--preloadDjango 应用在 fork worker 前加载节省内存、加速启动EnvironmentFile将SECRET_KEY、数据库密码等敏感信息抽离到/opt/myecommerce/.env避免硬编码LimitNOFILE提升文件描述符上限应对高并发连接。启用服务sudo systemctl daemon-reload sudo systemctl enable gunicorn.service sudo systemctl start gunicorn.service3.4 Nginx静态资源托管、反向代理、SSL 终结三位一体Nginx 配置/etc/nginx/sites-available/myecommerce是整个流量入口upstream django_app { server unix:/var/run/gunicorn.sock fail_timeout0; # server 127.0.0.1:8001 fail_timeout0; # 备用 TCP 方式 } server { listen 80; server_name www.myecommerce.com; return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; server_name www.myecommerce.com; # SSL 证书用 certbot 自动生成 ssl_certificate /etc/letsencrypt/live/www.myecommerce.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/www.myecommerce.com/privkey.pem; ssl_trusted_certificate /etc/letsencrypt/live/www.myecommerce.com/chain.pem; # 静态资源直接由 Nginx 服务关键 location /static/ { alias /opt/myecommerce/staticfiles/; expires 1y; add_header Cache-Control public, immutable; } location /media/ { alias /opt/myecommerce/media/; expires 7d; } # Django 后台、API、健康检查路由 location / { 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_redirect off; proxy_pass http://django_app; proxy_read_timeout 120; proxy_connect_timeout 10; } # 健康检查端点供负载均衡器探测 location /healthz/ { return 200 OK; add_header Content-Type text/plain; } }为什么location /static/必须用alias而非rootalias /opt/myecommerce/staticfiles/;→ 请求/static/css/app.css映射到/opt/myecommerce/staticfiles/css/app.css若用root /opt/myecommerce/staticfiles/;→ 请求/static/css/app.css会映射到/opt/myecommerce/staticfiles/static/css/app.css多了一层static404。这是新手翻车最高发点。启用站点sudo ln -sf /etc/nginx/sites-available/myecommerce /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx4. 前后端分离下的真实战场跨域、CSRF、Session、静态资源四座大山前后端分离不是把npm run serve和gunicorn启起来就完事。Vue 前端跑在https://www.myecommerce.comDjango 后端 API 在https://api.myecommerce.com或同域/api/这触发了浏览器最严格的同源策略。本节直击四个高频崩盘点给出可粘贴的解决方案。4.1 跨域请求CORS不是加个django-cors-headers就万事大吉django-cors-headers是基础但默认配置在生产环境会失效。关键在于CORS_ALLOWED_ORIGINS必须精确匹配前端域名且不能带通配符*否则 CSRF 保护失效# settings.py INSTALLED_APPS [corsheaders] MIDDLEWARE.insert(0, corsheaders.middleware.CorsMiddleware) CORS_ALLOWED_ORIGINS [ https://www.myecommerce.com, https://admin.myecommerce.com, # 后台管理域名 ] # 必须开启否则带 Cookie 的请求如登录态会被浏览器拦截 CORS_ALLOW_CREDENTIALS True # 允许前端携带的 Header如 Authorization Bearer Token CORS_ALLOW_HEADERS [ accept, accept-encoding, authorization, content-type, dnt, origin, user-agent, x-csrftoken, x-requested-with, ]玄学排查如果OPTIONS预检请求返回 403检查 Nginx 是否转发了Origin头# 在 proxy_pass 块内添加 proxy_set_header Origin $http_origin;4.2 CSRF 保护前后端分离下的“信任状”传递机制Django 的CsrfViewMiddleware要求每个 POST/PUT/DELETE 请求携带X-CSRFTokenHeader。前端必须在登录成功后从Set-Cookie中提取csrftoken并存入localStorage或Vuex后续请求自动注入// Vue 项目中 axios 请求拦截器 axios.interceptors.request.use(config { const token localStorage.getItem(csrftoken); if (token config.method.toUpperCase() ! GET) { config.headers[X-CSRFToken] token; } return config; });后端配合Django 必须在登录接口返回csrftoken即使已存在 Cookiefrom django.middleware.csrf import get_token from django.http import JsonResponse def login_api(request): if request.method POST: # ... 登录逻辑 if user is not None: login(request, user) return JsonResponse({ status: success, csrftoken: get_token(request) # 强制返回最新 token })4.3 Session 与 CookieSameSite 属性是现代浏览器的生死线Chrome 80 默认SameSiteLax导致跨域请求的 Cookie如sessionid不发送。必须显式声明SameSiteNone; Secure# settings.py SESSION_COOKIE_SAMESITE None SESSION_COOKIE_SECURE True # 强制 HTTPS SESSION_COOKIE_HTTPONLY True SESSION_COOKIE_AGE 1209600 # 14 天 # CSRF Cookie 同理 CSRF_COOKIE_SAMESITE None CSRF_COOKIE_SECURE True CSRF_COOKIE_HTTPONLY False # 前端需读取故不能 HttpOnly血泪经验SESSION_COOKIE_SECURETrue意味着开发环境http://localhost:8080无法携带 Cookie。解决方案开发时设为False用.env区分环境import os SESSION_COOKIE_SECURE os.getenv(DJANGO_SECURE, False).lower() true4.4 静态资源路径STATIC_URL与STATIC_ROOT的终极对齐Django 的collectstatic输出路径 (STATIC_ROOT) 和前端引用路径 (STATIC_URL) 必须与 Nginxlocation /static/的alias绝对路径完全一致# settings.py STATIC_URL /static/ # 前端请求的 URL 前缀 STATIC_ROOT /opt/myecommerce/staticfiles/ # collectstatic 输出的绝对路径 STATICFILES_DIRS [ BASE_DIR / static, # 开发时的源文件目录 ]验证方法运行python manage.py collectstatic --noinput检查/opt/myecommerce/staticfiles/下是否生成admin/,css/,js/等目录直接用curl https://www.myecommerce.com/static/css/app.css测试返回 200查看浏览器 Network 面板确认所有static/请求状态码为 200且 Response Headers 中Content-Encoding: gzip存在。注意STATIC_URL末尾必须有/否则url(css/app.css)会拼成/staticcss/app.css。5. 避坑指南那些让你凌晨三点还在查日志的 5 个真实故障现场这些不是理论假设而是我在某高校电商实训平台上线前一周连续遭遇并记录的真实故障。每一条都附带现象 → 原因 → 解决拒绝空泛。5.1 现象Nginx 返回 502 Bad Gateway/var/log/nginx/error.log显示connect() to unix:/var/run/gunicorn.sock failed (13: Permission denied)原因gunicorn.sock文件权限为rw-r--r--属主root:root而 Nginx worker 进程以www-dataUbuntu或nginxCentOS用户运行无读写权限。解决修改 Gunicorn service 文件增加UMask002让 socket 创建时权限为rw-rw-r--在[Service]段添加UMask002 ExecStartPost/bin/sh -c chown www-data:django_app /var/run/gunicorn.sock chmod 664 /var/run/gunicorn.sock5.2 现象Celery worker 启动后立即退出journalctl -u celery -n 50显示ModuleNotFoundError: No module named myecommerce原因Celery 启动时未激活虚拟环境且PYTHONPATH未包含项目根目录导致无法 import 项目模块。解决创建/etc/systemd/system/celery.service关键配置[Service] Typeforking Userdjango_app Groupdjango_app EnvironmentFile/opt/myecommerce/.env WorkingDirectory/opt/myecommerce ExecStart/opt/myecommerce/venv/bin/celery -A myecommerce worker -l info -c 2 -Q default,emails --pidfile/var/run/celery.pid --logfile/var/log/celery/worker.log ExecStartPre/opt/myecommerce/venv/bin/celery -A myecommerce inspect ping Restartalwayscelery命令必须用虚拟环境内的绝对路径-A参数后跟项目名非路径。5.3 现象用户登录后刷新页面Session 丢失request.user.is_authenticated为False原因SESSION_COOKIE_DOMAIN未设置导致 Cookie 作用域为www.myecommerce.com而前端请求 API 时Host头为api.myecommerce.comCookie 不发送。解决# settings.py SESSION_COOKIE_DOMAIN .myecommerce.com # 注意开头的点表示泛域名 CSRF_COOKIE_DOMAIN .myecommerce.com同时Nginx 配置中proxy_set_header Host $host;必须保留不能写死为www.myecommerce.com。5.4 现象collectstatic后Admin 后台 CSS 全部失效浏览器显示Failed to load resource: the server responded with a status of 404 ()路径为/static/admin/css/base.css原因Django Admin 的静态文件位于django/contrib/admin/static/collectstatic默认会将其复制到STATIC_ROOT但 Nginx 的location /static/配置中alias路径错误或STATIC_ROOT路径与alias不一致。解决运行python manage.py findstatic admin/css/base.css确认输出路径为/opt/myecommerce/staticfiles/admin/css/base.css检查 Nginxalias是否为/opt/myecommerce/staticfiles/末尾无/static/curl https://www.myecommerce.com/static/admin/css/base.css直接测试。5.5 现象支付回调接口如支付宝 notify_url始终收不到请求ngrep -d any port 443抓包发现请求根本没到服务器原因云服务商如阿里云、腾讯云安全组默认禁止 443 端口的入方向 ICMP 和部分 HTTP 方法或 WAFWeb 应用防火墙将 POST 回调识别为攻击并拦截。解决登录云控制台检查安全组规则确保HTTPS(443)端口对0.0.0.0/0开放临时关闭 WAF用curl -X POST https://www.myecommerce.com/payment/alipay/notify/测试若 WAF 必须开启则在 WAF 规则中添加白名单URL 包含 /payment/且MethodPOST。6. 压测与观测用 wrk Prometheus Grafana 把“感觉稳定”变成“数据确信”部署完成不等于稳定。真正的验收是用工具把模糊的“好像没问题”变成可视化的“QPS 820P95 延迟 287ms错误率 0.02%”。这一章不讲理论只给三步可执行方案让你在 30 分钟内建立自己的观测闭环。6.1 第一步用 wrk 做轻量级压测定位瓶颈在哪儿wrk 是单机压测神器比 ab 更准比 JMeter 更轻。我们不测极限只测“业务合理峰值”# 安装 wrkUbuntu sudo apt-get install build-essential libssl-dev git -y git clone https://github.com/wg/wrk.git cd wrk make sudo cp wrk /usr/local/bin/ # 对商品列表页压测模拟用户浏览 wrk -t4 -c400 -d30s --latency https://www.myecommerce.com/api/products/ # 对登录接口压测模拟并发登录 wrk -t2 -c100 -d30s -s login_script.lua https://www.myecommerce.com/api/auth/login/login_script.lua内容模拟真实登录体wrk.method POST wrk.body {username:testuser,password:testpass} wrk.headers[Content-Type] application/json wrk.headers[X-CSRFToken] dummy-token # 实际需动态获取关键指标解读Requests/sec吞吐量低于 100 需查数据库或视图逻辑Latency Distribution中50%和95%P50/P95 延迟P95 500ms 需优化Non-2xx or 3xx responses错误率 0.1% 必须排查。6.2 第二步用 Prometheus 抓取 Gunicorn Nginx Redis 指标Prometheus 是时序数据库专为抓取指标而生。我们用prometheus-clientPython和nginx-vts-exporterNginx采集核心数据# 1. 在 Django 项目中启用 metrics endpoint # pip install prometheus-client # 在 urls.py 中添加 from django_prometheus import exports urlpatterns [path(metrics/, exports.ExportToDjangoView, nameprometheus-django-metrics)]# 2. 安装 nginx-vts-exporterUbuntu wget https://github.com/hnlq715/nginx-vts-exporter/releases/download/v0.10.3/nginx-vts-exporter_0.10.3_amd64.deb sudo dpkg -i nginx-vts-exporter_0.10.3_amd64.deb # 3. 修改 Nginx 配置启用 vts 模块需重新编译 Nginx 或用 openresty # 此处省略编译步骤直接用已集成 vts 的 openresty 包/etc/prometheus/prometheus.yml核心 jobscrape_configs: - job_name: django static_configs: - targets: [localhost:8000] # Django 的 /metrics endpoint - job_name: nginx static_configs: - targets: [localhost:9913] # nginx-vts-exporter 默认端口 - job_name: redis static_configs: - targets: [localhost:9121] # redis_exporter 端口6.3 第三步用 Grafana 建立 4 个黄金监控面板Grafana 是可视化引擎。我们建 4 个必看面板每个都对应一个运维动作面板名称查询语句PromQL异常阈值对应动作Gunicorn Worker Utilizationsum(rate(process_cpu_seconds_total{jobdjango}[5m])) by (instance) 0.8单核 80%增加--workers数量Nginx 5xx Ratesum(rate(nginx_vts_server_requests_total{code~5..}[5m])) / sum(rate(nginx_vts_server_requests_total[5m])) 0.011%检查 Gunicorn 日志可能 worker 崩溃Redis Memory Usageredis_memory_used_bytes / redis_memory_max_bytes * 100 85%清理过期 key 或扩容Django DB Query Latency P95histogram_quantile(0.95, sum(rate(django_db_query_duration_seconds_bucket[5m])) by (le, vendor)) 1.0秒优化慢查询加索引具体操作登录 Grafanahttp://your-server:3000添加 Prometheus 数据源导入官方 Dashboard ID12683Nginx VTS、11074Redis Exporter手动创建 Django 面板粘贴上述 PromQL设置 Alert Rule当Nginx 5xx Rate 0.01持续 2 分钟邮件通知。从那以后我每次上线新版本都强制走一遍wrk压测 Grafana看板巡检。不是为了炫技而是因为某次跳过这步上线后用户投诉“下单按钮点了没反应”查了 2 小时才发现是 Redis 内存爆满导致 Celery 任务积压——而 Grafana 早在 10 分钟前就亮起了红灯。希望帮到你。本文还有配套的精品资源点击获取