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