1. 這個(gè)項(xiàng)目到底要解決什么問(wèn)題拍賣(mài)業(yè)務(wù)和普通電商的差距在哪先說(shuō)個(gè)實(shí)際場(chǎng)景。我見(jiàn)過(guò)不少同學(xué)拿到“在線(xiàn)拍賣(mài)系統(tǒng)”這個(gè)題目后第一反應(yīng)是照抄電商系統(tǒng)的商品模塊商品列表、購(gòu)物車(chē)、訂單、支付然后換了個(gè)殼子叫“拍賣(mài)”。答辯時(shí)被問(wèn)了一句“拍賣(mài)截止時(shí)間到了但有人正在輸入出價(jià)你怎么處理”就卡住了。說(shuō)實(shí)話(huà)這是做拍賣(mài)系統(tǒng)最典型的誤區(qū)——拍賣(mài)的核心從來(lái)不是“賣(mài)東西的流程”而是競(jìng)價(jià)規(guī)則本身。普通電商的訂單狀態(tài)是線(xiàn)性流轉(zhuǎn)下單、支付、發(fā)貨、收貨。買(mǎi)個(gè)東西你付了錢(qián)東西就是你的邏輯很直接。拍賣(mài)則完全不同它有幾個(gè)電商沒(méi)有的特殊問(wèn)題時(shí)間敏感每個(gè)拍賣(mài)品有明確的起止時(shí)間“最后幾秒”往往決定成敗系統(tǒng)必須在毫秒級(jí)處理出價(jià)請(qǐng)求。狀態(tài)競(jìng)爭(zhēng)同一個(gè)拍賣(mài)品同一時(shí)刻可能有幾十個(gè)用戶(hù)同時(shí)在出價(jià)但只有價(jià)格最高的那個(gè)人能勝出其他人的出價(jià)要被拒絕或立刻被超出的新價(jià)格作廢。結(jié)果裁定拍賣(mài)結(jié)束后系統(tǒng)要自動(dòng)判定贏家如果有人在最后幾秒出價(jià)是否順延拍賣(mài)時(shí)間這個(gè)規(guī)則必須在后端嚴(yán)格控制不能靠前端倒計(jì)時(shí)來(lái)約定?？梢?jiàn)性競(jìng)拍過(guò)程本身就是一個(gè)“實(shí)時(shí)直播”所有參與者的客戶(hù)端必須看到最新的出價(jià)記錄、倒計(jì)時(shí)和領(lǐng)先者變化這顆不是“刷新一下頁(yè)面”那種體驗(yàn)而是服務(wù)端推動(dòng)的實(shí)時(shí)更新。我當(dāng)時(shí)拿到需求文檔之后第一件事不是選技術(shù)棧而是先把拍賣(mài)的規(guī)則細(xì)化成一張可執(zhí)行的邏輯表。比如“加價(jià)幅度不低于多少”“同一用戶(hù)不能連續(xù)自加價(jià)”“大促場(chǎng)景下五萬(wàn)人圍觀一個(gè)拍賣(mài)品的實(shí)時(shí)瀏覽怎么支撐”——這些才是決定架構(gòu)的核心約束。順便也明確一下這個(gè)系統(tǒng)的目標(biāo)用戶(hù)和形態(tài)這是一個(gè)面向Web端的在線(xiàn)拍賣(mài)平臺(tái)管理員可以發(fā)布拍賣(mài)品、設(shè)置起拍價(jià)和保證金規(guī)則用戶(hù)通過(guò)瀏覽器參與競(jìng)拍系統(tǒng)自動(dòng)記錄出價(jià)歷史、判定成交并處理保證金退還。它適合做課程設(shè)計(jì)、畢業(yè)設(shè)計(jì)也能作為企業(yè)內(nèi)部“內(nèi)部資產(chǎn)拍賣(mài)”或“二手設(shè)備競(jìng)價(jià)”的原型系統(tǒng)。2. 技術(shù)選型的真實(shí)理由為什么是Node.js不只是因?yàn)樗鼘?xiě)著簡(jiǎn)單確定了業(yè)務(wù)邊界后第二步是選技術(shù)棧。當(dāng)時(shí)我選的是Node.js Express Socket.IO Redis MongoDB這個(gè)組合放到今天依然很能打。下面按“為什么選它”而不是“它多流行”的方式拆一下。2.1 Node.js的擅長(zhǎng)區(qū)間正好卡在拍賣(mài)系統(tǒng)的點(diǎn)上拍賣(mài)系統(tǒng)是一個(gè)典型的I/O密集、短連接高頻請(qǐng)求、高并發(fā)讀寫(xiě)場(chǎng)景。每個(gè)用戶(hù)的出價(jià)動(dòng)作本質(zhì)上是一次快速的事件提交而系統(tǒng)需要把這個(gè)事件廣播給所有正在圍觀這個(gè)拍品的人。Node.js的異步事件驅(qū)動(dòng)模型天生適合這種“小而快”的任務(wù)。有人可能擔(dān)心Node.js是單線(xiàn)程的會(huì)不會(huì)在高并發(fā)下?lián)尾蛔　?shí)際上普通拍賣(mài)系統(tǒng)的真實(shí)瓶頸很少在CPU計(jì)算而在數(shù)據(jù)庫(kù)連接數(shù)、Redis讀寫(xiě)能力和網(wǎng)絡(luò)帶寬。Node.js單線(xiàn)程負(fù)責(zé)調(diào)度阻塞操作都丟給底層線(xiàn)程池配合Cluster模塊起多個(gè)進(jìn)程單機(jī)扛住一兩千并發(fā)連接問(wèn)題不大。我做壓測(cè)時(shí)8核機(jī)器上跑4個(gè)Node進(jìn)程每個(gè)進(jìn)程保持1萬(wàn)個(gè)Socket連接整體狀態(tài)很穩(wěn)定。再說(shuō)維護(hù)成本。整個(gè)系統(tǒng)前后端都用JavaScript部署時(shí)不需要多個(gè)運(yùn)行時(shí)環(huán)境寫(xiě)業(yè)務(wù)邏輯的思路也連貫。對(duì)我這種做全棧的人來(lái)說(shuō)一套語(yǔ)言打通確實(shí)省了不少事。2.2 Socket.IO做實(shí)時(shí)推送選擇它的關(guān)鍵原因是容錯(cuò)而不是炫技拍賣(mài)頁(yè)面的核心體驗(yàn)是當(dāng)前價(jià)變了、領(lǐng)先者變了、倒計(jì)時(shí)變了所有在線(xiàn)用戶(hù)都能立刻看到。用傳統(tǒng)的HTTP輪詢(xún)也行但一是浪費(fèi)請(qǐng)求二是延遲不穩(wěn)定。WebSocket是正確答案但直接裸用WebSocket要處理斷線(xiàn)重連、心跳、連接狀態(tài)同步這些臟活。Socket.IO在這方面幫了大忙。它底層自動(dòng)選擇WebSocket、輪詢(xún)或其他可用方式實(shí)測(cè)中某個(gè)用戶(hù)網(wǎng)絡(luò)差時(shí)自動(dòng)降級(jí)成HTTP長(zhǎng)輪詢(xún)體驗(yàn)不至于崩掉連接斷開(kāi)后會(huì)自動(dòng)重連配合房間里的事件廣播斷線(xiàn)幾秒再回來(lái)狀態(tài)還能對(duì)得上。異步任務(wù)的部分我用了Redis輔助這一點(diǎn)后面單獨(dú)講。這里先記住一個(gè)結(jié)論Socket.IO不是可有可無(wú)的“聊天室工具”它承擔(dān)了競(jìng)拍系統(tǒng)“現(xiàn)場(chǎng)直播感”的全部責(zé)任。2.3 Redis在系統(tǒng)里的三副面孔R(shí)edis在這個(gè)項(xiàng)目里不是可有可無(wú)的緩存層它承擔(dān)了三個(gè)職責(zé)實(shí)時(shí)數(shù)據(jù)的存儲(chǔ)當(dāng)前價(jià)格、當(dāng)前領(lǐng)先者、倒計(jì)時(shí)截止時(shí)間戳這些更新頻率高、數(shù)據(jù)量小的狀態(tài)放在Redis里避免每次都查MongoDB。分布式鎖解決“同一時(shí)間多個(gè)進(jìn)程處理同一個(gè)拍品的出價(jià)”時(shí)的并發(fā)沖突。Socket.IO的適配器后端讓多進(jìn)程之間能互相廣播事件確?？蛻?hù)端連在不同Node進(jìn)程上也能收到同一件拍品的出價(jià)提醒。只要系統(tǒng)會(huì)面臨拍賣(mài)高峰期Redis幾乎就是標(biāo)配不是可選項(xiàng)。2.4 數(shù)據(jù)庫(kù)選型MongoDB適合這種“敏捷演變”的數(shù)據(jù)結(jié)構(gòu)拍賣(mài)品、出價(jià)記錄、用戶(hù)信息這幾類(lèi)數(shù)據(jù)天然是文檔結(jié)構(gòu)。每件拍品的參數(shù)字段可能不一樣字畫(huà)有作者、古董有年代、電子產(chǎn)品有型號(hào)關(guān)系型數(shù)據(jù)庫(kù)里要搞一堆“規(guī)格擴(kuò)展表”而MongoDB允許直接嵌入一個(gè)動(dòng)態(tài)的屬性對(duì)象開(kāi)發(fā)效率高很多。另外出價(jià)記錄是典型的追加型數(shù)據(jù)MongoDB的寫(xiě)入性能也優(yōu)于傳統(tǒng)關(guān)系庫(kù)的常規(guī)配置。為了讓出價(jià)記錄查詢(xún)快我給collection加了聯(lián)合索引{auctionId: 1, price: -1}。為了讓拍賣(mài)中的拍品能快速篩選加了{(lán)status: 1, endTime: 1}的索引。這是設(shè)計(jì)初就規(guī)劃好的不是等數(shù)據(jù)量大了才想起來(lái)補(bǔ)。3. 第一個(gè)核心難點(diǎn)拍賣(mài)狀態(tài)機(jī)與延遲機(jī)制的完整實(shí)現(xiàn)進(jìn)到具體實(shí)現(xiàn)階段后最復(fù)雜的其實(shí)是“規(guī)則邏輯”而不是“增刪改查”。建議先畫(huà)一張狀態(tài)圖把拍品的生命周期理清楚再寫(xiě)代碼不然很容易在幾個(gè)狀態(tài)的邊界上兜圈子。3.1 狀態(tài)機(jī)pending到running到ending的三態(tài)流轉(zhuǎn)我把拍品的狀態(tài)定義得非常明確pending未開(kāi)始管理員創(chuàng)建拍品后等待到達(dá)開(kāi)始時(shí)間。running進(jìn)行中開(kāi)始時(shí)間到達(dá)或管理員手動(dòng)上架用戶(hù)可出價(jià)。ended已結(jié)束到達(dá)結(jié)束時(shí)間且無(wú)延時(shí)時(shí)系統(tǒng)自動(dòng)裁定結(jié)果。settled已成交在ended基礎(chǔ)上完成支付/保證金退還等后續(xù)動(dòng)作。這個(gè)狀態(tài)流轉(zhuǎn)我完整寫(xiě)在服務(wù)端禁止前端直接改狀態(tài)字段只允許通過(guò)服務(wù)端接口觸發(fā)。這里有一個(gè)關(guān)鍵設(shè)計(jì)容易被忽略狀態(tài)的變更必須帶時(shí)間戳和操作人。比如用戶(hù)出價(jià)時(shí)發(fā)現(xiàn)拍品已經(jīng)ended就要明確記下“誰(shuí)在什么時(shí)候試圖出價(jià)被拒”這在糾紛處理時(shí)要查得清楚。3.2 截止時(shí)間到底怎么定不可逆的時(shí)間戳原則前端展示的倒計(jì)時(shí)是從服務(wù)端取到的endTime字段計(jì)算出來(lái)的。任何客戶(hù)端本地時(shí)間都不參與“是否截止”的判定攻擊者改系統(tǒng)時(shí)鐘對(duì)服務(wù)端毫無(wú)影響。這里有個(gè)細(xì)節(jié)數(shù)據(jù)庫(kù)里存的是絕對(duì)時(shí)間戳epoch毫秒而不是“剩余秒數(shù)”。因?yàn)椤笆Ｓ嗝霐?shù)”是一種相對(duì)狀態(tài)會(huì)隨著計(jì)算時(shí)刻不同產(chǎn)生漂移絕對(duì)時(shí)間戳則無(wú)歧義。前端拿到endTime后通過(guò)const remain Math.max(0, Math.floor((endTime - Date.now()) / 1000))計(jì)算顯示。3.3 最后幾秒的規(guī)則延長(zhǎng)拍賣(mài)時(shí)間而非簡(jiǎn)單拒絕這是拍賣(mài)系統(tǒng)最出彩、也最容易出錯(cuò)的地方。規(guī)則是在剩余時(shí)間不足X秒如3秒時(shí)如有人出價(jià)則拍賣(mài)結(jié)束時(shí)間自動(dòng)延長(zhǎng)Y秒如5秒。這個(gè)機(jī)制通常稱(chēng)為“自動(dòng)延長(zhǎng)時(shí)間”作用是防止最后時(shí)刻的網(wǎng)絡(luò)延遲導(dǎo)致真實(shí)買(mǎi)家無(wú)法完成出價(jià)。實(shí)現(xiàn)時(shí)不能用“前端倒計(jì)時(shí)到了就鎖死”的方案必須由后端原子操作判斷。我用Redis的WATCH/MULTI事務(wù)來(lái)處理// 判斷并延長(zhǎng)截止時(shí)間 const redisClient require(./redis).getClient(); async function tryExtendAuction(auctionId, latestBidTime) { const key auction:endTime:${auctionId}; const result await redisClient.watch(key); if (!result) return; const currentEnd await redisClient.get(key); const remain currentEnd - Date.now(); const multi redisClient.multi(); if (remain EXTEND_THRESHOLD_MS remain 0) { const newEnd Date.now() EXTEND_DURATION_MS; multi.set(key, newEnd); multi.set(auction:status:${auctionId}, running); } const execRes await multi.exec(); if (!execRes) { // 有其他請(qǐng)求并發(fā)修改重試 return tryExtendAuction(auctionId, latestBidTime); } }這樣寫(xiě)的核心是REdis的watch機(jī)制監(jiān)聽(tīng)endTime如果在我讀取之后、事務(wù)執(zhí)行之前這個(gè)key被別的進(jìn)程改了整個(gè)事務(wù)就取消重試。這保證了多人同時(shí)出價(jià)時(shí)只會(huì)有一個(gè)人成功延長(zhǎng)而不會(huì)被覆蓋成亂七八糟的時(shí)間。3.4 定時(shí)任務(wù)的坑setTimeout不是用來(lái)做拍賣(mài)結(jié)算的一開(kāi)始很多人會(huì)用setTimeout來(lái)做“到點(diǎn)自動(dòng)結(jié)算”。看起來(lái)簡(jiǎn)單但服務(wù)器重啟后內(nèi)存中的timer會(huì)全部丟失。更穩(wěn)妥的做法是每個(gè)拍品結(jié)束時(shí)先把狀態(tài)標(biāo)記為“待結(jié)算”并寫(xiě)入結(jié)算時(shí)間。然后用一個(gè)獨(dú)立的輪詢(xún)?nèi)蝿?wù)去掃描所有“running且endTime已過(guò)”的拍品執(zhí)行結(jié)算。這個(gè)輪詢(xún)?nèi)蝿?wù)可以用node-cron實(shí)現(xiàn)每秒鐘掃一次const cron require(node-cron); cron.schedule(* * * * * *, async () { const expiredAuctions await Auction.find({ status: running, endTime: { $lte: new Date() } }); for (const auc of expiredAuctions) { await settleAuction(auc._id); } });掃描頻率是1秒一次粒度足夠了。即便定時(shí)任務(wù)有1秒延遲用戶(hù)也感知不到。不過(guò)千萬(wàn)注意掃描任務(wù)必須設(shè)計(jì)成可重入的。也就是說(shuō)同一件拍品不能在兩次掃描中被同時(shí)結(jié)算。我給處理過(guò)程加了一個(gè)狀態(tài)位開(kāi)始結(jié)算前用Redis setnx寫(xiě)入一個(gè)lock key成功才繼續(xù)否則跳過(guò)本次。4. 第二個(gè)核心難點(diǎn)競(jìng)價(jià)高并發(fā)下的數(shù)據(jù)一致性出價(jià)是拍賣(mài)系統(tǒng)的核心操作比普通的“寫(xiě)入一條記錄”復(fù)雜得多。每次出價(jià)必須同時(shí)滿(mǎn)足出價(jià)價(jià)格大于當(dāng)前最高價(jià)并且加價(jià)幅度合法。拍品狀態(tài)為running。當(dāng)前時(shí)間還沒(méi)到endTime。不能是領(lǐng)先者自己再次出價(jià)防止自己頂自己刷價(jià)。這幾個(gè)條件任何一個(gè)不滿(mǎn)足都要拒絕這次出價(jià)。但如果判斷完再寫(xiě)入期間又有別的請(qǐng)求插進(jìn)來(lái)就可能出現(xiàn)“兩個(gè)人同時(shí)認(rèn)為自己出價(jià)成功”的競(jìng)態(tài)條件。解決這個(gè)問(wèn)題的典型方法有樂(lè)觀鎖和Redis原子操作我兩個(gè)都用過(guò)說(shuō)說(shuō)實(shí)際的取舍。4.1 方案對(duì)比樂(lè)觀鎖 vs Redis原子操作給MongoDB的拍賣(mài)品文檔加一個(gè)version字段遞交出價(jià)時(shí)帶上讀出時(shí)的版本號(hào)更新時(shí)用findOneAndUpdate帶條件version 讀取的版本號(hào)如果更新結(jié)果為空說(shuō)明版本沖突重新讀取再試。這種樂(lè)觀鎖簡(jiǎn)單可靠但問(wèn)題是在高并發(fā)情況下重試次數(shù)會(huì)很多不僅浪費(fèi)體驗(yàn)也不好。改進(jìn)后我采用的方式是把“當(dāng)前最高價(jià)”放在Redis里用Redis的原子自增/范圍操作來(lái)裁決出價(jià)。const Script if redis.call(exists, KEYS[1]) 0 then return -1 end local currentPrice tonumber(redis.call(get, KEYS[2])) local requiredStep tonumber(ARGV[2]) if tonumber(ARGV[1]) currentPrice requiredStep then return 0 end redis.call(set, KEYS[2], ARGV[1]) redis.call(set, KEYS[3], ARGV[3]) return 1 ; const result await redisClient.eval(Script, 3, auction:status:${auctionId}, auction:currentPrice:${auctionId}, auction:leader:${auctionId}, newPrice, minStep, userId );Lua腳本在Redis里是原子執(zhí)行的這行命令在整個(gè)執(zhí)行期間不會(huì)被其他命令插入所以并發(fā)判斷和寫(xiě)入是安全無(wú)競(jìng)態(tài)的。出價(jià)成功后再把出價(jià)記錄異步寫(xiě)入MongoDB。這里Redis不是緩存而是數(shù)據(jù)的“合法裁決點(diǎn)”。4.2 MongoDB里的出價(jià)記錄異步落庫(kù)與補(bǔ)償Redis負(fù)責(zé)裁決MongoDB負(fù)責(zé)持久化。把出價(jià)記錄異步落庫(kù)時(shí)有兩種方案監(jiān)聽(tīng)Redis的鍵變化事件觸發(fā)寫(xiě)入。每個(gè)Node進(jìn)程在收到業(yè)務(wù)層“出價(jià)成功”信號(hào)后自行寫(xiě)庫(kù)。方案2更直觀但需要小心如果某一臺(tái)Node進(jìn)程在寫(xiě)入期間崩潰出價(jià)記錄就丟了。解決方法是引入一個(gè)簡(jiǎn)單的補(bǔ)償任務(wù)定每隔一段時(shí)間比如每分鐘比對(duì)Redis中的當(dāng)前狀態(tài)和MongoDB中記錄的最高價(jià)是否一致如果Redis中的價(jià)格高于數(shù)據(jù)庫(kù)記錄就補(bǔ)插一條記錄。看起來(lái)有點(diǎn)笨但拍賣(mài)場(chǎng)景下極少出現(xiàn)這個(gè)不一致而且補(bǔ)償對(duì)賬能保證賬目可靠。4.3 加價(jià)幅度的校驗(yàn)放在哪一層出價(jià)不是隨意數(shù)字系統(tǒng)規(guī)定加價(jià)幅度必須高于當(dāng)前價(jià)的某個(gè)比例例如5%或固定階梯值。這個(gè)校驗(yàn)務(wù)必放在服務(wù)端不能依賴(lài)前端禁用按鈕。理由是顯而易見(jiàn)的任何人都能直接偽造請(qǐng)求。前端可以輔助展示“最低可出價(jià)”后端則必須嚴(yán)格判斷if (bidPrice currentPrice minStep) { throw new BizError(BID_PRICE_TOO_LOW); }這個(gè)currentPrice從Redis里讀而不是從數(shù)據(jù)庫(kù)讀因?yàn)镽edis值實(shí)時(shí)滾動(dòng)的頻率遠(yuǎn)高于數(shù)據(jù)庫(kù)持久化頻率。前端顯示出現(xiàn)微小延遲沒(méi)關(guān)系但后端裁決必須使用最準(zhǔn)的數(shù)據(jù)。5. 前端實(shí)時(shí)交互那些容易被忽略的體驗(yàn)細(xì)節(jié)頁(yè)面實(shí)現(xiàn)上我用服務(wù)端渲染出基礎(chǔ)結(jié)構(gòu)再用Socket.IO負(fù)責(zé)動(dòng)態(tài)區(qū)域的實(shí)時(shí)更新。不是所有地方都要實(shí)時(shí)只有這幾個(gè)關(guān)鍵區(qū)域需要當(dāng)前最高價(jià)與領(lǐng)先者昵稱(chēng)。最新出價(jià)記錄列表。距離截止的時(shí)間倒計(jì)時(shí)。狀態(tài)橫幅“已結(jié)束”“已成交”。5.1 房間設(shè)計(jì)io.to(auctionId)只推相關(guān)用戶(hù)Socket.IO提供了房間room)能力。用戶(hù)進(jìn)入拍賣(mài)詳情頁(yè)時(shí)前端發(fā)一個(gè)joinAuctionRoom事件后端把socket加入到auction_${auctionId}房間內(nèi)。這樣出價(jià)成功時(shí)只需io.to(auctionRoomId).emit(bid:update, data)所有在線(xiàn)用戶(hù)都能收到不在這個(gè)頁(yè)面的人則不會(huì)被廣播干擾。有幾百萬(wàn)人在線(xiàn)時(shí)全局廣播會(huì)造成巨大壓力。按房間推送能把消息量限制在真正關(guān)注當(dāng)前拍品的用戶(hù)范圍內(nèi)。5.2 斷線(xiàn)重連與狀態(tài)同步保住用戶(hù)的“現(xiàn)場(chǎng)感”網(wǎng)絡(luò)抖動(dòng)是常態(tài)用戶(hù)刷新頁(yè)面也會(huì)觸發(fā)socket重新連接。Socket.IO默認(rèn)會(huì)自動(dòng)重連但重連后前端頁(yè)面上的價(jià)格和倒計(jì)時(shí)可能已經(jīng)過(guò)期。我寫(xiě)了一個(gè)reqState事件socket連接建立后前端主動(dòng)請(qǐng)求當(dāng)前拍品的完整快照當(dāng)前價(jià)、截止時(shí)間、領(lǐng)先者、最近的出價(jià)記錄服務(wù)端從Redis Mongo組裝返回。這樣用戶(hù)不管什么時(shí)候進(jìn)來(lái)看到的都是準(zhǔn)實(shí)時(shí)狀態(tài)不會(huì)顯示一個(gè)過(guò)期的死頁(yè)面。5.3 倒計(jì)時(shí)的前端算法不要依賴(lài)服務(wù)端的“剩余秒數(shù)”前面說(shuō)了服務(wù)端返回絕對(duì)時(shí)間戳。前端用一個(gè)統(tǒng)一的時(shí)間源來(lái)做倒計(jì)時(shí)更新function formatRemain(endTime) { const remain Math.max(0, Math.floor((endTime - Date.now()) / 1000)); const h Math.floor(remain / 3600); const m Math.floor((remain % 3600) / 60); const s remain % 60; return ${h}:${String(m).padStart(2, 0)}:${String(s).padStart(2, 0)}; }這里有一個(gè)細(xì)節(jié)如果用戶(hù)本地時(shí)鐘和服務(wù)端差了幾秒倒計(jì)時(shí)顯示會(huì)不準(zhǔn)確。雖然不是嚴(yán)重的問(wèn)題但競(jìng)拍最后幾秒用戶(hù)會(huì)很敏感。嚴(yán)謹(jǐn)?shù)淖龇ㄊ沁B接建立時(shí)服務(wù)端下發(fā)一個(gè)serverTime前端計(jì)算本地時(shí)鐘偏移量之后用Date.now() offset作為時(shí)間基準(zhǔn)。5.4 出價(jià)按鈕的防誤觸設(shè)計(jì)出價(jià)操作是不可撤銷(xiāo)的誤觸一次就可能花冤枉錢(qián)。前端在按鈕點(diǎn)擊后要加一個(gè)確認(rèn)彈窗顯示本次出價(jià)后的新價(jià)格。同時(shí)按鈕在收到“出價(jià)成功”或“出價(jià)過(guò)低”的socket響應(yīng)前應(yīng)處于loading狀態(tài)防止快速連點(diǎn)造成沖突。后端也不怕連點(diǎn)因?yàn)閮r(jià)格裁決在Redis的Lua里是原子操作。即便前端快速發(fā)了兩次相同價(jià)格的出價(jià)第二次會(huì)因?yàn)椤皟r(jià)格未高于當(dāng)前價(jià)”被自然拒絕。6. 數(shù)據(jù)庫(kù)模型設(shè)計(jì)寧可多寫(xiě)一點(diǎn)也不要留模糊地帶6.1 拍賣(mài)品集合的核心字段{ _id: ObjectId, title: String, // 標(biāo)題 description: String, // 描述 coverImage: String, // 封面圖URL startPrice: Number, // 起拍價(jià)單位分 currentPrice: Number, // 當(dāng)前價(jià)實(shí)時(shí)取Redis冗余存儲(chǔ) minStep: Number, // 最小加價(jià)幅度 deposit: Number, // 保證金分 startTime: Date, // 開(kāi)始時(shí)間 endTime: Date, // 截止時(shí)間 status: String, // pending / running / ended / settled leaderId: ObjectId, // 當(dāng)前領(lǐng)先者 bidCount: Number, // 出價(jià)次數(shù)統(tǒng)計(jì)用 actualEndTime: Date, // 實(shí)際結(jié)束時(shí)間可能因延時(shí)而變化 createdAt: Date, updatedAt: Date }注意我用了“分”作為貨幣單位。浮點(diǎn)數(shù)算錢(qián)在JavaScript里是災(zāi)難雖然MongoDB支持Decimal128但單位換算成整數(shù)更省心顯示時(shí)再除以100。加價(jià)幅度、當(dāng)前價(jià)、起拍價(jià)全部存整數(shù)分。6.2 出價(jià)記錄集合{ _id: ObjectId, auctionId: ObjectId, userId: ObjectId, price: Number, // 本次出價(jià)分 createdAt: Date, isAuto: Boolean, // 是否系統(tǒng)自動(dòng)出價(jià)預(yù)留 ip: String, // 操作來(lái)源審計(jì)用 source: String, // web / admin }這個(gè)集合只做追加不修改不刪除。用戶(hù)可以在詳情頁(yè)看到所有歷史出價(jià)也是后期審計(jì)的憑證。索引{auctionId: 1, price: -1}可以讓“最近出價(jià)列表”查詢(xún)走索引。6.3 用戶(hù)與保證金保證金設(shè)計(jì)上為了簡(jiǎn)化流程我初期用一個(gè)userDeposits集合記錄用戶(hù)為某個(gè)拍品繳納的保證金狀態(tài){ _id: ObjectId, userId: ObjectId, auctionId: ObjectId, amount: Number, status: String, // paid / frozen / returned / deducted paidAt: Date, returnedAt: Date }拍賣(mài)結(jié)束時(shí)贏家需要完成付款保證金可抵扣貨款輸家的保證金自動(dòng)原路退回。這是業(yè)務(wù)上比較合理的閉環(huán)。如果沒(méi)有支付渠道可以做成“模擬支付”但數(shù)據(jù)結(jié)構(gòu)上必須有這條鏈路。7. 部署架構(gòu)與橫向擴(kuò)展從單機(jī)到多進(jìn)程的平滑演進(jìn)前面的內(nèi)容主要集中在代碼層面。這部分把真實(shí)部署時(shí)的架構(gòu)設(shè)計(jì)講清楚因?yàn)楹芏嗤瑢W(xué)做完功能后就停了忽略了“系統(tǒng)能面對(duì)多少真實(shí)用戶(hù)”這個(gè)問(wèn)題。7.1 單機(jī)起步的最小架構(gòu)初期單機(jī)方案如下一臺(tái)云主機(jī)4核8G以上。Nginx做反向代理靜態(tài)資源走緩存。Node.js起4個(gè)進(jìn)程Cluster模式監(jiān)聽(tīng)同一個(gè)端口。Redis和MongoDB部署在同一臺(tái)機(jī)器上或者單獨(dú)實(shí)例。這個(gè)配置大概能支撐幾百到上千的并發(fā)在線(xiàn)用戶(hù)對(duì)課程設(shè)計(jì)和中小型內(nèi)部系統(tǒng)完全夠用。7.2 Socket.IO的跨進(jìn)程通信Redis Adapter是關(guān)鍵單機(jī)起4個(gè)進(jìn)程之后馬上會(huì)遇到一個(gè)麻煩用戶(hù)A連的是進(jìn)程1用戶(hù)B連的是進(jìn)程2A出價(jià)后進(jìn)程1只能給本進(jìn)程內(nèi)的socket廣播進(jìn)程2里的用戶(hù)收不到更新。解決方法是給Socket.IO配上Redis Adapterconst { createAdapter } require(socket.io/redis-adapter); const { createClient } require(redis); const pubClient createClient({ url: redis://localhost:6379 }); const subClient pubClient.duplicate(); io.adapter(createAdapter(pubClient, subClient));配好之后每個(gè)進(jìn)程的Socket.IO實(shí)例通過(guò)Redis互相傳遞廣播消息room的概念也自動(dòng)變成全局的。這樣“房間內(nèi)廣播所有在線(xiàn)用戶(hù)”是基于全集群的而不只限于單個(gè)進(jìn)程。7.3 Nginx的升級(jí)策略與負(fù)載均衡當(dāng)在線(xiàn)用戶(hù)數(shù)增長(zhǎng)到幾千、上萬(wàn)時(shí)單機(jī)肯定不夠了。擴(kuò)展思路是Nginx轉(zhuǎn)發(fā)請(qǐng)求到多臺(tái)Node服務(wù)器。Socket.IO長(zhǎng)連接必須開(kāi)啟ip_hash負(fù)載均衡或者使用sticky sessions否則同一個(gè)用戶(hù)的多次長(zhǎng)連接可能被分配到不同服務(wù)器重連后房間信息可能丟失。雖然Redis Adapter能解決跨進(jìn)程廣播但從用戶(hù)角度一個(gè)固定的連接能被路由到同一個(gè)后端進(jìn)程重連開(kāi)銷(xiāo)最小。Nginx配置里upstream node_app { ip_hash; server 10.0.0.1:3000; server 10.0.0.2:3000; }一個(gè)完整的生產(chǎn)級(jí)部署會(huì)涉及CDN、靜態(tài)資源分離、MongoDB副本集、Redis哨兵等但核心架構(gòu)和單機(jī)版本一脈相承。真正的門(mén)檻在“編排和監(jiān)控”不在“功能開(kāi)發(fā)”。7.4 性能瓶頸與優(yōu)化連接數(shù)比CPU更先到達(dá)上限壓測(cè)時(shí)最容易遇到的坑是EADDRNOTAVAIL或者too many open files。Linux默認(rèn)單進(jìn)程文件描述符上限是1024對(duì)一個(gè)支持幾千長(zhǎng)連接的Node進(jìn)程來(lái)說(shuō)根本不夠。必須調(diào)大ulimit -n 65535另外Socket.IO的心跳配置也需要按實(shí)際網(wǎng)絡(luò)情況去調(diào)。默認(rèn)心跳間隔和超時(shí)時(shí)間對(duì)弱網(wǎng)用戶(hù)不太友好我調(diào)整成const io new Server(httpServer, { pingInterval: 25000, pingTimeout: 20000, cors: { origin: [https://yourdomain.com] } });這兩個(gè)參數(shù)的含義是每25秒服務(wù)端發(fā)一次心跳若20秒內(nèi)客戶(hù)端沒(méi)有響應(yīng)則判定斷開(kāi)。太頻繁會(huì)增加無(wú)謂流量太慢會(huì)導(dǎo)致“用戶(hù)已經(jīng)斷網(wǎng)但服務(wù)端還掛著一堆僵尸連接”。8. 踩坑實(shí)錄那些文檔里不會(huì)寫(xiě)的教訓(xùn)這個(gè)系統(tǒng)前前后后寫(xiě)了兩三個(gè)版本踩過(guò)不少坑。挑幾個(gè)有代表性的分享出來(lái)。8.1 并發(fā)用戶(hù)出價(jià)后數(shù)據(jù)庫(kù)里的currentPrice和Redis不一致一開(kāi)始我把currentPrice放在Redis里做實(shí)時(shí)裁決但落庫(kù)時(shí)用的是Auction.updateOne({ _id }, { $set: { currentPrice: newPrice } })沒(méi)加版本控制。壓測(cè)時(shí)發(fā)現(xiàn)某個(gè)時(shí)刻數(shù)據(jù)庫(kù)里的價(jià)格低于Redis里的價(jià)格。原因很簡(jiǎn)單兩次并發(fā)更新在不同的進(jìn)程里執(zhí)行后到的寫(xiě)庫(kù)請(qǐng)求可能讀到一個(gè)舊的Redis值把數(shù)據(jù)庫(kù)覆蓋成更低的價(jià)。我的修復(fù)方案是把MongoDB更新也改成條件更新只有當(dāng)傳入的新價(jià)格大于當(dāng)前數(shù)據(jù)庫(kù)價(jià)格時(shí)才更新const updateRes await Auction.updateOne( { _id: auctionId, currentPrice: { $lt: newPrice } }, { $set: { currentPrice: newPrice, leaderId: userId, updatedAt: new Date() } } );數(shù)據(jù)庫(kù)里的值就永遠(yuǎn)不會(huì)被低價(jià)格覆蓋。即便Redis和數(shù)據(jù)庫(kù)偶爾不一致數(shù)據(jù)庫(kù)對(duì)賬任務(wù)也能最終修正。8.2 服務(wù)器時(shí)鐘漂移導(dǎo)致倒計(jì)時(shí)提前清零我一開(kāi)始認(rèn)為服務(wù)器時(shí)間絕對(duì)準(zhǔn)確后來(lái)發(fā)現(xiàn)云服務(wù)器啟用NTP對(duì)時(shí)后極小概率會(huì)出現(xiàn)幾秒的時(shí)鐘跳動(dòng)。當(dāng)時(shí)有一場(chǎng)拍賣(mài)明明還有10秒前端倒計(jì)時(shí)直接歸零了。排查半天發(fā)現(xiàn)問(wèn)題出在“本地服務(wù)器時(shí)間和NTP校時(shí)瞬間跳變”上。這種偶發(fā)問(wèn)題很難復(fù)現(xiàn)但拍賣(mài)系統(tǒng)對(duì)時(shí)間極度敏感。我的做法是服務(wù)端多維護(hù)一個(gè)serverTimeOffset字段校時(shí)跳變時(shí)做平滑校正不讓倒計(jì)時(shí)顯示瞬間突變。8.3 Socket.IO的內(nèi)存泄漏分清日志級(jí)別的作用有段時(shí)間線(xiàn)上運(yùn)行幾天后內(nèi)存占用持續(xù)上升堆快照后發(fā)現(xiàn)是console.log在打印大對(duì)象。看起來(lái)是個(gè)小事但生產(chǎn)環(huán)境每秒鐘幾百次出價(jià)廣播每次都打一大坨JSON日志系統(tǒng)自身就會(huì)成為性能瓶頸。優(yōu)化方案是log級(jí)別區(qū)分debug級(jí)別開(kāi)發(fā)環(huán)境打印完整對(duì)象。info級(jí)別生產(chǎn)環(huán)境只打印簡(jiǎn)要信息auctionId、price、userId、耗時(shí)。warn/error級(jí)別打印完整錯(cuò)誤堆棧。做技術(shù)的人容易忽視日志但日志其實(shí)是排障時(shí)的第一救命稻草。8.4 出價(jià)記錄查詢(xún)慢看懂explain()比瞎加索引管用有一個(gè)列表頁(yè)要顯示某件拍品的出價(jià)記錄數(shù)據(jù)量到了十萬(wàn)條后查詢(xún)?cè)絹?lái)越慢?？磮?zhí)行計(jì)劃發(fā)現(xiàn)查詢(xún)走了全表掃描。加了聯(lián)合索引{auctionId:1, createdAt:-1}后速度從幾百毫秒降到個(gè)位數(shù)毫秒。這種問(wèn)題其實(shí)很基礎(chǔ)但真遇到了才知道索引設(shè)計(jì)不能靠直覺(jué)。9. 最后還想再聊幾句這個(gè)項(xiàng)目我從頭到尾做下來(lái)最大的感受是拍賣(mài)系統(tǒng)表面上是“一個(gè)帶倒計(jì)時(shí)的商品頁(yè)面”實(shí)際上是一套包含并發(fā)控制、實(shí)時(shí)通信、狀態(tài)機(jī)、資金流轉(zhuǎn)的完整業(yè)務(wù)系統(tǒng)。每個(gè)細(xì)節(jié)背后都有真實(shí)場(chǎng)景在推動(dòng)不是硬湊出來(lái)的功能。如果你想在這個(gè)項(xiàng)目基礎(chǔ)上繼續(xù)擴(kuò)展可以考慮這幾個(gè)方向增加代理出價(jià)功能——用戶(hù)設(shè)定最高預(yù)算系統(tǒng)代替自動(dòng)加價(jià)增加拍賣(mài)直播——把出價(jià)事件流和視頻流組合起來(lái)增加多幣種支持——后臺(tái)統(tǒng)一按分存儲(chǔ)前端按區(qū)域顯示。這些都是很自然的業(yè)務(wù)延伸。最后分享一個(gè)我做壓測(cè)時(shí)用的腳本思路不要只測(cè)“每秒能處理多少出價(jià)”更要測(cè)“最后10秒高并發(fā)下系統(tǒng)的數(shù)據(jù)一致性是否依然正確”。因?yàn)檎Ｇ闆r下可能只有幾十個(gè)請(qǐng)求但壓測(cè)如果只有高峰值的1/10很多并發(fā)問(wèn)題根本暴露不出來(lái)。每輪測(cè)試結(jié)束后跑一次對(duì)賬腳本對(duì)比Redis和MongoDB里的最終數(shù)據(jù)這樣測(cè)試的意義才完整。