2019-M03 关於 Idempotent 两三事 早上朋友丢了问我关於解决 idempotent 的问题 原因在於他那边最近常常发现 存钱的 POST API 在 Server 端常常收到两次的 Bug 这类型的问题常常发生在 Mobile + API 自动 retry 因为 Mobile 的特性 : 使用 WiFi 会因为移动导致断线、自动重新连线 导致第一个 POST API 没有收到正常的回传值 而自动 retry 因此在很多 POST 等相关 API 都会加上 IDEMPOTENT 参数来避免重送攻击 概念上很简单：在 POST 的时候 Client 会带上一个 IDEMPOTENT 如果 Server 端收到来自同一个 IDENPOTENT 的请求 第二次之後的操作视为 NOP 如果来自不同使用者 但 IDENPOTENT 相同的情况 则回传 collision 错误 因此找到一个不会碰撞的 IDENPOTENT 的产生方式就极为重要 ---- 以下是本文重点 ---- 强者我朋友提出了 UUID[0] 的方式 也就是随机产生一组 128bit 的随机字串 但是他的长官认为 是否会有 collision 的状况 ... 因此废物我提出了一个 ULID[1] 解决方案用来解释他很难发生 collision 在 ULID 的 SPEC 下定义使用 128bit 长度：前面 48bit 用来表示时间、後面 80bit 则为随机 时间戳记本身为 ms 等级计算 因次发生 collision 的前提之一就是要在同一毫秒 而後者 80bit 的随机数字则假设遭遇到生日攻击法[2] 使用速算法来计算 collision 发生机率为百万分之一 (~ 2^-20) 约需要 2^30。大概是 1ms 需要有一亿次请求 #谨献给强者我朋友的长官# [0]: https://tools.ietf.org/html/rfc4122.html [1]: https://github.com/ulid/spec [2]: https://en.wikipedia.org/wiki/Birthday_attack --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 106.1.229.215 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/NetSecurity/M.1573698400.A.0F8.html