VideoAgentTrek Screen Filter 高并发架构设计：支持千人同时在线屏幕审核

VideoAgentTrek Screen Filter 高并发架构设计：支持千人同时在线屏幕审核

最近和几个做在线教育平台的朋友聊天，他们都在头疼同一个问题：线上考试的时候，怎么防止学生作弊？传统的方案，要么是人工监考，成本高得吓人；要么是简单的规则过滤，稍微变个花样就防不住了。他们问我，有没有一种技术，能像真人监考老师一样，实时分析成千上万个学生的屏幕画面，自动识别出切屏、打开无关软件、或者旁边有“场外援助”这些作弊行为？

这让我想起了我们团队之前做的一个项目——VideoAgentTrek Screen Filter。它本质上是一个AI驱动的屏幕内容实时分析与过滤服务。最初，我们只是用它来处理一些录屏文件的批量审核，比如审核游戏直播里有没有出现违规内容。但随着直播审核、大规模在线考试这些场景的需求爆发式增长，我们面临的核心挑战不再是“能不能分析”，而是“能不能同时为上千人提供低延迟、高可用的实时分析服务”。

今天，我就结合我们踩过的坑和最终落地的方案，跟大家聊聊，如何为这样一个AI屏幕审核服务，设计一套能扛住高并发冲击的架构。如果你也在为海量实时视频流处理头疼，希望这篇分享能给你一些启发。

1. 核心挑战与设计目标

当“实时屏幕审核”从处理几十个录播文件，升级到要同时处理上千个直播流时，整个技术栈面临的挑战是完全不同的。我们首先要搞清楚，我们要解决的是什么问题。

1.1 高并发场景下的四大核心挑战

想象一下，一个大型在线考试平台，同一时间有五千名学生在线考试。这意味着我们的服务需要同时建立五千个连接，接收五千路屏幕视频流（可能是截图流或视频流），并对每一帧画面进行毫秒级的AI分析。这里面的挑战非常具体：

第一，海量连接与数据涌入。五千个客户端意味着五千个长连接。每个客户端每秒可能推送1-5帧截图，假设每张截图压缩后100KB，那么每秒涌入服务器的数据量峰值可能达到5000 * 5 * 100KB ≈ 2.5GB/s。这不仅仅是网络带宽的压力，更是对连接管理、数据接收和解码能力的极限考验。

第二，AI模型推理的沉重负担。我们的Screen Filter核心是一个视觉模型，可能是基于目标检测或图像分类的，用来识别屏幕上是否有手机、第二块屏幕、非考试软件等。这种模型推理通常很耗资源（GPU/CPU）。单次推理可能需要几十到几百毫秒。如果请求排队，延迟会迅速累积到不可接受的程度，学生切屏后好几秒才告警，那就失去实时监控的意义了。

第三，状态管理与会话保持。每个学生的考试会话都是独立的，并且可能持续一两个小时。服务需要记住每个学生当前的分析状态、历史违规记录、以及可能不同的审核规则（例如，不同科目允许的软件白名单不同）。如何在服务多实例部署的情况下，保持会话状态的一致性和可访问性，是个难题。

第四，系统可用性与弹性伸缩。考试或直播高峰时段，流量是平时的数十倍。系统必须能自动扩容，以应对洪峰；在低谷时又能自动缩容，以节省成本。同时，任何单点故障都不能导致服务整体不可用，需要有无缝的故障转移机制。

1.2 我们的架构设计目标

面对这些挑战，我们为VideoAgentTrek Screen Filter的高并发架构定下了几个清晰的目标：

• 低延迟 (< 500ms端到端)：从客户端上传一帧画面，到收到分析结果（如“正常”或“疑似作弊-检测到手机”），整个流程必须在500毫秒内完成，以确保监控的实时性。
• 高可用 (99.99%)：服务需要具备极高的可用性，特别是在考试期间，不能出现服务中断。这意味着需要消除单点故障，并实现快速故障恢复。
• 水平可扩展：必须能够通过简单地增加服务器实例来提升系统的整体处理能力（吞吐量），以应对不断增长的用户数。
• 资源高效利用：优化昂贵的GPU资源使用，避免模型服务实例空闲或过载，通过合理的任务调度，让每一块计算卡都“忙”起来。
• 状态可管理：实现用户会话状态的集中、高效管理，支持多实例共享和快速查询。

2. 高并发架构全景图

说了这么多挑战和目标，最终我们落地的架构是什么样子呢？下面这张图概括了核心组件和数据处理流程。

[客户端] --> (负载均衡层) --> [API网关/WebSocket网关] --> (消息队列) --> [模型工作池] --> (缓存与存储) | | | | | | (屏幕流) (流量分发) (连接管理、协议转换) (任务缓冲、削峰) (AI推理) (状态、结果持久化)

整个流程可以理解为一条高效的“屏幕审核流水线”。接下来，我们拆解每一个关键环节。

3. 架构核心组件详解

3.1 第一道防线：负载均衡与网关层

这是所有外部请求的入口，它的健壮性决定了整个系统的第一印象。

我们选择了基于Nginx的七层负载均衡。为什么不用四层？因为我们需要基于HTTP/WebSocket协议的内容（如用户ID、考试场次ID）来做更智能的路由。例如，可以将同一场考试的所有学生请求，通过一致性哈希算法，固定分发到某一组后端服务器上，这样有利于本地缓存命中。

在负载均衡器之后，我们部署了独立的API网关集群（如使用Kong或自研网关）。它的职责很关键：

1. 认证与鉴权：验证客户端Token，确保只有合法的考试客户端才能连接。
2. 协议处理：对于实时性要求极高的屏幕流，我们采用了WebSocket协议进行全双工通信。网关需要维护大量的WebSocket长连接。
3. 限流与熔断：为每个用户或每个考试设置请求频率上限，防止恶意刷屏或客户端异常。当后端模型服务出现故障时，快速熔断，返回降级结果（如“服务繁忙，请稍后”），避免雪崩。
4. 请求转发：将携带了用户会话信息的审核请求，转发到后端的异步任务队列。

这一层全部采用无状态设计，可以轻松地水平扩展。任何一台网关服务器宕机，负载均衡器都会将流量切到健康的实例上。

3.2 异步解耦的核心：消息队列

这是解决高并发冲击最有效的“缓冲池”和“解耦器”。我们没有让网关直接调用模型服务，而是引入了一个消息队列（我们选用的是RabbitMQ，因其管理界面和特性丰富，Kafka也是优秀选择）。

它的工作模式是这样的：

1. 网关收到一帧图片和分析请求后，立即生成一个任务消息，里面包含任务ID、用户ID、图片数据（或图片存储地址）、时间戳等信息，然后快速投递到消息队列中一个名为screen_filter_tasks的队列，随后立即给客户端返回一个“请求已接收”的应答。这样客户端连接就不会被阻塞。
2. 消息队列起到了“削峰填谷”的作用。即使瞬间涌来一万个请求，队列会把它们暂存起来，后端模型服务按照自己的能力匀速消费，避免了洪峰直接压垮AI模型。
3. 我们为队列设置了优先级。例如，对于“切屏检测”这种需要极快反馈的请求，可以放入高优先级队列；对于“整体画面合规性复查”这种可以稍晚处理的请求，放入普通队列。

这种异步化设计，将请求的“接收”与“处理”完全分离，保证了系统前端的响应速度和高可用性，后端的处理能力也可以独立地、弹性地伸缩。

3.3 计算力军团：模型服务与工作池

这里是消耗GPU资源的“重火力”阵地。我们不可能在一台服务器上部署一个模型实例来应对所有请求，所以需要组建一个“模型工作池”。

多实例部署：我们在多台配备GPU的服务器上，启动多个Screen Filter模型服务的实例。每个实例都加载相同的AI模型。使用Docker容器化部署，可以保证环境一致性。

任务消费：一组被称为“Worker”的进程（或容器）从消息队列中拉取任务。每个Worker进程独立运行，它拿到任务后，调用本机或网络上的模型服务实例进行推理。我们采用“拉”模式，Worker的数量可以根据队列长度动态调整（结合弹性伸缩组）。

GPU资源池化（高级玩法）：为了更精细地利用GPU，我们尝试了使用NVIDIA Triton Inference Server这类专门的模型推理服务。它可以在单块GPU上同时托管多个模型的不同版本，并支持动态批处理（Dynamic Batching）。也就是说，当多个Worker的请求在极短时间内到来时，Triton可以将这些请求自动合并成一个批次（Batch）送给GPU计算，这能极大提升GPU的利用率和整体吞吐量。比如，单独处理10张图片要100ms*10=1秒，而合并成一个批次处理可能只需要200ms。

3.4 记忆中枢：缓存与状态管理

用户的状态（如已累计的违规次数、当前使用的审核规则）需要被所有Worker快速访问。我们引入Redis作为集中式缓存和状态存储。

• 会话状态存储：以session:{user_id}:{exam_id}为Key，在Redis中存储一个Hash结构，包含违规记录、最后活动时间、当前审核模式等。
• 结果缓存：对于一些静态或半静态的审核规则结果（例如，对某个固定软件图标的识别），可以进行短期缓存，避免对同一内容重复进行模型推理。
• 分布式锁：在对某个用户的违规次数进行“读取-加1-写入”这类操作时，使用Redis分布式锁确保并发安全。
• 发布/订阅：当某个用户被判定为严重违规时，服务可以通过Redis的Pub/Sub功能实时通知监管后台或监考老师界面。

所有的持久化数据（如最终的违规记录、审核日志）会异步地存入MySQL或时序数据库中，用于事后查询和分析。

4. 关键策略与优化实践

有了组件，还需要正确的策略把它们串联起来，才能发挥最大效能。

4.1 连接管理与心跳保活

五千个WebSocket长连接，管理不好就是灾难。我们实现了以下机制：

• 连接网关映射：在Redis中记录每个连接与网关实例的映射关系。当连接断开或消息需要推送时，能快速定位。
• 心跳机制：客户端定期发送心跳包。服务端检测到心跳超时，则主动清理无效连接和对应的会话状态，释放资源。
• 优雅重连：网络波动时，客户端支持自动重连，并携带之前的会话ID，以恢复会话状态。

4.2 动态伸缩与弹性

我们利用云平台的弹性伸缩组（Auto Scaling Group）来实现：

• 模型Worker层伸缩：监控消息队列的积压消息数量。当积压超过阈值（如>1000），自动触发扩容，增加Worker实例；当积压很少且持续一段时间，则触发缩容。
• 网关层伸缩：监控网关服务器的CPU、内存和连接数。连接数过高时，自动扩容新的网关实例。
• 这种弹性能力，让我们在考试高峰期能自动准备足够的“算力”，在平时则能节省大量成本。

4.3 降级与熔断策略

不是所有情况都必须调用完整的AI模型。

• 本地规则过滤：在图片送入模型前，先进行简单的规则判断。例如，如果连续3帧图片的哈希值几乎没变，可能学生电脑卡住了，可以直接返回“屏幕无变化”，无需调用模型。
• 模型服务熔断：如果某个模型服务实例的错误率飙升或响应过慢，网关和Worker会暂时将其标记为不可用，将流量切换到其他健康实例。
• 结果缓存降级：当Redis缓存不可用时，可以降级为直接读写数据库，虽然慢一些，但保证了核心功能可用。

4.4 监控与告警

一个复杂的分布式系统，没有监控就是“睁眼瞎”。我们建立了全方位的监控：

• 基础设施监控：服务器CPU、内存、GPU利用率、网络IO。
• 服务监控：各组件（网关、Worker、模型服务）的QPS、成功率、延迟（P50, P95, P99）。
• 业务监控：实时在线人数、任务队列长度、平均处理延迟、违规事件触发率。
• 告警：对关键指标（如P99延迟>1秒、队列积压>5000、服务成功率<99.9%）设置告警，通过钉钉、短信等方式通知运维人员。

5. 总结

回顾整个架构设计，其核心思想可以概括为“分层解耦、异步缓冲、池化计算、状态外置”。

通过负载均衡和网关层应对海量连接，通过消息队列将瞬时流量平滑为匀速处理，通过模型工作池和资源池化技术最大化利用昂贵的GPU算力，最后通过集中式的缓存来管理分布式环境下的会话状态。这套组合拳，让我们成功地将VideoAgentTrek Screen Filter的服务能力，从几十并发提升到了数千并发。

在实际的在线考试压力测试中，这套架构平稳支撑了超过3000人同时在线、每秒上万帧的屏幕审核请求，端到端延迟稳定在300毫秒以内。当然，架构没有银弹，这套方案在带来高可用的同时，也增加了系统的复杂性，对运维和监控提出了更高要求。

如果你正在规划类似的实时AI处理平台，希望这个架构能为你提供一个可行的思路。从最关键的消息队列和异步化开始，逐步引入缓存、弹性伸缩等组件，小步快跑，持续迭代。毕竟，能让技术真正落地，稳定、高效地解决实际问题，才是我们工程师最大的成就感。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。