当前位置：首页 > article >正文

如何设置MySQL分布式架构主键ID，为什么不能使用自增ID或者UUID做主键？

article 2024/10/4 1:35:56

MySQL分布式架构主键ID的设置方法

雪花算法（Snowflake）

原理：雪花算法是一种生成分布式唯一ID的算法。它由64位二进制数组成，结构如下：1位符号位（固定为0） + 41位时间戳（表示从一个固定时间开始到现在的毫秒数）+ 10位工作机器ID（可以用来区分不同的机器或节点）+ 12位序列号（在同一毫秒内对不同的ID请求进行区分）。
优点：生成的ID是趋势递增的，具有唯一性，并且在分布式系统中各个节点可以独立生成，不需要依赖中心节点协调。同时，由于包含时间戳信息，在一定程度上可以根据ID判断生成的先后顺序。

示例实现（以Java为例）：

public class SnowflakeIdGenerator {
    // 起始的时间戳
    private static final long START_STAMP = 1480166465631L;
    // 每一部分占用的位数
    private static final long SEQUENCE_BIT = 12;
    private static final long MACHINE_BIT = 10;
    private static final long TIMESTAMP_BIT = 41;
    // 每一部分的最大值
    private static final long MAX_SEQUENCE = -1L ^ (-1L << SEQUENCE_BIT);
    private static final long MAX_MACHINE_NUM = -1L ^ (-1L << MACHINE_BIT);
    // 每一部分向左的位移
    private static final long MACHINE_LEFT = SEQUENCE_BIT;
    private static final long TIMESTAMP_LEFT = SEQUENCE_BIT + MACHINE_BIT;
    private long machineId;
    private long sequence = 0L;
    private long lastStamp = -1L;

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

    public synchronized long nextId() {
        long currStamp = getNewStamp();
        if (currStamp < lastStamp) {
            throw new RuntimeException("Clock moved backwards.  Refusing to generate id");
        }
        if (currStamp == lastStamp) {
            sequence = (sequence + 1) & MAX_SEQUENCE;
            if (sequence == 0L) {
                currStamp = getNextStamp(lastStamp);
            }
        } else {
            sequence = 0L;
        }
        lastStamp = currStamp;
        return (currStamp - START_STAMP) << TIMESTAMP_LEFT
                | machineId << MACHINE_LEFT
                | sequence;
    }

    private long getNextStamp(long lastStamp) {
        long stamp = getNewStamp();
        while (stamp <= lastStamp) {
            stamp = getNewStamp();
        }
        return stamp;
    }

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

基于数据库的全局唯一ID生成器
- 原理：利用数据库的特性来生成唯一ID。例如，在MySQL中可以创建一个专门用于生成ID的表，表中只有一个字段（如id字段），每次需要生成ID时，通过对这个表进行插入操作（插入一条空记录），然后获取这个新插入记录的自增ID值，再将这个记录删除。这样就可以得到一个全局唯一的ID。
- 优点：简单直接，能保证唯一性。
- 缺点：性能较差，因为涉及到数据库的插入和删除操作，并且需要频繁访问数据库，不适合高并发场景。

不能使用自增ID的原因（在分布式架构下）
- 数据合并问题：在分布式环境中，可能存在多个数据库实例或者节点。如果每个节点都使用自增ID，当需要将这些节点的数据合并到一起时，就会出现ID冲突的问题。例如，节点A生成的自增ID范围是1 - 1000，节点B生成的自增ID范围是1 - 1000，当合并数据时，就会有很多相同的ID，导致数据混乱。
- 水平扩展受限：自增ID依赖于单个数据库实例的顺序生成机制。在分布式架构下，如果要进行水平扩展，添加新的数据库节点时，难以保证新节点生成的ID与现有节点的ID不冲突且能保持全局唯一。
不能使用UUID的原因（在某些情况下）
- 存储空间较大：UUID是128位的通用唯一识别码，相比其他的ID生成方式（如32位或64位的雪花算法生成的ID），UUID占用的存储空间更大。在数据库中，如果大量使用UUID作为主键，会增加数据库的存储成本。
- 性能问题：UUID是无序的，在数据库中，尤其是在使用基于B - Tree结构（如MySQL的InnoDB存储引擎）的索引时，无序的UUID会导致索引树的频繁分裂和重组。这是因为新插入的UUID可能随机分布在索引树的各个位置，而不像自增ID那样顺序插入。这种频繁的分裂和重组会降低数据库的插入性能，并且随着数据量的增加，这种性能影响会更加明显。