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

所有服务连同一个 redis ，使用同一个 key 的 incr 生成 id ，既能自增又分布式

@yaodong0126 #39 多运行一个服务和使用 redis 加锁没有本质区别, 一般后端项目都会引入 redis, 所以几乎是没有额外成本的. 另外我简单说一下多运行一个服务的缺点.
1. 浪费内存, java 后端项目启动就几百兆
2. 稳定性降低, 本来他是分布式部署的项目强行被这个单点服务拖累了, 一旦这个服务挂掉, 其他服务都 GG
3. 开发任务多了, 多维护一个模块, 也要多上线一个实例

当然这是一个好的解决方案, 但是一个小项目, 我还是秉承着资源最小化的理念, 不要过多的引入服务和模块

@mineralsalt 还是有区别的， 每个项目都引入 redis, 连接数要爆掉了。引入项目可以增加网关控制调用。

直接用 ULID 吧，生成的 id 带时间戳精确到毫秒，毫秒级有序

@dddd1919 热点 key 警告（

@jiobanma 那直接用比特币钱包地址生成算法

@luciankaltz #45 了解的有点少，想问下热点 key 可能会导致哪些问题

@tabris17 #21 “自增” 和 “ 递增” 是有区别的，注意看

@qingshengwen #30
public static Comparable<?> geneSnowFlakeIDByWorkId(String workId) {
shardingKeyGenerator.getProperties().setProperty("worker.id", workId);
return shardingKeyGenerator.generateKey();
}


public static void main(String[] args) {
System.out.println(geneSnowFlakeIDByWorkId("100")); // 890660284086501376
System.out.println(geneSnowFlakeIDByWorkId("200")); // 890660284095299585
System.out.println(geneSnowFlakeIDByWorkId("100")); // 890660284094889986
System.out.println(geneSnowFlakeIDByWorkId("200")); // 890660284095299587
}

这样是不就理解了

也没有大佬解释下 1 楼的方案？目前两台雪花算法在高并发下会重复，说明业务并发还是不低的，再加一个专门生成 id 的服务，是不是还是调用雪花服务器？如果这样的话这个服务就会面临瓶颈，服务如果再通过集群搞成分布式，感觉会面临同样的问题啊。

通过一个中心服务器拿自增号码段

https://cloud.tencent.com/developer/article/1352896

@jiobanma 自己实现，时间戳放最高位，自增数放中间，workid 放最低位

单调递增和趋势递增是 2 个概念，1L 其实就是解决方案，再起一个服务专门做 id 生成，另外其他楼说的美团的 leaf ，那个玩意儿的基于号段的和雪花的也是 2 种不同场景，要注意甄别

@wangxiaoaer 他这个两台服务器的 machine id 用的同一个，当然有重复的可能性。

@jiobanma 想象一下你对一张表的数据行做 10 次 update 。如果是 10 条记录，那么这些操作之间不会有并发锁问题；如果 10 次更新的是一条记录，那么 10 次操作会退化成串行执行

热点问题会直接导致各种分片或者分布策略失效，大多数情况下直接退化到单机性能（甚至可能影响到其他的操作

一言难尽
说不懂吧，又用上了雪花 id 算法
说懂吧，又不给服务器分配唯一编号🐶

不知道你业务顺序是怎么定义的？
两个不相关的客户端几乎同时发送的请求本身就是没有顺序的，网络随便抖一下到服务器的顺序就变了，更不要说还有相对论了。技术上讲，事件先后只有在同一个点比较才有意义，你分 ID 的时候就是要保证和这个顺序一致。比如来自同一个连接的请求在同一个线程处理。

lz 始终没解释为啥一定要递增。
产品需求？只有疯了的产品才关注这个。leader 的需求？那是技术不太行…

@veike 万万不可，会降低 b 树的效率，降低 pagecache 的利用率

1. 给定正确的 workerId ，
2. 雪花算法中将代表时间的段放在高位