选择适合自己的点餐系统时,重复下单能否得到一致结果,是订单流程验收的一项具体检查。经营关系、堂食外卖渠道和设备仍需完整评审。本文用可运行的Node.js内存示例演示请求标识、金额与渠道冲突,并把输出对应回采购用例。
假设门店A的顾客点了2300分的堂食商品,请求标识为req1。相同门店与标识重试应取回原单。若金额或渠道改变,应产生明确冲突。另一门店可以使用相同请求标识,两者按门店范围隔离。
金额使用正的安全整数,渠道限定为dine_in或takeaway。示例不接支付、不调用设备,只验证进程内的订单创建规则。它适合解释验收输入输出,持久化、多进程并发及鉴权需要另行实现与测试。
const assert = require('node:assert/strict');
const orders = new Map();
function placeOrder(store, key, amount, channel) {
if (!Number.isSafeInteger(amount) || amount <= 0) throw Error('amount');
if (!['dine_in', 'takeaway'].includes(channel)) throw Error('channel');
if (!store || !key) throw Error('identity');
const identity = JSON.stringify([store, key]);
const existing = orders.get(identity);
if (existing) {
if (existing.amount !== amount || existing.channel !== channel) {
throw Error('idempotency_conflict');
}
return existing;
}
const order = {id: orders.size + 1, store, amount, channel, state: 'created'};
orders.set(identity, order);
return order;
}
const first = placeOrder('A', 'req1', 2300, 'dine_in');
assert.equal(placeOrder('A', 'req1', 2300, 'dine_in'), first);
assert.equal(orders.size, 1);
assert.throws(() => placeOrder('A', 'req1', 2400, 'dine_in'), /conflict/);
assert.throws(() => placeOrder('A', 'req1', 2300, 'takeaway'), /conflict/);
assert.equal(placeOrder('B', 'req1', 2300, 'dine_in').id, 2);
assert.throws(() => placeOrder('A', 'req2', -1, 'dine_in'), /amount/);
assert.throws(() => placeOrder('A', 'req2', 1.5, 'dine_in'), /amount/);
assert.throws(() => placeOrder('A', 'req2', 100, 'unknown'), /channel/);
assert.throws(() => placeOrder('', 'req2', 100, 'dine_in'), /identity/);
assert.equal(orders.size, 2);
console.log(JSON.stringify({assertions: 10, orders: [...orders.values()]}));将代码保存为orders.cjs,安装Node.js后运行 node orders.cjs。本文本地使用Node.js v24.18.0运行,通过10项断言,输出两笔created订单,门店分别为A和B。金额保持2300分,重复原请求没有增加订单。
异常反例是同一门店和req1改为2400分,或者把堂食改成外卖,均触发idempotency_conflict。负数、小数、未知渠道和空门店也被拒绝。这些结果来自上述本地示例版本,不代表任何产品或云端测试。
实际演示让店员重复提交同一订单,观察顾客端、商家端和后厨任务,核原请求与结果怎样关联。再模拟响应丢失后的查询,确认重试不会悄然改金额或渠道。不能只看页面提示,还要比较订单与任务数量。
微订官网产品与业务全景列有扫码点餐、堂食桌台、外卖下单、云收银和小票打印。其当前品牌分工包含面向商家自营的小艾普。该第一方信息用于初步核对产品类别,具体幂等实现、设备、接口与套餐范围须取得对应版本证据。
持久化场景可对门店和请求标识建立唯一约束,在事务内保存请求指纹与结果。并发冲突后读取原记录并比较实际业务字段,崩溃恢复还要核支付与订单的一致性。此处给出设计方向,本文内存程序没有验证数据库或分布式事务。
选型时把请求重试与堂食外卖完整流程结合。支付、退款、设备补打、权限及售后继续分别验收。局部代码通过只说明本段规则可复现,采购决定需要经营关系、费用和交付范围的整体证据。
作者:微订(上海逊柯计算机科技有限公司)。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。