Golang+Mysql 实现的分布式 ID 生成服务
1
GjriFeu 2017-11-19 11:31:44 +08:00
唯一性:生成 64 位整形,整体递增,永不重复 太长
|
3
twm 2017-11-19 11:58:48 +08:00 via iPhone
实际情况中来讲不递增 id 会好一些
|
5
winglight2016 2017-11-19 12:47:03 +08:00
@owenliang id 最好不要带业务规则,这是 DB schema 的设计原则之一
|
6
owenliang OP @winglight2016 谁的原则
|
7
rockuw 2017-11-19 13:09:53 +08:00 via iPhone
> 高性能:分配 ID 只访问内存
多个服务器怎么保证递增? |
9
rockuw 2017-11-19 13:44:19 +08:00 via iPhone
分布式,只访问内存,还能保证严格递增,图灵奖级别的成就啊。
|
11
hilow 2017-11-19 14:26:46 +08:00 via Android
用 redis 的 increment 生成 id 比这个 mysql 方便吧?
|
12
pynix 2017-11-19 14:31:37 +08:00 via iPhone
直接用 uuid,自增 id 最麻烦的就是可猜测。。。。
|
13
notreami 2017-11-19 15:21:26 +08:00
SnowFlake
|
14
notreami 2017-11-19 15:23:58 +08:00
理论无上限,永不重复
就这两条,我能喷死你。。。 |
15
troywinter 2017-11-19 15:34:03 +08:00
楼上正解,现阶段 twitter snowflake 算法算是最为可用的方案。。。
|
17
owenliang OP @troywinter snowflake 还需要分享给大家么?
|
18
geelaw 2017-11-19 16:32:07 +08:00
|
19
owenliang OP 鉴于不同意见较多,不再一一回复大家,关于分布式 ID 方案优劣势参考: https://tech.meituan.com/MT_Leaf.html。
|
20
genesislive 2017-11-19 17:43:05 +08:00
@owenliang 链接多了个“。”
|
21
myself659410 2017-11-19 21:05:47 +08:00
肯定楼主的动手出代码
都用 golang 还再加上 mysql 就为了分布式 uuid 实现起来觉得有点重了 依赖了 mysql,考虑到就帮,那 mysql 高可用也需要保证了吧 |
22
Chingim 2017-11-19 21:38:21 +08:00 via Android
只能有 2^64 个 id 吧,永不重复有点过了
|
24
owenliang OP @myself659410 对 云或者公司都有能力提供高可用 mysql
|
25
ihuotui 2017-11-20 00:31:12 +08:00 via iPhone
有序 id 还是有用的
|
26
swulling 2017-11-20 00:49:11 +08:00 via iPhone
snowflake 加原子钟,直接硬件解决时间问题
便宜的原子钟才几百块 |
27
wowowo1 2017-11-20 02:49:50 +08:00
看了下代码,仿佛核心是先分区( 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 那套比较靠谱,虽然他不能保证连续,但是至少自增。 |
28
wowowo1 2017-11-20 02:52:23 +08:00
而且,mutex.lock 和 unlock 中间代码行数比较多,单个分片可能有性能问题。go 语言是否可以用 atomic.incr 那一套逻辑解决。
我只是稍微看了点代码,如有理解错误请提。 |
31
zkeeper 2017-12-03 07:24:54 +08:00 via iPhone
@owenliang 人家仔细看了代码,而且贴出来了自己的分析,即使你觉得错,多写两句告诉别人具体哪里你觉得有问题才是讨论的态度吧?什么都不说直接让人再看代码?别人估计不会再看了
|
33
zkeeper 2017-12-03 21:06:51 +08:00 via iPhone
@owenliang 就你这个态度,真没必要把你的什么项目贴出来,指望别人不由分说就一脸膜拜交口称赞?你自嗨去吧
|
35
wowowo1 2017-12-14 18:02:49 +08:00
@zkeeper 蛤蛤蛤,没必要的。
至于态度,也还好吧。 但是第二天 astaxie 发了每日链接,有他这个 ID 生成器的设计的文章,感觉还好。 他自己也贴在一楼了。 毕竟有产出,有益于社会。 不用苛求太多。 我要是好不容易写个东西然后被楼上这么喷,我估计我也会毛的。 |
36
iceheart 2018-01-02 19:29:48 +08:00 via Android
1024
|