• 【分布式ID】雪花、TDDLSEQUENCE、UUID


    分布式ID

      要保证id不重复,主要从三方面考虑,时间维度、空间维度、原子维度;

      时间维度:时间维度不重复,例如今天和明天不能重复,所以时间是可以加入id的一种因子;

      空间维度:不同的机器,不同的环境生成的id不同,所以mac地址,机房地址等,都可以作为空间维度的区分;

      原子维度:主要是线程的安全性,也就是递增的保证,我们一般称之为 序列 ,例如数据库的自增id,就仅仅是原子维度;

      讨论完分布式id后,我们讨论一下非功能性的一些要求:

      高可用:可以随时提供服务,不间断;

      低延迟:id获取速度要快;

      高并发:支持高QPS;

    雪花算法

      雪花算法生成的ID是一个64 bit的long型的数字且按时间趋势递增。大致由首位无效符(0,1bit)、时间戳差值(41bit)、机器编码(10bit),序列号四部分组成(12bit)。

    • 雪花算法是可以保证一定程度上的递增
    • 雪花算法基于高并发下,时间的最小精度可以生产最多的序列号个数决定了不重复率

    UUID

    • 基本自带实现,同样考虑:时间、空间、序列号维度,有多个实现版本。
    • 无序,长度太大,对数据库不友好。

    TDDL

      分布式序列:阿里内部的较多用法,主要是解决一个序列原子性的问题,首先它的序列是维护在数据中的,用一张表表示,每次获取一定个数(如10000)的序列到进程中使用。

      为了保证高可用,和高并发,维护序列的必然不能只是一张表,所以可以搞n张表,每一个数据库表,维护一个sequence,所以就有了单个步长和组步长的说法。

      序列的获取如下所示:

      时间维度:既然用了序列,因为序列的位数是有限的,那么必然就会重复,所以同样的,在同一个时刻内,一个序列不能做了一次重复,但一般如果时间精确到某一个维度,现实的重复可能性基本为0。但不管如何,时间维度是必须要加的

    • 递增,做数据库主键比较合适
    • 高可用,不会单机崩溃出现问题
    • 由于获取sequence是一次性获取多个在进场内部使用的,所以很有可能会造成空洞问题

    纯序列

      Redis:集群高可用,但是部署复杂,维护难;可读性好,容易记住,存储占有空间少。
     
      SQL自增:实现简单,但是性能不高;可读性好,容易记住,存储占有空间少。
     
     
  • 相关阅读:
    Mvc+三层(批量添加、删除、修改)
    js中判断复选款是否选中
    EF的优缺点
    Git tricks: Unstaging files
    Using Git Submodules
    English Learning
    wix xslt for adding node
    The breakpoint will not currently be hit. No symbols have been loaded for this document."
    Use XSLT in wix
    mfc110ud.dll not found
  • 原文地址:https://www.cnblogs.com/iCanhua/p/16198853.html
Copyright © 2020-2023  润新知