本文詳細(xì)介紹了中間件，主要從數(shù)據(jù)庫(kù)拆分過(guò)程及挑戰(zhàn)、主流數(shù)據(jù)庫(kù)中間件設(shè)計(jì)方案、讀寫(xiě)分離核心要點(diǎn)、分庫(kù)分表核心要點(diǎn)展開(kāi)說(shuō)明。
1. 數(shù)據(jù)庫(kù)拆分過(guò)程及挑戰(zhàn)
互聯(lián)網(wǎng)當(dāng)下的數(shù)據(jù)庫(kù)拆分過(guò)程基本遵循的順序是：垂直拆分、讀寫(xiě)分離、分庫(kù)分表(水平拆分)。每個(gè)拆分過(guò)程都能解決業(yè)務(wù)上的一些問(wèn)題，但同時(shí)也面臨了一些挑戰(zhàn)。
1.1 垂直拆分
對(duì)于一個(gè)剛上線的互聯(lián)網(wǎng)項(xiàng)目來(lái)說(shuō)，由于前期活躍用戶數(shù)量并不多，并發(fā)量也相對(duì)較小，所以此時(shí)企業(yè)一般都會(huì)選擇將所有數(shù)據(jù)存放在一個(gè)數(shù)據(jù)庫(kù) 中進(jìn)行訪問(wèn)操作。舉例來(lái)說(shuō)，對(duì)于一個(gè)電商系統(tǒng)，其用戶模塊和產(chǎn)品模塊的表剛開(kāi)始都是位于一個(gè)庫(kù)中。
其中：user、useraccount表屬于用戶模塊，productcategory、product表屬于產(chǎn)品模塊。
剛開(kāi)始，可能公司的技術(shù)團(tuán)隊(duì)規(guī)模比較小，所有的數(shù)據(jù)都位于一個(gè)庫(kù)中。隨著公司業(yè)務(wù)的發(fā)展，技術(shù)團(tuán)隊(duì)人員也得到了擴(kuò)張，劃分為不同的技術(shù)小組，不同的小組負(fù)責(zé)不同的業(yè)務(wù)模塊。例如A小組負(fù)責(zé)用戶模塊，B小組負(fù)責(zé)產(chǎn)品模塊。此時(shí)數(shù)據(jù)庫(kù)也迎來(lái)了第一次拆分：垂直拆分。
這里的垂直拆分，指的是將一個(gè)包含了很多表的數(shù)據(jù)庫(kù)，根據(jù)表的功能的不同，拆分為多個(gè)小的數(shù)據(jù)庫(kù)，每個(gè)庫(kù)包含部分表。下圖演示將上面提到的db_eshop庫(kù)，拆分為db_user庫(kù)和db_product庫(kù)。
通常來(lái)說(shuō)，垂直拆分，都是根據(jù)業(yè)務(wù)來(lái)對(duì)一個(gè)庫(kù)中的表進(jìn)行拆分的。關(guān)于垂直拆分，還有另一種說(shuō)法，將一個(gè)包含了很多字段的大表拆分為多個(gè)小表，每個(gè)表包含部分字段，這種情況在實(shí)際開(kāi)發(fā)中基本很少遇到。
垂直拆分的另一個(gè)典型應(yīng)用場(chǎng)景是服務(wù)化(SOA)改造。在服務(wù)化的背景下，除了業(yè)務(wù)上需要進(jìn)行拆分，底層的存儲(chǔ)也需要進(jìn)行隔離。 垂直拆分會(huì)使得單個(gè)用戶請(qǐng)求的響應(yīng)時(shí)間變長(zhǎng)，原因在于，在單體應(yīng)用的場(chǎng)景下，所有的業(yè)務(wù)都可以在一個(gè)節(jié)點(diǎn)內(nèi)部完成，而垂直拆分之后，通常會(huì)需要進(jìn)行RPC調(diào)用。然后雖然單個(gè)請(qǐng)求的響應(yīng)時(shí)間增加了，但是整個(gè)服務(wù)的吞吐量確會(huì)大大的增加。
1.2 讀寫(xiě)分離
隨著業(yè)務(wù)的不斷發(fā)展，用戶數(shù)量和并發(fā)量不斷上升。這時(shí)如果僅靠單個(gè)數(shù)據(jù)庫(kù)實(shí)例來(lái)支撐所有訪問(wèn)壓力,幾乎是在 自尋死路 。以產(chǎn)品庫(kù)為例，可能庫(kù)中包含了幾萬(wàn)種商品，并且每天新增幾十種，而產(chǎn)品庫(kù)每天的訪問(wèn)了可能有幾億甚至幾十億次。數(shù)據(jù)庫(kù)讀的壓力太大，單臺(tái)MySQL實(shí)例扛不住，此時(shí)大部分 Mysql DBA 就會(huì)將數(shù)據(jù)庫(kù)設(shè)置成 讀寫(xiě)分離狀態(tài) 。也就是一個(gè) Master 節(jié)點(diǎn)(主庫(kù))對(duì)應(yīng)多個(gè) Salve 節(jié)點(diǎn)(從庫(kù))?？梢詫lave節(jié)點(diǎn)的數(shù)據(jù)理解為master節(jié)點(diǎn)數(shù)據(jù)的全量備份。
master節(jié)點(diǎn)接收用戶的寫(xiě)請(qǐng)求，并寫(xiě)入到本地二進(jìn)制文件(binary log)中。slave通過(guò)一個(gè)I/O線程與Master建立連接，發(fā)送binlog dump指令。Master會(huì)將binlog數(shù)據(jù)推送給slave，slave將接收到的binlog保存到本地的中繼日志(relay log)中，最后，slave通過(guò)另一個(gè)線程SQL thread應(yīng)用本地的relay log，將數(shù)據(jù)同步到slave庫(kù)中。
關(guān)于mysql主從復(fù)制，內(nèi)部包含很多細(xì)節(jié)。例如binlog 格式分為statement、row和mixed，binlog同步方式又可以劃分為：異步、半同步和同步。復(fù)制可以基于binlogFile+position，也可以基于GTID。通常，這些都是DBA負(fù)責(zé)維護(hù)的，業(yè)務(wù)RD無(wú)感知。
在DBA將mysql配置成主從復(fù)制集群的背景下，開(kāi)發(fā)同學(xué)所需要做的工作是：當(dāng)更新數(shù)據(jù)時(shí)，應(yīng)用將數(shù)據(jù)寫(xiě)入master主庫(kù)，主庫(kù)將數(shù)據(jù)同步給多個(gè)slave從庫(kù)。當(dāng)查詢數(shù)據(jù)時(shí)，應(yīng)用選擇某個(gè)slave節(jié)點(diǎn)讀取數(shù)據(jù)。
1.2.1 讀寫(xiě)分離的優(yōu)點(diǎn)
這樣通過(guò)配置多個(gè)slave節(jié)點(diǎn)，可以有效的避免過(guò)大的訪問(wèn)量對(duì)單個(gè)庫(kù)造成的壓力。
1.2.1 讀寫(xiě)分離的挑戰(zhàn)
- 對(duì)于DBA而言，多了很多集群運(yùn)維工作
例如集群搭建、主從切換、從庫(kù)擴(kuò)容、縮容等。例如master配置了多個(gè)slave節(jié)點(diǎn)，如果其中某個(gè)slave節(jié)點(diǎn)掛了，那么之后的讀請(qǐng)求，我們應(yīng)用將其轉(zhuǎn)發(fā)到正常工作的slave節(jié)點(diǎn)上。另外，如果新增了slave節(jié)點(diǎn)，應(yīng)用也應(yīng)該感知到，可以將讀請(qǐng)求轉(zhuǎn)發(fā)到新的slave節(jié)點(diǎn)上。
- 對(duì)于開(kāi)發(fā)人員而言
- 基本讀寫(xiě)分離功能：對(duì)sql類型進(jìn)行判斷，如果是select等讀請(qǐng)求，就走從庫(kù)，如果是insert、update、delete等寫(xiě)請(qǐng)求，就走主庫(kù)。
- 主從數(shù)據(jù)同步延遲問(wèn)題：因?yàn)閿?shù)據(jù)是從master節(jié)點(diǎn)通過(guò)網(wǎng)絡(luò)同步給多個(gè)slave節(jié)點(diǎn)，因此必然存在延遲。因此有可能出現(xiàn)我們?cè)趍aster節(jié)點(diǎn)中已經(jīng)插入了數(shù)據(jù)，但是從slave節(jié)點(diǎn)卻讀取不到的問(wèn)題。對(duì)于一些強(qiáng)一致性的業(yè)務(wù)場(chǎng)景，要求插入后必須能讀取到，因此對(duì)于這種情況，我們需要提供一種方式，讓讀請(qǐng)求也可以走主庫(kù)，而主庫(kù)上的數(shù)據(jù)必然是最新的。
- 事務(wù)問(wèn)題：如果一個(gè)事務(wù)中同時(shí)包含了讀請(qǐng)求(如select)和寫(xiě)請(qǐng)求(如insert)，如果讀請(qǐng)求走從庫(kù)，寫(xiě)請(qǐng)求走主庫(kù)，由于跨了多個(gè)庫(kù)，那么本地事務(wù)已經(jīng)無(wú)法控制，屬于分布式事務(wù)的范疇。而分布式事務(wù)非常復(fù)雜且效率較低。因此對(duì)于讀寫(xiě)分離，目前主流的做法是，事務(wù)中的所有sql統(tǒng)一都走主庫(kù)，由于只涉及到一個(gè)庫(kù)，本地事務(wù)就可以搞定。
- 感知集群信息變更：如果訪問(wèn)的數(shù)據(jù)庫(kù)集群信息變更了，例如主從切換了，寫(xiě)流量就要到新的主庫(kù)上；又例如增加了從庫(kù)數(shù)量，流量需要可以打到新的從庫(kù)上；又或者某個(gè)從庫(kù)延遲或者失敗率比較高，應(yīng)該將這個(gè)從庫(kù)進(jìn)行隔離，讀流量盡量打到正常的從庫(kù)上
1.3 分庫(kù)分表
經(jīng)過(guò)垂直分區(qū)后的 Master/Salve 模式完全可以承受住難以想象的高并發(fā)訪問(wèn)操作，但是否可以永遠(yuǎn) 高枕無(wú)憂 了？答案是否定的，一旦業(yè)務(wù)表中的數(shù)據(jù)量大了，從維護(hù)和性能角度來(lái)看，無(wú)論是任何的 CRUD 操作，對(duì)于數(shù)據(jù)庫(kù)而言都是一件極其耗費(fèi)資源的事情。即便設(shè)置了索引， 仍然無(wú)法掩蓋因?yàn)閿?shù)據(jù)量過(guò)大從而導(dǎo)致的數(shù)據(jù)庫(kù)性能下降的事實(shí) ，因此這個(gè)時(shí)候 Mysql DBA 或許就該對(duì)數(shù)據(jù)庫(kù)進(jìn)行 水平分區(qū) （sharding，即分庫(kù)分表 ）。經(jīng)過(guò)水平分區(qū)設(shè)置后的業(yè)務(wù)表，必然能夠?qū)⒃疽粡埍砭S護(hù)的海量數(shù)據(jù)分配給 N 個(gè)子表進(jìn)行存儲(chǔ)和維護(hù)。
水平分表從具體實(shí)現(xiàn)上又可以分為3種：只分表、只分庫(kù)、分庫(kù)分表，下圖展示了這三種情況：
只分表：
將db庫(kù)中的user表拆分為2個(gè)分表，user_0和user_1，這兩個(gè)表還位于同一個(gè)庫(kù)中。適用場(chǎng)景：如果庫(kù)中的多個(gè)表中只有某張表或者少數(shù)表數(shù)據(jù)量過(guò)大，那么只需要針對(duì)這些表進(jìn)行拆分，其他表保持不變。
只分庫(kù)：
將db庫(kù)拆分為db_0和db_1兩個(gè)庫(kù)，同時(shí)在db_0和db_1庫(kù)中各自新建一個(gè)user表，db_0.user表和db_1.user表中各自只存原來(lái)的db.user表中的部分?jǐn)?shù)據(jù)。
分庫(kù)分表：
將db庫(kù)拆分為db_0和db_1兩個(gè)庫(kù)，db_0中包含user_0、user_1兩個(gè)分表，db_1中包含user_2、user_3兩個(gè)分表。下圖演示了在分庫(kù)分表的情況下，數(shù)據(jù)是如何拆分的：假設(shè)db庫(kù)的user表中原來(lái)有4000W條數(shù)據(jù)，現(xiàn)在將db庫(kù)拆分為2個(gè)分庫(kù)db_0和db_1，user表拆分為user_0、user_1、user_2、user_3四個(gè)分表，每個(gè)分表存儲(chǔ)1000W條數(shù)據(jù)。
1.3.1 分庫(kù)分表的好處
如果說(shuō)讀寫(xiě)分離實(shí)現(xiàn)了數(shù)據(jù)庫(kù)讀能力的水平擴(kuò)展，那么分庫(kù)分表就是實(shí)現(xiàn)了寫(xiě)能力的水平擴(kuò)展。
- 存儲(chǔ)能力的水平擴(kuò)展
在讀寫(xiě)分離的情況下，每個(gè)集群中的master和slave基本上數(shù)據(jù)是完全一致的，從存儲(chǔ)能力來(lái)說(shuō)，在存在海量數(shù)據(jù)的情況下，可能由于磁盤空間的限制，無(wú)法存儲(chǔ)所有的數(shù)據(jù)。而在分庫(kù)分表的情況下，我們可以搭建多個(gè)mysql主從復(fù)制集群，每個(gè)集群只存儲(chǔ)部分分片的數(shù)據(jù)，實(shí)現(xiàn)存儲(chǔ)能力的水平擴(kuò)展。
- 寫(xiě)能力的水平擴(kuò)展
在讀寫(xiě)分離的情況下，由于每個(gè)集群只有一個(gè)master，所有的寫(xiě)操作壓力都集中在這一個(gè)節(jié)點(diǎn)上，在寫(xiě)入并發(fā)非常高的情況下，這里會(huì)成為整個(gè)系統(tǒng)的瓶頸。
而在分庫(kù)分表的情況下，每個(gè)分片所屬的集群都有一個(gè)master節(jié)點(diǎn)，都可以執(zhí)行寫(xiě)入操作，實(shí)現(xiàn)寫(xiě)能力的水平擴(kuò)展。此外減小建立索引開(kāi)銷，降低寫(xiě)操作的鎖操作耗時(shí)等，都會(huì)帶來(lái)很多顯然的好處。
1.3.2 分庫(kù)分表的挑戰(zhàn)
分庫(kù)分表的挑戰(zhàn)主要體現(xiàn)在4個(gè)方面：基本的數(shù)據(jù)庫(kù)增刪改功能，分布式id，分布式事務(wù)，動(dòng)態(tài)擴(kuò)容，下面逐一進(jìn)行講述。
挑戰(zhàn)1：基本的數(shù)據(jù)庫(kù)增刪改功能
對(duì)于開(kāi)發(fā)人員而言，雖然分庫(kù)分表的，但是其還是希望能和單庫(kù)單表那樣的去操作數(shù)據(jù)庫(kù)。例如我們要批量插入四條用戶記錄，并且希望根據(jù)用戶的id字段，確定這條記錄插入哪個(gè)庫(kù)的哪張表。例如1號(hào)記錄插入user1表，2號(hào)記錄插入user2表，3號(hào)記錄插入user3表，4號(hào)記錄插入user0表，以此類推。sql如下所示：
這樣的sql明顯是無(wú)法執(zhí)行的，因?yàn)槲覀円呀?jīng)對(duì)庫(kù)和表進(jìn)行了拆分,這種sql語(yǔ)法只能操作mysql的單個(gè)庫(kù)和單個(gè)表。所以必須將sql改成4條如下所示，然后分別到每個(gè)庫(kù)上去執(zhí)行。
具體流程可以用下圖進(jìn)行描述：
解釋如下：
- sql解析：首先對(duì)sql進(jìn)行解析，得到需要插入的四條記錄的id字段的值分別為1,2,3,4
- sql路由：sql路由包括庫(kù)路由和表路由。庫(kù)路由用于確定這條記錄應(yīng)該插入哪個(gè)庫(kù)，表路由用于確定這條記錄應(yīng)該插入哪個(gè)表。
- sql改寫(xiě)：因?yàn)橐粭l記錄只能插入到一個(gè)庫(kù)中，而上述批量插入的語(yǔ)法將會(huì)在 每個(gè)庫(kù)中都插入四條記錄，明顯是不合適的，因此需要對(duì)sql進(jìn)行改寫(xiě)，每個(gè)庫(kù)只插入一條記錄。
- sql執(zhí)行：一條sql經(jīng)過(guò)改寫(xiě)后變成了多條sql，為了提升效率應(yīng)該并發(fā)的到不同的庫(kù)上去執(zhí)行，而不是按照順序逐一執(zhí)行
- 結(jié)果集合并：每個(gè)sql執(zhí)行之后，都會(huì)有一個(gè)執(zhí)行結(jié)果，我們需要對(duì)分庫(kù)分表的結(jié)果集進(jìn)行合并，從而得到一個(gè)完整的結(jié)果。
挑戰(zhàn)2：分布式id
在分庫(kù)分表后，我們不能再使用mysql的自增主鍵。因?yàn)樵诓迦胗涗浀臅r(shí)候，不同的庫(kù)生成的記錄的自增id可能會(huì)出現(xiàn)沖突。因此需要有一個(gè)全局的id生成器。目前分布式id有很多中方案，其中一個(gè)比較輕量級(jí)的方案是twitter的snowflake算法。
挑戰(zhàn)3：分布式事務(wù)
分布式事務(wù)是分庫(kù)分表繞不過(guò)去的一個(gè)坎，因?yàn)樯婕暗搅送瑫r(shí)更新多個(gè)分片數(shù)據(jù)。例如上面的批量插入記錄到四個(gè)不同的庫(kù)，如何保證要么同時(shí)成功，要么同時(shí)失敗。關(guān)于分布式事務(wù)，mysql支持XA事務(wù)，但是效率較低。柔性事務(wù)是目前比較主流的方案，柔性事務(wù)包括：最大努力通知型、可靠消息最終一致性方案以及TCC兩階段提交。但是無(wú)論XA事務(wù)還是柔性事務(wù)，實(shí)現(xiàn)起來(lái)都是非常復(fù)雜的。
挑戰(zhàn)4：動(dòng)態(tài)擴(kuò)容
動(dòng)態(tài)擴(kuò)容指的是增加分庫(kù)分表的數(shù)量。例如原來(lái)的user表拆分到2個(gè)庫(kù)的四張表上。現(xiàn)在我們希望將分庫(kù)的數(shù)量變?yōu)?個(gè)，分表的數(shù)量變?yōu)?個(gè)。這種情況下一般要伴隨著數(shù)據(jù)遷移。例如在4張表的情況下，id為7的記錄，7%4=3，因此這條記錄位于user3這張表上。但是現(xiàn)在分表的數(shù)量變?yōu)榱?個(gè)，而7%8=0，而user0這張表上根本就沒(méi)有id=7的這條記錄，因此如果不進(jìn)行數(shù)據(jù)遷移的話，就會(huì)出現(xiàn)記錄找不到的情況。本教程后面將會(huì)介紹一種在動(dòng)態(tài)擴(kuò)容時(shí)不需要進(jìn)行數(shù)據(jù)遷移的方案。
1.4 小結(jié)
在上面我們已經(jīng)看到了，讀寫(xiě)分離和分庫(kù)分表帶來(lái)的好處，但是也面臨了極大的挑戰(zhàn)。如果由業(yè)務(wù)開(kāi)發(fā)人員來(lái)完成這些工作，難度比較大。因此就有一些公司專門來(lái)做一些數(shù)據(jù)庫(kù)中間件，對(duì)業(yè)務(wù)開(kāi)發(fā)人員屏蔽底層的繁瑣細(xì)節(jié)，開(kāi)發(fā)人員使用了這些中間件后，不論是讀寫(xiě)分離還是分庫(kù)分表，都可以像操作單庫(kù)單表那樣去操作。
下面，我們將介紹 主流的數(shù)據(jù)庫(kù)中間件設(shè)計(jì)方案和實(shí)現(xiàn)。
2 主流數(shù)據(jù)庫(kù)中間件設(shè)計(jì)方案
數(shù)據(jù)庫(kù)中間件的主要作用是向應(yīng)用程序開(kāi)發(fā)人員屏蔽讀寫(xiě)分離和分庫(kù)分表面臨的挑戰(zhàn)，并隱藏底層實(shí)現(xiàn)細(xì)節(jié)，使得開(kāi)發(fā)人員可以像操作單庫(kù)單表那樣去操作數(shù)據(jù)。在介紹分庫(kù)分表的主流設(shè)計(jì)方案前，我們首先回顧一下在單個(gè)庫(kù)的情況下，應(yīng)用的架構(gòu)，可以用下圖進(jìn)行描述：
可以看到在操作單庫(kù)單表的情況下，我們是直接在應(yīng)用中通過(guò)數(shù)據(jù)連接池(connection pool)與數(shù)據(jù)庫(kù)建立連接，進(jìn)行讀寫(xiě)操作。而對(duì)于讀寫(xiě)分離和分庫(kù)分表，應(yīng)用都要操作多個(gè)數(shù)據(jù)庫(kù)實(shí)例，在這種情況下，我們就需要使用到數(shù)據(jù)庫(kù)中間件。
2.1 設(shè)計(jì)方案
典型的數(shù)據(jù)庫(kù)中間件設(shè)計(jì)方案有2種：proxy、smart-client。下圖演示了這兩種方案的架構(gòu)：
可以看到不論是proxy還是smart-client，底層都操作了多個(gè)數(shù)據(jù)庫(kù)實(shí)例。不論是分庫(kù)分表，還是讀寫(xiě)分離，都是在數(shù)據(jù)庫(kù)中間件層面對(duì)業(yè)務(wù)開(kāi)發(fā)同學(xué)進(jìn)行屏蔽。
2.1.1 proxy模式
我們獨(dú)立部署一個(gè)代理服務(wù)，這個(gè)代理服務(wù)背后管理多個(gè)數(shù)據(jù)庫(kù)實(shí)例。而在應(yīng)用中，我們通過(guò)一個(gè)普通的數(shù)據(jù)源(c3p0、druid、dbcp等)與代理服務(wù)器建立連接，所有的sql操作語(yǔ)句都是發(fā)送給這個(gè)代理，由這個(gè)代理去操作底層數(shù)據(jù)庫(kù)，得到結(jié)果并返回給應(yīng)用。在這種方案下，分庫(kù)分表和讀寫(xiě)分離的邏輯對(duì)開(kāi)發(fā)人員是完全透明的。
優(yōu)點(diǎn)：
1 多語(yǔ)言支持。也就是說(shuō)，不論你用的php、JAVA或是其他語(yǔ)言，都可以支持。以mysql數(shù)據(jù)庫(kù)為例，如果proxy本身實(shí)現(xiàn)了mysql的通信協(xié)議，那么你可以就將其看成一個(gè)mysql 服務(wù)器。mysql官方團(tuán)隊(duì)為不同語(yǔ)言提供了不同的客戶端卻動(dòng)，如java語(yǔ)言的mysql-connector-java，Python語(yǔ)言的mysql-connector-python等等。因此不同語(yǔ)言的開(kāi)發(fā)者都可以使用mysql官方提供的對(duì)應(yīng)的驅(qū)動(dòng)來(lái)與這個(gè)代理服務(wù)器建通信。
2 對(duì)業(yè)務(wù)開(kāi)發(fā)同學(xué)透明。由于可以把proxy當(dāng)成mysql服務(wù)器，理論上業(yè)務(wù)同學(xué)不需要進(jìn)行太多代碼改造，既可以完成接入。
缺點(diǎn)：
1 實(shí)現(xiàn)復(fù)雜。因?yàn)閜roxy需要實(shí)現(xiàn)被代理的數(shù)據(jù)庫(kù)server端的通信協(xié)議，實(shí)現(xiàn)難度較大。通常我們看到一些proxy模式的數(shù)據(jù)庫(kù)中間件，實(shí)際上只能代理某一種數(shù)據(jù)庫(kù)，如mysql。幾乎沒(méi)有數(shù)據(jù)庫(kù)中間件，可以同時(shí)代理多種數(shù)據(jù)庫(kù)(sqlserver、PostgreSQL、Oracle)。
2 proxy本身需要保證高可用。由于應(yīng)用本來(lái)是直接訪問(wèn)數(shù)據(jù)庫(kù)，現(xiàn)在改成了訪問(wèn)proxy，意味著proxy必須保證高可用。否則，數(shù)據(jù)庫(kù)沒(méi)有宕機(jī)，proxy掛了，導(dǎo)致數(shù)據(jù)庫(kù)無(wú)法正常訪問(wèn)，就尷尬了。
3 租戶隔離。可能有多個(gè)應(yīng)用訪問(wèn)proxy代理的底層數(shù)據(jù)庫(kù)，必然會(huì)對(duì)proxy自身的內(nèi)存、網(wǎng)絡(luò)、cpu等產(chǎn)生資源競(jìng)爭(zhēng)，proxy需要需要具備隔離的能力。
2.1.2 smart-client模式
業(yè)務(wù)代碼需要進(jìn)行一些改造，引入支持讀寫(xiě)分離或者分庫(kù)分表的功能的sdk，這個(gè)就是我們的smart-client。通常smart-client是在連接池或者driver的基礎(chǔ)上進(jìn)行了一層封裝，smart-client內(nèi)部與不同的庫(kù)建立連接。應(yīng)用程序產(chǎn)生的sql交給smart-client進(jìn)行處理，其內(nèi)部對(duì)sql進(jìn)行必要的操作，例如在讀寫(xiě)分離情況下，選擇走從庫(kù)還是主庫(kù)；在分庫(kù)分表的情況下，進(jìn)行sql解析、sql改寫(xiě)等操作，然后路由到不同的分庫(kù)，將得到的結(jié)果進(jìn)行合并，返回給應(yīng)用。
優(yōu)點(diǎn)：
1 實(shí)現(xiàn)簡(jiǎn)單。proxy需要實(shí)現(xiàn)數(shù)據(jù)庫(kù)的服務(wù)端協(xié)議，但是smart-client不需要實(shí)現(xiàn)客戶端通信協(xié)議。原因在于，大多數(shù)據(jù)數(shù)據(jù)庫(kù)廠商已經(jīng)針對(duì)不同的語(yǔ)言提供了相應(yīng)的數(shù)據(jù)庫(kù)驅(qū)動(dòng)driver，例如mysql針對(duì)java語(yǔ)言提供了mysql-connector-java驅(qū)動(dòng)，針對(duì)python提供了mysql-connector-python驅(qū)動(dòng)，客戶端的通信協(xié)議已經(jīng)在driver層面做過(guò)了。因此smart-client模式的中間件，通常只需要在此基礎(chǔ)上進(jìn)行封裝即可。
2 天然去中心化。smart-client的方式，由于本身以sdk的方式，被應(yīng)用直接引入，隨著應(yīng)用部署到不同的節(jié)點(diǎn)上，且直連數(shù)據(jù)庫(kù)，中間不需要有代理層。因此相較于proxy而言，除了網(wǎng)絡(luò)資源之外，基本上不存在任何其他資源的競(jìng)爭(zhēng)，也不需要考慮高可用的問(wèn)題。只要應(yīng)用的節(jié)點(diǎn)沒(méi)有全部宕機(jī)，就可以訪問(wèn)數(shù)據(jù)庫(kù)。(這里的高可用是相比proxy而言，數(shù)據(jù)庫(kù)本身的高可用還是需要保證的)
缺點(diǎn)：
1 通常僅支持某一種語(yǔ)言。例如tddl、zebra、sharding-jdbc都是使用java語(yǔ)言開(kāi)發(fā)，因此對(duì)于使用其他語(yǔ)言的用戶，就無(wú)法使用這些中間件。如果其他語(yǔ)言要使用，那么就要開(kāi)發(fā)多語(yǔ)言客戶端。
2 版本升級(jí)困難。因?yàn)閼?yīng)用使用數(shù)據(jù)源代理就是引入一個(gè)jar包的依賴，在有多個(gè)應(yīng)用都對(duì)某個(gè)版本的jar包產(chǎn)生依賴時(shí)，一旦這個(gè)版本有bug，所有的應(yīng)用都需要升級(jí)。而數(shù)據(jù)庫(kù)代理升級(jí)則相對(duì)容易，因?yàn)榉?wù)是單獨(dú)部署的，只要升級(jí)這個(gè)代理服務(wù)器，所有連接到這個(gè)代理的應(yīng)用自然也就相當(dāng)于都升級(jí)了。
2.2 業(yè)界產(chǎn)品
無(wú)論是proxy，還是smart-client，二者的作用都是類似的。以下列出了這兩種方案目前已有的實(shí)現(xiàn)以及各自的優(yōu)缺點(diǎn)：
proxy實(shí)現(xiàn)
目前的已有的實(shí)現(xiàn)方案有：
- 阿里巴巴開(kāi)源的cobar
- 阿里云上的drds
- mycat團(tuán)隊(duì)在cobar基礎(chǔ)上開(kāi)發(fā)的mycat
- mysql官方提供的mysql-proxy
- 奇虎360在mysql-proxy基礎(chǔ)開(kāi)發(fā)的atlas(只支持分表，不支持分庫(kù))
- 當(dāng)當(dāng)網(wǎng)開(kāi)源的sharing-sphere
目前除了mycat、sharing-sphere，其他幾個(gè)開(kāi)源項(xiàng)目基本已經(jīng)沒(méi)有維護(hù)，sharing-sphere前一段時(shí)間已經(jīng)進(jìn)去了Apache 軟件基金會(huì)孵化器。
smart-client實(shí)現(xiàn)
目前的實(shí)現(xiàn)方案有：
- 阿里巴巴開(kāi)源的tddl，已很久沒(méi)維護(hù)
- 大眾點(diǎn)評(píng)開(kāi)源的zebra，大眾點(diǎn)評(píng)的zebra開(kāi)源版本代碼已經(jīng)很久沒(méi)有更新，不過(guò)最近美團(tuán)上市，重新開(kāi)源大量?jī)?nèi)部新的功能特性，并計(jì)劃長(zhǎng)期維持。
- 當(dāng)當(dāng)網(wǎng)開(kāi)源的sharding-jdbc，目前算是做的比較好的，文檔資料比較全。和sharding-sphere一起進(jìn)入了Apache孵化器。
- 螞蟻金服的zal
- 等等
3 讀寫(xiě)分離核心要點(diǎn)
3.1 基本路由功能
基本路由路功能主要是解決，在讀寫(xiě)分離的情況下，如何實(shí)現(xiàn)一些基本的路由功能，這個(gè)過(guò)程通?？梢酝ㄟ^(guò)下圖進(jìn)行描述：
3.1.1 sql類型判斷
主要是判斷出來(lái)sql是讀還是寫(xiě)sql，將讀sql到從庫(kù)上去執(zhí)行，寫(xiě)sql去主庫(kù)上執(zhí)行
write語(yǔ)句：insert、update、delete、create、alter、truncate…
query語(yǔ)句：select、show、desc、explain…
3.1.2 強(qiáng)制走主庫(kù)
有的時(shí)候，對(duì)于一些強(qiáng)一致性的場(chǎng)景，需要寫(xiě)入后，必須能讀取到數(shù)據(jù)。由于主從同步存在延遲，可能會(huì)出現(xiàn)主庫(kù)寫(xiě)入，而從庫(kù)查不到的情況。這次時(shí)候，我們需要使用強(qiáng)制走主庫(kù)的功能。具體實(shí)現(xiàn)上有2種方案：hint 或API
hint，就是開(kāi)發(fā)人員在sql上做一些特殊的標(biāo)記，數(shù)據(jù)庫(kù)中間件識(shí)別到這個(gè)標(biāo)記，就知道這個(gè)sql需要走主庫(kù)，如：
/*master*/select * from table_xx
這里的/*master*/就是一個(gè)hint，表示需要走主庫(kù)。不同的數(shù)據(jù)庫(kù)中間件強(qiáng)制走主庫(kù)的hint可能不同，例如zebra的hint為/*zebra:w+*/，hint到底是什么樣是無(wú)所謂的，其作用僅僅就是一個(gè)標(biāo)記而已。之所以將hint寫(xiě)在/*…*/中，是因?yàn)檫@是標(biāo)準(zhǔn)的sql注釋語(yǔ)法。即使數(shù)據(jù)庫(kù)中間件未能識(shí)別這個(gè)hint，也不會(huì)導(dǎo)致sql語(yǔ)法錯(cuò)誤。
api：主要是通過(guò)代碼的方式來(lái)添加sql走主庫(kù)的標(biāo)識(shí)，hint通常只能加在某個(gè)sql上。如果我們希望多個(gè)sql同時(shí)都走主庫(kù)，也不希望加hint，則可以通過(guò)api的方式，其內(nèi)部主要利用語(yǔ)言的thread local線程上下文特性，如：
ForceMasterHelper.forceMaster() //…執(zhí)行多條sqlForceMasterHelper.clear()
在api標(biāo)識(shí)范圍內(nèi)執(zhí)行的sql，都會(huì)走主庫(kù)。具體API到底應(yīng)該是什么樣，如何使用，也是由相應(yīng)的數(shù)據(jù)庫(kù)中間件來(lái)決定的。
特別的，對(duì)于一些特殊的sql，例如 select last_insert_id；或者select @@identity等，這類sql總是需要走主庫(kù)。這些sql是要獲得最后一個(gè)插入記錄的id，插入操作只可能發(fā)生在主庫(kù)上。
3.2 從庫(kù)路由策略
通常在一個(gè)集群中，只會(huì)有一個(gè)master，但是有多個(gè)slave。當(dāng)判斷是一個(gè)讀請(qǐng)求時(shí)，如何判斷選擇哪個(gè)slave呢？
一些簡(jiǎn)單的選擇策略包括：
- 隨機(jī)選擇(random)
- 按照權(quán)重進(jìn)行選擇(weight)
- 或者輪訓(xùn)(round-robin)
- 等
特別的，對(duì)于一些跨IDC(數(shù)據(jù)中心)部署的數(shù)據(jù)庫(kù)集群，通常需要有就近路由的策略，如下圖：
圖中，在IDC2部署了一個(gè)master，在IDC1和IDC2各部署了一個(gè)slave，應(yīng)用App部署在IDC1。顯然當(dāng)app接收到一個(gè)查詢請(qǐng)求時(shí)，應(yīng)該優(yōu)先查詢與其位于同一個(gè)數(shù)據(jù)中心的slave1，而不是跨數(shù)據(jù)中心去查詢slave2，這就是就近路由的概念。
當(dāng)然一個(gè)數(shù)據(jù)中心內(nèi)，可能會(huì)部署多個(gè)slave，也需要進(jìn)行選擇，因此就近路由通常和一些基本的路由策略結(jié)合使用。另外，對(duì)于就近路由，通常也會(huì)有一個(gè)層級(jí)，例如同機(jī)房、同中心、同區(qū)域、跨區(qū)域等。
3.3 HA、Scalable相關(guān)
數(shù)據(jù)庫(kù)中間件除了需要具備上述提到的讀寫(xiě)分離功能來(lái)訪問(wèn)底層的數(shù)據(jù)庫(kù)集群。也需要一套支持高可用、動(dòng)態(tài)擴(kuò)展的體系：
- 從HA的角度來(lái)說(shuō)，例如主庫(kù)宕機(jī)了，那么應(yīng)該從從庫(kù)選擇一個(gè)作為新的主庫(kù)。開(kāi)源的MHA可以幫助我們完成這個(gè)事；然而，MHA只能在主庫(kù)宕機(jī)的情況下，完成主從切換，對(duì)于僅僅是一個(gè)從庫(kù)宕機(jī)的情況下，MHA通常是無(wú)能為力的。因此，通常都會(huì)在MHA進(jìn)行改造，使其支持更多的HA能力要求。
- 從Scalable角度來(lái)說(shuō)，例如讀qps實(shí)在太高，需要加一些從庫(kù)，來(lái)分擔(dān)讀流量。
事實(shí)上，無(wú)論是HA，還是Scalable，對(duì)于數(shù)據(jù)庫(kù)中間件(不論是proxy或者smart-client)來(lái)說(shuō)，只是配置信息發(fā)生了變更。
因此，通常我們會(huì)將所有的配置變更信息寫(xiě)到一個(gè)配置中心，然后配置心中監(jiān)聽(tīng)這個(gè)配置的變更，例如主從切換，只需要把最新的主從信息設(shè)置到配置中心；增加從庫(kù)，把新從庫(kù)ip、port等信息放到配置中心。數(shù)據(jù)庫(kù)中間件通過(guò)對(duì)這些配置信息變更進(jìn)行監(jiān)聽(tīng)，當(dāng)配置發(fā)生變更時(shí)，實(shí)時(shí)的應(yīng)用最新的配置信息即可。
因此，一個(gè)簡(jiǎn)化的數(shù)據(jù)庫(kù)中間件的高可用架構(gòu)通常如下所示：
監(jiān)控服務(wù)對(duì)集群進(jìn)行監(jiān)控，當(dāng)發(fā)生變更時(shí)，將變更的信息push到配置中心中，數(shù)據(jù)庫(kù)中間件(proxy或smart-client)接收到配置變更，應(yīng)用最新的配置。而整個(gè)過(guò)程，對(duì)于業(yè)務(wù)代碼基本是無(wú)感知的。
對(duì)于配置中心的選擇，有很多，例如百度的disconf、阿里的diamond、點(diǎn)評(píng)開(kāi)源的lion、攜程開(kāi)源的apollo等，也可以使用etcd、consul。通常如果沒(méi)有歷史包袱的話，建議使用攜程開(kāi)源的apollo。
特別需要注意的一點(diǎn)是，通常監(jiān)控服務(wù)監(jiān)控到集群信息變更，推送到配置中心，再到數(shù)據(jù)庫(kù)中間件，必然存在一些延遲。對(duì)于一些場(chǎng)景，例如主從切換，沒(méi)有辦法做到徹底的業(yè)務(wù)無(wú)感知。當(dāng)然，對(duì)于多個(gè)從庫(kù)中，某個(gè)從庫(kù)宕機(jī)的情況下，是可以做到業(yè)務(wù)無(wú)感知的。例如，某個(gè)從庫(kù)失敗，數(shù)據(jù)庫(kù)中間件，自動(dòng)從其他正常的從庫(kù)進(jìn)行重試。
另外，上圖中的HA方案強(qiáng)依賴于配置中心，如果某個(gè)數(shù)據(jù)庫(kù)集群上建立了很多庫(kù)，這個(gè)集群發(fā)生變更時(shí)，將會(huì)存在大量的配置信息需要推送。又或者，如果數(shù)據(jù)庫(kù)集群是多機(jī)房部署的，在某個(gè)機(jī)房整體宕機(jī)的情況下(例如光纖被挖斷了，或者機(jī)房宕機(jī)演練)，也會(huì)存在大量的配置信息需要推送。如果配置中心，推送有延遲，業(yè)務(wù)會(huì)有非常明顯的感知。
因此，通常我們會(huì)在客戶端進(jìn)行一些輕量級(jí)的HA保障。例如，根據(jù)數(shù)據(jù)庫(kù)返回異常的sqlstate和vendor code，判斷異常的嚴(yán)重級(jí)別，確定數(shù)據(jù)庫(kù)實(shí)例能否正常提供服務(wù)，如果不能正常提供服務(wù)，則自動(dòng)將其進(jìn)行隔離，并啟動(dòng)異步線程進(jìn)行檢測(cè)數(shù)據(jù)庫(kù)實(shí)例是否恢復(fù)。
最后，很多數(shù)據(jù)庫(kù)中間件，也會(huì)提供一些限流和降級(jí)的功能，計(jì)算sql的唯一標(biāo)識(shí)(有些稱之為sql指紋)，對(duì)于一些爛sql，導(dǎo)致數(shù)據(jù)庫(kù)壓力變大的情況，可以實(shí)時(shí)的進(jìn)行攔截，直接拋出異常，不讓這些sql打到后端數(shù)據(jù)庫(kù)上去。
4 分庫(kù)分表核心要點(diǎn)
從業(yè)務(wù)開(kāi)發(fā)的角度來(lái)說(shuō)，其不關(guān)心底層是否是分庫(kù)分表了，其還是希望想操作單個(gè)數(shù)據(jù)庫(kù)實(shí)例那樣編寫(xiě)sql，那么數(shù)據(jù)庫(kù)中間件就需要對(duì)其屏蔽所有底層的復(fù)雜邏輯。
下圖演示了一個(gè)數(shù)據(jù)庫(kù)表(user表)在分庫(kù)分表情況下，數(shù)據(jù)庫(kù)中間件內(nèi)部是如何執(zhí)行一個(gè)批量插入sql的：
數(shù)據(jù)庫(kù)中間件主要對(duì)應(yīng)用屏蔽了以下過(guò)程：
- sql解析：首先對(duì)sql進(jìn)行解析，得到抽象語(yǔ)法樹(shù)，從語(yǔ)法樹(shù)中得到一些關(guān)鍵sql信息
- sql路由：sql路由包括庫(kù)路由和表路由。庫(kù)路由用于確定這條記錄應(yīng)該操作哪個(gè)分庫(kù)，表路由用于確定這條記錄應(yīng)該操作哪個(gè)分表。
- sql改寫(xiě)：將sql改寫(xiě)成正確的執(zhí)行方式。例如，對(duì)于一個(gè)批量插入sql，同時(shí)插入4條記錄。但實(shí)際上用戶希望4個(gè)記錄分表存儲(chǔ)到一個(gè)分表中，那么就要對(duì)sql進(jìn)行改寫(xiě)成4條sql，每個(gè)sql都只能插入1條記錄。
- sql執(zhí)行：一條sql經(jīng)過(guò)改寫(xiě)后可能變成了多條sql，為了提升效率應(yīng)該并發(fā)的去執(zhí)行，而不是按照順序逐一執(zhí)行
- 結(jié)果集合并：每個(gè)sql執(zhí)行之后，都會(huì)有一個(gè)執(zhí)行結(jié)果，我們需要對(duì)分庫(kù)分表的結(jié)果集進(jìn)行合并，從而得到一個(gè)完整的結(jié)果。
4.1 SQL解析
用戶執(zhí)行只是一條sql，并傳入相關(guān)參數(shù)。數(shù)據(jù)庫(kù)中間件內(nèi)部需要通過(guò)sql解析器，對(duì)sql進(jìn)行解析?？梢詫ql解析，類比為xml解析，xml解析的最終結(jié)果是得到一個(gè)document對(duì)象，而sql解析最終得到一個(gè)抽象語(yǔ)法樹(shù)(AST)。通過(guò)這個(gè)語(yǔ)法樹(shù)，我們可以很簡(jiǎn)單的獲取到sql的一些執(zhí)行，例如當(dāng)前執(zhí)行的sql類型，查詢了那些字段，數(shù)據(jù)庫(kù)表名，where條件，sql的參數(shù)等一系列信息。
通常來(lái)說(shuō)，對(duì)于sql解析，內(nèi)部需要經(jīng)過(guò)詞法(lex)解析和語(yǔ)法(Syntax)解析兩個(gè)階段，最終得到一個(gè)語(yǔ)法樹(shù)。
SQL解析器的內(nèi)部實(shí)現(xiàn)原理對(duì)業(yè)務(wù)同學(xué)是屏蔽的，業(yè)務(wù)同學(xué)也感知不到。一些數(shù)據(jù)庫(kù)中間件采用了第三方開(kāi)源的sql解析器，也有一些自研sql解析器。例如mycat、zebra采用的都是druid解析器，shard-jdbc一開(kāi)始也用的是druid解析器，后面自研了解析器。目前較為流行的sql解析器包括：
- FoundationDB SQL Parser
- Jsqlparser
- Druid SQL Parser
其中，其中Fdbparser和jsqlparser都是基于javacc實(shí)現(xiàn)的。
mycat團(tuán)隊(duì)曾經(jīng)做過(guò)一個(gè)性能測(cè)試，druid解析器的解析性能通常能達(dá)到基于javacc生成的sql解析器10~20倍。本人也進(jìn)行過(guò)類似的測(cè)試，得出的結(jié)論基本一致。
如何對(duì)比不同的sql解析器的好壞呢？主要是考慮以下兩點(diǎn)：
解析性能：druid最好。
druid采用的是預(yù)測(cè)分析法，它只需要從字符的第一個(gè)到最后一個(gè)遍歷一遍，就同時(shí)完成了詞法解析和語(yǔ)法解析，語(yǔ)法樹(shù)也已經(jīng)構(gòu)造完成。
數(shù)據(jù)庫(kù)方言：druid支持的最多。
SQL-92、SQL-99等都是標(biāo)準(zhǔn)SQL，mysql/oracle/pg/sqlserver/odps等都是方言，sql-parser需要針對(duì)不同的方言進(jìn)行特別處理。Druid的sql parser是目前支持各種數(shù)據(jù)語(yǔ)法最完備的SQL Parser。
注：這里說(shuō)的僅僅是基于Java實(shí)現(xiàn)的SQL解析器，druid是比較好的。大部分同學(xué)可能知道druid是一個(gè)為監(jiān)控而生的連接池，事實(shí)上，druid另一大特性，就是它的SQL解析器。很多開(kāi)源的數(shù)據(jù)庫(kù)中間件，例如zebra、sharding-jdbc等，都使用了druid解析器。(sharding-jdbc后來(lái)自研了解析器)。雖然SQL解析是druid的一大亮點(diǎn)，不過(guò)github上也因?yàn)镾QL解析的bug，收到了不少issue。
4.2 SQL路由
路由規(guī)則是分庫(kù)分表的基礎(chǔ)，其規(guī)定了數(shù)據(jù)應(yīng)該按照怎樣的規(guī)則路由到不同的分庫(kù)分表中。對(duì)于一個(gè)數(shù)據(jù)庫(kù)中間件來(lái)說(shuō)，通常是支持用戶自定義任何路由規(guī)則的。路由規(guī)則本質(zhì)上是一個(gè)腳本表達(dá)式，數(shù)據(jù)庫(kù)中間件通過(guò)內(nèi)置的腳本引擎對(duì)表達(dá)式進(jìn)行計(jì)算，確定最終要操作哪些分庫(kù)、分表。常見(jiàn)的路由規(guī)則包括哈希取模，按照日期等。
下圖展示了user表進(jìn)行分庫(kù)分表后(2個(gè)分庫(kù)，每個(gè)分庫(kù)2個(gè)分表)，并如何根據(jù)id進(jìn)行路由的規(guī)則：
路由分則分為：
- 庫(kù)規(guī)則：用于確定到哪一個(gè)分庫(kù)
- 表規(guī)則：用于確定到哪一個(gè)分表
在上例中，我們使用id來(lái)作為計(jì)算分表、分表，因此把id字段就稱之為路由字段，或者分區(qū)字段。
需要注意的是，不管執(zhí)行的是INSERT、UPDATE、DELETE、SELECT語(yǔ)句，SQL中都應(yīng)該包含這個(gè)路由字段。否則，對(duì)于插入語(yǔ)句來(lái)說(shuō)，就不知道插入到哪個(gè)分庫(kù)或者分表；對(duì)于UPDATE、DELETE、SELECT語(yǔ)句而言，則更為嚴(yán)重，因?yàn)椴恢啦僮髂膫€(gè)分庫(kù)分表，意味著必須要對(duì)所有分表都進(jìn)行操作。SELECT聚合所有分表的內(nèi)容，極容易內(nèi)存溢出，UPDATE、DELETE更新、刪除所有的記錄，非常容易誤更新、刪除數(shù)據(jù)。因此，一些數(shù)據(jù)庫(kù)中間件，對(duì)于SQL可能有一些限制，例如UPDATE、DELETE必須要帶上分區(qū)字段，或者指定過(guò)濾條件。
4.3 SQL改寫(xiě)
前面已經(jīng)介紹過(guò)，如一個(gè)批量插入語(yǔ)句，如果記錄要插入到不同的分庫(kù)分表中，那么就需要對(duì)SQL進(jìn)行改寫(xiě)。 例如，將以下SQL
insert into user(id,name) values (1,”tianshouzhi”),(2,”huhuamin”), (3,”wanghanao”),(4,”luyang”)
改寫(xiě)為：
insert into user_1(id,name) values (1,”tianshouzhi”)insert into user_2(id,name) values (2,”huhuamin”)insert into user_3(id,name) values (3,”wanghanao”)insert into user_0(id,name) values (4,”luyang”)
這里只是一個(gè)簡(jiǎn)單的案例，通常對(duì)于INSERT、UPDATE、DELETE等，改寫(xiě)相對(duì)簡(jiǎn)單。比較復(fù)雜的是SELECT語(yǔ)句的改寫(xiě)，對(duì)于一些復(fù)雜的SELECT語(yǔ)句，改寫(xiě)過(guò)程中會(huì)進(jìn)行一些優(yōu)化，例如將子查詢改成JOIN，過(guò)濾條件下推等。因?yàn)镾QL改寫(xiě)很復(fù)雜，所以很多數(shù)據(jù)庫(kù)中間件并不支持復(fù)雜的SQL(通常有一個(gè)支持的SQL)，只能支持一些簡(jiǎn)單的OLTP場(chǎng)景。
當(dāng)然也有一些數(shù)據(jù)庫(kù)中間件，不滿足于只支持OLTP，在邁向OLAP的方向上進(jìn)行了更多的努力。例如阿里的TDDL、螞蟻的Zdal、大眾點(diǎn)評(píng)的zebra，都引入了apache calcite，嘗試對(duì)復(fù)雜的查詢SQL(例如嵌套子查詢，join等)進(jìn)行支持，通過(guò)過(guò)濾條件下推，流式讀取，并結(jié)合RBO(基于規(guī)則的優(yōu)化)、CBO(基于代價(jià)的優(yōu)化)來(lái)對(duì)一些簡(jiǎn)單的OLAP場(chǎng)景進(jìn)行支持。
4.4 SQL執(zhí)行
當(dāng)經(jīng)過(guò)SQL改寫(xiě)階段后，會(huì)產(chǎn)生多個(gè)SQL，需要到不同的分片上去執(zhí)行，通常我們會(huì)使用一個(gè)線程池，將每個(gè)SQL包裝成一個(gè)任務(wù)，提交到線程池里面并發(fā)的去執(zhí)行，以提升效率。
這些執(zhí)行的SQL中，如果有一個(gè)失敗，則整體失敗，返回異常給業(yè)務(wù)代碼。
4.5 結(jié)果集合并
結(jié)果集合并，是數(shù)據(jù)庫(kù)中間件的一大難點(diǎn)，需要case by case的分析，主要是考慮實(shí)現(xiàn)的復(fù)雜度，以及執(zhí)行的效率問(wèn)題，對(duì)于一些復(fù)雜的SQL，可能并不支持。例如：
對(duì)于查詢條件：大部分中間件都支持=、IN作為查詢條件，且可以作為分區(qū)字段。但是對(duì)于NIT IN、BETWEEN…AND、LIKE,NOT LIKE等，只能作為普通的查詢條件，因?yàn)楦鶕?jù)這些條件，無(wú)法記錄到底是在哪個(gè)分庫(kù)或者分表，只能全表掃描。
聚合函數(shù)：大部分中間件都支持MAX、MIN、COUNT、SUM，但是對(duì)于AVG可能只是部分支持。另外，如果是函數(shù)嵌套、分組(GROUP BY)聚合，可能也有一些數(shù)據(jù)庫(kù)中間件不支持。
子查詢：分為FROM部分的子查詢和WHERE部分的子查詢。大部分中對(duì)于子查詢的支持都是非常有限，例如語(yǔ)法上兼容，但是無(wú)法識(shí)別子查詢中的分區(qū)字段，或者要求子查詢的表名必須與外部查詢表名相同，又或者只能支持一級(jí)嵌套子查詢。
JOIN：對(duì)于JOIN的支持通常很復(fù)雜，如果做不到過(guò)濾條件下推和流式讀取，在中間件層面，基本無(wú)法對(duì)JOIN進(jìn)行支持，因?yàn)椴豢赡馨褍蓚€(gè)表的所有分表，全部拿到內(nèi)存中來(lái)進(jìn)行JOIN，內(nèi)存早就崩了。當(dāng)然也有一些取巧的辦法，一個(gè)是Binding Table，另外一個(gè)是小表廣播(見(jiàn)后文)。
分頁(yè)排序：通常中間件都是支持ORDER BY和LIMIT的。但是在分庫(kù)分表的情況下，分頁(yè)的效率較低。例如對(duì)于limit 100，10 ORDER BY id。表示按照id排序，從第100個(gè)位置開(kāi)始取10條記錄。那么，大部分?jǐn)?shù)據(jù)庫(kù)中間件實(shí)際上是要從每個(gè)分表都查詢110(100+10)條記錄，拿到內(nèi)存中進(jìn)行重新排序，然后取出10條。假設(shè)有10個(gè)分表，那么實(shí)際上要查詢1100條記錄，而最終只過(guò)濾出了10記錄。因此，在分頁(yè)的情況下，通常建議使用"where id > ? limit 10”的方式來(lái)進(jìn)行查詢，應(yīng)用記住每次查詢的最大的記錄id。之后查詢時(shí)，每個(gè)分表只需要從這個(gè)id之后，取10條記錄即可，而不是取offset + rows條記錄。
關(guān)于JOIN的特屬說(shuō)明：
Binding Table：
適用于兩個(gè)表之間存在關(guān)聯(lián)關(guān)系，路由規(guī)則相同。例如，有user表和user_account表，由于user_account與user表強(qiáng)關(guān)聯(lián)，我們可以將這兩個(gè)表的路由規(guī)則設(shè)置為完全一樣，那么對(duì)于某個(gè)特定用戶的信息，其所在的user分表和user_account分表必然唯一同一個(gè)分庫(kù)下，后綴名相同的分表中。在join時(shí)，某一個(gè)分庫(kù)內(nèi)的join，就可以拿到這個(gè)用戶以及賬號(hào)的完整信息，而不需要進(jìn)行跨庫(kù)join，這樣就不需要把用戶的數(shù)據(jù)庫(kù)拿到內(nèi)存中來(lái)進(jìn)行join。
小表廣播：
小表廣播通常是某一個(gè)表的數(shù)據(jù)量比較少， 例如部門表department。另外一個(gè)表數(shù)據(jù)量比較大，例如user。此時(shí)user需要進(jìn)行分庫(kù)分表，但是department不需要進(jìn)行分庫(kù)分表。為了達(dá)到JOIN的目的，我們可以將 department表在每個(gè)分庫(kù)內(nèi)都實(shí)時(shí)同步一份完整的數(shù)據(jù)。這樣，在JOIN的時(shí)候，數(shù)據(jù)庫(kù)中間件只需要將分庫(kù)JOIN的結(jié)果進(jìn)行簡(jiǎn)單合并即可。
下圖演示了小表廣播的流程，用戶在更新department表時(shí)，總是更新分庫(kù)db0的department表，同步組件將變更信息同步到其他分庫(kù)中。
注：圖中的同步組件指的是一般是偽裝成數(shù)據(jù)庫(kù)的從庫(kù)，解析源庫(kù)binlog，插入目標(biāo)庫(kù)。有一些開(kāi)源的組件，如canal、puma可以實(shí)現(xiàn)這個(gè)功能，當(dāng)然這些組件的應(yīng)用場(chǎng)景非常廣泛，不僅限于此。筆者曾寫(xiě)過(guò)一個(gè)系列的canal源碼解析文章，目前完成了大部分。
4.6 二級(jí)索引
通常情況下，分庫(kù)分表的時(shí)候，分區(qū)字段只有一個(gè)。例如對(duì)于用戶表user，按照user_id字段進(jìn)行分區(qū)，那么之后查詢某個(gè)用戶的信息，只能根據(jù)user_id作為分區(qū)字段。使用其他字段，則需要掃描所有分表，效率很低。但是又有根據(jù)其他字段查詢某個(gè)用戶信息的需求，例如根據(jù)手機(jī)號(hào)phone_id。
此時(shí)，我們可以將按照user_id插入的數(shù)據(jù)，進(jìn)行一份全量拷貝。通過(guò)同步組件，重新按照phone_id插入到另一個(gè)分庫(kù)分表集群中，這個(gè)集群就成為二級(jí)索引，或者叫輔維度同步。此后，對(duì)于根據(jù)user_id的操作，就在原來(lái)的分庫(kù)分表集群中進(jìn)行操作；根據(jù)phone_id的操作，就到二級(jí)索引集群中去進(jìn)行操作。
需要注意的是，對(duì)于更新操作，只能操作原集群，二級(jí)索引集群只能執(zhí)行查詢操作。原集群的增量數(shù)據(jù)變更信息，實(shí)時(shí)的通過(guò)同步組件，同步到二級(jí)索引集群中。
注：這是一個(gè)很常見(jiàn)的面試題。阿里的一些面試官，比較喜歡問(wèn)。一些面試者，可能自己想到了這個(gè)方案，因?yàn)榭紤]到這樣比較浪費(fèi)資源，就自行排除了。事實(shí)上，這點(diǎn)資源相對(duì)于滿足業(yè)務(wù)需求來(lái)說(shuō)，都不是事。
4.7 分布式id生成器
在分庫(kù)分表的情況下，數(shù)據(jù)庫(kù)的自增主鍵已經(jīng)無(wú)法使用。所以要使用一個(gè)分布式的id生成器。分布式事務(wù)id生成器要滿足以下條件：唯一、趨勢(shì)遞增(減少落庫(kù)時(shí)的索引開(kāi)銷)、高性能、高可用。
目前主流的分布式id生成方案都有第三方組件依賴，如：
- 基于zk
- 基于mysql
- 基于緩存
twitter的snowflake算法是一個(gè)完全去中心化的分布式id算法，但是限制workid最多能有1024，也就是說(shuō)，應(yīng)用規(guī)模不能超過(guò)1024。雖然可以進(jìn)行細(xì)微的調(diào)整，但是總是有數(shù)量的限制。
另外，美團(tuán)之前在github開(kāi)源了一個(gè)leaf組件，是用于生成分布式id的，感興趣的讀者可以研究一下。
這里提出一種支持動(dòng)態(tài)擴(kuò)容的去中心化分布式id生成方案，此方案的優(yōu)勢(shì)，除了保證唯一、趨勢(shì)遞增，沒(méi)有第三方依賴，支持存儲(chǔ)的動(dòng)態(tài)擴(kuò)容之外，還具有以下優(yōu)勢(shì)：
- 支持按照時(shí)間范圍查詢，或者 時(shí)間范圍+ip查詢，可以直接走主鍵索引；
- 每秒的最大序列id就是某個(gè)ip的qps等
12位日期+10位IP+6位序列ID+4位數(shù)據(jù)庫(kù)擴(kuò)展位
其中：
12位日期：格式為yyMMddHHmmss，意味著本方案的id生成策略可以使用到2099年，把時(shí)間部分前置，從而保證趨勢(shì)遞增。
10位ip：利用ip to decimal算法將12位的ip轉(zhuǎn)為10進(jìn)制數(shù)字。通過(guò)ip地址，來(lái)保證全局唯一。如果ip地址被回收重復(fù)利用了，也不用擔(dān)心id的唯一性，因?yàn)槿掌诓糠诌€在變化。
6位序列id：意味著每秒最多支持生成100百萬(wàn)個(gè)id(0~999999)。不足6位前置補(bǔ)0，如000123。
4位數(shù)據(jù)庫(kù)擴(kuò)展位：為了實(shí)現(xiàn)不遷移數(shù)據(jù)的情況下，實(shí)現(xiàn)動(dòng)態(tài)擴(kuò)容，其中2位表示DB，2位表示TB，最多可擴(kuò)容到10000張表。假設(shè)每張表存儲(chǔ)1000萬(wàn)數(shù)據(jù)，則總共可以支持存儲(chǔ)1000億條數(shù)據(jù)。
關(guān)于數(shù)據(jù)庫(kù)擴(kuò)展位實(shí)現(xiàn)動(dòng)態(tài)擴(kuò)容圖解：
首先明確一點(diǎn)，路由策略始終根據(jù)數(shù)據(jù)庫(kù)最后四位，確定某一條記錄要到哪個(gè)分庫(kù)的哪個(gè)分表中。例如xxxx0001，意味著這條記錄肯定是在00分庫(kù)的01分表上。
接著，就要在id的生成策略上做文章。
假設(shè)初始狀態(tài)為兩個(gè)分庫(kù)db_00,db_01，每個(gè)分庫(kù)里面有10張分表，tb_00~tb_09。此時(shí)，業(yè)務(wù)要保證生成id的時(shí)候，始終保證db的兩位在00~01之間，tb的兩位始終在00~09之間。路由策略根據(jù)這些id，可以找到正確的分庫(kù)分表。
現(xiàn)在需要擴(kuò)容到10個(gè)分庫(kù)，每個(gè)分表10個(gè)分表。那么DBA首先將新增的分庫(kù)：db_02~db_09創(chuàng)建好，每個(gè)分庫(kù)里面再創(chuàng)建10個(gè)分表：tb_01~tb_09。業(yè)務(wù)同學(xué)在此基礎(chǔ)上，將id生成策略改成：db的兩位在00~09之間，tb的兩位規(guī)則維持不變(只是分庫(kù)數(shù)變了，每個(gè)分庫(kù)的分表數(shù)沒(méi)變)。而由于路由從策略是根據(jù)最后四位確定到哪個(gè)分庫(kù)，哪個(gè)分表，當(dāng)這些新的分庫(kù)分表擴(kuò)展位id出現(xiàn)時(shí)，自然可以插入到新的分庫(kù)分表中。也就實(shí)現(xiàn)了動(dòng)態(tài)擴(kuò)容，而無(wú)需遷移數(shù)據(jù)。
當(dāng)然，新的分庫(kù)分表中，一開(kāi)始數(shù)據(jù)是沒(méi)有數(shù)據(jù)的，所以數(shù)據(jù)是不均勻的，可以調(diào)整id擴(kuò)展位中db和tb生成某個(gè)值的概率，使得落到新的分庫(kù)分表中的概率相對(duì)大一點(diǎn)點(diǎn)(不宜太大)，等到數(shù)據(jù)均勻后，再重新調(diào)整成完全隨機(jī)。
此方案的核心思想是，預(yù)分配未來(lái)的可能使用到的最大資源數(shù)量。通常，100個(gè)分庫(kù)，每個(gè)分庫(kù)100張分表，能滿足絕大部分應(yīng)用的數(shù)據(jù)存儲(chǔ)。如果100個(gè)分庫(kù)都在不同的mysql實(shí)例上，假設(shè)每個(gè)mysql實(shí)例都是4T的磁盤，那么可以存儲(chǔ)400T的數(shù)據(jù)，基本上可以滿足絕大部分業(yè)務(wù)的需求。
當(dāng)然，這個(gè)方案不完美。如果超過(guò)這個(gè)值，這種方案可能就不可行了。然而，通常一個(gè)技術(shù)方案，可以保證在5~10年之間不需要在架構(gòu)上做變動(dòng)，應(yīng)該就算的上一個(gè)好方案了。如果你追求的是完美的方案，可能類似于TIDB這種可以實(shí)現(xiàn)自動(dòng)擴(kuò)容的數(shù)據(jù)庫(kù)產(chǎn)品更適合，不過(guò)目前來(lái)說(shuō)，TIDB等類似產(chǎn)品還是無(wú)法取代傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)的。說(shuō)不定等到5~10年后，這些產(chǎn)品更成熟了，你再遷移過(guò)去也不遲。
4.7 分布式事務(wù)
在分庫(kù)分表的情況下，由于操作多個(gè)分庫(kù)，此時(shí)就涉及到分布式事務(wù)。例如執(zhí)行一個(gè)批量插入SQL，如果記錄要插入到不同的分庫(kù)中，就無(wú)法保證一致性。因此，通常情況下，數(shù)據(jù)庫(kù)中間件，只會(huì)保證單個(gè)分庫(kù)的事務(wù)，也就是說(shuō)，業(yè)務(wù)方在創(chuàng)建一個(gè)事務(wù)的時(shí)候，必須要保證事務(wù)中的所有操作，必須最終都在一個(gè)分庫(kù)中執(zhí)行。
事實(shí)上，在微服務(wù)的架構(gòu)下，事務(wù)的問(wèn)題更加復(fù)雜，如下圖
Service A在執(zhí)行某個(gè)操作時(shí)，需要操作數(shù)據(jù)庫(kù)，同時(shí)調(diào)用Service B和Service C，Service B底層操作的數(shù)據(jù)庫(kù)是分庫(kù)分表的，Service C也要操作數(shù)據(jù)庫(kù)。
這種場(chǎng)景下，保證事務(wù)的一致性就非常麻煩。一些常用的一致性算法如：paxIOS協(xié)議、raft協(xié)議也無(wú)法解決這個(gè)問(wèn)題，因?yàn)檫@些協(xié)議都是資源層面的一致性。在微服務(wù)架構(gòu)下，已經(jīng)將事務(wù)的一致性上升到了業(yè)務(wù)的層面。
如果僅僅考慮分庫(kù)分表，一些同學(xué)可能會(huì)想到XA，但是性能很差，對(duì)數(shù)據(jù)庫(kù)的版本也有要求，例如必須使用mysql 5.7，官方還建議將事務(wù)隔離級(jí)別設(shè)置為串行化，這是無(wú)法容忍的。
由于分布式事務(wù)的應(yīng)用場(chǎng)景，并不是僅僅分庫(kù)分表，因此通常都是會(huì)有一個(gè)專門的團(tuán)隊(duì)來(lái)做分布式事務(wù)，并不一定是數(shù)據(jù)庫(kù)中間件團(tuán)隊(duì)來(lái)做。例如，sharding-jdbc就使用了華為開(kāi)源的一套微服務(wù)架構(gòu)解決方案service comb中的saga組件，來(lái)實(shí)現(xiàn)分布式事務(wù)最終一致性。阿里也有類似的組件，在內(nèi)部叫TXC，在阿里云上叫GTS，最近開(kāi)源到了GitHub上叫fescar（Fast & Easy Commit And Rollback)。螞蟻金服也有類似的組件，叫DTX，支持FMT模式和TCC模式。其中FMT模式就類似于TXC。
總體來(lái)說(shuō)，實(shí)際上TCC更能滿足業(yè)務(wù)的需求，雖然接入更加復(fù)雜。關(guān)于fescar，最近比較火，這是java寫(xiě)的，具體可以參考：https://github.com/alibaba/fescar。
本文分享自微信公眾號(hào) - 數(shù)據(jù)和云（OraNews）
