（图 by 榜耶--电商订单号结构化思考）
关于电商订单号，网购一族一定不陌生。其实也不熟悉，想想谁会对一串数字/字符感兴趣呢？如果不需要售后服务，正常情景下我们是不会去关注那一串字符的。当哪天关注到订单号的时候，甚至感兴趣研究起电商订单号的，估计会被这一串字符背后的设计逻辑给震撼。
原来，这不起眼的小东西，还蕴含这么多值得思考的东西。
1、为什么淘宝单号这么长？前几年还12、13位，现在都16位了？
2、为什么自己的淘宝单号最后4位都一样呢？这4位数字代表什么？
3、凡客单号是日期+订单量吗？
4、从订单号可以推算出竞品的销量吗？
5、从订单号可以判断出竞品业务发展的速度吗？
6、从订单号可以猜想出竞品的业务策略和布局吗？
7、如何解决订单号重复的问题？
8、如何解决业务发展快，订单号长度不够用问题？
9、客服OR物流如何快速解读订单号的关键信息，从而提高工作效率？
10、业务变更，如果有拆单等需求，如何设计编码来满足业务的灵活和拓展需求？
11、编码变长之后，如何解决数据库的存储和读取性能？
等等等等
（图 by 榜耶--电商订单号结构化思考）
以下小故事摘录知乎：
http://www.zhihu.com/question/19805896#answer-31069940
日期+6位自增数字
这就是最基本的流水号的问题，不仅仅会暴露你的交易量，而且有规律的订单号很容易成为安全隐患。
即时生成‘日期+6位随机数字’
这就是即时随机数的问题，不仅仅是检测重复的性能差，你想一下一共六位数字理论值100万条，假设当天下单记录已有80w，接下来再下单可能会不断的随机并且产生的随机数都已经存在，而且，这种方式并发如果处理不好就会导致下单失败（数据库unique）或者相同订单号（数据库非unique）。
你苦思冥想，终于想到了解决办法，我每天把明天要用的订单号先随机好，放进redis之类的缓存里里随用随取，这样就不会有性能和并发的问题了，回家发现老婆不在家，于是你开心的玩起了dota。
这里已经很接近订单池的概念了，不过因为这个池子没有流动性，就让我们暂且叫做订单桶吧，每天都要往桶里打水。
随着用户量的增长，你们决定在三月三号做一个"对3促销节"，你在办公室监视着服务器，突然老王用你家座机给你打电话，大兄弟你快看下，下不了单了，你熟练的连接上服务器查找着问题，发现生成的订单号已经被用完了，这一天的促销不得不停止。
于是你又连续加班了三个月，做了一个实时监控订单号熟练的系统，当低于xxxxx的时候迅速生成新的订单号，并且买了更多的服务器，做了更多的集群，可以同时预留出更多的订单号等等等等。
这就是现在订单池的概念，随着订单号的被消费还继续生成着订单号，这个涉及的内容就很复杂了。
以下设计规则摘录知乎：
http://www.zhihu.com/question/19805896#answer-31069940
从用户体验和数据库优化的角度来看
1.利用数据库主键值产生一个自增长的订单号（订单号即数据表的主键）
2.日期+自增长数字的订单号（比如：2012040110235662）
3.产生随机的订单号(65865325365966)
4.字母+数字字符串式，字母有包含特别意义，C02356652
5.订单号无重复性；
6.如果方便客服的话，最好是“日期+自增数”样式的订单号，客服一看便知道订单是否在退货保障期限内容；
7.订单号长度尽量保持短（10位以内），方便用户，尤其电话投诉时，长的号码报错几率高，影响客服效率；
8.订单号尽量保持数字型(纯整数)，在数据库订单索引查询中，长整数字型的数据索引与检索效率，远远高于文本型，因此尽量避免“字母+数字字符串式”！
作者：榜耶
网友评论