游戏平台工程与架构研究站
研究方向速览
最新研究报告
共 104 篇HMAC 签名防不住重放攻击？补上时间戳、Nonce 和去重这三道防线
HMAC 签名防不住重放攻击？补上时间戳、Nonce 和去重这三道防线 HMAC 签名仅能验证密钥持有者身份，无法阻止旧消息重发；必须结合时间戳窗口、Nonce 随机数及持久化去重状态构建完整链条。 为什么单靠 HMAC 签名防不住重放攻击 单靠 HMAC 校验无法区分新旧请求，攻击者可原样重发昨日合法报文，导致系统在通过签名后重复执行如扣款等敏感业务操作。 你收到一条带着完美 X-Hub-Si…
-
Webhook 验签别先转 JSON：字节流差一个空格，伪造请求就能过
Webhook 验签别先转 JSON：字节流差一个空格，伪造请求就能过 Webhook 安全验证必须严格遵循先读取原始字节流计算签名、再解析业务数据的顺序，任何先反序列化再验签的操作都会因数据格式变动导致校验失效。 Webhook 安全的第一原则：必须读取原始字节流 验证 Webhook 请求真实性的首要原则是直接从网络流中抓取二进制原始数据，严禁在计算 HMAC 签名前进行任何形式的字符串反序…
-
Webhook 反复重试失败别硬撑：用指数退避防风暴，死信队列兜底
Webhook 反复重试失败别硬撑：用指数退避防风暴，死信队列兜底 处理 Webhook 反复重试失败的安全方案，需结合指数退避与随机延迟策略防止服务风暴，并将持续失败事件转入死信队列以保障系统稳定性。 先分清情况：哪些回调值得重试，哪些该放弃 区分回调是否值得重试，关键在于确认接收端状态而非仅依赖 HTTP 200 响应，遵循至少一次投递原则以避免因 ACK 丢失导致的资金损失。 别把 HTT…
-
Webhook 接收端崩溃怎么办？靠“先落盘后处理”保住数据不丢
Webhook 接收端崩溃怎么办？靠“先落盘后处理”保住数据不丢 Webhook 接收端崩溃后保证数据不丢，核心在于通过持久化存储事件标识与处理状态，配合幂等校验机制，确保系统重启后能识别并正确复用已处理记录。 为什么 HTTP 200 OK 可能是个陷阱？ HTTP 200 OK 状态码仅是发送方确认收到响应，若接收端在返回前崩溃导致 ACK 丢失，发送方将误判失败并触发重试，从而引发重复通知…
-
Webhook 重复通知怎么防止扣款错误：用事件 ID 锁死本地状态
Webhook 重复通知怎么防止扣款错误：用事件 ID 锁死本地状态 防止 Webhook 重复通知导致扣款错误，核心在于利用事件 ID 记录本地状态，确保同一笔订单在多次回调中仅执行一次资金操作。 为什么 HTTP 200 不代表交易完成？ HTTP 200 响应仅代表接收方收到请求，因网络边界无法保证恰好一次交付，发送方可能重发相同事件，故不能视作交易已安全完成。 你以为收到 HTTP 20…
-
余额对不上别瞎改：顺着追加式账本三步回溯，精准定位交易断点
余额对不上别瞎改：顺着追加式账本三步回溯，精准定位交易断点 错误交易后应利用追加式账本保留的完整变更轨迹，通过还原历史事件链而非依赖最终状态来定位差异源头。 盯着账户余额看，往往只能得到“结果”，却找不到“原因”。当一笔交易出错时，如果系统只是简单地覆盖旧数据，你就失去了还原现场的机会。真正的调查起点，在于理解 追加式账本 如何保留变更轨迹，而不是原地修改 [1] [2] 。 追加式记录 vs …
-
内部显示成功钱却没到账？追加式账本只能查错，不能替你对账
内部显示成功钱却没到账？追加式账本只能查错，不能替你对账 内部账本与银行对账不一致时，追加式账本可保留差异记录并触发调查流程，但无法自动消除跨数据层差异，需依赖后续证据或人工处置。 为什么追加式账本能帮上忙，却解决不了对账问题 追加式账本能提升内部交易回溯的可追溯性，却无法替代跨系统对账，当外部未入账时必须让位于人工介入以查明资金去向。 读完这篇你能自己判断：当内部系统显示交易成功时，追加式账本…
-
错误交易不覆盖：追加式账本如何用反向分录修正余额
错误交易不覆盖：追加式账本如何用反向分录修正余额 追加式账本通过生成反向分录或补偿事件抵消错误影响，在保留完整变更轨迹的同时重建当前余额，确保审计证据不被覆盖。 不覆盖记录的底层逻辑：为什么必须追加新事件 不覆盖记录的底层逻辑在于将复式记账与不可变日志绑定，强制系统生成新事件而非抹除旧记录，以维持历史数据的完整性。 一笔错误交易发生后，系统绝不会直接抹去那条错误的记录。相反，它会生成一条新的 追…
-
回调丢了怎么办？用事务性 Outbox 和 Saga 把本地账目锁死
回调丢了怎么办？用事务性 Outbox 和 Saga 把本地账目锁死 通过事务性 Outbox 或 Saga 模式，将本地数据库状态变更与外部异步通知解耦，利用内部日志或补偿机制在回调丢失时自动修复，确保最终数据一致。 系统收到支付回调的那一刻，并不代表账目已经彻底落定。很多人误以为“回调到达即等于资金最终正确”，这个推论在架构层面其实根本站不住脚 [1] 。网络波动、服务重试或链路阻塞，随时可…
-
只收到回调就敢入账？签名验证才是防黑客伪造的第一道防线
只收到回调就敢入账？签名验证才是防黑客伪造的第一道防线 验证支付回调来源真实性的核心在于签名校验机制，通过比对数字签名确认消息源自官方供应商且未被篡改。 为什么仅靠“收到通知”无法确保资金安全？ 仅收到通知无法确保资金安全，因为网络波动或中间人攻击可能伪造成功数据包，导致订单状态被恶意篡改。 很多系统把“收到回调”直接等同于“钱已到账”，这个推论在工程上极其危险。网络波动、重试风暴或中间人攻击，…
-
支付回调重复发送怎么处理？用数据库唯一约束筑起资金安全防线
支付回调重复发送怎么处理？用数据库唯一约束筑起资金安全防线 处理支付回调重复发送需构建架构级防线，利用幂等键与数据库唯一约束拦截重复请求，防止资金记录出现双份或状态错乱。 别把“收到回调”当成“钱已到账”。网络波动、超时重试和路由差异，让同一笔支付可能触发多次通知，甚至乱序到达。如果你只盯着回调做记账，重复入账或状态错乱的风险就藏在这些缝隙里。面对支付回调重复发送怎么处理这个难题，单纯依赖应用层…
-
钱到了却动不了？拆解充值后“余额增加”与“实际到账”的三个中间态
钱到了却动不了？拆解充值后“余额增加”与“实际到账”的三个中间态 钱到了但不可用是资金已入账但未完成外部清算或 Webhook 未触发的中间态，表现为余额可见却无法动用。 为什么会出现“钱到了但不可用”的异常现象？ 出现钱到了但不可用是因交易接受、资金可用资格与外部结算确认三个环节存在天然时序差，导致账面记录与实际可支配状态不同步。 用户明明看到账户多了一笔进账记录，点击转账或支付时却提示余额不…