乐趣区

关于java:分布式ID的解决方案

jiezi

常见 ID 解决方案的比照

形容 长处 毛病 毛病
UUID UUID 是通用惟一标识码的缩写，其目标是上分布式系统中的所有元素都有惟一的辨识信息，而不须要通过地方控制器来指定惟一标识。 1. 升高全局节点的压力，使得主键生成速度更快；2. 生成的主键全局惟一；3. 跨服务器合并数据不便 1. UUID 占用 16 个字符，空间占用较多；2. 不是递增有序的数字，数据写入 IO 随机性很大，且索引效率降落
数据库主键自增 MySQL 数据库设置主键且主键主动增长 1. INT 和 BIGINT 类型占用空间较小；2. 主键主动增长，IO 写入连续性好；3. 数字类型查问速度优于字符串 1. 并发性能不高，受限于数据库性能；2. 分库分表，须要革新，简单；3. 自增：数据量泄露
Redis 自增 Redis 计数器，原子性自增 应用内存，并发性能好 1. 数据失落；2. 自增：数据量泄露
雪花算法（snowflake） 赫赫有名的雪花算法，分布式 ID 的经典解决方案 1. 不依赖内部组件；2. 性能好 1. 时钟回拨；2. 趋势递增不是相对递增；3. 不能在一台服务器上部署多个分布式 ID 服务；

风行的分布式 ID 解决方案

雪花算法（snowflake）

雪花算法是由符号位 + 工夫戳 + 工作机器 id+ 序列号组成

解释

  1. 符号位为 0，0 示意负数，ID 为负数。
  2. 工夫戳位不必多说，用来寄存工夫戳，单位是 ms。
  3. 工作机器 id 位用来寄存机器的 id，通常分为 5 个区域位 + 5 个服务器标识位。

Twitter 的 Snowflake 算法 Java 实现

public class SnowFlake {

    /**
     * 起始的工夫戳
     */
    private final static long START_STMP = 1480166465631L;

    /**
     * 每一部分占用的位数
     */
    private final static long SEQUENCE_BIT = 12; // 序列号占用的位数
    private final static long MACHINE_BIT = 5;   // 机器标识占用的位数
    private final static long DATACENTER_BIT = 5;// 数据中心占用的位数

    /**
     * 每一部分的最大值
     */
    private final static long MAX_DATACENTER_NUM = -1L ^ (-1L << DATACENTER_BIT);
    private final static long MAX_MACHINE_NUM = -1L ^ (-1L << MACHINE_BIT);
    private final static long MAX_SEQUENCE = -1L ^ (-1L << SEQUENCE_BIT);

    /**
     * 每一部分向左的位移
     */
    private final static long MACHINE_LEFT = SEQUENCE_BIT;
    private final static long DATACENTER_LEFT = SEQUENCE_BIT + MACHINE_BIT;
    private final static long TIMESTMP_LEFT = DATACENTER_LEFT + DATACENTER_BIT;

    private long datacenterId;  // 数据中心
    private long machineId;     // 机器标识
    private long sequence = 0L; // 序列号
    private long lastStmp = -1L;// 上一次工夫戳

    public SnowFlake(long datacenterId, long machineId) {if (datacenterId > MAX_DATACENTER_NUM || datacenterId < 0) {throw new IllegalArgumentException("datacenterId can't be greater than MAX_DATACENTER_NUM or less than 0");
        }
        if (machineId > MAX_MACHINE_NUM || machineId < 0) {throw new IllegalArgumentException("machineId can't be greater than MAX_MACHINE_NUM or less than 0");
        }
        this.datacenterId = datacenterId;
        this.machineId = machineId;
    }

    /**
     * 产生下一个 ID
     *
     * @return
     */
    public synchronized long nextId() {long currStmp = getNewstmp();
        if (currStmp < lastStmp) {throw new RuntimeException("Clock moved backwards.  Refusing to generate id");
        }

        if (currStmp == lastStmp) {
            // 雷同毫秒内，序列号自增
            sequence = (sequence + 1) & MAX_SEQUENCE;
            // 同一毫秒的序列数曾经达到最大
            if (sequence == 0L) {currStmp = getNextMill();
            }
        } else {
            // 不同毫秒内，序列号置为 0
            sequence = 0L;
        }

        lastStmp = currStmp;

        return (currStmp - START_STMP) << TIMESTMP_LEFT // 工夫戳局部
                | datacenterId << DATACENTER_LEFT       // 数据中心局部
                | machineId << MACHINE_LEFT             // 机器标识局部
                | sequence;                             // 序列号局部
    }

    private long getNextMill() {long mill = getNewstmp();
        while (mill <= lastStmp) {mill = getNewstmp();
        }
        return mill;
    }

    private long getNewstmp() {return System.currentTimeMillis();
    }

    public static void main(String[] args) {SnowFlake snowFlake = new SnowFlake(2, 3);

        for (int i = 0; i < (1 << 12); i++) {System.out.println(snowFlake.nextId());
        }

    }
}

号段模式

号段模式能够了解为从数据库批量的获取自增 ID，每次从数据库取出一个号段范畴，例如 (1,1000] 代表 1000 个 ID，具体的业务服务将本号段，生成 1~1000 的自增 ID 并加载到内存。表构造如下：

CREATE TABLE id_generator (id int(10) NOT NULL,
  max_id bigint(20) NOT NULL COMMENT '以后最大 id',
  step int(20) NOT NULL COMMENT '号段的布长',
  biz_type    int(20) NOT NULL COMMENT '业务类型',
  version int(20) NOT NULL COMMENT '版本号',
  PRIMARY KEY (`id`)
)
  • biz_type：代表不同业务类型
  • max_id：以后最大的可用 id
  • step：代表号段的长度
  • version：是一个乐观锁，每次都更新 version，保障并发时数据的正确性

等这批号段 ID 用完，再次向数据库申请新号段，对 max_id 字段做一次 update 操作，update max_id= max_id + step，update 胜利则阐明新号段获取胜利，新的号段范畴是(max_id ,max_id +step]。

update id_generator set max_id = #{max_id+step}, version = version + 1 where version = # {version} and biz_type = XXX

因为多业务端可能同时操作，所以采纳版本号 version 乐观锁形式更新，这种 分布式 ID生成形式不强依赖于数据库，不会频繁的拜访数据库，对数据库的压力小很多。

其余解决方案

  1. 滴滴出品（TinyID）Github 地址：https://github.com/didi/tinyid
  2. 百度（Uidgenerator）GitHub 地址：https://github.com/baidu/uid-…
  3. 美团（Leaf）github 地址：https://github.com/Meituan-Di…
退出移动版