我都快无语了……

1楼 @tinyfool 咋的了、 为啥无语？是问题太简单么？

根据日期加几位的数字序列不行吗

日期后再跟一个10位自增数字呗（例如20150920xxxxxxxxxx），或者日期时间之后再跟个6位（例如201509201357xxxxxx）

3楼 @zhiyuan 嗯、那具体的几位数字是什么数字呢？

4楼 @rothcold 那我每次生成订单时要查下现在数据库中的10位自增数字到了哪里了是不是？并发的时候可以么？

6楼 @tolerious 这个时候你就需要借助一些工具了比如Redis

不建议用自增数字，容易被穷举。建议日期时间加随机数。

订单号的生成，看你如何考虑了。

简单的方式： orderId就是一个唯一识别，如果没有特别的含义。那么就是自增生成就行。至于说被猜到，那就看对业务的影响。是否允许任何人根据orderId查询订单，通过业务来判断。

复杂的方式： 由于系统订单数据越来越多，那么最终你需要做数据库的分布式存储。这样的话，订单号就可以有很多的含义在里面了。 例如：（如果使用关系数据库存储）分布式后，数据分表分库，那么通过订单号能找到订单的准确位置，这就很重要了。单纯的自增可能就不是很好的方案了。因此可以这样考虑： orderId=[yyyyMMDDhhmmss][商户id后4位][自增序列6位]

如果主要是通过商户分区，那么就能根据商户的id信息来找到数据的位置。如果数据越来越多，大量的历史数据需要迁移，例如3个月前的所有订单可以放到备份库中，那么就可以根据时间来定位数据的位置，因此联合起来就能知道orderId能在哪里查到数据

8楼 @caipanjin 嗯、

9楼 @akwei 自增序列是6位的是否就是随机的6位、还是说是递增的6位呢？

11楼 @tolerious 从 1----- 999999 的循环递增 ，在分布式的环境下，可以考虑使用独立的id服务来做唯一生成.保证位数固定，位数固定主要是为了方便解析，获得有用的信息

如果需要无序的，uuid就最好了，这也是tinytool无语的地方，如果需要有点规律可以方便查找，用时间+uuid的四段中的第一段，够你用了。

13楼 @damon uuid当然知道的、但是你让顾客看到那么丑陋的py uuid你觉得合适么？ 我觉得没什么无语不无语的、如果觉得简单直接给出答案即可、没必要是这种讥讽的语气、呵呵、

uuid 不适合做单号，建议把时间打上去，交易类型最好也有，有一段是用来做随机的，分布式一定要一台单独的服务保证唯一性。你可以使用一些数据库的特性保证唯一。比如redis的incry生成一个base。

订单号是订单号流水号是流水号 , 订单号可以用自增的 ,流水号通过订单号 +日期+业务类型+随机数 自己制定规则混淆即可 .....这样用户看着不会恶心 自己程序使用也方便...