关于订单号的生成

[harry890829]

现在项目场景是， pc 客户端生成订单号传给后端，之前使用的是微秒级的时间+随机数，但是依旧发生了重复情况，现在想要优化这个算法，要求订单号中只包含数字，长度小于 30 。

后来想到两种方法： 1.YYMMDDhhmmss+mac 地址（转成 18 位十进制），经过讨论， mac 地址可以进行修改，时间也不一定是确定的，假设场景，客户在 12:00 支付完成之后，发现自己时间快了半小时，然后回调了，这样在 11:30 到 12:00 之间就有可能重复。

2.YYYYMMDDhhmiss+毫秒+微秒+IP 尾 4 位+6 位随机数，其中 6 位随机数种子采用（ mac 地址前三位前补 00 ）与（ mac 地址后三位后补 00 ）进行异或得出。这个方法大家觉得只是极大的减少的几率问题，但是并不能避免重复的问题

也有同事提到了， guid 来做，但是订单号要求纯数字，现问下如何解决此类问题，多谢 开发语言 c/c++

[gkiwi]

@yao978318542
@Perry
@HunterPan

头像是什么梗。。求科普

[imnpc]

客户端生成订单号 这么作大死的办法谁想出来的？
客户端只允许传输关键类数据 例如商品 ID 数量
其他涉及到安全的一律服务端控制...

[likai]

客户端时间随便可以更改。拿来生成订单号合适么？
再一个。都知道重复了。后台啥事也不作？

[gkiwi]

本来想写点的客户端怎么避免和处理的，但是这个锅不应该让客户端背！

[GKLuke]

客户端就不要调用本地时间了，调用网络时间或者服务器时间，那就不存在时间回调了。
当然，永远不要相信前台数据，起码都要滤一边真伪啊。

[Clarencep]

订单号居然在客户端生成，这是在开玩笑吗

[wanttofly]

@gkiwi 头像的梗：这马容易劈腿。。。

[yuankui]

这种问题，网上解决方案不是一大堆吗？

你不是应该发一个帖子说你发现了哪些方案，然后让大家评价一下各个方案的优劣吗？

[GavinJ]

客户端生成订单， 新鲜~~~~

[DrJoseph]

@gkiwi 马蓉的微博头像

[killerv]

客户端生成订单号，这是什么人想出来的……

[ThreeBody]

天啊，订单号让前端生成已经是很严重的设计缺陷了，金额也让前段发？你后台有验证还要前段发一次？
就这两个，我觉得你们系统可能还有很多坑。
我想问问，我看到你说前端的用户 id 是一样的，你们前端难道不用用户登录的？就是可以匿名下单？
是不是类似那种， 1688 元的 iphone 6s ，然后输入名字，地址，电话就直接下单那些？
微妙级的订单都可能重复，加个 uuid ，这样应该就够的了。 uuid 碰撞几率这么低，加时间前缀，应该是够的了。

[pljhonglu]

服务器的锅为什么要你来背。。。

[southwolf]

LZ 赶紧来爆一下产品名字，组织 V2 群众薅羊毛去啊…… iPhone6s 点击就送啊

[damean]

@harry890829 “本来一次的能够完成的动作变成了两次完成，这样失败的情况也就大幅度增加了”
这个“大幅度”有统计过吗？
为啥会失败呢？失败了还可以在尝试几次的。

[romisanic]

如果改客户端订单号生成规则可行，意味着大家的客户端都要更新，既然如此，为什么不直接改成后端生成，这样所有客户端使用的订单号实际上是从一个位置生成的，也就不会再有重复的顾虑。哪怕后续有需要修改的地方，那也只需要直接修改服务端就可以了。

[22too]

我们目前的做法，毫秒级时间 + 随机数 + 用户 id 。也就是除非这个用户故意重复，用户直接是隔离的。目前没有发现问题。

[williamx]

上面的说得没错，把用户 id 加上，基本都不会出现重复的问题。

[hitmanx]

如果把本地时间换成通过网络服务器获取时间呢？这样精确到毫秒，应该没有重复性的问题了吧，除非用户 hack ，不过那就是是整个架构问题了，反正现在也有这个问题。

[maxmilia]

用户 ID 直接给的话会被人知道用户规模，所以加个密