毕业设计Ticket Guard —— 赛事抢票高频IP拦截系统 全功能点详解

最近写了一个抢票限流的毕业设计，需要源码的请私信我~

本文详细介绍 Ticket Guard 系统的所有功能模块，涵盖后端 API 限流引擎、前端管理控制台、桌面客户端三大子系统。项目采用 FastAPI + Vue 3 + Redis + MySQL 技术栈，实现了完整的赛事票务 + 高频请求拦截方案。

一、项目概览

1.1 系统定位

Ticket Guard 是一套赛事抢票场景下的 API 限流拦截系统。核心解决的问题是：在热门赛事（演唱会、体育比赛等）开票瞬间，大量用户（包括黄牛脚本）集中请求抢票接口，系统需要对高频恶意请求进行识别、限流和封禁，同时放行正常用户的请求。

1.2 技术架构

整个项目由三个子系统组成：

1.3 数据库设计

系统共涉及 10 张数据表：

二、后端核心功能（ticket_guard）

2.1 用户认证模块

路由前缀：/auth

2.1.1 用户注册

接口POST /auth/register接收用户名和密码，使用 bcrypt 算法对密码进行哈希处理后存入sys_user表。注册时会校验用户名是否已存在，若重复则返回 400 错误。

2.1.2 用户登录

接口POST /auth/login验证用户名密码，成功后生成一个有效期 2 小时的 JWT Token（基于 HS256 算法），Token 的 payload 中包含用户 ID。同时会校验用户账号是否处于激活状态（is_active），被禁用的账号无法登录。

2.1.3 获取当前用户信息

接口GET /auth/me通过 Token 解析出用户身份，返回用户 ID、用户名、昵称、激活状态等基本信息。该接口需要登录后携带 Bearer Token 访问。

2.1.4 认证中间件

系统在 FastAPI 的 HTTP 中间件层实现了全局认证。每个请求到达时，中间件自动解析Authorization头中的 JWT Token，将解析出的user_id注入到request.state中，供下游路由使用。需要认证的路由通过require_user依赖项进行鉴权——若 Token 无效或用户不存在，返回 401 错误。

2.2 限流引擎（核心模块）

限流引擎是整个系统的核心，以 HTTP 中间件的形式运行，对所有进入系统的请求进行实时拦截判断。

2.2.1 请求处理流程

每个请求经过限流中间件时，依次执行以下步骤：

1. 生成请求ID：为每个请求分配一个 UUID，写入响应头X-Request-ID，方便全链路追踪。

2. 获取客户端IP：优先从X-Forwarded-For头获取真实 IP（支持反向代理场景），否则取request.client.host。

3. 白名单检查：查询 IP 或用户是否在白名单中。命中白名单则直接放行，响应头附加X-RateLimit-Bypass: whitelist。

4. 黑名单检查：检查 IP 或用户是否被封禁（永久封禁或临时封禁未过期）。命中则直接返回 403。

5. 加载限流规则：从数据库加载所有启用的规则（带 5 秒本地缓存），按优先级降序排列。

6. 规则匹配与计数：遍历每条规则，根据作用范围（Scope）判断是否适用于当前请求的 HTTP 方法和路径。匹配成功后，根据规则的限流对象（IP/用户/IP+用户）构建 Redis 计数键，并执行计数器递增。

7. 超限处理：若计数超过阈值，根据规则配置的处置动作（BLOCK/TEMP_BAN/LOG_ONLY）执行相应操作。

8. 日志记录：按 20% 的采样率记录请求日志，拦截日志则 100% 记录。

2.2.2 限流算法

系统支持两种限流算法：

滑动窗口（SLIDING_WINDOW）：使用 Redis 的 Sorted Set（ZSET）实现。每次请求以当前时间戳作为 score 和 member 加入集合，同时移除窗口时间范围之外的过期成员，然后用ZCARD获取当前窗口内的请求数量。这种算法精度高，不存在固定窗口的边界突增问题。

固定窗口（FIXED_WINDOW）：将时间按窗口大小划分为若干桶（bucket），使用 Redis 的字符串计数器INCR递增当前桶的计数值，并设置 TTL 自动过期。实现简单、性能高，适用于对精度要求不高的场景。

2.2.3 限流对象类型

2.2.4 处置动作

2.2.5 规则作用范围（Scope）

每条规则可以配置一个或多个作用范围，支持三种匹配模式：

每个 Scope 还可以限定 HTTP 方法（如仅对 POST 请求生效），未指定方法则匹配所有方法。

2.2.6 缓存策略

为了减少数据库查询压力，限流引擎大量使用了 Redis 缓存：

规则变更（增删改、启禁用）时会主动失效规则缓存；黑白名单变更时会主动清除相关的 Redis 缓存键。

2.3 规则管理模块

路由前缀：/rules（需登录）

提供限流规则的完整 CRUD 操作：

2.3.1 规则列表查询

GET /rules支持分页查询和按启用状态筛选，返回的规则列表按优先级降序排列。每条规则关联返回其所有 Scope（作用范围）信息。

2.3.2 创建规则

POST /rules接受规则的完整配置，包括名称、限流对象类型、算法、时间窗口、阈值、处置动作、封禁时长、优先级以及作用范围列表。创建完成后自动失效规则缓存，使新规则立即生效。

2.3.3 编辑规则

PUT /rules/{rule_id}支持部分字段更新。如果传入了新的 Scopes 列表，会先删除该规则下所有旧 Scope，再批量插入新的 Scope（全量替换策略）。

2.3.4 启禁用规则

PATCH /rules/{rule_id}/enable提供快捷的规则启用/禁用操作，无需提交完整规则数据。

2.3.5 删除规则

DELETE /rules/{rule_id}删除规则时会同步清理其下所有 Scope 记录，并失效缓存。

2.4 黑名单管理模块

路由前缀：/blacklist（需登录）

分为 IP 黑名单和用户黑名单两个子模块，功能结构一致。

2.4.1 IP 黑名单

• GET /blacklist/ip：分页查询 IP 黑名单列表

• POST /blacklist/ip：手动封禁 IP。支持设置永久封禁或临时封禁（指定封禁秒数）。封禁操作同时写入数据库和 Redis：永久封禁不设 TTL，临时封禁按ban_seconds设置 TTL。如果该 IP 已在黑名单中，则更新封禁信息。

• DELETE /blacklist/ip/{ip}：解封 IP，同时清除数据库记录和 Redis 缓存。

2.4.2 用户黑名单

• GET /blacklist/user：分页查询用户黑名单

• POST /blacklist/user：手动封禁用户，逻辑与 IP 封禁一致

• DELETE /blacklist/user/{user_id}：解封用户

自动封禁场景：当限流规则的处置动作为TEMP_BAN时，引擎会自动调用apply_temp_ban将 IP 和用户同时加入临时黑名单，并设置 Redis 封禁键。

2.5 白名单管理模块

路由前缀：/whitelist（需登录）

白名单内的 IP 或用户将完全绕过限流检查，不受任何规则约束。

2.5.1 IP 白名单

• GET /whitelist/ip：分页查询 IP 白名单

• POST /whitelist/ip：添加 IP 白名单，需填写 IP 和备注原因。重复添加同一 IP 会更新原因。

• DELETE /whitelist/ip/{ip}：移除白名单

2.5.2 用户白名单

• GET /whitelist/user：分页查询用户白名单

• POST /whitelist/user：添加用户白名单

• DELETE /whitelist/user/{user_id}：移除白名单

白名单变更后会主动清除 Redis 缓存，确保变更即时生效。

2.6 日志查询模块

路由前缀：/logs（需登录）

2.6.1 拦截日志（Block Log）

GET /logs/blocks查询被限流引擎拦截的请求记录，支持以下筛选条件：

• minutes：最近 N 分钟内的记录

• ip：按 IP 地址筛选

• user_id：按用户 ID 筛选

• rule_id：按触发的规则 ID 筛选

每条拦截日志包含完整的请求信息（IP、用户、方法、路径）、触发的规则信息（规则 ID、窗口大小、阈值、当前计数）以及处置动作和封禁时长。

2.6.2 请求日志（Request Log）

GET /logs/requests查询系统的请求访问记录（按 20% 采样率记录），支持按时间、IP、路径关键词等条件筛选。每条记录包含请求 ID、IP、用户 ID、HTTP 方法、路径、响应状态码和响应耗时（毫秒）。

2.6.3 日志导出

• GET /logs/blocks/export：导出拦截日志为 CSV 文件（最多 50000 条）

• GET /logs/requests/export：导出请求日志为 CSV 文件（最多 50000 条）

导出使用流式响应（StreamingResponse），避免大量数据一次性加载到内存。

2.7 统计分析模块

路由前缀：/stats（需登录）

2.7.1 拦截趋势

GET /stats/blocks_by_minute统计最近 N 分钟内每分钟的拦截数量，返回时间序列数据，前端用 ECharts 渲染为折线图。使用 MySQL 的DATE_FORMAT函数按分钟分组聚合。

2.7.2 Top 拦截 IP

GET /stats/top_blocked_ips统计最近 N 分钟内被拦截次数最多的 IP 排行榜（默认 Top 10），前端渲染为柱状图。

2.8 系统监控模块

路由前缀：/system（需登录）

2.8.1 系统概览

GET /system/overview返回系统运行状态的全面概览，包括：

• 当前服务器时间（GMT+8）

• Redis 连接状态、内存占用、连接客户端数、db0 键数量

• 限流规则总数/启用数

• 黑白名单总数

• 拦截日志/请求日志总数

• 数据库连接池状态（池大小、空闲连接数、使用中连接数、溢出数）

2.8.2 当前生效封禁

GET /system/active-bans查询当前所有生效中的封禁（包括永久封禁和临时封禁未过期的），分为 IP 封禁和用户封禁两个列表。

2.8.3 限流状态实时查看

GET /system/rate-limit-status扫描 Redis 中所有limit:*前缀的计数器键和ban:*前缀的封禁键，返回每个计数器的当前值、TTL、关联的规则名称以及是否处于封禁状态。管理员可以通过这个接口实时观察限流计数器的变化情况，用于排查问题。

2.9 规则测试工具模块

路由前缀：/tools（需登录）

这是系统提供的一组无副作用的诊断工具，帮助管理员在不影响线上数据的情况下调试限流规则。

2.9.1 规则预览

POST /tools/rule-preview输入一个模拟请求的参数（IP、用户 ID、HTTP 方法、路径），系统返回该请求会命中哪些规则、该 IP/用户是否在黑白名单中。帮助管理员快速排查"为什么某个请求没被拦截"或"为什么某个用户被拦截了"。

2.9.2 规则模拟测试

POST /tools/rule-test在规则预览的基础上增加了模拟重复请求的能力。输入模拟次数（repeat_count），系统计算在该次数下，每条命中的规则是否会触发拦截，以及第几次请求开始触发拦截。整个过程完全在内存中推演，不写入 Redis 计数器。

返回结果包含：匹配的规则数、是否会被拦截、首个触发拦截的规则名称和触发次数、封禁秒数等详细信息。

2.10 赛事管理模块

路由前缀：/api/events

提供赛事/演出的完整 CRUD 接口，是票务业务的基础数据管理。

2.10.1 赛事列表

GET /api/events查询赛事列表，支持按分类（演唱会/体育赛事/话剧/音乐节等）和状态（0-未开售/1-售票中/2-已售罄/3-已结束）筛选，按开始时间升序排列。

2.10.2 赛事详情

GET /api/events/{event_id}返回单个赛事的完整信息，包括标题、场馆、城市、时间、分类、票价、总库存、剩余库存、状态、开售时间、描述等。

2.10.3 创建赛事

POST /api/events创建新赛事。核心字段包括赛事标题、场馆（必填）、票价、总库存（初始时剩余库存等于总库存）、状态和开售时间。

2.10.4 编辑赛事

PUT /api/events/{event_id}更新赛事信息，支持修改标题、场馆、城市、分类、票价、库存、状态、描述等所有字段。

2.10.5 删除赛事

DELETE /api/events/{event_id}删除指定赛事。

2.10.6 赛事统计

GET /api/events/stats返回赛事的汇总统计数据：赛事总数、在售赛事数、总票数、已售出票数。

2.11 订单模块

路由前缀：/api

2.11.1 抢票下单

POST /api/ticket/buy是系统的核心业务接口。用户提交赛事 ID 和购买数量，系统执行以下操作：

1. 验证用户登录状态

2. 使用SELECT ... FOR UPDATE行锁查询赛事，保证并发安全

3. 校验赛事状态（必须为"售票中"）和库存是否充足

4. 扣减库存，若库存为 0 则自动将状态更新为"已售罄"

5. 生成订单号（格式：TK+ 时间戳 + 8位短UUID）

6. 创建待支付订单

该接口是限流引擎重点保护的目标接口——可以配置针对/api/ticket/buy路径的专属限流规则。

2.11.2 我的订单

GET /api/orders/my查询当前登录用户的所有订单，按创建时间倒序排列。每条订单关联显示赛事标题、订单状态（待支付/已支付/已取消/已退票）等信息。

2.11.3 管理端订单查询

GET /api/orders供管理员查看系统所有订单，支持按赛事 ID 和订单状态筛选。

2.11.4 模拟支付

POST /api/orders/{order_id}/pay将待支付的订单状态改为已支付，并记录支付时间。仅订单所属用户可操作，且仅待支付状态的订单可执行支付。

2.11.5 取消订单

POST /api/orders/{order_id}/cancel取消订单并自动恢复对应赛事的库存。如果赛事因售罄状态变为"已售罄"，取消订单后会自动恢复为"售票中"。待支付和已支付状态的订单均可取消。

2.12 数据库连接池配置

系统的 MySQL 连接池经过精细调优，支持通过环境变量配置以下参数：

连接池启用了pool_pre_ping（使用前探活）、pool_use_lifo（后进先出，优先复用热连接）、pool_reset_on_return="rollback"（归还时回滚未提交事务）等最佳实践配置。

2.13 压力测试

使用k6脚本进行压力测试

import http from 'k6/http'; export const options = { vus: 400, // 400并发 duration: '15s', // 持续15秒 }; const BASE_URL = 'http://127.0.0.1:8000'; export default function () { const res = http.get(`${BASE_URL}/test`); if (res.status === 429) { console.log("----->触发封禁:", res.status); } }

三、前端管理控制台（ticket_guard_front）

前端使用 Vue 3 + Element Plus 构建，整体采用左侧导航 + 右侧内容区的经典后台布局。

3.1 登录页

提供用户名/密码登录表单，登录成功后将 JWT Token 存储在 localStorage 中。页面采用蓝白色调的现代设计风格，带有网格背景和品牌 Logo。路由守卫（router.beforeEach）自动拦截未登录的访问并重定向到登录页。

3.2 统计面板（Dashboard）

首页统计面板展示四个核心指标卡片（规则总数、启用规则数、黑名单总数、Redis 状态），以及两个 ECharts 图表：

• 拦截趋势折线图：展示最近 N 分钟（可调节）每分钟的拦截数量变化

• Top 拦截 IP 柱状图：展示被拦截次数最多的 IP 排行

图表支持窗口自适应缩放。

3.3 规则管理页（Rules）

功能完备的限流规则管理页面：

• 规则列表：表格展示所有规则，支持按启用状态筛选，展示规则名称、限流对象（中文显示）、算法类型、窗口秒数、阈值、处置动作、封禁秒数、优先级和启用开关

• 新建/编辑弹窗：完整的表单，包含规则基本配置和 Scope 作用范围的动态表格编辑（支持增删行）

• 启用开关：表格行内直接切换规则的启禁用状态

• 删除操作：二次确认后删除

前端做了英文枚举到中文的映射显示，如SLIDING_WINDOW显示为"滑动窗口（SLIDING_WINDOW）"，TEMP_BAN显示为"临时封禁（TEMP_BAN）"。

3.4 规则测试页（RuleTest）

左右分栏布局：

• 左侧：测试表单，输入请求路径、HTTP 方法、IP、用户 ID 和模拟次数

• 右上：命中预览结果，展示黑白名单状态和命中的规则列表

• 右下：模拟测试结果，展示是否会被拦截、匹配规则数、首个拦截规则和触发次数

页面底部提示"这是无副作用测试"，给予管理员信心。

3.5 黑名单管理页（Blacklist）

Tab 切换 IP 黑名单和用户黑名单：

• 表格展示 IP/用户 ID、封禁原因、是否永久封禁、到期时间

• 新增封禁弹窗支持配置永久/临时封禁和封禁秒数

• 解封操作带二次确认

3.6 白名单管理页（Whitelist）

Tab 切换 IP 白名单和用户白名单：

• 表格展示 IP/用户 ID、备注原因、创建时间

• 新增弹窗，删除带二次确认

3.7 日志查询页（Logs）

Tab 切换拦截日志和请求日志：

• 拦截日志：支持按时间范围、IP、用户 ID 筛选，展示时间、IP、用户、方法、路径、规则 ID、当前次数、处置动作和说明。支持导出 CSV。

• 请求日志：支持按时间范围、IP、路径关键词筛选，展示时间、IP、用户、方法、路径、状态码和响应耗时。支持导出 CSV。

3.8 系统状态监控页（SystemMonitor）

这是信息最丰富的监控页面，包含以下区域：

• 顶部状态栏：Redis 连接状态指示灯（绿色脉动/红色告警）、当前服务器时间、刷新按钮

• 统计卡片网格：8 个指标卡片（规则总数、启用规则、IP/用户黑名单数、IP/用户白名单数、拦截/请求日志数）

• Redis 信息面板：内存占用、连接客户端数、db0 键数

• 数据库连接池面板：池大小、空闲/使用中/溢出连接数

• 活跃 IP 封禁表格：当前生效的 IP 封禁列表

• 活跃用户封禁表格：当前生效的用户封禁列表

• 限流计数器状态表格：Redis 中所有活跃的限流计数器，展示维度、对象、规则名、算法、当前计数、剩余 TTL 和封禁状态

• Redis 封禁键表格：所有ban:*前缀的 Redis 键

整个页面采用纯 CSS 手工定制样式，没有依赖 Element Plus 组件，呈现出专业的监控面板效果。

3.9 全局 UI 设计

• 整体色调以蓝白为主（Primary:#3b82f6），配合淡蓝灰背景

• 全局覆盖了 Element Plus 的默认样式，统一了卡片、表格、表单、弹窗、标签页等组件的视觉风格

• 侧边栏固定宽度 220px，展示品牌 Logo、导航菜单和底部 API 地址

• 顶栏展示当前页面标题和退出登录按钮

• 自定义了滚动条样式

• 支持窗口缩放自适应

四、桌面客户端（ticket_client）

4.1 统一 API 客户端（api_client.py）

封装了与后端所有 HTTP 交互的ApiClient类。内部自动管理 JWT Token，登录成功后所有后续请求自动携带Authorization: Bearer {token}头。提供认证、赛事、抢票、订单等全套 API 方法。

4.2 用户端（user_client.py）

基于 Python Tkinter 构建的用户侧抢票客户端。

4.2.1 登录/注册

• 简洁的登录界面，输入用户名和密码

• 支持直接注册新用户

• 登录成功后自动获取用户信息

4.2.2 赛事列表

• Tab 标签页切换"赛事列表"和"我的订单"

• 按分类筛选赛事（全部/演唱会/体育赛事/话剧/音乐节）

• Treeview 表格展示赛事 ID、名称、城市、场馆、时间、分类、票价、余票和状态

• 状态用不同颜色和 emoji 标识（如"🔥 售票中"、"已售罄"）

4.2.3 赛事详情

• 弹窗展示赛事的完整信息：标题、状态、场馆、时间、分类、票价、库存、开售时间和简介

4.2.4 抢票

• 选择赛事和购买数量（1-5张）

• 点击"立即抢票"后二次确认

• 成功后弹出订单号和金额提示

4.2.5 我的订单

• 展示个人订单列表：订单号、赛事名称、数量、总价、状态和下单时间

• 支持选中订单后一键支付（模拟）或取消

4.3 管理端（admin_client.py）

面向票务管理员的桌面管理工具。

4.3.1 赛事管理

• 赛事列表展示（Treeview 表格）

• 新增赛事：弹出完整表单（名称、场馆、城市、分类、时间、票价、总票数、状态、描述）

• 编辑赛事：加载现有数据到表单中修改

• 删除赛事：二次确认

• 刷新列表

4.3.2 订单管理

• 查看系统所有订单

• 按订单状态筛选（全部/待支付/已支付/已取消/已退票）

• 表格展示订单号、用户 ID、赛事名称、数量、总价、状态、支付时间和下单时间

4.3.3 数据统计

• 四个统计卡片：赛事总数、在售赛事数、总票数、已售出数

• 各赛事售票进度条：可视化展示每个赛事的售出比例，根据比例使用绿色/黄色/红色不同颜色

五、API 接口汇总

5.1 认证接口

5.2 限流规则接口

5.3 黑名单接口

5.4 白名单接口

5.5 日志接口

5.6 统计与监控接口

5.7 工具接口

5.8 赛事与订单接口

六、部署与运行

6.1 环境依赖

• Python 3.8+

• MySQL 8.0+

• Redis 5.0+

• Node.js 16+（前端构建）

6.2 后端启动

cd ticket_guard pip install -r requirements.txt ​ # 配置 .env 文件 # MYSQL_URL=mysql+pymysql://user:pass@localhost/ticket_guard # REDIS_HOST=127.0.0.1 # REDIS_PORT=6379 # REDIS_PASSWORD= # SECRET_KEY=your-secret-key ​ uvicorn app.main:app --reload --host 0.0.0.0 --port 8000

6.3 前端启动

cd ticket_guard_front npm install npm run dev

6.4 数据库初始化

# 执行建表脚本（包含赛事示例数据） mysql -u root -p ticket_guard < ticket_client/new_schema.sql

6.5 客户端启动

cd ticket_client pip install requests ​ # 修改 config.py 中的 API_BASE_URL ​ python user_client.py # 用户端 python admin_client.py # 管理端

七、总结

Ticket Guard 系统实现了从请求接入到限流拦截的完整链路，核心亮点包括：

1. 双算法支持：滑动窗口和固定窗口两种限流算法可按需选择

2. 灵活的规则引擎：支持按 IP/用户/IP+用户三种维度限流，支持全局/路径/前缀三种作用范围

3. 多级防御：白名单直通 → 黑名单拦截 → 规则匹配 → 超限处置，层层递进

4. 实时监控：Redis 计数器可视化、封禁状态实时查看、拦截趋势图表

5. 无副作用测试：规则预览和模拟测试工具，安全排查问题

6. 完整的票务闭环：赛事管理 → 抢票下单 → 支付/取消 → 库存自动管理

7. 多端接入：Web 管理控制台 + Python 桌面客户端，展示前后端分离架构的扩展能力

如果本文对你有帮助，欢迎点赞收藏关注，后续会继续分享更多实战项目的技术细节。