订单号设计

一:订单号的需求

如果公司有交易相关的业务,那么订单号是一定需要的。

订单号设计需求:

1、基本需求

唯一性,安全性,稳定性,满足当前业务需求

2、定制化需求:

业务相关,技术相关

3、其他

比如查询方面等,其实也跟业务有关


1:基本需求

其实最基本的需求就是满足当前业务发展,对未来的业务发展有一定的前瞻性(这个比较难做到)。

唯一性:每个用户生成的每一笔订单号,不能重复,不然就有可能混淆用户订单。而且这个订单号最好能做到全局唯一,便于以后订单合并统计,全局查询等。

安全性:用户或者其他人查看订单号时,不能看出订单的数量。如果看出来,那么公司业务情况就会暴露了,不利于公司发展和竞争。特别是竞争对手知晓了业务量,就会比较危险,对手可能根据这个信息而制定相应的竞争策略。毕竟商场上知己知彼百战不殆。

稳定性:订单号肯定也需要稳定,不能过几天订单号突然又变了,那么客服,技术,业务,产品都可能会出现问题。


### 2:定制化需求 #### 业务相关: 比如用户打电话给客服时,根据订单号来咨询相关信息,这时候订单号怎么设计才方便用户和客服?
是不是位数越短,用户报订单号就越容易,客服也容易输入和记录。

比如公司有几个销售平台-线上微信平台,web平台,APP平台,线下的店铺,产品想从订单号就能看出是哪个平台出来的订单,这时的订单号是不是要加入平台相关的参数呢

比如想从订单号看出商品的大类类别,业务类型

比如有这么多家的支付渠道,想从订单号知道支付渠道信息

比如想从订单号知道物流信息,哪家的配送物流

比如从订单号知道下单时间,用户ID等信息

等等... ...

上面这些都是业务相关需求。
所以要多多思考,自己当时的业务需求是什么?适当的进行取舍,减去不必要的需求,然后合理的设计订单号。

技术相关:

其实也跟业务发展有关,当业务发展比较快,订单越来越多,数量越来越大,数据库的订单存储有了瓶颈,
这时候就需要考虑分库分表。 那根据什么标准来分?根据订单号来分的话,那么这个订单号必须要有一个固定部分,才好作为分库分表的一个基准。
用户ID是不变的,所以订单号嵌入用户ID,当然可以根据一定的规则把用户ID“变形”,比如截取用户ID后5位,或者用hash把用户ID进行hash在截取等等


### 3:其他 比如分库分表等

二:订单号编码规则

订单号尽可能短,在10 - 15位之间。

一般常见的编码规则:

1、随机生成订单号

一个变种:
    日期(8位)+后6位(随机数),随机数这一天内不能重复

2、数据库自增主键

这个很容易暴露销量信息,但是是最简单的一种方式

redis的incr命令

3、日期+自增主键

缺点跟上面的1一样

4、 年月日分+用户ID(4位)+微秒

年可以是2位的,2019,只要19后面2位,19091732323412
     用户ID可以截取几位

5、年月日分+支付渠道1位+业务类型2位+用户ID+随机数(一天内部重复)

6、UUID

太长了,不利于阅读

7、GUID

跟上面一样,太长,不利于阅读

8、twitter的雪花算法

PHP版:https://github.com/zh-ang/php-snowflake
      java版:https://www.cnblogs.com/relucent/p/4955340.html
     Go版:https://github.com/bwmarrin/snowflake

三:参考

https://www.zhihu.com/question/19805896

posted @ 2018-07-19 18:09  九卷  阅读(918)  评论(0编辑  收藏  举报