❄ 雪花ID是走向分布式架构的垫脚石，如果只会Guid和数据库自增，怎敢说会分布式系统架构。
❄ 雪花ID适宜小项目、大项目、超级大项目。
本算法先容
❄ 这是优化的雪花算法（雪花漂移），它天生的ID更短、速率更快。
❄ 支持 k8s 等容器环境自动扩容（自动注册 WorkerId），可在单机或分布式环境天生数字型唯一ID。
❄ 原生支持 C#/Java/Go/Rust/C 等措辞，并供应 PHP 扩展及 Python、Node.js 多线程安全调用动态库（FFI）。
❄ 这是打算机历史上最全面的雪花ID天生器，期待你来超越
需求来源作为架构设计的你，想要办理数据库主键唯一的问题，特殊是在分布式系统多数据库中。
你希望数据表主键用最少的存储空间，索引速率更快，Select、Insert 和 Update 更迅速。
你要考虑在分库分表（合库合表）时，主键值可直策应用，并能反响业务时序。
如果这样的主键值太长，超过前端 js Number 类型最大值，须把 Long 型转换为 String 型，你会以为有点沮丧。
只管 Guid 能自增，但占用空间大，索引速率慢，你不想用它。
运用实例可能超过50个，每个并发要求可达10W/s。
要在容器环境支配运用，支持水平复制、自动扩容。
不想依赖 redis 的自增操作得到连续的主键ID，由于连续的ID存在业务数据安全风险。
你希望系统运行 100 年以上。
传统算法问题❌ 天生的ID太长。
❌ 瞬时并发量不足。
❌ 不能办理韶光回拨问题。
❌ 不支持后补天生前序ID。
❌ 可能依赖外部存储系统。
新算法特点✔ 整形数字，随韶光单调递增（不一定连续），长度更短，用50年都不会超过 js Number类型最大值。（默认配置）
✔ 速率更快，是传统雪花算法的2-5倍，0.1秒可天生50万个（基于8代低压i7）。
✔ 支持韶光回拨处理。比如做事器韶光回拨1秒，本算法能自动适应天生临界韶光的唯一ID。
✔ 支持手工插入新ID。当业务须要在历史韶光天生新ID时，用本算法的预留位能天生5000个每秒。
✔ 不依赖任何外部缓存和数据库。（k8s环境下自动注册 WorkerId 的动态库依赖 redis）
✔ 根本功能，开箱即用，无需配置文件、数据库连接等。
性能数据(参数：10位自增序列，1000次漂移最大值)
连续要求量
5K
5W
50W
传统雪花算法
0.0045s
0.053s
0.556s
雪花漂移算法
0.0015s
0.012s
0.113s
极致性能：500W/s~3000W/s。（所有测试数据均基于8代低压i7打算）
如何处理韶光回拨当发生系统韶光回拨时，算法采取过去时序的预留序数天生新的ID。
回拨天生的ID序号，默认靠前，也可以调度为靠后。
许可韶光回拨至本算法预设基数（参数可调）。
ID组成本算法天生的ID由3部分组成（沿用雪花算法定义）：+-------------------------+--------------+----------+| 1.相对根本韶光的韶光差 | 2.WorkerId | 3.序列数 |+-------------------------+--------------+----------+第1部分，韶光差，是天生ID时的系统韶光减去 BaseTime 的总韶光差（毫秒单位）。第2部分，WorkerId，是区分不同机器或不同运用的唯一ID，最大值由 WorkerIdBitLength（默认6）限定。第3部分，序列数，是每毫秒下的序列数，由参数中的 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个 WorkerId（6bit）的同时，能用70年才到 js Number Max 值。
长度估算 每增加 1位 WorkerIdBitLength 或 SeqBitLength，天生的ID数字值将会乘以2（根本长度可参考前一节“ID示例”），反之则除以2。能用多久
在默认配置下，ID可用 71000 年不重复。
在支持 1024 个事情节点时，ID可用 4480 年不重复。
在支持 4096 个事情节点时，ID可用 1120 年不重复。
参数设置❄ WorkerIdBitLength，机器码位长，决定 WorkerId 的最大值，默认值6，取值范围 [1, 19]，实际上有些措辞采取 无符号 ushort (uint16) 类型吸收该参数，以是最大值是16，如果是采取 有符号 short (int16)，则最大值为15。
❄ WorkerId，机器码，最主要参数，无默认值，必须 全局唯一，必须 程序设定，缺省条件（WorkerIdBitLength取默认值）时最大值63，理论最大值 2^WorkerIdBitLength-1（不同实现措辞可能会限定在 65535 或 32767，事理同 WorkerIdBitLength 规则）。不同机器或不同运用实例 不能相同，你可通过运用程序配置该值，也可通过调用外部做事获取值。针对自动注册WorkerId需求，本算法供应默认实现：通过 redis 自动注册 WorkerId 的动态库，详见“Tools\AutoRegisterWorkerId”。
❄ SeqBitLength，序列数位长，默认值6，取值范围 [3, 21]（建议不小于4），决定每毫秒根本天生的ID个数。规则哀求：WorkerIdBitLength + SeqBitLength 不超过 22。
❄ MinSeqNumber，最引言列数，默认值5，取值范围 [5, MaxSeqNumber]，每毫秒的前5个序列数对应编号0-4是保留位，个中1-4是韶光回拨相应预留位，0是手工新值预留位。
❄ MaxSeqNumber，最大序列数，设置范围 [MinSeqNumber, 2^SeqBitLength-1]，默认值0，真实最大序列数取最大值（2^SeqBitLength-1），不为0时，取其为真实最大序列数，一样平常无需设置，除非多机共享WorkerId分段天生ID（此时还要精确设置最引言列数）。
常规集成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。
通过redis注册WorkerId，并不是唯一的方法。你也可以自己开拓一个配置中央做事，各个运用做事启动时，通过配置中央获取唯一 WorkerId。
当然，如果你的做事不须要自动扩展，你就不必自动注册WorkerId，而是为每个运用手工设定一个唯一值。
自动注册流程图图片链接：https://gitee.com/yitter/idgenerator/blob/master/Tools/AutoRegisterWorkerId/regprocess.jpg
源码路径：/Go/source/regworkerid/reghelper.go
动态库下载下载链接：https://gitee.com/yitter/idgenerator/attach_files/662372/download/regworkerid_lib_v1.0.zip
动态库接口定义
// 注册一个 WorkerId，会先注销所有本机已注册的记录// ip: redis 做事器地址// port: redis 端口// password: redis 访问密码，可为空字符串“”// maxWorkerId: 最大 WorkerIdextern GoInt32 RegisterOne(char ip, GoInt32 port, char password, GoInt32 maxWorkerId);// 注销本机已注册的 WorkerIdextern void UnRegister();// 检讨本地WorkerId是否有效（0-有效，其它-无效）extern GoInt32 Validate(GoInt32 workerId);已实现的措辞措辞
github
gitee
C#
查看示例
查看示例
Java
查看示例
查看示例
Go
查看示例
查看示例
Rust
查看示例
查看示例
C
查看示例
查看示例
C (PHP扩展)
查看示例
查看示例
V
查看示例
查看示例
D
查看示例
查看示例
为什么不用大厂的？❄ 首先，大厂们不但自己用雪花ID，而且还开源：百度 | 美团 | 滴滴 | 雪花ID鼻祖-推特。
❄ 然而，大厂的雪花算法分为“经典算法”和“号段算法”两种，个中“号段算法”依赖网络或外部存储系统，不适宜“非大厂”，且存在无法反应业务时序的缺陷。
❄ 至于其“经典算法”，在“ID长度和天生性能”方面，未做过优化，而这正是本算法——雪花漂移算法的核心所在。
原文链接：https://my.oschina.net/u/3033246/blog/5015207?_from=gitee_search
如果以为本文对你有帮助，可以转发关注支持一下
