分布式系统唯一主键标识符ID生成机制比较 - Encore

然而，在分布式系统中，让一个数字从 1 开始并缓慢增加要困难得多。您可以构建一个选举领导者的系统，并且该领导者负责增加数量 - 但这会给您的系统设计增加很多复杂性，它不会无限扩展，因为您仍然会受到吞吐量的限制领导。您仍然可能会遇到脑裂问题，即相同的数字由两个不同的“领导者”生成两次
在项目的早期做出正确的决定总是很重要的，因为一旦投入生产，这是系统中最难改变的事情之一。
 
现有选项
如果我们暂时忽略类型安全和人类可读性要求，那么我们所要求的已经解决了一千次了，我们不需要在这里重新发明轮子。让我们看看一些现有的久经考验的选项。

• 数据库的自动递增键

• UUIDs

版本1和2，尽管它们每秒可以生成大约1600亿个标识符，但它们使用机器的MAC地址，这意味着同一台机器上的两个进程如果同时调用，可能会生成相同的标识符。
第4版生成完全随机的标识符，具有2122比特的随机性。这意味着我们非常不可能发生碰撞，并且可以无限扩展而不会出现瓶颈。然而，我们失去了按时间顺序排列标识符的能力。
  

• Snowflake 

这给了我们很好的可扩展性，因为实例的比特集允许我们同时运行1024个不同的进程，同时知道它们不能产生相同的标识符，因为进程自己的标识符是在里面编码的 它给我们提供了我们的k-排序，因为上面的位是ID产生的时间。最后，我们在进程内有一个序列号，这使我们能够在每个进程中每秒产生4096个标识符。

然而，Snowflake 不符合我们需要零配置的要求，因为实例 ID 必须在每个进程中进行配置。
 

• KSUID

• XID

XID给了我们所有的核心要求，它的字符串编码使用32进制（没有大写字母来破坏我们的排序！）。这个字符串编码始终是20个字符，这意味着我们可以在任何marshalling代码中使用这一事实进行验证（例如Postgres对数据库类型的CHECK约束）。
 
Encore公司的选择要求

• 可排序

import "github.com/rs/xid"

type AppID xid.ID
type TraceID xid.ID

func NewAppID() AppID { return AppID(xid.New()) }
func NewTraceID() TraceID { return TraceID(xid.New()) }

var app AppID = NewTraceID() // this won't compile

import (
    "fmt"
    "github.com/rs/xid"
)

type EncoreID struct {
    ResourceType string
    ID           xid.ID
}

type AppID *EncoreID
type TraceID *EncoreID

func NewAppID() AppID { return &EncoreID{ "app", xid.New() } }
func NewTraceID() TraceID { return &EncoreID{ "trace", xid.New() } }

import (
    "fmt"
    "github.com/rs/xid"
)

type ResourceType struct{}
type App ResourceType
type Trace ResourceType

type ID[T ResourceType] xid.ID

func New<a href=") ID[T] { return ID[T](xid.New(">T ResourceType</a>) }