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

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

用 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”。

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

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

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

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

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

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

  
  

  Snowflake 示意圖

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

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

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

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

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

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

  • 根據(jù)業(yè)務不同分庫，這種情況都會把主營業(yè)務和其他功能分開。例如可以分為訂單數(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 庫主要負責寫操作，Slave 庫主要負責讀操作。在應用訪問數(shù)據(jù)庫的時候會通過一個負載均衡代理，通過判斷讀寫操作把請求路由到對應的數(shù)據(jù)庫。

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

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

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

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

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

  在沒有數(shù)據(jù)庫主從配置的情況下的擴容，假設有數(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 中獲取。

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

  

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

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

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

  

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

  分布式事務原理

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

  CAP

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

  

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

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

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

  

  一致性簡圖

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

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

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

  

  可用性簡圖

  分區(qū)容錯性(Partition tolerance)：假設兩個數(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è)務代碼修改，直到數(shù)據(jù)庫 01 記錄完成修改。因此 C 和 A 在此刻是矛盾的。兩者不能兼得。

  BASE

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

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

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

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

  軟狀態(tài)( Soft State)：一條數(shù)據(jù)如果存在多個副本，允許副本之間同步的延遲，在較短時間內能夠容忍不一致。這個正在同步并且還沒有完成同步的狀態(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” 的操作就存在因果關系?！斑M程 2” 的計算依賴于進程 1 寫入的 X，如果沒有 X 的值，“進程 2”無法計算。

  
  

  ②讀己之所寫(Read Your Writes)

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

  ③會話一致性(Session Consistency)

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

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

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

  分布式事務方案

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

  兩階段提交

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

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

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

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

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

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

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

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

  情況 1，當所有參與者均反饋 yes，提交事務：

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

  情況 2，當有一個參與者反饋 no，回滾事務：

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

  TCC(Try，Confirm，Cancel)

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

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

  假設我們有一個轉賬服務，需要把“A 銀行”“A 賬戶”中的錢分別轉到“B銀行”“B 賬戶”和“C 銀行”“C 賬戶”中去。

  假設這三個銀行都有各自的轉賬服務，那么這次轉賬事務就形成了一次分布式事務。

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

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

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

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

  
  

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

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

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

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

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

  TCC 接口實現(xiàn)

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

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

  TCC 可靠性

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

  分庫表中間件介紹

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

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

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

  另外著重介紹 Sharding-JDBC 的架構，它的構成和“服務注冊中心”很像。

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

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

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

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

  
  

  總結

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

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

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

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

分享名稱：終于明白為什么要“分庫分表”了！
網頁網址：http://www.bm7419.com/news/98067.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供網站排名、網站策劃、網頁設計公司、服務器托管、搜索引擎優(yōu)化、建站公司

廣告

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