分布式系统生成全局唯一 ID 的方式请教

[jiobanma]

咨询各位大佬们一个问题目前有两台服务器负载，使用 apache 的 SnowflakeShardingKeyGenerator 生成雪花算法作为 id ，业务上需要生成的 id 是递增的。 之前两台服务器的 SnowflakeShardingKeyGenerator 的 workId 都是默认的，高并发情况下，两台服务器的时间可能会有误差 就会导致生成的 id 是重复的。但是两台服务器根据不同的 workId 去生成虽然能解决重复的问题，但是会导致生成的 id 不是连续递增的。 有什么其他的方式实现吗（排过坑的[旺柴]）。

[tabris17]

又要严格自增，又要分布式，你这是既要又要啊

[veike]

@jiobanma 我说的 ulid ，不是 uuid ，不是一个东西

[ns09005264]

把 workid 放到最后试试，比如服务 1 生成序列号 123777701 服务 2 同一时间生成 123777702 ，这样不管从全局来看还是单个服务来看，id 都是连续的

[nekolr]

@dw2693734d 1 太长 2 可能的安全性问题 3 不是递增的，会导致数据存储不够紧凑，不能充分利用 B+ 树的优势

[Belmode]

修改一下 workerId ，你这问题不是迎刃而解了

[jiobanma]

@Belmode #25 workId 影响的是中间的某几位，修改没法解决呀
@bugmakerxs #17 这个我了解下

[crysislinux]

@jiobanma machine id 如果都一样，那还设计这个位干嘛呢。

[opengps]

“ id 是递增”天然的设计优势就是自增步长设置为 2 啊，一台 1 作为种子，一台 2 作为种子

[yangyaofei]

给机器分配 ID(0 到 N 的自然数)不就好了, 比如 10 台, 就找个 N=11, 每个机器自己生成的时候乘以 11 加上自己的 ID 就好了, N 可以有个比较大的余量, 虽然很工程但是感觉应该挺好用

[qingshengwen]

没太明白，时间戳是在最前面的，这样一定是可以做到大致递增的，跟 workId 有什么关系呢

[fuis]

为什么需要严格的单调递增？

[icedir]

了解一下美团的 leaf ，解决了这个场景

[cat]

或许可以看看这个：
Sharding & IDs at Instagram
https://instagram-engineering.com/sharding-ids-at-instagram-1cf5a71e5a5c

[leonshaw]

这种需求不管怎么折腾都等效于一个单点

[taevas]

@fuis 可读性呀，不必时间排序，仅通过主键可知时序

[bringyou]

美团开源过分布式 ID 的生成服务，并有写文章介绍，可以参考： https://tech.meituan.com/2019/03/07/open-source-project-leaf.html

[xiaoHuaJia]

uuid 重写加入时间，可以实现是有排序的。目前我们系统的方案就是这个。除了 id 看起没没纯数字那么规整，差一点点性能，其它都是小问题

[yc8332]

写个服务预先生成好，放 redis 或者自己的服务。然后用的直接取就行了。。

[yaodong0126]

@mineralsalt 我倒是觉得 1L 非常优雅

[PythonYXY]

需要递增就没法采用分布式的方式，无论是 snowflake 还是基于数据库自增 id ，最后肯定还是会有单点问题。