最近做小型B2B和B2C电商，一直在思考订单号的生成方式
订单号的几个约束：
- 不重复
- 安全性：订单编号不能透露你公司的真实运营信息，比如你的订单就是流水号的话，那么别人就可以从订单号推测出你公司的整体运营情况了
- 控制位数：一般正常使用场景应该是订单出异状或者退货的时候，用户将订单号报给客服，由客服进行查询，长的号码报错几率高，影响客服效率。所以一般在10~15位为好。
- 订单号尽量保持数字型(纯整数)，在数据库订单索引查询中，长整数字型的数据索引与检索效率，远远高于文本型，因此尽量避免“字母+数字字符串式”
- 如果方便客服的话，最好是“日期+自增数”样式的订单号，客服一看便知道订单是否在退货保障期限内容；
不重复性一般通过自增序列保证，安全性可以通过随机码保证，但是随机码不能过多
如果要在订单号中融入日期、业务类型、买家ID等属性，订单号的长度没法降低。用户报订单号给客服现在很少复述，一般都是通过复制实现，所以很多APP上都有复制订单号的功能
看了下考拉的订单号带了时间信息，总共25位，美团16到17位，同一家店的前四位相同
最终我确定的规则是 平台类订单
年月日（6位） + 业务类型（2位） + 0 + 买家ID(后2位) + 随机码(3位) + 平台每日自增序列
商户类订单
年月日（6位）+ 业务类型（2位） + 1 + 买家ID（后2位） + 买家ID（后两位）+ 随机码(3位) + 店铺每日自增序列
PS：可以将自增序列根据业务情况固定长度或最小长度
这里没有用Unix时间戳+每秒的自增序列，因为在分布式环境下不好处理
随机码处理
一开始我只是简单将随机码加载了订单的签名或者后面，一直没有想到好的方式，后来偶尔看到了stackoverflow上面的一个回复，决定借鉴他的方式来处理随机码
首先系统根据当前日期与上线日期计算出一个3位随机码（简单处理我就用的相减）
- 第1天：442
- 第10天：153
-
第14天：539
- 订单自增序列=1，订单号=4412
- 订单自增序列=2，订单号=4422
- 订单自增序列=10，订单号=41402
- 订单自增序列=200，订单号=240402
- 订单自增序列=2000，订单号=2040402
