这是一个创建于 1272 天前的主题，其中的信息可能已经有所发展或是发生改变。
我目前看到的雪花算法生成的 id 基本都是长整型，有没有短数字唯一 id 生成，直接生成 int，比如 b 站 av 号之类的。既然是短数字的唯一 id 生成，那就不会应用到类似“订单 id 生成”等诸如 1 秒内生成几百几千个 id 的场景中，
希望能在服务端内部生成，不用必须依赖数据库来生成 id，能控制长度（比如长度固定，或者数字长度不低于几位不高于几位之类的）
有没有序无所谓，当然如果能选择无序模式或有序模式的话，那最好不过了。
那么有哪些实现的呢，或者哪些工具类有这些功能了
 |
1
tabris17 2021-07-07 13:51:10 +08:00
有啊，数据库自增字段，或者其他全局计数器
|
 |
2
retanoj 2021-07-07 14:01:05 +08:00
时间戳够用么？
|
 |
4
rioshikelong121 2021-07-07 14:06:55 +08:00
你搜 shortid 就出来了
|
 |
6
liaohongxing 2021-07-07 14:13:21 +08:00
最类似下面这个，但还是偏长
https://gitee.com/yitter/idgenerator |
 |
7
tctc4869 OP @liaohongxing 谢谢，js 的话，数字很长就得把数字转成字符串
|
 |
8
timethinker 2021-07-07 14:32:55 +08:00
给一条数据赋值 ID 一般代表这条数据具有生命周期，也就是实体，随机性的 ID 生成优点是速度快，但是一般都比较长，短且紧凑的 ID 一般需要有一个单独的地方进行维护管理，因为随机会有重复的风险，毕竟这个状态我们需要持久化。
说一下我们之前做过的一个 ID 生成服务：不同实体的 ID，都是一个隔离开的空间范围，这个递增的空间范围需要由一个独立的服务来进行维护和管理。传入实体类型，也就是一个 Key 绑定一个 ID 的当前值，并告诉这个服务我需要多大范围的 ID，可以设计一个接口： (start, end) nextIdRange(key, size) 其中 key （实体标识）和 size （获取多少个）为参数，用于获取一段 ID 范围，返回值 start 为起始值，end 为结束值。 客户端获得以后就可以在这个范围内进行本地递增。需要注意的是，这个接口需要保证原子性，也就是并发的时候不会返回相同的数据，每一次调用都将会导致内部维护的当前 ID 值发生变化。 客户端如果生成 ID 频繁，可以考虑优化为当剩余的 ID 快要耗尽时，另外起一个线程去预取下一批次的 ID 段（假设是跨网络的服务调用，ID 生成服务为一个独立的进程），保证 ID 生成不会受到获取 ID 这个操作的延迟影响，设置为多少合适则取决于实际的情况。 |
|
9
liaohongxing 2021-07-07 14:35:52 +08:00
@tctc4869 你注意看文档，我说的很长是指和 B 站 BV 相比 ，他这个 避免了 js 的最大值 ，仔细看下 。
|
 |
11
oddcc 2021-07-07 14:49:14 +08:00
还是要依赖 id 生成的服务的
简单的设计可以考虑提前生成 id，放到库里 服务端用的时候一批一批的取，只要取出来就认为是用掉了 整体设计比较简单，好理解，也没有过多的依赖 |
 |
12
jslang 2021-07-07 16:38:42 +08:00
自己生成呗，毫秒时间戳+2~3 随机数
或者 21-0707-剩余(毫秒 /秒)+几位随机数 |
 |
13
kop1989 2021-07-07 16:43:47 +08:00
最简单的就是时间相关+随机。具体时间精度取多少，随机又取多长，要看你的目标压力而定。
|
 |
14
macttt 2021-07-07 17:42:23 +08:00
增加一个服务实例分配号段吧，每个服务存一个 id 池譬如 1~1000，用完了之后到发号服务里再拿一段号段，以此类推。用发号服务来保证 id 不重复。如果需要标识实例编号的话，得在短 id 头部预留几位保存实例编号。
|
 |
15
zachlhb 2021-07-07 17:51:23 +08:00 via iPhone
short uuid 就可以
|
 |
16
sakishum 2021-07-07 17:54:38 +08:00
Snowflake 雪花？
|
 |
17
libook 2021-07-07 18:23:04 +08:00
如果不担心被遍历的话，可以数据库自增。
如果担心被遍历的话就用时间戳+随机数字再 HASH，只不过越短碰撞可能性越大。 当然也可以数据库自增再加随机量的增量，然后再做个风控监测，如果某客户端短时间内访问了大量的无效 ID 就封掉。 缩短 ID 的最重要的一步是做进制转换。 自增是十进制，HASH 是十六进制，如果你大小写不敏感就一律转换成 36 进制，即 0-9a-z，如果大小写敏感就用 62 进制，0-9a-zA-Z，这个如果用 JS 的话可以直接 toString(进制数)。 |
 |
18
sighforever 2021-07-07 18:44:16 +08:00
又短又唯一，不用数据库记录一下不可能啊，最少需要保存一个已用的数据范围
|
 |
19
mxT52CRuqR6o5 2021-07-07 18:56:54 +08:00
把自增 id 用对称加密算法加密，就能获得随机（只要密钥不泄露对外就等于随机）不会碰撞的 id
|
 |
20
lix7 2021-07-07 19:09:06 +08:00
从服务上线起的毫秒时间戳 + IP 前后 16 位异或 + 两位随机数
应该是足够用了，如果再有碰撞的话，就依赖于重试去处理了 |
 |
21
find456789 2021-07-07 20:52:21 +08:00  2
我知道有个 基于字母+数字 的 叫 hashid， 很多语言都支持
|
 |
22
sunmoon1983 2021-07-08 11:21:48 +08:00
不知道京东的订单号是怎么得出来的，很短，纯数字
|
Select Language