分布式ID解決方案

在分布式系統中，當資料庫資料量達到一定量級的時候，需要進行資料拆分、分庫分表操作，傳統使用方式的資料庫自有的自增特性產生的主鍵id已不能滿足拆分的需求，它只能保證在單個表中唯一，所以需要乙個在分布式環境下都能使用的全域性唯一id。

uuid

uuid是指在一台機器上生成的數字，主要由當前日期和時間、時鐘序列和全域性唯一的ieee機器識別號組合而成，由一組32位數的16進製制數字所構成，是故uuid理論上的總數為16^32=2^128，約等於3.4 x 10^38。也就是說若每納秒產生1兆個uuid，要花100億年才會將所有uuid用完。

優點：簡單易用、高效；

缺點：32位的長度太長；使用16進製表示，可讀性差；無序，不利於排序。

twitter-snowflake

snowflake是twitter公司設計的一套全域性唯一id生成演算法。根據演算法設計生成的id共64位，第一位始終為0暫未使用，接著的41位為時間序列（精確到毫秒，41位的長度可以使用69年），緊接著的10位為機器標識（10位的長度最多支援部署1024個節點），最後的12位為計數順序號（12位的計數順序號支援每個節點每毫秒產生4096個id序號）。

優點：有序、高效；

缺點：自主開發。

mysql

既然傳統使用方式下的資料庫自增特性不能滿足需求，不如設計單獨的庫表，單獨提供產生全域性id的服務，利用auto_increment特性和replace into語法，例如建立如下表：

create table distribute_id

id bigint(25) unsigned not null auto_increment comment '全域性id',

purposes varchar(30) not null default '' comment '用途',

primary key (id),

unique key uk_purposes (purposes)

) engine=innodb;;

當需要產生全域性id時，執行如下sql：

replace into distribute_id (purposes) values ('payment');

select last_insert_id();

當然這些都是資料庫層面的操作，需要將其封裝成服務介面，呼叫介面即可獲取id。如果需要防止單點故障問題，可以部署兩個資料庫服務，同時給兩個資料庫的兩個表設定不同的初始值和自增步長。

優點：資料庫自增機制，可靠、有序；

缺點：如果多伺服器只提供獲取id服務，會產生資源浪費；每次都從資料庫獲取，不高效。

mysql+快取

使用mysql實現的方式有兩個缺點，乙個是產生資源浪費，乙個是不高效。其實，按實際來說，能用前來解決的問題就不算問題，所以第乙個不需要太關心，那就剩下效率的問題。既然不高效的原因是每次都運算元據庫，那麼就減少運算元據庫，每次取批量的資料，並結合快取使用。可以建立如下表：

create table distribute_id

purposes varchar(30) not null default '' comment '用途',

increment int not null default 1 comment 『增長步長',

min_value bigint not null default 1 comment '最小值',

max_value bigint not null comment '最大值',

unique key uk_purposes (purposes)

) engine=innodb;

在使用之前初始化資料，設定增長步長、最小值和最大值，編寫類用於封裝這些資料，以purposes值為key，類例項為value，將key-value存放到快取中，可以使用堆快取，也可以使用分布式快取如redis，下面以堆快取為例。

public class distributeid implements serializable inally {

lock.unlock();

如果需要防止單點故障問題，部署兩個需要注意設定不同步長，同時**中的自增操作需要換成getandadd。

分布式ID解決方案

分布式ID生成器解決方案

分布式全域性ID的多種解決方案

分布式事務解決方案

分布式ID解決方案

分布式ID生成器解決方案

分布式全域性ID的多種解決方案

分布式事務解決方案

相關推薦