|
|
51CTO旗下网站
|
|
移动端

认识“雪花ID”:如何在分布式环境中大规模生成唯一ID?

唯一的ID使开发人员能够正确识别、保存和检索数据对象,并使数据对象参与到复杂的关系模式中。

作者:佚名来源:读芯术|2020-07-21 11:35

认识“雪花ID”:如何在分布式环境中大规模生成唯一ID?

图源:unsplash

唯一的ID使开发人员能够正确识别、保存和检索数据对象,并使数据对象参与到复杂的关系模式中。在应用程序开发周期中,程序员总会遇到要处理生成唯一的标识符这项任务。

这些独特的ID是如何生成的呢?哪种方法在不同的负载规模下最有效?ID如何在多个计算节点竞争下一个可用ID的分布式环境中保持唯一性?从小型单节点,到Twitter级别,本文笔者就将介绍三种最常见的技术。

通用唯一标识符——UUID

通用唯一标识符(UUID)这个概念大家不会陌生,它在软件中已经使用多年了。它是一个128位的数字,以受控和标准化的方式生成时,能够提供非常大的键空间,几乎消除了冲突的可能性。

UUID是由几个不同部分组成的合成ID,例如时间、节点的MAC地址或MD5散列的命名空间。为了适应所有这些组合,多年来,UUID规格已经发展出多个版本,特别是版本1和版本4。

根据数据和业务域的不同,一些开发人员可能会对其他版本感兴趣。处理128位数字并不是最适合开发人员描述信息的方式,因此UUID通常以规范文本形式表示,其中16个八位字节转换为32个十六进制字符,用连字符分隔,总共36个字符:

认识“雪花ID”:如何在分布式环境中大规模生成唯一ID?

UUID样本-版本4

UUID最有趣的特性是其可以单独生成,且仍能保证在分布式环境中的唯一性。基本的ID生成算法并不复杂,也不需要任何同步(至少是低至100纳秒级别),可以并行执行:

认识“雪花ID”:如何在分布式环境中大规模生成唯一ID?

分布式环境中生成唯一ID

能够自生成唯一性的内在属性,使得UUID成为分布式环境中最常用的ID生成技术之一。但UUID需要额外的存储空间,这可能会对查询性能产生负面影响。

持久层生成的ID

如果不想在应用程序级别生成唯一ID时,另一种常见的方法是用永续性储存体来处理。

最近所有的RDBMS都提供了某种列数据类型,开发人员能够委托它们生成唯一标识符。MongoDB提供ObjectID,MySQL和MariaDB提供AUTO_INCREMENT,MS-SQL-Server提供IDENTITY,等等。执行不同的数据库,ID的实际表现会有所不同,但唯一性的含义保持不变。

持久层生成的ID缓解了必须在应用程序代码中生成唯一ID的问题。但如果操作一个大型数据库集群,且有非常繁忙的应用程序在前,这种方法可能就无法满足需要了。

还有另一个问题:如果不往返数据库,则生成的ID对于代码来说是未知的:

认识“雪花ID”:如何在分布式环境中大规模生成唯一ID?

RDBMS vs代码生成ID

上图中,额外往返于RDBMS可能会减慢应用程序的速度,可能使代码不必要地复杂化。然而,无论使用的是否是基础RDBMS产品,现代ORM框架都有助于以标准化的方式完成这项工作。

ID服务器还是Snowflake ID

ID服务器负责为分布式基础设施生成唯一的ID。根据ID服务器执行功能的不同,可以是创建ID的单个服务器,也可以是每秒创建大量ID的服务器集群。

Twitter就不用我介绍了吧,平均每秒有9000条推特产生,峰值高达每秒143199条。Twitter需要一个解决方案,扩大其庞大服务器基础设施的规模,生成高效的存储ID。

认识“雪花ID”:如何在分布式环境中大规模生成唯一ID?

图源:unsplash

这就是Twitter推出Snowflake计划的原因:Snowflake是一种能大规模生成唯一ID号的网络服务,同时具备一些基础的保证。

Twitter之前使用过一种每个进程每秒至少生成10000个ID且响应速度小于2ms的服务器。ID服务器之间不需要任何网络协调,生成的ID应大致按时间顺序排列,为了将存储保持在最低限度,生成的ID必须紧凑。

为了解决上述项目,Twitter开发了Snowflake项目作为用Scala编写的Thrift服务器。生成的ID包括:

· 时间——41位(毫秒精度)

· 配置的机器ID——10位

· 序列号——12位(每台机器每4096转一次)

虽然现在Snowflake项目已经结束,以一个更广泛的项目TwitterServer取而代之,但是分布式ID生成器工作的基本原则仍然适用。由于每个生成器具有独立性,Twitter能够根据需要扩展其基础设施,不会产生由于集群同步和协调而造成额外的延迟。

使用ID服务器的解决方案与代码生成ID的运作方式类似:

认识“雪花ID”:如何在分布式环境中大规模生成唯一ID?

ID服务器生成ID

你会发现,其性能仍然会由于往返于ID服务器而降低,但因为不涉及复杂的数据库操作,这一额外的延迟比将对象刷新到RDBMS要短得多。ID服务器提供了一个中间解决方案,使开发人员能够控制生成唯一ID的方式与地点,无需引入复杂的、导致高延迟的基础设施。

对于最终需要保存数据的所有应用程序来说,生成唯一标识符都是必要步骤。本文讨论了三种常用的方法:UUID——本地生成ID,持久层驱动ID——集中创建ID,以及SnowflakeID——作为网络服务生成ID。

没有一劳永逸的解决方案。在应用程序中,选择生成唯一ID的方法需要考虑数据、持久性选项和网络基础设施等各个方面,这样才能挑到符合你需求和想法规模的方案。

【编辑推荐】

  1. 苹果宣布将弃用代码库中的非包容性语言
  2. 全栈工程师15年经验分享:40个改变编程技能的小技巧
  3. 谷歌推出免费的 Kotlin 和 Android 开发课程
  4. 防止删库悲剧发生,这里有个Bash脚本测试框架,危险代码一测便知
  5. 酷!GitHub开发者自制火星车,完整教程全面开源
【责任编辑:张燕妮 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

大数据安全运维实战

大数据安全运维实战

CDH+Ambari
共20章 | 大数据陈浩

86人订阅学习

实操案例:Jenkins持续交付和持续部署

实操案例:Jenkins持续交付和持续部署

微服务架构下的自动化部署
共18章 | freshman411

176人订阅学习

思科交换网络安全指南

思科交换网络安全指南

安全才能无忧
共5章 | 思科小牛

108人订阅学习

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微