掌握這幾個祕籍，你的分佈式系統絕對牛掰！！！

根據CAP理論，分佈式環境系統需要儘量保證C 一致性 A 可用性 P 容錯性。分佈式系統，從本質上來講，就是通過一些低廉的硬件來實現系統更好的吞吐、性能以及可用性。分佈式系統，有一套通用的系統設計策略。大致上分為：

在分佈式系統環境中，對於能夠檢測眾多節點的活性是很有必要的。只有當節點存活，才可以進行執行對應的業務任務。傳統來說，解決該類問題，一般都是通過心跳檢測手段。如同醫生通過儀器探測病人心跳一樣，去判定服務器眾節點的存活。

客戶端，在請求對應的服務節點前，需要經過心跳檢測服務器，進行路由轉發到對應的節點處理。

心跳檢測服務器，檢測眾多分發或者路由節點的活性，如果存活正常，路由才會轉發到該節點。

傳統心跳檢測，存在一定的侷限性

總結來說，心跳檢測收到心跳正常，是正常的，但是心跳檢測收不到心跳，也不代表節點存在異常，判定死亡

優化心跳檢測策略

系統高可用性的常用設計模式包括三種：主備、互備、集群模式

主備模式,就是Active Standby，當主機宕機時，備機接管主機一切工作，待主機正常之後，會通過兩種方式自動（熱備）、手動（冷備），恢復主機的工作

數據庫高可用方案中，一般都是MS主從模式 Matser-Slave

互備模式，指的是多臺主機同時運行各自的服務工作且互相檢測，同步。在數據庫高可用部分，採用互備，主要是MM模式（Multi-Master）。多個master都具有read - write 能力，需根據時間戳或者版本，最終合併。分佈式版本管理系統git就可以理解為MM模式

集群模式，指的是，多個節點同時運行服務，可以通過類似心跳服務器這種分擔服務請求。

容錯性，指系統對於錯誤、異常的包容能力，為了更好地提供用戶的舒適度或者說客戶端的響應合理，做出來的一些系統的讓步處理。

容錯，並非容忍錯誤。以分佈式環境下的，緩存舉例說明：

一個查詢業務，先通過緩存查詢，如果緩存沒有，再去數據庫查詢。如果沒有查詢得到，可能的原因包括以下幾個方面：

那麼，用戶可以進行間隔一定時間發起重試，可以一定程度友好的，解決問題

另外，如果出現緩存失效的情況下，惡意攻擊，調用查詢接口，查詢緩存中不存在的key，導致大量流量進入DB，導致DB崩潰。

為了解決這個問題，我們可以考慮，如果在高頻、短週期內，當客戶查詢不存在的key時，我們可以對當前key進行賦值，直接返回。響應給系統用戶，截斷惡意操作。

分佈式系統環境，通過負載均衡，達到資源的合理分配利用

負載均衡，分為硬件和軟件。硬件常見的設備F5，軟件的LVS 、Nginx等等

以nginx為例，常見的負載均衡策略如下