全服补偿(万人规模)、活动结算奖励(按排名发放)、 GM 群发——大批量邮件如果同步逐封写入,数据库会被写爆。批量邮件的投递需要队列化:任务拆批、限速写入、失败重试、进度可查。适用于一切万级规模的邮件发放场景。
local function dispatchBatch(list, batchId)
local batch = loadBatchState(batchId) or { cursor = 1 }
local batchList = list
for i = batch.cursor, #batchList do
local ok, err = writeMail(batchList[i])
if not ok then
saveBatchState(batchId, i) -- 记录游标,下次从断点继续
return false, err
end
end
saveBatchState(batchId, #batchList + 1)
return true
end
游标持久化让中断后可以从断点续投,不重不漏。写入限速(每秒 200 封)保护数据库,批间隔 sleep 控制节奏。
批量邮件的附件多为补偿道具:附件在邮件创建时入托管库(不进玩家背包),玩家领取时校验托管记录后入包。托管记录带唯一领取键(batchId + 玩家 id),重复领取被唯一键拦截——万人规模的补偿不会因为重复点击而多发。
批量投递完成后输出对账单:应收件人数、实际投递数、失败清单(失败原因分类)。运营撤回场景(发错内容)支持按 batchId 整批撤回未领取的邮件(已领取的不追回,走单独补偿流程)。某项目万人补偿的投递从逐封同步的 40 分钟缩短到 3 分钟,投递期间服务负载曲线平稳。批量邮件框架建好后,运营的补偿、结算、通知三类需求都走同一通道,运维成本从每次特批变成后台配置。
批量邮件的正文变量白名单:模板里允许的变量只有玩家名、角色名、金额、道具清单四类,白名单外的占位符在预检阶段报错。变量值全部来自服务端数据,不接受运营在模板里引用任意玩家字段,防止模板被改造成信息泄露的通道。
本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付,内容以官方知识库与真实项目为出处,按版本持续修订。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
设计初衷 新手的第一个 30 级决定留存:被红名追杀一次、被高级玩家抢一次 BOSS,新号当周流失率直接翻倍。新手走廊是 1…
设计初衷 拍卖行的恶意挂拍有两种:挂天价试探市场、批量挂垃圾物刷屏——挂拍零成本,恶意就没有代价。保证金机制让挂拍押上真金白…
设计初衷 家园系统回答的是长线玩家"下线之后游戏还在为我工作"的情感需求:种下去的种子在离线时生长,上线收割即是回馈。产出设…
底层原理 缓存防的是重复查询,但有一类查询永远查不到:恶意玩家批量请求不存在的物品名,每次都绕过缓存直击底层查询——缓存对"…
底层原理 金币、功勋这类关键数值,单账本一旦被静默改坏(bug 写错、内存篡改),没有任何报警——账本自己不会喊冤。双写校验…
底层原理 内存涨了不回落,十有八九是有张该死的表被谁攥着不放。Lua 的回收按可达性判定:只要还存在一条从全局表、活跃闭包或…