Dotnet3.0下SnowFlake算法生成53位ID

世界上没有两片雪花是完全相同的。

为了满足Twitter每秒上万条消息的请求,每条消息都必须分配一条唯一的ID,这些id还需要一些大致的顺序(方便客户端排序),并且在分布式系统中不同机器产生的ID必须不同。Twitter公司提出了一种名为SnowFlake算法来生成唯一的ID作为系统中的key。

为何需要生成ID?

在应用程序中,经常需要全局唯一的ID作为数据库中表主键。如何生成全局唯一ID?

首先,需要确定全局唯一ID是整型还是字符串?如果是字符串,那么现有的UUID就完全满足需求,不需要额外的工作。缺点是字符串作为ID占用空间大,索引效率比整型低。

通常情况下,我们都会使用数据库的自增主键功能,从1开始,基本可以做到连续递增。Oracle可以用SEQUENCE,MySQL可以用表主键的AUTO_INCREMENT, 虽然不能保证全局唯一,但每个表唯一,也基本满足需求。

但是这样的做法有两个问题,第一个是每次生成都是先要插入数据库,让数据库去生成这个ID后返回。当需要插入关联数据的时候,必须先等数据库插入成功,然后才能插入关联数据。如果插入过程比较长,需要用队列操作的时候,就无法将相关操作放入队列做异步处理。第二个是生成的ID是连续的,很多ID是用于用户号,订单号等敏感信息,网站外部用户可以根据特定时间之间生成的ID差值来估算出业务量。

因此,可以在插入数据库之前,就先用Twitter提出的雪花算法,生成ID后再作为主键插入数据库。

SnowFlake算法

SnowFlake算法生成id的结果是一个64bit大小的整数,它的结构如下图:

Dotnet3.0下SnowFlake算法生成53位ID

  • 1位,不用。二进制中最高位为1的都是负数,但是我们生成的id一般都使用整数,所以这个最高位固定是0
  • 41位,用来记录时间戳(毫秒)。

    41位可以表示2^{41}-1个数字,

    如果只用来表示正整数(计算机中正数包含0),可以表示的数值范围是:0 至 2^{41}-1,减1是因为可表示的数值范围是从0开始算的,而不是1。

也就是说41位可以表示2^{41}-1个毫秒的值,转化成单位年则是(2^{41}-1) / (1000 60 60 24 365) = 69年

  • 10位,用来记录工作机器id。

    可以部署在2^{10} = 1024个节点,包括5位datacenterId和5位workerId

    5位(bit)可以表示的最大正整数是2^{5}-1 = 31,即可以用0、1、2、3、....31这32个数字,来表示不同的datecenterId或workerId。严格来说,应该每个进程都需要不同的workId。

  • 12位,序列号,用来记录同毫秒内产生的不同id。

    12位(bit)可以表示的最大正整数是2^{12}-1 = 4095,即可以用0、1、2、3、....4094这4095个数字,来表示同一机器同一时间截(毫秒)内产生的4095个ID序号。
    

SnowFlake算法生成53位长度整数

如果直接用网上的SnowFlake算法库生成的64位长度整数,在作为主键传递到Web前端的时候,就会碰到一个大坑。JavaScript里面没有64位整数,只有一种Number数据类型表示数字,采用IEEE754格式来表示数字,不区分整数和浮点数,JavaScript中的所有数字都用浮点数值表示,最大的数字精度只有53位,超过这个位数,JavaScript将丢失精度。因此,使用53位整数可以直接由JavaScript读取,而超过53位时,就必须转换成字符串才能保证JavaScript处理正确,这会给API接口带来额外的复杂度。

因此我根据网上的代码,做了一些修改,用c#语言改写SnowFlake算法生成53位长度整数。方法就是保留41位时间戳,加上2位机器编号,10位序列号组成一个53位的ID。对于小型的项目,4个生成器也够用了,每毫秒最多可以生成1024个序列号也足够满足使用。

源代码以MIT协议的方式开源,托管到github

Dotnet3.0下SnowFlake算法生成53位ID

上一篇:数据结构与算法:线性表(下)


下一篇:关于全局ID,雪花(snowflake)算法的说明