本文就分庫分表的產生背景、一些通用的分庫分表的涉及記錄做一下簡要的理解和闡述。

為什麼的需要分庫分表

在分散式架構中，隨著資料量的不斷上升和使用者量的不斷累加，原先資料庫的單點（很多為了資料庫的高可用只是做了簡單的讀寫分離）設計早就已經不夠用使用資料庫的三個階段

• 第一階段：單庫單表

• 第二階段：單庫多表
  比如一個User 表，當資料量增加的時候，查詢出現很慢的情況，增加和刪除索引的代價太大，就可以考慮把User表分為 User_1 ,User_2 ....這時候可以放在不同的例項裡面，也可以放在同一個例項裡面。

• 第三階段：多庫多表
  微服務的設計思路里面就是每個服務有自己的資料庫。

分而治之

資料庫拆分的兩個方式就是

垂直拆分：一個資料庫例項多個表組成，需要按照業務的使用不同把表拆分成多個分類，分佈到多個資料庫例項，達到負載均衡的效果。專人幹專事。

水平拆分 ：同一個表中的資料分散到多個資料庫例項裡面。簡單來說就是拆分成User_1 ,User_2 .... 與原有結構相同。多個人幹一件事。

冷熱分離的角度去拆分

冷資料：查詢多，變更少，推薦使用引擎MyISAM，可配置多個從庫緩解讀取的壓力

熱資料：查詢和變更都多 推薦使用引擎InnoDB，對於活躍資料，在某些場景下適合使用redis等快取，比如點贊系統，等到累積一定的量再去跟新資料庫。。

讀寫分離的也是一個拆分角度

分庫分表存在的問題

• 存在分散式事務的問題
• 跨界點Join問題
• 跨界點合併資料和分頁的問題
• 多個資料來源的管理的問題

水平切分的維度選擇

1. 一致性Hash
   為什麼使用一致性Hash而不是簡單的Hash，為了解決縮容和擴容的問題，
   缺點很明顯，很難做資料聚合的處理。
2. 按照時間切邊
   在一些場景下面存在資料傾斜的問題，資料的二次查詢也存在問題。

垂直切分更加偏向於業務拆分的過程，水平拆分的技術難度相對於比較高。

分片後的查詢問題

例如： 使用者購買了商品,需要將交易記錄儲存下來,那麼如果按照買家的緯度分表,則每個買家的交易記錄都被儲存在同一表中,我們可以很快、很方便地查到某個買家的購買情況,
但是某個商品被購買的交易資料很有可能分佈在多張表中,查詢起來比較麻煩。反之,按照商品維度分表,則可以很方便地查詢到該商品的購買情況,但若要查詢到買家的交易記錄,則會比較麻煩。

1. 分片資料聚合，但是這樣的效率很低 。

2.記錄兩份資料，比如在商品服務中，一份買家的維度拆分，一份商品維度拆分。

3.在搜尋實時性比較高的情況下，考慮使用搜尋引擎，例如採用大資料工具Elasticsearch。

當然查詢還有其他變相的方案

電商系統的訂單和商品價格的問題

分片後事務處理機制

柔性事務和剛性事務
柔性事務滿足BASE理論（基本可用，最終一致）
剛性事務滿足ACID理論

二階段提交協議(2PC)

分為準備階段和提交階段
對應技術上的XA、JTA/JTS

缺點比較明顯，在準備的時候需要鎖定資源，參與者較多的情況下，等待的時間差拉長，影響響應時間，出現死鎖的可能性比較大。所以很少使用這個方案

最大努力保證模式

例如商戶交易結果通知重試、補單重試
這種模式適用於一致性要求不高但是對效能要求高的場景

1.開始訊息事物
2.開始資料庫事物
3.接收訊息
4.跟新資料庫
5.提交資料庫事務
6.提交訊息事務

如果5失敗了那麼資料庫和訊息佇列全部回滾，保持一致。
5成功但是6超時失敗，這時候出現不一致的現象。可以配合事務補償模式完成，也就是訊息佇列的重試機制

事物補償模式(TCC)

TCC型事務（Try/Confirm/Cancel）可以歸為補償型。補償型的例子，在一個長事務（long-running）中，一個由兩臺伺服器一起參與的事務，伺服器A發起事務，伺服器B參與事務，B的事務需要人工參與，所以處理時間可能很長。如果按照ACID的原則，要保持事務的隔離性、一致性，伺服器A中發起的事務中使用到的事務資源將會被鎖定，不允許其他應用訪問到事務過程中的中間結果，直到整個事務被提交或者回滾。這就造成事務A中的資源被長時間鎖定，系統的可用性將不可接受。WS-BusinessActivity提供了一種基於補償的long-running的事務處理模型。還是上面的例子，伺服器A的事務如果執行順利，那麼事務A就先行提交，如果事務B也執行順利，則事務B也提交，整個事務就算完成。但是如果事務B執行失敗，事務B本身回滾，這時事務A已經被提交，所以需要執行一個補償操作，將已經提交的事務A執行的操作作反操作，恢復到未執行前事務A的狀態。這樣的SAGA事務模型，是犧牲了一定的隔離性和一致性的，但是提高了long-running事務的可用性。

非同步確保型

將一些同步阻塞的事務操作變為非同步的操作，避免對資料庫事務的爭用，典型例子是熱點賬戶非同步記賬、批量記賬的處理。