12 位纯数字兑换码的生成算法，如何尽可能保证不重复？

uniqid()不可以么?

我也来个思路， 12 位分成 8+4 ， 8 位账号＋ 4 位密码，前 8 位可以按照一定规则直接递增，因为你要求 1000w 这个量级，然后用组合的方式来做验证。

从加密学角度出发，可以使用浮动的 账号密码位置模式，比如 8+4 ， 4+4+4 根据一定的规则把数字拆开，具体还是位数太短， 1000w 量级， 16-20 位会比较方便一点。


其实上面也有很好的思路
1. 预先生成不重复的方 redis ，如果在生产环境我会这样做， 1000w 应该很快
2. 记录单据和所有者的关系，这样做一个 link 就可以了。

有索引的话，数据库查重速度很快的。数据库是树形存储的，查询单个记录秒查的，不是瓶颈。

@jsjscool 自增 ID 不是随机的，有被爆破的可能性。

我觉得随机数 8 位，时间戳取 4 位不错。
如果重复就改用备用算法重新生成，就按照最糟糕的纯随机？
然后循环检查是否重复

先说下是否是分布式部署。。。
其实可以不用查库直接生成不重复的。。。
基本原理推荐查考：[twitter 的 id 生成]( https://github.com/twitter/snowflake)

@xi_lin 鄙人愚钝……看不是很懂，但是这个兑换码要求**乱序**且**纯数字**，你回复的这个看起来似乎不那么贴近需求，谢谢
@debiann 主要是希望利用算法尽可能减少查询的次数，谢谢
@haython 这项目后期要允许单用户多个券的，所以没有采用你所说的这种方法，谢谢
@am241 请问有哪种对称加密算法加密后的结果是 12 位纯数字的？我暂时还没听说过，请指教，谢谢
@SuperFashi 沃日 dalao 亲自回复，萌新瑟瑟发抖……我暂时不清楚如何哈希出 12 位纯数字来， dalao 可以给个思路吗？谢谢
@k9982874 那个……没有 redis
@jsjscool 自增 ID 不是乱序的，很容易被他人猜出来，作为兑换码的话绝对不行
@Valyrian 愿闻其详，看不是很懂，谢谢
@realpg 刚毕业的萌新给 dalao 跪下了。看不是很懂你所说的“ INSERT IGNORE INTO 一大批”，因为这个项目里券是用户主动领取的，也就是服务端被动发券，每次一张，动态生成券码这样的
@txlty 感觉原理上和纯随机没有本质区别，稍后试一下重复率，谢谢
@fthvgb1 不行，需要 12 位纯数字
@lygmqkl 你这里所说的账号可以理解为用户的 id 吗？
@zacard 看不懂嘤嘤嘤……

感谢各位的关注及回复

@mokeyjay
主动领取模型，都没有集中插入的负载，那不是更简单
INSERT IGNORE INTO 一个随机码
返回 affected_rows 是 1 就成功了 不是 1 再生成一个往里插

我觉的楼主自己的方案在产品的生命周期中出现重复的概率可以说为 0 ，如果这系统不是准备用上几百年，就没必要将简单的问题搞这么复杂。

这不是可以用 RSA 来做吗.
12 位数字就是万亿级别,那就取一百万左右的质数 2 个:
p = 997207 , q = 997219
则 n = p * q = 994433767333
然后取尽可能小的 d = 107 ,则 e = 9293754887

然后设自增 id 为 a,则有和 a 一一对应的 b
b = (a ^ d) % n

这样可以保证 id 从(2-994433767333)都不会重复

(2-10)的 ID 对应的卡号如下:
2 = 899396353970
3 = 781336638737
4 = 874206977826
5 = 756065937681
6 = 515322322794
7 = 538347577421
8 = 17370581741
9 = 812852944487
10 = 643487003155

@mokeyjay 大数异或肯定是乱序的
纯数字只要拿字母转数字就行，最基本就是直接变成对应的字母序。。建个映射嘛

@mokeyjay 以 PHP 为例：
hexdec(substr(md5("Hello"), 5, 10))

@debiann 不對吧，拼接上時間戳是縮小了可能重複的區域，而不是縮小了取值範圍。

最糟糕的方案里面，检查部分工作可以由数据库自己做 unique 完成。

或者先生成足够数量，然后 distinct 到目标表