大家好，我是为广大程序员兄弟操碎了心的小编，每天推荐一个小工具/源码，装满你的收藏夹，每天分享一个小技巧，让你轻松节省开发效率，实现不加班不熬夜不掉头发，是我的目标！
你是否烦恼过这些问题
- 作为架构设计的你，想要解决数据库主键唯一的问题，特别是在分布式系统多数据库的时候。
- 你希望这个主键是用最少的存储空间，索引速度更快，Select、Insert 和 Update 更迅速。
- 你要考虑在分库分表（合库合表）的时候，主键值可直接使用，并能反映业务时序。
- 如果这样的主键值太长，超过前端 JS Number 类型最大值，须把 Long 型转换为 String 型，你会觉得有点沮丧。
- 哪怕 Guid 能自增，但占用空间大，这也不是你想要的。
- 你的应用实例可能超过50个，每个并发请求可能达10W/s。
- 你希望系统能运行 100 年以上。
为了解决这个问题，今天小编推荐一种全新的雪花漂移算法——IdGenerator，让ID更短、生成速度更快。 核心在于缩短ID长度的同时，还能拥有极高瞬时并发处理量（50W/0.1s）。 顶尖优化，超强效能（位数更短，速度更快），全新 SnowFlake 算法，支持 C#/Java/Go/PHP 等语言。
开源协议
使用 MIT 开源许可协议
链接地址
传统算法问题
- 生成的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 瞬时处理速度。
结尾
本期就分享到这里，我是小编南风吹，专注分享好玩有趣、新奇、实用的开源项目及开发者工具、学习资源！希望能与大家共同学习交流。