链接多了个“。”

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

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


<br>func (alloc *Alloc)NextId() (int64, error) {<br> alloc.mutex.Lock()<br> defer alloc.mutex.Unlock()<br><br> if len(alloc.segments) &gt; 0 {<br> id := alloc.segments[0].left + alloc.segments[0].offset<br> alloc.segments[0].offset++<br> if id + 1 &gt;= alloc.segments[0].right {<br> alloc.segments = append(alloc.segments[:0], alloc.segments[1:]...)<br> }<br> return id, nil<br> } else {<br> return 0, errors.New("no more id")<br> }<br>}<br>

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

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

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