别再傻乎乎地用主键递增的方式设计数据库了

大家好，我是为广大程序员兄弟操碎了心的小编，每天推荐一个小工具/源码，装满你的收藏夹，每天分享一个小技巧，让你轻松节省开发效率，实现不加班不熬夜不掉头发，是我的目标！

你是否烦恼过这些问题

作为架构设计的你，想要解决数据库主键唯一的问题，特别是在分布式系统多数据库的时候。
你希望这个主键是用最少的存储空间，索引速度更快，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导航站】。