數(shù)據(jù)庫應(yīng)用與設(shè)計-大型數(shù)據(jù)庫系統(tǒng)架構(gòu)設(shè)計方法課件

1、第三章大型數(shù)據(jù)庫系統(tǒng)應(yīng)用設(shè)計方法可擴展性、高可用性及負載均衡基本概念可擴展性（Scalability|伸縮性）：在一些大的系統(tǒng)中，預(yù)測最終用戶的數(shù)量和行為是非常困難的，可擴展性是指系統(tǒng)適應(yīng)不斷增長的用戶數(shù)的能力。提高這種并發(fā)會話能力的一種最直觀的方式就增加資源（CPU，內(nèi)存，硬盤等），集群是解決這個問題的另一種方式，它允許一組服務(wù)器組在一起，像單個服務(wù)器一樣分擔(dān)處理一個繁重的任務(wù)。高可用性（High availability）：單一服務(wù)器的解決方案并不是一個健壯方式，因為容易出現(xiàn)單點失效。像銀行、賬單處理這樣一些關(guān)鍵的應(yīng)用程序是不能容忍哪怕是幾分鐘的死機。它們需要這樣一些服務(wù)在任何時間都可以訪

2、問并在可預(yù)期的合理的時間周期內(nèi)有響應(yīng)。集群方案通過在集群中增加的冗余的服務(wù)器，使得在其中一臺服務(wù)器失效后仍能提供服務(wù)，從而獲得高的可用性。負載均衡（Load balancing）：負載均衡是集群的一項關(guān)鍵技術(shù)，通過把請求分發(fā)給不同的服務(wù)器，從而獲得高可用性和較好的性能。一個負載均衡器可以是從一個簡單的Servlet或Plug-Ins（例如一個Linux box利用ipchains來實現(xiàn)），到昂貴的內(nèi)置SSL加速器的硬件。除此之外，負載均衡器還需執(zhí)行一些其他的重要任務(wù)，如“會話膠粘”讓一個用戶會話始終存在一個服務(wù)器上，“健康檢查”用于防止將請求分發(fā)到已失效的服務(wù)器上。有些負載均衡器也會參與我們下

3、面將要談到“失效轉(zhuǎn)移”過程?；靖拍钊蒎e（Fault tolerance）：高可用性意味著對數(shù)據(jù)正確性的要求不那么高。在J2EE集群中，當(dāng)一個服務(wù)器實例失效后，服務(wù)仍然是有效的，這是因為新的請求將被冗余服務(wù)器處理。但是，當(dāng)一個請求在一個正在失效的服務(wù)器中處理時，可能得到不正確的結(jié)果。不管有多少個錯誤，容錯的服務(wù)應(yīng)當(dāng)能確保有嚴(yán)格的正確的行為。失效轉(zhuǎn)移（Failover）：失效轉(zhuǎn)移是集群中用來獲取容錯能力的另一項關(guān)鍵的技術(shù)。當(dāng)一個結(jié)點失效后，通過選擇集群中的另一個結(jié)點，處理將會繼續(xù)而不會終止。轉(zhuǎn)移到另一個結(jié)點可以被顯式的編碼，或是通過底層平臺自動地透明地路由到另一個服務(wù)器。等冪方法（Idempot

4、ent methods）：等冪方法是指這樣一些方法：重復(fù)用相同的參數(shù)調(diào)用都能得到相同的結(jié)果。這些方法不會影響系統(tǒng)狀態(tài)，可以重復(fù)調(diào)用而不用擔(dān)心改變系統(tǒng)。例如：getUsername()就是等冪的，而deleteFile就不是。當(dāng)我們討論HTTP Session失效轉(zhuǎn)移和EJB失效轉(zhuǎn)移時，它是一個重要的概念。討論的背景主題數(shù)據(jù)庫基本問題調(diào)查關(guān)系數(shù)據(jù)庫的基本背景ACID基本概念解析范式問題解析（Normalization）數(shù)據(jù)庫基本問題調(diào)查大家都使用過哪些數(shù)據(jù)庫？哪些內(nèi)容是數(shù)據(jù)庫系統(tǒng)的關(guān)鍵點？常見的數(shù)據(jù)存儲傳統(tǒng)的數(shù)據(jù)庫系統(tǒng) Oracle DB2、SQL Server MySQL、PosgreSQL分

5、布式數(shù)據(jù)庫 Google Spanner & BigTable & MegaStore OceanBase、Hbase緩存服務(wù)器 KeyValue Store Tair Memcached Redis數(shù)據(jù)庫的主要特性ACID 原子性（Atomicity） 完整性（Consistency） 隔離性 （Isolation） 持久性 （Durability）Relation SQL Structured Query Language （即SQL） A Relational Model of Data for Large Shared Data Banks（By Edgar Codd）RDBMS之前的

6、數(shù)據(jù)庫的問題不支持?jǐn)?shù)據(jù)獨立性數(shù)據(jù)庫與應(yīng)用系統(tǒng)之間的強耦合應(yīng)用系統(tǒng)的復(fù)雜度應(yīng)用系統(tǒng)本身的規(guī)模較?。ㄐ詢r比？）關(guān)系數(shù)據(jù)庫的主要業(yè)務(wù)場景Billing （記賬類業(yè)務(wù)，電信、銀行）Booking （訂票類業(yè)務(wù)，航空）Inventory （庫存管理，零售）這些業(yè)務(wù)的共同特征是什么？關(guān)系數(shù)據(jù)庫的關(guān)系來自哪里？這是關(guān)系的一個來源另一個來源是NormalizationACID的基礎(chǔ)概念Transaction的概念借自Contract Law 一手交錢、一手交貨（Atomicity） 不會出現(xiàn)庫存為負，也不會出現(xiàn)資金為負的情況（Consistency） 可同時與多人進行交易（Isolation） 離柜概不負責(zé)（

7、Durability）Atomicity 要么全部成功，要么全不成功Consistency 寫入數(shù)據(jù)庫的數(shù)據(jù)必須滿足所有定義的約束規(guī)則（主鍵、唯一鍵、外鍵等約束）Isolation 確保并發(fā)執(zhí)行的事務(wù)就如同串行執(zhí)行的事務(wù)一樣，保證系統(tǒng)狀態(tài)（state）的一致性。Durability 一旦提交，哪怕出現(xiàn)掉電、Crash也不會丟數(shù)據(jù)幾個基礎(chǔ)概念Write-Ahead LogRedo Logical Physical PhysiologicalUndo事務(wù)槽事務(wù)標(biāo)識SCN 系統(tǒng)變更統(tǒng)一時間戳（邏輯時鐘）如何實現(xiàn)原子性一個簡單購物場景A賣一件衣服給BA的衣服庫存-1A的資金+NB的衣服庫存+1B的資金

8、-N如何實現(xiàn)原子性（2）事務(wù)槽為變更入口，單一入口（原子）每個變更的記錄都包含事務(wù)槽信息數(shù)據(jù)庫中如何保證C通過Read Dirty與鎖來解決PK/UK通過Ref檢查來解決FK的問題（需要Index）通過PreCommit trigger來做Null以及Check數(shù)據(jù)庫中如何保證I鎖控制 不同粒度的鎖（表級、塊級、記錄級） 不同維度的鎖（數(shù)據(jù)相關(guān)鎖，內(nèi)存相關(guān)鎖）MVCC Snapshot Isolation Block Image + SCN + Undo Image 判斷差別在于讀取哪個時間點的Snapshot數(shù)據(jù)庫中如何保證DLog before DataLGWR before DBWnFl

9、ush Log on Commit Durability On CommitCheckpoint Before Redo Log File ReuseACID的代價不同的Isolation對應(yīng)不同的代價 Serialiazability Read Committed (Through Snapshot) Read Dirty ? （沒有并發(fā)控制）不同的Durability級別 Flush on Commit Flush on Timeout ( Time Range) Flush on Batch ( commits count?)主題數(shù)據(jù)庫基本問題調(diào)查關(guān)系數(shù)據(jù)庫的基本背景ACID基本概念解析

10、范式問題解析（Normalization）數(shù)據(jù)庫的擴展性淺析常見數(shù)據(jù)庫系統(tǒng)回顧NORMALIZATION先做個小游戲用筆記錄下 學(xué)生名單、老師姓名、講師簡介、課程名稱、課程簡介調(diào)整下 老師（黃晉湯庸）以及對應(yīng)的老師簡介再次調(diào)整下 課程 （數(shù)據(jù)庫概論分布式數(shù)據(jù)庫原理）簡介NORMALIZATION解決的問題更新一個源頭不會出現(xiàn)異常每份數(shù)據(jù)只有一個源頭 如何保證多份數(shù)據(jù)的一致性？ 一份數(shù)據(jù)有多少個源頭？同一份數(shù)據(jù)被重復(fù)了多少次？ 對應(yīng)的存儲空間？ 為了存儲耗費的其它資源？NORMALIZATION帶來的問題表之間的依賴（關(guān)系依賴，耦合）表關(guān)聯(lián)的成本（關(guān)聯(lián)開銷，可能的IO開銷）系統(tǒng)擴展的復(fù)雜度（解耦

11、合）如何權(quán)衡NORMALIZATION盡量不要對靜態(tài)數(shù)據(jù)做Normalization 除非你希望節(jié)約存儲空間考慮范式化 Vs 反范式化的投入產(chǎn)出為什么很多IT新人喜歡Normalization 那是因為他們的老師告訴他們需要建議 適度的使用 關(guān)鍵在于判斷業(yè)務(wù)之間的耦合性主題數(shù)據(jù)庫基本問題調(diào)查關(guān)系數(shù)據(jù)庫的基本背景ACID基本概念解析范式問題解析（Normalization）數(shù)據(jù)庫的擴展性淺析常見數(shù)據(jù)庫系統(tǒng)回顧一個小實驗如何將2個人從這里送到大學(xué)城？如何將5個人從這里送到大學(xué)城？如何將50個人從這里送到大學(xué)城？如何將500個人從這里送到大學(xué)城？如何將5000個人從這里送到大學(xué)城？如何將50000個

12、人從這里送到大學(xué)城？數(shù)據(jù)庫的擴展性問題數(shù)據(jù)庫架構(gòu)、系統(tǒng)架構(gòu)在于： 如何滿足如下的要求檢索問題 Relation并發(fā)問題 Isolation Consistency(UK)一致性問題 Isolation速度問題 Performance, Durability+Isolation數(shù)據(jù)庫檢索問題如何從班級的聯(lián)系方式中找到XX的電話號碼？如何從公司的聯(lián)系方式中找到XX的電話號碼？如何從移動公司的系統(tǒng)中找到XX的電話號碼？如何從移動、電信、聯(lián)通的數(shù)據(jù)庫找到XX的電話號碼？數(shù)據(jù)庫的并發(fā)問題同時有多個人要購買手機號？如何保證大家購買的不是同一個手機號？如何支持幾百、幾千、幾萬人同時購買手機號？數(shù)據(jù)庫的一致性

13、問題如何保證大家看到的庫存有效？如何保證讀取的信息是準(zhǔn)確的？庫存的變更如何實時的提供給每一個人看到？數(shù)據(jù)庫的性能問題？如何快速的讓1個人買到號碼？ 有多快？如何快速的讓10個人買到號碼？ 要不要排隊？ 一個服務(wù)員？ 一個營業(yè)廳？PERFORMANCE VS SCALABILITY1.當(dāng)只有一個人訪問時，速度如何？2.當(dāng)有很多人訪問時，速度如何？ 大家都同樣快？如果滿足1 表示Performance很好？如何能較好的滿足2 表示系統(tǒng)有較好的Scalability一致性問題再探討新浪發(fā)的微薄需要強一致嗎？ITPUB的論壇需要強一致嗎？當(dāng)當(dāng)?shù)膱D書描述信息需要強一致嗎？12306的火車票庫存信息需要強

14、一致嗎？支付寶/財付通的賬戶余額需要強一致嗎？中行信用卡/招商銀行卡的賬戶信息需要強一致嗎?討論擴展性數(shù)據(jù)庫系統(tǒng)的擴展性Scale（擴展）就是讓我們的數(shù)據(jù)庫能夠提供更強的服務(wù)能力，更強的處理能力。Scalable（可擴展）則是表明數(shù)據(jù)庫系統(tǒng)在通過相應(yīng)升級（包括增加單機處理能力或者增加服務(wù)器數(shù)量）之后能夠達到提供更強處理能力。在理論能上來說，任何數(shù)據(jù)庫系統(tǒng)都是Scalable 的，只不過是所需要的實現(xiàn)方式不一樣而已。Scalability（擴展性）則是指一個數(shù)據(jù)庫系統(tǒng)通過相應(yīng)的升級之后所帶來處理能力提升的難易程度。雖然理論上任何系統(tǒng)都可以通過相應(yīng)的升級來達到處理能力的提升，但是不同的系統(tǒng)提升相同

15、的處理能力所需要的升級成本（資金和人力）是不一樣的，這也就是我們所說的各個數(shù)據(jù)庫應(yīng)用系統(tǒng)的 Scalability存在很大的差異。數(shù)據(jù)庫系統(tǒng)的擴展性Scale Up 則是指縱向的擴展，向上擴展，也就是通過增加當(dāng)前處理節(jié)點的處理能力來提高整體的處理能力，是通過升級現(xiàn)有服務(wù)器的配置，如增加內(nèi)存，增加CPU，增加存儲系統(tǒng)的硬件配置，或者是直接更換為處理能力更強的服務(wù)器和更為高端的存儲系統(tǒng)。Scale Out 就是指橫向的擴展，向外擴展，也就是通過增加處理節(jié)點的方式來提高整體處理能力，即通過增加機器來增加整體的處理能力。SCALE UP 優(yōu)缺點Scale Up 優(yōu)點：處理節(jié)點少，維護相對簡單；所有數(shù)據(jù)

16、都集中在一起，應(yīng)用系統(tǒng)架構(gòu)簡單，開發(fā)相對容易；Scale Up 缺點高端設(shè)備成本高，且競爭少，容易受到廠家限制；受到硬件設(shè)備發(fā)展速度限制，單臺主機的處理能力總是有極限的，容易遇到最終無法解決的性能瓶頸；設(shè)備和數(shù)據(jù)集中，發(fā)生故障后的影響較大；SCALE OUT 優(yōu)缺點Scale Out 優(yōu)點成本低，很容易通過價格低廉的PC Server 搭建出一個處理能力非常強大的計算集群；不容易遇到瓶頸，因為很容易通過添加主機增加處理能力；單個節(jié)點故障對系統(tǒng)整體影響較?。灰泊嬖谌秉c，更多的計算節(jié)點，大部分時候都是服務(wù)器主機，這自然會帶來整個系統(tǒng)維護復(fù)雜性的提高，在某些方面肯定會增加維護成本，而且對應(yīng)用系統(tǒng)的架

17、構(gòu)要求也會比 Scale Up 更高，需要集群管理軟件的配合。Scale Out 缺點處理節(jié)點多，造成系統(tǒng)架構(gòu)整體復(fù)雜度提高，應(yīng)用程序復(fù)雜度提高；集群維護難以程度更高，維護成本更大；SCALABILITY很好的數(shù)據(jù)庫應(yīng)用系統(tǒng)遵循的原則 事務(wù)相關(guān)性最小化原則 數(shù)據(jù)一致性原則 高可用及數(shù)據(jù)安全原則事務(wù)相關(guān)性最小化原則分布式的架構(gòu)帶來分布式事務(wù)的問題在傳統(tǒng)的集中式數(shù)據(jù)庫架構(gòu)中，事務(wù)的問題非常好解決，可以完全依賴數(shù)據(jù)庫本身非常成熟的事務(wù)機制來保證。但是一旦我們的數(shù)據(jù)庫作為分布式的架構(gòu)之后，很多原來在單一數(shù)據(jù)庫中所完成的事務(wù)現(xiàn)在可能需要跨多個數(shù)據(jù)庫主機，這樣原來單機事務(wù)可能就需要引入分布式事務(wù)的概念。分

18、布式事務(wù)本身就是一個非常復(fù)雜的機制不管是商業(yè)的大型數(shù)據(jù)庫系統(tǒng)還是各開源數(shù)據(jù)庫系統(tǒng)，雖然大多數(shù)數(shù)據(jù)庫廠家基本上都實現(xiàn)了這個功能，但或多或少都存在各種各樣的限制。而且也存在一些 Bug，可能造成某些事務(wù)并不能很好的保證，或者是不能順利的完成。一些解決方案1. 進行 Scale Out 設(shè)計的時候合理設(shè)計切分規(guī)則，盡可能保證事務(wù)所需數(shù)據(jù)在同一個 MySQL Server 上，避免分布式事務(wù)。2. 大事務(wù)切分成多個小事務(wù)，數(shù)據(jù)庫保證各個小事務(wù)的完整性，應(yīng)用控制各個小事務(wù)之間的整體事務(wù)完整性。3. 結(jié)合上述兩種解決方案，整合各自的優(yōu)勢，避免各自的弊端。1. 比如我們可以在保證部分核心事務(wù)所需數(shù)據(jù)在同一個

19、MySQL Server 上，而其他并不是特別重要的事務(wù)，則通過分拆成小事務(wù)和應(yīng)用系統(tǒng)結(jié)合來保證。2. 通過這樣相互平衡設(shè)計的原則，我們既可以避免應(yīng)用程序需要處理太多的小事務(wù)來保證其整體的完整性，同時也能夠避免拆分規(guī)則太多復(fù)雜而帶來后期維護難度的增加及擴展性受阻的情況數(shù)據(jù)一致性原則如何在 Scale Out 的同時又較好的保證數(shù)據(jù)一致性呢？BASE 模型。即：基本可用，柔性狀態(tài)，基本一致和最終一致簡單來說，應(yīng)用系統(tǒng)通過相關(guān)的技術(shù)實現(xiàn)，讓整個系統(tǒng)在滿足用戶使用的基礎(chǔ)上，允許數(shù)據(jù)短時間內(nèi)處于非一致狀態(tài)，而通過后續(xù)技術(shù)來保證數(shù)據(jù)在最終保證處于一致狀態(tài)。高可用及數(shù)據(jù)安全原則在支持可擴展性的同時，要注意

20、高可用性和數(shù)據(jù)安全。基本方法SHARDINGREPLICATIONCLUSTERSHARDINGSHARE NOTHING并行數(shù)據(jù)庫要求盡可能的去并行執(zhí)行數(shù)據(jù)庫操作，從而提高性能。在并行計算體系結(jié)構(gòu)實現(xiàn)中有很多可選的體系結(jié)構(gòu)。包括：Share-memory：多個cpu共享同一片內(nèi)存，cpu之間通過內(nèi)部通訊機制（interconnection network）進行通訊；Share-disk ：每一個cpu使用自己的私有內(nèi)存區(qū)域，通過內(nèi)部通訊機制直接訪問所有磁盤系統(tǒng)。Share-nothing： 每一個cpu都有私有內(nèi)存區(qū)域和私有磁盤空間，而且2個cpu不能訪問相同磁盤空間，cpu之間的通訊通過網(wǎng)

21、絡(luò)連接。并行計算體系結(jié)構(gòu)Share diskshare nothingshare memory并行計算體系結(jié)構(gòu)Shared memory 體系結(jié)構(gòu)的cpu之間通過主存進行通訊，具有很高的效率；但當(dāng)更多的cpu被添加到主機上時，內(nèi)存競爭contection就成為瓶頸，cpu越多，瓶頸越厲害。Shared disk也存在同樣問題，因為磁盤系統(tǒng)由 Interconnection Network 連接在一起。Shared memory和shared disk的基本問題是interference：當(dāng)添加更多的cpu，系統(tǒng)反而減慢，因為增加了對內(nèi)存訪問（memroy access）和網(wǎng)絡(luò)帶寬（networ

22、k bandwidth）的競爭。這樣shared nothing體系得到了廣泛的推廣。Shared nothing體系是數(shù)據(jù)庫穩(wěn)定增長，當(dāng)隨著事務(wù)數(shù)量不斷增加，增加額外的cpu和主存就可以保證每個事務(wù)處理時間不變。SHARED NOTHINGARCHITECTURE (SN)A shared nothing architecture (SN) is a distributedcomputing architecture in which each node is independent and self-sufficient, and there is no single point of c

23、ontention across the system.More specifically, none of the nodes share memory or disk storage.People typically contrast SN with systems that keep a large amount ofcentrally-stored state information, whether in a database, an applicationserver, or any other similar single point of contention. While S

24、N is bestknown in the context of web development, the concept predates theweb: Michael Stonebraker at the University of California, Berkeley usedthe term in a 1986 database paper.1 In it he mentions existingcommercial implementations of the architecture (although none arenamed explicitly). Teradata,

25、 which delivered its first system in 1983, wasprobably one of those commercial implementations.2 TandemComputers officially released NonStop SQL, a shared nothing database,in 1984. 3SHARED NOTHINGARCHITECTURE (SN)Shared nothing is popular for web development because ofits scalability. As Google has

26、demonstrated, a pure SN systemcan scale almost infinitely simply by adding nodes in the form ofinexpensive computers, since there is no single bottleneck to slowthe system down.4 Google calls this sharding. A SN systemtypically partitions its data among many nodes on differentdatabases (assigning di

27、fferent computers to deal with differentusers or queries), or may require every node to maintain its owncopy of the applications data, using some kind of coordinationprotocol. This is often referred to as database sharding.從 SHARD 到 SHARDING“Shard” 這個詞英文的意思是”碎片”，而作為數(shù)據(jù)庫相關(guān)的技術(shù)用語，似乎最早見于大型多人在線角色扮演游戲(MMOR

28、PG)中。”Sharding” 稱之為”分片”。Sharding 不是一門新技術(shù)，而是一個相對簡樸的軟件理念。MySQL 5 之后才有了數(shù)據(jù)表分區(qū)功能，那么在此之前，很多 MySQL 的潛在用戶都對MySQL 的擴展性有所顧慮，而是否具備分區(qū)功能就成了衡量一個數(shù)據(jù)庫可擴展性與否的一個關(guān)鍵指標(biāo)(當(dāng)然不是唯一指標(biāo))。數(shù)據(jù)庫擴展性是一個永恒的話題，MySQL 的推廣者經(jīng)常會被問到：如在單一數(shù)據(jù)庫上處理應(yīng)用數(shù)據(jù)捉襟見肘而需要進行分區(qū)化之類的處理，是如何辦到的呢? 答案是：Sharding。Sharding 不是一個某個特定數(shù)據(jù)庫軟件附屬的功能，而是在具體技術(shù)細節(jié)之上的抽象處理，是水平擴展(Scale

29、Out，亦或橫向擴展、向外擴展)的解決方案，其主要目的是為突破單節(jié)點數(shù)據(jù)庫服務(wù)器的 I/O 能力限制，解決數(shù)據(jù)庫擴展性問題。數(shù)據(jù)庫擴展性目前的商業(yè)數(shù)據(jù)都有自己的擴展性解決方案，在過去相對來說比較成熟，但是隨著互聯(lián)網(wǎng)的高速發(fā)展，不可避免的會帶來一些計算模式上的演變，這樣很多主流商業(yè)系統(tǒng)也難免暴露出一些不足之處。比如 Oracle 的 RAC 是采用共享存儲機制，對于 I/O 密集型的應(yīng)用，瓶頸很容易落在存儲上，這樣的機制決定后續(xù)擴容只能是 ScaleUp（向上擴展） 類型，對于硬件成本、開發(fā)人員的要求、維護成本都相對比較高。Sharding 基本上是針對開源數(shù)據(jù)庫的擴展性解決方案，很少有聽說商業(yè)

30、數(shù)據(jù)庫進行 Sharding 的。目前業(yè)界的趨勢基本上是擁抱Scale Out，逐漸從 Scale Up 中解放出來。SHARDING 的應(yīng)用場景任何技術(shù)都是在合適的場合下能發(fā)揮應(yīng)有的作用。 Sharding 也一樣。聯(lián)機游戲、IM、BSP 都是比較適合 Sharding 的應(yīng)用場景。其共性是抽象出來的數(shù)據(jù)對象之間的關(guān)聯(lián)數(shù)據(jù)很小。IM ，每個用戶如果抽象成一個數(shù)據(jù)對象，完全可以獨立存儲在任何一個地方，數(shù)據(jù)對象是 Share Nothing 的；Blog 服務(wù)提供商的站點內(nèi)容，基本為用戶生成內(nèi)容(UGC)，完全可以把不同的用戶隔離到不同的存儲集合，而對用戶來說是透明的?！癝hare Nothin

31、g” 是從數(shù)據(jù)庫集群中借用的概念，有些類型的數(shù)據(jù)粒度之間就不是 “Share Nothing” 的，比如類似交易記錄的歷史表信息，如果一條記錄中既包含賣家信息與買家信息，如果隨著時間推移，買、賣家會分別與其它用戶繼續(xù)進行交易， Sharding會可能導(dǎo)致兩個買賣家的信息會分布到不同的 Sharding DB 上，而這時如果針對買賣家查詢，就會跨越更多的 Sharding ，開銷就會比較大。Sharding 并不是數(shù)據(jù)庫擴展方案的銀彈，也有其不適合的場景，如處理事務(wù)型應(yīng)用會非常復(fù)雜。對于跨不同DB的事務(wù)，很難保證完整性，得不償失。所以，采用什么樣的 Sharding 形式，不是生搬硬套的。SHA

32、RDING與數(shù)據(jù)庫分區(qū)(PARTITION)的區(qū)別有的時候，Sharding 也被近似等同于水平分區(qū)(Horizontal Partitioning)，網(wǎng)上很多地方也用 水平分區(qū)來指代 Sharding，但二者之間實際上還是有區(qū)別的。Sharding 的思想是從分區(qū)的思想而來，但數(shù)據(jù)庫分區(qū)基本上是數(shù)據(jù)對象級別的處理，比如表和索引的分區(qū)，每個子數(shù)據(jù)集上能夠有不同的物理存儲屬性，還是單個數(shù)據(jù)庫范圍內(nèi)的操作，而 Sharding是能夠跨數(shù)據(jù)庫，甚至跨越物理機器的。SHARDING 策略Sharding根據(jù)切分規(guī)則類型，可分為兩種切分模式：數(shù)據(jù)的垂直（縱向）切分是按照不同的表（或者 Schema）來切

33、分到不同的數(shù)據(jù)庫（主機）之上，這種切可以稱之為；數(shù)據(jù)的水平（橫向）切分是根據(jù)表中的數(shù)據(jù)的邏輯關(guān)系，將同一個表中的數(shù)據(jù)按照某種條件拆分到多臺數(shù)據(jù)庫（主機）上面，這種切分稱之為。數(shù)據(jù)的垂直切分?jǐn)?shù)據(jù)的垂直切分，也可以稱之為縱向切分。將數(shù)據(jù)庫想象成為由很多個一大塊一大塊的“數(shù)據(jù)塊”（表）組成，我們垂直的將這些“數(shù)據(jù)塊”切開，然后將他們分散到多臺數(shù)據(jù)庫主機上面。這樣的切分方法就是一個垂直（縱向）的數(shù)據(jù)切分。當(dāng)我們的功能模塊越清晰，耦合度越低，數(shù)據(jù)垂直切分的規(guī)則定義也就越容易。完全可以根據(jù)功能模塊來進行數(shù)據(jù)的切分，不同功能模塊的數(shù)據(jù)存放于不同的數(shù)據(jù)庫主機中，可以很容易就避免掉跨數(shù)據(jù)庫的 Join 存在，同

34、時系統(tǒng)架構(gòu)也非常的清晰。EXAMPLE 數(shù)據(jù)庫-垂直劃分系統(tǒng)功能可以基本分為四個功能模塊：用戶，群組消息，相冊以及事件，分別對應(yīng)為如下這些表：用戶模塊表：user, user_profile, user_group, user_photo_album群組討論表：groups, group_message, group_message_content,top_message相冊相關(guān)表：photo, photo_album, photo_album_relation,photo_comment事件信息表：eventEXAMPLE 數(shù)據(jù)庫-垂直劃分群組討論模塊和用戶模塊之間主要存在通過用戶或者是群組

35、關(guān)系來進行關(guān)聯(lián)。一般關(guān)聯(lián)的時候都會是通過用戶的 id 或者nick_name 以及 group 的 id 來進行關(guān)聯(lián)，通過模塊之間的接口實現(xiàn)不會帶來太多麻煩；相冊模塊僅僅與用戶模塊存在通過用戶的關(guān)聯(lián)。這兩個模塊之間的關(guān)聯(lián)基本就有通過用戶 id 關(guān)聯(lián)的內(nèi)容，簡單清晰，接口明確；事件模塊與各個模塊可能都有關(guān)聯(lián)，但是都只關(guān)注其各個模塊中對象的ID信息，同樣可以做到很容易分拆。EXAMPLE 數(shù)據(jù)庫-垂直劃分我們第一步可以將數(shù)據(jù)庫按照功能模塊相關(guān)的表進行一次垂直拆分，每個模塊所涉及的表單獨到一個數(shù)據(jù)庫中，模塊與模塊之間的表關(guān)聯(lián)都在應(yīng)用系統(tǒng)端通過接口來處理。通過這樣的垂直切分之后，之前只能通過一個數(shù)據(jù)庫

36、來提供的服務(wù)，就被分拆成四個數(shù)據(jù)庫來提供服務(wù)，服務(wù)能力自然是增加幾倍了。垂直切分的優(yōu)缺點垂直切分的優(yōu)點數(shù)據(jù)庫的拆分簡單明了，拆分規(guī)則明確；應(yīng)用程序模塊清晰明確，整合容易；數(shù)據(jù)維護方便易行，容易定位；垂直切分的缺點部分表關(guān)聯(lián)無法在數(shù)據(jù)庫級別完成，需要在程序中完成；對于訪問極其頻繁且數(shù)據(jù)量超大的表仍然存在性能瓶頸，不一定能滿足要求；事務(wù)處理相對更為復(fù)雜；切分達到一定程度之后，擴展性會遇到限制；過讀切分可能會帶來系統(tǒng)過渡復(fù)雜而難以維護。數(shù)據(jù)的水平切分水平切分可理解為是按照數(shù)據(jù)行的切分，就是將表中的某些行切分到一個數(shù)據(jù)庫，而另外的某些行又切分到其他的數(shù)據(jù)庫中。為了能夠比較容易的判定各行數(shù)據(jù)被切分到哪個

37、數(shù)據(jù)庫中了，切分總是都需要按照某種特定的規(guī)則來進行的。如根據(jù)某個數(shù)字類型字段基于特定數(shù)目取模，某個時間類型字段的范圍，或者是某個字符類型字段的 hash 值。如EXAMPLE數(shù)據(jù)庫，所有數(shù)據(jù)都是和用戶關(guān)聯(lián)的，那么我們就可以根據(jù)用戶來進行水平拆分，將不同用戶的數(shù)據(jù)切分到不同的數(shù)據(jù)庫中。唯一有點區(qū)別的是用戶模塊中的 groups 表和用戶沒有直接關(guān)系，所以 groups 不能根據(jù)用戶來進行水平拆分。對于這種特殊情況下的表，則可以獨立出來，單獨放在一個數(shù)據(jù)庫中。EXAMPLE數(shù)據(jù)庫-水平劃分大部分的表都可以根據(jù)用戶 ID 來進行水平的切分。不同用戶相關(guān)的數(shù)據(jù)進行切分之后存放在不同的數(shù)據(jù)庫中。如將所有

38、用戶 ID 通過取模（模5）然后分別存放于兩個不同的數(shù)據(jù)庫中。每個和用戶 ID 關(guān)聯(lián)上的表都可以這樣切分。這樣，基本上每個用戶相關(guān)的數(shù)據(jù)，都在同一個數(shù)據(jù)庫中，即使是需要關(guān)聯(lián)，也可以非常簡單的關(guān)聯(lián)上。水平切分的優(yōu)缺點水平切分的優(yōu)點表關(guān)聯(lián)基本能夠在數(shù)據(jù)庫端全部完成；不會存在某些超大型數(shù)據(jù)量和高負載的表遇到瓶頸的問題；應(yīng)用程序端整體架構(gòu)改動相對較少；事務(wù)處理相對簡單；只要切分規(guī)則能夠定義好，基本上較難遇到擴展性限制；水平切分的缺點切分規(guī)則相對更為復(fù)雜，很難抽象出一個能夠滿足整個數(shù)據(jù)庫的切分規(guī)則；后期數(shù)據(jù)的維護難度有所增加，人為手工定位數(shù)據(jù)更困難；應(yīng)用系統(tǒng)各模塊耦合度較高，可能會對后面數(shù)據(jù)的遷移拆分造

39、成一定的困難。利用 MYSQL PROXY 實現(xiàn)數(shù)據(jù)切分及整合MySQL Proxy 是 MySQL 官方提供的一個數(shù)據(jù)庫代理層產(chǎn)品，和 MySQL Server 一樣，同樣是一個基于 GPL 開源協(xié)議的開源產(chǎn)品。可用來監(jiān)視、分析或者傳輸他們之間的通訊信息。他的靈活性允許你最大限度的使用它，目前具備的功能主要有連接路由，Query 分析，Query 過濾和修改，負載均衡，以及基本的 HA 機制等。實際上，MySQL Proxy 本身并不具有上述所有的這些功能，而是提供了實現(xiàn)上述功能的基礎(chǔ)。要實現(xiàn)這些功能，還需要通過我們自行編寫 LUA腳本來實現(xiàn)。MySQL Proxy 實際上是在客戶端請求與M

40、ySQL Server 之間建立了一個連接池。所有客戶端請求都是發(fā)向 MySQL Proxy，然后經(jīng)由MySQL Proxy進行相應(yīng)的分析，判斷出是讀操作還是寫操作，分發(fā)至對應(yīng)的 MySQL Server上。對于多節(jié)點 Slave 集群，也可以起做到負載均衡的效果。高可用性HIGH AVAILABILITYSINGLE MYSQL SERVERWHY HA? Something can and will fail Service Maintenance Downtime is expensive Adding HA to an existing system is complex 墨菲定律（M

41、urphys Law） Anything that can go wrong will go wrong高可用性HA-IBM定義業(yè)務(wù)連續(xù)性是指企業(yè)的一種能力，有了此能力，企業(yè)能夠抵御中斷，并根據(jù)預(yù)定義的服務(wù)級別協(xié)議正常且連續(xù)不斷地經(jīng)營重要服務(wù)。要實現(xiàn)期望的給定級別業(yè)務(wù)連續(xù)性，必須選擇一系列服務(wù)、軟件、硬件和過程，用文檔計劃加以描述，付諸實現(xiàn)并定期實踐。業(yè)務(wù)連續(xù)性解決方案必須解決有關(guān)數(shù)據(jù)、運營環(huán)境、應(yīng)用程序、用于主管環(huán)境的應(yīng)用程序以及最終用戶接口的問題。所有這些都必須予以提供，才能交付完整的業(yè)務(wù)連續(xù)性解決方案。業(yè)務(wù)連續(xù)性包括災(zāi)難恢復(fù) (DR) 和高可用性 (HA)，是指抵御所有中斷（預(yù)期中斷、意

42、外中斷以及災(zāi)難），并為所有重要應(yīng)用程序提供連續(xù)處理的能力。最終目標(biāo)是讓中斷時間少于總服務(wù)時間的 0.001%。與災(zāi)難恢復(fù)方案相比，高可用性環(huán)境通常包括要求更為苛刻的恢復(fù)時間目標(biāo)（數(shù)秒到數(shù)分鐘）和恢復(fù)點目標(biāo)（零用戶中斷）?？捎眯约墑e90%95%99%99.9%99.99%99.999%每年的停機時間36.5 天18.25 天3.65 天8.76 小時50 分鐘5 分鐘需要 100% 可用性的應(yīng)用程序嗎？在大多數(shù)情況下，可以通過實施合理的處理和系統(tǒng)管理實務(wù)來實現(xiàn)高級別的可用性。當(dāng)所需要的越接近連續(xù)可用性，則必須作出的投資就越大。在作出這種投資之前，應(yīng)該確信需要該級別的可用性。下列數(shù)字顯示不同技術(shù)所

43、能提高可用性的程度，但是需要付出的成本可能會隨之增加。系統(tǒng)可用性的定義在特定時間內(nèi)和特定條件下系統(tǒng)正常工作的相應(yīng)程度?？捎眯缘臏y量方式：系統(tǒng)的可用性(availability)，即利用率。可用性的平均值即平均利用率，其計算方法為： A = MTBF / (MTBF + MTTR)MTBF(MeanTime Between Failures)故障間隔平均時間MTTR(MeanTime To Repair)系統(tǒng)平均修復(fù)時間A=uptime/(uptime+downtime)系統(tǒng)可用性的獲得可用性容錯性(fault tolerance)完美性(perfection)冗余技術(shù)硬件冗余(redundan

44、cy)軟件冗余完美硬件整機完美性完美軟件可信軟件|時間冗余信息冗余部件完美性器件完美性|靜態(tài)冗余（部件冗余）|可用硬件動態(tài)重組|-被動重組（后備 stand-by）|-主動重組（優(yōu)美降級 graceful degradation)完美性與避錯技術(shù)完美性追求一種避錯技術(shù)，即避免出錯。要求組成系統(tǒng)的各個部件、器件具有高可用性，不允許出錯，或者出錯率降至最低。硬件的可用性與完美性指元器件的完美性、部件的完美性、整機與系統(tǒng)的完美性軟件的可用性與完美性是指軟件的正確性、完美性、兼容性。容錯性與容錯技術(shù)容錯技術(shù)：在一定程度上容忍故障的技術(shù)容錯系統(tǒng)：采用容錯技術(shù)的系統(tǒng)當(dāng)系統(tǒng)因某種原因出錯或者失效，系統(tǒng)能夠繼

45、續(xù)工作，程序能夠繼續(xù)運行，不會因計算機故障而中止或被修改，執(zhí)行結(jié)果也不包含系統(tǒng)中故障引起的差錯。容錯技術(shù)也稱為故障掩蓋技術(shù)(fault masking)。容錯性與容錯技術(shù)冗余技術(shù)是容錯技術(shù)的重要結(jié)構(gòu)，它以增加資源的辦法換取可用性。由于資源的不同，冗余技術(shù)分為硬件冗余、軟件冗余、時間冗余和信息冗余。資源與成本按線性增加，而故障概率則可按對數(shù)規(guī)律下降。冗余要消耗資源，應(yīng)當(dāng)在可用性與資源消耗之間進行權(quán)衡和折衷。雙CPU容錯系統(tǒng)當(dāng)一個 CPU板出現(xiàn)故障時，另一個 CPU保持繼續(xù)運行。這個過程對用戶是透明的，系統(tǒng)沒有受到絲毫影響，更不會引起交易的丟失，充分保證數(shù)據(jù)的一致性和完整性。系統(tǒng)的容錯結(jié)構(gòu)能夠提供

46、系統(tǒng)連續(xù)運行的能力，任何單點故障不會引起系統(tǒng)停機，系統(tǒng)提供在線的維護診斷工具可在應(yīng)用繼續(xù)運轉(zhuǎn)的情況下修復(fù)單點故障。冗余類型1.硬件冗余：增加線路、設(shè)備、部件，形成備份。2.軟件冗余：增加程序，一個程序分別用幾種途徑編寫，按一定方式執(zhí)行，分段或多種表決。3.時間冗余：指令重復(fù)執(zhí)行，程序回卷技術(shù)。4.信息冗余：增加信息數(shù)據(jù)位數(shù)，檢錯、糾錯。容錯系統(tǒng)工作方式自動偵測(AUTO-DETECT)自動偵測(Auto-Detect)通過專用的冗余偵測線路和軟件判斷系統(tǒng)運行情況，發(fā)現(xiàn)可能的錯誤和故障，進行嚴(yán)謹(jǐn)?shù)呐袛嗯c分析。確認(rèn)主機出錯后，啟動后備系統(tǒng)。偵測程序需要檢查主機硬件（處理器與外設(shè)部件）、主機網(wǎng)絡(luò)、操

47、作系統(tǒng)、數(shù)據(jù)庫、重要應(yīng)用程序、外部存儲子系統(tǒng)（如磁盤陣列）等。為了保證偵測的正確性，防止錯誤判斷，系統(tǒng)可以設(shè)置安全偵測時間、偵測時間間隔、偵測次數(shù)等安全系數(shù)，通過冗余通信連線，收集并記錄這些數(shù)據(jù)，作出分析處理。數(shù)據(jù)可信是切換的基礎(chǔ)。自動切換(AUTO-SWITCH)當(dāng)確認(rèn)某一主機出錯時，正常主機除了保證自身原來的任務(wù)繼續(xù)運行外，將根據(jù)各種不同的容錯后備模式，接管預(yù)先設(shè)定的后備作業(yè)程序，進行后續(xù)程序及服務(wù)。系統(tǒng)的接管工作包括文件系統(tǒng)、數(shù)據(jù)庫、系統(tǒng)環(huán)境（操作系統(tǒng)平臺）、網(wǎng)絡(luò)地址和應(yīng)用程序等。如果不能確定系統(tǒng)出錯，容錯監(jiān)控中心通過與管理者交互進行有效的處理。決定切換基礎(chǔ)、條件、時延、斷點自動恢復(fù)(A

48、UTO-RECOVERY)故障主機被替換后，離線進行故障修復(fù)。修復(fù)后通過冗余通信線與正常主機連線，繼而將原來的工作程序和磁盤上的數(shù)據(jù)自動切換回修復(fù)完成的主機上。這個自動完成的恢復(fù)過程用戶可以預(yù)先設(shè)置，也可以設(shè)置為半自動或不恢復(fù)。常用方法雙機雙工熱備份(MUTUALBACKUP)兩機同時運行，分不同作業(yè)，各自資源負載，故障、接管、修復(fù)、交還。雙主機通過一條TCP/IP網(wǎng)絡(luò)線以及一條RS-232電纜線相聯(lián)雙主機各自通過一條SCSI電纜線與RAID磁盤陣列相聯(lián)雙主機各自運行不同的作業(yè)，彼此獨立，并相互備援主機A故障后，主機B自動接管主機A運行。主機A的作業(yè)將在主機B上自動運行。主機A修復(fù)后，主機B將

49、把A的作業(yè)自動交還主機A。主機B故障時，主機A接管主機B的作業(yè)和數(shù)據(jù)。主機B修復(fù)時,主機A再將原來接管的作業(yè)和數(shù)據(jù)交還主機B 。主從熱備份(MASTER/SLAVE)主從式（M/S），M運行，S后備，M故障，S接管并升級為M,原M修復(fù)后作為S。雙主機通過一條TCP/IP網(wǎng)絡(luò)線以及一條RS-232電纜線相聯(lián)。雙主機各自通過一條SCSI電纜線與RAID相聯(lián)。主機A為Master，主機B為Slave。主機A處理作業(yè)和數(shù)據(jù)，主機B作為熱備份機。主機A故障后，主機B自動接管主機A的作業(yè)和數(shù)據(jù)。主機B同時接管A的主機名(Host)及網(wǎng)絡(luò)地址(IP)。主機A的作業(yè)將在主機B上自動運行。主機A的客戶(clie

50、nt)可繼續(xù)運行，無需重新登錄。主機B現(xiàn)為Master,主機A修復(fù)后作為Slave，作為熱備份機。熱備份(HOT-STANDBY)M運行，S后備M故障，S接管作M原M修復(fù)，S歸還M。RULES OF HIGHAVAILABILITYPrepare for failureAim to ensure that no important data is lostKeep it simple, stupid (KISS)Complexity is the enemy of reliabilityAutomate itTest your setup frequently!高可用常用方法主機硬件高可用 硬

51、件冗余（冷備/熱備） 主機冗余、電源冗余、網(wǎng)絡(luò)環(huán)境冗余.數(shù)據(jù)高可用 基于共享數(shù)據(jù)存儲的數(shù)據(jù)高可用 SAN、NAS、iScsi 、SAS 基于數(shù)據(jù)庫軟件的數(shù)據(jù)復(fù)制冗余 MySQL Replication、Oracle Data Guard . 基于第三方（或自行設(shè)計）的數(shù)據(jù)復(fù)制冗余 Tungeten、DBMoto、MMM .SHARE STORAGEREPLICATIONREPLICATION通過 MySQL 的 Replication，可以將一臺 MySQL 中的數(shù)據(jù)完整的同時復(fù)制到多臺主機上面的 MySQL 數(shù)據(jù)庫中，并且正常情況下這種復(fù)制的延時并不是很長。當(dāng)我們各臺服務(wù)器上面都有同樣的數(shù)據(jù)

52、之后，應(yīng)用訪問就不再只能到一臺數(shù)據(jù)庫主機上面讀取數(shù)據(jù)了，而是訪問整個 MySQL 集群中的任何一臺主機上面的數(shù)據(jù)庫都可以得到相同的數(shù)據(jù)。整個復(fù)制過程實際上就是Slave從Master端獲取該日志然后再在自己身上完全順序的執(zhí)行日志中所記錄的各種操作REPLICATION 機制的實現(xiàn)原理MySQL的 Replication 是一個異步的復(fù)制過程，從一個MySQL instance（我們稱之為 Master）復(fù)制到另一個MySQL instance（我們稱之 Slave）。在 Master 與 Slave 之間的實現(xiàn)整個復(fù)制過程主要由三個線程來完成，其中兩個線程（SQL線程和IO線程）在 Slave

53、 端，另外一個線程（IO線程）在 Master 端。首先必須打開 Master 端的Binary Log（mysql-bin.xxxxxx）功能MYSQL 復(fù)制的基本過程1. Slave 上面的IO線程連接上 Master，并請求從指定日志文件的指定位置（或者從最開始的日志）之后的日志內(nèi)容；2. Master 接收到來自 Slave 的 IO 線程的請求后，通過負責(zé)復(fù)制的 IO 線程根據(jù)請求信息讀取指定日志指定位置之后的日志信息，返回給 Slave 端的 IO 線程。返回信息中除了日志所包含的信息之外，還包括本次返回的信息在 Master 端的 Binary Log 文件的名稱以及在 Bina

54、ry Log 中的位置；3. Slave 的 IO 線程接收到信息后，將接收到的日志內(nèi)容依次寫入到 Slave 端的Relay Log文件(mysql-relay-bin.xxxxxx)的最末端，并將讀取到的Master端的bin-log的文件名和位置記錄到master-info文件中，以便在下一次讀取的時候能夠清楚的高速Master“我需要從某個bin-log的哪個位置開始往后的日志內(nèi)容，請發(fā)給我”4. Slave 的 SQL 線程檢測到 Relay Log 中新增加了內(nèi)容后，會馬上解析該 Log文件中的內(nèi)容成為在 Master 端真實執(zhí)行時候的那些可執(zhí)行的 Query 語句，并在自身執(zhí)行這

55、些 Query。這樣，實際上就是在 Master 端和 Slave 端執(zhí)行了同樣的 Query，所以兩端的數(shù)據(jù)是完全一樣的。復(fù)制實現(xiàn)級別Row Level：Binary Log 中會記錄成每一行數(shù)據(jù)被修改的形式，然后在 Slave 端再對相同的數(shù)據(jù)進行修改。優(yōu)點：在 Row Level 模式下，Binary Log 中可以不記錄執(zhí)行的sql語句的上下文相關(guān)的信息，僅僅只需要記錄那一條記錄被修改了，修改成什么樣了。所以Row Level 的日志內(nèi)容會非常清楚的記錄下每一行數(shù)據(jù)修改的細節(jié)，非常容易理解。而且不會出現(xiàn)某些特定情況下的存儲過程，或function，以及trigger的調(diào)用和觸發(fā)無法被正

56、確復(fù)制的問題。缺點：Row Level下，所有的執(zhí)行的語句當(dāng)記錄到 Binary Log 中的時候，都將以每行記錄的修改來記錄，這樣可能會產(chǎn)生大量的日志內(nèi)容，比如有這樣一條update語句：UPDATE group_message SET group_id = 1 where group_id = 2，執(zhí)行之后，日志中記錄的不是這條update語句所對應(yīng)的事件（MySQL以事件的形式來記錄 Binary Log 日志），而是這條語句所更新的每一條記錄的變化情況，這樣就記錄成很多條記錄被更新的很多個事件。自然，Binary Log 日志的量就會很大。尤其是當(dāng)執(zhí)行ALTER TABLE 之類的語句

57、的時候，產(chǎn)生的日志量是驚人的。因為MySQL對于 ALTER TABLE 之類的 DDL 變更語句的處理方式是重建整個表的所有數(shù)據(jù)，也就是說表中的每一條記錄都需要變動，那么該表的每一條記錄都會被記錄到日志中。復(fù)制實現(xiàn)級別Statement Level:每一條會修改數(shù)據(jù)的 Query 都會記錄到 Master的 Binary Log 中。Slave在復(fù)制的時候 SQL 線程會解析成和原來 Master 端執(zhí)行過的相同的 Query 來再次執(zhí)行。優(yōu)點：Statement Level下的優(yōu)點首先就是解決了Row Level下的缺點，不需要記錄每一行數(shù)據(jù)的變化，減少 Binary Log 日志量，節(jié)約

58、了 IO 成本，提高了性能。因為他只需要記錄在Master上所執(zhí)行的語句的細節(jié)，以及執(zhí)行語句時候的上下文的信息。缺點：由于他是記錄的執(zhí)行語句，所以，為了讓這些語句在slave端也能正確執(zhí)行，那么他還必須記錄每條語句在執(zhí)行的時候的一些相關(guān)信息，也就是上下文信息，以保證所有語句在slave端杯執(zhí)行的時候能夠得到和在master端執(zhí)行時候相同的結(jié)果。另外就是，由于Mysql現(xiàn)在發(fā)展比較快，很多的新功能不斷的加入，使mysql得復(fù)制遇到了不小的挑戰(zhàn)，自然復(fù)制的時候涉及到越復(fù)雜的內(nèi)容，bug也就越容易出現(xiàn)。在statement level下，目前已經(jīng)發(fā)現(xiàn)的就有不少情況會造成mysql的復(fù)制出現(xiàn)問題，主要

59、是修改數(shù)據(jù)的時候使用了某些特定的函數(shù)或者功能的時候會出現(xiàn)，比如：sleep()函數(shù)在有些版本中就不能真確復(fù)制，在存儲過程中使用了last_insert_id()函數(shù)，可能會使slave和master上得到不一致的id等等。由于rowlevel是基于每一行來記錄的變化，所以不會出現(xiàn)類似的問題。常規(guī)復(fù)制架構(gòu)(MASTER - SLAVES)對于數(shù)據(jù)實時性要求不是特別 Critical 的應(yīng)用，只需要通過廉價的pc server來擴展 Slave 的數(shù)量，將讀壓力分散到多臺 Slave 的機器上面，即可通過分散單臺數(shù)據(jù)庫服務(wù)器的讀壓力來解決數(shù)據(jù)庫端的讀性能瓶頸DUAL MASTER 復(fù)制架構(gòu)(MAS

60、TER - MASTER).一些特定的場景下進行 Master的切換Slave 節(jié)點切換成 Master 來提供寫入的服務(wù)Master 節(jié)點的數(shù)據(jù)就會和實際的數(shù)據(jù)不一致反轉(zhuǎn)原 Master - Slave 關(guān)系，重新搭建 Replication 環(huán)境Dual Master 環(huán)境就是兩個MySQL Server 互相將對方作為自己的 Master，自己作為對方的Slave 來進行復(fù)制。這樣，任何一方所做的變更，都會通過復(fù)制應(yīng)用到另外一方的數(shù)據(jù)庫中。級聯(lián)復(fù)制架構(gòu)(MASTER -SLAVES - SLAVES .)有些應(yīng)用場景中，可能讀寫壓力差別比較大，讀壓力特別的大，一個 Mast