参考

https://zhuanlan.zhihu.com/p/107939861

UUID

优点：

  • 生成足够简单，本地生成无网络消耗，具有唯一性

缺点：

  • 无序的字符串，不具备趋势自增特性
  • 没有具体的业务含义
  • 长度过长 16 字节 128 位，36 位长度的字符串，存储以及查询对 MySQL 的性能消耗较大，MySQL 官方明确建议主键要尽量越短越好，作为数据库主键 UUID 的无序性会导致数据位置频繁变动，严重影响性能

数据库自增 ID

优点：

  • 实现简单，ID 单调自增，数值类型查询速度快

缺点：

  • DB 单点存在宕机风险，无法扛住高并发场景

数据库多主模式

优点：

  • 解决 DB 单点问题

缺点：

  • 不利于后续扩容，而且实际上单个数据库自身压力还是大，依旧无法满足高并发场景

基于数据库的号段模式

号段模式是当下分布式 ID 生成器的主流实现方式之一，号段模式可以理解为从数据库批量的获取自增 ID，每次从数据库取出一个号段范围，例如 (1,1000] 代表 1000 个 ID，具体的业务服务将本号段，生成 1~1000 的自增 ID 并加载到内存

Redis

Redis 也同样可以实现，原理就是利用 redis 的 incr 命令实现 ID 的原子性自增

1
2
3
4
127.0.0.1:6379> set seq_id 1     // 初始化自增ID为1
OK
127.0.0.1:6379> incr seq_id      // 增加1，并返回递增后的数值
(integer) 2

用 redis 实现需要注意一点，要考虑到 redis 持久化的问题。redis 有两种持久化方式 RDB 和 AOF

  • RDB 会定时打一个快照进行持久化，假如连续自增但 redis 没及时持久化，而这会 Redis 挂掉了，重启 Redis 后会出现 ID 重复的情况。
  • AOF 会对每条写命令进行持久化，即使 Redis 挂掉了也不会出现 ID 重复的情况，但由于 incr 命令的特殊性，会导致 Redis 重启恢复的数据时间过长。

雪花算法（SnowFlake）

滴滴出品（TinyID）

百度 （Uidgenerator）

美团（Leaf）