1. 為什么要分庫分表（設計高并發(fā)系統(tǒng)的時候屈雄，數據庫層面該如何設計）官套？用過哪些分庫分表中間件蚁孔？不同的分庫分表中間件都有什么優(yōu)點和缺點杠氢？你們具體是如何對數據庫如何進行垂直拆分或水平拆分的修然？

面試題剖析

為什么要分庫分表质况？（設計高并發(fā)系統(tǒng)的時候结榄，數據庫層面該如何設計囤捻？）

說白了蝎土，分庫分表是兩回事兒誊涯，大家可別搞混了，可能是光分庫不分表跪呈，也可能是光分表不分庫耗绿，都有可能误阻。

我先給大家拋出來一個場景晴埂。

假如我們現在是一個小創(chuàng)業(yè)公司（或者是一個 BAT 公司剛興起的一個新部門）邑时，現在注冊用戶就 20 萬晶丘，每天活躍用戶就 1 萬唐含，每天單表數據量就 1000捷枯，然后高峰期每秒鐘并發(fā)請求最多就 10淮捆。天攀痊，就這種系統(tǒng)拄显，隨便找一個有幾年工作經驗的躬审，然后帶幾個剛培訓出來的承边，隨便干干都可以。

結果沒想到我們運氣居然這么好险污，碰上個 CEO 帶著我們走上了康莊大道罗心，業(yè)務發(fā)展迅猛渤闷，過了幾個月飒箭，注冊用戶數達到了 2000 萬蜒灰！每天活躍用戶數 100 萬强窖！每天單表數據量 10 萬條翅溺！高峰期每秒最大請求達到 1000髓抑！同時公司還順帶著融資了兩輪吨拍，進賬了幾個億人民幣案巍队秩！公司估值達到了驚人的幾億美金昼浦！這是小獨角獸的節(jié)奏座柱！

好吧色洞，沒事火诸，現在大家感覺壓力已經有點大了置蜀，為啥呢悉盆？因為每天多 10 萬條數據焕盟，一個月就多 300 萬條數據脚翘，現在咱們單表已經幾百萬數據了来农，馬上就破千萬了沃于。但是勉強還能撐著海诲。高峰期請求現在是 1000饿肺，咱們線上部署了幾臺機器敬辣，負載均衡搞了一下溉跃，數據庫撐 1000QPS 也還湊合撰茎。但是大家現在開始感覺有點擔心了打洼，接下來咋整呢......

再接下來幾個月募疮，我的天阿浓，CEO 太牛逼了芭毙，公司用戶數已經達到 1 億退敦，公司繼續(xù)融資幾十億人民幣翱疗浮！公司估值達到了驚人的幾十億美金唱捣，成為了國內今年最牛逼的明星創(chuàng)業(yè)公司震缭！天拣宰，我們太幸運了巡社。

但是我們同時也是不幸的晌该，因為此時每天活躍用戶數上千萬朝群，每天單表新增數據多達 50 萬姜胖，目前一個表總數據量都已經達到了兩三千萬了右莱！扛不住啊踏志！數據庫磁盤容量不斷消耗掉！高峰期并發(fā)達到驚人的 5000~8000凄诞！別開玩笑了帆谍，哥汛蝙。我跟你保證窖剑，你的系統(tǒng)支撐不到現在西土，已經掛掉了需了！

好吧肋乍，所以你看到這里差不多就理解分庫分表是怎么回事兒了墓造，實際上這是跟著你的公司業(yè)務發(fā)展走的，你公司業(yè)務發(fā)展越好，用戶就越多摊求，數據量越大刘离，請求量越大硫惕，那你單個數據庫一定扛不住恼除。

分表

比如你單表都幾千萬數據了豁辉，你確定你能扛住么徽级？絕對不行餐抢，單表數據量太大旷痕，會極大影響你的 sql 執(zhí)行的性能欺抗，到了后面你的 sql 可能就跑的很慢了。一般來說竿屹，就以我的經驗來看拱燃，單表到幾百萬的時候碗誉，性能就會相對差一些了哮缺，你就得分表了尝苇。

分表是啥意思糠溜？就是把一個表的數據放到多個表中非竿，然后查詢的時候你就查一個表红柱。比如按照用戶 id 來分表，將一個用戶的數據就放在一個表中。然后操作的時候你對一個用戶就操作那個表就好了众眨。這樣可以控制每個表的數據量在可控的范圍內容诬，比如每個表就固定在 200 萬以內览徒。

分庫

分庫是啥意思纽什？就是你一個庫一般我們經驗而言芦缰，最多支撐到并發(fā) 2000浪规，一定要擴容了笋婿，而且一個健康的單庫并發(fā)值你最好保持在每秒 1000 左右缸濒，不要太大。那么你可以將一個庫的數據拆分到多個庫中元镀，訪問的時候就訪問一個庫好了绍填。

這就是所謂的分庫分表，為啥要分庫分表栖疑？你明白了吧讨永。

用過哪些分庫分表中間件？不同的分庫分表中間件都有什么優(yōu)點和缺點揪漩？

這個其實就是看看你了解哪些分庫分表的中間件旋恼，各個中間件的優(yōu)缺點是啥？然后你用過哪些分庫分表的中間件奄容。

比較常見的包括：

• cobar
• TDDL
• atlas
• sharding-jdbc
• mycat

cobar

阿里 b2b 團隊開發(fā)和開源的冰更，屬于 proxy 層方案。早些年還可以用昂勒，但是最近幾年都沒更新了蜀细，基本沒啥人用，差不多算是被拋棄的狀態(tài)吧戈盈。而且不支持讀寫分離奠衔、存儲過程谆刨、跨庫 join 和分頁等操作。

TDDL

淘寶團隊開發(fā)的归斤，屬于 client 層方案痊夭。支持基本的 crud 語法和讀寫分離，但不支持 join官册、多表查詢等語法生兆。目前使用的也不多，因為還依賴淘寶的 diamond 配置管理系統(tǒng)膝宁。

atlas

360 開源的鸦难，屬于 proxy 層方案，以前是有一些公司在用的员淫，但是確實有一個很大的問題就是社區(qū)最新的維護都在 5 年前了合蔽。所以，現在用的公司基本也很少了介返。

sharding-jdbc

當當開源的拴事，屬于 client 層方案。確實之前用的還比較多一些圣蝎，因為 SQL 語法支持也比較多刃宵，沒有太多限制，而且目前推出到了 2.0 版本徘公，支持分庫分表牲证、讀寫分離、分布式 id 生成关面、柔性事務（最大努力送達型事務坦袍、TCC 事務）。而且確實之前使用的公司會比較多一些（這個在官網有登記使用的公司等太，可以看到從 2017 年一直到現在捂齐，是有不少公司在用的），目前社區(qū)也還一直在開發(fā)和維護缩抡，還算是比較活躍奠宜，個人認為算是一個現在也可以選擇的方案。

mycat

基于 cobar 改造的瞻想，屬于 proxy 層方案压真，支持的功能非常完善，而且目前應該是非衬诒撸火的而且不斷流行的數據庫中間件，社區(qū)很活躍待锈，也有一些公司開始在用了漠其。但是確實相比于 sharding jdbc 來說，年輕一些，經歷的錘煉少一些和屎。

總結

綜上拴驮，現在其實建議考量的，就是 sharding-jdbc 和 mycat柴信，這兩個都可以去考慮使用套啤。

sharding-jdbc 這種 client 層方案的優(yōu)點在于不用部署，運維成本低随常，不需要代理層的二次轉發(fā)請求潜沦，性能很高，但是如果遇到升級啥的需要各個系統(tǒng)都重新升級版本再發(fā)布绪氛，各個系統(tǒng)都需要耦合 sharding-jdbc 的依賴唆鸡；

mycat 這種 proxy 層方案的缺點在于需要部署，自己運維一套中間件枣察，運維成本高争占，但是好處在于對于各個項目是透明的，如果遇到升級之類的都是自己中間件那里搞就行了序目。

通常來說臂痕，這兩個方案其實都可以選用，但是我個人建議中小型公司選用 sharding-jdbc猿涨，client 層方案輕便握童，而且維護成本低，不需要額外增派人手嘿辟，而且中小型公司系統(tǒng)復雜度會低一些舆瘪，項目也沒那么多；但是中大型公司最好還是選用 mycat 這類 proxy 層方案红伦，因為可能大公司系統(tǒng)和項目非常多英古，團隊很大，人員充足昙读，那么最好是專門弄個人來研究和維護 mycat召调，然后大量項目直接透明使用即可。

你們具體是如何對數據庫如何進行垂直拆分或水平拆分的蛮浑？

水平拆分的意思唠叛，就是把一個表的數據給弄到多個庫的多個表里去，但是每個庫的表結構都一樣沮稚，只不過每個庫表放的數據是不同的艺沼，所有庫表的數據加起來就是全部數據。水平拆分的意義蕴掏，就是將數據均勻放更多的庫里障般，然后用多個庫來抗更高的并發(fā)调鲸，還有就是用多個庫的存儲容量來進行擴容。

database-split-horizon

垂直拆分的意思挽荡，就是把一個有很多字段的表給拆分成多個表藐石，或者是多個庫上去。每個庫表的結構都不一樣定拟，每個庫表都包含部分字段于微。一般來說，會將較少的訪問頻率很高的字段放到一個表里去青自，然后將較多的訪問頻率很低的字段放到另外一個表里去株依。因為數據庫是有緩存的，你訪問頻率高的行字段越少性穿，就可以在緩存里緩存更多的行勺三，性能就越好。這個一般在表層面做的較多一些需曾。

database-split-vertically

這個其實挺常見的吗坚，不一定我說，大家很多同學可能自己都做過呆万，把一個大表拆開商源，訂單表、訂單支付表谋减、訂單商品表牡彻。

還有表層面的拆分，就是分表出爹，將一個表變成 N 個表庄吼，就是讓每個表的數據量控制在一定范圍內，保證 SQL 的性能严就。否則單表數據量越大总寻，SQL 性能就越差。一般是 200 萬行左右梢为，不要太多渐行，但是也得看具體你怎么操作，也可能是 500 萬铸董，或者是 100 萬祟印。你的SQL越復雜，就最好讓單表行數越少粟害。

好了蕴忆，無論分庫還是分表，上面說的那些數據庫中間件都是可以支持的悲幅。就是基本上那些中間件可以做到你分庫分表之后套鹅，中間件可以根據你指定的某個字段值驻襟，比如說 userid，自動路由到對應的庫上去芋哭，然后再自動路由到對應的表里去。

你就得考慮一下郁副，你的項目里該如何分庫分表减牺？一般來說，垂直拆分存谎，你可以在表層面來做拔疚，對一些字段特別多的表做一下拆分；水平拆分既荚，你可以說是并發(fā)承載不了稚失，或者是數據量太大，容量承載不了恰聘，你給拆了句各，按什么字段來拆，你自己想好晴叨；分表凿宾，你考慮一下，你如果哪怕是拆到每個庫里去兼蕊，并發(fā)和容量都ok了初厚，但是每個庫的表還是太大了，那么你就分表孙技，將這個表分開产禾，保證每個表的數據量并不是很大。

而且這兒還有兩種分庫分表的方式：

• 一種是按照 range 來分牵啦，就是每個庫一段連續(xù)的數據亚情，這個一般是按比如時間范圍來的，但是這種一般較少用蕾久，因為很容易產生熱點問題势似，大量的流量都打在最新的數據上了。
• 或者是按照某個字段hash一下均勻分散僧著，這個較為常用履因。

range 來分，好處在于說盹愚，擴容的時候很簡單栅迄，因為你只要預備好，給每個月都準備一個庫就可以了皆怕，到了一個新的月份的時候毅舆，自然而然西篓，就會寫新的庫了；缺點憋活，但是大部分的請求岂津，都是訪問最新的數據。實際生產用 range悦即，要看場景吮成。

hash 分發(fā)，好處在于說辜梳，可以平均分配每個庫的數據量和請求壓力粱甫；壞處在于說擴容起來比較麻煩，會有一個數據遷移的過程作瞄，之前的數據需要重新計算 hash 值重新分配到不同的庫或表茶宵。

2. 現在有一個未分庫分表的系統(tǒng)，未來要分庫分表宗挥，如何設計才可以讓系統(tǒng)從未分庫分表動態(tài)切換到分庫分表上乌庶？

面試題剖析

這個其實從 low 到高大上有好幾種方案，我們都玩兒過契耿，我都給你說一下安拟。

停機遷移方案

我先給你說一個最 low 的方案，就是很簡單宵喂，大家伙兒凌晨 12 點開始運維糠赦，網站或者 app 掛個公告，說 0 點到早上 6 點進行運維锅棕，無法訪問拙泽。

接著到 0 點停機，系統(tǒng)停掉裸燎，沒有流量寫入了顾瞻，此時老的單庫單表數據庫靜止了。然后你之前得寫好一個導數的一次性工具德绿，此時直接跑起來荷荤，然后將單庫單表的數據嘩嘩嘩讀出來，寫到分庫分表里面去移稳。

導數完了之后蕴纳，就 ok 了，修改系統(tǒng)的數據庫連接配置啥的个粱，包括可能代碼和 SQL 也許有修改古毛，那你就用最新的代碼，然后直接啟動連到新的分庫分表上去。

驗證一下稻薇，ok了嫂冻，完美，大家伸個懶腰塞椎，看看看凌晨 4 點鐘的北京夜景桨仿，打個滴滴回家吧。

但是這個方案比較 low案狠，誰都能干蹬敲，我們來看看高大上一點的方案。

database-shard-method-1

雙寫遷移方案

這個是我們常用的一種遷移方案莺戒，比較靠譜一些，不用停機急波，不用看北京凌晨 4 點的風景从铲。

簡單來說，就是在線上系統(tǒng)里面澄暮，之前所有寫庫的地方名段，增刪改操作，除了對老庫增刪改泣懊，都加上對新庫的增刪改伸辟，這就是所謂的雙寫，同時寫倆庫馍刮，老庫和新庫信夫。

然后系統(tǒng)部署之后，新庫數據差太遠卡啰，用之前說的導數工具静稻，跑起來讀老庫數據寫新庫，寫的時候要根據 gmt_modified 這類字段判斷這條數據最后修改的時間匈辱，除非是讀出來的數據在新庫里沒有振湾，或者是比新庫的數據新才會寫。簡單來說亡脸，就是不允許用老數據覆蓋新數據押搪。

導完一輪之后，有可能數據還是存在不一致浅碾，那么就程序自動做一輪校驗大州，比對新老庫每個表的每條數據，接著如果有不一樣的垂谢，就針對那些不一樣的摧茴，從老庫讀數據再次寫。反復循環(huán)埂陆，直到兩個庫每個表的數據都完全一致為止苛白。

接著當數據完全一致了娃豹，就 ok 了，基于僅僅使用分庫分表的最新代碼购裙，重新部署一次懂版，不就僅僅基于分庫分表在操作了么，還沒有幾個小時的停機時間躏率，很穩(wěn)躯畴。所以現在基本玩兒數據遷移之類的，都是這么干的薇芝。

database-shard-method-2

3. 如何設計可以動態(tài)擴容縮容的分庫分表方案蓬抄？

考點分析

對于分庫分表來說，主要是面對以下問題：

• 選擇一個數據庫中間件夯到，調研嚷缭、學習、測試耍贾；
• 設計你的分庫分表的一個方案阅爽，你要分成多少個庫，每個庫分成多少個表荐开，比如 3 個庫付翁，每個庫 4 個表；
• 基于選擇好的數據庫中間件晃听，以及在測試環(huán)境建立好的分庫分表的環(huán)境百侧，然后測試一下能否正常進行分庫分表的讀寫；
• 完成單庫單表到分庫分表的遷移能扒，雙寫方案移层；
• 線上系統(tǒng)開始基于分庫分表對外提供服務；
• 擴容了赫粥，擴容成 6 個庫观话，每個庫需要 12 個表，你怎么來增加更多庫和表呢越平？

這個是你必須面對的一個事兒频蛔，就是你已經弄好分庫分表方案了，然后一堆庫和表都建好了秦叛，基于分庫分表中間件的代碼開發(fā)啥的都好了晦溪，測試都 ok 了，數據能均勻分布到各個庫和各個表里去挣跋，而且接著你還通過雙寫的方案咔嚓一下上了系統(tǒng)三圆，已經直接基于分庫分表方案在搞了。

那么現在問題來了，你現在這些庫和表又支撐不住了舟肉，要繼續(xù)擴容咋辦修噪？這個可能就是說你的每個庫的容量又快滿了，或者是你的表數據量又太大了路媚，也可能是你每個庫的寫并發(fā)太高了黄琼，你得繼續(xù)擴容。

這都是玩兒分庫分表線上必須經歷的事兒整慎。

面試題剖析

停機擴容（不推薦）

這個方案就跟停機遷移一樣脏款，步驟幾乎一致，唯一的一點就是那個導數的工具裤园，是把現有庫表的數據抽出來慢慢倒入到新的庫和表里去撤师。但是最好別這么玩兒，有點不太靠譜拧揽，因為既然分庫分表就說明數據量實在是太大了剃盾，可能多達幾億條，甚至幾十億强法，你這么玩兒，可能會出問題湾笛。

從單庫單表遷移到分庫分表的時候饮怯，數據量并不是很大，單表最大也就兩三千萬嚎研。那么你寫個工具蓖墅，多弄幾臺機器并行跑，1小時數據就導完了临扮。這沒有問題论矾。

如果 3 個庫 + 12 個表屋谭，跑了一段時間了讼稚，數據量都 1~2 億了鸯檬。光是導 2 億數據腌逢，都要導個幾個小時看峻，6 點怨绣，剛剛導完數據迎罗，還要搞后續(xù)的修改配置捧灰，重啟系統(tǒng)钻注，測試驗證蚂且，10 點才可以搞完。所以不能這么搞幅恋。

優(yōu)化后的方案

一開始上來就是 32 個庫杏死，每個庫 32 個表，那么總共是 1024 張表。

我可以告訴各位同學淑翼，這個分法腐巢，第一，基本上國內的互聯(lián)網肯定都是夠用了窒舟，第二系忙，無論是并發(fā)支撐還是數據量支撐都沒問題。

每個庫正常承載的寫入并發(fā)量是 1000惠豺，那么 32 個庫就可以承載32 * 1000 = 32000 的寫并發(fā)银还，如果每個庫承載 1500 的寫并發(fā)，32 * 1500 = 48000 的寫并發(fā)洁墙，接近 5萬/s 的寫入并發(fā)蛹疯，前面再加一個MQ，削峰热监，每秒寫入 MQ 8 萬條數據捺弦，每秒消費 5 萬條數據。

有些除非是國內排名非承⒖福靠前的這些公司列吼，他們的最核心的系統(tǒng)的數據庫，可能會出現幾百臺數據庫的這么一個規(guī)模苦始，128個庫寞钥，256個庫，512個庫陌选。

1024 張表理郑，假設每個表放 500 萬數據，在 MySQL 里可以放 50 億條數據咨油。

每秒的 5 萬寫并發(fā)您炉，總共 50 億條數據，對于國內大部分的互聯(lián)網公司來說役电，其實一般來說都夠了赚爵。

談分庫分表的擴容，第一次分庫分表法瑟，就一次性給他分個夠囱晴，32 個庫，1024 張表瓢谢，可能對大部分的中小型互聯(lián)網公司來說畸写，已經可以支撐好幾年了。

一個實踐是利用 32 * 32 來分庫分表氓扛，即分為 32 個庫枯芬，每個庫里一個表分為 32 張表论笔。一共就是 1024 張表。根據某個 id 先根據 32 取模路由到庫千所，再根據 32 取模路由到庫里的表狂魔。

剛開始的時候，這個庫可能就是邏輯庫淫痰，建在一個數據庫上的最楷，就是一個mysql服務器可能建了 n 個庫，比如 32 個庫待错。后面如果要拆分籽孙，就是不斷在庫和 mysql 服務器之間做遷移就可以了。然后系統(tǒng)配合改一下配置即可火俄。

比如說最多可以擴展到32個數據庫服務器犯建，每個數據庫服務器是一個庫。如果還是不夠瓜客？最多可以擴展到 1024 個數據庫服務器适瓦，每個數據庫服務器上面一個庫一個表。因為最多是1024個表谱仪。

這么搞玻熙，是不用自己寫代碼做數據遷移的，都交給 dba 來搞好了疯攒，但是 dba 確實是需要做一些庫表遷移的工作嗦随，但是總比你自己寫代碼，然后抽數據導數據來的效率高得多吧卸例。

哪怕是要減少庫的數量称杨，也很簡單肌毅，其實說白了就是按倍數縮容就可以了筷转，然后修改一下路由規(guī)則。

這里對步驟做一個總結：

1. 設定好幾臺數據庫服務器悬而，每臺服務器上幾個庫呜舒，每個庫多少個表，推薦是 32庫 * 32表笨奠，對于大部分公司來說袭蝗，可能幾年都夠了。
2. 路由的規(guī)則般婆，orderId 模 32 = 庫到腥，orderId / 32 模 32 = 表
3. 擴容的時候，申請增加更多的數據庫服務器蔚袍，裝好 mysql乡范，呈倍數擴容配名，4 臺服務器，擴到 8 臺服務器晋辆，再到 16 臺服務器渠脉。
4. 由 dba 負責將原先數據庫服務器的庫，遷移到新的數據庫服務器上去瓶佳，庫遷移是有一些便捷的工具的芋膘。
5. 我們這邊就是修改一下配置，調整遷移的庫所在數據庫服務器的地址霸饲。
6. 重新發(fā)布系統(tǒng)为朋，上線，原先的路由規(guī)則變都不用變贴彼，直接可以基于 n 倍的數據庫服務器的資源潜腻，繼續(xù)進行線上系統(tǒng)的提供服務。

4. 分庫分表之后融涣，id 主鍵如何處理精钮？

考點分析

其實這是分庫分表之后你必然要面對的一個問題轨香，就是 id 咋生成？因為要是分成多個表之后科雳，每個表都是從 1 開始累加，那肯定不對啊脓杉，需要一個全局唯一的 id 來支持糟秘。所以這都是你實際生產環(huán)境中必須考慮的問題。

面試題剖析

基于數據庫的實現方案

數據庫自增 id

這個就是說你的系統(tǒng)里每次得到一個 id球散，都是往一個庫的一個表里插入一條沒什么業(yè)務含義的數據尿赚，然后獲取一個數據庫自增的一個 id。拿到這個 id 之后再往對應的分庫分表里去寫入蕉堰。

這個方案的好處就是方便簡單凌净，誰都會用；缺點就是單庫生成自增 id屋讶，要是高并發(fā)的話冰寻，就會有瓶頸的；如果你硬是要改進一下皿渗，那么就專門開一個服務出來斩芭，這個服務每次就拿到當前 id 最大值没卸，然后自己遞增幾個 id，一次性返回一批 id秒旋，然后再把當前最大 id 值修改成遞增幾個 id 之后的一個值约计；但是無論如何都是基于單個數據庫。

適合的場景：你分庫分表就倆原因迁筛，要不就是單庫并發(fā)太高，要不就是單庫數據量太大尉桩；除非是你并發(fā)不高，但是數據量太大導致的分庫分表擴容，你可以用這個方案屈扎，因為可能每秒最高并發(fā)最多就幾百，那么就走單獨的一個庫和表生成自增主鍵即可模蜡。

設置數據庫 sequence 或者表自增字段步長

可以通過設置數據庫 sequence 或者表的自增字段步長來進行水平伸縮。

比如說膝昆，現在有 8 個服務節(jié)點，每個服務節(jié)點使用一個 sequence 功能來產生 ID，每個 sequence 的起始 ID 不同共苛，并且依次遞增澄峰，步長都是 8。

database-id-sequence-step

適合的場景：在用戶防止產生的 ID 重復時魂毁，這種方案實現起來比較簡單税稼，也能達到性能目標闻镶。但是服務節(jié)點固定，步長也固定墩剖，將來如果還要增加服務節(jié)點沼头，就不好搞了土至。

UUID

好處就是本地生成陶因，不要基于數據庫來了楷扬；不好之處就是烘苹，UUID 太長了徘溢、占用空間大，作為主鍵性能太差了曾雕；更重要的是，UUID 不具有有序性，會導致 B+ 樹索引在寫的時候有過多的隨機寫操作（連續(xù)的 ID 可以產生部分順序寫），還有炫刷，由于在寫的時候不能產生有順序的 append 操作，而需要進行 insert 操作，將會讀取整個 B+ 樹節(jié)點到內存涨享，在插入這條記錄后會將整個節(jié)點寫回磁盤儒旬，這種操作在記錄占用空間比較大的情況下挡爵，性能下降明顯。

適合的場景：如果你是要隨機生成個什么文件名、編號之類的疗韵，你可以用 UUID逞怨，但是作為主鍵是不能用 UUID 的驹马。

UUID.randomUUID().toString().replace(“-”, “”) -> sfsdf23423rr234sfdaf

獲取系統(tǒng)當前時間

這個就是獲取當前時間即可寇蚊，但是問題是，并發(fā)很高的時候，比如一秒并發(fā)幾千盗痒，會有重復的情況，這個是肯定不合適的。基本就不用考慮了吩抓。

適合的場景：一般如果用這個方案涉茧，是將當前時間跟很多其他的業(yè)務字段拼接起來，作為一個 id疹娶，如果業(yè)務上你覺得可以接受降瞳，那么也是可以的。你可以將別的業(yè)務字段值跟當前時間拼接起來蚓胸，組成一個全局唯一的編號锹安。

snowflake 算法

snowflake 算法是 twitter 開源的分布式 id 生成算法糠排，采用 Scala 語言實現，是把一個 64 位的 long 型的 id继谚，1 個 bit 是不用的荠割，用其中的 41 bit 作為毫秒數，用 10 bit 作為工作機器 id，12 bit 作為序列號肤寝。

• 1 bit：不用曹抬，為啥呢岩馍？因為二進制里第一個 bit 為如果是 1佃乘，那么都是負數岭埠，但是我們生成的 id 都是正數，所以第一個 bit 統(tǒng)一都是 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 代表的數字來區(qū)分同一個毫秒內的 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 算法嚎尤，你可以開發(fā)自己公司的服務荔仁，甚至對于機房 id 和機器 id，反正給你預留了 5 bit + 5 bit芽死，你換成別的有業(yè)務含義的東西也可以的乏梁。

這個 snowflake 算法相對來說還是比較靠譜的，所以你要真是搞分布式 id 生成关贵，如果是高并發(fā)啥的遇骑，那么用這個應該性能比較好，一般每秒幾萬并發(fā)的場景揖曾，也足夠你用了落萎。

關注我亥啦！這里只有干貨！
本文原創(chuàng)地址：https://jsbintask.cn/2019/02/17/interview/interview-db-shard/练链，轉載請注明出處翔脱。