关于生成订单号规则的一些思考

关于我为什么写这篇文章是因为今天在做订单模块的时候,看到之前的PRD上描述的订单生成规则是由 年月日＋用户id2位+企业id位
＋四位自增长数。然后竟被我反驳的突然改成了精确时间＋4位自增长数，于是我更失望了。

我们考虑一下，据我所常见的订单基本都14-20位。(年月日时分秒和随机数)基本上就有14位了。虽然一般项目做不到淘宝双11这种
支付峰值达到每秒10万笔订单.但是我觉得至少事先可以考虑到，想必当初淘宝或许也没意识到以后发展
得这么好。

背景

为了达到业务订单的生成。我觉得要至少要符合以下这三种,
1. 全局唯一
2. 一定不能重复

在复杂的分布式系统中，很多场景需要的都是全局唯一ID的场景，一般为了防止冲突可以考虑的有36
位的UUID,twitter的snowflake等。

但是可以思考这些问题？
1. 是不是应该有一些其他意义的思考，比如说订单系统有买家的id(取固定几位)
2. 是否有商品的标识,方便熟悉业务的排查问题或者查询也通过不去系统查找可以有个初步的认识，但是业务量大的话感觉就可以排除这个人为的去辨识了。
3. 个人的看法是主要是唯一，其他关于业务方面的不是太太重要。

查阅了相关资料，主要有以下这几种

1. UUID, 组成：当前日期+时间+时钟序列+机器识别号（Mac地址或其他）没有mac网卡的话会有别的东西识别。
   在分布式系统中，所有元素（WEB服务器）都不需要通过中央控制端来判断数据唯一性。几十年之内可以达到全球唯一性。
   snowflake的结构如下(每部分用-分开):

2. Mysql通过AUTO_INCREMENT实现、Oracle通过Sequence序列实现。
   在数据库集群环境下，不同数据库节点可设置不同起步值、相同步长来实现集群下生产全局唯一、递增ID

3. Snowflake算法 雪花算法　
   41位时间戳+10位机器ID+12位序列号（自增） 转化长度为18位的长整型。
   Twitter为满足美秒上万条消息的创建，且ID需要趋势递增，方便客户端排序。
   Snowflake虽然有同步锁，但是比uuid效率高。

4. Redis自增ID
   实现了incr(key)用于将key的值递增1，并返回结果。如果key不存在，创建默认并赋值为0。 具有原子性，保证在并发的时候。

但是我在这主要想说的是雪花算法生成id,至于为什么，就测试了一下其他的，感觉这种生成方式个人比较喜欢。

Snowflake算法
规则如下

使用41bit作为毫秒数，10bit作为机器的ID（5个bit是数据中心，5个bit的机器ID），12bit作为毫秒内的流水号（意味着每个节点在每毫秒可以产生 4096 个 ID），最后还有一个符号位，永远是0。

0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000

该算法实现基本是二进制操作。

一共加起来刚好64位，为一个Long型。(转换成字符串长度为18)

snowflake生成的ID整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞（由datacenter和workerId作区分），并且效率较高。据说：snowflake每秒能够产生26万个ID。

以下是代码
部分借鉴与网络
100万个ID 耗时２秒