1
0
mirror of synced 2026-04-17 22:08:39 +08:00
Files
SnowFlake-IdGenerator/README.md
2021-04-05 19:15:13 +08:00

222 lines
9.8 KiB
Markdown
Raw Blame History

This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 比雪花算法更好用的ID生成算法单机或分布式唯一ID
## 💎 算法介绍
<font color="#11aaff" size="5">❄</font> 一个全新的雪花漂移算法生成的ID更短、速度更快。
<font color="#11aaff" size="5">❄</font> 核心在于缩短ID长度的同时具有极高瞬时并发处理量保守值 50W/0.1s)。
<font color="#11aaff" size="5">❄</font> 原生支持 C#/Java/Go/Rust/C 等语言,并由 Rust 提供 PHP、Python、Node.js、Ruby 等语言多线程安全调用库(FFI)。如果你的应用有语言开发,基于本算法提供的逻辑实现,集成会更简单,逻辑会更一致。
<font color="#11aaff" size="5">❄</font> 支持 k8s 等容器化部署,自动注册 WorkerId。
<font color="#11aaff" size="5">❄</font> 可在单机或分布式环境中生成唯一ID。
<font color="#11aaff" size="5">❄</font> 这是计算机历史上最全面的唯一ID生成器未来会超越自己。目前我还没其它发现更好的或许你可以😀
## 💎 技术支持
开源地址1https://gitee.com/yitter/idgenerator
开源地址2https://github.com/yitter/idgenerator
QQ群646049993
## 需求来源
<font color="green" size="5">💧</font> 作为架构设计的你,想要解决数据库主键唯一的问题,特别是在分布式系统多数据库的时候。
<font color="green" size="5">💧</font> 你希望这个主键是用最少的存储空间索引速度更快Select、Insert 和 Update 更迅速。
<font color="green" size="5">💧</font> 你要考虑在分库分表(合库合表)时,主键值可直接使用,并能反映业务时序。
<font color="green" size="5">💧</font> 如果这样的主键值太长,超过前端 JS Number 类型最大值,须把 Long 型转换为 String 型,你会觉得有点沮丧。
<font color="green" size="5">💧</font> 尽管 Guid 能自增,但占用空间大,索引速度慢,你也不想用它。
<font color="green" size="5">💧</font> 应用实例可能超过50个每个并发请求可达10W/s。
<font color="green" size="5">💧</font> 在容器环境部署应用(水平扩展、自动伸缩)。
<font color="green" size="5">💧</font> 不想依赖 redis 的自增操作。
<font color="green" size="5">💧</font> 你希望系统运行 100 年以上。
## 传统算法问题
❌ 生成的ID太长。
❌ 瞬时并发量不够。
❌ 不能解决时间回拨问题。
❌ 不支持后补生成前序ID。
❌ 依赖外部存储系统。
## 新算法特点
<font color="green" size="5">✔</font> 整形数字随时间单调递增不一定连续长度更短用50年都不会超过 js Number类型最大值。默认配置 WorkerId 是6bit自增数是6bit
<font color="green" size="5">✔</font> 速度更快是传统雪花算法的2-5倍0.1秒可生成50万个。i7笔记本默认算法配置6bit+6bit
<font color="green" size="5">✔</font> 支持时间回拨处理。比如服务器时间回拨1秒本算法能自动适应生成临界时间的唯一ID。
<font color="green" size="5">✔</font> 支持手工插入新ID。当业务需要在历史时间生成新ID时用本算法的预留位能生成5000个每秒。
<font color="green" size="5">✔</font> 漂移时能外发通知事件。让调用方确切知道算法漂移记录Log并发调用量。
<font color="green" size="5">✔</font> 不依赖任何外部缓存和数据库。k8s环境下自动注册 WorkerId 的动态库依赖 redis
<font color="green" size="5">✔</font> 基础功能,开箱即用,无需配置文件、数据库连接等。
## 性能数据
(参数10位自增序列1000次漂移最大值)
| 连续请求量 | 5K | 5W | 50W |
| ---- | ---- | ---- | ---- |
| 传统雪花算法 | 0.0045s | 0.053s | 0.556s |
| 雪花漂移算法 | 0.0015s | 0.012s | 0.113s |
💍 极致性能500W/s~3000W/s。所有测试数据均基于8代低压i7计算。
## 适用范围
🔷小型、中型、大型需要全局唯一Id不用Guid的项目。
🔷 单机或分布式项目。
🔷不想将 Long 型转 String 给前端用的项目。
## 如何处理时间回拨
🔶 当发生系统时间回拨时算法采用过去时序的预留序数生成新的ID。
🔶 回拨生成的ID序号默认靠前也可以调整为靠后。
🔶 允许时间回拨至本算法预设基数(参数可调)。
## 💎 配置参数
<font color="#11aaff" size="5">❄</font> WorkerIdBitLength决定 WorkerId 的最大值。
<font color="#11aaff" size="5">❄</font> SeqBitLength决定每毫秒生成的 ID 个数。
<font color="#11aaff" size="5">❄</font> WorkerIdBitLength + SeqBitLength 不能超过 22。
<font color="#11aaff" size="5">❄</font> WorkerId最大值 2^WorkerIdBitLength-1。
<font color="#11aaff" size="5">❄</font> 默认配置值:
```
WorkerIdBitLength = 6
SeqBitLength = 6
```
## 💎 关于ID
本算法生成的 ID 是一串整数最多8字节。
🟣 ID示例基于默认配置
```
129053495681099 (本算法运行1年)
387750301904971 (运行3年)
646093214093387 (运行5年)
1292658282840139 (运行10年)
9007199254740992 (js Number 最大值)
165399880288699493 (普通雪花算法生成的ID)
```
🟣 本算法生成的 ID 值,是 js Number 最大值的 1%-10%,是普通雪花算法值的千分之一,而计算能力却超过普通雪花算法。
🟣 js Number 类型最大数值9007199254740992本算法在保持并发性能5W+/0.01s和最大64个 WorkerId6bit的同时能用70年才到 js Number Max 值。
### 长度估算
```
💍 每增加 1位 WorkerIdBitLength 或 SeqBitLength生成的ID数字值将会乘以2基础长度可参考前“ID示例”反之则除以2。
```
### 能用多久
🔵 在默认配置下ID可用 71000 年不重复。
🔵 在支持 1024 个工作节点时ID可用 4480 年不重复。
🔵 在支持 4096 个工作节点时ID可用 1120 年不重复。
## 💎 常规集成
1⃣ 用单例模式调用。外部集成方使用更多的实例并行调用本算法不会增加ID产出效能因为本算法采用单线程模式生成ID。
2⃣ 指定唯一的 WorkerId。必须由外部系统确保 WorkerId 的全局唯一性,并赋值给本算法入口方法。
3⃣ 单机多实例部署时使用不同 WorkerId。并非所有实现都支持跨进程的并发唯一保险起见在同一主机上部署多应用实例时请确保各 WorkerId 唯一。
4⃣ 异常处理。算法会抛出所有 Exception外部系统应 catch 异常并做好应对处理,以免引发更大的系统崩溃。
5⃣ 认真理解 IdGeneratorOptions 的定义,这对集成和使用本算法有帮助。
6⃣ 使用雪花漂移算法。虽然代码里包含了传统雪花算法的定义并且你可以在入口处指定Method=2来启用传统算法但仍建议你使用雪花漂移算法Method=1默认的毕竟它具有更好的伸缩力和更高的性能。
7⃣ 不要修改核心算法。本算法内部参数较多,逻辑较为复杂,在你尚未掌握核心逻辑时,请勿尝试修改核心代码且用于生产环境,除非通过大量细致、科学的测试验证。
## 💎 配置变更
配置变更指是系统运行一段时间后再变更运行参数IdGeneratorOptions选项值请注意
🔴 1.最重要的一条原则是BaseTime **只能往前**(比老值更小、距离现在更远)赋值,原因是往后赋值极大可能产生相同的时间戳。[**不推荐**在系统运行之后调整 BaseTime]
🔴 2.任何时候增加 WorkerIdBitLength 或 SeqBitLength都是可以的但是慎用 “减小”的操作,因为这可能导致在未来某天生成的 ID 与过去老配置时相同。[允许在系统运行之后**增加**任何一个 BitLength 值]
🔴 3.如果必须减小 WorkerIdBitLength 或 SeqBitLength 其中的一项,一定要满足一个条件:新的两个 BitLength 之和要大于 老的值之和。[**不推荐**在运行之后缩小任何一个 BitLength 值]
🔴 4.上述3条规则并未在本算法内做逻辑控制集成方应根据上述规则做好影响评估确认无误后再实施配置变更。
## 自动注册WorkerId
🔍 唯一ID生成器依赖WorkerId当业务服务需要水平自动化复制时就要求它能自动化注册全局唯一WorkerId然后各个容器化的无差别部署的业务服务才能根据它生产唯一ID。
🔍 本算法提供一个开源的动态库go语言实现能在容器 k8s或其它容器化集群 环境下,通过 redis 自动注册 WorkerId。动态库提供的C接口方法可参考
源码文件 [ Tools/AutoRegisterWorkerId/lib/yitidgengo.h ]
redis作用
🔎 在集成“自动注册WorkerId”功能时用于注册 WorkerId ,不用于生产 ID。
## 💎 代码示例
🌲🏳️‍🌈 C#[查看示例][1]
🌲🏳️‍🌈 Java[查看示例][2]
🌲🏳️‍🌈 Go[查看示例][3]
🌲🏳️‍🌈 Rust[查看示例][4]
🌲🏳️‍🌈 C[查看示例][5]
🌲🏳️‍🌈 Vlang[查看示例][6]
如果你有其它语言的实现需求,不妨试着自己写一个,或者给我留言。
[1]: https://gitee.com/yitter/idgenerator/tree/master/C%23.NET
[2]: https://gitee.com/yitter/idgenerator/tree/master/Java
[3]: https://gitee.com/yitter/idgenerator/tree/master/Go
[4]: https://gitee.com/yitter/idgenerator/tree/master/Rust
[5]: https://gitee.com/yitter/idgenerator/tree/master/C
[6]: https://gitee.com/yitter/idgenerator/tree/master/ZeOthers/Vlang