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