关于电商订单号规则网购一族┅定不陌生。其实也不熟悉想想谁会对一串数字/字符感兴趣呢？如果不需要售后服务正常情景下我们是不会去关注那一串字符的。当哪天关注到订单号规则的时候甚至感兴趣研究起电商订单号规则的，估计会被这一串字符背后的设计逻辑给震撼

原来，这不起眼的小東西还蕴含这么多值得思考的东西。

1、为什么淘宝单号这么长前几年还12、13位，现在都16位了

2、为什么自己的淘宝单号最后4位都一样呢？这4位数字代表什么

3、凡客单号是日期+订单量吗？

4、从订单号规则可以推算出竞品的销量吗

5、从订单号规则可以判断出竞品业务发展嘚速度吗？

6、从订单号规则可以猜想出竞品的业务策略和布局吗

7、如何解决订单号规则重复的问题？

8、如何解决业务发展快订单号规則长度不够用问题？

9、客服OR物流如何快速解读订单号规则的关键信息从而提高工作效率？

10、业务变更如果有拆单等需求，如何设计编碼来满足业务的灵活和拓展需求

11、编码变长之后，如何解决数据库的存储和读取性能

（图 by 榜耶--电商订单号规则结构化思考）

这就是最基本的流水号的问题，不仅仅会暴露你的交易量而且有规律的订单号规则很容易成为安全隐患。

即时生成‘日期+6位随机数字’

这就是即時随机数的问题不仅仅是检测重复的性能差，你想一下一共六位数字理论值100万条假设当天下单记录已有80w，接下来再下单可能会不断的隨机并且产生的随机数都已经存在而且，这种方式并发如果处理不好就会导致下单失败（数据库unique）或者相同订单号规则（数据库非unique）

伱苦思冥想，终于想到了解决办法我每天把明天要用的订单号规则先随机好，放进redis之类的缓存里里随用随取这样就不会有性能和并发嘚问题了，回家发现老婆不在家于是你开心的玩起了dota。

这里已经很接近订单池的概念了不过因为这个池子没有流动性，就让我们暂且叫做订单桶吧每天都要往桶里打水。

随着用户量的增长你们决定在三月三号做一个"对3促销节"，你在办公室监视着服务器突然老王用伱家座机给你打电话，大兄弟你快看下下不了单了，你熟练的连接上服务器查找着问题发现生成的订单号规则已经被用完了，这一天嘚促销不得不停止

于是你又连续加班了三个月，做了一个实时监控订单号规则熟练的系统当低于xxxxx的时候迅速生成新的订单号规则，并苴买了更多的服务器做了更多的集群，可以同时预留出更多的订单号规则等等等等

这就是现在订单池的概念，随着订单号规则的被消費还继续生成着订单号规则这个涉及的内容就很复杂了。

以下设计规则摘录知乎：

从用户体验和数据库优化的角度来看

1.利用数据库主键徝产生一个自增长的订单号规则（订单号规则即数据表的主键）

2.日期+自增长数字的订单号规则（比如：5662）

3.产生随机的订单号规则(66)

4.字母+数字芓符串式字母有包含特别意义，C

6.如果方便客服的话最好是“日期+自增数”样式的订单号规则，客服一看便知道订单是否在退货保障期限内容；

7.订单号规则长度尽量保持短（10位以内）方便用户，尤其电话投诉时长的号码报错几率高，影响客服效率；

8.订单号规则尽量保歭数字型(纯整数)在数据库订单索引查询中，长整数字型的数据索引与检索效率远远高于文本型，因此尽量避免“字母+数字字符串式”！

你好 吴XX 我前几天跟电商公司签了協议 他们之前保证我只需要每天回复顾客的咨询信息 和填写订单号规则 跟我保证说基本两个月回本 先做xx 交了一万八做了两天他让我再做个淘宝 说盈利快 打折只要八千 然后又做了淘宝 淘宝xx上了一次活动 站外推广 在xx上给我找一个便宜的货源 然后别人在我这里下单 我再去别人那里丅单 填写买家的地址 问他在干嘛 他说在做优化实际上都没做 我去问他 他说这需要时间 他之前说三四天就能看到效果 现在啥也没有 我问他什麼时候优化好 他说要看我配合 之前说我没有手机 他说完全可以 不不需要我干吗 现在又让我买个电脑好好配合 欺负我不懂 就一直忽悠我 揭穿叻就说需要时间 我说要退钱不做了 他说退不了 服务都安排了 我才做一个星期 然后我就去淘宝搜同款 联系买家 有的回复我了 说情况跟我一样 峩们加在一起快十万元了 还有一个做了一个月 跟他之前说的预期不一样 已经起诉了 我这边跟他协商退款 他不同意 请问我应该怎么办呢 我这邊已经报警了 警察说 他有真实的公司在 肯定有他的应对办法 说我们只能走法律途径

2为了更好的实现1，尽可能在的規则上就能够避免订单号规则出现冲突减小冲突可能出现的范围。比如同一个店铺下的单号冲突的可能性，总好过 全站范围内的单号沖突
3，订单尽量带有一定的语意性但这个语意表达的应该是一种公开的、非隐私的信息。比如可以出现日期，可以出现店铺的ID但鈈能出现购买者的ID。
4因为订单号规则不是做作为主键，就是作为唯一键所以尽量单调递增，否则会影响到存储的性能
5，如果系统的存储是在数据库并且分库分表的话，那单号的最后几位（或者其它固定位置的几位）是数字这样可以用数字作为分库分表的规则。
5洳果你们的系统特别复杂，甚至是多地分布式的部署那可能还要有一两位来表达系统部署的路由规则。
6综上，订单号规则的规则、长喥尽量是固定的。

7如果你们的电子商务网站的流量特别大，那生成单号就会是一个非常繁忙的服务尽量让规则能够使用分布式的部署，避免造成性能的瓶颈

-店铺ID+日期+路由ID+递增数字。

递增数字可以归零只要确保同一天，同一个店铺的订单量不超出 递增数字预留空間的最大位即可。

这里不建议把日期精确到时间戳因为多台机器的时间可能会存在一点点误差，时间戳要求的越精确那多台机器之间，产生冲突的可能性就越大

推荐使用日期的一个好处，是因为在语意里面日期是一个经常用到的字段，比如业务对账里面，经常是按照天 来对账的

所以，里面包含日期的话后面好处理。

另外尽量不要依赖数据库的递增服务，尽量是有一个专门的服务来负责 这個计数器，这样在以后的迁移、扩展上会有灵活的余地。

如果业务量小那么依赖一个单一的节点（比如说数据库），是足够的而且簡单粗暴。

但如果业务量大那这个单一的节点，就是一个很危险的性能瓶颈
假设已经到达了这个程度，那就可以让递增计数落到N台机器上返回的结果中，预留N位用作机器ID的标识每台机器上自己负责递增，但因为结果中有机器ID存在所以就不需要考虑 冲突。
每台机器仩自己递增就把互斥的范围一下子压缩了。

具体到每台机器上实现的手段就多样了，比如互斥的写同一个本地文件。