1

1

批量生成存数据库

2

第二种假设秘钥漏了你不炸了

4

1

记得前前同事用 uuid.md5.hashCode/100000 结果上线三个月后重复了

7

8

1

批量生成兑换码，保存到数据库，同时兑换码本身带有部分校验逻辑（如校验位、活动标识）。核销时既能快速查表，又能做基础校验，避免误输和伪造。

9

1

存到数据库更稳妥，一则如楼上所说更安全，二则可以方便地控制兑换码，比如停用某个兑换码。你用 key 解析的话，后续想加限制就得改代码

10

1

同意 8 楼说法，本身带校验位可以让你快速判断兑换码是否合法，但是实际是否有效还应该以数据库中的内容为准。

11

1

12

1

比如这个兑换码有 32 字节，前面 16 字节是随机数 A ，后面 16 字节 B=hash(A+C+salt1)，服务器存随机数 A, 随机数 C, 验证哈希 D=hash(B+salt2)
把兑换码印刷之后，就可以把 salt1 记在小本本上，然后把 B 从数据库中删掉。
简单的校验可以是限定随机数 A 具有某些性质，比如某两位和必须为固定值。

13

1

设计比较简单，活动标识 3 位-渠道标识 3 位-10 位随机字符串 存数据库😂

14

1

之前用 cursor 写过，提供的方案是后端数据库一个兑换码表，批量生成唯一值，哪个用户兑了就标记已兑状态，实现不难。

16

1

生成 uuid 然后存库 并对字段做唯一约束

17

1

只存数据库，不用搞什么校验位，兑换码这种功能请求量太少了，给上个索引，你数据库 CPU 都上不了 1%，
10000 以内的直接创建， 创建的时候唯一索引，太多开个队列创建就好了，加个批量创建批次码很管用，经常让查🥲
兑换的时候加个乐观锁

18

1

用 guid 最好，注意不是 uuid ，uuid 单个位只能是 16 进制数字范围，容量比 guid 小很多

19

1

不过注意，兑换接口一定要防止穷举，错误到一定次数 ban 掉

20

@opengps 穷举 guid 吗。。有这算力去挖矿不是更好

21

@fdd92 #20 你能让攻击者也这么想吗？显然做不到，所以网络防护必须得有所应对