MongoDB的ObjectId生成原理

在分布式系统中，分布式 ID 有很多特殊的要求，其中两个要求 各个 ID 必须全局唯一，且 ID 能够趋势递增。

• mongo插入一条记录

db.xttblog.insert({"name":"张三","age":88,"url":"www.xttblog.com"})

插入成功： Inserted 1 record(s) in 64ms

• 查询

db.getCollection('xttblog').find({})

查询结果多出了一个_id，它是 ObjectId 类型。它是一个 24 位的字符串：60c468e6101bf215dc9fa835

实际上它是由一组十六进制的字符构成，每个字节(byte)占两位的十六进制数字，总共用了 12 字节的存储空间。相比 MYSQL int 类型的 4 个字节，MongoDB 的主键_id确实多出了很多字节

• 4 字节的 timestamp
  timestamp 就是时间戳。将刚才生成的 ObjectId 的前 4 位进行提取“60c468e6”，然后按照十六进制转为十进制，变为1623484646，这个数字就是一个时间戳，精确到秒

• Machine
  ObjectId 规范中，还描述了，有一个占 3 个字节的 Machine(机器)。也就是说，字符串60c468e6101bf215dc9fa835中的第 9 到 15 位，101bf2这三个字节是所在主机的唯一标识符，一般是机器主机名的散列值，这样就确保了不同主机生成不同的机器的 hash 值，确保在分布式中不造成冲突，这也就是说在同一台机器生成的 ObjectId 中间（第9到15位）的字符串都是一模一样的原因。

• PID
  规范中中还描述了，还有两个字节的 process id(进程 ID)。上面的 Machine 是为了确保在不同机器产生的 ObjectId 不冲突，而 pid 就是为了在同一台机器不同的 mongodb 进程中产生的 ObjectId 不冲突。那么接着截取 4 位字符，15dc就是产生 ObjectId 的进程标识符。
  实际上，你也可以把这个 16 进制的字符串15dc转换成 10 进制，然后在机器上通过 ps 命令看看，mongodb 的进程 pid 是不是相同的。

• INC
  规范中还描述了，最后 3 字节是 counter，也就是通过 INC 自增计数器实现的。前面的九个字节是保证了一秒内不同机器不同进程生成 ObjectId 不冲突，最后面的这三个字节9fa835是一个自动增加的计数器，用来确保在同一秒内产生的 ObjectId 也不会发生冲突，允许 256 的 3 次方等于 16777216 条记录的唯一性。也就是说每秒钟可以产生 16777216 个 ID，足够我们使用了，如果还不够，我们可以分机器，分集群。或者让客户端产生 ObjectId

ObjectId 的前 4 个字节时间戳，记录了文档创建的时间；接下来 3 个字节代表了所在主机的唯一标识符，确定了不同主机间产生不同的 ObjectId；后 2 个字节的进程 id，决定了在同一台机器下，不同 mongodb 进程产生不同的 ObjectId；最后通过 3 个字节的自增计数器，确保同一秒内产生 ObjectId 的唯一性。

ObjectId 的这个主键生成策略，很好地解决了在分布式环境下高并发情况主键唯一性问题，非常值得我们学习和借鉴。