mysql全局查询,解析分布式主键MongoDB_数据库

资料来源：网络整理时间：2023/3/5 12:44:51 共计：3597 浏览

mysql全局查询，解析分布式主键MongoDB？

可以的。

全局唯一 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开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。

版权说明：
本网站凡注明“广州京杭原创”的皆为本站原创文章，如需转载请注明出处！
本网转载皆注明出处，遵循行业规范，如发现作品内容版权或其它问题的，请与我们联系处理！
欢迎扫描右侧微信二维码与我们联系。

·上一条：mysql 查询引号,mysql存的字段是数值_数据库 | ·下一条：mysql查询序号,如何将数据库中查询出来的数据再进行分页操作_数据库