业务ID 生成规则

在实际业务中，是否碰到过这种场景：

我们需要一个单号，要在业务系统里面保证唯一，保证增长？

在运营过程，需要知道业务单发生的时间，最好不用经过系统查找就知道发生的时间？

在排障过程中，不用再次查找就知道，订单的一些信息？

业务ID 经常需要生成以方便后续跟踪使用。一般需要满足以下特性：

1. 唯一性

2. 可阅读

3. 增长

4. 数字类型？

5. 其他信息(payload)

所以，业务ID的生成，这里涉及两个问题：

1. ID 的规则，也就是ID 最终长什么样，满足什么约束

2. ID 生成策略

比如，一个常见的订单号生成规则可能如下：{yyyyMMddHHmm}[0-9][0-9]{4}

这个规则满足了以下约束：

1. 17位数字， 数据库存储可以用BIGINT 存储， 各系统接口可以使用Long 类型交互

2. 可以阅读， 通过{yyyyMMddHHmm} 快速的知道订单的创建时间

3. 可以猜测类型， 如中间的[0-9],支持10种类型， 这个数据丰富信息，可不存。

4. 支持的最大并发在每分钟10000，在系统确实有每分钟10000个订单，这个单号生成策略就够了

当然，上述订单号规则，只是一种实例，不过对大多数小系统足够了。即便是这样，上述规则，也有一些缺陷。

比如Long 范围的限定情况下， 使用了类似string 的 拼接技术，未能充分使用Long的范围。

如果ID 规则，不用太多考虑可读性的话， 可以像设计序列化协议一样，设计的更为紧凑，以容纳更多信息， 比如Long 有64bit，可以按照bit 长度划分成若干段。

现实中，有很多系统为了单号的可读性，经常会超出Long的最大值，所以设计为 NChar(128) 也比较常见。