微服务+分库分表的自增主键ID该如何设计？

一. 前言

分布式ID 是分布式系统里面非常重要的一个组成部分，那么我们在设计分布式ID的时候，需要考虑什么问题呢？

• ❓简单结构下是怎么实现 ID 的控制的？

• 单实例系统 ：通过时间戳，系统内自增，上锁等方式保证ID的唯一性

• 单数据库实例 : 通过自增字段（不谈性能）实现ID的唯一

• ❓微服务 + 分库分表了 ，又该如何进行控制？

• 问题 ： 单个系统没办法直接感知到其他系统的ID情况，哪怕通信也要付出极大的代价

二. 来理解分布式ID的原则

2.1 分布式 ID 的本质是什么 ？

• 全局唯一 ： 要保证的是在任何场景下，任何系统，任何库，同一业务场景中生成的ID一定是唯一的

• 递增 ： 有的文章里面会谈到单调递增和趋势递增，这讲到的是2个维度：

• 一个要求ID是有序增长的（趋势递增 ，用于排序）

• 一个是要求ID是正向增长的（单调递增 ，下一个一定比上一个大）

• 无规则 ： 无规则是指不能按照MySQL主键自增这种方式进行 + 1 自增，简单的自增方式会带来安全层面的风险

最近无意间获得一份阿里大佬写的刷题笔记，一下子打通了我的任督二脉，进大厂原来没那么难。这是大佬写的，7701页的BAT大佬写的刷题笔记，让我offer拿到手软

2.2 有哪些相同性质的问题？

对于分布式 ID 的实现 ，在某些思路上和很多业务是通用的 ，例如 ：

• 订单编号的生成逻辑 ：有序 + 反映时间
• 券码的生成逻辑 ： 有序 + 不可推测
• 动态码 ： 付款码，会员动态码等等

这些码的生产一般都会包含上述的2项原则，一定会要求全局唯一 ，同时根据情况来进行有序或者无序的控制。

其实无序一般也是看起来无序，在底层逻辑的生成上不可能完全无序，否则总会出现冲突的场景。

2.3 分布式 ID 的根本实现方式是什么 ？

ID的生成本质上只需要关注两个核心 ：

• 区域的划分 ：我们需要保证每台机器是一个固定的区域 ，一般称之为机器ID
• 锁的控制 ： 不止是不同服务之间的分布式锁，还包括同一个服务的线程锁

来简单解读下 ，服务之间的通信很消耗资源 ，所以能不通信实现分布式ID的生成效率是最高的 ， 那么一般会在服务启动的时候就计算出对应的工作区间。

同时要理解的是 ，锁往往和性能是对立关系，锁越多 ，则性能会相对越差，所以如何控制锁的粒度，则是分布式ID生成的一大核心。

三. 来探讨一下实现的思路

3.1 常规的分布式ID 算法

可用但是有限制的方案

// 简易版 - 基于时间戳的ID算法 ：
- 方案 ： 使用时间戳作为ID的前缀，然后通过机器的IP地址或MAC地址进行哈希计算得到剩余部分
- 问题 ： 过于简单 , 只能实现单机毫秒级的并发
// 低效版 - 数据库自增
- 方案 ： 没有方案 ，交给数据库来
- 问题 ： 性能低 ， 不支持分库分表
// 升级版 - 基于UUID
- 方案 ：
    - 基于时间的UUID：主要依赖当前的时间戳及机器mac地址，因此可以保证全球唯一性