这是一个创建于 2119 天前的主题，其中的信息可能已经有所发展或是发生改变。
各位的数据存储的唯一 id 是在数据库直接自增生成，还是在服务端程序里生成的？
服务端程序里生成的 id，各位用的是哪个生成算法？雪花？雪花变种？还是 uuid ？或是其他？
还是数据库自增结合自己定制？（比如获得一个序列自增值，并合并指定数字字符串，并转成数字，再插入数据库）
我的话，其实如果能用数据库的自增序列，就用数据库的自增序列，毕竟使用简单。各位的 id 生成方案策略是怎样的呢，对于主键列，各位都是用数字 id 么？对于唯一约束的列，如果用到生成，各位会用数字 id，还是使用 uuid/guid ？
第 1 条附言 2020 年 7 月 6 日
对于.net 和 java 雪花算法有哪些比较好的实现？
 | 1 opengps 2020 年 7 月 6 日 via Android 前两天有个 v 友发的全局 id 生成器，软文里包含各种 id 的用法和优缺点，你找找看看 |
 | 2 wujieyuan 2020 年 7 月 6 日 数据库自增,省事 |
 | 3 hemingway 2020 年 7 月 6 日 via iPhone redis incrby |
 | 4 jzmws 2020 年 7 月 6 日 雪花最香, mysql 下用数字主键性能相对最好 , 有一定顺序(针对同一个数据节点而言,不该初始化时间) , 保证数据安全(自增主键容易被猜到下一个数据是什么) |
 | 5 wangritian 2020 年 7 月 6 日 雪花变种直接做的主键：毫秒时间戳+集群 id （从配置文件读取）+容器 id （ k8s 每次更新的容器 hostname 前缀做 key，用 redis 的 incr 获得）+进程 id+自增数（如果 1ms 内生成量大于上限，就 sleep 一下），凑够 char(16) 好处多多，外人从 id 看不到真实数据量，无法遍历采集，跨集群合并数据方便等等 |
 | 6 lizz666 2020 年 7 月 6 日 我也来学习学习，取取经 |
 | 7 magicnobob 2020 年 7 月 6 日 1. 时间戳+6 位序列 |
 | 8 sujin190 2020 年 7 月 6 日  1 @opengps #1 但是事实上说的全是错的，纯属啥不懂还瞎 BB 分布式 ID 大多都是 Client 本地生成，算法基本逻辑大多是一样的，看最终字节数吧，8 字节估计大部分情况都需要手动配置 clientID，也就是集权机器进程 ID，16 字节一般也就可以直接本地取信息自动生成了，除此之外很多情况下还有希望是直接数字时间，比如订单号这样比较容易给人看的，但是这样的话直接占了 14 字符了，所以很多时候还是需要依据自己业务量来适当调整的 |
 | 9 zzzmh 2020 年 7 月 6 日 这个我也不太懂，我们一般 int 的用数据库自增，string 的用 java uuid 或 mysql uuid |
 | 10 keshawnvan 2020 年 7 月 6 日 自己实现了一款，现在生产环境在用 实现： https://github.com/KeshawnVan/Ray 介绍： https://juejin.im/post/5e9d402df265da48094da80d |
 | 11 sirius1024 2020 年 7 月 6 日 MARK 一下，坐等最优解。 我用过的分布式，大部分都是 Client 标识+共享算法。 |
 | 12 cco 2020 年 7 月 6 日 美团、百度、滴滴都有基于雪花的 ID 生成器,看你的场景了,你要是趋势递增还不能被猜到,那就用美团的哪个吧 |
 | 14 egfegdfr 2020 年 7 月 6 日 非重要数据 id 自增。重要数据用的 mybatis-plus 带的 ID_WORKER,他是雪花的变种，纯数字，有序，比 uuid 要好。 |
 | 15 YAR 2020 年 7 月 6 日 sequence |
Select Language