在高并发应用场景下,如订单体系、分布式数据库主键、消息队列等,分布式ID的生成至关重要。本文将基于Go语言,对多种分布式ID生成方案举行基准测试(Benchmark),并分析其性能及适用场景,资助开辟者选择最优方案。
常见分布式ID生成方案
在Go语言生态中,常见的分布式ID生成方案包括:
- XID(github.com/rs/xid):基于MongoDB ObjectID 改进的方案,时间排序、唯一性强、无中央化依靠。示例:cv4t2bgqnen8i96gcq90
- MongoDB ObjectID(go.mongodb.org/mongo-driver/bson/primitive):MongoDB默认的唯一ID方案,时间戳+呆板ID+进程ID+随机数。示例:67c9d12e050656d79bb0c630
- Snowflake(github.com/bwmarrin/snowflake):Twitter提出的分布式ID生成算法,64位整数,包罗时间戳、呆板ID和序列号。示例:1897690027819798528
- UUID(github.com/google/uuid):通用唯一标识符(UUID),标准化方案,适用于分布式体系,但字符串格式较长。示例:98c04b4b-b865-47e6-b72b-03fe04389fdd
- ShortUUID(github.com/lithammer/shortuuid/v4):UUID的短版本,淘汰字符长度,便于存储和传输。示例:k8PsWEDmsYUAbmeHcyjfeB
- Krand(github.com/go-dev-frame/sponge/pkg/krand):自定义随机数方案,提供更机动的ID生成能力。时间戳(微妙)+随机数。示例:1741351724666957080
基准测试代码
我们利用 testing.B 举行基准测试,代码如下:
- package main
- import (
- "testing"
- "github.com/bwmarrin/snowflake"
- "github.com/go-dev-frame/sponge/pkg/krand"
- "github.com/google/uuid"
- "github.com/lithammer/shortuuid/v4"
- "github.com/rs/xid"
- "go.mongodb.org/mongo-driver/bson/primitive"
- )
- func BenchmarkXID(b *testing.B) {
- for i := 0; i < b.N; i++ {
- xid.New().String()
- }
- }
- func BenchmarkObjectID(b *testing.B) {
- for i := 0; i < b.N; i++ {
- primitive.NewObjectID().Hex()
- }
- }
- func BenchmarkSnowFlakeInt64(b *testing.B) {
- node, _ := snowflake.NewNode(1)
- for i := 0; i < b.N; i++ {
- node.Generate()
- }
- }
- func BenchmarkKrandIDUint64(b *testing.B) {
- for i := 0; i < b.N; i++ {
- krand.NewID()
- }
- }
- func BenchmarkKrandIDString(b *testing.B) {
- for i := 0; i < b.N; i++ {
- krand.NewStringID()
- }
- }
- func BenchmarkUUID(b *testing.B) {
- for i := 0; i < b.N; i++ {
- uuid.New().String()
- }
- }
- func BenchmarkShotUUID(b *testing.B) {
- for i := 0; i < b.N; i++ {
- shortuuid.New()
- }
- }
复制代码 执行测试命令:
- go test -bench=. -benchmem
复制代码 测试效果分析
- goos: windows
- goarch: amd64
- pkg: id_test
- cpu: AMD Ryzen 7 6800H with Radeon Graphics
- BenchmarkXID-16 43977468 27.54 ns/op 0 B/op 0 allocs/op
- BenchmarkObjectID-16 46614250 26.21 ns/op 0 B/op 0 allocs/op
- BenchmarkSnowFlakeInt64-16 4633701 258.4 ns/op 0 B/op 0 allocs/op
- BenchmarkKrandIDUint64-16 97430276 12.03 ns/op 0 B/op 0 allocs/op
- BenchmarkKrandIDString-16 24759777 43.70 ns/op 16 B/op 1 allocs/op
- BenchmarkUUID-16 7194732 165.0 ns/op 64 B/op 2 allocs/op
- BenchmarkShotUUID-16 6521544 184.6 ns/op 40 B/op 2 allocs/op
复制代码 1. 性能最佳方案:Krand (Uint64)
- 生成速率最快,仅 12.03 ns,无额外分配。
- 适用于极致性能寻求的应用,如缓存键、数据库主键等。
2. 综合性能良好方案:MongoDB ObjectID、XID
- 生成速率约 26-27 ns,无额外内存分配。
- 适用于需要时间排序和唯一性的分布式应用。
3. 适用于大规模分布式体系:Snowflake
- 由于需要维护节点信息,生成速率稍慢 258.4 ns,但可包管递增性和唯一性。
- 适用于大规模分布式体系,如订单ID、日志ID。
4. 适用于跨体系兼容:UUID、ShortUUID
- UUID 标准化程度高,但 165 ns 生成速率较慢,占用 64 B 内存。
- ShortUUID 淘汰了字符串长度,但仍有 184.6 ns 生成时间。
最佳实践建议
- 数据库主键:Krand(数值型)或 Snowflake(整数型)。
- 分布式服务间追踪ID:XID 或 MongoDB ObjectID。
- 可读性强的ID:ShortUUID 或 Krand(字符串型)。
- 跨体系唯一标识:UUID。
结论
在分布式ID生成方案中,没有绝对的“最优”方案,只有“最适合”的方案。Krand 适用于高性能场景,XID 分身性能和可读性,而 Snowflake 适用于大规模分布式体系。开辟者应根据业务需求选择最优方案,以提升体系的稳固性和性能。
Sponge 是一个强大的 Go 开辟框架,其核生理念是通过解析 SQL、Protobuf、JSON 文件逆向生成模块化代码,这些代码可机动组合成多种类型的完备后端服务。Sponge 提供一站式项目开辟解决方案,涵盖代码生成、开辟、测试、API 文档生成和部署等方面,明显提升开辟效率,降低开辟难度,实现以"低代码"方式构建高质量企业级项目。Sponge与内置的DeepSeek R1助手协同重构传统开辟范式,打造极速开辟体验。
Sponge Github 地点: https://github.com/go-dev-frame/sponge
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。 |