簡(jiǎn)介這是一套面向教育機(jī)構(gòu)、培訓(xùn)平臺(tái)及知識(shí)競(jìng)賽組織者的在線考試答題系統(tǒng)源碼適用于考試測(cè)評(píng)、日常刷題、活動(dòng)競(jìng)答與題庫建設(shè)等多場(chǎng)景兼顧教師出題管理與考生作答體驗(yàn)。資源包共2000個(gè)文件主體為10443個(gè)PHP后端邏輯文件含題庫、用戶、考試核心模塊輔以427個(gè)JS交互腳本、73個(gè)CSS樣式文件、194個(gè)HTML前端頁面及88個(gè)WXML/WXSS微信小程序適配文件體現(xiàn)B/S架構(gòu)與跨端兼容設(shè)計(jì)另含SQL數(shù)據(jù)庫腳本、配置文件與日志模板總大小37.93MB。已有153人學(xué)習(xí)下載開發(fā)者可基于完整目錄結(jié)構(gòu)快速掌握系統(tǒng)分層邏輯復(fù)用題庫管理、隨機(jī)組卷、自動(dòng)評(píng)分與防作弊等核心功能模塊并通過源碼定制角色權(quán)限、擴(kuò)展題型或?qū)右苿?dòng)端。 一次偶然的需求碰撞讓我徹底改寫了這類產(chǎn)品的架構(gòu)認(rèn)知。一開始我只是給一家駕校做科目一模擬考試系統(tǒng)上線后不到三個(gè)月同一套底層陸續(xù)被教育機(jī)構(gòu)、銀行工會(huì)、商場(chǎng)活動(dòng)方看中問法幾乎一致“能不能加個(gè)刷題模式”“能不能做團(tuán)隊(duì)知識(shí)競(jìng)賽”“能不能搞一個(gè)答題抽獎(jiǎng)活動(dòng)”我當(dāng)時(shí)的第一反應(yīng)是“要重寫”但真正動(dòng)手拆解之后才發(fā)現(xiàn)所謂在線考試答題系統(tǒng)本質(zhì)就三件事題庫管理、答題引擎、結(jié)果統(tǒng)計(jì)外層所有五花八門的功能只是對(duì)不同場(chǎng)景的規(guī)則包裝。這篇文章把我這些年在這種“考試、答題、刷題、知識(shí)競(jìng)賽、活動(dòng)答題、題庫”多場(chǎng)景需求里沉淀下來的系統(tǒng)設(shè)計(jì)思路、核心表結(jié)構(gòu)、踩坑記錄和上線經(jīng)驗(yàn)完整梳理一遍。適合兩類人看一類是準(zhǔn)備自己開發(fā)答題類產(chǎn)品的技術(shù)同學(xué)另一類是需要做技術(shù)選型或評(píng)估外包方案的培訓(xùn)機(jī)構(gòu)、企業(yè)HR、活動(dòng)運(yùn)營(yíng)負(fù)責(zé)人。文章不準(zhǔn)備只停留在理論層面所有內(nèi)容都是可以被直接落地的。1. 為什么一套系統(tǒng)能同時(shí)扛住考試、刷題、競(jìng)賽和活動(dòng)答題1.1 先看清四種場(chǎng)景的本質(zhì)差異很多人一聽“多場(chǎng)景復(fù)用”就覺得是過度設(shè)計(jì)但實(shí)際上這類系統(tǒng)之所以能復(fù)用是因?yàn)樗袌?chǎng)景都共享同一個(gè)答題閉環(huán)出題、作答、判分、出結(jié)果。區(qū)別只在于四個(gè)維度的規(guī)則不同。我做過一個(gè)對(duì)比表把四個(gè)核心場(chǎng)景拆開看維度考試刷題知識(shí)競(jìng)賽活動(dòng)答題賬號(hào)要求強(qiáng)制登錄實(shí)名關(guān)聯(lián)弱登錄游客可刷必須登錄可能組隊(duì)通常無感登錄或微信授權(quán)答題節(jié)奏嚴(yán)格計(jì)時(shí)到時(shí)自動(dòng)交卷自由節(jié)奏隨時(shí)暫停搶答/限時(shí)/同步開始輕快單題限時(shí)短判分規(guī)則客觀題主觀題混合嚴(yán)謹(jǐn)客觀題為主即時(shí)判定按積分計(jì)時(shí)雙重排名正確給分錯(cuò)誤立即提示結(jié)果訴求成績(jī)單、及格率、歸檔錯(cuò)題本、進(jìn)度、知識(shí)點(diǎn)掌握度榜單、晉級(jí)、獎(jiǎng)品中獎(jiǎng)概率、分享裂變單看這張表你會(huì)發(fā)現(xiàn)如果照著四個(gè)場(chǎng)景獨(dú)立開發(fā)生命周期題目資源會(huì)嚴(yán)重割裂運(yùn)營(yíng)人員要維護(hù)四套題庫、四套用戶體系、四套統(tǒng)計(jì)報(bào)表這是巨大的重復(fù)投入。而如果做一套底層只是在最外層提供不同的場(chǎng)景配置模板那所有題目、用戶、答題記錄、統(tǒng)計(jì)口徑都能打通。所以這套系統(tǒng)的架構(gòu)思路從一開始就是統(tǒng)一題庫、統(tǒng)一答題引擎、隔離場(chǎng)景配置。題庫和引擎是固定的能力底座場(chǎng)景層只是配置文件的不同組合。1.2 從需求反推出一套可復(fù)用的系統(tǒng)架構(gòu)我在項(xiàng)目的第二版本里把系統(tǒng)拆成了四個(gè)中心這個(gè)劃分后續(xù)被驗(yàn)證非?？煽款}庫中心負(fù)責(zé)題目的增刪改查、分類、標(biāo)簽、難度、答案解析、知識(shí)點(diǎn)關(guān)聯(lián)以及多租戶數(shù)據(jù)隔離。答題引擎負(fù)責(zé)一場(chǎng)考試/一次刷題會(huì)話的狀態(tài)流轉(zhuǎn)包括開始、暫停、提交、超時(shí)判定、斷點(diǎn)續(xù)答、防重復(fù)提交。場(chǎng)景配置中心把考試限制、刷題策略、競(jìng)賽規(guī)則、活動(dòng)權(quán)益抽象成配置項(xiàng)一個(gè)場(chǎng)景就是一組配置的實(shí)例。數(shù)據(jù)統(tǒng)計(jì)中心統(tǒng)一采集答題行為、判分結(jié)果、時(shí)間消耗輸出成績(jī)單、排行榜、知識(shí)點(diǎn)薄弱項(xiàng)、題目質(zhì)量分析。這四大中心的劃分不是拍腦袋而是從一次真實(shí)事故反推出來的。早期我把一堆功能塞在一個(gè)“考試模塊”里結(jié)果駕校要加刷題模式時(shí)發(fā)現(xiàn)刷題記錄和考試記錄混在了一張表里統(tǒng)計(jì)報(bào)表怎么算都不對(duì)最后只能加班拆表。所以現(xiàn)在我對(duì)這類系統(tǒng)的建議是答題會(huì)話和答題結(jié)果必須拆開建模一場(chǎng)考試、一次刷題練習(xí)、一場(chǎng)競(jìng)賽搶答本質(zhì)都是不同狀態(tài)下的答題會(huì)話統(tǒng)一掛靠在同一個(gè)引擎下業(yè)務(wù)層再根據(jù)場(chǎng)景類型做差異化處理。2. 題庫與組卷模塊所有場(chǎng)景的地基2.1 題型設(shè)計(jì)的邊界別把自己鎖死在單選題上題庫最容易犯的錯(cuò)誤是一開始只設(shè)計(jì)單選和多選等客戶提出填空、判斷、簡(jiǎn)答題的時(shí)候發(fā)現(xiàn)數(shù)據(jù)庫結(jié)構(gòu)完全不支持只能打補(bǔ)丁。我建議的題型模型至少要留出這些擴(kuò)展位客觀題單選、多選、判斷、不定項(xiàng)選擇判分規(guī)則由選項(xiàng)組合決定。主觀題簡(jiǎn)答、論述、案例分析系統(tǒng)只做人工評(píng)分輔助不硬核判分。半自動(dòng)題填空題、匹配題、排序題這類題的判分可以采用寬松匹配規(guī)則比如關(guān)鍵詞命中給分。在數(shù)據(jù)庫設(shè)計(jì)上題目主表和子表是可以縱向擴(kuò)展的。題目主表存放題干、題型、難度、知識(shí)點(diǎn)、解析、所屬題庫ID選擇題子表存放選項(xiàng)列表和正確選項(xiàng)填空題子表存放多個(gè)空位的答案。這樣每次新增題型只需要擴(kuò)展子表不需要改動(dòng)主表結(jié)構(gòu)。我在處理填空題的答案匹配時(shí)吃過一次大虧。題目答案是“TCP/IP”考生填的是“tcp/ip”按精確匹配就判錯(cuò)但實(shí)際按語義兩者是同一個(gè)答案。后來我加了一個(gè)答案匹配規(guī)則配置項(xiàng)允許多個(gè)等價(jià)答案并支持忽略大小寫、忽略首尾空格、忽略全半角。這個(gè)看起來不起眼的小功能在真實(shí)考試中能減少大量的人工申訴。2.2 人工組卷與智能抽題的取舍題庫建設(shè)好之后組卷策略是另一個(gè)關(guān)鍵點(diǎn)。考試類場(chǎng)景通常需要人工組卷保證試卷難度穩(wěn)定而刷題和競(jìng)賽場(chǎng)景尤其是活動(dòng)答題更依賴智能抽題做到每次會(huì)話題目不重復(fù)、難度符合用戶水平。智能抽題的實(shí)現(xiàn)邏輯不算復(fù)雜核心是帶權(quán)重的隨機(jī)選取。我通常按三個(gè)維度做約束知識(shí)點(diǎn)占比、難度分布、題型分布。偽代碼邏輯大概是這樣的function generatePaper(rule): remaining rule.totalCount selected [] for dimension in rule.dimensions: // 知識(shí)點(diǎn)、難度、題型 quota dimension.ratio * rule.totalCount pool queryQuestions(dimension, rule.excludeIds) picked shuffle(pool).take(quota) selected.add(picked) rule.excludeIds.add(picked.id) remaining - picked.size // 剩余名額從全量池中隨機(jī)補(bǔ)齊 selected.add(shuffle(queryAll(rule)).take(remaining)) return shuffle(selected)這里有一個(gè)非常容易被忽略的細(xì)節(jié)抽題必須支持排除已經(jīng)出現(xiàn)在同一場(chǎng)會(huì)話中的題目。如果不做排除用戶刷題時(shí)連續(xù)遇到重復(fù)題目的概率會(huì)很高尤其是題庫量小的時(shí)候體驗(yàn)極差。我一般會(huì)在Redis里維護(hù)一個(gè)“本場(chǎng)已出題ID集合”每次抽完題都寫入超時(shí)后自動(dòng)過期。人工組卷則強(qiáng)調(diào)可控性和穩(wěn)定性我會(huì)給組卷人提供一個(gè)實(shí)時(shí)預(yù)覽面板實(shí)時(shí)顯示當(dāng)前試卷的知識(shí)點(diǎn)分布比例和平均難度預(yù)估幫助組卷人在保存前就調(diào)整到目標(biāo)曲線。這個(gè)功能開發(fā)成本不高但客戶滿意度提升非常明顯。2.3 題庫安全與權(quán)限隔離題庫是這類系統(tǒng)的核心資產(chǎn)尤其是培訓(xùn)機(jī)構(gòu)題庫泄露等于核心競(jìng)爭(zhēng)力流失。我做過三層的安全設(shè)計(jì)數(shù)據(jù)層隔離每個(gè)租戶/機(jī)構(gòu)有獨(dú)立的題庫空間通過庫ID字段隔離查詢鏈路里強(qiáng)制帶上租戶ID防止越權(quán)訪問。接口層權(quán)限題目詳情接口和試卷查看接口做權(quán)限分級(jí)?？忌荒芸吹疆?dāng)前答卷中的題目不能通過遍歷題號(hào)獲取全部題目只有出題人和管理員能看到答案與解析。展示層防復(fù)制針對(duì)高價(jià)值題目前端限制右鍵菜單和文本選擇部分客戶會(huì)要求對(duì)題目文本做切片渲染防止直接爬取整題。還有一點(diǎn)是關(guān)于圖片題目的處理。很多實(shí)操類考試的題目是圖片版比如汽車零部件識(shí)別、電路圖判斷。圖片題目最大的風(fēng)險(xiǎn)是容易被批量下載建議默認(rèn)走帶簽名的臨時(shí)URL訪問URL有效期設(shè)為10分鐘而不是直接在頁面里暴露永久資源地址。3. 答題引擎的設(shè)計(jì)一場(chǎng)考試到底要存什么狀態(tài)3.1 一場(chǎng)答題會(huì)話的生命周期管理答題引擎是整個(gè)系統(tǒng)的“心臟”它的核心職責(zé)是把一場(chǎng)考試的狀態(tài)管清楚。我常用的狀態(tài)設(shè)計(jì)是IDLE待開始試卷已分配考生未進(jìn)入。IN_PROGRESS進(jìn)行中考生已進(jìn)入計(jì)時(shí)開始答案實(shí)時(shí)持久化。PAUSED暫停僅用于刷題場(chǎng)景考試類場(chǎng)景一般不允許暫停。SUBMITTED已提交考生主動(dòng)交卷或系統(tǒng)自動(dòng)交卷進(jìn)入判分流程。SCORED已判分判分完成成績(jī)可查詢。ARCHIVED已歸檔結(jié)果鎖定不可修改。我在狀態(tài)設(shè)計(jì)上最主要的經(jīng)驗(yàn)是狀態(tài)流轉(zhuǎn)一定要放在服務(wù)端做不能依賴前端判斷。之前有個(gè)版本把“是否顯示交卷按鈕”放在前端控制結(jié)果有用戶通過瀏覽器調(diào)試把交卷按鈕撈出來未答完就提前交卷了。后來改成所有交卷操作都走后端校驗(yàn)后端判斷當(dāng)前會(huì)話狀態(tài)、剩余時(shí)間、已答題數(shù)才允許交卷。3.2 時(shí)間控制倒計(jì)時(shí)的三個(gè)大坑時(shí)間控制是考試系統(tǒng)里最容易出錯(cuò)的地方我踩過的坑基本可以歸納為三個(gè)第一個(gè)坑前端倒計(jì)時(shí)不可信?？忌南到y(tǒng)時(shí)間可能不準(zhǔn)瀏覽器切后臺(tái)后定時(shí)器會(huì)被節(jié)流。所以正確做法是前端只負(fù)責(zé)展示“剩余秒數(shù)”真正的計(jì)時(shí)器由后端維護(hù)后端在會(huì)話開始時(shí)記錄start_time每次交卷請(qǐng)求把當(dāng)前時(shí)間和start_time做差值超過規(guī)定時(shí)長(zhǎng)直接拒絕并標(biāo)記超時(shí)提交。第二個(gè)坑斷網(wǎng)續(xù)答的時(shí)間補(bǔ)償?？忌诳荚囍袛嗑W(wǎng)重連重連時(shí)發(fā)現(xiàn)倒計(jì)時(shí)還在走肯定投訴。我的方案是前端在重連成功后上報(bào)斷網(wǎng)時(shí)間戳后端校驗(yàn)斷線時(shí)長(zhǎng)和上次心跳時(shí)間差值不超過閾值就把start_time向后順延。這個(gè)補(bǔ)償邏輯需要和“防作弊”——切后臺(tái)的時(shí)間判定——區(qū)分開否則就會(huì)出現(xiàn)考生故意斷網(wǎng)來暫停考試的漏洞。第三個(gè)坑自動(dòng)交卷的邊界條件。倒計(jì)時(shí)歸零那一刻正在作答但未保存的答案怎么處理我的方案是前端在倒計(jì)時(shí)還剩5秒時(shí)強(qiáng)制保存當(dāng)前答案并在超時(shí)后禁止繼續(xù)作答后端在收到自動(dòng)交卷請(qǐng)求后以最后一次持久化成功的答案為最終答案。這個(gè)機(jī)制要把“保存成功”的口令做成冪等的避免同一份答案重復(fù)提交產(chǎn)生兩條答題記錄。3.3 防作弊從主流程就開始設(shè)計(jì)而不是上線后補(bǔ)救防作弊是所有考試場(chǎng)景的剛需但也不要一開始就上人臉識(shí)別這種重方案性價(jià)比不高的功能反而會(huì)把考生惹毛。我建議按風(fēng)險(xiǎn)等級(jí)分層處理基礎(chǔ)層所有考試都開切換頁面離開考試頁面的次數(shù)記錄超出閾值觸發(fā)警告。進(jìn)階層重要考試開啟禁止切屏、強(qiáng)制全屏、鼠標(biāo)離開考試窗口提醒。嚴(yán)苛層高價(jià)值考試開啟人臉識(shí)別抽拍、AI監(jiān)考、第二攝像頭監(jiān)控可對(duì)接第三方審核服務(wù)。另外一個(gè)低成本但效果很好的措施是題目和選項(xiàng)亂序。給同一份試卷的每個(gè)考生隨機(jī)打亂題目順序和選項(xiàng)順序能極大降低鄰座偷瞄答案的概率。實(shí)現(xiàn)上只需要在會(huì)話生成時(shí)為每個(gè)考生生成一份亂序映射表判分時(shí)根據(jù)映射表還原正確選項(xiàng)。設(shè)備和IP維度也不能完全忽視。我在高價(jià)值考試中會(huì)采集設(shè)備指紋瀏覽器指紋、IP段、MAC地址等如果同一設(shè)備指紋在短時(shí)間內(nèi)關(guān)聯(lián)多個(gè)考生賬號(hào)自動(dòng)標(biāo)記異常記錄提交給人工審核。這個(gè)功能不阻斷流程但確實(shí)在真實(shí)場(chǎng)景里幫用戶抓出過代考行為。4. 多場(chǎng)景適配不同答題模式的差異化實(shí)現(xiàn)4.1 刷題模式先去掉考試那一堆限制刷題模式和考試模式最大的差異在于刷題不需要一次完整會(huì)話而是隨開隨練、隨練隨走。所以刷題模式我建議單獨(dú)實(shí)現(xiàn)一套輕量流程關(guān)鍵詞是“即存即走”。具體表現(xiàn)在三個(gè)方面做題即保存無需提交進(jìn)入刷題模式后每答一題立即保存答案不需要“交卷”動(dòng)作退出即完成。錯(cuò)題本閉環(huán)答錯(cuò)的題自動(dòng)進(jìn)錯(cuò)題本用戶可以從錯(cuò)題本重新刷刷對(duì)了可以移出錯(cuò)題本或標(biāo)記掌握。模式切換提供順序練習(xí)、隨機(jī)練習(xí)、背題模式直接顯示答案和解析不做判分、模擬測(cè)試四種入口。模擬測(cè)試走正式考試引擎其余走刷題引擎。我踩過的一個(gè)坑是刷題模式下用戶反復(fù)在同一道題上作答多次需要保留歷史記錄還是只保留最后一次如果全部保留數(shù)據(jù)暴增如果只保留最后一次錯(cuò)題本容易丟數(shù)據(jù)。后來我采取折中記錄每一次作答的明細(xì)用于統(tǒng)計(jì)掌握度但展示層以最后一次為準(zhǔn)。4.2 知識(shí)競(jìng)賽從單機(jī)答題變成實(shí)時(shí)互動(dòng)知識(shí)競(jìng)賽是“在線考試答題系統(tǒng)”里最有意思的場(chǎng)景因?yàn)樗鼜膯螜C(jī)走向了實(shí)時(shí)互動(dòng)技術(shù)難度會(huì)有一次躍遷。這里分為兩種常見競(jìng)賽形式一種是同步賽所有選手同一時(shí)間開始、同一時(shí)間結(jié)束按正確率和耗時(shí)排名。這種形式依賴后端統(tǒng)一計(jì)時(shí)器開賽時(shí)通過WebSocket批量推送開賽信令結(jié)束后統(tǒng)一回收成績(jī)。同步賽最怕的是網(wǎng)絡(luò)延遲導(dǎo)致大家開始時(shí)間不一致我建議前端在收到開賽信令后回傳本地時(shí)間戳后端校準(zhǔn)出一個(gè)分發(fā)補(bǔ)償值讓所有選手的倒計(jì)時(shí)終點(diǎn)對(duì)齊。另一種是搶答賽系統(tǒng)出一道題所有選手在規(guī)定時(shí)間內(nèi)搶答答對(duì)得分答錯(cuò)扣分。這個(gè)場(chǎng)景的技術(shù)核心是“公平性”誰先提交誰優(yōu)先。搶答提交的判定必須在服務(wù)端完成不能依賴前端時(shí)間戳而且要對(duì)極端情況做保護(hù)同一毫秒內(nèi)有兩個(gè)人提交如何判先我常用的方案是按請(qǐng)求到達(dá)網(wǎng)關(guān)的時(shí)間排序網(wǎng)關(guān)層的NTP同步周期控制在50ms以內(nèi)。競(jìng)賽還有一個(gè)和考試截然不同的設(shè)計(jì)點(diǎn)排行榜需要實(shí)時(shí)滾動(dòng)。這個(gè)功能建議使用Redis的有序集合ZSET維護(hù)分?jǐn)?shù)作為score時(shí)間戳作為附加值參與排序排行榜查詢走Redis不同步寫數(shù)據(jù)庫等競(jìng)賽結(jié)束后再把最終排名落庫。這樣即使榜單接口被高頻刷新數(shù)據(jù)庫也不會(huì)被打爆。4.3 活動(dòng)答題高并發(fā)下的抽題與風(fēng)控活動(dòng)答題是很多企業(yè)運(yùn)營(yíng)拉新的標(biāo)配玩法典型形態(tài)是“答對(duì)5道題參與抽獎(jiǎng)”。這類場(chǎng)景的流量特征和考試完全不同瞬時(shí)并發(fā)可能非常高而且安全需求相反——不是防作弊而是防刷題。我把活動(dòng)答題的技術(shù)方案拆成兩端性能端抽題盡量走緩存。活動(dòng)答題的題庫通常不大幾千道題撐死了。建議啟動(dòng)時(shí)把題目全量加載到Redis緩存抽題時(shí)直接內(nèi)存隨機(jī)而不是每次都查數(shù)據(jù)庫。活動(dòng)答題的接口要單獨(dú)做限流比如單用戶每秒最多1次請(qǐng)求超出直接丟棄。風(fēng)控端判斷“人機(jī)”是關(guān)鍵。活動(dòng)答題如果不做風(fēng)控很快會(huì)被腳本刷爆獎(jiǎng)品被機(jī)器人批量薅走。我建議至少做三層登錄門檻回調(diào)至少在抽獎(jiǎng)環(huán)節(jié)強(qiáng)制微信授權(quán)或手機(jī)號(hào)驗(yàn)證。頻率限制同一設(shè)備/IP/賬號(hào)限制每日答題次數(shù)超出后提示明日再來。行為校驗(yàn)單題作答耗時(shí)小于800毫秒的全部標(biāo)記為異常不參與抽獎(jiǎng)資格。還有一個(gè)運(yùn)營(yíng)向小細(xì)節(jié)活動(dòng)答題通常需要限制“每人只能中獎(jiǎng)一次”這個(gè)校驗(yàn)必須放在發(fā)獎(jiǎng)事務(wù)的最前面而且發(fā)獎(jiǎng)和扣減庫存要在一個(gè)事務(wù)里完成否則并發(fā)下會(huì)出現(xiàn)庫存扣成負(fù)數(shù)、幾個(gè)人同時(shí)領(lǐng)到最后一個(gè)獎(jiǎng)品的情況。5. 成績(jī)計(jì)算與數(shù)據(jù)統(tǒng)計(jì)判分只是開始5.1 判分邏輯的正確寫法很多剛?cè)胄械拈_發(fā)者會(huì)把判分邏輯寫得很簡(jiǎn)單正確答案和考生答案做一次字符串比較。這在只有單選題的小項(xiàng)目里可行但一旦題型變多這種寫法就廢了。我推薦的判分邏輯是按題型分派到不同的判定器每種題型有獨(dú)立的判定規(guī)則單選題考生答案ID與正確選項(xiàng)ID一致判對(duì)。多選題全部選對(duì)得滿分選錯(cuò)或漏選可以配置為0分或部分得分。判斷題布爾值相等即可。填空題字符串標(biāo)準(zhǔn)化去空格、轉(zhuǎn)小寫、全半角歸一化后再比較支持多個(gè)等價(jià)答案。主觀題系統(tǒng)不判分進(jìn)入人工評(píng)分隊(duì)列評(píng)分后支持成績(jī)修訂和申訴。這里我強(qiáng)烈建議一點(diǎn)判分過程要可追溯。每一個(gè)得分點(diǎn)都要記錄判分依據(jù)比如多選部分得分時(shí)得分明細(xì)里要寫明“選對(duì)2個(gè)漏選1個(gè)得50%分”。我在真實(shí)項(xiàng)目里被用戶質(zhì)問過“為什么我這題不是滿分”如果沒有判分依據(jù)根本說不清有了記錄之后申訴處理速度能快好幾倍。部分得分規(guī)則對(duì)考試成績(jī)分布的影響很大。比如多選題漏選給一半分、選錯(cuò)給零分整體通過率會(huì)明顯高于全錯(cuò)全扣。具體選擇哪種規(guī)則一定要讓客戶在配置里自己決定千萬不要寫死在代碼里。5.2 數(shù)據(jù)統(tǒng)計(jì)別把數(shù)據(jù)分析做成一個(gè)平均數(shù)展示列表統(tǒng)計(jì)模塊的價(jià)值高低決定了這套系統(tǒng)是交差用的工具還是真正能幫客戶提升題庫質(zhì)量的服務(wù)。我建議至少包含三個(gè)層次的分析成績(jī)匯總層最高分、最低分、平均分、通過率、不及格率。這些是最基礎(chǔ)的指標(biāo)只能用來做結(jié)果匯報(bào)。試卷質(zhì)量層難度系數(shù)和區(qū)分度。難度系數(shù)計(jì)算公式是P 平均分 / 滿分P值低于0.3說明題目偏難高于0.8說明偏易。區(qū)分度指標(biāo)可以簡(jiǎn)單用“高分組平均分 - 低分組平均分”來評(píng)估區(qū)分度低于0.2的題目說明沒有區(qū)分能力可以考慮淘汰或修改。知識(shí)點(diǎn)掌握層按知識(shí)點(diǎn)聚合答題正確率。這一層價(jià)值最大因?yàn)榕嘤?xùn)機(jī)構(gòu)可以直接看到“三角函數(shù)”章節(jié)學(xué)員普遍弱然后針對(duì)性調(diào)整教學(xué)計(jì)劃。我的實(shí)現(xiàn)方式是在答題記錄落庫時(shí)把題目關(guān)聯(lián)的知識(shí)點(diǎn)ID同樣寫入明細(xì)表統(tǒng)計(jì)時(shí)按知識(shí)點(diǎn)ID做聚合生成學(xué)員個(gè)人畫像和班級(jí)整體畫像。統(tǒng)計(jì)分析有一個(gè)容易忽略的性能問題答題明細(xì)表增長(zhǎng)很快一次五百人的考試就能產(chǎn)生幾萬條明細(xì)記錄直接用明細(xì)表做聚合查詢會(huì)越查越慢。我建議每天凌晨跑定時(shí)任務(wù)把明細(xì)表按天聚合到結(jié)果表報(bào)表查詢只查聚合表明細(xì)表只做鉆取回溯。6. 從零搭建到上線我的踩坑記錄與實(shí)施建議6.1 三個(gè)印象最深的線上事故這些年做答題系統(tǒng)線上問題沒少出講三個(gè)最典型的每個(gè)都值一次加班教訓(xùn)。事故一空格導(dǎo)致大面積錯(cuò)判。有次填空題答案是“CRM系統(tǒng)”考生填“CRM系統(tǒng)”帶了一個(gè)全角空格所有帶空格的填空題全部判錯(cuò)學(xué)員群直接炸了。排查后發(fā)現(xiàn)是字符串標(biāo)準(zhǔn)化環(huán)節(jié)漏了全角轉(zhuǎn)半角的處理。修復(fù)方案就是把標(biāo)準(zhǔn)化函數(shù)抽成公共模塊填空題、簡(jiǎn)答題的關(guān)鍵詞命中全部走同一個(gè)函數(shù)。事故二并發(fā)交卷產(chǎn)生重復(fù)記錄?；顒?dòng)答題上線當(dāng)天大量用戶集中提交數(shù)據(jù)庫在極端并發(fā)下出現(xiàn)了一條答題記錄在同一玩家名下存了兩份的情況導(dǎo)致獎(jiǎng)品發(fā)放邏輯認(rèn)為他答題次數(shù)超額。根因是數(shù)據(jù)庫缺少非唯一索引約束修復(fù)方式是在(session_id, question_id)上加唯一索引并在插入時(shí)使用ON DUPLICATE KEY UPDATE。事故三倒計(jì)時(shí)突然跳變。有考生反饋考試倒計(jì)時(shí)有次從15分鐘直接跳到3分鐘排查后發(fā)現(xiàn)是后端有一個(gè)定時(shí)任務(wù)在刷新會(huì)話時(shí)把start_time錯(cuò)誤地更新成了最新一次心跳時(shí)間。修復(fù)方案是定時(shí)刷新任務(wù)只允許刷新last_heartbeat_time禁止觸碰start_time字段。這個(gè)事故讓我深刻意識(shí)到關(guān)鍵字段的寫入權(quán)限必須收口不能到處都有UPDATE session SET start_time xxx的代碼。6.2 上線前的壓測(cè)清單答題類系統(tǒng)和其他系統(tǒng)比對(duì)實(shí)時(shí)性要求更高壓測(cè)時(shí)不能只測(cè)接口吞吐量還要重點(diǎn)關(guān)注時(shí)間敏感鏈路。我總結(jié)了一份壓測(cè)前的檢查清單并發(fā)交卷測(cè)試模擬500人同時(shí)交卷確認(rèn)不丟單、不重復(fù)、不超時(shí)。倒計(jì)時(shí)精確性測(cè)試比對(duì)服務(wù)端計(jì)時(shí)和真實(shí)時(shí)間誤差在3秒內(nèi)算合格。排行榜刷新測(cè)試競(jìng)賽場(chǎng)景每2秒刷一次排名確認(rèn)Redis集群無雪崩。斷網(wǎng)重連測(cè)試模擬斷網(wǎng)2分鐘再連上確認(rèn)答案恢復(fù)完整時(shí)間補(bǔ)償正確。抽題緩存命中率測(cè)試活動(dòng)答題場(chǎng)景盯緊Redis命中率正常情況下應(yīng)高于99%。壓測(cè)工具我常用JMeter和Locust腳本提前按場(chǎng)景寫好上線前至少跑兩輪完整回歸。6.3 部署形態(tài)與成本控制建議最后給一個(gè)務(wù)實(shí)的技術(shù)選型建議。這套系統(tǒng)的主流部署形態(tài)是這樣的單機(jī)起步一個(gè)Spring Boot或Go服務(wù)加上MySQL和Redis足夠支撐幾百到幾千人的考試場(chǎng)景。上云擴(kuò)展考試高峰時(shí)用云服務(wù)器臨時(shí)擴(kuò)容答題接口無狀態(tài)化通過負(fù)載均衡分發(fā)Redis扛會(huì)話狀態(tài)數(shù)據(jù)庫做主從。這樣一套配置扛幾萬人并發(fā)答題是沒問題的。文件存儲(chǔ)題目中的圖片和音視頻素材建議走對(duì)象存儲(chǔ)加CDN不要打在業(yè)務(wù)服務(wù)器上不然一場(chǎng)考試下來帶寬費(fèi)用就能讓人肉疼。前端移動(dòng)端適配要重點(diǎn)說一句競(jìng)賽和活動(dòng)答題必須優(yōu)先做手機(jī)H5或小程序端答題界面的操作熱區(qū)要大倒計(jì)時(shí)和交卷按鈕要固定在觸手可及的位置。我做過的幾個(gè)項(xiàng)目里70%以上的流量來自手機(jī)端如果前端適配沒做好后面接再多的功能都要打折扣。數(shù)據(jù)庫表設(shè)計(jì)上我見過很多失敗案例都是因?yàn)榘岩坏李}的所有字段塞在一張表里導(dǎo)致后面擴(kuò)展無力。至少要把題目主表、選項(xiàng)表、答案表、知識(shí)點(diǎn)表、試卷表、答題明細(xì)表、會(huì)話表拆分開來字段冗余寧可多幾列也不能把關(guān)系揉在一起。這套系統(tǒng)做完之后我最大的感受是答題類產(chǎn)品真正難的不是某一個(gè)功能而是把不同場(chǎng)景的差異抽象成可配置的規(guī)則。考試要求嚴(yán)謹(jǐn)刷題要求輕快競(jìng)賽要求實(shí)時(shí)活動(dòng)要求抗壓它們共享的底層越穩(wěn)定外層場(chǎng)景的功能就越安全。你越早用抽象思維把這些場(chǎng)景拆開后面的擴(kuò)展就越省力。本文還有配套的精品資源點(diǎn)擊獲取