昨晚用 Golang 写了个 ID 生成服务，分享给大家

[owenliang]

go-id-alloc

Golang+Mysql 实现的分布式 ID 生成服务

特性

• 高性能：分配 ID 只访问内存
• 分布式：横向扩展，理论无上限
• 高可靠：Mysql 持久化，故障恢复快
• 唯一性：生成 64 位整形，整体递增，永不重复
• 易用性：可自定义 ID 起始位置，对外 HTTP 服务
• 可运维性：提供健康检查接口，通过负载均衡自动摘除故障节点

地址： https://github.com/owenliang/go-id-alloc

整理成博客，供大家理解： https://yuerblog.cc/2017/11/21/golang-id-alloc/

[GjriFeu]

唯一性：生成 64 位整形，整体递增，永不重复 太长

[owenliang]

@GjriFeu 额

[twm]

实际情况中来讲不递增 id 会好一些

[owenliang]

@twm 按业务规则生成会好一些

[winglight2016]

@owenliang id 最好不要带业务规则，这是 DB schema 的设计原则之一

[owenliang]

@winglight2016 谁的原则

[rockuw]

> 高性能：分配 ID 只访问内存

多个服务器怎么保证递增？

[owenliang]

@rockuw 看代码喽

[rockuw]

分布式，只访问内存，还能保证严格递增，图灵奖级别的成就啊。

[owenliang]

@rockuw 不是严格。。我的措辞是整体递增，哈哈

[hilow]

用 redis 的 increment 生成 id 比这个 mysql 方便吧？

[pynix]

直接用 uuid，自增 id 最麻烦的就是可猜测。。。。

[notreami]

SnowFlake

[notreami]

理论无上限，永不重复
就这两条，我能喷死你。。。

[troywinter]

楼上正解，现阶段 twitter snowflake 算法算是最为可用的方案。。。

[owenliang]

@notreami 我就很好奇你能喷出啥。。

[owenliang]

@troywinter snowflake 还需要分享给大家么？

[geelaw]

@owenliang 编码长度是有限的，只要执行足够多次就会出现重复或者程序不正常。

用带有硬件信息的 GUID 算法就好了啊，这样不同电脑生成的就会不同了。

[owenliang]

鉴于不同意见较多，不再一一回复大家，关于分布式 ID 方案优劣势参考： https://tech.meituan.com/MT_Leaf.html。

[genesislive]

@owenliang 链接多了个“。”

[myself659410]

肯定楼主的动手出代码
都用 golang 还再加上 mysql 就为了分布式 uuid 实现起来觉得有点重了 依赖了 mysql，考虑到就帮，那 mysql 高可用也需要保证了吧

[Chingim]

只能有 2^64 个 id 吧，永不重复有点过了

[owenliang]

@Chingim 很有道理

[owenliang]

@myself659410 对 云或者公司都有能力提供高可用 mysql

[ihuotui]

有序 id 还是有用的

[swulling]

snowflake 加原子钟，直接硬件解决时间问题

便宜的原子钟才几百块

[wowowo1]

看了下代码，仿佛核心是先分区（ segments ），仿佛也可称为分片，然后根据每个分片根据自己的分区信息自己内部进行 ID 递增。


```
func (alloc *Alloc)NextId() (int64, error) {
alloc.mutex.Lock()
defer alloc.mutex.Unlock()

if len(alloc.segments) > 0 {
id := alloc.segments[0].left + alloc.segments[0].offset
alloc.segments[0].offset++
if id + 1 >= alloc.segments[0].right {
alloc.segments = append(alloc.segments[:0], alloc.segments[1:]...)
}
return id, nil
} else {
return 0, errors.New("no more id")
}
}
```

套用日本中二片里面自吹的话，最简单是 ID 生成器，最难也是 ID 生成器。

如果我理解没错的话，
你这套代码只能保证某个分区内递增，不能保证所有分区一起递增。
每次请求不能落盘，不能记录已分配的 ID，或许可以采用异步解决，但是遇到灾难性故障基本会出现重复的情况。
64 位整形仍然不能保证不重复。

目前来看，UUID 中 snowflake 才是终极方案，自增 ID 仍然数 TIDB 那套比较靠谱，虽然他不能保证连续，但是至少自增。

[wowowo1]

而且，mutex.lock 和 unlock 中间代码行数比较多，单个分片可能有性能问题。go 语言是否可以用 atomic.incr 那一套逻辑解决。

我只是稍微看了点代码，如有理解错误请提。

[owenliang]

@wowowo1 你理解错了，再看看代码吧。

[ztao8607]

@owenliang 问个问题，都记录在内存中，有容灾处理么？分布式节点中，多个节点 down 后，如何解决脑裂问题呢？

[zkeeper]

@owenliang 人家仔细看了代码，而且贴出来了自己的分析，即使你觉得错，多写两句告诉别人具体哪里你觉得有问题才是讨论的态度吧？什么都不说直接让人再看代码？别人估计不会再看了

[owenliang]

@zkeeper 看不看与我何干？感兴趣自己看，还有管闲事的，真是笑尿了

[zkeeper]

@owenliang 就你这个态度，真没必要把你的什么项目贴出来，指望别人不由分说就一脸膜拜交口称赞？你自嗨去吧

[zkeeper]

@zkeeper 拉黑

[wowowo1]

@zkeeper 蛤蛤蛤，没必要的。

至于态度，也还好吧。

但是第二天 astaxie 发了每日链接，有他这个 ID 生成器的设计的文章，感觉还好。

他自己也贴在一楼了。

毕竟有产出，有益于社会。

不用苛求太多。

我要是好不容易写个东西然后被楼上这么喷，我估计我也会毛的。

[iceheart]

1024