Loading...
墨滴

阿东lazy

2021/12/12  阅读:24  主题:蔷薇紫

浅谈postgre-sql uuid生成方法的细节

浅谈postgre-sql uuid生成方法的细节

前言

    最近在工作中编写业务sql的时候,突然对于gen_random_uuid() 这个方法比较好奇,他在高并发的情况下是否拥有强一致性的特点(就是保证主键唯一性),趁着感兴趣研究了一波,发现有不少有意思的东西可以讨论,所以出了这篇文章来聊聊。

前提条件

我估计很多读者根本不知道postgreSql是啥玩意,个人起初接触这个数据库也很别扭,并且这个名字很难记,所以业内人士一般叫读这块数据库为:post-gres-s-q-l,个人比较习惯叫做 pg-sql,关于这一款数据个人认为几个比较突出的特点:

  1. 完全开源,基于社区维护,并且社区较为活跃。

  2. NoSQL :JSON,JSONB,XML,HStore原生支持,NoSQL数据库的外部数据包装器

  3. 自从mysql被甲骨文收购之后,mysql的原作者也有参与其中,可以看到不少mysql的影子,比如OLTP和MVCC的实现。

然而遗憾的是虽然postgresql看起来全面强于mysql但是不如mysql流行,并且mysql看上去是有很多令人诟病的历史遗留问题,但是依然不可否认他依然是现在的主流数据库。好了关于pg-sql这款数据库就唠叨到这里,今天的主题不是介绍这个数据库,所以我们来看下重点关于postgre-sql生成uuid的方法。

文章目的

    关于本文,我们将会讨论下面几个话题:

  • Gen_random_uuid()怎么来的?

PostgreSQL 13: 新增内置函数Gen_random_uuid()生成UUID数据,换句话说这个版本之前需要用手动的安装形式

  • uuid_generate_v4() 有没有可能重复?

答案是肯定的,哪怕是sql原始的gen_randowm_uuid方法也是存在重复的可能性的,但是存在某些“特殊条件”,下面来一起探讨一下原因。

  • 对比gen_randowm_uuid()函数和uuid_generate_v4函数的实现差异。

差异主要是生成随机数的方式上,其他工作基本一致。

1. Gen_random_uuid()怎么来的?

    如果postgre-sql的版本使用的是13之前,会抛出下面的问题:

function gen_random_uuid() does not exist

​ 如果想要能够使用此方法,需要使用如下的命令,也就是使用 pgcrypto :

CREATE EXTENSION pgcrypto;

​ 下面是postgresql-sql 12版本,会出现如下的提示。

# SELECT gen_random_uuid();
ERROR:  function gen_random_uuid() does not exist
LINE 1: select gen_random_uuid();
               ^
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.
# CREATE EXTENSION pgcrypto;
CREATE EXTENSION
# SELECT gen_random_uuid();
           gen_random_uuid            
--------------------------------------
 19a12b49-a57a-4f1e-8e66-152be08e6165
(1 row)

​ 但是需要注意的是13版本添加的并不是这个库,而是依赖于OSSP库的uuid函数。其实就是gen_random_uuid_v4()这个函数,下面我们来看下这个函数的介绍。

1.1 gen_random_uuid_v4()官方介绍

​ 函数有什么作用不必多说,下面是关于官方的介绍:

  We create a uuid_t object just once per session and re-use it for all  
  operations in this module.  OSSP UUID caches the system MAC address and  
  other state in this object.  Reusing the object has a number of benefits:  
 saving the cycles needed to fetch the system MAC address over and over,  
 reducing the amount of entropy we draw from /dev/urandom, and providing a  
 positive guarantee that successive generated V1-style UUIDs don't collide.  
 (On a machine fast enough to generate multiple UUIDs per microsecond,  
  or whatever the system's wall-clock resolution is, we'd otherwise risk  
  collisions whenever random initialization of the uuid_t's clock sequence  
  value chanced to produce duplicates.) 

​ 如果看不懂,下面是谷歌翻译之后的介绍:

我们每个会话只创建一个 uuid_t 对象,并为所有人重新使用它本模块中的操作。 OSSP UUID 缓存系统 MAC 地址和此对象中的其他状态。 
重用对象有很多好处:
1. 节省一遍又一遍地获取系统 MAC 地址所需的周期,
2. 减少我们从 /dev/urandom 中提取的熵量,并提供一个积极保证连续生成的 V1 风格的 UUID 不会发生冲突。
(在足够快的机器上每微秒生成多个 UUID,或者无论系统的时钟分辨率是多少,否则我们会冒险
每当随机初始化 uuid_t 的时钟序列时发生冲突值机会产生重复。)

​ 翻译之后发现依然比较拗口,个人其实也看不懂,所以这里又找了一篇文章,下面简单说明一下这篇文章的内容和含义。

参考文章:Is Postgres's uuid_generate_v4 securely random?

​ 问题:这位老哥的大致问题就是他使用了postgresql v4版本的uuid() 来生成一个access token的密钥令牌,并且询问是否线程安全(uuid是否唯一),以及是否需要使用应用端保证唯一性,这正好符合这篇文章的主题。

​ 下面是分析之后的个人总结出来的答案(每个人理解能力不同,不一定完全正确):

  1. 首先,uuid_generate_v4 依赖uuid-ossp这个库,并且13版本的postgres的uuid是依赖此实现的。

  2. OSSP(版本1.6.2)源代码表明,该代码在类Unix系统(Windows上的CryptGenRandom())上使用**/dev/urandom** ,以及基于当前时间、进程ID的可靠性较差的PRNG,和 C 库 rand() 函数,但是对于这三个结果使用了异或操作,可以极大避免重复,使用 /dev/urandom 足以保证强随机性

  3. 但是如果/dev/urandom因为某些原因失败(例如,该进程当时已用完可用文件描述符),则库将回退到仅使用弱 PRNG ,而不会发出警告 ,这就很恐怖了,这样随机性和可能性大大提高,如果此时出现并发使用同一个时钟节点。

​ 总结来说就是,基于上面三个点,虽然uuid-ossp在通常情况下可以保证强唯一性,但是存在退化为弱唯一性的可能性,甚至最坏的情况是使用机器的时钟点来生成uuid造成重复uuid,所以这位答主最终的建议是:谨慎建议不要依赖 PostgreSQL 生成的 UUID 的强随机性,而是在应用程序端明确使用强随机源

有读者会问PRNG是啥?伪随机数生成器 (pseudo random number generator,PRNG ),又被称为确定性随机比特生成器 (deterministic random bit generator,DRBG ),[1]是一个生成数字序列的算法,其特性近似于随机数序列的特性。PRNG生成的序列并不是真随机,因此它完全由一个初始值决定,这个初始值被称为PRNG的随机种子(seed,但这个种子可能包含真随机数)。尽管接近于真随机的序列可以通过硬件随机数生成器生成,但伪随机数生成器因为其生成速度和可再现的优势,在实践中也很重要。[2]

话外题:其实很多的策略游戏就是用了伪随机数的算法。

1.2 小结

​ 通过上面的铺垫,我们大致了解了uuid_generate_v4() 的基本实现,下面我们来进行一个简单的总结。

​ 产生情况:

  1. 如果机器在同一个微秒产生多个uuid就会出现重复的情况,并且**/dev/urandom** 失效的时候。

  2. 没有定义HAVE_UUID_OSSP,则需要调用操作系统的uuid_generate_time或uuid_generate_random来产生UUID。

  3. 绝大多数情况下如果仅仅只是需要一个随机数的生成函数,官方更加建议使用pgcrypto的gen_random_uuid()。

2. 对比gen_random_uuid()uuid_generate_v4()

​ 没错,这个也是参考文章的,并且对比了很多资料发现下面这个答案简洁明了:

参考文章:PostgreSQL 生成 UUID 的两种不同方式:gen_random_uuid 与 uuid_generate_v4s

首先是关于这两个函数的直接区别:

  • gen_random_uuid()扩展提供pgcrypto

  • uuid_generate_v4()扩展提供uuid-ossp

从这篇参考文章得出的根本结论就是:

  • uuid_generate_v4() 使用 arc4random 来确定随机部分。

  • gen_random_uuid() 使用fortuna代替实现。

​ 关于这两个算法区别这里就不再进行展开了,有条件的可以看一下下面的维基的链接介绍,如果访问不了也可以自行上网查阅资料,都是一些比较理论化的东西,这里就不再继续深入追究了。

参考文章:https://en.wikipedia.org/wiki/RC4#RC4-based_random_number_generators

总结

    用这篇文章其实是想告诉各位,对待数据库的uuid生成方法需要结合实际的业务是否需要保证uuid的强唯一性,如果需要则强烈建议不要依赖数据库的实现方式,特别是在并发量十分高的情况下,是十分不可靠的。

​ 最后如果发现有任何错误欢迎指正。

扩展阅读

1. 如何创建一个适合PostgreSQL中会话ID的随机字符串?

阿东lazy

2021/12/12  阅读:24  主题:蔷薇紫

作者介绍

阿东lazy