VR 体验馆是近年商场娱乐业态里增长较快的一类：几十平米到几百平米的场地，几台到几十台 VR 设备（蛋椅、大空间自由行走、赛车模拟器），按场次或按时长收费。这个业态的系统需求是"票务 + 设备控制 + 计时计费"三者的组合体，工程上比普通票务系统复杂。本文以一个单场馆多设备的典型配置为例，拆解核心模块的设计与实现。
一、业务模型：设备、场次、订单
核心实体四个：设备（device）、项目（scene，一个 VR 内容对应一个项目）、场次（session）、订单（order）。设备与项目是多对多关系——同一台蛋椅可以运行多个内容，同一内容可能部署在多台设备上。计费模型有两种：按场次（固定时长、固定价格、整场开散）和按时长（自由上机、分钟计费、卡扣结算）。多数场馆两种并存：蛋椅类按场次，大空间类按时长。
CREATE TABLE device (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
venue_id BIGINT NOT NULL,
device_no VARCHAR(20) NOT NULL COMMENT '设备编号',
device_type TINYINT NOT NULL COMMENT '1蛋椅 2大空间 3模拟器',
scene_ids VARCHAR(200) NOT NULL COMMENT '支持的内容ID,逗号分隔',
status TINYINT NOT NULL DEFAULT 1 COMMENT '1空闲 2使用中 3维护 4故障',
UNIQUE KEY uk_no (venue_id, device_no)
);
CREATE TABLE session (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
device_id BIGINT NOT NULL,
scene_id BIGINT NOT NULL,
start_time DATETIME NOT NULL,
end_time DATETIME NOT NULL,
capacity INT NOT NULL COMMENT '本场可上人数',
sold INT NOT NULL DEFAULT 0,
status TINYINT NOT NULL DEFAULT 0 COMMENT '0待开 1进行中 2已结束',
KEY idx_dev_time (device_id, start_time)
);
二、场次的并发扣减
场次名额扣减与电影票选座同构，但有个区别：VR 场次的容量小（蛋椅一场一人或两人，大空间一场四到六人），超卖的危害相对小、但"扣了名额没到场"的浪费危害大——一台蛋椅空转十分钟就是纯损失。所以扣减策略上，建议"预约占位 + 到场核销"两层：下单即扣名额， 15 分钟内未核销自动释放回库存。释放动作用延迟队列实现（Redis ZSet 存核销截止时间戳，定时任务扫描释放），不要依赖订单超时关闭的统一机制——VR 场次的释放时效要求到分钟级。
// 场次扣减的原子操作
public boolean bookSession(long sessionId, int qty) {
String key = "sess:" + sessionId;
Long left = redis.opsForValue().decrement(key, qty);
if (left == null || left < 0) {
redis.opsForValue().increment(key, qty);
return false;
}
return true;
}
场次名额以 Redis 计数器为权威值，MySQL 的 sold 字段异步对账同步。场馆开关门、设备故障导致的整场取消，要有批量回滚接口：一场取消，该场所有订单自动退款并推送通知，这个批量事务在实际运营里每周都会用到，务必做进管理后台。
三、设备联动：指令下发与状态回报
这是 VR 场馆系统区别于普通票务系统的核心模块。小程序核销后，系统要向设备下发"启动内容"的指令。设备侧通常是 Windows 主机 + 内容运行器，联动的两种方案：本地局域网方案（场馆内一台中控主机，与设备主机同网段，中控收到核销消息后通过 WebSocket 或 HTTP 向设备主机发启动指令）和云端直控方案（设备主机长连云端，指令走云下发）。单场馆推荐本地中控方案——商场网络抖动不影响核心链路，云端只做订单与核销。
状态回报比指令下发更重要：设备主机每三十秒上报一次心跳（运行中内容、当前玩家人数、温度），中控侧超过九十秒无心跳即标记异常并告警。设备故障要能在小程序端体现：故障设备的场次自动下架，已购客人自动退款。这套"心跳—告警—自动下架"的链路，是场馆运营人员最依赖的功能——十几台设备的场馆靠人盯是盯不过来的。
四、计时计费与断网兜底
按时长计费的设备，计费起点的权威判定在上机动作：核销后设备端点击"开始"，中控记录开始时间；下机由工作人员或超时自动判定。计费环节的关键是"开始时间的权威来源"，以中控记录为准、设备端时间仅参考——设备本地时间被改动是常见故障源。
断网兜底必须设计进去。商场网络断网时，核销与启动指令走本地中控（中控有本地订单缓存队列），断网期间的消费记录暂存本地，网络恢复后批量上传，上传按设备号与时间戳幂等去重。这个本地队列的设计要点：队列文件落盘、进程重启不丢、上传重试带指数退避。VR 场馆的客单价不低（几十到上百），丢一笔账等于白跑一场，本地队列是这个业态的底线工程。
五、运营侧的功能清单
管理后台必备：设备状态大盘（空闲/使用中/故障一目了然）、场次日历（按天视图直观查看排期与空档）、营收报表（按设备、按内容、按时段三维度）、内容热度分析（哪个 VR 内容复购高就多排）。小程序端必备：项目列表（配宣传片与适龄提示）、选场次下单、到场扫码核销、排队叫号（大空间项目人多时）、会员次卡。会员卡在这个业态值得做：VR 客群的"回头客"特征明显，玩过的内容会拉朋友再来，次卡与邀请返券的组合能把复购和裂变同时抓住。次卡的核销也要走场次模型：一张次卡对应一次预约扣减，不搞"刷一次算一次"的模糊口径，账目才经得起查。财务与运营两条线各取所需，系统才立得住。
六、小结
VR 体验馆系统的工程要点可以归结为一句话：票务是骨架，设备联动是肌肉，断网兜底是骨骼里的钙。青海青帝信息科技有限公司在本地娱乐场馆类项目中观察到，这类系统最常见的失败不是功能缺失，而是设备联动的稳定性没做实——心跳、告警、本地队列三件套做扎实，运营人员在系统里才有"掌控感"，系统才从辅助工具变成场馆的生产资料。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/jincheng100/article/details/170740639
