【IT168 評論】分布式系統設計理念
分布式系統架構的第一原則是不要分布!這句話看似矛盾實則揭露了分布式系統的很多特徵。
分布式系統的目標與要素
分布式系統的目標是提升系統的整體性能和吞吐量另外還要儘量保證分布式系統的容錯性(假如增加10臺伺服器才達到單機運行效果2倍左右的性能,那麼這個分布式系統就根本沒有存在的意義)。
即使採用了分布式系統,我們也要盡力運用並發編程、高性能網絡框架等等手段提升單機上的程序性能。
分布式系統設計兩大思路:中心化和去中心化
1)中心化設計:
兩個角色: 中心化的設計思想很簡單,分布式集群中的節點機器按照角色分工,大體上氛圍兩種角色: 「領導」 和 「幹活的」
角色職責: 「領導」通常負責分發任務並監督「幹活的」,發現誰太閒了,就想發設法地給其安排新任務,確保沒有一個「幹活的」能夠偷懶,如果「領導」發現某個「幹活的」因為勞累過度而病倒了,則是不會考慮先嘗試「醫治」他的,而是一腳踢出去,然後把他的任務分給其他人。其中微服務架構 Kubernetes 就恰好採用了這一設計思路。
中心化設計的問題:
中心化的設計存在的最大問題是「領導」的安危問題,如果「領導」出了問題,則群龍無首,整個集群就奔潰了。但我們難以同時安排兩個「領導」以避免單點問題。
中心化設計還存在另外一個潛在的問題,既「領導」的能力問題:可以領導10個人高效工作並不意味著可以領導100個人高效工作,所以如果系統設計和實現得不好,問題就會卡在「領導」身上。
領導安危問題的解決辦法: 大多數中心化系統都採用了主備兩個「領導」的設計方案,可以是熱備或者冷備,也可以是自動切換或者手動切換,而且越來越多的新系統都開始具備自動選舉切換「領導」的能力,以提升系統的可用性。
2)去中心化設計
終生地位平等: 在去中心化的設計裡,通常沒有「領導」和「幹活的」這兩種角色的區分,大家的角色都是一樣的,地位是平等的,全球網際網路就是一個典型的去中心化的分布式系統,聯網的任意節點設備宕機,都只會影響很小範圍的功能。
「去中心化」不是不要中心,而是由節點來自由選擇中心。 (集群的成員會自發的舉行「會議」選舉新的「領導」主持工作。最典型的案例就是ZooKeeper及Go語言實現的Etcd)
去中心化設計的問題: 去中心化設計裡最難解決的一個問題是 「腦裂」問題 ,這種情況的發聲概率很低,但影響很大。腦裂問題,這種情況的發生概率很低,但影響很大。腦裂指一個集群猶豫網絡的故障,被分為至少兩個彼此無法通信的單獨集群,此時如果兩個集群都各自工作,則可能會產生眼中的數據衝突何錯誤。一般的設計思路是,當集群半段發聲了腦裂問題是,規模較小的集群就「自殺」或者拒絕服務。
分布式與集群的區別是什麼?
分布式: 一個業務分拆多個子業務,部署在不同的伺服器上
集群: 同一個業務,部署在多個伺服器上。比如之前做電商網站搭的redis集群以及solr集群都是屬於將redis伺服器提供的緩存服務以及solr伺服器提供的搜索服務部署在多個伺服器上以提高系統性能、並發量解決海量存儲問題。
CAP定理
在理論計算機科學中,CAP定理(CAP theorem),又被稱作布魯爾定理(Brewer's theorem),它指出對於一個分布式計算系統來說,不可能同時滿足以下三點:
一致性(Consistence) :所有節點訪問同一份最新的數據副本
可用性(Availability):每次請求都能獲取到非錯的響應——但是不保證獲取的數據為最新數據
分區容錯性(Partition tolerance) : 分布式系統在遇到某節點或網絡分區故障的時候,仍然能夠對外提供滿足一致性和可用性的服務。
CAP僅適用於原子讀寫的NOSQL場景中,並不適合資料庫系統。
注意:不是所謂的3選2(不要被網上大多數文章誤導了):
現實生活中,大部分人解釋這一定律時,常常簡單的表述為:「一致性、可用性、分區容忍性三者你只能同時達到其中兩個,不可能同時達到」。實際上這是一個非常具有誤導性質的說法,而且在CAP理論誕生12年之後,CAP之父也在2012年重寫了之前的論文。
當發生網絡分區的時候,如果我們要繼續服務,那麼強一致性和可用性只能2選1。也就是說當網絡分區之後P是前提,決定了P之後才有C和A的選擇。也就是說分區容錯性(Partition tolerance)我們是必須要實現的。
我在網上找了很多文章想看一下有沒有文章提到這個不是所謂的3選2,用百度半天沒找到了一篇,用谷歌搜索找到一篇比較不錯的,如果想深入學習一下CAP就看這篇文章把,我這裡就不多BB了:《分布式系統之CAP理論》 : http://www.cnblogs.com/hxsyl/p/4381980.html
BASE理論
BASE理論由eBay架構師Dan Pritchett提出,在2008年上被分表為論文,並且eBay給出了他們在實踐中總結的基於BASE理論的一套新的分布式事務解決方案。
BASE 是 Basically Available(基本可用) 、Soft-state(軟狀態) 和 Eventually Consistent(最終一致性) 三個短語的縮寫。BASE理論是對CAP中一致性和可用性權衡的結果,其來源於對大規模網際網路系統分布式實踐的總結,是基於CAP定理逐步演化而來的,它大大降低了我們對系統的要求。
BASE理論的核心思想
即使無法做到強一致性,但每個應用都可以根據自身業務特點,採用適當的方式來使系統達到最終一致性。也就是犧牲數據的一致性來滿足系統的高可用性,系統中一部分數據不可用或者不一致時,仍需要保持系統整體「主要可用」。
針對資料庫領域,BASE思想的主要實現是對業務數據進行拆分,讓不同的數據分布在不同的機器上,以提升系統的可用性,當前主要有以下兩種做法:
按功能劃分資料庫
分片(如開源的Mycat、Amoeba等)。
由於拆分後會涉及分布式事務問題,所以eBay在該BASE論文中提到了如何用最終一致性的思路來實現高性能的分布式事務。
BASE理論三要素
1. 基本可用
基本可用是指分布式系統在出現不可預知故障的時候,允許損失部分可用性。但是,這絕不等價於系統不可用。
比如:
響應時間上的損失:正常情況下,一個在線搜尋引擎需要在0.5秒之內返回給用戶相應的查詢結果,但由於出現故障,查詢結果的響應時間增加了1~2秒
系統功能上的損失:正常情況下,在一個電子商務網站上進行購物的時候,消費者幾乎能夠順利完成每一筆訂單,但是在一些節日大促購物高峰的時候,由於消費者的購物行為激增,為了保護購物系統的穩定性,部分消費者可能會被引導到一個降級頁面
2. 軟狀態
軟狀態指允許系統中的數據存在中間狀態,並認為該中間狀態的存在不會影響系統的整體可用性,即允許系統在不同節點的數據副本之間進行數據同步的過程存在延時
3. 最終一致性
最終一致性強調的是系統中所有的數據副本,在經過一段時間的同步後,最終能夠達到一個一致的狀態。因此,最終一致性的本質是需要系統保證最終數據能夠達到一致,而不需要實時保證系統數據的強一致性。
總結
本文主要是簡單的介紹了三個常見的概念: 分布式系統設計理念 、 CAP定理 、 BASE理論 ,關於分布式系統的還有很多很多東西。