一攒暇，唯一ID的特性：
整個(gè)系統(tǒng)ID唯一
ID是數(shù)字類型曹傀，而且是趨勢(shì)遞增的
ID簡(jiǎn)短，查詢效率快
什么是遞增狭莱？
如：第一次生成的ID為12僵娃，下一次生成的ID是13，再下一次生成的ID是14腋妙。這個(gè)就是生成ID遞增默怨。
什么是趨勢(shì)遞增？
如：在一段時(shí)間內(nèi)辉阶，生成的ID是遞增的趨勢(shì)先壕。如：再一段時(shí)間內(nèi)生成的ID在【0瘩扼，1000】之間，過段時(shí)間生成的ID在【1000垃僚，2000】之間集绰。但在【0-1000】區(qū)間內(nèi)的時(shí)候，ID生成有可能第一次是12谆棺，第二次是10栽燕，第三次是14。
二改淑、分布式ID的幾種生成方案
2.1碍岔、UUID
這個(gè)方案是小伙伴們第一個(gè)能過考慮到的方案
優(yōu)點(diǎn)：
代碼實(shí)現(xiàn)簡(jiǎn)單。
本機(jī)生成朵夏，沒有性能問題
因?yàn)槭侨蛭ㄒ坏腎D蔼啦，所以遷移數(shù)據(jù)容易
缺點(diǎn)：
每次生成的ID是無序的，無法保證趨勢(shì)遞增
UUID的字符串存儲(chǔ)仰猖，查詢效率慢
存儲(chǔ)空間大
ID本事無業(yè)務(wù)含義捏肢，不可讀
應(yīng)用場(chǎng)景：
類似生成token令牌的場(chǎng)景
不適用一些要求有趨勢(shì)遞增的ID場(chǎng)景
此UUID方案是不適用老顧的需求。
實(shí)現(xiàn)代碼：
<pre xml:space="preserve" style="margin: 0px; padding: 0px; border: 0px; line-height: 1.57143em; font-family: Monaco, Courier, monospace; color: rgb(56, 56, 56); font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;">import java.util.UUID;
public class Uuid {
public static void main(String[] args) {
for (int i = 0; i < 5; i++) {
//注意replaceAll前面的是正則表達(dá)式
String uuid = UUID.randomUUID().toString().replaceAll("-","");
System.out.println(uuid);
}
}
}</pre>
2.2饥侵、MySQL主鍵自增
這個(gè)方案就是利用了MySQL的主鍵自增auto_increment鸵赫，默認(rèn)每次ID加1。
優(yōu)點(diǎn)：
數(shù)字化躏升，id遞增
查詢效率高
具有一定的業(yè)務(wù)可讀
缺點(diǎn)：
存在單點(diǎn)問題辩棒，如果mysql掛了，就沒法生成iD了
數(shù)據(jù)庫壓力大膨疏，高并發(fā)抗不住
2.3一睁、MySQL多實(shí)例主鍵自增
這個(gè)方案就是解決mysql的單點(diǎn)問題，在auto_increment基本上面佃却，設(shè)置step步長
[圖片上傳失敗...(image-b6deb9-1570518549756)]
每臺(tái)的初始值分別為1,2,3...N卖局，步長為N（這個(gè)案例步長為4）
優(yōu)點(diǎn)：
- 解決了單點(diǎn)問題
缺點(diǎn)：
- 一旦把步長定好后，就無法擴(kuò)容双霍；而且單個(gè)數(shù)據(jù)庫的壓力大，數(shù)據(jù)庫自身性能無法滿足高并發(fā)
應(yīng)用場(chǎng)景：
- 數(shù)據(jù)不需要擴(kuò)容的場(chǎng)景
此方案也不滿足老顧的需求批销，因?yàn)椴环奖銛U(kuò)容（記住這個(gè)方案洒闸，嘿嘿）
2.4、雪花snowflake算法
這個(gè)算法網(wǎng)上介紹了很多均芽，老顧這里就不詳細(xì)介紹丘逸。雪花算法生成64位的二進(jìn)制正整數(shù)，然后轉(zhuǎn)換成10進(jìn)制的數(shù)掀宋。64位二進(jìn)制數(shù)由如下部分組成：
1位標(biāo)識(shí)符：始終是0
41位時(shí)間戳：41位時(shí)間截不是存儲(chǔ)當(dāng)前時(shí)間的時(shí)間截深纲，而是存儲(chǔ)時(shí)間截的差值（當(dāng)前時(shí)間截 - 開始時(shí)間截 )得到的值仲锄，這里的的開始時(shí)間截，一般是我們的id生成器開始使用的時(shí)間湃鹊，由我們程序來指定的
10位機(jī)器標(biāo)識(shí)碼：可以部署在1024個(gè)節(jié)點(diǎn)儒喊，如果機(jī)器分機(jī)房（IDC）部署，這10位可以由 5位機(jī)房ID + 5位機(jī)器ID 組成
12位序列：毫秒內(nèi)的計(jì)數(shù)币呵，12位的計(jì)數(shù)順序號(hào)支持每個(gè)節(jié)點(diǎn)每毫秒(同一機(jī)器怀愧，同一時(shí)間截)產(chǎn)生4096個(gè)ID序號(hào)
優(yōu)點(diǎn)：
此方案每秒能夠產(chǎn)生409.6萬個(gè)ID，性能快
時(shí)間戳在高位余赢，自增序列在低位芯义，整個(gè)ID是趨勢(shì)遞增的，按照時(shí)間有序遞增
靈活度高妻柒，可以根據(jù)業(yè)務(wù)需求扛拨，調(diào)整bit位的劃分，滿足不同的需求
缺點(diǎn)：
- 依賴機(jī)器的時(shí)鐘举塔，如果服務(wù)器時(shí)鐘回?fù)馨缶瑫?huì)導(dǎo)致重復(fù)ID生成
在分布式場(chǎng)景中，服務(wù)器時(shí)鐘回?fù)軙?huì)經(jīng)常遇到啤贩，一般存在10ms之間的回?fù)艽海恍』锇閭兙驼f這點(diǎn)10ms，很短可以不考慮吧痹屹。但此算法就是建立在毫秒級(jí)別的生成方案章郁，一旦回?fù)埽秃苡锌赡艽嬖谥貜?fù)ID志衍。
此方案暫不符合老顧的需求（嘿嘿暖庄，看看怎么優(yōu)化這個(gè)方案，小伙伴們先記茁シ尽）
2.5培廓、Redis生成方案
利用redis的incr原子性操作自增，一般算法為：
年份 + 當(dāng)天距當(dāng)年第多少天 + 天數(shù) + 小時(shí) + redis自增
優(yōu)點(diǎn)：
- 有序遞增春叫，可讀性強(qiáng)
缺點(diǎn)：
- 占用帶寬肩钠，每次要向redis進(jìn)行請(qǐng)求
整體測(cè)試了這個(gè)性能如下：
需求：同時(shí)10萬個(gè)請(qǐng)求獲取ID
1、并發(fā)執(zhí)行完耗時(shí)：9s左右
2暂殖、單任務(wù)平均耗時(shí)：74ms
3价匠、單線程最小耗時(shí)：不到1ms
4、單線程最大耗時(shí)：4.1s
性能還可以呛每，如果對(duì)性能要求不是太高的話踩窖，這個(gè)方案基本符合老顧的要求。
但不完全符合業(yè)務(wù)老顧希望id從 1 開始趨勢(shì)遞增晨横。（當(dāng)然算法可以調(diào)整為 就一個(gè) redis自增洋腮，不需要什么年份箫柳，多少天等）。
2.6啥供、小結(jié)
以上介紹了常見的幾種分布式ID生成方案悯恍。一線大廠的分布式ID方案絕沒有這個(gè)簡(jiǎn)單，他們對(duì)高并發(fā)滤灯，高可用的要求很高坪稽。
如Redis方案中，每次都要去Redis去請(qǐng)求鳞骤，有網(wǎng)絡(luò)請(qǐng)求耗時(shí)窒百，并發(fā)強(qiáng)依賴了Redis。這個(gè)設(shè)計(jì)是有風(fēng)險(xiǎn)的豫尽，一旦Redis掛了篙梢，整個(gè)系統(tǒng)不可用。
而且一線大廠也會(huì)考慮到ID安全性的問題美旧，如：Redis方案中渤滞，用戶是可以預(yù)測(cè)下一個(gè)ID號(hào)是多少，因?yàn)樗惴ㄊ沁f增的榴嗅。
這樣的話競(jìng)爭(zhēng)對(duì)手第一天中午12點(diǎn)下個(gè)訂單妄呕，就可以看到平臺(tái)的訂單ID是多少，第二天中午12點(diǎn)再下一單嗽测，又平臺(tái)訂單ID到多少绪励。這樣就可以猜到平臺(tái)1天能產(chǎn)生多少訂單了，這個(gè)是絕對(duì)不允許的唠粥，公司絕密啊疏魏。
三、一線大廠是如何設(shè)計(jì)的呢?
一線大廠的設(shè)計(jì)思路其實(shí)和小伙伴們思路差不多晤愧，只是多想了1～2層大莫，設(shè)計(jì)上面多了1～2個(gè)環(huán)節(jié)。
3.1官份、改造數(shù)據(jù)庫主鍵自增
上述我們介紹了利用數(shù)據(jù)庫的自增主鍵的特性只厘，可以實(shí)現(xiàn)分布式ID；這個(gè)ID比較簡(jiǎn)短明了舅巷，適合做userId懈凹，正好符合如何永不遷移數(shù)據(jù)和避免熱點(diǎn)? 根據(jù)服務(wù)器指標(biāo)分配數(shù)據(jù)量(揭秘篇)文章中的ID的需求。但這個(gè)方案有嚴(yán)重的問題：
一旦步長定下來悄谐，不容易擴(kuò)容
數(shù)據(jù)庫壓力山大
小伙伴們看看怎么優(yōu)化這個(gè)方案。先看數(shù)據(jù)庫壓力大库北，為什么壓力大爬舰？是因?yàn)槲覀兠看潍@取ID的時(shí)候们陆，都要去數(shù)據(jù)庫請(qǐng)求一次。那我們可以不可以不要每次去惹橐佟坪仇？
思路我們可以請(qǐng)求數(shù)據(jù)庫得到ID的時(shí)候，可設(shè)計(jì)成獲得的ID是一個(gè)ID區(qū)間段垃你。
利用事務(wù)方式加行鎖暂论，上面的語句面褐，在沒有執(zhí)行完之前，是不允許第二個(gè)用戶服務(wù)請(qǐng)求過來的取胎，第二個(gè)請(qǐng)求只能阻塞展哭。
3.3、突發(fā)阻塞問題
