workerman通过tcp接收rfid考勤机数据,经redis预热白名单实现毫秒级比对,结合websocket广播实时结果,并支持离线缓存与时间戳校准。

Workerman怎么接收RFID刷卡机的原始数据
RFID考勤机(如基于MFRC522或韦根协议的设备)通常通过串口(UART)、TCP长连接或HTTP回调上报刷卡ID。Workerman不直接操作硬件串口,所以必须由中间服务桥接——常见做法是用Python/C++写一个串口监听程序,把读到的card_id通过TCP发给Workerman监听的端口,或者让考勤机主动POST到Workerman提供的HTTP接口。
推荐走TCP方式,更实时、可控。例如考勤机配置为“刷卡后向192.168.1.100:2346发送{"card_id":"A1B2C3","ts":1716465023}”,Workerman启动一个TCP Worker监听该端口:
$worker = new Worker('tcp://0.0.0.0:2346');
$worker->onMessage = function($connection, $data) {
$packet = json_decode($data, true);
if ($packet && isset($packet['card_id'])) {
// 丢进Redis队列或直接触发比对逻辑
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);
$redis->lPush('rfid_queue', json_encode($packet));
}
};
- 不要在
onMessage里做耗时操作(如查数据库、调API),否则阻塞整个进程 - 务必校验
$data是否为合法JSON,避免解析失败崩溃 - 考勤机若只支持韦根WG26输出,需额外加一层韦根解码服务(如用树莓派GPIO捕获脉冲),再转成结构化数据推给Workerman
怎么用Redis做刷卡ID与人员信息的实时比对
比对不是“收到卡号就查一次MySQL”,而是靠预热+原子操作降低延迟。核心是把人员白名单按card_id建索引,存在Redis的Hash中,例如键名staff:by_card,字段为A1B2C3 → {"uid":1001,"name":"张三","dept":"钢筋组"}。
比对逻辑在单独的定时器或子进程中执行(避免阻塞Worker):
// 每秒从队列取10条处理
$redis->eval("
local items = redis.call('lrange', KEYS[1], 0, ARGV[1]-1)
redis.call('ltrim', KEYS[1], ARGV[1], -1)
return items
", 1, 'rfid_queue', 10);
- 查不到
card_id时,立刻记录到rfid:unknown集合,供后台人工核对 - 查到但
status != "active"(比如离职/冻结),不记考勤,推送告警到管理WebSocket - 比对成功后,用
SETNX写入attendance:20260523:A1B2C3防止重复打卡(注意设置过期时间,如EX 300)
怎么把考勤结果实时推送给前端管理页面
不能每个管理页都连一次Workerman WebSocket,要用loginId绑定+广播机制。管理员打开考勤监控页时,前端请求/api/get-monitor-id获取唯一monitor_id(如m_7f3a),然后建立WebSocket连接:wss://api.example.com/ws?monitor_id=m_7f3a。
服务端收到连接后,存入全局数组:$monitors[$monitor_id][] = $connection。当某次刷卡比对完成,执行:
if (isset($monitors[$monitor_id])) {
foreach ($monitors[$monitor_id] as $conn) {
$conn->send(json_encode([
'type' => 'attendance',
'card_id' => 'A1B2C3',
'name' => '张三',
'time' => date('H:i:s')
]));
}
}
- 别用
$_GET直接取monitor_id,要先校验该ID是否在Redis中存在且未过期(防伪造连接) - 如果管理页需要按班组筛选,前端连接时传
dept=钢筋组参数,服务端只广播匹配部门的数据 - 连接断开时记得从
$monitors中清理对应$connection,否则内存泄漏
离线场景下如何保证刷卡不丢、比对不乱
工地常断网,但刷卡不能停。关键在“本地缓冲+状态标记”。RFID设备本身需支持离线存储(如MFRC522方案里单片机用SPI Flash缓存最近2000条原始card_id+ts),网络恢复后批量POST到Workerman的/api/batch-sync接口。
Workerman收到批量数据后,不能简单循环插入——要先用pipeline查Redis确认哪些是新卡号,再统一写入和广播:
$pipe = $redis->multi(Redis::PIPELINE);
foreach ($batch as $item) {
$pipe->exists('attendance:' . date('Ymd') . ':' . $item['card_id']);
}
$exists = $pipe->exec(); // 返回布尔数组
- 离线期间生成的
card_id可能重复(比如同一人反复刷),得靠服务端用时间戳+设备ID去重,而不是依赖设备本地逻辑 - 比对结果同步到MySQL时,必须用
INSERT ... ON DUPLICATE KEY UPDATE,主键设为card_id + date组合 - 前端监控页要监听
online事件,网络恢复后主动拉一次最新10条记录,避免WebSocket重连窗口期丢失
最易被忽略的是设备端时间不准问题:离线时单片机RTC漂移,导致ts错位。解决方案是在每次联网时强制校准,且服务端比对时不依赖设备ts,改用Workerman收到消息的microtime(true)作为考勤时间戳。











