共计 1554 个字符，预计需要花费 4 分钟才能阅读完成。
大家好，我是为宽广程序员兄弟操碎了心的小编，每天举荐一个小工具 / 源码，装满你的收藏夹，每天分享一个小技巧，让你轻松节俭开发效率，实现不加班不熬夜不掉头发，是我的指标！
你是否懊恼过这些问题
- 作为架构设计的你，想要解决数据库主键惟一的问题，特地是在分布式系统多数据库的时候。
- 你心愿这个主键是用起码的存储空间，索引速度更快，Select、Insert 和 Update 更迅速。
- 你要思考在分库分表（合库合表）的时候，主键值可间接应用，并能反映业务时序。
- 如果这样的主键值太长，超过前端 JS Number 类型最大值，须把 Long 型转换为 String 型，你会感觉有点丧气。
- 哪怕 Guid 能自增，但占用空间大，这也不是你想要的。
- 你的利用实例可能超过 50 个，每个并发申请可能达 10W/s。
- 你心愿零碎能运行 100 年以上。
为了解决这个问题，明天小编举荐一种全新的雪花漂移算法——IdGenerator，让 ID 更短、生成速度更快。外围在于缩短 ID 长度的同时，还能领有极高刹时并发处理量（50W/0.1s）。顶尖优化，超强效力（位数更短，速度更快），全新 SnowFlake 算法，反对 C#/Java/Go/PHP 等语言。
开源协定
应用 MIT 开源许可协定
链接地址
公众号【Github 导航站】回复关键词【idg】获取 git 地址
传统算法问题
- 生成的 ID 太长。
- 刹时并发量不够。
- 不能解决工夫回拨问题。
- 不反对后补生成前序 ID。
- 依赖内部存储系统。
新算法特点
- 整形数字，随工夫枯燥递增（不肯定间断），长度更短，用 50 年都不会超过 js Number 类型最大值。（默认配置 WorkerId 是 6bit，自增数是 6bit）
- 速度更快，是传统雪花算法的 2 - 5 倍，0.1 秒可生成 50 万个。（i7 笔记本，默认算法配置 6bit+6bit）
- 反对工夫回拨解决。比方服务器工夫回拨 1 秒，本算法能主动适应生成临界工夫的惟一 ID。
- 反对手工插入新 ID。当业务须要在历史工夫生成新 ID 时，用本算法的预留位能生成 5000 个每秒。
- 漂移时能外发告诉事件。让调用方确切晓得算法漂移记录，Log 并发调用量。
- 不依赖任何内部缓存和数据库。（但 WorkerId 必须由内部指定）
性能数据
(参数：10 位自增序列，1000 次漂移最大值)
成果
- js Number 类型最大数值：9007199254740992，本算法在放弃并发性能（5W+/0.01s）和最大 64 个 WorkerId（6bit）的同时，能用 70 年才到 js Number Max 值。
- 减少 WorkerId 位数到 8bit（256 节点）时，15 年达到 js Number Max 值。
- 极致性能：500W/1s。
- 所有测试数据均基于 8 代低压 i7 计算。
“我”是什么
- 本算法是一个类库，它基于 net standard2.0 根底库，不依赖任何第三方组件。
- 本算法不依赖任何内部数据系统（除了要被指定 WorkerId 之外）。
适用范围
- 小型、中型、大型须要全局惟一 Id（不必 Guid）的我的项目。
- 分布式我的项目。
- 不想将 Long 型转 String 给前端用的我的项目。（若前端反对 bigint，则可不转类型）
如何解决工夫回拨
- 当产生零碎工夫回拨时，算法采纳过来时序的预留序数生成新的 ID。
- 默认每秒生成 100 个（速度可调整）。
- 回拨生成的 ID 序号，默认靠前，也能够调整为靠后。
- 许工夫回拨至本算法预设基数（参数可调）。
能用多久
- 在默认配置下，ID 可用 71000 年不反复。
- 在反对 1024 个工作节点时，ID 可用 4480 年不反复。
- 在反对 4096 个工作节点时，ID 可用 1120 年不反复。
- 以上所有工作节点，均领有 50W/0.1s 刹时处理速度。
结尾
本期就分享到这里，我是小编南风吹，专一分享好玩乏味、离奇、实用的开源我的项目及开发者工具、学习资源！心愿能与大家独特学习交换，欢送关注我的公众号 【Github 导航站】。
正文完