MongoDB ObjectID生成
在项目中需要用到一个随机数,将其作为唯一且无法重复,第一个想到的就是MongoDB里面的objectID,将其作为一个唯一且不重复的键值。
ObjectId是一个12字节的 BSON 类型字符串。按照字节顺序,一次代表:
- 4字节:UNIX时间戳
- 3字节:表示运行MongoDB的机器
- 2字节:表示生成此_id的进程
- 3字节:由一个随机数开始的计数器生成的值
1 | // machineId stores machine id generated once and used in subsequent calls |
MongoDB objectID改变
在golang的MongoDB官方库中,objectID的生成方式发生了改变。
1 | // "go.mongodb.org/mongo-driver/bson/primitive" |
可以看到这12字节,已改为,4字节unix时间戳+5字节随机值+随机值加上1。
查看官方文档也可以发现,其对objectID的定义已经更改。
- a 4-byte value representing the seconds since the Unix epoch,
- a 5-byte random value, and
- a 3-byte counter, starting with a random value.
只找到一篇博客对这个修改的推测,我也确实没有找到确切的修改理由,我认为博主说的有些道理。
引用自:Mongo ObjectId 早就不用机器标识和进程号了
mongo 的 C++ 源码中,设置 ObjectId 中间 5 个字节的函数叫
setInstanceUnique
,而在官方 golang 驱动中叫processUnique
,字面意思相近,都是说明这个值的作用是“区分不同进程实例”,而这个值具体怎么实现并没有什么要求,所以,使用“机器标识+进程号”来拿区分不同进程实例是可以的,使用互无关联的随机数来拿区分不同进程实例也是可以的。可想而知,“在同一秒内,两个进程实例产生了相同的 5 字节随机数,且刚巧这时候两个进程的自增计数器的值也是相同的”——这种情况发生的概率实在太低了,完全可以认为不可能发生,所以使用互无关联的随机数来拿区分不同进程实例是完全合乎需求的。
那问题来了,为什么不继续使用“机器标识+进程号”呢?主观臆测开始。
问题就在于,机器标识和进程号一定就那么可靠吗,尤其在这个物理机鲜见,虚拟机、云主机、容器横行的时代?
先说机器标识码,ObjectId 的机器标识码是取系统 hostname 哈希值的前几位,问题来了,想必在座的各位都有干过吧:准备了几台虚拟机,hostname 都是默认的 localhost,谁都想着这玩意儿能有什么用,还得刻意给不同机器起不同的 hostname?此外,hostname 在容器、云主机里一般默认就是随机数,也不会检查同一集群里是否有 hostname 重名。
再说进程号,这个问题就更大了,要知道,容器内的进程拥有自己独立的进程空间,在这个空间里只用它自己这一个进程(以及它的子进程),所以它的进程号永远都是 1。也就是说,如果某个服务(既可以是 mongo 实例也可以是 mongo 客户端)是使用容器部署的,无论部署多少个实例,在这个服务上生成的 ObjectId,第八第九个字节恒为
0000 0001
,相当于说这两个字节废了。综上,与其使用一个固定值来“区分不同进程实例”,且这个固定值还是人类随意设置或随机生成的 hostname 加上一个可能恒为 1 的进程号,倒不如每次都随机生成一个新值。
本文标题:MongoDB ObjectID生成
文章作者:小师
发布时间:2019-03-15
最后更新:2022-05-04
原始链接:chunlife.top/2019/03/15/MongoDB ObjectID生成/
版权声明:本站所有文章均采用知识共享署名4.0国际许可协议进行许可