消息队列的投递语义是"至少一次":网络抖动时同一条奖励消息可能投递两次,消费端不设防就给玩家发两份奖励。幂等消费封装:每条消息带唯一键,消费端维护去重表,重复键直接跳过;处理成功才记录键,处理失败不记键让消息重投——重复不重复发、失败不吞单,两头都要保。
去重表与幂等消费:键查重、处理成功落键。示例代码如下:
local dedup = {}
local TTL = 7 * 86400
local function isDuplicate(msgId)
local e = dedup[msgId]
if e == nil then
return false
end
if os.time() - e.ts > TTL then
dedup[msgId] = nil
return false
end
return true
end
local function consume(msg)
if isDuplicate(msg.id) then
print("重复消息 " .. msg.id .. ",跳过")
return true
end
deliverReward(msg)
dedup[msg.id] = { ts = os.time() }
return true
end
local function deliverReward(msg)
giveitem(getplayerbyname(msg.to), msg.item, msg.num, 0, "活动奖励")
end
去重表过期清理示例代码如下:
local function purgeDedup()
local now = os.time()
for k, e in pairs(dedup) do
if now - e.ts > TTL then
dedup[k] = nil
end
end
end
consume 的顺序是"查重、处理、落键":处理成功才落键,处理抛错不落键,消息重投时还能再处理一次——这是"至少一次加幂等"组合的标准姿势。去重键用消息自带的消息号而非内容哈希,跨服务生成键的口径统一由发送方负责。TTL 7 天覆盖重投窗口,purgeDedup 周期清理防表膨胀。
幂等消费踩过三个坑:一是"先落键后处理"的顺序在处理失败时把消息永久标记为已消费,奖励丢失且不会重投——顺序必须处理成功再落键;二是去重键由各服务自己生成,两个服务对同一笔业务生成了不同键,去重失效,键的生成规则收口到消息发送方;三是去重表没有清理机制,三个月膨胀到百万条拖慢查询,TTL 加周期清理是标配。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
一、抛坑提问:名单展示要给隐私留余地,"裁决之杖"持有者的名字怎么打码?保留首尾字符中间换星,长度自适应,规则统一进一个函数…
一、一行代码拆解:DEG[dep] = (DEG[dep] or 0) + 1 —— 这一行统计每个脚本被依赖的入度:入度清…
一、隐蔽陷阱:5000 人里选前 10,全量 sort 再取头——n log n 白花;只要前 K 名时,维护一张 K 大小…
一、线上事故:全服 5000 名玩家状态挤一张大表,pairs 巡检一遍 5000 项耗时 120 毫秒,撞上主循环就是一次…
一、线上事故:装备合成链 A 吃 B、B 吃 A,合成脚本顺着链找源头,死循环 8 万次后栈爆,M2 卡死 40 秒;数据带…
一、抛坑提问:战报里直接写 os.time() 的原始秒数 1758849600,谁能看懂?按"3 分钟前""2 小时前"分…