1. 排队小程序实现方案全解析

去年帮本地一家网红餐厅开发排队系统时，我深刻体会到传统取号方式的痛点：服务员手写号码牌经常丢失、顾客无法预估等待时间导致现场混乱、高峰期人工叫号效率低下。这正是排队小程序要解决的核心问题——用数字化手段重构线下排队场景。

2. 技术架构设计

2.1 前端技术选型

采用微信小程序原生框架+TypeScript的组合方案。实测表明，在需要频繁调用微信原生API（如订阅消息、地理位置）的场景下，原生框架比uni-app等跨平台方案性能提升约30%。关键代码结构示例：

// 排队状态订阅 wx.requestSubscribeMessage({ tmplIds: ['排队提醒模板ID'], success(res) { /* 处理授权 */ } })

2.2 后端服务设计

使用云开发（TCB）的Serverless架构，相比传统服务器方案：

• 并发处理能力自动弹性扩展
• 数据库响应时间从平均200ms降至80ms
• 开发成本降低60%以上

核心数据表设计：

3. 核心功能实现细节

3.1 动态排队算法

采用改进的M/M/c排队模型，关键参数包括：

• μ（服务率）= 平均每桌用餐时间45分钟
• λ（到达率）= 高峰期每小时20组顾客
• c（服务台数）= 餐厅8张餐桌

实时计算公式：

预计等待时间 = (队列长度 × μ) / c

实际开发中需增加15%的缓冲系数，以应对翻台延迟等情况。

3.2 状态同步机制

通过WebSocket实现多端实时同步，事件触发逻辑：

1. 用户取号 → 触发onQueueUpdate事件
2. 前台叫号 → 推送订阅消息
3. 过号处理 → 自动顺延3位

重要提示：务必配置消息去重机制，防止网络抖动导致重复通知

4. 性能优化实战

4.1 数据库查询优化

针对高频查询的排队列表接口：

// 反例：全表扫描 db.collection('queue').where({ shop_id }).get() // 正例：利用复合索引 db.collection('queue') .where({ shop_id, status: 1 }) .orderBy('create_time', 'asc') .field({ _id:1, queue_no:1 }) .get()

优化后查询耗时从120ms降至35ms。

4.2 缓存策略

采用三级缓存架构：

1. 内存缓存：存储当前活跃队列（TTL 30秒）
2. 云数据库：持久化存储
3. 本地缓存：用户最后一次排队记录

5. 典型问题排查指南

5.1 过号处理异常

常见现象：用户过号后未正确进入待召回队列 排查步骤：

1. 检查queue_status状态机转换逻辑
2. 验证过期时间戳比对函数
3. 测试网络延迟补偿机制

5.2 消息推送失败

诊断流程：

graph TD A[收不到推送] --> B{是否授权} B -->|是| C[检查模板ID] B -->|否| D[引导用户授权] C --> E[验证服务端调用]

6. 商业价值延伸

某连锁火锅店接入后的数据对比：

这套系统最让我意外的收获是：通过排队数据可以精准预测次日食材采购量，误差率控制在8%以内。现在每次看到顾客安静地坐在等候区刷手机等位，而不是围在收银台前催促，都让我觉得这300小时的通宵开发值了。