面試題
分庫分表之后,id 主鍵如何處理?(唯一性,排序等)
面試官心理分析
其實這是分庫分表之后你必然要面對的一個問題,就是 id 咋生成?因為要是分成多個表之后,每個表都是從 1 開始累加,那肯定不對啊,需要一個全局唯一的 id 來支持,排序問題等。所以這都是你實際生產環境中必須考慮的問題。
面試題剖析
基於數據庫的實現方案
數據庫自增 id
這個就是說你的系統里每次得到一個 id,都是往一個庫的一個表里插入一條沒什么業務含義的數據,然后獲取一個數據庫自增的一個 id。拿到這個 id 之后再往對應的分庫分表里去寫入。
這個方案的好處就是方便簡單,誰都會用;缺點就是單庫生成自增 id,要是高並發的話,就會有瓶頸的;如果你硬是要改進一下,那么就專門開一個服務出來,這個服務每次就拿到當前 id 最大值,然后自己遞增幾個 id,一次性返回一批 id,然后再把當前最大 id 值修改成遞增幾個 id 之后的一個值;但是無論如何都是基於單個數據庫。
適合的場景:你分庫分表就倆原因,要不就是單庫並發太高,要不就是單庫數據量太大;除非是你並發不高,但是數據量太大導致的分庫分表擴容,你可以用這個方案,因為可能每秒最高並發最多就幾百,那么就走單獨的一個庫和表生成自增主鍵即可。
設置數據庫 sequence 或者表自增字段步長
可以通過設置數據庫 sequence 或者表的自增字段步長來進行水平伸縮。
比如說,現在有 8 個服務節點,每個服務節點使用一個 sequence 功能來產生 ID,每個 sequence 的起始 ID 不同,並且依次遞增,步長都是 8。
適合的場景:在用戶防止產生的 ID 重復時,這種方案實現起來比較簡單,也能達到性能目標。但是服務節點固定,步長也固定,將來如果還要增加服務節點,就不好搞了。
UUID
好處就是本地生成,不要基於數據庫來了;不好之處就是,UUID 太長了、占用空間大,作為主鍵性能太差了;更重要的是,UUID 不具有有序性,會導致 B+ 樹索引在寫的時候有過多的隨機寫操作(連續的 ID 可以產生部分順序寫),還有,由於在寫的時候不能產生有順序的 append 操作,而需要進行 insert 操作,將會讀取整個 B+ 樹節點到內存,在插入這條記錄后會將整個節點寫回磁盤,這種操作在記錄占用空間比較大的情況下,性能下降明顯。
適合的場景:如果你是要隨機生成個什么文件名、編號之類的,你可以用 UUID,但是作為主鍵是不能用 UUID 的。
UUID.randomUUID().toString().replace(“-”, “”) -> sfsdf23423rr234sfdaf
獲取系統當前時間
這個就是獲取當前時間即可,但是問題是,並發很高的時候,比如一秒並發幾千,會有重復的情況,這個是肯定不合適的。基本就不用考慮了。
適合的場景:一般如果用這個方案,是將當前時間跟很多其他的業務字段拼接起來,作為一個 id,如果業務上你覺得可以接受,那么也是可以的。你可以將別的業務字段值跟當前時間拼接起來,組成一個全局唯一的編號。
snowflake 算法
snowflake 算法是 twitter 開源的分布式 id 生成算法,采用 Scala 語言實現,是把一個 64 位的 long 型的 id,1 個 bit 是不用的 + 用其中的 41 bit 作為毫秒數 + 用 10 bit 作為工作機器 id + 12 bit 作為序列號。
- 1 bit:不用,為啥呢?因為二進制里第一個 bit 為如果是 1,那么都是負數,但是我們生成的 id 都是正數,所以第一個 bit 統一都是 0。
- 41 bit:表示的是時間戳,單位是毫秒。41 bit 可以表示的數字多達
2^41 - 1
,也就是可以標識2^41 - 1
個毫秒值,換算成年就是表示69年的時間。 - 10 bit:記錄工作機器 id,代表的是這個服務最多可以部署在 2^10台機器上哪,也就是1024台機器。但是 10 bit 里 5 個 bit 代表機房 id,5 個 bit 代表機器 id。意思就是最多代表
2^5
個機房(32個機房),每個機房里可以代表2^5
個機器(32台機器)。 - 12 bit:這個是用來記錄同一個毫秒內產生的不同 id,12 bit 可以代表的最大正整數是
2^12 - 1 = 4096
,也就是說可以用這個 12 bit 代表的數字來區分同一個毫秒內的 4096 個不同的 id。
0 | 0001100 10100010 10111110 10001001 01011100 00 | 10001 | 1 1001 | 0000 00000000
public class IdWorker {
private long workerId;
private long datacenterId;
private long sequence;
public IdWorker(long workerId, long datacenterId, long sequence) {
// sanity check for workerId
// 這兒不就檢查了一下,要求就是你傳遞進來的機房id和機器id不能超過32,不能小於0
if (workerId > maxWorkerId || workerId < 0) {
throw new IllegalArgumentException(
String.format("worker Id can't be greater than %d or less than 0", maxWorkerId));
}
if (datacenterId > maxDatacenterId || datacenterId < 0) {
throw new IllegalArgumentException(
String.format("datacenter Id can't be greater than %d or less than 0", maxDatacenterId));
}
System.out.printf(
"worker starting. timestamp left shift %d, datacenter id bits %d, worker id bits %d, sequence bits %d, workerid %d",
timestampLeftShift, datacenterIdBits, workerIdBits, sequenceBits, workerId);
this.workerId = workerId;
this.datacenterId = datacenterId;
this.sequence = sequence;
}
private long twepoch = 1288834974657L;
private long workerIdBits = 5L;
private long datacenterIdBits = 5L;
// 這個是二進制運算,就是 5 bit最多只能有31個數字,也就是說機器id最多只能是32以內
private long maxWorkerId = -1L ^ (-1L << workerIdBits);
// 這個是一個意思,就是 5 bit最多只能有31個數字,機房id最多只能是32以內
private long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);
private long sequenceBits = 12L;
private long workerIdShift = sequenceBits;
private long datacenterIdShift = sequenceBits + workerIdBits;
private long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;
private long sequenceMask = -1L ^ (-1L << sequenceBits);
private long lastTimestamp = -1L;
public long getWorkerId() {
return workerId;
}
public long getDatacenterId() {
return datacenterId;
}
public long getTimestamp() {
return System.currentTimeMillis();
}
public synchronized long nextId() {
// 這兒就是獲取當前時間戳,單位是毫秒
long timestamp = timeGen();
if (timestamp < lastTimestamp) {
System.err.printf("clock is moving backwards. Rejecting requests until %d.", lastTimestamp);
throw new RuntimeException(String.format(
"Clock moved backwards. Refusing to generate id for %d milliseconds", lastTimestamp - timestamp));
}
if (lastTimestamp == timestamp) {
// 這個意思是說一個毫秒內最多只能有4096個數字
// 無論你傳遞多少進來,這個位運算保證始終就是在4096這個范圍內,避免你自己傳遞個sequence超過了4096這個范圍
sequence = (sequence + 1) & sequenceMask;
if (sequence == 0) {
timestamp = tilNextMillis(lastTimestamp);
}
} else {
sequence = 0;
}
// 這兒記錄一下最近一次生成id的時間戳,單位是毫秒
lastTimestamp = timestamp;
// 這兒就是將時間戳左移,放到 41 bit那兒;
// 將機房 id左移放到 5 bit那兒;
// 將機器id左移放到5 bit那兒;將序號放最后12 bit;
// 最后拼接起來成一個 64 bit的二進制數字,轉換成 10 進制就是個 long 型
return ((timestamp - twepoch) << timestampLeftShift) | (datacenterId << datacenterIdShift)
| (workerId << workerIdShift) | sequence;
}
private long tilNextMillis(long lastTimestamp) {
long timestamp = timeGen();
while (timestamp <= lastTimestamp) {
timestamp = timeGen();
}
return timestamp;
}
private long timeGen() {
return System.currentTimeMillis();
}
// ---------------測試---------------
public static void main(String[] args) {
IdWorker worker = new IdWorker(1, 1, 1);
for (int i = 0; i < 30; i++) {
System.out.println(worker.nextId());
}
}
}
怎么說呢,大概這個意思吧,就是說 41 bit 是當前毫秒單位的一個時間戳,就這意思;然后 5 bit 是你傳遞進來的一個機房 id(但是最大只能是 32 以內),另外 5 bit 是你傳遞進來的機器 id(但是最大只能是 32 以內),剩下的那個 12 bit序列號,就是如果跟你上次生成 id 的時間還在一個毫秒內,那么會把順序給你累加,最多在 4096 個序號以內。
所以你自己利用這個工具類,自己搞一個服務,然后對每個機房的每個機器都初始化這么一個東西,剛開始這個機房的這個機器的序號就是 0。然后每次接收到一個請求,說這個機房的這個機器要生成一個 id,你就找到對應的 Worker 生成。
利用這個 snowflake 算法,你可以開發自己公司的服務,甚至對於機房 id 和機器 id,反正給你預留了 5 bit + 5 bit,你換成別的有業務含義的東西也可以的。
當然,你也可以用 : 1 個 bit 是不用的 + 用其中的 41 bit 作為毫秒數 + 12 bit 作為序列號 + 用 10 bit 作為工作機器 id,或者顛倒兌換一下順序,怎么使用根據你自己的業務需要進行組合配用。
這個 snowflake 算法相對來說還是比較靠譜的,所以你要真是搞分布式 id 生成,如果是高並發啥的,那么用這個應該性能比較好,一般每秒幾萬並發的場景,也足夠你用了。
本文在米兜公眾號鏈接:
https://mp.weixin.qq.com/s/mt8bVpM57SsI-nvTRKxSKg
出處:https://www.cnblogs.com/midoujava/p/11610492.html
============================================================================================
如果僅僅是保證唯一性,自己寫一個算法和規則,根據這個規則各個模塊自己生成編號;
比如,之前寫過一個簡單的示例,使用xml文件作為配置生成固定格式的序列號的配置文件,程序根據算法生成指定格式的字符串。類似日期的格式化函數。
但是往往很多時候又需要把多份數據匯總、聚合等,還有排序等情況,這個時候需要根據生成的記錄進行排序(也可考慮根據插入時間排序,各有利弊),還要考慮精度:有時、分、秒、厘秒、毫秒、微妙等等,當多台服務器進行時間同步到時候,還有需要靠網絡延遲等情況。
所有,要根據自己的業務需要和自己能夠承受的容錯率來確定。
============================================================================================
本文已經收錄自 JavaGuide (60k+ Star【Java學習+面試指南】 一份涵蓋大部分Java程序員所需要掌握的核心知識。)
本文授權轉載自:https://juejin.im/post/5d6fc8eff265da03ef7a324b ,作者:1點25。
ID是數據的唯一標識,傳統的做法是利用UUID和數據庫的自增ID,在互聯網企業中,大部分公司使用的都是Mysql,並且因為需要事務支持,所以通常會使用Innodb存儲引擎,UUID太長以及無序,所以並不適合在Innodb中來作為主鍵,自增ID比較合適,但是隨着公司的業務發展,數據量將越來越大,需要對數據進行分表,而分表后,每個表中的數據都會按自己的節奏進行自增,很有可能出現ID沖突。這時就需要一個單獨的機制來負責生成唯一ID,生成出來的ID也可以叫做分布式ID,或全局ID。下面來分析各個生成分布式ID的機制。
這篇文章並不會分析的特別詳細,主要是做一些總結,以后再出一些詳細某個方案的文章。
數據庫自增ID
第一種方案仍然還是基於數據庫的自增ID,需要單獨使用一個數據庫實例,在這個實例中新建一個單獨的表:
表結構如下:
CREATE DATABASE `SEQID`;
CREATE TABLE SEQID.SEQUENCE_ID (
id bigint(20) unsigned NOT NULL auto_increment,
stub char(10) NOT NULL default '',
PRIMARY KEY (id),
UNIQUE KEY stub (stub)
) ENGINE=MyISAM;
可以使用下面的語句生成並獲取到一個自增ID
begin;
replace into SEQUENCE_ID (stub) VALUES ('anyword');
select last_insert_id();
commit;
stub字段在這里並沒有什么特殊的意義,只是為了方便的去插入數據,只有能插入數據才能產生自增id。而對於插入我們用的是replace,replace會先看是否存在stub指定值一樣的數據,如果存在則先delete再insert,如果不存在則直接insert。
這種生成分布式ID的機制,需要一個單獨的Mysql實例,雖然可行,但是基於性能與可靠性來考慮的話都不夠,業務系統每次需要一個ID時,都需要請求數據庫獲取,性能低,並且如果此數據庫實例下線了,那么將影響所有的業務系統。
為了解決數據庫可靠性問題,我們可以使用第二種分布式ID生成方案。
數據庫多主模式
如果我們兩個數據庫組成一個主從模式集群,正常情況下可以解決數據庫可靠性問題,但是如果主庫掛掉后,數據沒有及時同步到從庫,這個時候會出現ID重復的現象。我們可以使用雙主模式集群,也就是兩個Mysql實例都能單獨的生產自增ID,這樣能夠提高效率,但是如果不經過其他改造的話,這兩個Mysql實例很可能會生成同樣的ID。需要單獨給每個Mysql實例配置不同的起始值和自增步長。
第一台Mysql實例配置:
set @@auto_increment_offset = 1; -- 起始值
set @@auto_increment_increment = 2; -- 步長
第二台Mysql實例配置:
set @@auto_increment_offset = 2; -- 起始值
set @@auto_increment_increment = 2; -- 步長
經過上面的配置后,這兩個Mysql實例生成的id序列如下: mysql1,起始值為1,步長為2,ID生成的序列為:1,3,5,7,9,... mysql2,起始值為2,步長為2,ID生成的序列為:2,4,6,8,10,...
對於這種生成分布式ID的方案,需要單獨新增一個生成分布式ID應用,比如DistributIdService,該應用提供一個接口供業務應用獲取ID,業務應用需要一個ID時,通過rpc的方式請求DistributIdService,DistributIdService隨機去上面的兩個Mysql實例中去獲取ID。
實行這種方案后,就算其中某一台Mysql實例下線了,也不會影響DistributIdService,DistributIdService仍然可以利用另外一台Mysql來生成ID。
但是這種方案的擴展性不太好,如果兩台Mysql實例不夠用,需要新增Mysql實例來提高性能時,這時就會比較麻煩。
現在如果要新增一個實例mysql3,要怎么操作呢? 第一,mysql1、mysql2的步長肯定都要修改為3,而且只能是人工去修改,這是需要時間的。 第二,因為mysql1和mysql2是不停在自增的,對於mysql3的起始值我們可能要定得大一點,以給充分的時間去修改mysql1,mysql2的步長。 第三,在修改步長的時候很可能會出現重復ID,要解決這個問題,可能需要停機才行。
為了解決上面的問題,以及能夠進一步提高DistributIdService的性能,如果使用第三種生成分布式ID機制。
號段模式
我們可以使用號段的方式來獲取自增ID,號段可以理解成批量獲取,比如DistributIdService從數據庫獲取ID時,如果能批量獲取多個ID並緩存在本地的話,那樣將大大提供業務應用獲取ID的效率。
比如DistributIdService每次從數據庫獲取ID時,就獲取一個號段,比如(1,1000],這個范圍表示了1000個ID,業務應用在請求DistributIdService提供ID時,DistributIdService只需要在本地從1開始自增並返回即可,而不需要每次都請求數據庫,一直到本地自增到1000時,也就是當前號段已經被用完時,才去數據庫重新獲取下一號段。
所以,我們需要對數據庫表進行改動,如下:
CREATE TABLE id_generator (
id int(10) NOT NULL,
current_max_id bigint(20) NOT NULL COMMENT '當前最大id',
increment_step int(10) NOT NULL COMMENT '號段的長度',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
這個數據庫表用來記錄自增步長以及當前自增ID的最大值(也就是當前已經被申請的號段的最后一個值),因為自增邏輯被移到DistributIdService中去了,所以數據庫不需要這部分邏輯了。
這種方案不再強依賴數據庫,就算數據庫不可用,那么DistributIdService也能繼續支撐一段時間。但是如果DistributIdService重啟,會丟失一段ID,導致ID空洞。
為了提高DistributIdService的高可用,需要做一個集群,業務在請求DistributIdService集群獲取ID時,會隨機的選擇某一個DistributIdService節點進行獲取,對每一個DistributIdService節點來說,數據庫連接的是同一個數據庫,那么可能會產生多個DistributIdService節點同時請求數據庫獲取號段,那么這個時候需要利用樂觀鎖來進行控制,比如在數據庫表中增加一個version字段,在獲取號段時使用如下SQL:
update id_generator set current_max_id=#{newMaxId}, version=version+1 where version = #{version}
因為newMaxId是DistributIdService中根據oldMaxId+步長算出來的,只要上面的update更新成功了就表示號段獲取成功了。
為了提供數據庫層的高可用,需要對數據庫使用多主模式進行部署,對於每個數據庫來說要保證生成的號段不重復,這就需要利用最開始的思路,再在剛剛的數據庫表中增加起始值和步長,比如如果現在是兩台Mysql,那么 mysql1將生成號段(1,1001],自增的時候序列為1,3,4,5,7.... mysql1將生成號段(2,1002],自增的時候序列為2,4,6,8,10...
更詳細的可以參考滴滴開源的TinyId:github.com/didi/tinyid…
在TinyId中還增加了一步來提高效率,在上面的實現中,ID自增的邏輯是在DistributIdService中實現的,而實際上可以把自增的邏輯轉移到業務應用本地,這樣對於業務應用來說只需要獲取號段,每次自增時不再需要請求調用DistributIdService了。
雪花算法
上面的三種方法總的來說是基於自增思想的,而接下來就介紹比較著名的雪花算法-snowflake。
我們可以換個角度來對分布式ID進行思考,只要能讓負責生成分布式ID的每台機器在每毫秒內生成不一樣的ID就行了。
snowflake是twitter開源的分布式ID生成算法,是一種算法,所以它和上面的三種生成分布式ID機制不太一樣,它不依賴數據庫。
核心思想是:分布式ID固定是一個long型的數字,一個long型占8個字節,也就是64個bit,原始snowflake算法中對於bit的分配如下圖:
- 第一個bit位是標識部分,在java中由於long的最高位是符號位,正數是0,負數是1,一般生成的ID為正數,所以固定為0。
- 時間戳部分占41bit,這個是毫秒級的時間,一般實現上不會存儲當前的時間戳,而是時間戳的差值(當前時間-固定的開始時間),這樣可以使產生的ID從更小值開始;41位的時間戳可以使用69年,(1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69年
- 工作機器id占10bit,這里比較靈活,比如,可以使用前5位作為數據中心機房標識,后5位作為單機房機器標識,可以部署1024個節點。
- 序列號部分占12bit,支持同一毫秒內同一個節點可以生成4096個ID
根據這個算法的邏輯,只需要將這個算法用Java語言實現出來,封裝為一個工具方法,那么各個業務應用可以直接使用該工具方法來獲取分布式ID,只需保證每個業務應用有自己的工作機器id即可,而不需要單獨去搭建一個獲取分布式ID的應用。
snowflake算法實現起來並不難,提供一個github上用java實現的:github.com/beyondfengy…
在大廠里,其實並沒有直接使用snowflake,而是進行了改造,因為snowflake算法中最難實踐的就是工作機器id,原始的snowflake算法需要人工去為每台機器去指定一個機器id,並配置在某個地方從而讓snowflake從此處獲取機器id。
但是在大廠里,機器是很多的,人力成本太大且容易出錯,所以大廠對snowflake進行了改造。
百度(uid-generator)
github地址:uid-generator
uid-generator使用的就是snowflake,只是在生產機器id,也叫做workId時有所不同。
uid-generator中的workId是由uid-generator自動生成的,並且考慮到了應用部署在docker上的情況,在uid-generator中用戶可以自己去定義workId的生成策略,默認提供的策略是:應用啟動時由數據庫分配。說的簡單一點就是:應用在啟動時會往數據庫表(uid-generator需要新增一個WORKER_NODE表)中去插入一條數據,數據插入成功后返回的該數據對應的自增唯一id就是該機器的workId,而數據由host,port組成。
對於uid-generator中的workId,占用了22個bit位,時間占用了28個bit位,序列化占用了13個bit位,需要注意的是,和原始的snowflake不太一樣,時間的單位是秒,而不是毫秒,workId也不一樣,同一個應用每重啟一次就會消費一個workId。
美團(Leaf)
github地址:Leaf
美團的Leaf也是一個分布式ID生成框架。它非常全面,即支持號段模式,也支持snowflake模式。號段模式這里就不介紹了,和上面的分析類似。
Leaf中的snowflake模式和原始snowflake算法的不同點,也主要在workId的生成,Leaf中workId是基於ZooKeeper的順序Id來生成的,每個應用在使用Leaf-snowflake時,在啟動時都會都在Zookeeper中生成一個順序Id,相當於一台機器對應一個順序節點,也就是一個workId。
總結
總得來說,上面兩種都是自動生成workId,以讓系統更加穩定以及減少人工成功。
Redis
這里額外再介紹一下使用Redis來生成分布式ID,其實和利用Mysql自增ID類似,可以利用Redis中的incr命令來實現原子性的自增與返回,比如:
127.0.0.1:6379> set seq_id 1 // 初始化自增ID為1
OK
127.0.0.1:6379> incr seq_id // 增加1,並返回
(integer) 2
127.0.0.1:6379> incr seq_id // 增加1,並返回
(integer) 3
使用redis的效率是非常高的,但是要考慮持久化的問題。Redis支持RDB和AOF兩種持久化的方式。
RDB持久化相當於定時打一個快照進行持久化,如果打完快照后,連續自增了幾次,還沒來得及做下一次快照持久化,這個時候Redis掛掉了,重啟Redis后會出現ID重復。
AOF持久化相當於對每條寫命令進行持久化,如果Redis掛掉了,不會出現ID重復的現象,但是會由於incr命令過得,導致重啟恢復數據時間過長。