生成全服唯一ID,你们是怎么做的呢?

buguang01 · 2023-06-06 13:59:05 · 4202 次点击 · 大约8小时之前 开始浏览    置顶
这是一个创建于 2023-06-06 13:59:05 的主题,其中的信息可能已经有所发展或是发生改变。

我们在工作中常常需要在分布式的服务器上,生成全服唯一的ID,同时还需要按时间有序; 之前在一个项目中拿 到一个这样的ID生成器,代码如下:

// IDFetcher 获取唯一的TempID号
type IDFetcher struct {
    baseID  uint64
    startID uint64
    seed    uint64
}

func newIDFetcher(srvID uint64) *IDFetcher {
    return &IDFetcher{
        baseID: srvID,
        startID: uint64(time.Now().Unix()),
        seed:   0,
    }
}

func (srv *IDFetcher) FetchTempID() uint64 {
    seed := srv.incSeed()
    id := srv.baseID<<44 | srv.startID<<32 | seed
    return id
}

func (srv *IDFetcher) incSeed() uint64 {
    var n, v uint64
    for {
        v = atomic.LoadUint64(&srv.seed)
        n = v + 1
        if n > 0xFFFFFFFF {
            n = 0
        }
        if atomic.CompareAndSwapUint64(&srv.seed, v, n) {
            break
        }
    }
    return n
}

然后发现一个问题,就是并发获取ID的时候,必然会有人触发for循环的逻辑导致多次获取ID; 于是我就想优化一下,就有了下面的代码:

// IDGenerater 获取唯一的ID号
type IDGenerater struct {
    baseID uint64
    seed   uint64
}

func NewIDGenerater(srvID uint64) *IDGenerater {
    result := new(IDGenerater)
    result.baseID = srvID
    result.seed = uint64(time.Now().Unix()) << 16
    return result
}

func (srv *IDGenerater) GenerateID() uint64 {
    seed := atomic.AddUint64(&srv.seed, 1)
    high := seed << 16 >> 16
    tmptime := seed >> 16
    for n := int64(tmptime - uint64(time.Now().Unix())); n > 0; n = int64(tmptime - uint64(time.Now().Unix())) {
        time.Sleep(time.Duration(n-1)*time.Second + time.Millisecond*100)
    }
    result := srv.baseID<<48 | high
    return result
}

今天拿出来和大家分享一下。欢迎大家一起交流!你们的ID生成器是怎么写的呢?


有疑问加站长微信联系(非本文作者)

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

4202 次点击  ∙  1 赞  
加入收藏 微博
8 回复  |  直到 2023-07-28 09:27:08
tangzhangming
tangzhangming · #1 · 2年之前

Redis自增

agree
agree · #2 · 2年之前

我就好奇sleep是为了干嘛?单纯的卡一下流程?为了后期优化速度?

jinl80
jinl80 · #3 · 2年之前

为什么不直接用atomic.AddInt64

buguang01
buguang01 · #4 · 2年之前
agreeagree #2 回复

我就好奇sleep是为了干嘛?单纯的卡一下流程?为了后期优化速度?

因为这个生成ID的过程中有32位是表示时间 的,如果生成ID的速度过快,会导致生成出末来时间 的ID,这个时候,需要卡一下时间来避免这个问题。正常情况下时间段内的ID是够用的,写sleep是为了保证逻辑完整性。

buguang01
buguang01 · #5 · 2年之前
jinl80jinl80 #3 回复

为什么不直接用atomic.AddInt64

同上回答,为了验证时间是否为末来时间

agree
agree · #6 · 2年之前
buguang01buguang01 #4 回复

#2楼 @agree 因为这个生成ID的过程中有32位是表示时间 的,如果生成ID的速度过快,会导致生成出末来时间 的ID,这个时候,需要卡一下时间来避免这个问题。正常情况下时间段内的ID是够用的,写sleep是为了保证逻辑完整性。

主要是你这sleep并不会改变本次返回,相当于是你发现本次生成的ID应该是在1秒后生成的,这个时候你就延时1秒返回出去。你这不就是强制卡处理延时了

buguang01
buguang01 · #7 · 2年之前
agreeagree #6 回复

#4楼 @buguang01 主要是你这sleep并不会改变本次返回,相当于是你发现本次生成的ID应该是在1秒后生成的,这个时候你就延时1秒返回出去。你这不就是强制卡处理延时了

对的,因为如果提前拿到ID,然后保存下来了,那这个时候程序如果重启后,会导致ID重复。所以,需要sleep一下,来保证ID只在正确的时间后出现。

buguang01
buguang01 · #8 · 2年之前

虽然结合业务逻辑这个sleep进去的可能性是很底的,但从逻辑上需要保证完整性。

添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传