分布式數(shù)據(jù)庫產(chǎn)品

1、分布式數(shù)據(jù)庫數(shù)據(jù)持久層產(chǎn)品線關系型數(shù)據(jù)庫產(chǎn)品關系型數(shù)據(jù)庫集群組件數(shù)據(jù)傳輸工具（同步、備份恢復）分布式數(shù)據(jù)庫訪問層K/V數(shù)據(jù)庫（NoSQL）分布式文件系統(tǒng)大數(shù)據(jù)平臺產(chǎn)品2分布式數(shù)據(jù)庫3數(shù)據(jù)庫體系結構4數(shù)據(jù)庫系統(tǒng)的體系結構受其運行所在的計算機系統(tǒng)的影響很大，尤其受計算體系結構中的聯(lián)網(wǎng)、并行和分布式的影響：l 集中式數(shù)據(jù)庫系統(tǒng)：運行在一臺計算機上，不與其他計算機系統(tǒng)交互的數(shù)據(jù)庫系統(tǒng)；l 客戶-服務器數(shù)據(jù)庫系統(tǒng)：計算機的的聯(lián)網(wǎng)使的任務可以分別劃分在服務器和客戶端上執(zhí)行；l 并行數(shù)據(jù)庫系統(tǒng)：通過網(wǎng)絡連接多個CPU和磁盤來提高處理速度和I/O速度；l 分布式數(shù)據(jù)庫系統(tǒng)：分布式數(shù)據(jù)庫系統(tǒng)用來處理地理上或者管

2、理上分布在多個數(shù)據(jù)庫系統(tǒng)中的數(shù)據(jù)；并行數(shù)據(jù)庫5并行數(shù)據(jù)庫系統(tǒng)（Parallel Database System）是新一代高性能的數(shù)據(jù)庫系統(tǒng)，是在MPP和集群并行計算環(huán)境的基礎上建立的數(shù)據(jù)庫系統(tǒng)。并行數(shù)據(jù)庫系統(tǒng)的目標是高性能（High Performance）和高可用性（High Availability），通過多個處理節(jié)點并行執(zhí)行數(shù)據(jù)庫任務，提高整個數(shù)據(jù)庫系統(tǒng)的性能和可用性。并行數(shù)據(jù)庫系統(tǒng)基于多處理節(jié)點的物理結構，將數(shù)據(jù)庫管理技術與并行處理技術有機結合，來實現(xiàn)系統(tǒng)的高性能。并行數(shù)據(jù)庫分為：l共享內(nèi)存l共享磁盤（例如：Oracle Rac）l無共享（例如：Teradata產(chǎn)品、IBM DB2 P

3、urceScale）分布式數(shù)據(jù)庫6分布式數(shù)據(jù)庫系統(tǒng)（distributed database system），數(shù)據(jù)存儲在多臺計算機中，通過網(wǎng)絡相互通信，計算機之間不共享主存儲器或磁盤。分布式數(shù)據(jù)系統(tǒng)由一些松耦合的計算機組成，不共享任何物理部件。集中式數(shù)據(jù)與分布式數(shù)據(jù)庫的主要區(qū)別在于，前者數(shù)據(jù)存儲在一臺計算機中，后者數(shù)據(jù)存儲在多臺分散的計算機中。數(shù)據(jù)的分散給事務處理和查詢處理帶來新的難題；也就是所謂的分布式事務如何保證，跨庫查詢?nèi)绾螆?zhí)行。分布式數(shù)據(jù)庫-透明性7分布式數(shù)據(jù)庫系統(tǒng)的用戶不需要知道數(shù)據(jù)的物理位置，也不需要知道如何訪問某個數(shù)據(jù)庫節(jié)點的數(shù)據(jù)；l切片透明性：用戶不需要知道數(shù)據(jù)是如何進行切片的

4、；l復制透明性：用戶不需要關心數(shù)據(jù)或者切片的如何復制的，也不需要關心副本存放的位置；l位置透明性：用戶不需要關心數(shù)據(jù)的物理位置，也不需要關心如何找到數(shù)據(jù)；分布式數(shù)據(jù)庫-應用場景8取代傳統(tǒng)企業(yè)級架構中商業(yè)數(shù)據(jù)庫產(chǎn)品（Oracle、DB2），替換掉小型服務器和FC存儲和網(wǎng)絡交換設備。通過分布式的水平擴展（Scale-out）能力，提高數(shù)據(jù)的IO訪問性能和安全性，實現(xiàn)數(shù)據(jù)的管理、拆分、路由、擴容、遷移等工作。應用場景：l 單節(jié)點數(shù)據(jù)庫數(shù)據(jù)量大l 單節(jié)點數(shù)據(jù)庫的并發(fā)很高l 商業(yè)數(shù)據(jù)庫的許可費用高l 應用層和服務層的業(yè)務邏輯變化很快，對于擴展性要求較高分布式數(shù)據(jù)庫-數(shù)據(jù)拆分9ID賬戶密碼區(qū)域狀態(tài)用戶姓名

5、手機家庭電話聯(lián)系地址郵箱性別垂直拆分，拆分業(yè)務把一個表結構拆分為兩個表結構例如：把下表拆分為賬戶表和用戶信息表水平拆分，拆分數(shù)據(jù)把一個表中的數(shù)據(jù)拆分為兩個表，兩表結構相同l 水平拆分，拆分數(shù)據(jù)l 垂直拆分，拆分業(yè)務分布式數(shù)據(jù)庫-分庫分表10通過切片對集中式數(shù)據(jù)庫進行分庫分表，把一個數(shù)據(jù)庫的業(yè)務數(shù)據(jù)分成多個物理數(shù)據(jù)庫。系統(tǒng)經(jīng)sharding（切片）改造之后，原來單一的數(shù)據(jù)庫會演變成多個數(shù)據(jù)庫，如何確保多數(shù)據(jù)源同時操作的原子性和一致性是不得不考慮的一個問題；實現(xiàn)Sharding需要解決一系列關鍵的技術問題，主要包括：切分策略、節(jié)點路由、全局主鍵生成、跨節(jié)點排序/分組/表關聯(lián)、多數(shù)據(jù)源事務處理和數(shù)據(jù)

6、庫擴容等。分布式數(shù)據(jù)庫-分庫分表11通過切片對集中式數(shù)據(jù)庫進行分庫分表，把一個數(shù)據(jù)庫的業(yè)務數(shù)據(jù)分成多個物理數(shù)據(jù)庫。DB垂直拆分DB1DB2業(yè)務緊密，關聯(lián)緊密的表分在一個切片里水平拆分數(shù)據(jù)量小，增量緩慢，則不需要再劃分數(shù)據(jù)量大，增量迅速，則需要再進行水平拆分DB2_1DB2_2DB2_3DB2_41.將主表和其關聯(lián)的表放到同一個切片中，避免跨切片查詢。（拆分根據(jù)表的ID進行散列拆分）2.講業(yè)務相近并且具有相同數(shù)據(jù)增長速率的兩個或者多個切片放到同一個數(shù)據(jù)庫中。目標：一次數(shù)據(jù)庫業(yè)務數(shù)據(jù)的操作（查詢、更改數(shù)據(jù)），在一個數(shù)據(jù)庫中完成。對數(shù)據(jù)庫進行分庫分表(Sharding)前，需要開發(fā)人員充分了解系統(tǒng)業(yè)

7、務邏輯和數(shù)據(jù)庫結構：l 建議是繪制一張數(shù)據(jù)庫ER圖或領域模型圖，如果項目使用數(shù)據(jù)驅(qū)動的開發(fā)方式，團隊以數(shù)據(jù)庫ER圖作為業(yè)務交流的基礎，則自然會選擇數(shù)據(jù)庫ER圖l 如果項目使用的是領域驅(qū)動的開發(fā)方式，并通過OR-Mapping構建了一個良好的領域模型，那么領域模型圖無疑是最好的選擇。更加傾向使用領域模型圖，因為進行切分時更多的是以業(yè)務為依據(jù)進行分析判斷，領域模型無疑更加清晰和直觀。避免跨庫操作。如需要，在應用層協(xié)調(diào)解決此問題。最后拆分到五個數(shù)據(jù)庫中12分布式事務-兩階段提交12分布式事務處理（ Distributed Transaction Processing ， DTP ）涉及多個分布在不同

8、地方的數(shù)據(jù)庫，但對數(shù)據(jù)庫的操作必須全部被提交或者回滾。只要任一數(shù)據(jù)庫操作時失敗，所有參與事務的數(shù)據(jù)庫都需要回滾。使用兩階段提交協(xié)議2PC。DB1DB2事務管理器預備（Prepare）預備（Prepare）就緒（Ready）就緒（Ready）第一階段：準備階段DB1DB2事務管理器預備（Prepare）預備（Prepare）異常（Abort）就緒（Ready）第一階段：準備階段DB1DB2事務管理器提交（Commit）提交（Commit）已提交確認已提交確認第二階段：提交階段DB1DB2事務管理器回滾（Rollback）回滾（Rollback）已回滾已回滾第二階段：回滾階段兩階段提交協(xié)議的問題：

9、l性能瓶頸，數(shù)據(jù)庫在提交請求階段應答后對很多資源處于鎖定狀態(tài)，要等到事務管理器收集齊所有數(shù)據(jù)庫的應答后，才能發(fā)commit或者rollback消息結束這種鎖定；（鎖定時間的長度是由最慢的一個數(shù)據(jù)庫制約）l分布式系統(tǒng)中節(jié)點越多，存在緩慢網(wǎng)絡或者故障節(jié)點的概率也就越大，資源被長時間鎖定的概率指數(shù)上升；l從業(yè)務功能劃分的角度上，盡量避免使用分布式事務兩階段提交；分布式事務-事務補償13在某些對數(shù)據(jù)一致的實時性要求并不高的系統(tǒng)環(huán)境中，只要在一個可以接受的時間周期內(nèi)達到最終一致性即可，這使得事務補償機制成為一種可行的方案。事務補償?shù)膶崿F(xiàn)與系統(tǒng)業(yè)務緊密相關，并沒有一種標準的處理方式，是大多數(shù)情況下最合適的

10、分布式事務的保障機制，只能適用于對事務性要求不高，允許數(shù)據(jù)“最終一致”即可的系統(tǒng)，犧牲實時一致性，但是能獲得最大的性能回報。事務補償分為兩種機制，事務補償機制和基于消息的最終一致性機制：事務補償機制，基本可以是做到準實時的事務補償（實時性較好），但需要大量的代碼研發(fā)工作來保障事務的完整性；基于消息的最終一致性機制，對于實時性要求不高，可使用BASE策略中的基于消息的最終一致性是比較好的解決方案。這種方案真正實現(xiàn)一個事務的兩個服務的真正解耦，解耦的關鍵就是異步消息和消息持久化機制。 14分布式事務-事務補償機制14在應用層或者服務層中，任何一個分布事務的正向操作都必須生成一個符合回滾規(guī)則的可逆向

11、操作。例如：一個用戶跨銀行的轉(zhuǎn)賬，該事務涉及到調(diào)用兩個Service服務，一個是本地提供的取款服務，一個是異地目標銀行提供的存款服務，該兩個服務本身無狀態(tài)且獨立，構成一個完整的事務。DB1支行ADB2支行B取款服務存款服務中間狀態(tài)緩存1234671匯款轉(zhuǎn)賬分布式事務登記，開始一個分布式事務，生成分布式事務每一個操作的逆向操作和運行狀態(tài)；從支行A的某賬戶中取款100元，賬戶余額減去100元，并凍結賬戶；通知事務中間狀態(tài)緩存，取款事務操作提交完成，修改取款操作的狀態(tài)；調(diào)用異地支行B中的存款服務，運行存款服務業(yè)務；為某賬戶存款100元，該賬戶余額增加100元；通知支行A的取款服務，匯款操作完成，并通

12、知事務中間狀態(tài)緩存，修改存款操作的狀態(tài)為成功，解鎖支行A凍結的賬戶，并通知用戶；如果第六步存款操作不成功，事務中間狀態(tài)緩存會持續(xù)調(diào)用支行B存款服務，直到存款操作成功完成；如果多次調(diào)用存款服務，存款操作沒有成功執(zhí)行，事務中間狀態(tài)緩存會回滾該匯款轉(zhuǎn)賬分布式事務，回滾支行A中的取款操作（根據(jù)取款操作的逆向操作）； 正向操作和逆向操作都有可能會出現(xiàn)多次調(diào)用；6234568785登記取款操作取款回滾修改狀態(tài)調(diào)用存款操作結果通知再次調(diào)用準實時性，會增加分布式系統(tǒng)的復雜度15分布式事務-基于消息最終一致性機制15對于轉(zhuǎn)賬操作，原有的兩個服務調(diào)用變化為第一步調(diào)用本地的取款服務，第二步發(fā)送異地取款的異步消息到消

13、息中間件。消息中間件得到消息后對消息解析，然后調(diào)用異地銀行提供的存款服務進行存款，如果服務調(diào)用失敗則進行重試以保證事務的最終一致性。只要兩個操作都成功即可以返回客戶成功。在本地取款到異地存款兩個服務調(diào)用之間，會存在一個真空期，這段時間相關現(xiàn)金不在任何一個賬戶，而只是在一個事務的中間狀態(tài)，但是客戶并不關心這個，只要在約定的時間保證事務最終的一致性即可。 DB1支行ADB2支行B取款服務存款服務215674取款回滾取款操作取款回滾調(diào)用存款操作結果通知再次調(diào)用發(fā)送存款消息37消息中間件實時性較差，但對系統(tǒng)性能開銷很小16分布式數(shù)據(jù)庫-跨庫Join查詢16分布式查詢處理，從應用層或者服務層的角度，應用

14、業(yè)務功能劃分的越清晰，越能避免在分布式數(shù)據(jù)庫環(huán)境中出現(xiàn)跨庫Join查詢的情況。l由應用層或者服務層進行跨庫Join的分布式查詢的SQL分解，并在內(nèi)存中保存中間數(shù)據(jù)結果并做最終的數(shù)據(jù)查詢的結果合并；l由查詢發(fā)起的數(shù)據(jù)庫進行數(shù)據(jù)收集，其他節(jié)點的數(shù)據(jù)庫把相關的數(shù)據(jù)傳輸?shù)桨l(fā)起數(shù)據(jù)庫后，進行查詢處理；目標：一個好的分布式查詢，應該使數(shù)據(jù)的傳輸量和通信次數(shù)最少，這樣才能使查詢所花費的數(shù)據(jù)傳輸和通信時間最少，從而減少查詢的總代價；分布式數(shù)據(jù)庫-跨庫Join查詢17產(chǎn)品表（Pid，Pname，type，price）用戶表（Uid，Uname）訂單表（Oid，Uid，TotalPrices）訂單明細表（id，O

15、id，Pid，amount，prices）產(chǎn)品表訂單明細表用戶表訂單表數(shù)據(jù)庫A數(shù)據(jù)庫B查看用戶名User1的購買的訂單中產(chǎn)品類型為“電子類”的金額總數(shù)；SELECT 用戶表.Uname，產(chǎn)品表.type，count(訂單明細表.Pries) AS 購買金額總數(shù) FROM 產(chǎn)品表，用戶表，訂單表，訂單明細表 Where 用戶表.Uname =User1 AND 產(chǎn)品表.type = 電子類AND 用戶表.Uid = 訂單表.Uid AND 訂單表.Oid = 訂單明細表.OidAND 產(chǎn)品表.Pid = 訂單明細表.PidProxyApplication用戶名用戶名產(chǎn)品類型產(chǎn)品類型購買金額總數(shù)購

16、買金額總數(shù)User1電子類16800元策略1：把用戶表和產(chǎn)品表的數(shù)據(jù)傳輸?shù)綌?shù)據(jù)庫A中進行查詢，性能很差，浪費網(wǎng)絡帶寬；策略2：把數(shù)據(jù)庫A的數(shù)據(jù)傳輸?shù)綌?shù)據(jù)庫B中進行查詢，性能很差，浪費網(wǎng)絡帶寬；策略3：在Proxy中進行SQL拆分，例如在數(shù)據(jù)庫B中，先查詢 用戶“User1”的所有訂單編號，把該用戶的訂單編號傳輸?shù)綌?shù)據(jù)庫A中執(zhí)行進一步數(shù)據(jù)查詢，性能快，網(wǎng)絡帶寬開銷很小；策略4：在Application層，對SQL查詢進行分解查詢，在Application層的內(nèi)存中進行數(shù)據(jù)的合并統(tǒng)計，并產(chǎn)生最終查詢結果，對數(shù)據(jù)庫的性能和網(wǎng)絡帶寬開銷很小，但會增加應用層的性能開銷，不適合中間結果數(shù)據(jù)較大的查詢；策略

17、5：需要跨庫查詢的關系表，四個表復制到一個查詢庫，由查詢庫提供分布式查詢；查詢庫分布式數(shù)據(jù)庫18分布式數(shù)據(jù)庫19分布式數(shù)據(jù)庫產(chǎn)品把數(shù)據(jù)交互的工作封裝成 數(shù)據(jù)訪問層，服務層不直接與數(shù)據(jù)庫交互，由數(shù)據(jù)訪問層來提供數(shù)據(jù)的訪問策略。幫助服務層完成數(shù)據(jù)的拆分以及整個數(shù)據(jù)的管理、擴容、遷移等工作。數(shù)據(jù)訪問層幫助數(shù)據(jù)完成拆分，并對數(shù)據(jù)進行管理、擴容、遷移等工作。通過訪問層讓應用可以路由到已被分庫分表的數(shù)據(jù)庫主從節(jié)點上；分布式數(shù)據(jù)庫場景需要關系型數(shù)據(jù)庫產(chǎn)品和Proxy數(shù)據(jù)訪問層產(chǎn)品來進行搭建。功能列表20l數(shù)據(jù)庫讀寫分離，雙機容災熱備 l根據(jù)業(yè)務拆分數(shù)據(jù)庫，水平和垂直拆分業(yè)務數(shù)據(jù)（分庫分表）l數(shù)據(jù)訪問層自定義

18、數(shù)據(jù)訪問路由策略，數(shù)據(jù)訪問路由自動選擇l支持三種分布式事物保障機制，兩階段提交、事物補償機制、基于消息的最終一致性l支持分布式查詢處理l全局主鍵生成機制l數(shù)據(jù)庫自動擴容、遷移l開放API，與云計算IaaS平臺結合并構建云數(shù)據(jù)庫服務，支持一鍵申請、數(shù)據(jù)庫環(huán)境HA、自動備份恢復等功能易用云數(shù)據(jù)庫提供一鍵申請、自動備份、故障自動遷移、誤刪數(shù)據(jù)可恢復，高可靠的MySQL、MariaDB、MongoDB云服務。應用場景：需要使用關系型和K/V類型數(shù)據(jù)庫服務的各種業(yè)務。l高可用：自動對數(shù)據(jù)庫進行高可用部署，保障服務在不可用時自動完成切換l數(shù)據(jù)備份：實時將數(shù)據(jù)庫鏡像及日志備份至云存儲、實現(xiàn)針對數(shù)據(jù)庫實例的鏡

19、像恢復和時間點恢復l安全隔離：通過使用安全組功能，增強原有數(shù)據(jù)庫的訪問權限控制ClientProxyProxyDBDBDBDBDBDBMySQL實例MariaDB實例MongoDB實例22數(shù)據(jù)庫讀寫分離22訂單應用服務器用戶商品商品表數(shù)據(jù)庫從庫（讀）用戶表訂單表應用服務器從數(shù)據(jù)庫服務器負載均衡器訂單應用服務器用戶商品負載均衡器主數(shù)據(jù)庫服務器寫庫：需要寫入數(shù)據(jù)庫的事務操作讀庫：緩存訪問不命中、緩存過期、需要讀取數(shù)據(jù)庫的事務操作分布式緩存集群商品表數(shù)據(jù)庫主庫（寫）用戶表訂單表分布式緩存集群主從庫數(shù)據(jù)同步分布式數(shù)據(jù)庫23EonDB數(shù)據(jù)訪問層Proxy訂單用戶商品負載均衡器訂單用戶商品用戶（主）分布式緩存集群商品（主）用戶（從）交易（從）商品（從）交易（主）訂單服務商品查詢服務登錄服務服務層應用層應用服務器應用服務器新增服務數(shù)據(jù)復制數(shù)據(jù)復制數(shù)據(jù)復制讀寫分離（主從）分庫分表水平分割，將相同業(yè)務不同的數(shù)據(jù)放到不同的數(shù)據(jù)庫中垂直分割，將不同的業(yè)務數(shù)據(jù)放到不同的數(shù)據(jù)庫中訪問路由策略自動擴容，增加數(shù)據(jù)節(jié)點（數(shù)