掌握之分布式-6.分布式數(shù)據(jù)庫

掌握高并發(fā)、高可用架構(gòu)

第三章 分布式

本章介紹分布式架構(gòu)的底層技術(shù)。主要說明面試過程中可能被問到的技術(shù)點。

第六節(jié) 分布式數(shù)據(jù)庫MyCat

分庫分表 Sharding

1. 分庫分表的方法

垂直切分，也就是因為表多而數(shù)據(jù)多，將關(guān)系緊密（比如統(tǒng)一模塊）的表切分出來放到一個服務(wù)器中

水平切分，表不多，而是表中數(shù)據(jù)量龐大，也就是把表的數(shù)據(jù)按照某種規(guī)則切分到多個服務(wù)器中

現(xiàn)實中多是這兩種的混合

2. 分庫分表需要解決的問題

• 事務(wù)問題

  解決方案一：使用分布式事務(wù)；優(yōu)點是，由數(shù)據(jù)庫管理，簡單有效；缺點是，性能代價高

  解決方案二：將分布式事務(wù)拆分成單個數(shù)據(jù)庫的小事務(wù)，通過程序來總控各個小事務(wù)；優(yōu)點，性能好一些；缺點，代碼耦合高

• 跨節(jié)點join的問題

  只要是進(jìn)行切分，跨節(jié)點Join問題不可避免。但良好的設(shè)計和切分可以減少此類情況的發(fā)生

  普遍的解決方案是分兩次查詢，第一次查詢找出關(guān)聯(lián)數(shù)據(jù)的ID，然后根據(jù)這些ID發(fā)起第二次的查詢

• 跨節(jié)點的count、order by、group by以及聚合函數(shù)問題

  這是一類問題，因為它們都需要基于全部數(shù)據(jù)進(jìn)行計算，而多數(shù)的代理都不會自動處理合并工作

  解決方案與跨節(jié)點Join一樣，分別在各個節(jié)點得到結(jié)果后在應(yīng)用程序進(jìn)行合并，不同的是每個節(jié)點的查詢可以并行執(zhí)行

• 數(shù)據(jù)遷移、容量規(guī)劃、擴(kuò)容的問題

• ID問題

  一旦數(shù)據(jù)庫被切分到多個物理節(jié)點上，我們將不能再依賴數(shù)據(jù)庫自身的主鍵生成機(jī)制。一方面，某個分區(qū)數(shù)據(jù)庫自生成的ID無法保證全局唯一性；另一方面，應(yīng)用程序在插入數(shù)據(jù)之前要先獲取到ID，以便對SQL進(jìn)行路由

  以下是常見的主鍵生成策略

  UUID，簡單，但是數(shù)據(jù)過長，占空間，而且建索引和基于索引進(jìn)行查詢都有性能問題

  基于數(shù)據(jù)庫維護(hù)一個Sequence表，表的壓力會很大，而且有單點問題，一旦發(fā)生故障，整個應(yīng)用程序?qū)o法使用

  Twitter的分布式自增ID算法Snowflake

• 跨節(jié)點的排序分頁

  一般來說，分頁時需要按照指定字段進(jìn)行排序。當(dāng)排序字段就是分片字段時，我們根據(jù)分片規(guī)則可以比較容易定位到指定的分片，當(dāng)排序字段不是分片字段時，情況就比較復(fù)雜了。為了最終結(jié)果的準(zhǔn)確性，我們需要在不同的分片節(jié)點中將數(shù)據(jù)進(jìn)行排序并返回，并將不同分片的結(jié)果集進(jìn)行匯總和再次排序，最后再返回給用戶

  

  如果只是取第一頁的數(shù)據(jù)，看起來對性能的影響并不大。但是，如果取第10頁的數(shù)據(jù)，情況將復(fù)雜的多。

  

  因為各分片節(jié)點的數(shù)據(jù)都是隨機(jī)的，為了排序的準(zhǔn)確性，必須把所有分片節(jié)點的前N頁數(shù)據(jù)都排序好后做合并，最后再進(jìn)行整體的排序。特別的消耗資源，分頁頁碼越大，性能越差。

  解決方案如下：

  在前端做分頁，并且限定只能看前n的數(shù)據(jù)

  如果是后臺程序要獲取分頁數(shù)據(jù)，可以加大page size，比如獲取5000條記錄，有效減少分頁數(shù)

  分庫設(shè)計時，配套大數(shù)據(jù)平臺匯總所有分庫的記錄，有些分頁查詢可以走大數(shù)據(jù)平臺

• 分庫數(shù)量

  分庫數(shù)量和彈庫能處理的記錄數(shù)有關(guān)，一般來說，MySql單庫超過5000萬條記錄，Oracle單庫超過1億條記錄，DB壓力就很大。一般建議初次分庫數(shù)量為4-8個庫

3. 分布式事務(wù)

• XA規(guī)范

  主要定義了（全局）事務(wù)管理器（Transaction Manager）和（局部）資源管理器（Resource Manager）之間的接口。XA接口是雙向的系統(tǒng)接口，在事務(wù)管理器和一個或多個資源管理器之間形成通信橋梁

  事務(wù)管理器控制著全局事務(wù)，管理事務(wù)生命周期，并協(xié)調(diào)資源

  資源管理器負(fù)責(zé)控制和管理實際資源

• JTA（Java Transaction API）

  Java平臺上的事務(wù)規(guī)范，它僅定義了接口，具體實現(xiàn)則由具體的提供商來實現(xiàn)

• 兩階段提交

  

  第一階段，準(zhǔn)備階段：事務(wù)協(xié)調(diào)者（事務(wù)管理器）給每個參與者（資源管理器）發(fā)送Prepare消息，每個參與者要么直接返回失敗，要么在本地執(zhí)行事務(wù)，寫本地的redo和undo日志，但不提交

  第二階段，提交階段：如果協(xié)調(diào)者收到了參與者的失敗消息或者超時，直接給每個參與者發(fā)送回滾（Rollback）消息，否則，發(fā)送Commit消息；參與者根據(jù)協(xié)調(diào)者的指令執(zhí)行回滾或提交操作，并釋放所有事務(wù)處理過程中的鎖資源

  優(yōu)點：效率高

  缺點：當(dāng)事務(wù)的并發(fā)量達(dá)到一定數(shù)量時，會出現(xiàn)大量的事務(wù)積壓甚至出現(xiàn)死鎖，系統(tǒng)性能會嚴(yán)重下降

• 一階段提交（Best Efforts 1PC模式）

  就是從應(yīng)用程序向數(shù)據(jù)庫發(fā)出請求到數(shù)據(jù)庫完成提交或回滾之后將結(jié)果返回給應(yīng)用程序的過程，非常直白

• 事務(wù)補(bǔ)償機(jī)制

  像Best Efforts 1PC模式，前提是應(yīng)用程序能獲取所有的數(shù)據(jù)源，然后使用同一個事務(wù)管理器（指Spring的事務(wù)管理器）管理事務(wù)，最典型的應(yīng)用場景是數(shù)據(jù)庫sharding

  對于那些基于WebService、RPC、JMS等高度自治的分布式系統(tǒng)接口，Best Efforts 1PC無能為力，可以通過事務(wù)補(bǔ)償機(jī)制來實現(xiàn)最終一致性