001---mysql分庫分表

標籤：過程   web   ase   medium   商品   cap理論   應該   單表   特點   

mysql分庫分表 一、整體的切分方式

1、分庫分表：即資料的切分就是通過某種特定的條件，將我們存放在同一個資料庫中的資料分散存放到多個資料庫（主機）中，以達到分散單台裝置負載的效果

2、資料的切分根據其切分規則的類型，可以分為如下兩種切分模式

【1】垂直（縱向）切分：把單一的表拆分成多個表 / 將不相關的表，分散到不同的資料庫（主機）上。

        如：使用者表、商品SKU表、交易Pay表，根據業務不同進行切分，將表切分到不同資料庫上。

        優點：

         （1）。拆分後業務清晰，拆分規則明確

         （2）。系統之間進行整合或擴充很容易

         （3）。按照成本、應用的等級、應用的類型等將表放到不同的機器上，便於管理

         （4）。便於實現動靜分離、冷熱分離的資料庫表的設計模式

                     冷熱分離：冷資料（查詢多，變化少），熱資料/活躍資料（變化多）。將冷熱資料分開存放即冷熱分離。

         （5）。資料維護簡單

       缺點：

         （1）。部分業務表無法關聯（Join），只能通過介面方式解決，提高了系統的複雜度

         （2）。受每種業務的不同限制，存在單庫效能瓶頸，不易進行資料擴充和提升效能

         （3）。交易處理複雜

設計資料庫表結構時考慮因素：

（1）。冷資料適合MyISAM儲存引擎（查詢快） ，熱資料適合InnoDB儲存引擎（更新快）。

（2）。主從分離：主庫用於寫入操作，從庫（可配置更多從庫）用於查詢操作，分擔請求壓力。

（3）。針對活躍/熱資料，可採用Memcache、Redis等緩衝，待累計一定量時再更新DB。

【2】水平（橫向）切分：根據表中資料的邏輯關係，將同一個表中的資料按照某種條件拆分到多台資料庫（主機）上。

         如：使用者表可根據ID被水平切分為使用者1表 & 使用者2表 （表結構一致），即使用者表資料=使用者1表資料+使用者2表資料

         優點：

         （1）。單庫單表的資料保持在一定的量級，有助於效能的提高。

         （2）。切分的表的結構相同，應用程式層改造較少，只需要增加路由規則即可。

         （3）。提高了系統的穩定性和負載能力。

        缺點：

         （1）。切分後，資料是分散的，很難利用資料庫的Join操作，跨庫Join效能較差

         （2）。拆分規則難以抽象。

         （3）。分區事務的一致性難以解決。

         （4）。資料擴容的難度和維護量極大。

     以上，水平/垂直切分共同點：

• 存在分散式交易的問題。

• 存在跨節點Join的問題。

• 存在跨節點合并排序、分頁的問題。

• 存在多資料來源管理的問題。

二、水平切分方式的路由過程和分區維度

1. 水平切分的路由過程

我們在設計表時需要確定對錶按照什麼樣的規則進行分庫分表。

例如，當有新使用者時，程式得確定

          （1）。將此使用者的資訊添加到哪個表中；

           （2）。在登入時我們需要通過使用者的帳號找到資料庫中對應的記錄。

         所有這些都需要按照某一規則進行路由請求，因為請求所需要的資料分布在不同的分區表中。

以上：針對輸入的請求，通過分庫分表規則尋找到對應的表和庫的過程叫作路由。

例如：

分庫分表的規則是user_id % 4，當使用者新註冊了一個帳號時，假設使用者的ID是123，我們就可以通過123 % 4 = 3確定此帳號應該被儲存在User3表中。

當ID為123的使用者登入時，我們可通過123 % 4 = 3計算後，確定其被記錄在User3中。

2. 水平切分的分區維度（可參考Myca提供的切片方式）

【1】按照雜湊切片

         雜湊分區：對資料的某個欄位求雜湊，再除以分區總數後模數，模數後相同的資料為一個分區。

         按照雜湊分區常常應用於資料沒有時效性的情況，比如所有資料無論是在什麼時間產生的，都需要進行處理或者查詢。

         優點：資料切片比較均勻，對資料壓力分散的效果較好。

         缺點：資料分散後，對於查詢需求需要進行彙總處理。

【2】按照時間切片

         時間分區：按照時間的範圍將資料分布到不同的分區上。（這種切片方式適用於有明顯時間特點的資料）

三、分區後的交易處理機制

（一）、分散式交易

由於我們將單表的資料切片後儲存在多個資料庫甚至多個資料庫執行個體中，所以依靠資料庫本身的事務機制不能滿足所有情境的需要。

但是，我們推薦在一個資料庫執行個體中的操作儘可能使用本地事務來保證一致性，跨資料庫執行個體的一系列更新操作需要根據事務路由在不同的資料來源中完成，各個資料來源之間的更新操作需要通過分散式交易處理。

主流的分散式交易解決方案有三種：兩階段交易認可協議、最大努力保證模式和事務補償機制。

1、兩階段交易認可協議

兩階段交易認可協議將分散式交易分為兩個階段，一個是準備階段，一個是提交階段，兩個階段都由交易管理員發起。

基於兩階段交易認可協議，交易管理員能夠最大限度地保證跨資料庫操作的事務的原子性，是分布式系統內容下最嚴格的事務實現方法。

符合J2EE規範的AppServer（例如：Websphere、Weblogic、Jboss等）對關係型資料庫資料來源和訊息佇列都實現了兩階段交易認可協議，只需在使用時配置即可

:

但是，兩階段交易認可協議也帶來了效能方面的問題，難於進行水平伸縮，因為在提交事務的過程中，交易管理員需要和每個參與者進行準備和提交的操作的協調，在準備階段鎖定資源，在提交階段消費資源。

但是由於參與者較多，鎖定資源和消費資源之間的時間差被拉長，導致響應速度較慢，在此期間產生死結或者不確定結果的可能性較大。因此，在互連網行業裡，為了追求效能的提升，很少使用兩階段交易認可協議。

另外，由於兩階段交易認可協議是阻塞協議，在極端情況下不能快速響應請求方，因此有人提出了三階段提交協議，解決了兩階段交易認可協議的阻塞問題，但仍然需要交易管理員在參與者之間協調，才能完成一個分散式交易。

2、最大努力保證模式

這是一種非常通用的保證分布式一致性的模式，很多開發人員一直在使用，但是並未意識到這是一種模式。最大努力保證模式適用於對一致性要求並不十分嚴格但是對效能要求較高的情境。

具體的實現方法是，在更新多個資源時，將多個資源的提交盡量延後到最後一刻處理，這樣的話，如果商務程序出現問題，則所有的資源更新都可以復原，事務仍然保持一致。

唯一可能出現問題的情況是在提交多個資源時發生了系統問題，比如網路問題等，但是這種情況是非常罕見的，一旦出現這種情況，就需要進行即時補償，將已提交的事務進行復原，這和我們常說的TCC模式有些類似。

下面是使用最大努力保證模式的一個範例，在該範例中涉及兩個操作，一個是從訊息佇列消費訊息，一個是更新資料庫，需要保證分布式的一致性。

（1）開始訊息事務。

（2）開始資料庫事務。

（3）接收訊息。

（4）更新資料庫。

（5）提交資料庫事務。

（6）提交訊息事務。

這時，從第1步到第4步並不是很關鍵，關鍵的是第5步和第6步，需要將其放在最後一起提交，盡最大努力保證前面的業務處理的一致性。

到了第5步和第6步，商務邏輯處理完成，這時只可能發生系統錯誤，如果第5步失敗，則可以將訊息佇列和資料庫事務全部復原，保持一致。如果第5步成功，第6步遇到了網路逾時等問題，則這是唯一可能產生問題的情況。

在這種情況下，訊息的消費過程並沒有被提交到訊息佇列，訊息佇列可能會重新發送訊息給其他訊息處理服務，這會導致訊息被重複消費，但是可以通過等冪處理來保證消除重複訊息帶來的影響。

當然，在使用這種模式時，我們要充分考慮每個資源的提交順序。我們在生產實踐中遇到的一種反模式，就是在資料庫事務中嵌套遠程調用，而且遠程調用是耗時任務，導致資料庫事務被拉長，最後拖垮資料庫。

因此，上面的案例涉及的是訊息事務嵌套資料庫事務，在這裡必須進行充分評估和設計，才可以規避事務風險。

3、事務補償機制

顯然，在對效能要求很高的情境中，兩階段交易認可協議並不是一種好方案，最大努力保證模式也會使多個分布式操作互相嵌套，有可能互相影響。這裡，我們給出事務補償機制，其效能很高，並且能夠盡最大可能地保證事務的最終一致性。

在資料庫分庫分表後，如果涉及的多個更新操作在某一個資料庫範圍內完成，則可以使用資料庫內的本地事務保證一致性；對於跨庫的多個操作，可通過補償和重試，使其在一定的時間視窗內完成操作，這樣就可以實現事務的最終一致性，突破事務遇到問題就滾回的傳統思路。

如果採用事務補償機制，則在遇到問題時，我們需要記錄遇到問題的環境、資訊、步驟、狀態等，後續通過重試機制使其達到最終一致性，詳細內容可以參考《分布式服務架構：原理、設計與實戰》第2章，徹底理解ACID原理、CAP理論、BASE原理、最終一致性模式等內容。

 

 本文來自於：

https://www.toutiao.com/a6545626478447428103/?tt_from=weixin&utm_campaign=client_share&article_category=stock&timestamp=1524215325&app=news_article&utm_source=weixin&iid=28070358035&utm_medium=toutiao_android&wxshare_count=1

 

001---mysql分庫分表