數據庫分布式系統設計策略是什么

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

一：分布式系統設計策略

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

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

• 如何檢測當前節點還活著？

• 如何保障高可用？

• 容錯處理

• 負載均衡

1.1：心跳檢測

為什么進行心跳檢測？

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

如何進行心跳檢測？

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

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

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

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

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

1.2：高可用設計

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

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

主備模式（使用較多）

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

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

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

互備模式（使用較少）

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

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

集群模式

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

1.3：容錯性

容錯性表示一個系統是否具有安全性、穩定性、健壯性；對錯誤的包容能力。

以緩存穿透為例：

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

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

1.4：負載均衡

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

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

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

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

• 最少連接：當前誰連接最少，分發給誰。

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

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

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