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