數(shù)據(jù)在分片時，典型的是分庫分表膏斤，就有一個全局ID生成的問題盅惜。
單純的生成全局ID并不是什么難題中剩，但是生成的ID通常要滿足分片的一些要求：
1 不能有單點(diǎn)故障。
2 以時間為序酷窥，或者ID里包含時間咽安。這樣一是可以少一個索引，二是冷熱數(shù)據(jù)容易分離蓬推。
3 可以控制ShardingId妆棒。比如某一個用戶的文章要放在同一個分片內(nèi)，這樣查詢效率高沸伏，修改也容易糕珊。
4 不要太長，最好64bit毅糟。使用long比較好操作红选，如果是96bit，那就要各種移位相當(dāng)?shù)牟环奖隳妨恚€有可能有些組件不能支持這么大的ID喇肋。
一 twitter
twitter在把存儲系統(tǒng)從MySQL遷移到Cassandra的過程中由于Cassandra沒有順序ID生成機(jī)制，于是自己開發(fā)了一套全局唯一ID生成服務(wù)：Snowflake迹辐。
1 41位的時間序列（精確到毫秒蝶防，41位的長度可以使用69年）
2 10位的機(jī)器標(biāo)識（10位的長度最多支持部署1024個節(jié)點(diǎn)）
3 12位的計(jì)數(shù)順序號（12位的計(jì)數(shù)順序號支持每個節(jié)點(diǎn)每毫秒產(chǎn)生4096個ID序號） 最高位是符號位，始終為0明吩。
優(yōu)點(diǎn)：高性能间学，低延遲；獨(dú)立的應(yīng)用印荔；按時間有序低葫。 缺點(diǎn)：需要獨(dú)立的開發(fā)和部署。
2 來自Flicker的解決方案
因?yàn)镸ySQL本身支持auto_increment操作仍律，很自然地嘿悬，我們會想到借助這個特性來實(shí)現(xiàn)這個功能。
Flicker在解決全局ID生成方案里就采用了MySQL自增長ID的機(jī)制（auto_increment + replace into + MyISAM）水泉。一個生成64位ID方案具體就是這樣的：
先創(chuàng)建單獨(dú)的數(shù)據(jù)庫(eg:ticket)善涨，然后創(chuàng)建一個表：
CREATE TABLE Tickets64 (
id bigint(20) unsigned NOT NULL auto_increment,
stub char(1) NOT NULL default '',
PRIMARY KEY (id),
UNIQUE KEY stub (stub)
) ENGINE=MyISAM
當(dāng)我們插入記錄后主到，執(zhí)行SELECT * from Tickets64，查詢結(jié)果就是這樣的：
+-------------------+------+
| id | stub |
+-------------------+------+
| 72157623227190423 | a |
+-------------------+------+
在我們的應(yīng)用端需要做下面這兩個操作躯概，在一個事務(wù)會話里提交：
REPLACE INTO Tickets64 (stub) VALUES ('a');
SELECT LAST_INSERT_ID();
這樣我們就能拿到不斷增長且不重復(fù)的ID了。
到上面為止畔师，我們只是在單臺數(shù)據(jù)庫上生成ID娶靡，從高可用角度考慮，接下來就要解決單點(diǎn)故障問題：Flicker啟用了兩臺數(shù)據(jù)庫服務(wù)器來生成ID看锉，通過區(qū)分auto_increment的起始值和步長來生成奇偶數(shù)的ID姿锭。
TicketServer1:
auto-increment-increment = 2
auto-increment-offset = 1
TicketServer2:
auto-increment-increment = 2
auto-increment-offset = 2
最后，在客戶端只需要通過輪詢方式取ID就可以了伯铣。
優(yōu)點(diǎn)：充分借助數(shù)據(jù)庫的自增ID機(jī)制呻此，提供高可靠性，生成的ID有序腔寡。
缺點(diǎn)：占用兩個獨(dú)立的MySQL實(shí)例焚鲜，有些浪費(fèi)資源，成本較高
三 UUID
UUID生成的是length=32的16進(jìn)制格式的字符串放前，如果回退為byte數(shù)組共16個byte元素忿磅，即UUID是一個128bit長的數(shù)字，
一般用16進(jìn)制表示凭语。
算法的核心思想是結(jié)合機(jī)器的網(wǎng)卡葱她、當(dāng)?shù)貢r間、一個隨即數(shù)來生成UUID似扔。
從理論上講吨些，如果一臺機(jī)器每秒產(chǎn)生10000000個GUID，則可以保證（概率意義上）3240年不重復(fù)
優(yōu)點(diǎn)：
（1）本地生成ID炒辉，不需要進(jìn)行遠(yuǎn)程調(diào)用豪墅，時延低
（2）擴(kuò)展性好，基本可以認(rèn)為沒有性能上限
缺點(diǎn)：
（1）無法保證趨勢遞增
（2）uuid過長辆脸，往往用字符串表示但校，作為主鍵建立索引查詢效率低，常見優(yōu)化方案為“轉(zhuǎn)化為兩個uint64整數(shù)存儲”或者“折半存儲”（折半后不能保證唯一性）
四 基于redis的分布式ID生成器
首先啡氢，要知道redis的EVAL状囱，EVALSHA命令：
原理
利用redis的lua腳本執(zhí)行功能，在每個節(jié)點(diǎn)上通過lua腳本生成唯一ID倘是。
生成的ID是64位的：
使用41 bit來存放時間亭枷，精確到毫秒，可以使用41年搀崭。
使用12 bit來存放邏輯分片ID叨粘，最大分片ID是4095
使用10 bit來存放自增長ID猾编，意味著每個節(jié)點(diǎn)，每毫秒最多可以生成1024個ID
比如GTM時間 Fri Mar 13 10:00:00 CST 2015 升敲，它的距1970年的毫秒數(shù)是 1426212000000答倡，假定分片ID是53，自增長序列是4驴党，則生成的ID是：
5981966696448054276 = 1426212000000 << 22 + 53 << 10 + 41
redis提供了TIME命令瘪撇，可以取得redis服務(wù)器上的秒數(shù)和微秒數(shù)。因些lua腳本返回的是一個四元組港庄。
second, microSecond, partition, seq
客戶端要自己處理倔既，生成最終ID。
((second * 1000 + microSecond / 1000) << (12 + 10)) + (shardId << 10) + seq;
