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

唯一序列码

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

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

如果是采用了mysql数据库，使用自带的数据库自增序列是非常方便的。但数据库数据序列是按照一定的整数进行新增，删除数据时会导致ID数据自增序列断开。

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

单例模式与序列号

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

在这种业务背景下，第一想到的是，使用一个单例模式类、管理整个业务唯一码的生成。在单例类中，可以自定义唯一码的复杂的处理逻辑，避开数据库自增序列、uuid等缺点。

集群与序列号

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

两种解决办法：

1、单例中序列号增加机器号进行区分

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

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

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

故此，很多地方和项目，都自发的采用了redis这种高效快速的内存数据库，维护一个序列号键值，对外提供序列号的管理。

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

复杂的，真多很多，不同类型、长度、字段等序列号的生成，还可以通过关系数据表，形成一个web服务，通过页面配置，后台逻辑，就可以在不关心数据库底层的方式，实现对序列号的管理和生成。

结语

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

若无特别需求，直接使用UUID肯定是方便而简单的。