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

1. 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。
     • 优点：简单直接，能保证唯一性。
     • 缺点：性能较差，因为涉及到数据库的插入和删除操作，并且需要频繁访问数据库，不适合高并发场景。

2. 不能使用自增ID的原因（在分布式架构下）

   • 数据合并问题：在分布式环境中，可能存在多个数据库实例或者节点。如果每个节点都使用自增ID，当需要将这些节点的数据合并到一起时，就会出现ID冲突的问题。例如，节点A生成的自增ID范围是1 - 1000，节点B生成的自增ID范围是1 - 1000，当合并数据时，就会有很多相同的ID，导致数据混乱。
   • 水平扩展受限：自增ID依赖于单个数据库实例的顺序生成机制。在分布式架构下，如果要进行水平扩展，添加新的数据库节点时，难以保证新节点生成的ID与现有节点的ID不冲突且能保持全局唯一。

3. 不能使用UUID的原因（在某些情况下）

   • 存储空间较大：UUID是128位的通用唯一识别码，相比其他的ID生成方式（如32位或64位的雪花算法生成的ID），UUID占用的存储空间更大。在数据库中，如果大量使用UUID作为主键，会增加数据库的存储成本。
   • 性能问题：UUID是无序的，在数据库中，尤其是在使用基于B - Tree结构（如MySQL的InnoDB存储引擎）的索引时，无序的UUID会导致索引树的频繁分裂和重组。这是因为新插入的UUID可能随机分布在索引树的各个位置，而不像自增ID那样顺序插入。这种频繁的分裂和重组会降低数据库的插入性能，并且随着数据量的增加，这种性能影响会更加明显。