全局唯一 ID
有些同学可能会有疑问,MySQL 数据库本身就有自增长的主键,为什么还需要别的组件协助生成呢?
如果是单台 MySQL 数据库的话,当然是用本身的自增长序列就可以了,但是如果大家做了分库分表之后呢?比如用户表 userTable 数据量达到了 4000 万,单表有些吃力,大家将 userTable 拆成两张表保存到两个 MySQL 数据库中;这时候如果再使用数据库本身的自增序列,倒是也不会有错,每一个表内的主键不会重复,但是表和表比较的话,主键 ID 可能会发生重复;这时候就需要使用组件或者算法,生成全局唯一 ID 了。
MongoDB ObjectId
MongoDB 的 ObjectId ,也是可以用于全局唯一 ID 的。
{“_id”: ObjectId(“5d47ca7528021724ac19f745”)}
MongoDB 的 ObjectId 共占 12 个字节,其中:
3.2 之前的版本(包括 3.2):4 字节时间戳 + 3 字节机器标识符(机器 ID) + 2 字节进程 ID + 3字节随机计数器;
3.2 之后版本:4 字节时间戳 + 5 字节随机值 + 3 字节递增计数器;
其中时间戳字节可以保证毫秒级唯一,节机器标识符考虑到了分布式,字节进程 ID 保证了同一台服务器运行多个实例时的唯一性,字节递增计数器保证了同一个时间点内 ID 的唯一性。
优缺点
不管是老版本还是新版本,MongoDB 的 ObjectId 至少都可以保证集群内的唯一,大家可以搭建一个全局唯一 ID 生成的服务,利用 MongoDB 生成 ObjectId 并对外提供服务(MongoDB 的各语言驱动都实现了 ObjectId 的生成算法)。
优点:MongoDB 的性能不错,可以使用集群部署,保证其高可用;ID 内自带一些含义,比如时间戳,必要的时候可以进行反解;
缺点:和数据库一样,需要引入对应的组件/软件,增加了系统的复杂度;最关键的是,这两种方案都意味着生成全局唯一 ID 的系统(服务),会成为一个单点,在软件架构中,单独就意味着风险;如果这个服务出现问题,那么所有依赖于这个服务的系统都会崩溃掉。
偶将持续分享Java开发、架构设计、程序员职业发展等方面的见解,希望能得到你的关注。
如果觉得《解析分布式主键MongoDB – 数据库 – 前端》对你有帮助,请点赞、收藏,并留下你的观点哦!