这是什么
一个幂等键审计工具。它按照正确的 API 应遵守的规则重放日志中的请求，并把每条记为首次写入、安全重放或问题。
面向支付和订单 API 的幂等性审计
找出被你的 API 扣了两次款的请求。
Idempotency Ledger 读取你的请求日志，把每个写请求记在它的幂等键名下，并指出哪一次重试造成了第二笔扣款、第二个订单或第二次打款。每个问题都附有涉及金额和修复方法。
按键记录的扣款No. 0417
| 时间 | 键 | 金额 |
|---|---|---|
| 10:00:00 | ik_7f3a | 49.99 |
| 10:00:03 | ik_7f3a | 49.99 |
| 10:05:00 | ik_c044 | 89.00 |
| 10:05:00 | ik_c044 | 89.00 |
| 10:12:00 | ik_f611 | 9.99 |
多扣金额+89.00 EUR
适合谁
需要弄清客户是否真的被扣了两次款以及原因的后端工程师、支付工程师、SRE 和客服负责人。
解决什么问题
重试很正常，但如果重试把工作又执行了一遍，就会造成真实的资金问题。它们淹没在成千上万行日志里。账本会把它们连同合计一起放到最上面。
审计你的请求日志
粘贴或打开一份日志导出。不会上传任何内容，解析和检查都在本页完成。
每行一个请求，或一个 JSON 数组，或带表头的 CSV。
按字段名识别：time 或 ts、method、path 或 url、status、幂等键、所创建对象的 ID，例如 charge_id 或 order_id，以及 amount、currency 和 customer。也支持嵌套 JSON 和 Idempotency-Key 请求头。
审计结果会显示在这里
粘贴日志后点击“审计日志”，或加载示例查看所有类型的发现。
账本会标出什么
每个重复出现的键都按时间顺序检查，并与正确的服务器应有的行为对比。
重复生效
同一个键、同一个请求，却创建了两个不同的 ID。服务器把工作做了两次，这是代价最高的情况。
竞争
两份副本在两秒内到达且都成功了。常见于双击和过于激进的客户端重试。
请求体不一致
旧键带着新参数到来。正确的服务器会用 422 拒绝，接受它会掩盖客户端的缺陷。
部分失败
一次返回 5xx 却仍创建了对象的请求，随后重试又创建了一个。只有日志中带 ID 时才能看到。
没有键
没有键的写请求无法去重。时间相近的两个相同写请求会被记为重复。
过期复用
在有效期之后又出现的键会被当作新工作。请按你的服务器设置选择有效期。
使用方法
导出日志
从网关、负载均衡器或应用日志中，取出某个接口或服务在一段时间内的请求。
粘贴或打开
JSON 行、JSON 数组、带表头的 CSV 或包含 key=value 的普通日志行都可以。
设置键的有效期
选择你的服务器保存键的时长。Stripe 风格的 API 使用 24 小时。
阅读账本
问题和涉及金额排在最前面。展开一个键查看每一行和修复方法，然后复制报告或下载 CSV。
注意事项
- 只有日志里包含所创建对象的 ID 时，才能证实重复生效。没有 ID 时，重复请求按重放记账。
- 请求按方法、路径和请求体比较；没有请求体时，按金额、币种和客户比较。
- 时间以 UTC 显示，没有时区的时间也按 UTC 读取。没有时间的行保持文件中的顺序。
- 大日志也能处理，但只保留你关心的接口会更快。
- 数据不会离开你的浏览器。即便如此，分享报告前也请删除卡号和个人数据。
常见问题
什么是幂等键？
客户端随写请求发送的唯一值。如果同一个请求带着同一个键再次到来，服务器会返回第一次的结果，而不是再做一遍。
为什么 409 被标为正确？
这表示第一个请求还在执行时第二份副本到达，服务器拒绝并行执行它。客户端稍后重试即可拿到保存的结果。
只扣了一次款，为什么请求体不一致也重要？
用旧键接受新参数，说明客户端存在复用键的缺陷。下一次它就会造成一笔看起来像重放的错误扣款。
日志里需要有 ID 吗？
有 ID 审计才精确。请在日志中记录每次写入所创建对象的 ID，例如 charge_id 或 order_id。