从唯一序列码、单例模式到集群的思考

唯一序列码

在做实际业务开发中，不定时需要用到序列号的生成，要求为唯一序列码。

在实际的实现过程中，我常用的是两种方式：1、数据库自增序列；2：随机序列

1、数据库自增序列

如果是采用了mysql数据库，使用自带的数据库自增序列是非常方便的。

对于Oracle,由于ORACLE没有自增字段，可以考虑以下几种方式：

1、单独查询ID，每次插入逻辑自增（小白方法，容易理解）

2、每张表设计sequences，每次获取序列值插入（进阶）

3、使用sequences+trigger来实现主键字段的自增。（最好）

但数据库数据序列是按照一定的整数进行新增，删除数据时会导致ID数据自增序列断开。

2、随机序列

随机序列包含时间戳、随机数、哈希函数、uuid、guid、复合键、序列号与随机数结合

时间戳：

• 使用当前时间（年、月、日、时、分、秒、毫秒）生成一个唯一的序列号。例如，202407181030。

随机数：

• 生成一个随机数，确保在一定范围内不会重复。可以使用伪随机数生成器或加密安全的随机数生成器。

哈希函数：

• 将某些数据（如用户ID、时间戳等）通过哈希函数（如SHA-256）处理，生成一个固定长度的唯一哈希值。

uuid

• uuid在日常中常常作为一个工具类来显示的在代码中调用，非常方便清晰。但uuid生成是无规则的，无法作为主键进行排序，以及查找。

guid

• GUID（Globally Unique Identifier）实际上与UUID（Universally Unique Identifier）是同一种概念的不同叫法。GUID这个词主要是在微软的技术领域中使用的，而在其他技术社区，如Linux或开源软件社区，则更多地使用UUID这一术语。两者都指的是一种标准的唯一标识符，用于在计算机系统中生成全球唯一的标识符。

复合键

• 将多个字段组合成一个复合键，确保每个组合是唯一的。类似于数据库中的联合主键。

序列号与随机数结合

• 将序列号与随机数结合，生成一个既有顺序又有随机性的唯一序列码。

Snowflake算法

• 雪花算法最初由Twitter开发，用于生成短的、全局唯一的ID。雪花算法生成的ID具有良好的时间顺序性，并且在存储和索引方面表现更佳，因为它是一个简单的整数。

单例模式与序列号

针对某些业务，需要由一定的规则+序号生成一个唯一的编码（A+1），序号要求自增。

在这种业务背景下，第一想到的是，使用一个单例模式类、管理整个业务唯一码的生成。在单例类中，可以自定义唯一码的复杂的处理逻辑，避开数据库自增序列、uuid等缺点。该单例类，可抽象细化综合成一个更加复杂的编码系统，单独建立服务，管理整个公司、所有系统序号的生成。

编码系统：

• 使用特定的编码规则，如邮政编码、车牌号等，生成唯一标识。

集群与序列号

当系统扩展到集群时，使用单例来管理序列号，每个节点都将存在一个单例，单例之间不会存在互斥，所以将会出现序号重复的情况的，这将无法满足唯一码的要求。

两种解决办法：

1、单例中序列号增加机器号进行区分，比如Snowflake算法

2、使用一个单独的服务提供序列号的生成。集群中所有机器都访问这个服务来获取序列号，生成唯一码。比如编码系统服务，基于Redis的序列号.

单独的服务提供序列号的生成

基于对单独服务的理解，我们很容易想到数据库。数据库（包括内存数据库，关系数据库）本身对外就是一个标准的单例式服务。

故此，很多地方和项目，都自发的采用了redis这种高效快速的内存数据库，可以使用INCR或INCRBY命令来递增一个键的值，从而生成序列号，对外提供序列号的管理。

若不想在项目里引入新的中间件，针对关系数据本身就存在一个Sequence,专用序列的管理和生成。

复杂的，真多很多，不同类型、长度、字段等序列号的生成，还可以通过关系数据表,redis高速序列，形成一个Resful API服务，通过网络接口，实现对序列号的管理和生成。

结语

实际项目里关于序列号生成、更多还需考虑效率、引入中间件、代码复杂度、唯一码的业务要求、进行综合考虑。

UUID：适用于需要高安全性和无需中心化管理的场景。

雪花ID：适用于需要高性能、低延迟和较小存储开销的场景。

基于Redis的序列号：适用于需要简单、快速并且在Redis中进行集中管理的场景。