分布式系统主键生成策略

分布式系统主键生成策略

本篇文章主要是针对于平时我们会遇到的一个问题，主键的相关生成策略做出简单介绍。数据库主键，指的是一个列或多列的组合，其值能唯一地标识表中的每一行，通过它可强制表的实体完整性。主键主要是用与其他表的外键关联，以及本记录的修改与删除。下面我将以 Id 为例，简单介绍几种我所知道的主键生成策略。

数据库自增 这种方法比较简单，在设计数据表时给字段设置自动增长 AUTO_INCREMNTA即可，这种方式利用了数据库系统自身的一些功能就可以实现 缺点：强依赖DB，当DB异常时整个系统不可用；还有个问题是分库分表操作时，就不是很友好 以上图为例，假设我们将数据放在三张表中，第二张和第三张表都需要知道上一张表的最后一个值，在这个基础上+1

UUID UUID(Universally Unique Identifier)的标准型式包含32个16进制数字，以连字号分为五段，形式为8-4-4-4-12的36个字符，每次生成随机的唯一的值 与第一种方式相比，这种方式无需关注上一张表，但他生成的值比较长，不易储存，信息也不太安全，随机生成也无法进行排序操作

Redis 生成 Id 假如一个集群中有5台Redis。可以初始化每台Redis的值分别是1,2,3,4,5，然后步长都是5。各个Redis生成的ID为： A：1，6，11，16，21 B：2，7，12，17，22 C：3，8，13，18，23 D：4，9，14，19，24 E：5，10，15，20，25 这种方法较前面相比就很灵活，不需要依赖于数据库，生成的 Id 也是排了序的，但这种方法需要引入组件，增加了一定的编码和配置的工作量

Twitter 的 snowflake 算法 mp自带策略 雪花算法 核心：使用41bit作为毫秒数，10bit作为机器的ID（5个bit是数据中心，5个bit的机器ID），12bit作为毫秒内的流水号（意味着每个节点在每毫秒可以产生 4096 个 ID），最后还有一个符号位，永远是0，每次生成唯一的值

如何改变主键策略 以 Id 为主键为例

@TableId(type = IdType.AUTO) private Integer id; //在主键的属性上面加注解 @TableId

AUTO：自动增长 INPUT：自己来设定id值 NONE：没有设定值，也需要自己来输入 UUID：随机唯一值 ｍｐ自带的策略 ID_WORKER，ID_WORKER_STR， @TableId(type = IdType.ID_WORKER)//mp自带策略，生成19位，数字类型使用，比如Long，int @TableId(type = IdType.ID_WORKER_STR)//mp自带策略，生成19位，字符串使用，比如String

以上就是本篇文章的主要内容，除了上述的几种方法之外，主键生成策略还有 UUID 的变种，利用zookeeper 生成唯一Id，MongoDB 的ObjectId 等方法，有需要的可以去了解