业务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) 也比较常见。