分布式ID

2021-06-20 00:32:12   35  举报





分布式ID是一种在分布式系统中生成唯一标识符的方法。它能够保证在多个节点、多个系统之间生成的ID是唯一且递增的，以满足数据的一致性和完整性要求。常见的分布式ID生成算法有雪花算法（Snowflake）和全局唯一标识符（GUID）。雪花算法通过时间戳、机器ID和序列号的组合来生成唯一的ID，具有高效、稳定和可扩展等优点。而GUID则通过随机数和时间戳的组合来生成唯一的ID，具有简单易用的特点。分布式ID在微服务架构、分布式数据库等场景中广泛应用，能够解决单点系统中ID重复、并发冲突等问题，提高系统的可靠性和稳定性。

分布式ID算法

分布式ID

作者其他创作

大纲/内容

号段模式

uid-generator是基于Snowflake算法实现的，与原始的snowflake算法不同在于，uid-generator支持自定义时间戳、工作机器ID和序列号等各部分的位数，而且uid-generator中采用用户自定义workId的生成策略。uid-generator需要与数据库配合使用，需要新增一个WORKER_NODE表。当应用启动时会向数据库表中去插入一条数据，插入成功后返回的自增ID就是该机器的workId数据由host，port组成。uid-generator ID组成结构：workId占用了22个bit位，时间占用了28个bit位，序列化占用了13个bit位，需要注意的是，和原始的snowflake不太一样，时间的单位是秒，而不是毫秒，workId也不一样，而且同一应用每次重启就会消费一个workId。默认分配方式如下： sign(1bit)：固定1bit符号标识，即生成的UID为正数。 delta seconds (28 bits)：当前时间，相对于时间基点\"2016-05-20\"的增量值，单位：秒，最多可支持约8.7年（注意：1. 这里的单位是秒，而不是毫秒！ 2.注意这里的用词，是“最多”可支持8.7年，为什么是“最多”，后面会讲） worker id (22 bits)：机器id，最多可支持约420w次机器启动。内置实现为在启动时由数据库分配，默认分配策略为用后即弃，后续可提供复用策略。 sequence (13 bits)：每秒下的并发序列，13 bits可支持每秒8192个并发。（注意下这个地方，默认支持qps最大为8192个）由百度技术部开发，开源项目链接：https://github.com/baidu/uid-generator

UUID数据库自增ID数据库多主模式号段模式Redis雪花算法（SnowFlake）百度（Uidgenerator）美团（Leaf）滴滴出品（TinyID）

总结

UUID

Uidgenerator

雪花算法

数据库多主模式

可以发现，常用的分布式唯一ID生成思路基本是利用一个长串数字或字符串，将其分割成多个部分，分别记录时间信息、机器/名字信息、随机信息、序列信息等。时间信息部分决定了该策略能使用的时长，机器/名字信息支持了分布式环境下的独自生成唯一ID与识别能力，序列信息保证了事件的顺序记录以及同一时间单位下的并发数，而随机信息则加大了ID整体的不可识别性。实际上如果现有的方法依然不能满足，我们完全可以依据自身业务和发展需求，来自行决定使用何种策略生成唯一ID。各种方案都有其优缺点，技术的使用没有绝对的好坏之分，主要在于是否适合使用场景： 1）要求生成全局唯一且不会重复ID，不关心顺序 —— 使用基于时间的UUID（如游戏聊天室中不同用户的身份ID） 2）要求生成唯一ID，具有名称不可变性，可重复生成 —— 使用基于名称哈希的UUID（如基于不可变信息生成的用户ID，若不小心删除，仍可根据信息重新生成同一ID） 3）要求生成有序且自然增长的ID —— 使用数据库自增ID（如各业务操作流水ID，高并发下可参考优化方案） 4）要求生成数值型无序定长ID —— 使用雪花算法（如对存储空间、查询效率、传输数据量等有较高要求的场景）

数据库自增ID

由滴滴开发，开源项目链接：https://github.com/didi/tinyidTinyid是在美团（Leaf）的leaf-segment算法基础上升级而来，不仅支持了数据库多主节点模式，还提供了tinyid-client客户端的接入方式，使用起来更加方便。但和美团（Leaf）不同的是，Tinyid只支持号段一种模式不支持雪花模式。Tinyid提供了两种调用方式，一种基于Tinyid-server提供的http方式，另一种Tinyid-client客户端方式。span style=\"font-size: inherit;\

/** * @ClassName: UUID_Id * @Author: 99847 * @Description: * @Date: 2021/6/19 18:00 * @Version: 1.0 */public class UUID_Id { public static void main(String[] args) { // 版本4，使用随机性或伪随机性生成。 String id = UUID.randomUUID().toString(); System.out.println(id); System.out.println(id.replace(\"-\

单点数据库方式存在很明显的性能问题，可以对数据库进行高可用优化，搭建数据库集群模式; 担心一个主节点挂掉没法用，可以选择做双主模式集群，也就是两个Mysql实例都能单独的生产自增ID。解决方案：数据库水平拆分，设置不同的初始值和相同的步长(解决自增ID都从1开始)优点：解决DB单点问题缺点：不利于后续扩容，而且实际上单个数据库自身压力还是大，依旧无法满足高并发场景。

TinyID

生成策略概述

利用Redis的 incr 命令实现ID的原子性自增。注意要考虑redis持久化的问题，AOF可以实现对每条写命令进行持久化，即使Redis挂掉了也不会出现ID重复的情况。由于incr命令的特殊性，会导致Redis重启恢复的数据时间过长。

九大分布式ID生成策略