简介这是一套面向知识竞赛组织者与开发者的在线答题系统源码资源基于VC6.0与MFC框架开发配套Access数据库适合需要搭建竞赛平台或进行课程设计、二次开发的技术人员参考。压缩包共61个文件约7.68MB以cpp与h源文件为核心另有obj、pdb、ilk等编译中间文件以及mdf、ldf数据库文件、bmp与ico界面素材和dsp、dsw工程文件结构完整可直接编译运行。系统覆盖试题的添加、删除与修改参赛人员信息录入在线答题计时与自动评分并支持按答对数量、答题速度等维度生成动态排名同时包含通知消息、数据统计与安全隐私等模块。已有395人学习下载读者可从中获取完整的竞赛系统实现方案、数据库脚本与界面设计思路便于理解MFC与ADO数据库访问的具体用法快速完成系统维护、功能扩展或二次开发。1. 知识竞赛系统面试从答题到排名考官到底在盯什么很多人以为知识竞赛系统的面试就是问“怎么存题目”“怎么算分数”真坐到对面才发现考官根本不关心你能不能把题库表建出来。他们盯的是三件事答题过程怎么保证不崩、排名怎么保证不飘、高并发下怎么保证不丢分。这三件事对应的是消息队列、缓存一致性、分布式锁、幂等设计这些硬考点而不是增删改查。一份能拿高分的备考笔记必须先把考点分布摸清楚答题链路占四成排名与榜单占三成防作弊与幂等占两成剩下的才是基础数据模型。适合已经写过项目、但一被追问“为什么”就卡壳的人。下面按模块拆开讲每道题都给答题思路照着练就能用。2. 答题链路高频考点从提交到判分每一步都可能被追问2.1 答题提交接口的幂等设计面试官最爱问的第一道题用户手抖点了两次提交或者网络重试导致同一份答案发了两遍你怎么保证不重复计分这题考的是幂等不是“加个锁”就完事。答题思路分三层说。第一层客户端生成一个全局唯一的提交令牌随答案一起发到服务端服务端用 Redis 的SET key value NX EX做占位占位成功才继续处理失败直接返回上一次的结果。第二层数据库层面对(user_id, question_id, exam_id)建唯一索引作为最后一道防线防止缓存穿透后重复写入。第三层如果判分是异步的消息消费端也要用同一个令牌做去重保证“至少一次投递”不会变成“至少一次计分”。import redis import hashlib r redis.Redis() def submit_answer(user_id, exam_id, question_id, answer, token): # 用提交令牌做幂等键NX 保证只有第一次能占位成功 idem_key fidem:{exam_id}:{user_id}:{token} # EX 设置过期时间防止死键堆积 ok r.set(idem_key, 1, nxTrue, ex300) if not ok: # 已经处理过直接返回缓存里的结果 return r.get(fresult:{idem_key}) # 真正落库判分 score judge(question_id, answer) r.set(fresult:{idem_key}, score, ex300) return score这段代码的关键在nxTrue和ex300。nx保证原子性占位ex防止用户一直不重试导致键永久占用。注意判分逻辑要放在占位成功之后否则占位失败也会白算一次。面试时如果只答“用 Redis 做幂等”考官会追问“Redis 挂了怎么办”这时候要补数据库唯一索引兜底才算答完整。2.2 判分服务的同步与异步选择第二道高频题判分是同步返回还是异步返回这题没有标准答案但答错方向直接暴露你没想过流量。答题思路客观题、题量小、要求即时出分走同步接口里直接算响应控制在 200ms 内。主观题、题量大、或者有复杂规则比如多选漏选给一半分走异步提交后返回一个task_id客户端轮询或走长连接拿结果。异步方案要讲清楚消息队列选型、消费失败重试、以及结果回写后怎么通知前端。面试官最想听的是你对“用户等多久会烦躁”的判断。一般超过 1.5 秒的等待用户就会怀疑系统卡了。所以同步判分只做轻量计算重逻辑一律异步。如果考官追问“异步怎么保证用户看到分数”答提交后前端展示“判分中”用task_id每 500ms 轮询一次最多轮询 10 次超时提示“稍后在成绩页查看”。这样既不让用户干等也不给服务端压力。2.3 答题过程中的断线续答第三道题很实战用户答到第 8 题突然断网重新进来怎么恢复进度这题考的是状态存储和恢复策略。答题思路每答一题客户端本地先存一份同时异步上报服务端。服务端用user_id exam_id作为 key存一个答题进度对象包含已答题号、已选答案、剩余时间。恢复时优先读服务端服务端没有再用本地。注意剩余时间不能只靠客户端算否则改本地时间就能作弊服务端要记录开考时间戳恢复时用服务端时间重新计算剩余秒数。提示进度存储别用关系库一行行更新用 Redis Hash 存整个进度对象一次读写搞定还能顺带设置和考试时长一致的过期时间。3. 排名与榜单高频考点实时榜、最终榜、并列名次怎么答3.1 实时排名的数据结构选型排名题第一问实时榜单怎么实现很多人张口就是“数据库 order by”考官一听就知道没做过高并发。答题思路用 Redis 的有序集合 ZSET。ZADD更新分数ZREVRANGE取前 N 名ZREVRANK查某人排名全是 O(log N)。分数相同时按提交时间早的排前面可以把分数和时间戳拼成一个复合分值比如score * 10^10 - timestamp这样分数高的自然靠前同分时时间早的靠前。# 更新用户分数exam:1001:rank 是榜单键 ZADD exam:1001:rank 950 user:2001 # 取前 10 名WITHSCORES 带分数 ZREVRANGE exam:1001:rank 0 9 WITHSCORES # 查 user:2001 的排名从 0 开始算 ZREVRANK exam:1001:rank user:2001参数说明ZADD的分数是 double注意精度分数差距小于 1e-10 会出问题所以分数最好用整数。ZREVRANGE的起止索引是闭区间取前 10 是0 9。如果榜单要分页用ZREVRANGE key start stop配合页码算偏移。面试时如果被问“ZSET 底层是什么”答跳表加哈希表跳表保证范围查询快哈希表保证 O(1) 查分数。3.2 最终榜单与实时榜单的差异处理第二问考试结束后最终榜单怎么定实时榜和最终榜能一样吗答题思路不能一样。实时榜追求快允许短暂不一致最终榜追求准必须等所有判分完成、所有异步任务落库后再生成。做法是考试结束后发一个“结算”消息消费端把所有答题记录聚合算出最终分数再写入一个独立的最终榜单键。最终榜单生成后加个标记位前端读榜时先看标记位有最终榜就读最终榜没有才读实时榜。面试官想听的是你对“结算时机”的把控。如果判分有异步任务结算必须等所有任务完成可以用一个计数器记录待完成任务数归零时触发结算。别小看这个细节很多考生答“考试结束就生成最终榜”考官会追问“异步判分还没完怎么办”这时候就露馅了。3.3 并列名次的处理逻辑第三问两个人分数一样排名怎么算这题考的是业务理解和细节。答题思路先明确业务规则。常见两种一种是并列都算第 5 名下一个是第 7 名另一种是打破并列按提交时间早的排前面。面试时先反问“业务上要求并列还是打破”再给方案。如果并列ZSET 里分数相同ZREVRANK返回的排名是任意的需要额外查同分人数来修正。如果打破并列就用前面说的复合分值。注意并列名次在发奖场景下很敏感第 5 名并列两个奖品怎么发面试时主动提这个业务点考官会觉得你考虑得全。4. 防作弊与高并发易错点这些题一错就丢分4.1 易错点一用数据库自增做主键还沾沾自喜错在哪答题记录表用自增 ID高并发下自增锁竞争严重插入变慢。为什么错知识竞赛的答题写入是高频操作自增主键在并发插入时会产生锁等待QPS 上不去。怎么答对用雪花算法生成分布式 ID或者用user_id exam_id question_id做联合主键避免单点自增。面试时如果被问“为什么不用自增”把锁竞争和分库分表扩展性两点讲清楚。4.2 易错点二排行榜用数据库 order by 还觉得没问题错在哪每次查榜都select * from score order by score desc limit 10数据量一大就慢查询。为什么错排序无法命中索引时走全表扫描几千人同时看榜直接拖垮数据库。怎么答对用 Redis ZSET 扛读数据库只做持久化榜单读请求全部走缓存。如果考官追问“缓存和数据库不一致怎么办”答写分数时先写数据库再更新 ZSET用消息队列保证最终一致读榜只读 ZSET。4.3 易错点三判分逻辑写在接口里还觉得挺清晰错在哪判分规则和接口耦合改一个规则要动接口代码回归测试全量跑。为什么错知识竞赛的判分规则经常变比如多选从“全对得分”改成“漏选得一半”硬编码在接口里就是灾难。怎么答对把判分规则抽成策略模式每种题型一个策略类接口只负责调度。面试时补一句“规则配置化运营后台可改”考官会高看一眼。4.4 易错点四忽略答题时间的服务端校验错在哪剩余时间只在前端倒计时服务端不校验用户改本地时间就能多答题。为什么错这是安全漏洞不是功能问题。怎么答对服务端记录开考时间戳和考试时长每次提交答案时校验当前时间 - 开考时间 考试时长超时直接拒绝。如果考官问“网络延迟导致提交晚了一秒怎么办”答允许一个小的宽限期比如 3 秒宽限期内提交仍有效但记录异常供风控排查。4.5 易错点五消息队列消费失败直接丢弃错在哪异步判分消息消费失败没有重试用户分数丢了。为什么错消息队列的“至少一次”语义要求消费端必须幂等且可重试直接丢弃等于数据丢失。怎么答对消费失败进死信队列人工介入或定时重试重试时用幂等键去重。面试时如果被问“重试多少次”答一般 3 次间隔递增超过进死信队列并告警。5. 答题技巧与押题思路一套能直接套用的答题框架面试知识竞赛系统最怕的是东一榔头西一棒子。我后来总结了一个四步框架每次遇到系统设计题都强制走一遍先问业务场景再定数据模型然后拆读写链路最后补异常和边界。这套框架能覆盖八成以上的追问。第一步问业务场景。别急着答技术方案先确认考试规模、并发量、是否实时出分、有没有防作弊要求。比如“这场考试是 100 人还是 10 万人”直接决定你用不用消息队列和分布式缓存。面试官抛出题目后你反问一句“大概什么量级”他会觉得你靠谱。第二步定数据模型。题库表、答题记录表、榜单表三张核心表先画出来。答题记录表用联合唯一索引防重榜单表可以不存在数据库里直接 Redis ZSET。这一步要讲清楚每张表的读写比例题库读多写少答题记录写多读少榜单读多写少。第三步拆读写链路。写链路提交答案 → 幂等校验 → 判分 → 写记录 → 更新榜单。读链路查题目 → 查进度 → 查榜单。每条链路标出瓶颈点写链路的瓶颈在判分和榜单更新读链路的瓶颈在榜单查询。瓶颈点就是你要加缓存、加队列的地方。第四步补异常和边界。断线怎么办、重复提交怎么办、判分失败怎么办、榜单并列怎么办、缓存挂了怎么办。每个异常给一个兜底方案不用多复杂但要有。押题方向上优先准备三道题设计一个支持 10 万人同时答题的知识竞赛系统实时榜单怎么实现同分怎么处理答题提交的幂等和防作弊怎么做。这三道题练熟基本覆盖核心考点。另外准备一个自己项目里的翻车经历比如“当时榜单用数据库排序压测直接崩了后来换 ZSET 才扛住”面试官对血泪经验比对标准答案更感兴趣。提示答题时多用“我会先…再…最后…”的句式让考官跟上你的思路。别一上来就堆技术名词先讲清楚为什么选这个方案再讲怎么实现。从那以后我每次准备面试都强制自己把每个系统设计题按这四步写一遍写完再对着镜子讲一遍讲不顺的地方就是没想透的地方。希望帮到你。本文还有配套的精品资源点击获取 简介这是一套面向知识竞赛组织者与开发者的在线答题系统源码资源基于VC6.0与MFC框架开发配套Access数据库适合需要搭建竞赛平台或进行课程设计、二次开发的技术人员参考。压缩包共61个文件约7.68MB以cpp与h源文件为核心另有obj、pdb、ilk等编译中间文件以及mdf、ldf数据库文件、bmp与ico界面素材和dsp、dsw工程文件结构完整可直接编译运行。系统覆盖试题的添加、删除与修改参赛人员信息录入在线答题计时与自动评分并支持按答对数量、答题速度等维度生成动态排名同时包含通知消息、数据统计与安全隐私等模块。已有395人学习下载读者可从中获取完整的竞赛系统实现方案、数据库脚本与界面设计思路便于理解MFC与ADO数据库访问的具体用法快速完成系统维护、功能扩展或二次开发。1. 知识竞赛系统面试从答题到排名考官到底在盯什么很多人以为知识竞赛系统的面试就是问“怎么存题目”“怎么算分数”真坐到对面才发现考官根本不关心你能不能把题库表建出来。他们盯的是三件事答题过程怎么保证不崩、排名怎么保证不飘、高并发下怎么保证不丢分。这三件事对应的是消息队列、缓存一致性、分布式锁、幂等设计这些硬考点而不是增删改查。一份能拿高分的备考笔记必须先把考点分布摸清楚答题链路占四成排名与榜单占三成防作弊与幂等占两成剩下的才是基础数据模型。适合已经写过项目、但一被追问“为什么”就卡壳的人。下面按模块拆开讲每道题都给答题思路照着练就能用。2. 答题链路高频考点从提交到判分每一步都可能被追问2.1 答题提交接口的幂等设计面试官最爱问的第一道题用户手抖点了两次提交或者网络重试导致同一份答案发了两遍你怎么保证不重复计分这题考的是幂等不是“加个锁”就完事。答题思路分三层说。第一层客户端生成一个全局唯一的提交令牌随答案一起发到服务端服务端用 Redis 的SET key value NX EX做占位占位成功才继续处理失败直接返回上一次的结果。第二层数据库层面对(user_id, question_id, exam_id)建唯一索引作为最后一道防线防止缓存穿透后重复写入。第三层如果判分是异步的消息消费端也要用同一个令牌做去重保证“至少一次投递”不会变成“至少一次计分”。import redis import hashlib r redis.Redis() def submit_answer(user_id, exam_id, question_id, answer, token): # 用提交令牌做幂等键NX 保证只有第一次能占位成功 idem_key fidem:{exam_id}:{user_id}:{token} # EX 设置过期时间防止死键堆积 ok r.set(idem_key, 1, nxTrue, ex300) if not ok: # 已经处理过直接返回缓存里的结果 return r.get(fresult:{idem_key}) # 真正落库判分 score judge(question_id, answer) r.set(fresult:{idem_key}, score, ex300) return score这段代码的关键在nxTrue和ex300。nx保证原子性占位ex防止用户一直不重试导致键永久占用。注意判分逻辑要放在占位成功之后否则占位失败也会白算一次。面试时如果只答“用 Redis 做幂等”考官会追问“Redis 挂了怎么办”这时候要补数据库唯一索引兜底才算答完整。2.2 判分服务的同步与异步选择第二道高频题判分是同步返回还是异步返回这题没有标准答案但答错方向直接暴露你没想过流量。答题思路客观题、题量小、要求即时出分走同步接口里直接算响应控制在 200ms 内。主观题、题量大、或者有复杂规则比如多选漏选给一半分走异步提交后返回一个task_id客户端轮询或走长连接拿结果。异步方案要讲清楚消息队列选型、消费失败重试、以及结果回写后怎么通知前端。面试官最想听的是你对“用户等多久会烦躁”的判断。一般超过 1.5 秒的等待用户就会怀疑系统卡了。所以同步判分只做轻量计算重逻辑一律异步。如果考官追问“异步怎么保证用户看到分数”答提交后前端展示“判分中”用task_id每 500ms 轮询一次最多轮询 10 次超时提示“稍后在成绩页查看”。这样既不让用户干等也不给服务端压力。2.3 答题过程中的断线续答第三道题很实战用户答到第 8 题突然断网重新进来怎么恢复进度这题考的是状态存储和恢复策略。答题思路每答一题客户端本地先存一份同时异步上报服务端。服务端用user_id exam_id作为 key存一个答题进度对象包含已答题号、已选答案、剩余时间。恢复时优先读服务端服务端没有再用本地。注意剩余时间不能只靠客户端算否则改本地时间就能作弊服务端要记录开考时间戳恢复时用服务端时间重新计算剩余秒数。提示进度存储别用关系库一行行更新用 Redis Hash 存整个进度对象一次读写搞定还能顺带设置和考试时长一致的过期时间。3. 排名与榜单高频考点实时榜、最终榜、并列名次怎么答3.1 实时排名的数据结构选型排名题第一问实时榜单怎么实现很多人张口就是“数据库 order by”考官一听就知道没做过高并发。答题思路用 Redis 的有序集合 ZSET。ZADD更新分数ZREVRANGE取前 N 名ZREVRANK查某人排名全是 O(log N)。分数相同时按提交时间早的排前面可以把分数和时间戳拼成一个复合分值比如score * 10^10 - timestamp这样分数高的自然靠前同分时时间早的靠前。# 更新用户分数exam:1001:rank 是榜单键 ZADD exam:1001:rank 950 user:2001 # 取前 10 名WITHSCORES 带分数 ZREVRANGE exam:1001:rank 0 9 WITHSCORES # 查 user:2001 的排名从 0 开始算 ZREVRANK exam:1001:rank user:2001参数说明ZADD的分数是 double注意精度分数差距小于 1e-10 会出问题所以分数最好用整数。ZREVRANGE的起止索引是闭区间取前 10 是0 9。如果榜单要分页用ZREVRANGE key start stop配合页码算偏移。面试时如果被问“ZSET 底层是什么”答跳表加哈希表跳表保证范围查询快哈希表保证 O(1) 查分数。3.2 最终榜单与实时榜单的差异处理第二问考试结束后最终榜单怎么定实时榜和最终榜能一样吗答题思路不能一样。实时榜追求快允许短暂不一致最终榜追求准必须等所有判分完成、所有异步任务落库后再生成。做法是考试结束后发一个“结算”消息消费端把所有答题记录聚合算出最终分数再写入一个独立的最终榜单键。最终榜单生成后加个标记位前端读榜时先看标记位有最终榜就读最终榜没有才读实时榜。面试官想听的是你对“结算时机”的把控。如果判分有异步任务结算必须等所有任务完成可以用一个计数器记录待完成任务数归零时触发结算。别小看这个细节很多考生答“考试结束就生成最终榜”考官会追问“异步判分还没完怎么办”这时候就露馅了。3.3 并列名次的处理逻辑第三问两个人分数一样排名怎么算这题考的是业务理解和细节。答题思路先明确业务规则。常见两种一种是并列都算第 5 名下一个是第 7 名另一种是打破并列按提交时间早的排前面。面试时先反问“业务上要求并列还是打破”再给方案。如果并列ZSET 里分数相同ZREVRANK返回的排名是任意的需要额外查同分人数来修正。如果打破并列就用前面说的复合分值。注意并列名次在发奖场景下很敏感第 5 名并列两个奖品怎么发面试时主动提这个业务点考官会觉得你考虑得全。4. 防作弊与高并发易错点这些题一错就丢分4.1 易错点一用数据库自增做主键还沾沾自喜错在哪答题记录表用自增 ID高并发下自增锁竞争严重插入变慢。为什么错知识竞赛的答题写入是高频操作自增主键在并发插入时会产生锁等待QPS 上不去。怎么答对用雪花算法生成分布式 ID或者用user_id exam_id question_id做联合主键避免单点自增。面试时如果被问“为什么不用自增”把锁竞争和分库分表扩展性两点讲清楚。4.2 易错点二排行榜用数据库 order by 还觉得没问题错在哪每次查榜都select * from score order by score desc limit 10数据量一大就慢查询。为什么错排序无法命中索引时走全表扫描几千人同时看榜直接拖垮数据库。怎么答对用 Redis ZSET 扛读数据库只做持久化榜单读请求全部走缓存。如果考官追问“缓存和数据库不一致怎么办”答写分数时先写数据库再更新 ZSET用消息队列保证最终一致读榜只读 ZSET。4.3 易错点三判分逻辑写在接口里还觉得挺清晰错在哪判分规则和接口耦合改一个规则要动接口代码回归测试全量跑。为什么错知识竞赛的判分规则经常变比如多选从“全对得分”改成“漏选得一半”硬编码在接口里就是灾难。怎么答对把判分规则抽成策略模式每种题型一个策略类接口只负责调度。面试时补一句“规则配置化运营后台可改”考官会高看一眼。4.4 易错点四忽略答题时间的服务端校验错在哪剩余时间只在前端倒计时服务端不校验用户改本地时间就能多答题。为什么错这是安全漏洞不是功能问题。怎么答对服务端记录开考时间戳和考试时长每次提交答案时校验当前时间 - 开考时间 考试时长超时直接拒绝。如果考官问“网络延迟导致提交晚了一秒怎么办”答允许一个小的宽限期比如 3 秒宽限期内提交仍有效但记录异常供风控排查。4.5 易错点五消息队列消费失败直接丢弃错在哪异步判分消息消费失败没有重试用户分数丢了。为什么错消息队列的“至少一次”语义要求消费端必须幂等且可重试直接丢弃等于数据丢失。怎么答对消费失败进死信队列人工介入或定时重试重试时用幂等键去重。面试时如果被问“重试多少次”答一般 3 次间隔递增超过进死信队列并告警。5. 答题技巧与押题思路一套能直接套用的答题框架面试知识竞赛系统最怕的是东一榔头西一棒子。我后来总结了一个四步框架每次遇到系统设计题都强制走一遍先问业务场景再定数据模型然后拆读写链路最后补异常和边界。这套框架能覆盖八成以上的追问。第一步问业务场景。别急着答技术方案先确认考试规模、并发量、是否实时出分、有没有防作弊要求。比如“这场考试是 100 人还是 10 万人”直接决定你用不用消息队列和分布式缓存。面试官抛出题目后你反问一句“大概什么量级”他会觉得你靠谱。第二步定数据模型。题库表、答题记录表、榜单表三张核心表先画出来。答题记录表用联合唯一索引防重榜单表可以不存在数据库里直接 Redis ZSET。这一步要讲清楚每张表的读写比例题库读多写少答题记录写多读少榜单读多写少。第三步拆读写链路。写链路提交答案 → 幂等校验 → 判分 → 写记录 → 更新榜单。读链路查题目 → 查进度 → 查榜单。每条链路标出瓶颈点写链路的瓶颈在判分和榜单更新读链路的瓶颈在榜单查询。瓶颈点就是你要加缓存、加队列的地方。第四步补异常和边界。断线怎么办、重复提交怎么办、判分失败怎么办、榜单并列怎么办、缓存挂了怎么办。每个异常给一个兜底方案不用多复杂但要有。押题方向上优先准备三道题设计一个支持 10 万人同时答题的知识竞赛系统实时榜单怎么实现同分怎么处理答题提交的幂等和防作弊怎么做。这三道题练熟基本覆盖核心考点。另外准备一个自己项目里的翻车经历比如“当时榜单用数据库排序压测直接崩了后来换 ZSET 才扛住”面试官对血泪经验比对标准答案更感兴趣。提示答题时多用“我会先…再…最后…”的句式让考官跟上你的思路。别一上来就堆技术名词先讲清楚为什么选这个方案再讲怎么实现。从那以后我每次准备面试都强制自己把每个系统设计题按这四步写一遍写完再对着镜子讲一遍讲不顺的地方就是没想透的地方。希望帮到你。本文还有配套的精品资源点击获取