終于明白為什么要“分庫分表”了！

隨著互聯(lián)網(wǎng)產(chǎn)業(yè)的蓬勃發(fā)展，在互聯(lián)網(wǎng)應(yīng)用上產(chǎn)生的數(shù)據(jù)也是與日俱增。產(chǎn)生大量的交易記錄和行為記錄，它們的存放和分析是我們需要面對的問題。

用 ID 取模的分表方式分配記錄

ID 分別為 01-04 的四條記錄，如果分配到 3 個表中，那么對 3 取模得到的余數(shù)分別是：

• ID：01 對 3 取模余數(shù)為 1 ，存到“表 1”。
• ID：02 對 3 取模余數(shù)為 2 ，存到“表 2”。
• ID：03 對 3 取模余數(shù)為 3 ，存到“表 3”。
• ID：04 對 3 取模余數(shù)為 1 ，存到“表 1”。

當(dāng)然這里只是一個例子，實際情況需要對 ID 做 Hash 之后再計算。同時還可以針對不同表所在的不同的數(shù)據(jù)庫的資源來設(shè)置存儲數(shù)據(jù)的多少。針對每個表所在的庫的資源設(shè)置權(quán)值。

用這種方式存放數(shù)據(jù)以后，在訪問具體數(shù)據(jù)的時候需要通過一個 Mapping Table 獲取對應(yīng)要響應(yīng)的數(shù)據(jù)來自哪個數(shù)據(jù)表。目前比較流行的數(shù)據(jù)庫中間件已經(jīng)幫助我們實現(xiàn)了這部分的功能。

也就是說不用大家自己去建立這個 Mapping Table，在做查詢的時候中間件幫助你實現(xiàn)了 Mapping Table 的功能。所以，我們這里只需要了解其實現(xiàn)原理就可以了。

按照時間做的數(shù)據(jù)分表

需要注意的是由于分表造成一系列記錄級別的問題，例如 Join 和 ID 生成，事務(wù)處理，同時存在這些表需要跨數(shù)據(jù)庫的可能性：

• Join：需要做兩次查詢，把兩次查詢的結(jié)果在應(yīng)用層做合并。這種做法是最簡單的，在應(yīng)用層設(shè)計的時候需要考慮。
• ID：可以使用 UUID，或者用一張表來存放生成的 Sequence，不過效率都不算高。UUID 實現(xiàn)起來比較方便，但是占用的

  
  

  Snowflake 示意圖

  排序/分頁：數(shù)據(jù)分配到水平的幾個表中的時候，做排序和分頁或者一些集合操作是不容易的。

  這里根據(jù)經(jīng)驗介紹兩種方法。對分表的數(shù)據(jù)先進行排序/分頁/聚合，再進行合并。對分表的數(shù)據(jù)先進行合并再做排序/分頁/聚合。

  事務(wù)：存在分布式事務(wù)的可能，需要考慮補償事務(wù)或者用 TCC(Try Confirm Cancel)協(xié)助完成，這部分的內(nèi)容我們下面會為大家介紹。

  數(shù)據(jù)分庫

  說完了分表，再來談?wù)劮謳臁Ｃ總€物理數(shù)據(jù)庫支持數(shù)據(jù)都是有限的，每一次的數(shù)據(jù)庫請求都會產(chǎn)生一次數(shù)據(jù)庫鏈接，當(dāng)一個庫無法支持更多訪問的時候，我們會把原來的單個數(shù)據(jù)庫分成多個，幫助分擔(dān)壓力。

  這里有幾類分庫的原則，可以根據(jù)具體場景進行選擇：

  • 根據(jù)業(yè)務(wù)不同分庫，這種情況都會把主營業(yè)務(wù)和其他功能分開。例如可以分為訂單數(shù)據(jù)庫，核算數(shù)據(jù)庫，評論數(shù)據(jù)庫。
  • 根據(jù)冷熱數(shù)據(jù)進行分庫，用數(shù)據(jù)訪問頻率來劃分，例如：近一個月的交易數(shù)據(jù)屬于高頻數(shù)據(jù)，2-6 個月的交易數(shù)據(jù)屬于中頻數(shù)據(jù)，大于 6 個月的數(shù)據(jù)屬于低頻數(shù)據(jù)。
  • 根據(jù)訪問數(shù)據(jù)的地域/時間范圍進行分庫。

  單個表會分到不同的數(shù)據(jù)庫中

  通常數(shù)據(jù)分庫之后，每一個數(shù)據(jù)庫包含多個數(shù)據(jù)表，多個數(shù)據(jù)庫會組成一個 Cluster/Group，提高了數(shù)據(jù)庫的可用性，并且可以把讀寫做分離。

  Master 庫主要負責(zé)寫操作，Slave 庫主要負責(zé)讀操作。在應(yīng)用訪問數(shù)據(jù)庫的時候會通過一個負載均衡代理，通過判斷讀寫操作把請求路由到對應(yīng)的數(shù)據(jù)庫。

  如果是讀操作，也會根據(jù)數(shù)據(jù)庫設(shè)置的權(quán)重或者平均分配請求。另外，還有數(shù)據(jù)庫健康監(jiān)控機制，定時發(fā)送心跳檢測數(shù)據(jù)庫的健康狀況。

  如果 Slave 出現(xiàn)問題，會啟動熔斷機制停止對其的訪問;如果 Master 出現(xiàn)問題，通過選舉機制選擇新的 Master 代替。

  兩個集群中的兩個主從，分別擴展成四個集群中的四個

  從兩個集群擴展成四個集群

  雙寫數(shù)據(jù)庫擴容

  在沒有數(shù)據(jù)庫主從配置的情況下的擴容，假設(shè)有數(shù)據(jù)庫 M1 M2 如下圖：

  

  擴展前的兩個主庫

  需要對目前的兩個數(shù)據(jù)庫做擴容，擴容之后是 4 個庫如下圖。新增的庫是 M3，M4 路由的方式分別是 ID%2=0 和 ID%2=1。

  

  新增兩個主庫

  這個時候新的數(shù)據(jù)會同時進入 M1 M2 M3 M4 四個庫中，而老數(shù)據(jù)的使用依舊從 M1 M2 中獲取。

  與此同時，后臺服務(wù)對 M1 M3，M2 M4 做數(shù)據(jù)同步，建議先做全量同步再做數(shù)據(jù)校驗。

  

  老庫給新庫做數(shù)據(jù)同步

  當(dāng)完成數(shù)據(jù)同步之后，四個庫的數(shù)據(jù)保持一致了，修改負載均衡代理的配置為 ID%4 的模式。此時擴容就完成了，從原來的 2 個數(shù)據(jù)庫擴展成 4 個數(shù)據(jù)庫。

  當(dāng)然會存在部分的數(shù)據(jù)冗余，需要像上面一個方案一樣通過后臺服務(wù)刪除這些冗余數(shù)據(jù)，刪除的過程不會影響業(yè)務(wù)。

  

  數(shù)據(jù)同步以后做 Hash 切分

  分布式事務(wù)原理

  架構(gòu)設(shè)計的分表分庫帶來的結(jié)果是我們不得不考慮分布式事務(wù)，今天創(chuàng)新互聯(lián)來看看分布式事務(wù)需要記住哪兩個原理。

  CAP

  互聯(lián)網(wǎng)應(yīng)用大多會使用分表分庫的操作，這個時候業(yè)務(wù)代碼很可能會同時訪問兩個不同的數(shù)據(jù)庫，做不同的操作。同時這兩個操作有可能放在同一個事務(wù)中處理。

  

  這里引出分布式系統(tǒng)的 CAP 理論，他包括以下三個屬性：

  一致性(Consistency)：分布式系統(tǒng)中的所有數(shù)據(jù)，同一時刻有同樣的值。

  業(yè)務(wù)代碼往數(shù)據(jù)庫 01 這個節(jié)點寫入記錄 A，數(shù)據(jù)庫 01 把 A 記錄同步到數(shù)據(jù)庫 02，業(yè)務(wù)代碼再從數(shù)據(jù)庫 02 中讀出的記錄也是 A。那么兩個數(shù)據(jù)庫存放的數(shù)據(jù)就是一致的。

  

  一致性簡圖

  可用性(Availability)：分布式系統(tǒng)中一部分節(jié)點出現(xiàn)故障，分布式系統(tǒng)仍舊可以響應(yīng)用戶的請求。

  假設(shè)數(shù)據(jù)庫 01 和 02 同時存放記錄 A，由于數(shù)據(jù)庫 01 掛掉了，業(yè)務(wù)代碼不能從中獲取數(shù)據(jù)。

  那么業(yè)務(wù)代碼可以從數(shù)據(jù)庫 02 中獲取記錄 A。也就是在節(jié)點出現(xiàn)問題的時候，還保證數(shù)據(jù)的可用性。

  

  可用性簡圖

  分區(qū)容錯性(Partition tolerance)：假設(shè)兩個數(shù)據(jù)庫節(jié)點分別在兩個區(qū)，而兩個區(qū)的通訊發(fā)生了問題。就不能達成數(shù)據(jù)一致，這就是分區(qū)的情況，我就需要從 C 和 A 之間做出選擇。

  是選擇可用性(A)，獲取其中一個區(qū)的數(shù)據(jù)。還是選擇一致性(C)，等待兩個區(qū)的數(shù)據(jù)同步了再去獲取數(shù)據(jù)。

  這種情況的前提是兩個節(jié)點的通訊失敗了，寫入數(shù)據(jù)庫 01 記錄的時候，需要鎖住數(shù)據(jù)庫 02 記錄不讓其他的業(yè)務(wù)代碼修改，直到數(shù)據(jù)庫 01 記錄完成修改。因此 C 和 A 在此刻是矛盾的。兩者不能兼得。

  BASE

  Base 原理廣泛應(yīng)用在數(shù)據(jù)量大，高并發(fā)的互聯(lián)網(wǎng)場景。一起來看看都包含哪些：

  基本可用(Basically Available)： 不會因為某個節(jié)點出現(xiàn)問題就影響用戶的請求。

  即使在流量激增的情況下，也會考慮通過限流降級的辦法保證用戶的請求是可用的。

  比如，電商系統(tǒng)在流量激增的時候，資源會向核心業(yè)務(wù)傾斜，其他的業(yè)務(wù)降級處理。

  軟狀態(tài)( Soft State)：一條數(shù)據(jù)如果存在多個副本，允許副本之間同步的延遲，在較短時間內(nèi)能夠容忍不一致。這個正在同步并且還沒有完成同步的狀態(tài)稱為軟狀態(tài)。
  最終一致性( Eventual Consistency)：最終一致性是相對于強一致性來說的，強一致性是要保證所有的數(shù)據(jù)都是一致的，是實時同步。

  而最終一致性會容忍一小段時間數(shù)據(jù)的不一致，但過了這段時間以后數(shù)據(jù)會保證一致。其包含以下幾種“一致性”：

  ①因果一致性(Causal Consistency)

  如果有兩個進程 1 和 2 都對變量 X 進行操作，“進程 1” 寫入變量 X，“進程 2”需要讀取變量 X，然后用這個 X 來計算 X+2。

  這里“進程 1”和“進程 2” 的操作就存在因果關(guān)系?！斑M程 2” 的計算依賴于進程 1 寫入的 X，如果沒有 X 的值，“進程 2”無法計算。

  
  

  ②讀己之所寫(Read Your Writes)

  “進程 1”寫入變量 X 之后，該進程可以獲取自己寫入的這個值。
  進程寫入的值的同時獲取值

  ③會話一致性(Session Consistency)

  如果一個會話中實現(xiàn)來讀己之所寫。一旦數(shù)據(jù)更新，客戶端只要在同一個會話中就可以看到這個更新的值。

  ④單調(diào)寫一致性(Monotonic Write Consistency)

  “進程 1”如果有三個操作分別是 1，2，3。“進程 2”有兩個操作分別是 1，2。當(dāng)進程請求系統(tǒng)時，系統(tǒng)會保證按照進程中操作的先后順序來執(zhí)行。

  分布式事務(wù)方案

  說完了分布式的原理，再來提一下分布式的方案。由于所處場景不一樣，所以方案也各有不同，這里介紹兩種比較流行的方案，兩段式和 TCC(Try，Confirm，Cancel)。

  兩階段提交

  顧名思義，事務(wù)會進行兩次提交。這里需要介紹兩個概念，一個是事務(wù)協(xié)調(diào)者，也叫事物管理器。

  它是用來協(xié)調(diào)事務(wù)的，所有事務(wù)什么時候準備好了，什么時候可以提交了，都由它來協(xié)調(diào)和管理。

  另一個是參與者，也叫資源管理器。它主要是負責(zé)處理具體事務(wù)的，管理者需要處理的資源。例如：訂票業(yè)務(wù)，扣款業(yè)務(wù)。

  第一階段(準備階段)：事務(wù)協(xié)調(diào)者(事務(wù)管理器)給每個參與者(資源管理器)發(fā)送 Prepare 消息，發(fā)這個消息的目的是問“大家是不是都準備好了，我們馬上就要執(zhí)行事務(wù)了”。

  參與者會根據(jù)自身業(yè)務(wù)和資源情況進行檢查，然后給出反饋。這個檢查過程根據(jù)業(yè)務(wù)內(nèi)容不同而不同。

  例如：訂票業(yè)務(wù)，就要檢查是否有剩余票。扣款業(yè)務(wù)就要檢查，余額是否足夠。一旦檢查通過了才能返回就緒(Ready)信息。

  否則，事務(wù)將終止，并且等待下次詢問。由于這些檢查需要做一些操作，這些操作可能再之后回滾時用到，所以需要寫 redo 和 undo 日志，當(dāng)事務(wù)失敗重試，或者事務(wù)失敗回滾的時候使用。

  第二階段(提交階段)：如果協(xié)調(diào)者收到了參與者失敗或者超時的消息，會給參與者發(fā)送回滾(rollback)消息;否則，發(fā)送提交(commit)消息。兩種情況處理如下：

  情況 1，當(dāng)所有參與者均反饋 yes，提交事務(wù)：

  • 協(xié)調(diào)者向所有參與者發(fā)出正式提交事務(wù)的請求(即 commit 請求)。
  • 參與者執(zhí)行 commit 請求，并釋放整個事務(wù)期間占用的資源。
  • 各參與者向協(xié)調(diào)者反饋 ack(應(yīng)答)完成的消息。
  • 協(xié)調(diào)者收到所有參與者反饋的 ack 消息后，即完成事務(wù)提交。

  情況 2，當(dāng)有一個參與者反饋 no，回滾事務(wù)：

  • 協(xié)調(diào)者向所有參與者發(fā)出回滾請求(即 rollback 請求)。
  • 參與者使用第一階段中的 undo 信息執(zhí)行回滾操作，并釋放整個事務(wù)期間占用的資源。
  • 各參與者向協(xié)調(diào)者反饋 ack 完成的消息。
  • 協(xié)調(diào)者收到所有參與者反饋的 ack 消息后，即完成事務(wù)。
  
  

  TCC(Try，Confirm，Cancel)

  對于一些要求高一致性的分布式事務(wù)，例如：支付系統(tǒng)，交易系統(tǒng)，我們會采用 TCC。

  它包括，Try 嘗試，Confirm 確認，Cancel 取消?？聪旅嬉粋€例子能否幫助大家理解。

  假設(shè)我們有一個轉(zhuǎn)賬服務(wù)，需要把“A 銀行”“A 賬戶”中的錢分別轉(zhuǎn)到“B銀行”“B 賬戶”和“C 銀行”“C 賬戶”中去。

  假設(shè)這三個銀行都有各自的轉(zhuǎn)賬服務(wù)，那么這次轉(zhuǎn)賬事務(wù)就形成了一次分布式事務(wù)。

  我們來看看用 TCC 的方式如何解決：
  首先是 Try 階段，主要檢測資源是否可用，例如檢查賬戶余額是否足夠，緩存，數(shù)據(jù)庫，隊列是否可用等等。

  并不執(zhí)行具體的邏輯。如上圖，這里從“A 賬戶”轉(zhuǎn)出之前要檢查，賬戶的總金額是否大于 100，并且記錄轉(zhuǎn)出金額和剩余金額。

  對于“B 賬戶”和“C 賬戶”來說需要知道賬戶原有總金額和轉(zhuǎn)入的金額，從而可以計算轉(zhuǎn)入后的金額。

  這里的交易數(shù)據(jù)庫設(shè)計除了有金額字段，還要有轉(zhuǎn)出金額或者轉(zhuǎn)入金額的字段，在 Cancel 回滾的時候使用。

  
  

  如果 Try 階段成功，那么就進入 Confirm 階段，也就是執(zhí)行具體的業(yè)務(wù)邏輯。

  這里從“A 賬戶”轉(zhuǎn)出 100 元成功，剩余總金額=220-100=120，把這個剩余金額寫入到總金額中保存，并且把交易的狀態(tài)設(shè)置為“轉(zhuǎn)賬成功”。

  “B 賬戶”和“C 賬戶”分別設(shè)置總金額為 80=50+30 和 130=60+70，也把交易狀態(tài)設(shè)置為“轉(zhuǎn)賬成功”。則整個事務(wù)完成。

  如果 Try 階段沒有成功，那么服務(wù) A B C 都要做回滾的操作。對于“A賬戶”來說需要把扣除的 100 元加回，所以總金額 220=120+100。

  那么“B 服務(wù)”和“C 服務(wù)”需要把入賬的金額從總金額里面減去，也就是 50=80-30 和 60=130-70。

  TCC 接口實現(xiàn)

  這里需要注意的是，需要針對每個服務(wù)去實現(xiàn) Try，Confirm，Cancel 三個階段的代碼。

  例如上面所說的檢查資源，執(zhí)行業(yè)務(wù)，回滾業(yè)務(wù)等操作。目前有很多開源的架構(gòu)例如：ByteTCC、TCC-transaction 可以借鑒。

  TCC 可靠性

  TCC 通過記錄事務(wù)處理日志來保證可靠性。一旦 Try，Confirm，Cancel 操作的時候服務(wù)掛掉或者出現(xiàn)異常，TCC 會提供重試機制。另外如果服務(wù)存在異步的情況可以采用消息隊列的方式通信保持事務(wù)一致。

  分庫表中間件介紹

  如果覺得分表分庫之后，需要考慮的問題很多，可以使用市面上的現(xiàn)成的中間件幫我們實現(xiàn)。

  這里介紹幾個比較常用的中間件：

  • 基于代理方式的有 MySQL Proxy 和 Amoeba。
  • 基于 Hibernate 框架的有 Hibernate Shards。
  • 基于 JDBC 的有當(dāng)當(dāng) Sharding-JDBC。
  • 基于 MyBatis 的類似 Maven 插件式的蘑菇街 TSharding。

  另外著重介紹 Sharding-JDBC 的架構(gòu)，它的構(gòu)成和“服務(wù)注冊中心”很像。

  Sharding-JDBC 會提供一個 Sharding-Proxy 做代理，他會連接一個注冊中心(registry center)，一旦數(shù)據(jù)庫的節(jié)點掛接到系統(tǒng)中，會在這個中心注冊，同時也會監(jiān)控數(shù)據(jù)庫的健康狀況做心跳檢測。

  而 Sharding-Proxy 本身在業(yè)務(wù)代碼(Business Code)請求數(shù)據(jù)庫的時候可以協(xié)助做負載均衡和路由。

  同時 Sharding-Proxy 本身也可以支持被 MySQL Cli 和 MySQL Workbench 查看。

  實際上如果我們理解了分表分庫的原理之后，實現(xiàn)并不難，很多大廠都提供了產(chǎn)品。

  
  

  總結(jié)

  因為數(shù)據(jù)量的上升，為了提高性能會對系統(tǒng)進行分表分庫。從分表來說，有水平分表和垂直分表兩種方式。

  可以根據(jù)業(yè)務(wù)，冷熱數(shù)據(jù)等來進行分庫，分庫以后通過主從庫來實現(xiàn)讀寫分離。

  如果對分庫之后數(shù)據(jù)庫做擴容，有兩種方式，主從數(shù)據(jù)庫擴容和雙寫數(shù)據(jù)庫擴容。

  分表分庫會帶來分布式事務(wù)，我們需要掌握 CAP 和 BASE 原理，同時介紹了兩階段提交和 TCC 兩個分布式事務(wù)方案。最后，介紹了流行的分表分庫中間件，以及其實現(xiàn)原理。

當(dāng)前標(biāo)題：終于明白為什么要“分庫分表”了！
網(wǎng)站路徑：http://www.muchs.cn/news17/98067.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)建站、網(wǎng)站內(nèi)鏈、ChatGPT、關(guān)鍵詞優(yōu)化、App開發(fā)、虛擬主機

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)