各位现在常用 id 生成方案有哪些，使用策略是怎样的？

[tctc4869]

各位的数据存储的唯一 id 是在数据库直接自增生成，还是在服务端程序里生成的？

服务端程序里生成的 id，各位用的是哪个生成算法？雪花？雪花变种？还是 uuid ？或是其他？

还是数据库自增结合自己定制？（比如获得一个序列自增值，并合并指定数字字符串，并转成数字，再插入数据库）

我的话，其实如果能用数据库的自增序列，就用数据库的自增序列，毕竟使用简单。各位的 id 生成方案策略是怎样的呢，对于主键列，各位都是用数字 id 么？对于唯一约束的列，如果用到生成，各位会用数字 id，还是使用 uuid/guid ？

[opengps]

前两天有个 v 友发的全局 id 生成器，软文里包含各种 id 的用法和优缺点，你找找看看

[wujieyuan]

数据库自增,省事

[hemingway]

redis incrby

[jzmws]

雪花最香, mysql 下用数字主键性能相对最好 , 有一定顺序(针对同一个数据节点而言,不该初始化时间) , 保证数据安全(自增主键容易被猜到下一个数据是什么)

[wangritian]

雪花变种直接做的主键：毫秒时间戳+集群 id （从配置文件读取）+容器 id （ k8s 每次更新的容器 hostname 前缀做 key，用 redis 的 incr 获得）+进程 id+自增数（如果 1ms 内生成量大于上限，就 sleep 一下），凑够 char(16)
好处多多，外人从 id 看不到真实数据量，无法遍历采集，跨集群合并数据方便等等

[lizz666]

我也来学习学习，取取经

[magicnobob]

1. 时间戳+6 位序列

[sujin190]

@opengps #1 但是事实上说的全是错的，纯属啥不懂还瞎 BB

分布式 ID 大多都是 Client 本地生成，算法基本逻辑大多是一样的，看最终字节数吧，8 字节估计大部分情况都需要手动配置 clientID，也就是集权机器进程 ID，16 字节一般也就可以直接本地取信息自动生成了，除此之外很多情况下还有希望是直接数字时间，比如订单号这样比较容易给人看的，但是这样的话直接占了 14 字符了，所以很多时候还是需要依据自己业务量来适当调整的

[zzzmh]

这个我也不太懂，我们一般 int 的用数据库自增，string 的用 java uuid 或 mysql uuid

[keshawnvan]

自己实现了一款，现在生产环境在用
实现： https://github.com/KeshawnVan/Ray
介绍： https://juejin.im/post/5e9d402df265da48094da80d

[sirius1024]

MARK 一下，坐等最优解。

我用过的分布式，大部分都是 Client 标识+共享算法。

[cco]

美团、百度、滴滴都有基于雪花的 ID 生成器,看你的场景了,你要是趋势递增还不能被猜到,那就用美团的哪个吧

[opengps]

@sujin190 我没细读，前面传统 id 的优缺点还是没啥问题的，后面可能有错的，但还不至于说他全错

[egfegdfr]

非重要数据 id 自增。重要数据用的 mybatis-plus 带的 ID_WORKER,他是雪花的变种，纯数字，有序，比 uuid 要好。

[YAR]

sequence