数据库的主键策略

生成数据库的ID有很多中方法,常见的有基于数据的自增ID,PostgreSQL,Oracle 可以有sequence,MySQL可以使用auto_increment。在系统并发量不大的情况下,这些都是可行的办法。但是如果并发量比较大,数据库很快会成为整个系统的瓶颈。

另外,有时候我们希望主键只是渐进递增,并不是逐个递增,比如订单表。

关于主键数据类型的选择

字符串和UUID不适合用作主键。

字符串和UUID的缺点是占用空进大,索引效率低。正常情况下使用Long只有8个字节,如果数据库不支持UUID的存储方式则要中用32字节,这是一笔不小的开销。

同时,UUID不可描述,除了作为唯一标识,没有任何意义,类似于:’02500d31-7900-448c-b88d-5bacb11dfce3’,看不出表达什么。

UUID的一个优点就是比较容易水平拆分,因为这些键全部是业务无关的。

所以,应该优先选择整型作为数据库的主键。

但是,在选择整型作为主键之前,应该先估算数据的规模,根据数据的规模确定整型的长度。

在PostgreSQL数据库中,每钟类型的属性如下:

类型 长度 表示范围
smallint 2 bytes -32768 to +32767
integer 4 bytes -2147483648 to +2147483647
bigint 8 bytes -9223372036854775808 to +9223372036854775807

如果要存储世界的人口,那么使用integer类型是不合适的,此时可以考虑使用bigint。

就算每秒写入1000W条数据,Long类型也可以支持接近30000年,这已经够用了。

Long类型在性能和存储之间取得了平衡,往往是分布式系统首选的主键类型。

主键的生成策略

主键的生成策略有多种,目前没有一种绝对完美的方案,需要根绝业务的类型来选择。

1. 使用数据库自增ID

数据库递增的ID只能做到单表递增,做不到全局唯一。对于一些小型的应用来讲,这不会有什么问题。

数据库自增ID的缺陷是,无法在写入数据之前获得数据的ID,必须要在提交数据库之后才会返回ID。还有就是ID的产生依赖于数据库,可能会降低数据库的性能。并且,不可以后续分库分表。

2. 使用集中的ID生成策略

也就是专门提供一个服务用于批量生成ID。可以使用Redis的INCR,或者使用Zookeeper或者关系数据库也可以。这种方式最大的缺陷是又引入一个外部系统,依赖外部系统又带来新的不稳定性,并且实现起来也比较复杂。

3. 使用Twitter开源的Snowflake算法

使用Long类型,可以考虑使用Snowflake算法。

Snowflake是一种:时间戳+机器标识+自增序列的方式实现全局唯一ID。这种算法的好处是没有引入外部服务,没有网络调用的开销,安全高效。

这种方式生成的ID是渐进有序,并不是逐个递增。

Snowflake

第一位是符号位,不使用。

这里的时间戳是毫秒级别的,所以换算成秒需要乘以1000。

余下63位:前面41为作为时间戳,可以表示大概不到70年的时间;余下10位可以作为机器标识,可以表示1024台机器;剩下12位是自增序列,理论上单台机器在1ms内可以产生4096个ID。

但是,需要注意的是,如果前端应用是JavaScript的话,是有可能面临丢失精度的问题,因为在JavaScript中,Number基本类型可以精确表示的最大整数是 2^53,如果用Number来存储Snowflake生成的ID肯定是不行的(虽然JavaScript引入来BigInt,但是目前来看还不成熟)。

针对这种情况,目前有两种解决方案:

  1. 后端应用在序列化的时候,把整型转化成字符串,这种方式简单直接,直接配置一下代码即可;

  2. 修改一下Snowflake算法,使用更小的时间戳:使用32位的秒级时间戳+5位的机器标识+16位自增。这样可以容纳32台机器,每秒可以生成6.5W个序列号。对于一个中型互联网公司足够用了。

Snowflake算法需要注意的问题:

需要注意CPU时钟回拨的问题, 这个主要是由于闰秒的原因。

如果按照原子钟来算,每一秒的绝对时间都是相等的,我们可以把这个叫作原子时间。但是地球的每一天自传的长度并不是相等的,大概平均每日会增加1.7ms。所以为了是原子钟的时间和地球自转的时间对齐,就有了闰秒的概念。

为什么会产生闰秒:是因为每一个太阳日的时间不是相等的,这就造成每一天每一秒的长度是不等的。但是我们计时的原子钟的时间每一秒都是相等的。如果没有闰秒来调节时间,这两个时间的差距会越来越大。

这种情况下给我们编程带来的问题就是调节时间是不确定的,我们没有办法规避。

避免这种情况的一个办法就是,如果一个业务不是时间特别敏感,我们最好关闭时钟同步。

4. 其它基于Snowflake的衍生算法

百度(uid-generator)

和Snowflake不同的是,调整了一下各个部位的长度。

workId,占用了22个bit位,时间占用了28个bit位,序列化占用了13个bit位。

同时,时间单位变成了秒,而不是毫秒。

美团(Leaf)& 滴滴的(Tinyid)

这两种,都是在Snowflake的基础上,添加了数据库或者zookeeper依赖,来管理ID的分配,比较适合他们自己的业务特点。

根据业务的类型,确定适当的主键策略

在一些访问并发量和数据量并不是特别大的表上,使用数据库递增的策略也是可取的。甚至说没有必要使用Long作为主键的类型。

我个人认为,Snowflake算法设计的非常漂亮,其它的衍生算法都带来一定程度的复杂性。虽然也解决来他们业务上的问题,但是我感觉不够漂亮。

Snowflake算法的正确性是基于时间只能往前,不能后退的假设。这个假设在绝大多数时候都是成立的


【参考连接】

闰秒
分布式唯一ID生成器
分布式唯一 ID 解析
百度UidGenerator
万亿级调用系统:微信序列号生成器架构设计及演变
UUID or GUID as Primary Keys? Be Careful!
tinyid
Leaf——美团点评分布式ID生成系统
百度uid-generator源码解析
分布式唯一 ID 之 Snowflake 算法


  • 2020.02.19 初稿
  • 2020.07.26 修改 完成PPT

发表评论

电子邮件地址不会被公开。 必填项已用*标注