全局唯一ID
有些同学可能会有疑问，MySQL数据库本身就有自增长的主键，为什么还需要别的组件协助生成呢？
如果是单台MySQL数据库的话，当然是用本身的自增长序列就可以了，但是如果大家做了分库分表之后呢？比如用户表userTable数据量达到了4000万，单表有些吃力，大家将userTable拆成两张表保存到两个MySQL数据库中；这时候如果再使用数据库本身的自增序列，倒是也不会有错，每一个表内的主键不会重复，但是表和表比较的话，主键ID可能会发生重复；这时候就需要使用组件或者算法，生成全局唯一ID了。
MongoDBObjectId
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的系统（服务），会成为一个单点，在软件架构中，单独就意味着风险；如果这个服务出现问题，那么所有依赖于这个服务的系统都会崩溃掉。