分佈式系統目標
提升系統的整體性能和吞吐量以及儘量保證分佈式系統的容錯性。
分佈式系統設計思路
- 中心化:分佈式集羣中的節點機器按照角色分工,“領導”“和員工”。領導負責分發並監督員工,發現員工空閒及時分派新任務,發現員工壞掉直接踢出局,然後把任務分派給其他員工。
存在問題:
- 領導出現問題,整個集羣就崩潰了。
- 能力問題,能領導10個人高效工作不一定能領導100個人高效工作。
- 去中心化:所有節點地位平等,由節點自有選擇中心(ZooKeeper的選舉)。
存在問題:
一個集羣由於網絡的故障,被分爲至少兩個彼此無法通信的單獨集羣,此時如果兩個集羣都各自工作,可能會產生嚴重的數據衝突和錯誤。所謂的“腦裂”問題。
一般的解決思路是,當集羣判斷髮生了腦裂問題時,規模較小的集羣就“自殺”或者拒絕服務。
cap定理:
又被稱爲布魯爾定理(Brewer's thworem),指出對於一個分佈式系統不能同時滿足一致性(C),可用性(A),分區容錯性(P)。
- Consistence 一致性:所有節點訪問同一份最新的數據副本。
- Availability 可用性:每次請求都能獲取非錯的相應。但不保證爲最新的數據。
- Patition tolerance 分區容錯性:分佈式系統遇到某節點或網絡故障仍能對外提供滿足一致性和可用性的服務。
base理論:
核心思想:無法做到強一致性,每個業務根據自身的特點,採用適當的方式最終達到一致性。在數據庫領域,主要實現爲對業務數據拆分,不同的數據分佈在不同的機器上,以此來提升系統的可用性。比如:按功能劃分數據庫(不同功能不同的數據庫實例);分片(MyCat)。
三要素:
- basically Available 基本可用:
分佈式系統出現不可預知的故障時,允許損失部分可用性。 比如:系統時間增加;搶購時部分被引導到降級頁面。
- soft-state 軟狀態:允許系統在不同節點同步數據副本時存在延時。
- Eventually Consistent 最終一致性:所有的數據副本經過一定時間的同步後最終達到一致。
分佈式和集羣的區別:
- 分佈式:一個業務拆分位多個子業務,部署在不同的服務器上。
- 集羣:同一個業務部署在多個服務器上。提高系統性能,解決高併發。
本文完。
勤助手-教育機構好助手。一款專注中小機構教學管理的軟件。
註冊可免費使用。