76.Go分布式ID总览

这篇具有很好参考价值的文章主要介绍了76.Go分布式ID总览。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

简介

在分布式系统中,生成唯一的ID是一个核心问题,特别是在需要确保数据完整性和避免冲突的场景中,比如作为链路追踪的trace_id,作为幂等性的主键id, 分布式锁中为了避免释放的是别人的锁时,本地保存的唯一id等。以下是对一些分布式唯一ID生成方法的详细阐述,包括它们的工作原理、优缺点,以及对网络依赖性的考量

一:UUID

实现原理

  • 工作方式:UUID是通过一系列算法生成的128位数字,通常基于时间戳、计算机硬件标识符、随机数等元素。

  • 全局唯一性:算法设计确保了即使在分布式系统中也能生成全局唯一的ID

优缺点

  • 优点:实现简单,无需网络交互,保证了ID的全球唯一性。

  • 缺点:通常不能保证顺序性,ID较长,可能导致存储和索引效率低下。

  • 网络依赖性:无网络依赖。

注意:工作中基本不使用uuid,这里是为了介绍分布式ID的完整性,以及UUID大家都熟知,所以一起介绍一下

uuid有两种包:

  • github.com/google/uuid,仅支持V1V4版本。

  • github.com/gofrs/uuid ,支持全部五个版本。

下面简单说下五种版本的区别:

Version 1,基于mac地址、时间戳。

Version 2,based on timestamp,MAC address and POSIX UID/GID (DCE 1.1)

Version 3,Hash获取入参并对结果进行MD5。

Version 4,纯随机数。

Version 5,based on SHA-1 hashing of a named value。

特点

  • 5个版本可供选择。

  • 定长36字节,偏长。

  • 无序。

package mian

import (
    "github.com/gofrs/uuid"
    "fmt"
)

func main() {
    // Version 1:时间+Mac地址
    id, err := uuid.NewV1()
    if err != nil {
        fmt.Printf("uuid NewUUID err:%+v", err)
    }
    // id: f0629b9a-0cee-11ed-8d44-784f435f60a4 length: 36
    fmt.Println("id:", id.String(), "length:", len(id.String()))

    // Version 4:是纯随机数,error会在内部报panic
    id, err = uuid.NewV4()
    if err != nil {
        fmt.Printf("uuid NewUUID err:%+v", err)
    }
    // id: 3b4d1268-9150-447c-a0b7-bbf8c271f6a7 length: 36
    fmt.Println("id:", id.String(), "length:", len(id.String()))
}

二、雪花算法

Twitter开发的一种生成64ID的服务,基于时间戳、节点ID和序列号。

实现原理

  • 工作方式:结合时间戳、工作机器的ID和序列号来生成64位的ID。时间戳保证了ID的唯一性和顺序性,工作机器ID保证了在多机环境下的唯一性。

  • 时间戳:确保ID按时间顺序增长。

优缺点

  • 优点:ID有时间顺序,长度适中,生成速度快。

  • 缺点:对系统时钟有依赖,时钟回拨会导致ID冲突。(时钟回拨:服务器上的时间突然倒退回之前的时间。可能是人为的调整时间;也可能是服务器之间的时间校对。)

  • 网络依赖性:通常无需网络交互,除非在多机器环境中同步机器ID

由于雪花算法工作中还是可能用到的,所以介绍更详细一些。

Snowflake的核心思想是:使用41bit作为毫秒数,10bit作为机器的ID5bit是数据中心(DC,机房)),5bit的机器ID(也可能是容器id)),12bit作为毫秒内的流水号(意味着每个节点在每毫秒可以产生 4096 个 ID),最后还有一个符号位,永远是01。这样可以确保每个ID都是唯一的。
76.Go分布式ID总览,go,golang,分布式

package main

import(
    "fmt"
    "github.com/bwmarrin/snowflake"
)

func main() {
// 参数为机器id
  node, err := snowflake.NewNode(1)
    if err != nil {
      fmt.Println(err)
      return
    }

    id := node.Generate().String()    
    // id: 1552614118060462080 length: 19
    fmt.Println("id:", id, "length:", len(id))
}

三:Leaf-snowflake

时钟回拨

服务器上的时间突然倒退回之前的时间。可能是人为的调整时间;也可能是服务器之间的时间校对。

实现方案
76.Go分布式ID总览,go,golang,分布式

Zookeeper顺序增、全局唯一的节点版本号,替换了原有的机器地址。解决了时钟回拨的问题。强依赖ZooKeeper、大流量下可能存在网络瓶颈。下图的方案在Leaf-snowflake 中通过缓存一个ZooKeeper文件夹,提高可用性。运行时,时差小于5ms会等待时差两倍时间,如果时差大于5ms报警并停止启动。

76.Go分布式ID总览,go,golang,分布式

四:数据库自增ID

实现原理

  • 工作方式:基于中央数据库的序列生成器,如自增主键ID,每次请求时递增序列值。

  • 顺序性:保证了生成ID的顺序性和唯一性。

优缺点

  • 优点:简单可靠,保证顺序性。

  • 缺点:

    • 可能成为系统的单点故障,对数据库有较高的依赖。
    • 由于有序递增,易暴露业务量。受到数据库性能限制,对高并发场景不友好。
    • bigint最大是2^64-1,但是数据库单表肯定放不了这么多,那么就涉及到分表。
    • 如果业务量真的太大了,主键的自增id涨到头了,会发生什么?报错:主键冲突。
    • 网络依赖性:高度依赖网络,所有ID生成请求都需要访问中央数据库。

正是由于这众多缺点,所以工作中是不用它的,不过可以作为一种思路。

五:使用Redis实现分布式ID生成

Redis是一个高性能的键值数据库,它可以用于生成分布式唯一标识符。

实现原理

  • 利用Redis的原子操作:Redis提供了原子性的INCRINCRBY命令,可用于生成唯一的递增数值。这些数值可以作为唯一ID

  • 分布式环境中的应用:在分布式环境中,可以部署多个Redis实例。每个实例可以独立生成ID,或者通过配置不同的起始值和步长来确保ID的全局唯一性。

  • 高性能和可靠性:Redis的高性能确保了即使在高负载下也能快速生成ID,同时Redis的持久化和复制特性提高了系统的可靠性。

优缺点分析

  • 优点:快速、简单且易于扩展;支持高并发环境。

  • 缺点:依赖于外部服务(Redis),需要管理和维护额外的基础设施。

  • 网络依赖性:高度依赖网络。

六:使用数据库分段(Leaf-segment)

这种方法涉及到使用数据库来生成和管理ID段,以实现分布式ID的生成。

实现原理

  • ID段的分配:在数据库中预设一个起始ID和步长,每个应用实例或服务节点从数据库中获取一个ID段,然后在本地生成ID,直到该段用完再从数据库获取新的段。

  • 减少数据库交互:每个节点在消耗完一个ID段之前不需要与数据库交互,这减少了数据库的负载,并提高了ID生成的效率。

  • 避免冲突:通过确保每个节点获取的ID段不重叠,可以保证生成的ID在全系统范围内是唯一的。

优缺点分析

  • 优点:减少了对数据库的频繁访问,提高了性能;适合在分布式系统中使用。

  • 缺点:管理复杂性:管理不同的ID段需要额外的逻辑和数据库设计。可能的ID浪费:如果某个服务或实例在用完其ID段之前下线或重启,可能导致分配的ID未被完全使用。

  • 网络依赖性:对网络的依赖相对较低,只在申请新的ID段时需要访问数据库。

实际例子
把数据库自增主键换成了计数法。每个业务分配一个biz_tag、并记录各业务最大id(max_id)、号段跨度(step)等数据。这样每次取号只需要更新biz_tag对应的max_id,就可以拿到stepid。比如业务business_a当前max_id3000,取了1000个号在本地使用,使用完后,可以更新DB中对应的max_id4000,这样business_a本地就有1000个新的id可以用了

76.Go分布式ID总览,go,golang,分布式

优点

  1. 除了拥有自增ID的优点之外,在性能上比自增ID更好,扩展灵活。
  2. 使用灵活、可配置性强。
  3. 缓存机制,突发状况下短时间内能保证服务正常运转。

缺点

  1. id是有序自增,容易暴露信息,不可用于订单。
  2. leaf的缓存ID用完再去获取新号段的间隙,性能会有波动。
  3. 强依赖DB

七 :增强版Leaf-segment

增强版是对上面描述的缺点2进行的改进——双cache。在leafID消耗到一定百分比时,常驻的后台进程会预先去号段服务获取新的号段并缓存。具体消耗百分比、及号段step根据业务消耗速度来定。

76.Go分布式ID总览,go,golang,分布式

八:Tinyid

和增强版Leaf-segment类似,也是号段模式,提前加载号段。

76.Go分布式ID总览,go,golang,分布式

九: 分布式键生成服务(如Zookeeper、etcd)

分布式协调服务在集群中生成唯一ID

ZooKeeper是使用了Znode结构中的Zxid实现顺序增IDZookeeper类似一个文件系统,每个节点都有唯一路径名(Znode),Zxid是个全局事务计数器,每个节点发生变化都会记录响应的版本(Zxid),这个版本号是全局唯一且顺序递增的。这种架构还是出现了ZooKeeper的单点问题。

实现原理

  • 工作方式:这些服务提供了分布式锁和原子性操作来生成唯一的ID

  • 协调机制:通过集群协调机制保证ID的唯一性和顺序性。

优缺点

  • 优点:提供了更加灵活和可控的ID生成方式,适合分布式环境。

  • 缺点:引入外部依赖,增加了系统的复杂性。

  • 网络依赖性:高度依赖网络,因为它们需要在多个节点之间协调ID的生成。文章来源地址https://www.toymoban.com/news/detail-823848.html

到了这里,关于76.Go分布式ID总览的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【Go语言实战】(26) 分布式搜索引擎

    github地址:https://github.com/CocaineCong/tangseng 详细介绍地址:https://cocainecong.github.io/tangseng 这两周我也抽空录成视频发到B站的~ 本来应该10月份就要发了,结果一鸽就鸽到现在hhhh,有兴趣的同学也可留意一下~ gin作为http框架,grpc作为rpc框架,etcd作为服务发现。 总体服务分成

    2024年02月03日
    浏览(31)
  • 对象存储分布式代理-go初学者的开源练手项目

    最近写了一个go语言练手项目osproxy和osproxy-grpc,代码已完全开源到github。 相信不少接触go语言的读者,都是被它\\\"极简协程\\\",“高并发”,\\\"高性能\\\"的特性所吸引,我也不例外,想着学完之后,能快速上手享受一把。 但当我看完基本语法,想找个练手项目时,才发现github上大

    2024年02月08日
    浏览(45)
  • go-zero学习 第六章 分布式事务dtm

    Go开源说第十七期 分布式事务DTM DTM开源项目文档:官方文档 分布式事务解决方案:7种常见解决方案汇总 msg :二阶段消息,适合不需要回滚的全局事务。 saga :适合需要支持回滚的全局事务。 tcc :适合一致性要求较高的全局事务。 xa :适合性能要求不高,没有行锁争抢的

    2024年02月15日
    浏览(44)
  • 【go项目-geecache】动手写分布式缓存 day2 - 单机并发缓存

    [ Github- geecache ](luckly-0/geecache (github.com)) 收获总结: 了解接口的使用场景,它和函数之间的差别和优略势 测试文件要以_test结尾 系统设计要严谨,要考虑后期的拓展性和维护 ,比如load函数考虑到了分布式场景 数据结构之间的封装 sync.Mutex 互斥锁 如果我们要是实现并发缓存

    2023年04月18日
    浏览(86)
  • 【go项目-geecache】动手写分布式缓存 - day6 - 防止缓存击穿

    【go项目-geecache】动手写分布式缓存 - day1 - 实现LRU算法 【go项目-geecache】动手写分布式缓存 - day2 - 单机并发缓存 【go项目-geecache】动手写分布式缓存 - day3 - HTTP 服务端 【go项目-geecache】动手写分布式缓存 - day4 - 一致性哈希(hash) 【go项目-geecache】动手写分布式缓存 - day5 - 分布

    2023年04月20日
    浏览(39)
  • Asynq: 基于Redis实现的Go生态分布式任务队列和异步处理库

    Asynq [1] 是一个Go实现的分布式任务队列和异步处理库,基于redis,类似Ruby的 sidekiq [2] 和Python的 celery [3] 。Go生态类似的还有 machinery [4] 和goworker 同时提供一个WebUI asynqmon [5] ,可以源码形式安装或使用Docker image, 还可以和Prometheus集成 docker run --rm --name asynqmon -p 8080:8080 hibiken/as

    2024年02月14日
    浏览(41)
  • DAY 76 分布式监控平台:zabbix

    市场上常用的监控软件: 传统运维:zabbix、 Nagios 云原生环境: Prometheus (go语言开发的) 作为一个运维,需要会使用监控系统查看服务器状态以及网站流量指标,利用监控系统的数据去了解上线发布的结果,和网站的健康状态 利用一个优秀的监控软件,我们可以: 通过一

    2024年02月08日
    浏览(42)
  • 全面掌握 Jaeger 分布式调用链路跟踪理论和实战,Go 为所有使用 go-resty 库发起 HTTP 请求集成链路跟踪 jaeger(附源码)

    全面掌握 Jaeger 分布式调用链路跟踪理论和实战,Go 为所有使用 go-resty 库发起 HTTP 请求集成链路跟踪 jaeger(附源码)。 介绍一个开源的分布式跟踪系统 Jaeger,首先从理论基础知识开始学习,将学习如何在 HTTP 请求中集成链路跟踪,以及如何在 GORM 框架实现,最后学习 go-ze

    2024年02月13日
    浏览(48)
  • 【分布式】分布式ID

    分布式场景下,一张表可能分散到多个数据结点上。因此需要一些分布式ID的解决方案。 分布式ID需要有几个特点: 全局唯一(必要) :在多个库的主键放在一起也不会重复 有序(必要) :避免频繁触发索引重建 信息安全 :ID连续,可以根据订单编号计算一天的单量,造成

    2024年02月07日
    浏览(49)
  • 【分布式技术专题】「分布式ID系列」百度开源的分布式高性能的唯一ID生成器UidGenerator

    UidGenerator是什么 UidGenerator是百度开源的一款分布式高性能的唯一ID生成器,更详细的情况可以查看官网集成文档 uid-generator是基于Twitter开源的snowflake算法实现的一款唯一主键生成器(数据库表的主键要求全局唯一是相当重要的)。要求java8及以上版本。 snowflake算法 Snowflake算法描

    2024年02月04日
    浏览(61)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包