关于订单号的生成

[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++

[sunshinewu85]

按楼主现在的意思，后端是不愿意提供任何生成及检测支持，全靠客户端去整，呵呵，这也理解，谁都不愿在自己管辖的地盘补上一脚，否则一出问题，把全问题都推过去了。。。可是在客户端无论怎么整，其实都已经在拆东墙补西墙了，还不是亡羊补牢。目前亡羊补牢靠谱的还是这两个方案较为合适吧：
1 、找个能拍板让服务端改的人来，从服务端拿 ID 。有些业务，纵使现状改起来麻烦，也好过后续引出更多麻烦；
2 、服务端不提供生成，那总得提供个检测吧~话说回来，都检测了，干脆服务端生成一起了吧，毕竟一劳永逸啊 <img src=" " class="embedded_image" border="0" />

[xmh51]

额。不是办法的办法，服务器生成订单号传给客户端，客户端再上传到服务器。另一种 YYMMDDhhmm +随机数。但是被你否了。 另外随机和重复不是等同的，随机值不能避免重复。你还是在服务器生成订单号比较好。客户端怎么也不可能知道服务器上面是否有重复的订单号。

[finian]

客户端再怎么整都可能会有问题（合法性、安全性），这事儿必须服务端来整。

[harry890829]

@lincanbin guid 的情况我再看看能不能支持，多谢

@loading
@qian0206
@sunshinewu85
@xmh51
@finian
也不是没有想过服务端只开一个生成订单的接口，让客户端调用，但是本来一次的能够完成的动作变成了两次完成，这样失败的情况也就大幅度增加了，于是直接被否决

@xinyewdz 用户 id 是本地 id ，并不唯一，或者说大家都是重复的

@terence4444
@dong3580
@allce231
现在目前的情况是服务器收到相同的订单号就会直接拒绝，也就是说服务器收到的第二个订单会被拒绝并返回订单号重复，目前的解决就是让前端重新发起一笔

@BuilderQiu 哎，金额也是前端送的啊，不过我们后端有相应验证，并无大碍

感谢大家，我倾向于方案二来做了，毕竟几率已经很小，关于 guid 的情况，我上报一下，看看是不是有定论

[sc3263]

加个代理模块吧。客户端发消息到代理，代理那边计算好订单号，加到消息里，然后转发给服务端。

还是得服务端改。不过改动能小很多。

[dong3580]

@harry890829
订单重复谁发出的？服务器对吧，它都知道重复了还不自动重新生成一下订单号，也是醉了。

[scnace]

用户 id 做 hash?

[HunterPan]

@allce231 你的头像好像在哪见过..

[hinate]

客户端的时间戳是不可信的。。。

[abelyao]

客户端把不带订单号的数据提交给服务端，由服务端来生成订单号，反馈结果给客户端的时候，把订单号一起带上。这样仍然是一次请求。

[guizer]

前缀+时间+uid
应该淘宝差不多就这么干的

[ck65]

中心化的发号机，别让客户端生成 id 。

[flyingfz]

http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram

[jon]

客户端生成订单号服务端全盘接受吗，不检查怎么避免问题，检查了为什么不直接服务端生成

[ihuotui]

设计有问题，怎么补都不完美，再加一个接口，客户端获取服务器的全局唯一序号（不用别人教了吧，不过也不算很难或者很简单），然后剩下的逻辑和原来一样。
以后的项目再写第二版，重写。

[popok]

正常用户的用户使用出现重复的概率很小，就怕别有用心的人，毕竟你的订单号在客户端生成

[caola]

一切客户端传入的数据，都有可能是是不可靠的。要是你内部人员使用就无所谓，
如果是面向公众用户使用的话，做得安全一点是好的，毕竟可能会有那么一些别有用心之人。

[ljbha007]

客户端做的任何安全措施都是没有屌用的

[Perry]

@allce231 头像不错

[wavingclear]

微秒级加随机数还有重复，这就是尝试攻击了，客户端还改啥