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