在蛋糕店等线下零售场景中，排队是日常运营中不可避免的环节。传统的纸质叫号方式效率低、易出错，顾客体验差。随着数字化升级，一套稳定可靠的蛋糕排队系统成为门店刚需。本文基于Nuxt.js框架，分享一套高可用架构的源码设计思路，帮助开发者快速构建属于自己的排队系统。
一、为什么选择Nuxt.js构建排队系统
Nuxt.js是Vue生态中成熟的通用应用框架，具备服务端渲染（SSR）能力，非常适合需要实时交互和高性能的排队场景。选择Nuxt.js的原因有三点：
- 首屏加载快：SSR直接输出HTML，提升弱网环境下的页面响应速度。
- 前后端同构：一套代码同时支持客户端和服务端逻辑，降低维护成本。
- 强大的中间件机制：便于实现请求拦截、鉴权和日志记录，为高可用架构提供基础。
二、系统整体架构设计
高可用架构的核心是解决单点故障和流量突发问题。我们的蛋糕排队系统采用分层设计：
- 接入层：使用Nginx做负载均衡，配合反向代理转发请求到Nuxt.js服务集群。
- 应用层：Nuxt.js服务通过PM2或Docker多实例部署，利用Node.js集群模块充分利用多核CPU。
- 数据层：Redis负责会话存储和排队数据缓存，MySQL持久化用户和订单记录。
- 消息队列：引入RabbitMQ或Kafka处理高并发写操作，削峰填谷，避免数据库连接池被击穿。
2.1 Nuxt.js服务端渲染优化
排队页面需要实时显示当前号码、预计等待时间等动态数据。我们利用Nuxt.js的asyncData和fetch生命周期，在服务端获取数据并预填充页面状态，减少客户端请求次数。同时，对静态资源和组件进行按需加载，使用nuxt build --modern配合CDN加速，显著降低TTFB。
2.2 高可用并发处理
当大量用户同时取号或查看排队进度时，系统必须保证一致性。我们采用Redis分布式锁和Lua脚本原子性操作，确保取号号码的唯一性和递增顺序。具体实现中，通过SETNX命令加锁，执行完N个操作后释放锁，配合过期时间防止死锁。
// 简化示例：使用Redis原子自增获取排队号
const getQueueNumber = async (storeId) => {
const key = `queue:${storeId}:number`;
const value = await redis.incr(key);
return value;
};三、高可用关键策略
3.1 服务集群与健康检查
在Nuxt.js应用中，我们编写了内置的/healthcheck路由，返回应用运行状态。Nginx定期对该路由发起请求，若连续失败则自动摘除故障节点，实现服务自愈。此外，利用PM2的--max-memory-restart选项让每个实例在内存超标时自动重启，避免内存泄漏导致整个服务不可用。
3.2 缓存策略
对于公共页面（如商店首页、排队说明页），我们使用Redis缓存渲染后的HTML，设置较短TTL（如10秒），减少Nuxt.js重复渲染压力。对于用户排队状态，采用publish/subscribe模式，当号叫变化时主动推送更新，避免客户端轮询造成的不必要请求。
3.3 数据库读写分离与熔断
MySQL采用主从复制架构，写操作走主库，读操作走从库，并通过ProxySQL中间件实现读写分离。在Redis异常时，系统自动降级为文件缓存，并开启接口熔断器（如使用Opossum库），防止级联故障。
四、项目实战中的踩坑与优化
在真实部署中，我们遇到几个值得注意的问题：
- nuxtServerInit执行时机：需要确保初始化数据在所有页面渲染前完成，可通过服务中间件提前预取全局配置。
- 跨域问题：API服务与前端不同域名时，在Nuxt.config.js中配置proxy代理，避免浏览器CORS限制。
- WebSocket连接管理：若使用Socket.io实现实时排队进度，需在PM2中开启sticky模式，保证连接粘滞到同一实例。
五、部署与监控
我们推荐使用GitLab CI/CD流水线，将打包后的Nuxt.js应用构建为Docker镜像，通过Kubernetes编排自动扩缩容。监控方面，集成Prometheus + Grafana，采集Node.js的event loop延迟、内存占用、QPS等指标，并设置告警阈值。日志使用ELK统一收集，方便排查线上问题。
六、总结
基于Nuxt.js的高可用蛋糕排队系统源码，能够满足门店日常运营和高峰期并发需求。通过分层架构、Redis锁、消息队列、缓存优化和监控告警等手段，构建了一个健壮、可扩展的解决方案。开发者可以参考本文的思路，结合实际业务场景调整架构细节，打造属于自己的行业排队系统。