數(shù)據(jù)庫分布式系統(tǒng)設計策略是什么

這篇文章主要講解了“數(shù)據(jù)庫分布式系統(tǒng)設計策略是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“數(shù)據(jù)庫分布式系統(tǒng)設計策略是什么”吧！

一：分布式系統(tǒng)設計策略

分布式系統(tǒng)本質是通過低廉的硬件攢在一起以獲得更好的吞吐量、性能以及可用性等。

在分布式環(huán)境下，有幾個問題是普遍關心的，我們稱之為設計策略 ：

• 如何檢測當前節(jié)點還活著？

• 如何保障高可用？

• 容錯處理

• 負載均衡

1.1：心跳檢測

為什么進行心跳檢測？

在分布式環(huán)境中，存在非常多的節(jié)點（Node），由這些節(jié)點分擔任務的運行、計算或程序邏 輯處理。那么就有一個非常重要的問題，如何判斷一個節(jié)點是否出現(xiàn)了故障甚至無法工作了？

如何進行心跳檢測？

心跳檢測：以固定的頻率向其他節(jié)點匯報當前節(jié)點狀態(tài)，的一種檢測節(jié)點是否正常工作的方式。

若Server沒有收到Node3的心跳時，Server認為Node3失聯(lián)。但是失去聯(lián)系時，并不確定是否是Node3故 障，有可能是Node3處于繁忙狀態(tài)，導致調用檢測超時；也有可能是Server與Node3之間鏈路出現(xiàn)故障或閃斷。

所以心跳不是萬能的，收到心跳可以確認節(jié)點正常，但是收不到心跳也不能認為該節(jié)點就已經宣告“死亡”。 為了解決這種情況引入了：周期檢測心跳機制、累計失效檢測機制。

1. 周期檢測心跳機制：Server端每間隔 t 秒向Node集群發(fā)起監(jiān)測請求，設定超時時間，如果超過超時時間，則判斷“死亡”。

2. 累計失效檢測機制：在周期檢測心跳機制的基礎上，統(tǒng)計一定周期內節(jié)點的返回情況（包括超時及正確返回），以此計算節(jié)點的“死亡”概率。另外，對于宣告“瀕臨死亡”的節(jié)點可以發(fā)起有限次數(shù)的重試，以作進一步判斷。通過周期檢測心跳機制、累計失效檢測機制可以幫助判斷節(jié)點是否“死亡”，如果判斷“死亡”，可以把該節(jié)點踢出集群。

1.2：高可用設計

高可用設計：一個系統(tǒng)在長時間內能否對外提供可用的服務。

系統(tǒng)高可用性的常用設計模式包括三種：主備（Master-SLave）、互備（Active-Active）和集群（Cluster）模 式。

主備模式（使用較多）

主備模式就是Active-Standby模式，當主機宕機時，備機接管主機的一切工作，待主機恢復正常后，按使用者的設定以自動（熱備）或手動（冷備）方式將服務切換到主機上運行。

以數(shù)據(jù)庫為例：在數(shù)據(jù)庫部分稱之為MS模式。MS模式即Master/Slave模式，這在數(shù)據(jù)庫高可用性方案中比較常用，如MySQL、Redis等就采用MS模式實現(xiàn)主從復制。保證高可用，如圖所示。

一臺MySQL數(shù)據(jù)庫一旦啟用二進制日志后，作為master，它的數(shù)據(jù)庫中所有操作都會以“事件”的方式記錄在二進制日志中，其他數(shù)據(jù)庫作為slave通過一個I/O線程與主服務器保持通信，并監(jiān)控master的二進制日志文件的變化，如果發(fā)現(xiàn)master二進制日志文件發(fā)生變化，則會把變化復制到自己的中繼日志中，然后slave的一個SQL線程會把相關的“事件”執(zhí)行到自己的數(shù)據(jù)庫中，以此實現(xiàn)從數(shù)據(jù)庫和主數(shù)據(jù)庫的一致性，也就實現(xiàn)了主從復制。

互備模式（使用較少）

互備模式指兩臺主機同時運行各自的服務工作且相互監(jiān)測情況

在數(shù)據(jù)庫高可用部分，常見的互備是MM模式。MM模式即Multi-Master模式，指一個系統(tǒng)存在多個master，每個master都具有read-write能力，會根據(jù)時間戳或業(yè)務邏輯合并版本。

集群模式

集群模式是指有多個節(jié)點在運行，同時可以通過主控節(jié)點分擔服務請求。如Zookeeper。集群模式需要解決主控節(jié)點本身的高可用問題，一般采用主備模式。

1.3：容錯性

容錯性表示一個系統(tǒng)是否具有安全性、穩(wěn)定性、健壯性；對錯誤的包容能力。

以緩存穿透為例：

在項目中使用緩存通常都是先檢查緩存中是否存在，如果存在直接返回緩存內容，如果不存在就直接查詢數(shù)據(jù) 庫然后再緩存查詢結果返回。這個時候如果我們查詢的某一個數(shù)據(jù)在緩存中一直不存在，就會造成每一次請求都查詢DB，這樣緩存就失去了意義，在流量大時，或者有人惡意攻擊就會有麻煩了。

一個比較巧妙的解決方法是，可以將這個不存在的key預先設定一個值。比如，key=“null”，寫入緩存。即查詢這個key的時候直接返回null就行，但注意需要設置失效時間，否則數(shù)據(jù)存在時也返回null就不對了。

1.4：負載均衡

負載均衡：其關鍵在于使用多臺集群服務器共同分擔計算任務，把網(wǎng)絡請求及計算分配到集群可用的不同服務器節(jié) 點上，從而達到高可用性及較好的用戶操作體驗。

負載均衡分為：硬負載（硬件解決如：F5）、軟負載（軟件解決：LVS、HAProxy、Nginx）。

以Nginx為例，常見的負載均衡策略有：

• 輪詢：根據(jù)Nginx配置文件中的順序，依次把客戶端的Web請求分發(fā)到不同的后端服務器。

• 最少連接：當前誰連接最少，分發(fā)給誰。

• ip地址hash：確定相同IP請求可以轉發(fā)給同一個后端節(jié)點處理，以方便session保持。

• 基于權重的負載均衡：配置Nginx把請求更多地分發(fā)到高配置的后端服務器上，把相對較少的請求分發(fā)到低配服務器。

感謝各位的閱讀，以上就是“數(shù)據(jù)庫分布式系統(tǒng)設計策略是什么”的內容了，經過本文的學習后，相信大家對數(shù)據(jù)庫分布式系統(tǒng)設計策略是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！