一、分庫分表原則
關(guān)系型數(shù)據(jù)庫本身比較容易成為系統(tǒng)性能瓶頸，單機(jī)存儲(chǔ)容量耐版、連接數(shù)俐巴、處理能力等都很有限，數(shù)據(jù)庫本身的“有狀態(tài)性”導(dǎo)致了它并不像Web和應(yīng)用服務(wù)器那么容易擴(kuò)展牵囤。在互聯(lián)網(wǎng)行業(yè)海量數(shù)據(jù)和高并發(fā)訪問的考驗(yàn)下爸黄，聰明的技術(shù)人員提出了分庫分表技術(shù)（有些地方也稱為Sharding滞伟、分片）。同時(shí)炕贵，流行的分布式系統(tǒng)中間件（例如MongoDB梆奈、ElasticSearch等）均自身友好支持Sharding，其原理和思想都是大同小異的称开。
目前針對(duì)海量數(shù)據(jù)的優(yōu)化亩钟，其分庫分表是MySQL永遠(yuǎn)的話題，一般情況下認(rèn)為MySQL是個(gè)簡(jiǎn)單的數(shù)據(jù)庫鳖轰，在數(shù)據(jù)量大到一定程度之后處理查詢的效率降低清酥，如果需要繼續(xù)保持高性能運(yùn)轉(zhuǎn)的話，必須分庫或者分表了蕴侣。關(guān)于數(shù)據(jù)量達(dá)到多少大是個(gè)極限這個(gè)事兒总处，本文先不討論，研究源碼的同學(xué)已經(jīng)證實(shí)MySQL或者Innodb內(nèi)部的鎖粒度太大的問題大大限制了MySQL提供QPS的能力或者處理大規(guī)模數(shù)據(jù)的能力睛蛛。在這點(diǎn)上鹦马，一般的使用者只好坐等官方不斷推出的優(yōu)化版本了。
在一般運(yùn)維的角度來看忆肾，我們什么情況下需要考慮分庫分表荸频？
首先說明，這里所說的分庫分表是指把數(shù)據(jù)庫數(shù)據(jù)的物理拆分到多個(gè)實(shí)例或者多臺(tái)機(jī)器上去客冈，而不是類似分區(qū)表的原地切分旭从。
原則零：能不分就不分
是的，MySQL 是關(guān)系數(shù)據(jù)庫场仲，數(shù)據(jù)庫表之間的關(guān)系從一定的角度上映射了業(yè)務(wù)邏輯和悦。任何分庫分表的行為都會(huì)在某種程度上提升業(yè)務(wù)邏輯的復(fù)雜度，數(shù)據(jù)庫除了承載數(shù)據(jù)的存儲(chǔ)和訪問外渠缕，協(xié)助業(yè)務(wù)更好的實(shí)現(xiàn)需求和邏輯也是其重要工作之一鸽素。分庫分表會(huì)帶來數(shù)據(jù)的合并，查詢或者更新條件的分離亦鳞，事務(wù)的分離等等多種后果馍忽，業(yè)務(wù)實(shí)現(xiàn)的復(fù)雜程度往往會(huì)翻倍或者指數(shù)級(jí)上升。所以燕差，在分庫分表之前遭笋，不要為分而分，去做其他力所能及的事情吧徒探，例如升級(jí)硬件瓦呼，升級(jí)，升級(jí)網(wǎng)絡(luò)测暗，升級(jí)數(shù)據(jù)庫版本央串，讀寫分離谎替，負(fù)載均衡等等。所有分庫分表的前提是蹋辅，這些你已經(jīng)盡力了钱贯。
原則一：數(shù)據(jù)量太大，正常的運(yùn)維影響正常業(yè)務(wù)訪問
這里說的運(yùn)維侦另，例如：
1）對(duì)數(shù)據(jù)庫的備份秩命。如果單表或者單個(gè)實(shí)例太大，在做備份的時(shí)候需要大量的磁盤IO或者網(wǎng)絡(luò)IO資源褒傅。例如1T的數(shù)據(jù)弃锐，網(wǎng)絡(luò)傳輸占用50MB的時(shí)候，需要20000秒才能傳輸完畢殿托，在此整個(gè)過程中的維護(hù)風(fēng)險(xiǎn)都是高于平時(shí)的霹菊。我們?cè)赒unar的做法是給所有的數(shù)據(jù)庫機(jī)器添加第二塊網(wǎng)卡，用來做備份支竹，或者SST旋廷，Group Communication等等各種內(nèi)部的數(shù)據(jù)傳輸。1T的數(shù)據(jù)的備份礼搁，也會(huì)占用大量的磁盤IO饶碘，如果是SSD還好，當(dāng)然這里忽略某些廠商的產(chǎn)品在集中IO的時(shí)候會(huì)出一些BUG的問題馒吴。如果是普通的物理磁盤扎运，則在不限流的情況下去執(zhí)行xtrabackup，該實(shí)例基本不可用饮戳。
2）對(duì)數(shù)據(jù)表的修改豪治。如果某個(gè)表過大，對(duì)此表做DDL的時(shí)候扯罐，MySQL會(huì)鎖住全表负拟，這個(gè)時(shí)間可能很長，在這段時(shí)間業(yè)務(wù)不能訪問此表篮赢，影響甚大齿椅。解決的辦法有類似騰訊游戲DBA自己改造的可以在線秒改表，不過他們目前也只是能添加字段而已启泣，對(duì)別的DDL還是無效；或者使用pt-online-schema-change示辈，當(dāng)然在使用過程中寥茫，它需要建立觸發(fā)器和影子表，同時(shí)也需要很長很長的時(shí)間矾麻，在此操作過程中的所有時(shí)間纱耻，都可以看做是風(fēng)險(xiǎn)時(shí)間芭梯。把數(shù)據(jù)表切分，總量減小弄喘，有助于改善這種風(fēng)險(xiǎn)玖喘。
3）整個(gè)表熱點(diǎn)，數(shù)據(jù)訪問和更新頻繁蘑志，經(jīng)常有鎖等待累奈，你又沒有能力去修改源碼，降低鎖的粒度急但，那么只會(huì)把其中的數(shù)據(jù)物理拆開澎媒，用空間換時(shí)間，變相降低訪問壓力波桩。
原則二：表設(shè)計(jì)不合理戒努，需要對(duì)某些字段垂直拆分
這里舉一個(gè)例子，如果你有一個(gè)用戶表镐躲，在最初設(shè)計(jì)的時(shí)候可能是這樣：
|
1 id bigint #用戶的ID
2 name varchar #用戶的名字
3 last_login_time datetime #最近登錄時(shí)間
4 personal_info text #私人信息
5 xxxxx #其他信息字段
一般的users表會(huì)有很多字段储玫，我就不列舉了。如上所示萤皂，在一個(gè)簡(jiǎn)單的應(yīng)用中缘缚，這種設(shè)計(jì)是很常見的。但是：
設(shè)想情況一：你的業(yè)務(wù)中彩了敌蚜，用戶數(shù)從100w飆升到10個(gè)億桥滨。你為了統(tǒng)計(jì)活躍用戶，在每個(gè)人登錄的時(shí)候都會(huì)記錄一下他的最近登錄時(shí)間弛车。并且的用戶活躍得很齐媒，不斷的去更新這個(gè)login_time，搞的你的這個(gè)表不斷的被update纷跛，壓力非常大喻括。那么，在這個(gè)時(shí)候贫奠，只要考慮對(duì)它進(jìn)行拆分唬血，站在業(yè)務(wù)的角度，最好的辦法是先把last_login_time拆分出去唤崭，我們叫它 user_time拷恨。這樣做，業(yè)務(wù)的代碼只有在用到這個(gè)字段的時(shí)候修改一下就行了谢肾。如果你不這么做腕侄，直接把users表水平切分了，那么，所有訪問users表的地方冕杠，都要修改微姊。或許你會(huì)說分预，我有proxy兢交，能夠動(dòng)態(tài)merge數(shù)據(jù)。到目前為止我還從沒看到誰家的proxy不影響性能的笼痹。
設(shè)想情況二：personal_info這個(gè)字段本來沒啥用配喳，你就是讓用戶注冊(cè)的時(shí)候填一些個(gè)人愛好而已，基本不查詢与倡。一開始的時(shí)候有它沒它無所謂界逛。但是到后來發(fā)現(xiàn)兩個(gè)問題，一纺座，這個(gè)字段占用了大量的空間息拜，因?yàn)槭莟ext嘛，有很多人喜歡長篇大論地介紹自己净响。更糟糕的是二少欺，不知道哪天哪個(gè)產(chǎn)品經(jīng)理心血來潮，說允許個(gè)人信息公開吧馋贤，以方便讓大家更好的相互了解赞别。那么在所有人獵奇窺私心理的影響下，對(duì)此字段的訪問大幅度增加配乓。數(shù)據(jù)庫壓力瞬間抗不住了仿滔，這個(gè)時(shí)候，只好考慮對(duì)這個(gè)表的垂直拆分了犹芹。
原則三：某些數(shù)據(jù)表出現(xiàn)了無窮增長
例子很好舉崎页，各種的評(píng)論，消息腰埂，日志記錄飒焦。這個(gè)增長不是跟人口成比例的，而是不可控的屿笼，例如微博的feed的廣播牺荠，我發(fā)一條消息，會(huì)擴(kuò)散給很多很多人驴一。雖然主體可能只存一份休雌，但不排除一些索引或者路由有這種存儲(chǔ)需求。這個(gè)時(shí)候蛔趴，增加存儲(chǔ)挑辆，提升機(jī)器配置已經(jīng)蒼白無力了例朱，水平切分是最佳實(shí)踐孝情。拆分的標(biāo)準(zhǔn)很多鱼蝉，按用戶的，按時(shí)間的箫荡，按用途的魁亦，不在一一舉例。
原則四：安全性和可用性的考慮
這個(gè)很容易理解羔挡，雞蛋不要放在一個(gè)籃子里洁奈，我不希望我的數(shù)據(jù)庫出問題，但我希望在出問題的時(shí)候不要影響到100%的用戶绞灼，這個(gè)影響的比例越少越好利术，那么，水平切分可以解決這個(gè)問題低矮，把用戶印叁，庫存，訂單等等本來同統(tǒng)一的資源切分掉军掂，每個(gè)小的數(shù)據(jù)庫實(shí)例承擔(dān)一小部分業(yè)務(wù)轮蜕，這樣整體的可用性就會(huì)提升。這對(duì)Qunar這樣的業(yè)務(wù)還是比較合適的蝗锥，人與人之間跃洛，某些庫存與庫存之間，關(guān)聯(lián)不太大终议，可以做一些這樣的切分汇竭。
原則五：業(yè)務(wù)耦合性考慮
這個(gè)跟上面有點(diǎn)類似，主要是站在業(yè)務(wù)的層面上穴张，我們的火車票業(yè)務(wù)和烤羊腿業(yè)務(wù)是完全無關(guān)的業(yè)務(wù)细燎，雖然每個(gè)業(yè)務(wù)的數(shù)據(jù)量可能不太大，放在一個(gè)MySQL實(shí)例中完全沒問題陆馁，但是很可能烤羊腿業(yè)務(wù)的DBA 或者開發(fā)人員水平很差找颓，動(dòng)不動(dòng)給你出一些幺蛾子，直接把數(shù)據(jù)庫搞掛叮贩。這個(gè)時(shí)候击狮，火車票業(yè)務(wù)的人員雖然技術(shù)很優(yōu)秀，工作也很努力益老，照樣被老板打屁股彪蓬。解決的辦法很簡(jiǎn)單:惹不起，躲得起捺萌。
二档冬、分庫分表方案
- 垂直拆分
垂直拆分常見有垂直分庫和垂直分表兩種。垂直分表在日常開發(fā)和設(shè)計(jì)中比較常見，通俗的說法叫做“大表拆小表”酷誓，拆分是基于關(guān)系型數(shù)據(jù)庫中的“列”（字段）進(jìn)行的披坏。通常情況，某個(gè)表中的字段比較多盐数，可以新建立一張“擴(kuò)展表”棒拂，將不經(jīng)常使用或者長度較大的字段拆分出去放到“擴(kuò)展表”中，如下圖所示：
在字段很多的情況下，拆分開確實(shí)更便于開發(fā)和維護(hù)（筆者曾見過某個(gè)遺留系統(tǒng)中漾峡，一個(gè)大表中包含100多列的）攻旦。某種意義上也能避免“跨頁”的問題（MySQL、MSSQL底層都是通過“數(shù)據(jù)頁”來存儲(chǔ)的生逸，“跨頁”問題可能會(huì)造成額外的性能開銷牢屋，這里不展開，感興趣的朋友可以自行查閱相關(guān)資料進(jìn)行研究）牺陶。
拆分字段的操作建議在數(shù)據(jù)庫設(shè)計(jì)階段就做好伟阔。如果是在發(fā)展過程中拆分，則需要改寫以前的查詢語句掰伸，會(huì)額外帶來一定的成本和風(fēng)險(xiǎn)皱炉，建議謹(jǐn)慎。
垂直分庫是根據(jù)數(shù)據(jù)庫里面的數(shù)據(jù)表的相關(guān)性進(jìn)行拆分狮鸭，比如：一個(gè)數(shù)據(jù)庫里面既存在用戶數(shù)據(jù)合搅，又存在訂單數(shù)據(jù)，那么垂直拆分可以把用戶數(shù)據(jù)放到用戶庫歧蕉、把訂單數(shù)據(jù)放到訂單庫灾部。垂直分表是對(duì)數(shù)據(jù)表進(jìn)行垂直拆分的一種方式，常見的是把一個(gè)多字段的大表按常用字段和非常用字段進(jìn)行拆分惯退，每個(gè)表里面的數(shù)據(jù)記錄數(shù)一般情況下是相同的赌髓，只是字段不一樣，使用主鍵關(guān)聯(lián)催跪。
另外锁蠕，在“微服務(wù)”盛行的今天已經(jīng)非常普及了，按照業(yè)務(wù)模塊來劃分出不同的數(shù)據(jù)庫懊蒸，也是一種垂直拆分荣倾。而不是像早期一樣將所有的數(shù)據(jù)表都放到同一個(gè)數(shù)據(jù)庫中。如下圖：
垂直拆分優(yōu)點(diǎn)：
- 可以使得行數(shù)據(jù)變小妒貌，一個(gè)數(shù)據(jù)塊 (Block) 就能存放更多的數(shù)據(jù)，在查詢時(shí)就會(huì)減少 I/O 次數(shù) (每次查詢時(shí)讀取的 Block 就少)铸豁。
- 可以達(dá)到最大化利用 Cache 的目的灌曙，具體在垂直拆分的時(shí)候可以將不常變的字段放一起，將經(jīng)常改變的放一起推姻。
- 數(shù)據(jù)維護(hù)簡(jiǎn)單平匈。
垂直拆分缺點(diǎn)：
- 主鍵出現(xiàn)冗余框沟，需要管理冗余列藏古。
- 會(huì)引起表連接 JOIN 操作（增加 CPU 開銷）可以通過在業(yè)務(wù)服務(wù)器上進(jìn)行 join 來減少數(shù)據(jù)庫壓力。
- 依然存在單表數(shù)據(jù)量過大的問題（需要水平拆分）忍燥。
- 事務(wù)處理復(fù)雜拧晕。
垂直拆分小結(jié)：
系統(tǒng)層面的“服務(wù)化”拆分操作，能夠解決業(yè)務(wù)系統(tǒng)層面的耦合和性能瓶頸梅垄，有利于系統(tǒng)的擴(kuò)展維護(hù)厂捞。而數(shù)據(jù)庫層面的拆分，道理也是相通的队丝。與服務(wù)的“治理”和“降級(jí)”機(jī)制類似靡馁，我們也能對(duì)不同業(yè)務(wù)類型的數(shù)據(jù)進(jìn)行“分級(jí)”管理、維護(hù)机久、監(jiān)控臭墨、擴(kuò)展等。
眾所周知膘盖，數(shù)據(jù)庫往往最容易成為應(yīng)用系統(tǒng)的瓶頸胧弛，而數(shù)據(jù)庫本身屬于“有狀態(tài)”的，相對(duì)于Web和應(yīng)用服務(wù)器來講侠畔，是比較難實(shí)現(xiàn)“橫向擴(kuò)展”的结缚。數(shù)據(jù)庫的連接資源比較寶貴且單機(jī)處理能力也有限，在高并發(fā)場(chǎng)景下软棺，垂直分庫一定程度上能夠突破IO红竭、連接數(shù)及單機(jī)硬件資源的瓶頸，是大型分布式系統(tǒng)中優(yōu)化數(shù)據(jù)庫架構(gòu)的重要手段喘落。
然后茵宪，很多人并沒有從根本上搞清楚為什么要拆分，也沒有掌握拆分的原則和技巧揖盘，只是一味的模仿大廠的做法眉厨。導(dǎo)致拆分后遇到很多問題（例如：跨庫join，分布式事務(wù)等）兽狭。
- 水平拆分
水平拆分是通過某種策略將數(shù)據(jù)分片來存儲(chǔ)憾股，分為庫內(nèi)分表和分庫分表兩部分鹿蜀，每片數(shù)據(jù)會(huì)分散到不同的MySQL表或庫，達(dá)到分布式的效果服球，能夠支持非常大的數(shù)據(jù)量茴恰。
庫內(nèi)分表，僅僅是單純的解決了單一表數(shù)據(jù)過大的問題斩熊，由于沒有把表的數(shù)據(jù)分布到不同的機(jī)器上往枣，因此對(duì)于減輕 MySQL 服務(wù)器的壓力來說，并沒有太大的作用粉渠，大家還是競(jìng)爭(zhēng)同一個(gè)物理機(jī)上的 IO分冈、CPU、網(wǎng)絡(luò)霸株，這個(gè)就要通過分庫分表來解決雕沉。
最常見的方式就是通過主鍵或者時(shí)間等字段進(jìn)行Hash和取模后拆分。如下圖所示：
當(dāng)下分表有靜態(tài)分表和動(dòng)態(tài)分表兩種：
靜態(tài)分表：事先估算出表能達(dá)到的量，然后根據(jù)每一個(gè)表需要存多少數(shù)據(jù)直接算出需要?jiǎng)?chuàng)建表的數(shù)量倔叼。如：1億數(shù)據(jù)每一個(gè)表100W條數(shù)據(jù)那就要建100張表，然后通過一定的hash算法計(jì)算每一條數(shù)據(jù)存放在那張表宫莱。其實(shí)就有點(diǎn)像是使用partition table一樣丈攒。靜態(tài)分表有一個(gè)斃命就是當(dāng)分的那么多表還不滿足時(shí)，需要再擴(kuò)展難度和成本就會(huì)很高梢睛。
動(dòng)態(tài)分表：同樣也是對(duì)大數(shù)據(jù)量的表進(jìn)行拆分肥印，他可以避免靜態(tài)分表帶來的后遺癥。當(dāng)然也需要在設(shè)計(jì)上多一些東西（這往往是我們能接受的）绝葡。
某種意義上來講深碱，有些系統(tǒng)中使用的“冷熱數(shù)據(jù)分離”（將一些使用較少的歷史數(shù)據(jù)遷移到其他的數(shù)據(jù)庫中。而在業(yè)務(wù)功能上藏畅，通常默認(rèn)只提供熱點(diǎn)數(shù)據(jù)的查詢）敷硅，也是類似的實(shí)踐。在高并發(fā)和海量數(shù)據(jù)的場(chǎng)景下愉阎，分庫分表能夠有效緩解單機(jī)和單庫的性能瓶頸和壓力绞蹦，突破IO、連接數(shù)榜旦、硬件資源的瓶頸幽七。當(dāng)然，投入的硬件成本也會(huì)更高溅呢。同時(shí)澡屡，這也會(huì)帶來一些復(fù)雜的技術(shù)問題和挑戰(zhàn)（例如：跨分片的復(fù)雜查詢猿挚，跨分片事務(wù)等）。
水平拆分優(yōu)點(diǎn):
- 不存在單庫大數(shù)據(jù)和高并發(fā)的性能瓶頸驶鹉。
- 應(yīng)用端改造較少绩蜻。
- 提高了系統(tǒng)的穩(wěn)定性和負(fù)載能力。
水平拆分缺點(diǎn)：
- 分片事務(wù)一致性難以解決室埋。
- 跨節(jié)點(diǎn) Join 性能差办绝，邏輯復(fù)雜。
- 數(shù)據(jù)多次擴(kuò)展難度跟維護(hù)量極大姚淆。
三孕蝉、分庫分表難點(diǎn)
垂直分庫帶來的問題和解決思路：
- 跨庫join的問題
在拆分之前，系統(tǒng)中很多列表和詳情頁所需的數(shù)據(jù)是可以通過sql join來完成的肉盹。而拆分后昔驱，數(shù)據(jù)庫可能是分布式在不同實(shí)例和不同的主機(jī)上，join將變得非常麻煩上忍。而且基于架構(gòu)規(guī)范，性能纳本，安全性等方面考慮窍蓝，一般是禁止跨庫join的。那該怎么辦呢繁成？首先要考慮下垂直分庫的設(shè)計(jì)問題吓笙，如果可以調(diào)整，那就優(yōu)先調(diào)整巾腕。如果無法調(diào)整的情況面睛，下面筆者將結(jié)合以往的實(shí)際經(jīng)驗(yàn)，總結(jié)幾種常見的解決思路尊搬，并分析其適用場(chǎng)景叁鉴。
跨庫Join的幾種解決思路
全局表
所謂全局表，就是有可能系統(tǒng)中所有模塊都可能會(huì)依賴到的一些表佛寿。比較類似我們理解的“數(shù)據(jù)字典”幌墓。為了避免跨庫join查詢，我們可以將這類表在其他每個(gè)數(shù)據(jù)庫中均保存一份冀泻。同時(shí)常侣，這類數(shù)據(jù)通常也很少發(fā)生修改（甚至幾乎不會(huì)），所以也不用太擔(dān)心“一致性”問題弹渔。
字段冗余
這是一種典型的反范式設(shè)計(jì)胳施，在互聯(lián)網(wǎng)行業(yè)中比較常見，通常是為了性能來避免join查詢肢专。
舉個(gè)電商業(yè)務(wù)中很簡(jiǎn)單的場(chǎng)景：“訂單表”中保存“賣家Id”的同時(shí)舞肆，將賣家的“Name”字段也冗余您没，這樣查詢訂單詳情的時(shí)候就不需要再去查詢“賣家用戶表”。
字段冗余能帶來便利胆绊，是一種“空間換時(shí)間”的體現(xiàn)氨鹏。但其適用場(chǎng)景也比較有限，比較適合依賴字段較少的情況压状。最復(fù)雜的還是數(shù)據(jù)一致性問題仆抵，這點(diǎn)很難保證，可以借助數(shù)據(jù)庫中的觸發(fā)器或者在業(yè)務(wù)代碼層面去保證种冬。當(dāng)然镣丑，也需要結(jié)合實(shí)際業(yè)務(wù)場(chǎng)景來看一致性的要求。就像上面例子娱两，如果賣家修改了Name之后莺匠，是否需要在訂單信息中同步更新呢？
數(shù)據(jù)同步
定時(shí)A庫中的tab_a表和B庫中tbl_b有關(guān)聯(lián)十兢，可以定時(shí)將指定的表做同步趣竣。當(dāng)然，同步本來會(huì)對(duì)數(shù)據(jù)庫帶來一定的影響旱物，需要性能影響和數(shù)據(jù)時(shí)效性中取得一個(gè)平衡遥缕。這樣來避免復(fù)雜的跨庫查詢。筆者曾經(jīng)在項(xiàng)目中是通過ETL工具來實(shí)施的宵呛。
系統(tǒng)層組裝
在系統(tǒng)層面单匣，通過調(diào)用不同模塊的組件或者服務(wù)，獲取到數(shù)據(jù)并進(jìn)行字段拼裝宝穗。說起來很容易户秤，但實(shí)踐起來可真沒有這么簡(jiǎn)單，尤其是數(shù)據(jù)庫設(shè)計(jì)上存在問題但又無法輕易調(diào)整的時(shí)候逮矛。具體情況通常會(huì)比較復(fù)雜鸡号。
- 跨庫事務(wù)（分布式事務(wù)）問題
按業(yè)務(wù)拆分?jǐn)?shù)據(jù)庫之后，不可避免的就是“分布式事務(wù)”的問題橱鹏。想要了解分布式事務(wù)膜蠢，就需要了解“XA接口”和“兩階段提交”。值得提到的是莉兰，MySQL5.5x和5.6x中的xa支持是存在問題的挑围，會(huì)導(dǎo)致主從數(shù)據(jù)不一致。直到5.7x版本中才得到修復(fù)糖荒。Java應(yīng)用程序可以采用Atomikos框架來實(shí)現(xiàn)XA事務(wù)（J2EE中JTA）杉辙。感興趣的讀者可以自行參考《分布式事務(wù)一致性解決方案》，鏈接地址：http://www.infoq.com/cn/articles/solution-of-distributed-system-transaction-consistency
四捶朵、常見分片規(guī)則和策略
- 分布式全局唯一ID
在很多中小項(xiàng)目中蜘矢，我們往往直接使用數(shù)據(jù)庫自增特性來生成主鍵ID狂男，這樣確實(shí)比較簡(jiǎn)單。而在分庫分表的環(huán)境中品腹，數(shù)據(jù)分布在不同的分片上岖食，不能再借助數(shù)據(jù)庫自增長特性直接生成，否則會(huì)造成不同分片上的數(shù)據(jù)表主鍵會(huì)重復(fù)舞吭。簡(jiǎn)單介紹下使用和了解過的幾種ID生成算法泡垃。
1. Twitter的Snowflake（又名“雪花算法”）
2. UUID/GUID（一般應(yīng)用程序和數(shù)據(jù)庫均支持）
3. MongoDB ObjectID（類似UUID的方式）
4. Ticket Server（數(shù)據(jù)庫生存方式，F(xiàn)lickr采用的就是這種方式）
其中羡鸥，Twitter的Snowflake算法是近幾年在分布式系統(tǒng)項(xiàng)目中使用最多的蔑穴，未發(fā)現(xiàn)重復(fù)或并發(fā)的問題。該算法生成的是64位唯一Id（由41位的timestamp+10位自定義的機(jī)器碼+13位累加計(jì)數(shù)器組成）惧浴。這里不做過多介紹存和，感興趣的讀者可自行查閱相關(guān)資料。
- 分片字段該如何選擇
在開始分片之前衷旅，我們首先要確定分片字段（也可稱為“片鍵”）捐腿。很多常見的例子和場(chǎng)景中是采用ID或者時(shí)間字段進(jìn)行拆分。這也并不絕對(duì)的芜茵，我的建議是結(jié)合實(shí)際業(yè)務(wù)叙量，通過對(duì)系統(tǒng)中執(zhí)行的sql語句進(jìn)行統(tǒng)計(jì)分析，選擇出需要分片的那個(gè)表中最頻繁被使用九串，或者最重要的字段來作為分片字段。
常見的分片策略有隨機(jī)分片和連續(xù)分片這兩種寺鸥，如下圖所示：
當(dāng)需要使用分片字段進(jìn)行范圍查找時(shí)胆建，連續(xù)分片可以快速定位分片進(jìn)行高效查詢烤低，大多數(shù)情況下可以有效避免跨分片查詢的問題。后期如果想對(duì)整個(gè)分片集群擴(kuò)容時(shí)笆载，只需要添加節(jié)點(diǎn)即可扑馁，無需對(duì)其他分片的數(shù)據(jù)進(jìn)行遷移。但是凉驻，連續(xù)分片也有可能存在數(shù)據(jù)熱點(diǎn)的問題腻要，就像圖中按時(shí)間字段分片的例子，有些節(jié)點(diǎn)可能會(huì)被頻繁查詢壓力較大涝登，熱數(shù)據(jù)節(jié)點(diǎn)就成為了整個(gè)集群的瓶頸雄家。而有些節(jié)點(diǎn)可能存的是歷史數(shù)據(jù)，很少需要被查詢到胀滚。
隨機(jī)分片其實(shí)并不是隨機(jī)的趟济，也遵循一定規(guī)則乱投。通常，我們會(huì)采用Hash取模的方式進(jìn)行分片拆分顷编，所以有些時(shí)候也被稱為離散分片戚炫。隨機(jī)分片的數(shù)據(jù)相對(duì)比較均勻，不容易出現(xiàn)熱點(diǎn)和并發(fā)訪問的瓶頸媳纬。但是双肤，后期分片集群擴(kuò)容起來需要遷移舊的數(shù)據(jù)。使用一致性Hash算法能夠很大程度的避免這個(gè)問題层宫，所以很多中間件的分片集群都會(huì)采用一致性Hash算法杨伙。離散分片也很容易面臨跨分片查詢的復(fù)雜問題。
- 數(shù)據(jù)遷移萌腿，容量規(guī)劃限匣，擴(kuò)容等問題
很少有項(xiàng)目會(huì)在初期就開始考慮分片設(shè)計(jì)的，一般都是在業(yè)務(wù)高速發(fā)展面臨性能和存儲(chǔ)的瓶頸時(shí)才會(huì)提前準(zhǔn)備毁菱。因此米死，不可避免的就需要考慮歷史數(shù)據(jù)遷移的問題。一般做法就是通過程序先讀出歷史數(shù)據(jù)贮庞，然后按照指定的分片規(guī)則再將數(shù)據(jù)寫入到各個(gè)分片節(jié)點(diǎn)中峦筒。
此外，我們需要根據(jù)當(dāng)前的數(shù)據(jù)量和QPS等進(jìn)行容量規(guī)劃窗慎，綜合成本因素物喷，推算出大概需要多少分片（一般建議單個(gè)分片上的單表數(shù)據(jù)量不要超過1000W）。
如果是采用隨機(jī)分片遮斥，則需要考慮后期的擴(kuò)容問題峦失，相對(duì)會(huì)比較麻煩。如果是采用的范圍分片术吗，只需要添加節(jié)點(diǎn)就可以自動(dòng)擴(kuò)容尉辑。
五、跨分片技術(shù)問題
- 跨分片的排序分頁
一般來講较屿，分頁時(shí)需要按照指定字段進(jìn)行排序隧魄。當(dāng)排序字段就是分片字段的時(shí)候，我們通過分片規(guī)則可以比較容易定位到指定的分片隘蝎，而當(dāng)排序字段非分片字段的時(shí)候购啄，情況就會(huì)變得比較復(fù)雜了。為了最終結(jié)果的準(zhǔn)確性末贾，我們需要在不同的分片節(jié)點(diǎn)中將數(shù)據(jù)進(jìn)行排序并返回闸溃，并將不同分片返回的結(jié)果集進(jìn)行匯總和再次排序，最后再返回給用戶。如下圖所示：
上面圖中所描述的只是最簡(jiǎn)單的一種情況（取第一頁數(shù)據(jù)），看起來對(duì)性能的影響并不大乓旗。但是府蛇，如果想取出第10頁數(shù)據(jù)，情況又將變得復(fù)雜很多屿愚，如下圖所示：
有些讀者可能并不太理解妆距，為什么不能像獲取第一頁數(shù)據(jù)那樣簡(jiǎn)單處理（排序取出前10條再合并穷遂、排序）。其實(shí)并不難理解娱据，因?yàn)楦鞣制?jié)點(diǎn)中的數(shù)據(jù)可能是隨機(jī)的蚪黑，為了排序的準(zhǔn)確性，必須把所有分片節(jié)點(diǎn)的前N頁數(shù)據(jù)都排序好后做合并中剩，最后再進(jìn)行整體的排序忌穿。很顯然，這樣的操作是比較消耗資源的结啼，用戶越往后翻頁掠剑，系統(tǒng)性能將會(huì)越差。
- 跨分片的函數(shù)處理
在使用Max郊愧、Min朴译、Sum、Count之類的函數(shù)進(jìn)行統(tǒng)計(jì)和計(jì)算的時(shí)候属铁，需要先在每個(gè)分片數(shù)據(jù)源上執(zhí)行相應(yīng)的函數(shù)處理动分，然后再將各個(gè)結(jié)果集進(jìn)行二次處理，最終再將處理結(jié)果返回红选。如下圖所示：
