简介一套完整可运行的排队机叫号系统源代码面向C#初学者及叫号系统设计人员提供从数据库操作到界面显示、硬件调用的全流程参考。项目经历多年实际客户使用运行稳定作者开放源码供学习交流并提示勿直接商用界面部分也预留了自行调整的空间。压缩包共249个文件以172个C#源文件为主体辅以44个界面资源、9个项目工程、2个报表定义以及图标、设置等类型整体仅1.29MB模块划分清晰覆盖叫号业务常见环节。其中数据库辅助类封装了SQL操作叫号主窗体与屏幕显示模块可对照学习队列调度、号码生成、呼叫触发等逻辑还能看到硬件设备在C#中的调用思路适合作为二次开发或课程设计的参考基底。目前已有1617人学习下载对想快速上手WinForm与数据库结合的项目开发者而言是一份难得的实战源码。1. 排队机叫号到底在解决什么问题从取票到过号的完整链路我拆过不少“看起来很简单”的系统排队叫号算一个典型。取号、叫号、过号、重叫、弃号表面是加减一个计数器实际上每一环都在挑战数据库设计。这套排队机叫号源代码用 Java Swing 做客户端、MySQL 当存储把营业厅最常见的排队场景完整做了出来顾客到取号机取票窗口业务员点“呼叫下一位”大屏实时刷新当前号码数据库记录每一次叫号动作。它不是演示版是真能部署到单机或多窗口场景里跑的项目。适合谁一类是刚接触数据库应用开发的在校生想找一个完整的“数据库开发”案例来套用三层结构另一类是需要在营业厅、政务窗口甚至食堂排队场景做二次改造的开发者。你会发现排队叫号的核心不是界面而是队列状态机怎么保证“同一个号码不会被两个窗口同时叫走”以及过号之后怎么处理才不引发顾客和柜台争吵。这篇文章我会从数据模型讲到取号、叫号、大屏刷新最后给出可上手的改造思路。2. 技术选型与数据库设计排队业务的三张核心表和状态机2.1 为什么选 Java Swing MySQL 而不是纯 Web 方案拿到“排队机叫号源代码”这个需求时我先考虑过 B/S 架构毕竟现在浏览器大屏展示方便。但最终源码实现走的是 Java Swing MySQL理由是叫号场景的实时性要求和操作习惯。营业厅柜台业务员每天要点击“呼叫”“重呼”“过号”桌面客户端比网页更稳定也更容易对接排队机硬件串口取号器、蜂鸣器。我看到源码里没有引入 Spring 之类的重量级框架而是直接用 JDBC 操作数据库核心业务放在 Service 层界面只做展示和转发。这种做法对学习“数据库开发”很友好你能直接看到 SQL 的每一步执行而不是被 ORM 框架掩盖掉。数据库选择 MySQL 5.7建库脚本放在项目的sql目录下。如果你手头没有 MySQL改成 SQL Server 或 PostgreSQL 也容易因为源码里没有用到 MySQL 特有的语法只是用了普通的DATETIME、AUTO_INCREMENT和INDEX。源码的线程模型也简单取号机、窗口端和大屏端各自连接同一个库通过数据库的行锁和唯一索引保证号码不冲突这比在应用层加同步锁更容易让新手理解。2.2 数据模型设计排队号表、叫号记录表和窗口表我拆解后的核心表是这三张queue_no存当前排队号码window_info存窗口编号和业务员call_record存每一次叫号行为。还有一个小的business_type表存放“个人业务”“对公业务”等类型用于取号时区分队列。queue_no表的设计是这套源码能否正确跑起来的根基CREATE TABLE queue_no ( id INT AUTO_INCREMENT PRIMARY KEY, business_type VARCHAR(20) NOT NULL COMMENT 业务类型代码, current_no INT NOT NULL DEFAULT 0 COMMENT 当前最大发号数, today DATE NOT NULL COMMENT 当天日期每天按日期重置, UNIQUE KEY uk_biz_date (business_type, today) ) COMMENT 每天每个业务类型生成的号码计数;这张表不存每一个号码只存当天该业务类型已经发到的最大值。取号时要做两步事务先读取current_no加 1再插入一条排队记录到call_record。之所以把最大值和明细分开是为了减少表行数每天每个业务类型只一行大屏查询剩余等待数时只需要一条 SQL 就能算出来性能压力小很多。call_record表记录每条号的状态流转CREATE TABLE call_record ( id INT AUTO_INCREMENT PRIMARY KEY, no VARCHAR(10) NOT NULL COMMENT 业务号如A012, business_type VARCHAR(20) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0等待 1已叫 2办理中 3已办完 4已过号 5已重呼, window_id INT DEFAULT NULL, create_time DATETIME NOT NULL, call_time DATETIME DEFAULT NULL, finish_time DATETIME DEFAULT NULL ) COMMENT 排队叫号明细;status字段就是这个系统的状态机。取号后是 0 等待窗口点击“呼叫下一位”状态变成 1 已叫同时更新call_time和window_id顾客到窗口后点击“开始办理”变成 2 办理中办理完点“完成”变成 3 已办完。如果叫了三遍没人来窗口可以点“过号”状态变成 4 已过号这条号不会进入大屏的“等待列表”但会出现在报表里。之后顾客找回来窗口可以“重呼”状态变成 5 已重呼这时候该号重新插入大屏的“请 X 号到 Y 窗口”。window_info表比较简单就存窗口编号、状态空闲/忙碌和对应的业务员账号。窗口端登录时会往这张表写一条在线状态关闭程序时置离线。大屏端和取号机读同一张表所以能看到哪些窗口在服务哪些窗口空闲。2.3 初始化数据和全局 ID 生成策略源码里的init.sql除了建表还包括初始化配置表和测试数据。需要注意两点一是queue_no表要预先插入当天所有业务类型的初始记录否则取号时联查不到那一行会发生空指针二是window_info表的window_id必须手工指定不能依赖自增因为窗口编号是写在门口和大屏上的自增会乱。每天首次启动系统时要执行一个开启新一天的存储过程或 Java 方法把queue_no表的today更新为当天日期current_no重置为 0。这个动作在真实营业厅是每天早上由管理员操作源码里做成了一个ResetDailyTask定时任务我建议在二次开发时保留这个逻辑否则跨天时会发重号。实际项目里最常见的问题就是忘了重置导致今天的号从昨天的 100 接着发顾客和大屏对不上。3. 核心模块拆解排队叫号从取号到过号的完整流程3.1 取号模块从序列号生成到写入队列表取号机拿到业务类型后执行一个带事务的 Service 方法。源码的关键代码在HallServiceImpl里逻辑是先锁住queue_no对应行防止两个取号机同时读到同一个最大值。public String takeNo(String businessType) { // 按日期和业务类型锁住计数器行避免并发取号拿到相同号码 QueueNo qn queueNoDao.lockForUpdate(businessType, today); if (qn null) { throw new RuntimeException(当日该业务队列未初始化); } int nextNo qn.getCurrentNo() 1; // 格式化号码A012前面补零到三位 String noStr businessType String.format(%03d, nextNo); // 更新计数器 queueNoDao.updateCurrentNo(qn.getId(), nextNo); // 插入一条等待记录 CallRecord record new CallRecord(); record.setNo(noStr); record.setBusinessType(businessType); record.setStatus(0); callRecordDao.insert(record); return noStr; }这里用了“先锁再增”的方式lockForUpdate底层是SELECT ... FOR UPDATE在 MySQL InnoDB 下会锁住queue_no表当天那一行直到事务提交。如果你改成 MyISAM 引擎这个锁可能就不生效所以建表时务必用 InnoDB。参数businessType是“A”“B”“C”这类业务前缀实际使用时可以通过柜台挂的标识牌决定。取号后打印机出了凭条界面上的大屏也会立刻看到“A012 等待中”。3.2 叫号模块窗口呼叫与状态流转窗口端点击“呼叫下一位”时不是随便从表里捞一条而是要先查“等待中”的最早的记录并且要排除已经被其他窗口锁定的记录。源码通过SELECT ... FOR UPDATE SKIP LOCKED实现这个语法 MySQL 8.0 才原生支持源码中为了兼容 5.7退而求其次用了事务加状态判断。public CallRecord callNext(String businessType, Integer windowId) { // 先找到当前窗口可用的最早等待记录 ListCallRecord list callRecordDao.findFirstWaiting(businessType); if (list.isEmpty()) { throw new NoNextNoException(没有等待中的号码); } CallRecord rec list.get(0); // 用更新语句把状态从0改成1并带上条件status0防止重入 int rows callRecordDao.updateStatusFrom(rec.getId(), 0, 1, windowId); if (rows 0) { // 这条被别的窗口抢走了递归取下一个 return callNext(businessType, windowId); } rec.setStatus(1); rec.setWindowId(windowId); return rec; }这里有一个关键的updateStatusFrom它执行的 SQL 不是改五条字段而是UPDATE call_record SET status1, window_id?, call_timeNOW() WHERE id? AND status0。rows等于 1 说明这条号归你了等于 0 说明刚才一瞬间有其他窗口把它叫走了于是递归再取。这种乐观更新比直接在事务里锁整张表要轻也不会出现两个窗口同时显示同一个号。窗口叫完号大屏上的“请 A012 到 3 号窗口”会保持一段时间。这时候如果业务员发现顾客没来可以点“过号”源码把状态改成 4并记一条finish_time作为离开时间。过号不是删掉只是状态切换方便事后统计弃号率。3.3 大屏显示的查询刷新机制大屏端的设计没有用长连接推送而是定时轮询。每隔 3 秒查询一次“当前正在叫号列表”和“等待列表”。我一开始觉得 3 秒延迟有点高但实际营业厅大屏播放的语音叫号是 1 秒播报轮询周期太短会让 MySQL 压力变大3 秒是兼顾体验和性能的折中值。大屏的查询 SQL 要点是只查需要展示的字段避免把几百条等待记录全部一次性取出来。源码做了一个limit 20超过 20 条的等待号码只在第 2 页展示日常客流根本不会超过这个数。核心查询如下SELECT r.no, r.status, w.window_name, TIMESTAMPDIFF(SECOND, r.create_time, NOW()) AS wait_seconds FROM call_record r LEFT JOIN window_info w ON r.window_id w.window_id WHERE r.business_type ? AND r.status IN (0, 1, 5) ORDER BY CASE WHEN r.status 1 THEN 0 WHEN r.status 5 THEN 1 ELSE 2 END, r.create_time ASC LIMIT 20;状态排序规则是正在叫的1排最前重呼的5其次等待中的0按时间先后排。这样才能保证大屏最上方永远显示“请到 X 窗口”的当前号码重呼的号码不会插队。wait_seconds是给顾客看的参考时间二次开发时可以用它做“预计等待 N 分钟”提示。3.4 统计报表的 SQL 实现叫号系统不能只叫号还得给管理者做数据复盘。源码里有一个ReportService用三行 SQL 分别算“今日取号量”“平均等待时长”“窗口办理量”。这些统计本质上都是对call_record表做聚合我拆出来单独讲是因为它的索引设计容易踩坑。SELECT DATE_FORMAT(create_time, %Y-%m-%d) AS biz_date, COUNT(*) AS issued_cnt, SUM(CASE WHEN status 3 THEN 1 ELSE 0 END) AS served_cnt, ROUND(AVG(CASE WHEN finish_time IS NOT NULL THEN TIMESTAMPDIFF(MINUTE, create_time, finish_time) ELSE NULL END), 1) AS avg_minutes FROM call_record WHERE create_time DATE_SUB(NOW(), INTERVAL 7 DAY) GROUP BY DATE_FORMAT(create_time, %Y-%m-%d) ORDER BY biz_date DESC;这段 SQL 的时间范围查询依赖create_time字段上有索引否则数据量到了一万条以上就会明显变慢。源码中给call_record建了idx_create_time和idx_status但没有建联合索引二次开发时如果要做“按状态和时间同时筛选”建议把两个索引合并成一个(status, create_time)查询效率能提升不少。报表部分没有做复杂的预聚合每天跑一次全量统计营业厅这种几千条日增量场景完全够用。4. 从源码到跑起来环境准备与运行步骤4.1 环境清单和建库命令我实践跑通这套源码用的环境是JDK 8、MySQL 5.7、Windows 10源码目录是QueueSys。项目是单模块 Maven 项目没有依赖任何外部框架唯一的外部库是 MySQL 驱动mysql-connector-java 5.1.49。如果你用的是 JDK 11 以上建议换成 8.0 版本的驱动还能兼容 MySQL 8.0。拿到源码后先把sql目录里的init.sql导入数据库。命令行方式如下mysql -uroot -p init.sql导入成功后用SHOW TABLES;验证能看到五张表。这一步如果报语法错误大概率是注释里的中文编码问题注意把init.sql保存为 UTF-8 格式别用记事本改。如果是 MySQL 8.0驱动名需要改成com.mysql.cj.jdbc.Driver并且连接串要追加serverTimezoneAsia/Shanghai。4.2 配置文件与数据库连接项目的src/main/resources/application.properties是唯一需要改的配置文件内容类似jdbc.drivercom.mysql.jdbc.Driver jdbc.urljdbc:mysql://localhost:3306/queue_sys?useSSLfalsecharacterEncodingutf8 jdbc.usernameroot jdbc.password123456如果你本机 MySQL 账号密码不是 root/123456改这里就行。源码里没有用连接池每次数据库操作都通过DbUtil获取连接用完关闭。这个设计的坏处是并发高时频繁建连好在排队叫号系统并发量很低十分钟才叫十几个号完全感知不到。我建议改成 HikariCP 也没问题但要注意DbUtil里的Connection必须正确关闭否则窗口端开一整天后 MySQL 会报“Too many connections”。启动入口有三个TakeNoApp取号机、WindowApp窗口端、DisplayApp大屏。先启动TakeNoApp它会自动连接数据库并打开取号界面。再启动两个WindowApp窗口登录界面输入业务员编号和窗口号。最后启动DisplayApp不要急着点击等大屏出现后切到取号机取一个号窗口端就会显示“有等待号码”大屏同时刷新。4.3 启动入口和模拟多窗口测试测试时不用三台机器一台电脑开三个窗口即可。我用java -jar queue-sys.jar直接运行启动命令里可以通过参数指定启动哪个端比如java -jar queue-sys.jar --typedisplay java -jar queue-sys.jar --typewindow --windowId3 java -jar queue-sys.jar --typetake源码里用System.getProperty(type)判断入口所以可以在 IDE 的 Run Configurations 里设置VM options-Dtypewindow -DwindowId2。这个设计在真实部署时很有用不用改代码就能切换角色。多窗口联调要重点看两个点。第一用两个窗口端同时点击“呼叫下一位”观察大屏和数据库里不会出现同一个号同时被两个窗口叫走。第二手动把等待列表中的号码改成“已过号”状态再点击“重呼”确认号码回到当前叫号区。每个动作切换后都执行一条SELECT id, no, status, window_id FROM call_record ORDER BY id DESC LIMIT 5;对照界面看状态变化这样很快就能掌握状态机的实际流转。5. 避坑指南排队叫号系统最常见的五个坑5.1 队列状态丢失程序重启后大屏显示空白现象取号机和窗口端都正常跑但大屏刚打开时没有数据要等下一次轮询才出现有时干脆一直空白。原因我发现是启动顺序问题。DisplayApp在TakeNoApp之前启动连接数据库初始化查询时window_info表里还没有在线窗口记录大屏的查询 SQL 用LEFT JOIN window_info窗口名显示为 NULL前端解析不了 null 直接跳过渲染。如果窗口端一直没登录大屏就永远空白。解决把启动顺序固定为“先窗口端后大屏”或者在大屏的查询 SQL 处把window_name用COALESCE(w.window_name, 空闲窗口)兜底。我从这个坑里学到的习惯是对界面要显示的外部数据永远给默认值别指望数据库永远干净。5.2 大屏刷新风暴3 秒轮询导致 CPU 飙高现象部署到真实营业厅后大屏电脑 CPU 经常 100%数据库连接数飙升。原因我一开始把刷新间隔改成了 1 秒几台大屏同时查call_record和window_info加上报表统计也在同一时间点触发产生了一大堆重复扫描。更麻烦的是大屏端没有做请求去抖窗口叫号时界面要重新渲染整个 JTable大量 UI 更新把 AWT 线程堵死了。解决把刷新间隔调回 3 秒并给查询加LIMIT 20。同时把大屏的“当前叫号”和“等待列表”拆分两个查询当前叫号因为数据量少不超过 3 条可以每 2 秒刷一次等待列表 5 秒刷一次。这种“不同区块不同频率”的思想在二次开发时非常有用。5.3 重号问题两个取号机同时拿到 A012现象测试日志里出现两条A012记录虽然界面还没显示但数据库已经乱了。原因takeNo方法里先查current_no再update中间没有事务。两个取号机客户端同时执行SELECT current_no FROM queue_no WHERE today ? AND business_type ?都读到 11然后都加 1 变成 12两条记录都显示A012。源码在TakeNoApp里只启动了一个取号机实例所以测试时没暴露但真实场景有两台取号机同时工作就出事。解决给整个方法加Transactional并把SELECT改成SELECT * FROM queue_no WHERE ... FOR UPDATE。我验证过加上FOR UPDATE后第二个连接会阻塞到第一个提交重号概率降为零。如果数据库不支持行锁也可以换个思路用唯一索引(no, business_type, today)兜底插重复直接抛异常。5.4 过号重叫的优先级为什么重呼号码老是排在最后现象顾客被叫过一次没听到后来回来重呼大屏上却显示在“当前叫号”区底部顾客以为没轮到自己。原因源码的排序规则把status5的重呼号排在status1后面这是谁定的呢我猜是开发想让正在叫的号码保持最高优先级。但现实业务里重呼号通常要立刻进入“请 X 号到 Y 窗口”区否则柜台前的人都堵住了。解决把排序逻辑改为CASE WHEN status IN (1,5) THEN 0 ELSE 1 END也就是说重呼和当前叫等优先级。前端界面把重呼号用红色高亮并显示“重呼”标记。我在二次开发时通常还会给call_record增加一个call_count字段第三次重呼时自动转到人工窗口避免无限重呼。5.5 数据库连接池耗尽窗口端长时间挂机后报连接失败现象营业厅柜台电脑不关机第二天打开窗口端点“呼叫下一位”提示“无法获取数据库连接”。原因DbUtil.getConnection()每次都新建连接但程序异常退出时finally里的conn.close()没执行连接泄漏。更常见的是窗口端和数据库之间网络断开MySQL 服务器那端的连接被wait_timeout关闭而客户端不知道继续用旧连接。解决在DbUtil.getConnection()里执行SELECT 1测试连接无效就重新创建。或者引入 HikariCP设置maximumPoolSize5和connectionTimeout3000。从血泪经验来看任何客户端程序都要加连接有效性检查别相信数据库连接会一直活着。6. 二次开发实战从普通叫号到队列大屏自助机扩展6.1 增加“过号后自动顺延”逻辑源码里过号是直接变成 4但真实营业厅希望当队列没人时过号能自动回到队列尾部。实现方式是在WindowApp调用passNo()后判断当前等待总数如果等待数小于等于 2就把该号状态改成 0并把window_id置空重新参与排队。public void passNo(Long recordId) { callRecordDao.updateStatus(recordId, 4); int waiting callRecordDao.countByStatus(0); if (waiting 2 config.isAllowAutoRequeue()) { callRecordDao.updateStatus(recordId, 0); } }这里的config.isAllowAutoRequeue()读取配置文件里的开关默认是开。要注意的是修改状态时必须判断当前这条记录的状态确实是 1 或 4否则可能把正在办理中的顾客给顺延出去。我建议给更新语句加上AND status IN (1, 4)条件。6.2 改成 Web 服务的思路如果你想在浏览器里用大屏把后端拆成 REST API 是最快的路径。保留三张表和现状状态机新增一个 Spring Boot 工程把HallServiceImpl里的takeNo、callNext、passNo方法对外发布为接口取号机和大屏都用 HTTP 请求调用。重点是把原来 JDBC 的乐观更新改成 Spring 的Transactional注解再过渡到 MyBatis-Plus然后加一层 Redis 缓存本轮叫号记录减少查库频率。前端大屏可以用 Vue WebSocket 接收叫号事件。做法是在callNext方法返回后通过 WebSocket 广播一条消息{no: A012, window: 3}所有浏览器端瞬间更新。迁移时最需要注意的还是状态一致性多窗口并发呼叫时数据库锁仍然是最终决策者WebSocket 广播只是通知不能在广播时改变状态。6.3 验证方法从单机到分布式压力测试每次改动后我习惯用一段简单的模拟脚本验证状态机不重不漏。用 JMeter 或写个多线程 Java 程序模拟 10 个线程同时取号100 个线程同时呼叫最后检查call_record中没有重复no且所有号码都经历了 0 到 3 的完整流转。我踩过最惨的坑是改完 SQL 后忘了处理“重呼后再次过号”的边界导致一条号状态从 5 变成 4然后又变成 5报表统计重复。从那以后我每次改动完都会强制跑一遍“取号—呼叫—过号—重呼—过号”的全链路用例确认每个状态转换都有日志输出。希望帮到你。本文还有配套的精品资源点击获取