还在用数据库自增ID做主键?建议了解一下雪花算法生成的分布式ID

473 阅读5分钟

开启掘金成长之旅!这是我参与「掘金日新计划 · 12 月更文挑战」的第1天,点击查看活动详情。

前言

随着业务的发展,单一数据库的自增ID已经不能满足我们的需求,使用全局唯一ID的场景必然会出现,比如海量的订单号,档案号等等。我们初始可能会选择使用36位的UUID,配合机器id和时间戳,基本可以满足需求。

但是UUID的缺点也很明显,由于其完全无序,对MySQL的B+树结构特别不友好。另外UUID的长度也会造成数据库索引空间的浪费。

由此产生的需求

  1. 全局唯一:不能重复,这是最基本的要求。
  2. 趋势递增:生成的ID是有序递增的,这样数据库存储索引数据时可以保证写入性能。
  3. 信息安全:生成的ID不能是简单连续递增的,必须是大致递增。如果是连续的,那么恶意用户可以很简单地爬取我们的数据;而对于订单号这种敏感的数据,竞争对手更是可以轻松推算出我们一天的单量。

解决方案:雪花算法

雪花算法(Snowflake)是Twitter开源的一种生成分布式全局唯一ID的算法,产生的背景是为了满足Twitter每秒上万条消息的请求,这些消息为了不重复必须有一个全局唯一的ID,并且还需要有大致的顺序,以满足存储性能要求及客户端排序。

其默认生成结果是一个64bit的long型数值,组成部分包含时间戳,并且保持了大致递增。

雪花算法核心结构

如图所示,组成一共包含4个部分:

  1. 不使用:1bit,最高位bit默认为0,不使用;
  2. 时间戳:41bit,毫秒级的时间戳,可以支持该算法使用到2082年;建议使用64位Linux系统机器,通过vdso,gettimeofday()在用户态就可以完成操作,减少了进入内核态的损耗。
  3. 机器标识:10bit可以支持1024台机器,通常会将其拆分为两部分,5bit代表数据中心ID,5bit代表工作机器ID。
  4. 序列号:12bit递增序列号,就是一系列的自增id,每秒最多生成4096个不重复的ID。

通过这4部分,雪花算法可以在1秒内生成约409万个ID,已经基本满足绝大部分的业务需求。

由于雪花算法生成的ID是大致递增的,非常契合MySQL中B+树的结构,应用到数据库的主键时,可以极大的提升插入效率。

另外由于其是大致递增,而不是顺序递增,直接将生成结果作为如订单号这样的业务字段也没问题,可以保证第三方无法推断出真实的订单量。

雪花算法生成ID重复的问题及解决方案

虽然雪花算法通过不同的组成尽量避免了ID重复,但是在某些极限情况下,依然无法排除ID重复的发生。

  • 情况1:时钟回拨,雪花算法强依赖机器时钟,如果机器上时钟回拨,会造成发号重复。
  • 情况2:在某一毫秒内,某些节点上的机器标识一致,并且产生了同一个序列号。

针对情况1,我们可以维护一个上次生产ID的时间戳lastTimestamp,每次发号后更新lastTimestamp,发号前则对比当前时间戳和lastTimestamp,当前时间戳比lastTimestamp小,就强制等待两者时间差后再发号,但这会造成发号服务处于不可用的状态。

针对情况2,既然时间戳和序列号我们无法保证不重复,那就从机器标识下手。只要机器标识不重复,生成的ID自然也不会重复了。如果我们的项目部署是机器级别,即一台机器上部署一套服务,那以机器MAC地址作为机器标识就可以。如果是进程级别,即一台机器上部署多套相同的服务,仅仅是PID不同,这种情况下可以通过引入Redis、Zookeeper或者MySQL来保证机器标识位的唯一性。

国内开源的分布式ID框架

对于雪花算法可能重复的问题,国内也有一些开源的框架作为替代,比如MT的leaf、BD的Uid。

总得来说,雪花算法已经可以满足绝大部分场景,如果没有十分必要的话,还是不建议引入开源方案,毕竟会大大增加我们系统的复杂度。

总结

本文主要讲解了什么是雪花算法,雪花算法适用的场景以及如何解决雪花算法冲突的问题。

当然雪花算法也不是万能的,不能适用所有的场景,建议大家根据实际的业务进行评估,然后选择合适的方案。

学习技术,分享技术,期待与大家共同进步,也感谢您的点赞与关注。