分布式ID策略
為什么要用分布式ID？
在我們業務資料量不大的時候，單庫單表完全可以支撐現有業務，資料再大一點搞個 MySQL 主從同步讀寫分離也能對付，
但隨著資料日漸增長，主從同步也扛不住了，就需要對資料庫進行分庫分表，但分庫分表后需要有一個唯一ID來標識一條資料，資料庫的自增ID顯然不能滿足需求；特別一點的如訂單、優惠券也都需要有唯一ID做標識，此時一個能夠生成全域唯一ID的系統是非常必要的，那么這個全域唯一ID就叫分布式ID，
分布式ID要滿足什么特性？
唯一性：必須保證ID是全域性唯一的，這是基本要求；
高性能：高可用低延時，ID生成回應要塊，否則反倒會成為業務瓶頸；
高可用：需要保證高并發下的可用性，除了對 ID 號碼自身的要求，業務還對 ID 生成系統的可用性要求極高；
遞增性：生成的 ID 需要按照某種規則有序，便于資料庫的寫入和排序操作；
安全性：
- id的規律性太明顯，用戶就會知曉該店鋪每天的訂單量，暴露隱私；
- 受單表資料量的限制，訂單的資料量較大，訂單量隨著時間會不斷增大，如果訂單量已經達到了上億，那單張表保存不了這么龐大的資料，如果分為多張表來保存訂單資料，多張表訂單ID都是從1開始增長，那ID一定會出現重復，
分布式ID生成方式有哪些？
1、UUID
UUID，它有著全球唯一的特性，UUID可以做分布式ID，但并不推薦使用，
UUID 的標準形式為 32 個十六進制陣列成的字串，且分割為五個部分
String uuid = UUID.randomUUID().toString().replaceAll("-","");;
UUID的生成簡單到只有一行代碼，輸出結果 2fedcf5e38ac4bf78f6ab6035005eea2，但UUID卻并不適用于實際的業務需求，像用作訂單號UUID這樣的字串沒有絲毫的意義，看不出和訂單相關的有用資訊；而對于資料庫來說，用作業務主鍵ID，它不僅太長而且還是字串，存盤性能差，查詢也很耗時，所以不推薦用作分布式ID，
優點：
生成足夠簡單，本地生成無網路消耗，具有唯一性；
缺點：
- 無序的字串；
- 沒有具體的業務含義；
- 長度過長，16 位元組128位，36位長度的字串（加上四個“-”），存盤以及查詢對MySQL的性能消耗較大，(MySQL官方明確建議主鍵盡量越短越好，作為資料庫主鍵
UUID的無序性會導致資料位置頻繁變動，嚴重影響性能)；
2、資料庫自增ID
基于資料庫的auto_increment自增ID完全可以充當分布式ID，在資料庫內可以保證唯一，
優點：
實作簡單，ID單調自增，數值型別查詢速度快；
缺點：
DB單點存在宕機風險，無法扛住高并發場景，因為資料庫要承載每秒幾萬并發，肯定是不現實的，
3、資料庫集群自增ID
上面的單點資料庫方式不可取，那對上邊的方式做一些高可用優化，換成主從模式集群，害怕一個主節點掛掉沒法用，那就做雙主模式集群，也就是兩個 Mysql 實體都能單獨的生產自增ID，
那這樣還會有個問題，兩個MySQL實體的自增ID都從1開始，會生成重復的ID怎么辦？
解決方案：設定不同的起始值和相同的自增步長
舉個例子：
# MySQL_1 配置
set @@auto_increment_offset = 1; -- 起始值
set @@auto_increment_increment = 3; -- 步長
# MySQL_2 配置
set @@auto_increment_offset = 2; -- 起始值
set @@auto_increment_increment = 3; -- 步長
# MySQL_3 配置
set @@auto_increment_offset = 3; -- 起始值
set @@auto_increment_increment = 3; -- 步長
這樣兩個MySQL實體的自增ID分別就是：
1、4、7、10...
2、5、8、11...
3、6、9、12...
但是存在一個問題，如果后續需要擴展集群，增加一臺MySQL機器，就需要修改前3臺MySQL實體的起始值和步長，
優點：
解決DB單點問題；
缺點：
不利于后續擴容，而且實際上單個資料庫自身壓力還是大，依舊無法滿足高并發場景，
4、Redis自增ID
string有自增特性，能夠確保唯一性，利用redis的 incr命令實作ID的原子性自增，
127.0.0.1:6379> set seq_id 1 // 初始化自增ID為1
OK
127.0.0.1:6379> incr seq_id // 增加1，并回傳遞增后的數值
(integer) 2
用redis實作需要注意一點，要考慮到redis持久化的問題，redis有兩種持久化方式RDB和AOF：
RDB會定時打一個快照進行持久化，假如連續自增但redis沒及時持久化，而這會Redis掛掉了，重啟Redis后會出現ID重復的情況；AOF會對每條寫命令進行持久化，即使Redis掛掉了也不會出現ID重復的情況，但由于incr命令的特殊性，會導致Redis重啟恢復的資料時間過長，
5、雪花演算法
雪花演算法（Snowflake）是twitter公司內部分布式專案采用的ID生成演算法，
相比 UUID 無序生成的id而言，雪花演算法是有序的，而且都是由數字組成，雪花id最大為64位，符合java中long的長度64位，拋去一位符號位，那么最大為263，
Snowflake生成的是Long型別的ID，一個Long型別占8個位元組，每個位元組占8位元，也就是說一個Long型別占64個位元，
Snowflake ID組成結構：正數位（占1位元）+ 時間戳（占41位元）+ 資料中心（機房）（占5位元）+ 機器ID（占5位元）+ 自增值（占12位元），總共64位元組成的一個Long型別，
- 第一個bit位（1bit）：Java中long的最高位是符號位代表正負，正數是0，負數是1，一般生成ID都為正數，所以默認為0；
- 時間戳部分（41bit）：毫秒級的時間，不建議存當前時間戳，而是用（當前時間戳 - 固定開始時間戳）的差值，可以使產生的ID從更小的值開始；41位的時間戳可以使用69年，(1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69年
- 作業機器id（10bit）：也被叫做
workId，這個可以靈活配置，機房或者機器號組合都可以； - 序列號部分（12bit），自增值支持同一毫秒內同一個節點可以生成
2^12 = 4096個ID；
根據這個演算法的邏輯，只需要將這個演算法用Java語言實作出來，封裝為一個工具方法，那么各個業務應用可以直接使用該工具方法來獲取分布式ID，只需保證每個業務應用有自己的作業機器id即可，而不需要單獨去搭建一個獲取分布式ID的應用，
改進：
在生成唯一id的時候，一般都需要指定一個表名，比如說訂單表的唯一id，所以上面那64個bit中，代表機房的那5個bit，可以使用業務表名稱來替代，比如用00001代表的是訂單表，因為其實很多時候，機房并沒有那么多（大廠除外），所以前5個bit用做機房id可能意義不是太大，
這樣就可以做到，snowflake演算法系統的每一臺機器，對一個業務表，在某一毫秒內，可以生成一個唯一的id，一毫秒內生成很多id，用最后12個bit來區分序號對待，
Java版本的雪花演算法實作：
/**
* Twitter的SnowFlake演算法,使用SnowFlake演算法生成一個整數，然后轉化為62進制變成一個短地址URL
*
* https://github.com/beyondfengyu/SnowFlake
*/
public class SnowFlakeShortUrl {
/**
* 起始的時間戳
*/
private final static long START_TIMESTAMP = 1480166465631L;
/**
* 每一部分占用的位數
*/
private final static long SEQUENCE_BIT = 12; //序列號占用的位數
private final static long MACHINE_BIT = 5; //機器標識占用的位數
private final static long DATA_CENTER_BIT = 5; //資料中心占用的位數
/**
* 每一部分的最大值
*/
private final static long MAX_SEQUENCE = -1L ^ (-1L << SEQUENCE_BIT);
private final static long MAX_MACHINE_NUM = -1L ^ (-1L << MACHINE_BIT);
private final static long MAX_DATA_CENTER_NUM = -1L ^ (-1L << DATA_CENTER_BIT);
/**
* 每一部分向左的位移
*/
private final static long MACHINE_LEFT = SEQUENCE_BIT;
private final static long DATA_CENTER_LEFT = SEQUENCE_BIT + MACHINE_BIT;
private final static long TIMESTAMP_LEFT = DATA_CENTER_LEFT + DATA_CENTER_BIT;
private long dataCenterId; //資料中心
private long machineId; //機器標識
private long sequence = 0L; //序列號
private long lastTimeStamp = -1L; //上一次時間戳
private long getNextMill() {
long mill = getNewTimeStamp();
while (mill <= lastTimeStamp) {
mill = getNewTimeStamp();
}
return mill;
}
private long getNewTimeStamp() {
return System.currentTimeMillis();
}
/**
* 根據指定的資料中心ID和機器標志ID生成指定的序列號
*
* @param dataCenterId 資料中心ID
* @param machineId 機器標志ID
*/
public SnowFlakeShortUrl(long dataCenterId, long machineId) {
if (dataCenterId > MAX_DATA_CENTER_NUM || dataCenterId < 0) {
throw new IllegalArgumentException("DtaCenterId can't be greater than MAX_DATA_CENTER_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 currTimeStamp = getNewTimeStamp();
if (currTimeStamp < lastTimeStamp) {
throw new RuntimeException("Clock moved backwards. Refusing to generate id");
}
if (currTimeStamp == lastTimeStamp) {
//相同毫秒內，序列號自增
sequence = (sequence + 1) & MAX_SEQUENCE;
//同一毫秒的序列數已經達到最大
if (sequence == 0L) {
currTimeStamp = getNextMill();
}
} else {
//不同毫秒內，序列號置為0
sequence = 0L;
}
lastTimeStamp = currTimeStamp;
return (currTimeStamp - START_TIMESTAMP) << TIMESTAMP_LEFT //時間戳部分
| dataCenterId << DATA_CENTER_LEFT //資料中心部分
| machineId << MACHINE_LEFT //機器標識部分
| sequence; //序列號部分
}
public static void main(String[] args) {
SnowFlakeShortUrl snowFlake = new SnowFlakeShortUrl(2, 3);
for (int i = 0; i < (1 << 4); i++) {
//10進制
System.out.println(snowFlake.nextId());
}
}
}
參考
https://mp.weixin.qq.com/s/c1DsYzBrZ6nfJi4z8xEIvg
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/509571.html
標籤：其他