Go sonyflake 机器编号重复为什么会破坏唯一性

Go sonyflake 的机器编号一旦在同一个 ID 空间内重复，唯一性就不再由库自动保证。原因很直接：一个 Sonyflake ID 同时编码时间片、序列号和机器编号；如果两个实例在相同时间片里拿到相同序列号，而机器编号也相同，它们就可能组成同一个 ID。

排查这类问题时，重点不是简单换一个整数，而是确认机器编号的来源、作用域和占用检查是否一致。下面按 sonyflake v2 的配置语义说明为什么会冲突，以及如何把风险挡在启动阶段。

机器编号为什么会影响唯一性

官方文档给出的默认布局是 39 位时间、8 位序列号和 16 位机器编号。时间字段解决“什么时候生成”，序列号解决“同一实例在一个时间片内的多次生成”，机器编号则区分不同实例。三部分共同参与 ID 组成，不能只看时间字段是否递增。

因此，两个容器即使运行在不同主机上，只要最终得到同一个机器编号，就共享了同一个身份槽位。时间片和序列号通常只能降低碰撞概率，不能替代节点身份隔离。重启、容器重建、私有网络变化和多套环境共用注册范围，都是需要单独考虑的边界。

默认机器号为什么在部署后可能不够稳

sonyflake 的默认 MachineID 会取私有 IP 的低位。这个默认值在简单的独立主机环境中比较方便，但它不是“平台已经为所有实例发放的全局租约”。如果两个网络、容器或环境的私有地址低位重合，就可能出现相同编号。

更稳妥的做法是显式提供编号来源，并先定义唯一性作用域。例如同一个生产 ID 空间可以使用集中分配的节点号；开发、测试和生产则不要共用同一组编号租约。编号本身不必泄露主机信息，关键是它在有效生命周期内只绑定一个正在生成 ID 的实例。

package main

import (
    "fmt"
    "github.com/sony/sonyflake/v2"
)

func main() {
    settings := sonyflake.Settings{
        MachineID: func() (int, error) {
            // 演示用编号；生产环境应来自有租约的节点注册表。
            return 37, nil
        },
    }

    sf, err := sonyflake.New(settings)
    if err != nil {
        // 创建失败必须停止提供 ID，不能退回到未登记的默认编号。
        panic(fmt.Errorf("create sonyflake: %w", err))
    }

    id, err := sf.NextID()
    if err != nil {
        // 时间字段耗尽或其它生成错误都要交给上层处理。
        panic(fmt.Errorf("generate id: %w", err))
    }
    fmt.Println(id)
}

这段写法只说明编号如何注入，不代表编号 37 在所有环境都可用。真正的判断标准是：编号的分配系统是否知道它已经被占用，以及实例退出时是否能释放或续租。

用 CheckMachineID 把冲突挡在启动阶段

MachineID 负责给当前实例提供候选编号，CheckMachineID 负责回答这个编号是否满足当前部署的唯一性约束。sonyflake 文档说明，如果检查函数返回 false，New 不会创建实例；如果检查函数为 nil，则不会做这项校验。

关键在于检查的数据源必须是共享的。把已占用编号放在每个进程自己的内存 map 中，只能发现本进程内的重复，不能发现另一台主机已经使用同一个编号。生产环境通常需要带租约的注册表、数据库唯一约束或其它单一事实来源，并让“检查”和“占用”具有不会被并发插入打穿的原子性。

package main

import (
    "fmt"
    "github.com/sony/sonyflake/v2"
)

func main() {
    machineID := 37
    settings := sonyflake.Settings{
        MachineID: func() (int, error) {
            // 编号来自当前实例的启动配置，实际值应由注册系统分配。
            return machineID, nil
        },
        CheckMachineID: func(id int) bool {
            // 这里仅示意“共享占用检查”的返回结果，不伪造本地执行结果。
            return id != 0
        },
    }

    sf, err := sonyflake.New(settings)
    if err != nil {
        // 被占用时让服务启动失败，由编排层重新申请编号。
        panic(fmt.Errorf("machine id is unavailable: %w", err))
    }
    _ = sf
}

示例中的检查函数没有连接真实注册表，不能当作生产实现。实际代码要把“读取可用状态”和“登记当前租约”设计成一个可审计的分配动作，再把最终编号交给 MachineID。

按现象区分创建失败与真正的重复风险

常见现象可以这样区分：

上线前至少固定三项：所有节点使用同一个机器号分配规则；同一 ID 空间不允许并行占用同一编号；创建失败时不静默退回默认配置。这样即便某个实例重启，也会先重新确认身份，再开始生成 ID。

常见问题

机器编号不同就一定不会重复吗？

不能把它当成唯一条件。时间基准、位分配、序列号状态和实例实现都要符合库的约束；但在相同布局下，机器编号重复确实会直接破坏节点区分。

只设置 MachineID，不设置 CheckMachineID 可以吗？

可以运行，但库不会替你确认编号是否已经被其它实例占用。只要 ID 空间跨进程或跨主机，就应把唯一性检查放到共享的分配系统中。