一：订单号的需求
如果公司有交易相关的业务，那么订单号是一定需要的。
订单号设计需求：
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