機(jī)叫號源代碼解析：狀態(tài)機(jī)模型與數(shù)據(jù)庫并發(fā)控制)
簡介面向C#初學(xué)者以及正在設(shè)計(jì)排隊(duì)機(jī)、叫號系統(tǒng)的開發(fā)者這套源代碼提供了一套經(jīng)過多年客戶實(shí)際使用驗(yàn)證的完整方案覆蓋叫號邏輯、數(shù)據(jù)庫訪問、界面展示與報(bào)表打印等環(huán)節(jié)可幫助理解真實(shí)項(xiàng)目中的模塊劃分與數(shù)據(jù)流轉(zhuǎn)方式。壓縮包共249個文件以172個cs源碼文件為主體輔以44個resx界面資源、9個ico圖標(biāo)、6個user自定義控件、5個settings配置以及2個rdlc報(bào)表定義整體僅1.29MB結(jié)構(gòu)緊湊便于直接閱讀與二次開發(fā)。已有1617人瀏覽學(xué)習(xí)。代碼中包含DbHelperSQL等數(shù)據(jù)庫輔助類、frmCaller與frmScreen等核心窗體以及MyCommon公共方法模塊覆蓋從數(shù)據(jù)庫操作到多窗體協(xié)作的典型實(shí)現(xiàn)適合初學(xué)者拆解學(xué)習(xí)也可為實(shí)際項(xiàng)目提供可復(fù)用的設(shè)計(jì)思路與代碼骨架節(jié)省從零搭建系統(tǒng)的時(shí)間。1. 排隊(duì)機(jī)叫號源代碼本質(zhì)是一臺隊(duì)列狀態(tài)機(jī)「排隊(duì)機(jī)叫號源代碼」這幾個字聽起來像是一個「能叫號的程序」但真正拿到這種項(xiàng)目的人會發(fā)現(xiàn)叫號只是最表面的動作。取號、分配、叫號、過號、重呼、結(jié)單每一步都是一個狀態(tài)在數(shù)據(jù)庫里的流轉(zhuǎn)而最常見的翻車現(xiàn)場——兩個窗口搶同一個號、客戶沒到窗口號就過了、日報(bào)表數(shù)字對不上——全都出在狀態(tài)沒有守住而不是出在界面按鈕上。這套源代碼的價(jià)值在于把整條隊(duì)列的狀態(tài)管理從頭到尾做完了數(shù)據(jù)庫表怎么建、并發(fā)時(shí)怎么鎖號、過號之后怎么拉回來邏輯是一脈貫通的。它適合兩類人一類是接手維護(hù)網(wǎng)點(diǎn)排隊(duì)機(jī)系統(tǒng)的從業(yè)者想快速看懂老工程另一類是在做數(shù)據(jù)庫課程設(shè)計(jì)、需要真實(shí)業(yè)務(wù)場景源碼來改造的學(xué)生。2. 取號到結(jié)單的完整流轉(zhuǎn)四個角色與一套狀態(tài)碼任何一套排隊(duì)機(jī)源碼不管是銀行大堂、政務(wù)大廳還是醫(yī)院藥房用的拆開看都是四個角色在操作同一張?zhí)柎a流水表取號端負(fù)責(zé)產(chǎn)生號碼窗口端負(fù)責(zé)消費(fèi)號碼顯示端負(fù)責(zé)把當(dāng)前狀態(tài)廣播出去管理端負(fù)責(zé)配置和統(tǒng)計(jì)。這套代碼里四個角色沒有各自建表而是共享一張流水表靠狀態(tài)碼區(qū)分「這個號碼現(xiàn)在走到哪一步」。2.1 四個角色的職責(zé)劃分取號端一般是觸摸屏或者窗口人員代取動作只有一個調(diào)用取號邏輯生成一個當(dāng)天唯一的業(yè)務(wù)號碼插入流水表并置為待叫狀態(tài)。窗口端是叫號人員手里的操作界面包含叫下一個、過號、重呼、開始辦理、結(jié)單這五個動作是最復(fù)雜的一端。顯示端不寫數(shù)據(jù)庫只做一件事情把「當(dāng)前正在叫的號碼」和「排隊(duì)人數(shù)」拉出來推送到 LED、電視屏或語音盒子。管理端負(fù)責(zé)維護(hù)業(yè)務(wù)類型表、窗口表以及查看當(dāng)日流水和統(tǒng)計(jì)報(bào)表。把這四個角色的調(diào)用關(guān)系畫出來這套源碼至少能看懂八成。剩下兩成是細(xì)節(jié)過號以后號碼怎么重新進(jìn)入隊(duì)列、兩個窗口同時(shí)按叫號時(shí)數(shù)據(jù)庫怎么保證不重號這兩處是判斷一套排隊(duì)機(jī)代碼水平的分水嶺。2.2 號碼生命周期狀態(tài)位是隊(duì)列的命脈排隊(duì)機(jī)的核心表里一定會有一個狀態(tài)字段這套源碼用的是整數(shù)狀態(tài)位設(shè)計(jì)很干凈只有六個值狀態(tài)值含義觸發(fā)動作1待叫已取號還在排隊(duì)取號成功時(shí)寫入2已叫正在窗口辦理或正在等待客戶窗口叫號時(shí)寫入3過號叫了沒來窗口點(diǎn)過號時(shí)寫入4保留位部分版本用作「辦理中」視項(xiàng)目而定5完成業(yè)務(wù)辦結(jié)窗口結(jié)單時(shí)寫入6取消/作廢取號后離開管理端或自動清理時(shí)寫入為什么用整數(shù)而不是用字符串因?yàn)榻刑栠壿嬂镆l繁按狀態(tài)過濾整數(shù)可以直接進(jìn)索引還能用StatusId IN (1, 2)這類寫法一次撈出「還在隊(duì)列里」的所有號碼。我以前見過一個版本用中文狀態(tài)字段報(bào)表統(tǒng)計(jì)時(shí)WHERE Status已叫 AND Status!過號這種條件寫得到處都是后來改狀態(tài)值差點(diǎn)把線上數(shù)據(jù)改崩。這套狀態(tài)機(jī)里唯一需要嚴(yán)格并發(fā)控制的是「1→2」這一步待叫的號碼可能被多個窗口同時(shí)競爭。其余的狀態(tài)遷移比如過號、重呼、結(jié)單都是操作者針對自己窗口已經(jīng)持有的號碼做更新天然不會沖突。2.3 一條完整的指令序列把一次完整業(yè)務(wù)串起來看流水表的變化是這樣的步驟操作者動作數(shù)據(jù)變更1客戶取號機(jī)出票插入流水StatusId1記錄業(yè)務(wù)類型和取號時(shí)間2窗口人員點(diǎn)「叫下一個」原子鎖號StatusId 1→2寫入 WinId、CallTimeCallCount13a窗口人員客戶到窗點(diǎn)「開始辦理」StatusId 2→5寫 FinishTime3b窗口人員客戶未到點(diǎn)「過號」StatusId 2→3保留原 WinId3c窗口人員客戶回來點(diǎn)「重呼」StatusId 3→2CallCount1重寫 CallTime4客戶取號后離開管理端或日終清理時(shí)置 StatusId6這套序列是排查問題的總線索。比如報(bào)表里完成數(shù)偏少就去查是不是有大量記錄卡在狀態(tài) 2 或狀態(tài) 3比如兩個窗口叫出同一個號就去查步驟 2 的鎖號邏輯是不是原子的比如重呼后號碼跑到別的窗口去了就去查重呼時(shí)是不是錯誤地把 WinId 清空了。提示重呼時(shí)不應(yīng)該清空 WinId?？蛻袈牭浇刑柡笠呀?jīng)在走向原窗口重呼只是把號碼拉回「已叫」?fàn)顟B(tài)窗口還是原來那個窗口。如果重呼時(shí)把 WinId 置空這個號碼就會被其他窗口當(dāng)作待叫號搶走窗口之間必然起沖突。3. 數(shù)據(jù)庫是這套源碼的心臟三張核心表與關(guān)鍵 SQL數(shù)據(jù)庫開發(fā)類項(xiàng)目最怕看到一坨沒有主鍵、沒有索引、全靠程序里SELECT *硬撐的表。這套排隊(duì)機(jī)源碼的表結(jié)構(gòu)走的是經(jīng)典的中型業(yè)務(wù)系統(tǒng)路線三張核心表職責(zé)分明索引和約束都建在點(diǎn)子上。3.1 業(yè)務(wù)類型表控制號碼前綴與當(dāng)日序號業(yè)務(wù)類型表的作用是給每種業(yè)務(wù)一個獨(dú)立隊(duì)列。銀行網(wǎng)點(diǎn)里個人業(yè)務(wù)、對公業(yè)務(wù)、理財(cái)業(yè)務(wù)是三條隊(duì)政務(wù)大廳里社保、稅務(wù)、不動產(chǎn)是三條隊(duì)每一條隊(duì)有獨(dú)立的號碼前綴和當(dāng)日序號。CREATE TABLE dbo.t_BizType ( BizTypeId INT IDENTITY(1,1) PRIMARY KEY, -- 業(yè)務(wù)類型ID BizName NVARCHAR(20) NOT NULL, -- 業(yè)務(wù)名顯示在取號機(jī)上 Prefix NVARCHAR(4) NOT NULL, -- 號碼前綴如 A/B/C CurrentSeq INT NOT NULL, -- 當(dāng)日已發(fā)到的序號 StartNo INT NOT NULL DEFAULT 1, -- 當(dāng)日起始序號 Status TINYINT NOT NULL DEFAULT 1 -- 1啟用 0停用 );這里最關(guān)鍵的是CurrentSeq字段。取號邏輯就是把它加一然后拼上前綴生成號碼比如前綴是 A、當(dāng)前序號是 5號碼就是 A0005。這個字段有一個隱含問題跨天之后要?dú)w零。常見做法是每天凌晨跑一個定時(shí)任務(wù)執(zhí)行UPDATE dbo.t_BizType SET CurrentSeq StartNo - 1或者在程序啟動時(shí)檢測系統(tǒng)日期變化后統(tǒng)一重置。粗放一點(diǎn)的項(xiàng)目直接在日終結(jié)算時(shí)重置也能跑但遇到跨天不關(guān)機(jī)的取號機(jī)就有概率發(fā)重號這個坑后面細(xì)說。3.2 窗口表綁定業(yè)務(wù)類型窗口表負(fù)責(zé)定義「哪個窗口辦哪種業(yè)務(wù)」字段不多。CREATE TABLE dbo.t_Window ( WinId INT IDENTITY(1,1) PRIMARY KEY, WinName NVARCHAR(20) NOT NULL, -- 顯示名如 1號窗口 BizTypeId INT NOT NULL, -- 綁定的業(yè)務(wù)類型 DevStatus TINYINT NOT NULL DEFAULT 1, -- 1正常 0暫停 2午休 LastCallNo NVARCHAR(16) NULL -- 最近一次叫的號便于恢復(fù)現(xiàn)場 );窗口跟業(yè)務(wù)類型是「多對一」還是「一對一」實(shí)際項(xiàng)目里經(jīng)常是一個窗口在下午切換業(yè)務(wù)比如上午辦個人業(yè)務(wù)、下午辦對公業(yè)務(wù)。所以窗口端界面上要有「切換業(yè)務(wù)類型」的功能切換時(shí)業(yè)務(wù)類型表不變只改窗口當(dāng)前綁定的 BizTypeId。看到源碼里直接在t_Window上做這個綁定而不是做成中間映射表說明作者是按實(shí)際營業(yè)場景設(shè)計(jì)的不是按教科書設(shè)計(jì)的。3.3 號碼流水表隊(duì)列本身流水表是這套系統(tǒng)里數(shù)據(jù)量最大的表一天幾千到幾萬條一個月后就是幾十萬條。沒有索引的流水表撐不過三個月查詢會明顯變慢。CREATE TABLE dbo.t_TicketFlow ( FlowId BIGINT IDENTITY(1,1) PRIMARY KEY, TicketNo NVARCHAR(16) NOT NULL, -- 業(yè)務(wù)號碼如 A0005 BizTypeId INT NOT NULL, -- 指向業(yè)務(wù)類型表 StatusId TINYINT NOT NULL, -- 1待叫 2已叫 3過號 5完成 6取消 WinId INT NULL, -- 處理該號的窗口叫號后寫入 CreateTime DATETIME NOT NULL, -- 取號時(shí)間 CallTime DATETIME NULL, -- 叫號時(shí)間 FinishTime DATETIME NULL, -- 結(jié)單時(shí)間 CallCount TINYINT NOT NULL DEFAULT 0, -- 叫號/重呼次數(shù) Source NVARCHAR(10) NOT NULL DEFAULT TOUCH ); CREATE INDEX IX_Flow_Queue ON dbo.t_TicketFlow(StatusId, BizTypeId, CreateTime) INCLUDE(TicketNo, WinId);IX_Flow_Queue這個索引是給取號邏輯專門建的按狀態(tài)、業(yè)務(wù)類型、時(shí)間排序取最老的待叫號。因?yàn)椴樵冎灰刈xTicketNo和WinId用 INCLUDE 直接把這些列塞進(jìn)索引葉子節(jié)點(diǎn)避免每次回表讀整行。日終統(tǒng)計(jì)時(shí)流水表按CreateTime過濾這個索引也能頂一部分查詢。需要注意INCLUDE 語法是 SQL Server 的寫法。如果把這套表結(jié)構(gòu)遷移到 MySQL 8要改成普通聯(lián)合索引(StatusId, BizTypeId, CreateTime, TicketNo, WinId)遷移到 PostgreSQL 則可以直接建INCLUDE兩者的索引機(jī)制類似。關(guān)鍵的統(tǒng)計(jì) SQL 有兩句。一句是看每個窗口的待辦積壓SELECT w.WinName, SUM(CASE WHEN f.StatusId 1 THEN 1 ELSE 0 END) AS WaitingCount FROM dbo.t_Window w LEFT JOIN dbo.t_TicketFlow f ON f.BizTypeId w.BizTypeId AND f.WinId IS NULL AND CONVERT(DATE, f.CreateTime) CONVERT(DATE, GETDATE()) WHERE w.DevStatus 1 GROUP BY w.WinName;另一句是看全天的平均等待時(shí)長這是營業(yè)廳管理最看重的指標(biāo)SELECT AVG(DATEDIFF(SECOND, CreateTime, CallTime)) AS AvgWaitSec, COUNT(*) AS CalledCount FROM dbo.t_TicketFlow WHERE CONVERT(DATE, CreateTime) CONVERT(DATE, GETDATE()) AND CallTime IS NOT NULL;注意CONVERT(DATE, CreateTime)這類寫法在流水表數(shù)據(jù)量大時(shí)會放棄索引掃描全表。幾十萬條以內(nèi)沒感覺上了百萬條就要改成CreateTime 2025-06-01 AND CreateTime 2025-06-02的區(qū)間寫法。調(diào)試時(shí)如果發(fā)現(xiàn)報(bào)表越跑越慢先看執(zhí)行計(jì)劃是不是走了索引。4. 多窗口并發(fā)與調(diào)度策略怎么保證兩個窗口不叫到同一個號排隊(duì)機(jī)的并發(fā)問題集中在兩個窗口同時(shí)按「叫下一個」的瞬間。兩個窗口讀取到同一個待叫號碼、同時(shí)更新成功屏幕上兩個窗口都在喊同一個號客戶一臉懵。這個問題不是玄學(xué)是典型的讀寫競態(tài)解決思路只有一個把「查詢待叫號碼」和「把號碼標(biāo)記為己叫」合并成一個原子操作。4.1 重號是怎么發(fā)生的最容易出問題的寫法是「先查再更」窗口端先執(zhí)行SELECT TOP 1 ... WHERE StatusId 1拿到一個號碼顯示在界面上用戶點(diǎn)確認(rèn)后再執(zhí)行UPDATE ... SET StatusId 2。問題出在兩步之間有空窗窗口 A 查到了 A0005界面彈出確認(rèn)框窗口 B 在確認(rèn)框彈出的這一瞬間也執(zhí)行查詢同樣拿到 A0005兩邊都點(diǎn)確認(rèn)兩個 Update 都成功重號就發(fā)生了。我見過某個版本試圖用「程序里加鎖變量」來解決在單機(jī)進(jìn)程里定義一個靜態(tài)變量窗口端先搶到這個變量才能查號。這在單機(jī)演示時(shí)沒問題但排隊(duì)機(jī)是局域網(wǎng)多終端架構(gòu)取號機(jī)、多個窗口工控機(jī)連同一個數(shù)據(jù)庫進(jìn)程內(nèi)的鎖根本鎖不住其他機(jī)器的請求。所以這套源碼把鎖挪到了數(shù)據(jù)庫層用存儲過程解決方向是對的。4.2 用 UPDLOCK READPAST 實(shí)現(xiàn)原子取號這套源碼里的取號存儲過程是核心結(jié)構(gòu)大致如下CREATE PROCEDURE dbo.usp_CallNext WinId INT, -- 發(fā)起叫號的窗口ID BizTypeId INT -- 該窗口當(dāng)前受理的業(yè)務(wù)類型 AS BEGIN SET NOCOUNT ON; DECLARE TicketNo NVARCHAR(16); DECLARE FlowId BIGINT; BEGIN TRAN; -- 帶 UPDLOCK 鎖定掃描到的行帶 READPAST 跳過已被其他事務(wù)鎖住的行 SELECT TOP 1 FlowId FlowId, TicketNo TicketNo FROM dbo.t_TicketFlow WITH (UPDLOCK, READPAST) WHERE BizTypeId BizTypeId AND StatusId 1 AND WinId IS NULL ORDER BY CreateTime ASC, FlowId ASC; IF FlowId IS NULL BEGIN ROLLBACK; RETURN -1; -- 隊(duì)列為空 END; UPDATE dbo.t_TicketFlow SET StatusId 2, WinId WinId, CallTime GETDATE(), CallCount CallCount 1 WHERE FlowId FlowId; COMMIT; SELECT TicketNo AS TicketNo; END;這段邏輯的關(guān)鍵在WITH (UPDLOCK, READPAST)兩個提示的組合。UPDLOCK讓查詢在讀到行的時(shí)候就對該行加更新鎖后續(xù)其他事務(wù)再來讀同一行會被阻塞READPAST則保證當(dāng)前事務(wù)跳過已經(jīng)被別人鎖住的行不會傻等。兩者配合的效果是窗口 A 先執(zhí)行鎖住 A0005 并改成已叫窗口 B 同時(shí)執(zhí)行讀的時(shí)候直接跳過 A0005拿到下一條 A0006。這就是「既不重號、又不互相阻塞」的數(shù)據(jù)庫層實(shí)現(xiàn)。如果是 MySQL 8 環(huán)境等價(jià)寫法是SELECT ... FOR UPDATE SKIP LOCKEDPostgreSQL 也支持SKIP LOCKED。SQL Server 這套 Hint 語法在老項(xiàng)目里最常見所以排障時(shí)遇到同類源碼先找有沒有這兩個關(guān)鍵詞。4.3 窗口端調(diào)用與廣播解耦存儲過程只負(fù)責(zé)「把號碼從隊(duì)列里取出來并更新狀態(tài)」窗口端拿到號碼之后還要推送給 LED 屏幕和語音盒子。這里有一個重要的邊界數(shù)據(jù)庫狀態(tài)更新是主事務(wù)推送屏幕是附屬動作附屬動作失敗不能回滾主事務(wù)。// 窗口端“叫下一個”按鈕的完整處理 private void btnCallNext_Click(object sender, EventArgs e) { string ticketNo; // 第一步調(diào)存儲過程原子取號 using (var conn new SqlConnection(CONN_STR)) using (var cmd new SqlCommand(dbo.usp_CallNext, conn)) { cmd.CommandType CommandType.StoredProcedure; cmd.Parameters.AddWithValue(WinId, winId); cmd.Parameters.AddWithValue(BizTypeId, bizTypeId); conn.Open(); // 隊(duì)列為空時(shí)存儲過程返回 -1這里表現(xiàn)為取不到值 ticketNo (string)cmd.ExecuteScalar(); } if (string.IsNullOrEmpty(ticketNo)) { MessageBox.Show(當(dāng)前隊(duì)列為空請先取號, 提示, MessageBoxButtons.OK, MessageBoxIcon.Information); return; } // 第二步廣播。推送失敗不撤銷叫號只記錄日志 try { DisplayProxy.ShowNow(ticketNo, winName); VoiceProxy.Speak($請{ticketNo}號到{winName}窗口辦理); } catch (Exception ex) { Log.Error(廣播失敗但號碼已生效請人工喊號, ex); } }winId和bizTypeId是窗口端登錄后從配置表讀取的參數(shù)。廣播失敗時(shí)的處理是很多項(xiàng)目忽略的如果推送成功后 LED 屏幕斷電客戶看不到號碼窗口人員只能人工喊號此時(shí)如果代碼把數(shù)據(jù)庫狀態(tài)回滾成待叫那其他窗口就可能把這個號再叫一次徹底亂套。所以廣播失敗的正確做法是記日志、提示窗口人員、但不回滾。調(diào)度策略上這套代碼用的是「窗口主動搶占」模式窗口空閑時(shí)點(diǎn)按鈕去隊(duì)列里搶最老的號。另一種模式是「系統(tǒng)自動派號」取號時(shí)直接分配指定窗口客戶憑票去對應(yīng)窗口適合流水線式作業(yè)但銀行政務(wù)類場景用戶體驗(yàn)差客戶不知道被分到哪個窗口實(shí)際項(xiàng)目里很少用。提示如果某天線上出現(xiàn)了重號第一件事是查數(shù)據(jù)庫日志里這兩個 Update 的執(zhí)行順序和事務(wù)隔離級別而不是先改窗口端代碼。絕大多數(shù)重號問題根源在數(shù)據(jù)庫層界面端代碼改一百遍也沒用。5. 排隊(duì)機(jī)避坑指南五個真實(shí)翻車現(xiàn)場與修復(fù)方法這套源碼整體邏輯是完整的但實(shí)際部署中坑點(diǎn)不少。下面五條都是我見過或經(jīng)歷過的典型問題按「現(xiàn)象 → 原因 → 解決」整理出來照著排查能省半天時(shí)間。5.1 兩個窗口同時(shí)叫出同一個號現(xiàn)象早高峰兩個窗口幾乎同時(shí)點(diǎn)叫號LED 屏和語音同時(shí)播同一個號碼客戶不知道去哪個窗口窗口人員互相推諉。原因這不是數(shù)據(jù)庫并發(fā)問題而是流程設(shè)計(jì)問題。舊版本窗口端做了「預(yù)取號」程序先把待叫號查出來顯示在界面上等窗口人員確認(rèn)后再更新狀態(tài)。預(yù)取號和確認(rèn)之間的空窗期另一個窗口也能查到同一個號。窗口人員手速越快重號概率越高。解決嚴(yán)格走usp_CallNext存儲過程把查號和鎖號合并為一次數(shù)據(jù)庫操作。如果業(yè)務(wù)上必須保留確認(rèn)彈窗就把彈窗放在「調(diào)存儲過程之后」而不是之前先落庫拿到號碼彈窗只是展示結(jié)果不是確認(rèn)項(xiàng)。這一條改動就能根治重號。5.2 客戶還沒走到窗口號碼就變成過號了現(xiàn)象老年客戶從取號機(jī)拿完號走到窗口路上用了兩分鐘到窗口時(shí)系統(tǒng)已經(jīng)顯示「已過號」窗口人員重新叫號時(shí)客戶一臉委屈現(xiàn)場吵起來。原因過號等待時(shí)間寫死在代碼里默認(rèn)值只有 30 秒。代碼里用的是Thread.Sleep(30000)這類硬編碼部署時(shí)沒人去改。大廳越大、窗口越遠(yuǎn)、客戶群體年齡越大這個值就越不合理。解決把過號等待間隔做成配置表參數(shù)過號判定邏輯統(tǒng)一讀配置。配置表就兩列一列鍵一列值INSERT INTO dbo.t_Config ([Key], [Value]) VALUES (WaitTimeoutSec, 180);窗口端判定邏輯改成SELECT Value FROM dbo.t_Config WHERE [Key] WaitTimeoutSec取不到值時(shí)默認(rèn) 120 秒。另外窗口端要保留「撤銷過號」按鈕客戶到了就點(diǎn)一下把狀態(tài)從 3 拉回 2同時(shí)記錄一條操作日志避免被投訴時(shí)說不清楚。5.3 LED 屏幕顯示亂碼現(xiàn)象號碼數(shù)字正常漢字和字母變成「口」或菱形某些批次屏幕正常、某些批次亂碼。原因LED 控制器和程序約定的編碼不一致。常見組合是控制卡默認(rèn) GB2312程序按 UTF-8 拼報(bào)文或者反過來。同類源碼復(fù)制到不同網(wǎng)點(diǎn)顯示屏廠家不一樣編碼約定就不一樣看起來像系統(tǒng)「時(shí)好時(shí)壞」其實(shí)是換屏的時(shí)候沒同步改編碼。解決把編碼參數(shù)做成每個網(wǎng)點(diǎn)的配置項(xiàng)不要在代碼里寫死。調(diào)試時(shí)直接用串口工具抓報(bào)文看 Hex 字節(jié)流對照 GB2312 或 UTF-8 的碼表一看就知道哪一端錯了。這個坑最好在部署階段就統(tǒng)一確認(rèn)等上線后再改要同時(shí)改程序和屏參來回折騰。5.4 日報(bào)表統(tǒng)計(jì)數(shù)量比實(shí)際少了 20%現(xiàn)象晚上打印日報(bào)表系統(tǒng)統(tǒng)計(jì)當(dāng)天辦理 80 筆營業(yè)廳手寫臺賬記了 90 筆差了 10 筆。查流水表發(fā)現(xiàn)有一部分記錄狀態(tài)停在了「已叫」。原因窗口人員點(diǎn)「結(jié)單」按鈕時(shí)界面上的客戶記錄消失了但數(shù)據(jù)庫狀態(tài)沒有更新。舊代碼里「開始辦理」只改了前端界面狀態(tài)對應(yīng)數(shù)據(jù)庫根本沒有任何更新操作真正把狀態(tài)改成完成的那段代碼只存在于另一個沒人調(diào)用的模塊里。報(bào)表按 StatusId5 統(tǒng)計(jì)自然偏少。解決強(qiáng)制約定結(jié)單必須走統(tǒng)一的更新語句把StatusId從 2 改成 5 并寫入FinishTime。排查時(shí)用一個分組查詢看狀態(tài)分布哪里異常一眼可見SELECT StatusId, COUNT(*) AS Cnt FROM dbo.t_TicketFlow WHERE CONVERT(DATE, CreateTime) CONVERT(DATE, GETDATE()) GROUP BY StatusId;正常一天跑下來狀態(tài) 5完成應(yīng)該占絕大多數(shù)狀態(tài) 1 和狀態(tài) 2 是營業(yè)結(jié)束時(shí)還殘留在隊(duì)列里的少量號碼狀態(tài) 3 是過號。如果狀態(tài) 2 占比異常高說明「結(jié)單不落庫」的問題還在。5.5 取號機(jī)間歇性卡死重啟后恢復(fù)現(xiàn)象客戶按取號后紙質(zhì)票打印不出來或者觸摸屏轉(zhuǎn)圈十幾秒重啟軟件恢復(fù)過半天又犯。原因打印控件同步調(diào)用打印機(jī)打印機(jī)走網(wǎng)絡(luò)共享時(shí)響應(yīng)慢超時(shí)期間取號事務(wù)一致沒提交數(shù)據(jù)庫連接被占滿后面所有取號請求都在等連接表現(xiàn)為整個取號端卡死。這是典型的「外部設(shè)備拖垮主流程」。解決取號寫庫和打印徹底解耦。按鈕點(diǎn)擊后先執(zhí)行取號存儲過程拿到號碼立刻提示「取號成功」打印丟到后臺線程隊(duì)列慢慢處理失敗只記日志不彈窗。同時(shí)給所有SqlConnection設(shè)置短連接超時(shí)比如Connect Timeout 3避免單臺設(shè)備異常拖垮整個系統(tǒng)。6. 部署后怎么驗(yàn)證造數(shù)、并發(fā)測試與參數(shù)配置化拿到這套源碼不要急著改業(yè)務(wù)流程先做三輪驗(yàn)證。第一輪是造數(shù)據(jù)驗(yàn)證統(tǒng)計(jì)邏輯。寫一段腳本往流水表灌一天的量比如 3000 條記錄時(shí)間從早上 9 點(diǎn)均勻分布到下午 5 點(diǎn)狀態(tài)隨機(jī)落在 1、2、3、5然后跑前面那兩句統(tǒng)計(jì) SQL確認(rèn)報(bào)表口徑和你預(yù)期一致。這個步驟能提前發(fā)現(xiàn)狀態(tài)位含義和報(bào)表邏輯的錯位。第二輪是并發(fā)驗(yàn)證。打開五個數(shù)據(jù)庫查詢窗口模擬五個窗口同時(shí)執(zhí)行usp_CallNext連續(xù)跑幾十次觀察返回的號碼有沒有重復(fù)有沒有返回空值。正常情況每次返回的號碼都應(yīng)該嚴(yán)格遞增且不重復(fù)。如果出現(xiàn)重復(fù)回到第 4 章的鎖機(jī)制排查如果出現(xiàn)大量空值說明鎖粒度太粗事務(wù)互相阻塞嚴(yán)重要檢查是不是漏了READPAST。第三輪是把行為參數(shù)全部配置化。WaitTimeoutSec過號等待秒數(shù)、MaxCallCount號碼最大重呼次數(shù)、DailyResetTime每日序號歸零時(shí)間這些值全部挪到t_Config表里改參數(shù)不用重新編譯程序。我之前接手一個項(xiàng)目對方說系統(tǒng)「時(shí)好時(shí)壞很玄學(xué)」排查到最后發(fā)現(xiàn)是某臺窗口電腦的系統(tǒng)時(shí)間快了八分鐘叫號記錄和過號判斷全部錯位。從那以后我拿到任何排隊(duì)機(jī)源碼第一件事就是檢查所有終端的時(shí)間同步再做并發(fā)壓測最后才動業(yè)務(wù)邏輯。希望你拿到的這套代碼能少踩幾個類似的坑祝順利。本文還有配套的精品資源點(diǎn)擊獲取 排隊(duì)機(jī)叫號源代碼解析：狀態(tài)機(jī)模型與數(shù)據(jù)庫并發(fā)控制
簡介面向C#初學(xué)者以及正在設(shè)計(jì)排隊(duì)機(jī)、叫號系統(tǒng)的開發(fā)者這套源代碼提供了一套經(jīng)過多年客戶實(shí)際使用驗(yàn)證的完整方案覆蓋叫號邏輯、數(shù)據(jù)庫訪問、界面展示與報(bào)表打印等環(huán)節(jié)可幫助理解真實(shí)項(xiàng)目中的模塊劃分與數(shù)據(jù)流轉(zhuǎn)方式。壓縮包共249個文件以172個cs源碼文件為主體輔以44個resx界面資源、9個ico圖標(biāo)、6個user自定義控件、5個settings配置以及2個rdlc報(bào)表定義整體僅1.29MB結(jié)構(gòu)緊湊便于直接閱讀與二次開發(fā)。已有1617人瀏覽學(xué)習(xí)。代碼中包含DbHelperSQL等數(shù)據(jù)庫輔助類、frmCaller與frmScreen等核心窗體以及MyCommon公共方法模塊覆蓋從數(shù)據(jù)庫操作到多窗體協(xié)作的典型實(shí)現(xiàn)適合初學(xué)者拆解學(xué)習(xí)也可為實(shí)際項(xiàng)目提供可復(fù)用的設(shè)計(jì)思路與代碼骨架節(jié)省從零搭建系統(tǒng)的時(shí)間。1. 排隊(duì)機(jī)叫號源代碼本質(zhì)是一臺隊(duì)列狀態(tài)機(jī)「排隊(duì)機(jī)叫號源代碼」這幾個字聽起來像是一個「能叫號的程序」但真正拿到這種項(xiàng)目的人會發(fā)現(xiàn)叫號只是最表面的動作。取號、分配、叫號、過號、重呼、結(jié)單每一步都是一個狀態(tài)在數(shù)據(jù)庫里的流轉(zhuǎn)而最常見的翻車現(xiàn)場——兩個窗口搶同一個號、客戶沒到窗口號就過了、日報(bào)表數(shù)字對不上——全都出在狀態(tài)沒有守住而不是出在界面按鈕上。這套源代碼的價(jià)值在于把整條隊(duì)列的狀態(tài)管理從頭到尾做完了數(shù)據(jù)庫表怎么建、并發(fā)時(shí)怎么鎖號、過號之后怎么拉回來邏輯是一脈貫通的。它適合兩類人一類是接手維護(hù)網(wǎng)點(diǎn)排隊(duì)機(jī)系統(tǒng)的從業(yè)者想快速看懂老工程另一類是在做數(shù)據(jù)庫課程設(shè)計(jì)、需要真實(shí)業(yè)務(wù)場景源碼來改造的學(xué)生。2. 取號到結(jié)單的完整流轉(zhuǎn)四個角色與一套狀態(tài)碼任何一套排隊(duì)機(jī)源碼不管是銀行大堂、政務(wù)大廳還是醫(yī)院藥房用的拆開看都是四個角色在操作同一張?zhí)柎a流水表取號端負(fù)責(zé)產(chǎn)生號碼窗口端負(fù)責(zé)消費(fèi)號碼顯示端負(fù)責(zé)把當(dāng)前狀態(tài)廣播出去管理端負(fù)責(zé)配置和統(tǒng)計(jì)。這套代碼里四個角色沒有各自建表而是共享一張流水表靠狀態(tài)碼區(qū)分「這個號碼現(xiàn)在走到哪一步」。2.1 四個角色的職責(zé)劃分取號端一般是觸摸屏或者窗口人員代取動作只有一個調(diào)用取號邏輯生成一個當(dāng)天唯一的業(yè)務(wù)號碼插入流水表并置為待叫狀態(tài)。窗口端是叫號人員手里的操作界面包含叫下一個、過號、重呼、開始辦理、結(jié)單這五個動作是最復(fù)雜的一端。顯示端不寫數(shù)據(jù)庫只做一件事情把「當(dāng)前正在叫的號碼」和「排隊(duì)人數(shù)」拉出來推送到 LED、電視屏或語音盒子。管理端負(fù)責(zé)維護(hù)業(yè)務(wù)類型表、窗口表以及查看當(dāng)日流水和統(tǒng)計(jì)報(bào)表。把這四個角色的調(diào)用關(guān)系畫出來這套源碼至少能看懂八成。剩下兩成是細(xì)節(jié)過號以后號碼怎么重新進(jìn)入隊(duì)列、兩個窗口同時(shí)按叫號時(shí)數(shù)據(jù)庫怎么保證不重號這兩處是判斷一套排隊(duì)機(jī)代碼水平的分水嶺。2.2 號碼生命周期狀態(tài)位是隊(duì)列的命脈排隊(duì)機(jī)的核心表里一定會有一個狀態(tài)字段這套源碼用的是整數(shù)狀態(tài)位設(shè)計(jì)很干凈只有六個值狀態(tài)值含義觸發(fā)動作1待叫已取號還在排隊(duì)取號成功時(shí)寫入2已叫正在窗口辦理或正在等待客戶窗口叫號時(shí)寫入3過號叫了沒來窗口點(diǎn)過號時(shí)寫入4保留位部分版本用作「辦理中」視項(xiàng)目而定5完成業(yè)務(wù)辦結(jié)窗口結(jié)單時(shí)寫入6取消/作廢取號后離開管理端或自動清理時(shí)寫入為什么用整數(shù)而不是用字符串因?yàn)榻刑栠壿嬂镆l繁按狀態(tài)過濾整數(shù)可以直接進(jìn)索引還能用StatusId IN (1, 2)這類寫法一次撈出「還在隊(duì)列里」的所有號碼。我以前見過一個版本用中文狀態(tài)字段報(bào)表統(tǒng)計(jì)時(shí)WHERE Status已叫 AND Status!過號這種條件寫得到處都是后來改狀態(tài)值差點(diǎn)把線上數(shù)據(jù)改崩。這套狀態(tài)機(jī)里唯一需要嚴(yán)格并發(fā)控制的是「1→2」這一步待叫的號碼可能被多個窗口同時(shí)競爭。其余的狀態(tài)遷移比如過號、重呼、結(jié)單都是操作者針對自己窗口已經(jīng)持有的號碼做更新天然不會沖突。2.3 一條完整的指令序列把一次完整業(yè)務(wù)串起來看流水表的變化是這樣的步驟操作者動作數(shù)據(jù)變更1客戶取號機(jī)出票插入流水StatusId1記錄業(yè)務(wù)類型和取號時(shí)間2窗口人員點(diǎn)「叫下一個」原子鎖號StatusId 1→2寫入 WinId、CallTimeCallCount13a窗口人員客戶到窗點(diǎn)「開始辦理」StatusId 2→5寫 FinishTime3b窗口人員客戶未到點(diǎn)「過號」StatusId 2→3保留原 WinId3c窗口人員客戶回來點(diǎn)「重呼」StatusId 3→2CallCount1重寫 CallTime4客戶取號后離開管理端或日終清理時(shí)置 StatusId6這套序列是排查問題的總線索。比如報(bào)表里完成數(shù)偏少就去查是不是有大量記錄卡在狀態(tài) 2 或狀態(tài) 3比如兩個窗口叫出同一個號就去查步驟 2 的鎖號邏輯是不是原子的比如重呼后號碼跑到別的窗口去了就去查重呼時(shí)是不是錯誤地把 WinId 清空了。提示重呼時(shí)不應(yīng)該清空 WinId?？蛻袈牭浇刑柡笠呀?jīng)在走向原窗口重呼只是把號碼拉回「已叫」?fàn)顟B(tài)窗口還是原來那個窗口。如果重呼時(shí)把 WinId 置空這個號碼就會被其他窗口當(dāng)作待叫號搶走窗口之間必然起沖突。3. 數(shù)據(jù)庫是這套源碼的心臟三張核心表與關(guān)鍵 SQL數(shù)據(jù)庫開發(fā)類項(xiàng)目最怕看到一坨沒有主鍵、沒有索引、全靠程序里SELECT *硬撐的表。這套排隊(duì)機(jī)源碼的表結(jié)構(gòu)走的是經(jīng)典的中型業(yè)務(wù)系統(tǒng)路線三張核心表職責(zé)分明索引和約束都建在點(diǎn)子上。3.1 業(yè)務(wù)類型表控制號碼前綴與當(dāng)日序號業(yè)務(wù)類型表的作用是給每種業(yè)務(wù)一個獨(dú)立隊(duì)列。銀行網(wǎng)點(diǎn)里個人業(yè)務(wù)、對公業(yè)務(wù)、理財(cái)業(yè)務(wù)是三條隊(duì)政務(wù)大廳里社保、稅務(wù)、不動產(chǎn)是三條隊(duì)每一條隊(duì)有獨(dú)立的號碼前綴和當(dāng)日序號。CREATE TABLE dbo.t_BizType ( BizTypeId INT IDENTITY(1,1) PRIMARY KEY, -- 業(yè)務(wù)類型ID BizName NVARCHAR(20) NOT NULL, -- 業(yè)務(wù)名顯示在取號機(jī)上 Prefix NVARCHAR(4) NOT NULL, -- 號碼前綴如 A/B/C CurrentSeq INT NOT NULL, -- 當(dāng)日已發(fā)到的序號 StartNo INT NOT NULL DEFAULT 1, -- 當(dāng)日起始序號 Status TINYINT NOT NULL DEFAULT 1 -- 1啟用 0停用 );這里最關(guān)鍵的是CurrentSeq字段。取號邏輯就是把它加一然后拼上前綴生成號碼比如前綴是 A、當(dāng)前序號是 5號碼就是 A0005。這個字段有一個隱含問題跨天之后要?dú)w零。常見做法是每天凌晨跑一個定時(shí)任務(wù)執(zhí)行UPDATE dbo.t_BizType SET CurrentSeq StartNo - 1或者在程序啟動時(shí)檢測系統(tǒng)日期變化后統(tǒng)一重置。粗放一點(diǎn)的項(xiàng)目直接在日終結(jié)算時(shí)重置也能跑但遇到跨天不關(guān)機(jī)的取號機(jī)就有概率發(fā)重號這個坑后面細(xì)說。3.2 窗口表綁定業(yè)務(wù)類型窗口表負(fù)責(zé)定義「哪個窗口辦哪種業(yè)務(wù)」字段不多。CREATE TABLE dbo.t_Window ( WinId INT IDENTITY(1,1) PRIMARY KEY, WinName NVARCHAR(20) NOT NULL, -- 顯示名如 1號窗口 BizTypeId INT NOT NULL, -- 綁定的業(yè)務(wù)類型 DevStatus TINYINT NOT NULL DEFAULT 1, -- 1正常 0暫停 2午休 LastCallNo NVARCHAR(16) NULL -- 最近一次叫的號便于恢復(fù)現(xiàn)場 );窗口跟業(yè)務(wù)類型是「多對一」還是「一對一」實(shí)際項(xiàng)目里經(jīng)常是一個窗口在下午切換業(yè)務(wù)比如上午辦個人業(yè)務(wù)、下午辦對公業(yè)務(wù)。所以窗口端界面上要有「切換業(yè)務(wù)類型」的功能切換時(shí)業(yè)務(wù)類型表不變只改窗口當(dāng)前綁定的 BizTypeId。看到源碼里直接在t_Window上做這個綁定而不是做成中間映射表說明作者是按實(shí)際營業(yè)場景設(shè)計(jì)的不是按教科書設(shè)計(jì)的。3.3 號碼流水表隊(duì)列本身流水表是這套系統(tǒng)里數(shù)據(jù)量最大的表一天幾千到幾萬條一個月后就是幾十萬條。沒有索引的流水表撐不過三個月查詢會明顯變慢。CREATE TABLE dbo.t_TicketFlow ( FlowId BIGINT IDENTITY(1,1) PRIMARY KEY, TicketNo NVARCHAR(16) NOT NULL, -- 業(yè)務(wù)號碼如 A0005 BizTypeId INT NOT NULL, -- 指向業(yè)務(wù)類型表 StatusId TINYINT NOT NULL, -- 1待叫 2已叫 3過號 5完成 6取消 WinId INT NULL, -- 處理該號的窗口叫號后寫入 CreateTime DATETIME NOT NULL, -- 取號時(shí)間 CallTime DATETIME NULL, -- 叫號時(shí)間 FinishTime DATETIME NULL, -- 結(jié)單時(shí)間 CallCount TINYINT NOT NULL DEFAULT 0, -- 叫號/重呼次數(shù) Source NVARCHAR(10) NOT NULL DEFAULT TOUCH ); CREATE INDEX IX_Flow_Queue ON dbo.t_TicketFlow(StatusId, BizTypeId, CreateTime) INCLUDE(TicketNo, WinId);IX_Flow_Queue這個索引是給取號邏輯專門建的按狀態(tài)、業(yè)務(wù)類型、時(shí)間排序取最老的待叫號。因?yàn)椴樵冎灰刈xTicketNo和WinId用 INCLUDE 直接把這些列塞進(jìn)索引葉子節(jié)點(diǎn)避免每次回表讀整行。日終統(tǒng)計(jì)時(shí)流水表按CreateTime過濾這個索引也能頂一部分查詢。需要注意INCLUDE 語法是 SQL Server 的寫法。如果把這套表結(jié)構(gòu)遷移到 MySQL 8要改成普通聯(lián)合索引(StatusId, BizTypeId, CreateTime, TicketNo, WinId)遷移到 PostgreSQL 則可以直接建INCLUDE兩者的索引機(jī)制類似。關(guān)鍵的統(tǒng)計(jì) SQL 有兩句。一句是看每個窗口的待辦積壓SELECT w.WinName, SUM(CASE WHEN f.StatusId 1 THEN 1 ELSE 0 END) AS WaitingCount FROM dbo.t_Window w LEFT JOIN dbo.t_TicketFlow f ON f.BizTypeId w.BizTypeId AND f.WinId IS NULL AND CONVERT(DATE, f.CreateTime) CONVERT(DATE, GETDATE()) WHERE w.DevStatus 1 GROUP BY w.WinName;另一句是看全天的平均等待時(shí)長這是營業(yè)廳管理最看重的指標(biāo)SELECT AVG(DATEDIFF(SECOND, CreateTime, CallTime)) AS AvgWaitSec, COUNT(*) AS CalledCount FROM dbo.t_TicketFlow WHERE CONVERT(DATE, CreateTime) CONVERT(DATE, GETDATE()) AND CallTime IS NOT NULL;注意CONVERT(DATE, CreateTime)這類寫法在流水表數(shù)據(jù)量大時(shí)會放棄索引掃描全表。幾十萬條以內(nèi)沒感覺上了百萬條就要改成CreateTime 2025-06-01 AND CreateTime 2025-06-02的區(qū)間寫法。調(diào)試時(shí)如果發(fā)現(xiàn)報(bào)表越跑越慢先看執(zhí)行計(jì)劃是不是走了索引。4. 多窗口并發(fā)與調(diào)度策略怎么保證兩個窗口不叫到同一個號排隊(duì)機(jī)的并發(fā)問題集中在兩個窗口同時(shí)按「叫下一個」的瞬間。兩個窗口讀取到同一個待叫號碼、同時(shí)更新成功屏幕上兩個窗口都在喊同一個號客戶一臉懵。這個問題不是玄學(xué)是典型的讀寫競態(tài)解決思路只有一個把「查詢待叫號碼」和「把號碼標(biāo)記為己叫」合并成一個原子操作。4.1 重號是怎么發(fā)生的最容易出問題的寫法是「先查再更」窗口端先執(zhí)行SELECT TOP 1 ... WHERE StatusId 1拿到一個號碼顯示在界面上用戶點(diǎn)確認(rèn)后再執(zhí)行UPDATE ... SET StatusId 2。問題出在兩步之間有空窗窗口 A 查到了 A0005界面彈出確認(rèn)框窗口 B 在確認(rèn)框彈出的這一瞬間也執(zhí)行查詢同樣拿到 A0005兩邊都點(diǎn)確認(rèn)兩個 Update 都成功重號就發(fā)生了。我見過某個版本試圖用「程序里加鎖變量」來解決在單機(jī)進(jìn)程里定義一個靜態(tài)變量窗口端先搶到這個變量才能查號。這在單機(jī)演示時(shí)沒問題但排隊(duì)機(jī)是局域網(wǎng)多終端架構(gòu)取號機(jī)、多個窗口工控機(jī)連同一個數(shù)據(jù)庫進(jìn)程內(nèi)的鎖根本鎖不住其他機(jī)器的請求。所以這套源碼把鎖挪到了數(shù)據(jù)庫層用存儲過程解決方向是對的。4.2 用 UPDLOCK READPAST 實(shí)現(xiàn)原子取號這套源碼里的取號存儲過程是核心結(jié)構(gòu)大致如下CREATE PROCEDURE dbo.usp_CallNext WinId INT, -- 發(fā)起叫號的窗口ID BizTypeId INT -- 該窗口當(dāng)前受理的業(yè)務(wù)類型 AS BEGIN SET NOCOUNT ON; DECLARE TicketNo NVARCHAR(16); DECLARE FlowId BIGINT; BEGIN TRAN; -- 帶 UPDLOCK 鎖定掃描到的行帶 READPAST 跳過已被其他事務(wù)鎖住的行 SELECT TOP 1 FlowId FlowId, TicketNo TicketNo FROM dbo.t_TicketFlow WITH (UPDLOCK, READPAST) WHERE BizTypeId BizTypeId AND StatusId 1 AND WinId IS NULL ORDER BY CreateTime ASC, FlowId ASC; IF FlowId IS NULL BEGIN ROLLBACK; RETURN -1; -- 隊(duì)列為空 END; UPDATE dbo.t_TicketFlow SET StatusId 2, WinId WinId, CallTime GETDATE(), CallCount CallCount 1 WHERE FlowId FlowId; COMMIT; SELECT TicketNo AS TicketNo; END;這段邏輯的關(guān)鍵在WITH (UPDLOCK, READPAST)兩個提示的組合。UPDLOCK讓查詢在讀到行的時(shí)候就對該行加更新鎖后續(xù)其他事務(wù)再來讀同一行會被阻塞READPAST則保證當(dāng)前事務(wù)跳過已經(jīng)被別人鎖住的行不會傻等。兩者配合的效果是窗口 A 先執(zhí)行鎖住 A0005 并改成已叫窗口 B 同時(shí)執(zhí)行讀的時(shí)候直接跳過 A0005拿到下一條 A0006。這就是「既不重號、又不互相阻塞」的數(shù)據(jù)庫層實(shí)現(xiàn)。如果是 MySQL 8 環(huán)境等價(jià)寫法是SELECT ... FOR UPDATE SKIP LOCKEDPostgreSQL 也支持SKIP LOCKED。SQL Server 這套 Hint 語法在老項(xiàng)目里最常見所以排障時(shí)遇到同類源碼先找有沒有這兩個關(guān)鍵詞。4.3 窗口端調(diào)用與廣播解耦存儲過程只負(fù)責(zé)「把號碼從隊(duì)列里取出來并更新狀態(tài)」窗口端拿到號碼之后還要推送給 LED 屏幕和語音盒子。這里有一個重要的邊界數(shù)據(jù)庫狀態(tài)更新是主事務(wù)推送屏幕是附屬動作附屬動作失敗不能回滾主事務(wù)。// 窗口端“叫下一個”按鈕的完整處理 private void btnCallNext_Click(object sender, EventArgs e) { string ticketNo; // 第一步調(diào)存儲過程原子取號 using (var conn new SqlConnection(CONN_STR)) using (var cmd new SqlCommand(dbo.usp_CallNext, conn)) { cmd.CommandType CommandType.StoredProcedure; cmd.Parameters.AddWithValue(WinId, winId); cmd.Parameters.AddWithValue(BizTypeId, bizTypeId); conn.Open(); // 隊(duì)列為空時(shí)存儲過程返回 -1這里表現(xiàn)為取不到值 ticketNo (string)cmd.ExecuteScalar(); } if (string.IsNullOrEmpty(ticketNo)) { MessageBox.Show(當(dāng)前隊(duì)列為空請先取號, 提示, MessageBoxButtons.OK, MessageBoxIcon.Information); return; } // 第二步廣播。推送失敗不撤銷叫號只記錄日志 try { DisplayProxy.ShowNow(ticketNo, winName); VoiceProxy.Speak($請{ticketNo}號到{winName}窗口辦理); } catch (Exception ex) { Log.Error(廣播失敗但號碼已生效請人工喊號, ex); } }winId和bizTypeId是窗口端登錄后從配置表讀取的參數(shù)。廣播失敗時(shí)的處理是很多項(xiàng)目忽略的如果推送成功后 LED 屏幕斷電客戶看不到號碼窗口人員只能人工喊號此時(shí)如果代碼把數(shù)據(jù)庫狀態(tài)回滾成待叫那其他窗口就可能把這個號再叫一次徹底亂套。所以廣播失敗的正確做法是記日志、提示窗口人員、但不回滾。調(diào)度策略上這套代碼用的是「窗口主動搶占」模式窗口空閑時(shí)點(diǎn)按鈕去隊(duì)列里搶最老的號。另一種模式是「系統(tǒng)自動派號」取號時(shí)直接分配指定窗口客戶憑票去對應(yīng)窗口適合流水線式作業(yè)但銀行政務(wù)類場景用戶體驗(yàn)差客戶不知道被分到哪個窗口實(shí)際項(xiàng)目里很少用。提示如果某天線上出現(xiàn)了重號第一件事是查數(shù)據(jù)庫日志里這兩個 Update 的執(zhí)行順序和事務(wù)隔離級別而不是先改窗口端代碼。絕大多數(shù)重號問題根源在數(shù)據(jù)庫層界面端代碼改一百遍也沒用。5. 排隊(duì)機(jī)避坑指南五個真實(shí)翻車現(xiàn)場與修復(fù)方法這套源碼整體邏輯是完整的但實(shí)際部署中坑點(diǎn)不少。下面五條都是我見過或經(jīng)歷過的典型問題按「現(xiàn)象 → 原因 → 解決」整理出來照著排查能省半天時(shí)間。5.1 兩個窗口同時(shí)叫出同一個號現(xiàn)象早高峰兩個窗口幾乎同時(shí)點(diǎn)叫號LED 屏和語音同時(shí)播同一個號碼客戶不知道去哪個窗口窗口人員互相推諉。原因這不是數(shù)據(jù)庫并發(fā)問題而是流程設(shè)計(jì)問題。舊版本窗口端做了「預(yù)取號」程序先把待叫號查出來顯示在界面上等窗口人員確認(rèn)后再更新狀態(tài)。預(yù)取號和確認(rèn)之間的空窗期另一個窗口也能查到同一個號。窗口人員手速越快重號概率越高。解決嚴(yán)格走usp_CallNext存儲過程把查號和鎖號合并為一次數(shù)據(jù)庫操作。如果業(yè)務(wù)上必須保留確認(rèn)彈窗就把彈窗放在「調(diào)存儲過程之后」而不是之前先落庫拿到號碼彈窗只是展示結(jié)果不是確認(rèn)項(xiàng)。這一條改動就能根治重號。5.2 客戶還沒走到窗口號碼就變成過號了現(xiàn)象老年客戶從取號機(jī)拿完號走到窗口路上用了兩分鐘到窗口時(shí)系統(tǒng)已經(jīng)顯示「已過號」窗口人員重新叫號時(shí)客戶一臉委屈現(xiàn)場吵起來。原因過號等待時(shí)間寫死在代碼里默認(rèn)值只有 30 秒。代碼里用的是Thread.Sleep(30000)這類硬編碼部署時(shí)沒人去改。大廳越大、窗口越遠(yuǎn)、客戶群體年齡越大這個值就越不合理。解決把過號等待間隔做成配置表參數(shù)過號判定邏輯統(tǒng)一讀配置。配置表就兩列一列鍵一列值INSERT INTO dbo.t_Config ([Key], [Value]) VALUES (WaitTimeoutSec, 180);窗口端判定邏輯改成SELECT Value FROM dbo.t_Config WHERE [Key] WaitTimeoutSec取不到值時(shí)默認(rèn) 120 秒。另外窗口端要保留「撤銷過號」按鈕客戶到了就點(diǎn)一下把狀態(tài)從 3 拉回 2同時(shí)記錄一條操作日志避免被投訴時(shí)說不清楚。5.3 LED 屏幕顯示亂碼現(xiàn)象號碼數(shù)字正常漢字和字母變成「口」或菱形某些批次屏幕正常、某些批次亂碼。原因LED 控制器和程序約定的編碼不一致。常見組合是控制卡默認(rèn) GB2312程序按 UTF-8 拼報(bào)文或者反過來。同類源碼復(fù)制到不同網(wǎng)點(diǎn)顯示屏廠家不一樣編碼約定就不一樣看起來像系統(tǒng)「時(shí)好時(shí)壞」其實(shí)是換屏的時(shí)候沒同步改編碼。解決把編碼參數(shù)做成每個網(wǎng)點(diǎn)的配置項(xiàng)不要在代碼里寫死。調(diào)試時(shí)直接用串口工具抓報(bào)文看 Hex 字節(jié)流對照 GB2312 或 UTF-8 的碼表一看就知道哪一端錯了。這個坑最好在部署階段就統(tǒng)一確認(rèn)等上線后再改要同時(shí)改程序和屏參來回折騰。5.4 日報(bào)表統(tǒng)計(jì)數(shù)量比實(shí)際少了 20%現(xiàn)象晚上打印日報(bào)表系統(tǒng)統(tǒng)計(jì)當(dāng)天辦理 80 筆營業(yè)廳手寫臺賬記了 90 筆差了 10 筆。查流水表發(fā)現(xiàn)有一部分記錄狀態(tài)停在了「已叫」。原因窗口人員點(diǎn)「結(jié)單」按鈕時(shí)界面上的客戶記錄消失了但數(shù)據(jù)庫狀態(tài)沒有更新。舊代碼里「開始辦理」只改了前端界面狀態(tài)對應(yīng)數(shù)據(jù)庫根本沒有任何更新操作真正把狀態(tài)改成完成的那段代碼只存在于另一個沒人調(diào)用的模塊里。報(bào)表按 StatusId5 統(tǒng)計(jì)自然偏少。解決強(qiáng)制約定結(jié)單必須走統(tǒng)一的更新語句把StatusId從 2 改成 5 并寫入FinishTime。排查時(shí)用一個分組查詢看狀態(tài)分布哪里異常一眼可見SELECT StatusId, COUNT(*) AS Cnt FROM dbo.t_TicketFlow WHERE CONVERT(DATE, CreateTime) CONVERT(DATE, GETDATE()) GROUP BY StatusId;正常一天跑下來狀態(tài) 5完成應(yīng)該占絕大多數(shù)狀態(tài) 1 和狀態(tài) 2 是營業(yè)結(jié)束時(shí)還殘留在隊(duì)列里的少量號碼狀態(tài) 3 是過號。如果狀態(tài) 2 占比異常高說明「結(jié)單不落庫」的問題還在。5.5 取號機(jī)間歇性卡死重啟后恢復(fù)現(xiàn)象客戶按取號后紙質(zhì)票打印不出來或者觸摸屏轉(zhuǎn)圈十幾秒重啟軟件恢復(fù)過半天又犯。原因打印控件同步調(diào)用打印機(jī)打印機(jī)走網(wǎng)絡(luò)共享時(shí)響應(yīng)慢超時(shí)期間取號事務(wù)一致沒提交數(shù)據(jù)庫連接被占滿后面所有取號請求都在等連接表現(xiàn)為整個取號端卡死。這是典型的「外部設(shè)備拖垮主流程」。解決取號寫庫和打印徹底解耦。按鈕點(diǎn)擊后先執(zhí)行取號存儲過程拿到號碼立刻提示「取號成功」打印丟到后臺線程隊(duì)列慢慢處理失敗只記日志不彈窗。同時(shí)給所有SqlConnection設(shè)置短連接超時(shí)比如Connect Timeout 3避免單臺設(shè)備異常拖垮整個系統(tǒng)。6. 部署后怎么驗(yàn)證造數(shù)、并發(fā)測試與參數(shù)配置化拿到這套源碼不要急著改業(yè)務(wù)流程先做三輪驗(yàn)證。第一輪是造數(shù)據(jù)驗(yàn)證統(tǒng)計(jì)邏輯。寫一段腳本往流水表灌一天的量比如 3000 條記錄時(shí)間從早上 9 點(diǎn)均勻分布到下午 5 點(diǎn)狀態(tài)隨機(jī)落在 1、2、3、5然后跑前面那兩句統(tǒng)計(jì) SQL確認(rèn)報(bào)表口徑和你預(yù)期一致。這個步驟能提前發(fā)現(xiàn)狀態(tài)位含義和報(bào)表邏輯的錯位。第二輪是并發(fā)驗(yàn)證。打開五個數(shù)據(jù)庫查詢窗口模擬五個窗口同時(shí)執(zhí)行usp_CallNext連續(xù)跑幾十次觀察返回的號碼有沒有重復(fù)有沒有返回空值。正常情況每次返回的號碼都應(yīng)該嚴(yán)格遞增且不重復(fù)。如果出現(xiàn)重復(fù)回到第 4 章的鎖機(jī)制排查如果出現(xiàn)大量空值說明鎖粒度太粗事務(wù)互相阻塞嚴(yán)重要檢查是不是漏了READPAST。第三輪是把行為參數(shù)全部配置化。WaitTimeoutSec過號等待秒數(shù)、MaxCallCount號碼最大重呼次數(shù)、DailyResetTime每日序號歸零時(shí)間這些值全部挪到t_Config表里改參數(shù)不用重新編譯程序。我之前接手一個項(xiàng)目對方說系統(tǒng)「時(shí)好時(shí)壞很玄學(xué)」排查到最后發(fā)現(xiàn)是某臺窗口電腦的系統(tǒng)時(shí)間快了八分鐘叫號記錄和過號判斷全部錯位。從那以后我拿到任何排隊(duì)機(jī)源碼第一件事就是檢查所有終端的時(shí)間同步再做并發(fā)壓測最后才動業(yè)務(wù)邏輯。希望你拿到的這套代碼能少踩幾個類似的坑祝順利。本文還有配套的精品資源點(diǎn)擊獲取