84669인 학습
152542인 학습
20005인 학습
5487인 학습
7821인 학습
359900인 학습
3350인 학습
180660인 학습
48569인 학습
18603인 학습
40936인 학습
1549인 학습
1183인 학습
32909인 학습
最近在考虑订单id怎么生成。
全数字但是不要太长,同时orderId需要唯一。
简单的id自增长肯定不行,不仅位数不够,还会暴露业务量。
最近我考虑:
简单的时间戳+随机数+流水号计数器。
不知道大家有什么好的想法。
业精于勤,荒于嬉;行成于思,毁于随。
主要是看你的业务量了。
一般是几种方式: 1.用户id+年月日时分秒+随机数+流水号。随机数和流水号的位数按照业务量来设定,不过在秒级的时间内,两个4足够了。如果你的业务量小的话,随机数和流水号都不用。 如:0424 201505291832 0001 2455
2.用户id + md5(用户id+时间戳)。不过使用md5()进行消息摘要可能会出现重复,虽然36^32看起来很大,但是不能保证摘要后的数据不重复。或者可以在md5()的基础上再进行改造。 如:0424 + md5(0424 201505291832),(中间没有空格)生成的摘要是:0424e13c2fe2f569da04b2aa411980dbfa28
一般都是时间戳 + 随机数的,一天的量也不会太大
我们的订单系统就是用“年月日时分秒”+4位随机数。这样,理论上支持1秒钟允许最多创建999个订单。当然,订单号生成之后,还需要检测是否重复。
简单的时间戳+随机数+流水号计数器+分类id
分类id指的是,需要在数据库在写个映射表 比如 1-》某种订单 2-》另一种订单 3-》又是一种订单
UUID怎么样?
可以用发号器?
用户id+简单的时间戳(精确到小时)+(4位数的)流水号计数器 比如现在是2016年06月10日6时然后加上4位数的流水号计数(身份证上就4位,应该够了,随机数什么的个人觉得用处不大),写成0424-2016-06-10-06-0001。
主要是看你的业务量了。
一般是几种方式:
1.用户id+年月日时分秒+随机数+流水号。随机数和流水号的位数按照业务量来设定,不过在秒级的时间内,两个4足够了。如果你的业务量小的话,随机数和流水号都不用。
如:0424 201505291832 0001 2455
2.用户id + md5(用户id+时间戳)。不过使用md5()进行消息摘要可能会出现重复,虽然36^32看起来很大,但是不能保证摘要后的数据不重复。或者可以在md5()的基础上再进行改造。
如:0424 + md5(0424 201505291832),(中间没有空格)生成的摘要是:0424e13c2fe2f569da04b2aa411980dbfa28
一般都是时间戳 + 随机数的,一天的量也不会太大
我们的订单系统就是用“年月日时分秒”+4位随机数。这样,理论上支持1秒钟允许最多创建999个订单。当然,订单号生成之后,还需要检测是否重复。
简单的时间戳+随机数+流水号计数器+分类id
分类id指的是,需要在数据库在写个映射表
比如
1-》某种订单
2-》另一种订单
3-》又是一种订单
UUID怎么样?
可以用发号器?
用户id+简单的时间戳(精确到小时)+(4位数的)流水号计数器 比如现在是2016年06月10日6时然后加上4位数的流水号计数(身份证上就4位,应该够了,随机数什么的个人觉得用处不大),写成0424-2016-06-10-06-0001。