大型分布式系統關鍵指標衡量一個大型分布式系統是否健康需要用到一些指標。SLA在硅谷一線大廠所維護的系統服務中，我們經?？梢钥匆奡LA這樣的承諾。例如，在谷歌的云計算服務平臺GoogleCloudPlatform中，他們會寫著“99.9%Availability”這樣的承諾，這就是一個SLA承諾。SLA（Service-LevelAgreement），服務等級協議，指的是系統服務提供者對客戶的一個服務承諾。這是衡量一個大型分布式系統是否“健康”的常見方法。在開發設計系統服務的時候，無論面對的客戶是誰，都應該對自己所設計的系統服務有一個定義好的SLA。因為SLA是一種服務承諾，所以指標可以多種多樣，最常見的四個SLA指標包括可用性、準確性、系統容量和延遲?？捎眯裕ˋvailabilty）可用性指的是系統服務能正常運行所占的時間百分比。如果我們搭建了一個擁有“100％可用性”的系統服務，那就意味著這個系統在任何時候都能正常運行。但真要實現這樣的目標其實非常困難，成本也會很高。即便是大名鼎鼎的亞馬遜AWS云計算服務這樣大型的、對用戶來說極為關鍵的系統，也不能承諾100％的可用性，它的系統服務從推出到現在，也有過服務中斷（ServiceOutage）的時候。對于許多系統而言，四個9的可用性（99.99％Availability，或每年約50分鐘的系統中斷時間）即可以被認為是高可用性（Highavailability）。“99.99%Availability”指的是一天當中系統服務將會有大約8.6秒的服務間斷期。服務間斷也許是因為系統維護，也有可能是因為系統在更新升級系統服務。準確性（Accuracy）準確性指的是我們所設計的系統服務中，是否允許某些數據是不準確的或者是丟失的。不同的系統平臺可能會用不同的指標去定義準確性。很多時候，系統架構會以錯誤率（ErrorRate）來定義這一項SLA。可以用導致系統產生內部錯誤（InternalError）的有效請求數，除以這期間的有效請求總數來計算錯誤率。例如，我們在一分鐘內發送100個有效請求到系統中，其中有5個請求導致系統返回內部錯誤，那我們可以說這一分鐘系統的錯誤率是5/100=5%。GoogleCloudPlatform的SLA中，有著這樣的準確性定義：每個月系統的錯誤率超過5%的時間要少于0.1%，以每分鐘為單位來計算。而亞馬遜AWS云計算平臺有著稍微不一樣的準確性定義：以每5分鐘為單位，錯誤率不會超過0.1%。你一般來說，我們可以采用性能測試（PerformanceTest）或者是查看系統日志（Log）兩種方法來評估系統的準確性。系統容量（Capacity）在數據處理中，系統容量通常指的是系統能夠支持的預期負載量是多少，一般會以每秒的請求數為單位來表示。我們常常可以看見，某個系統的架構可以處理的QPS（QueriesPerSecond）是多少又或者RPS（RequestsPerSecond）是多少。這里的QPS或者是RPS就是指系統每秒可以響應多少請求數。之前Twitter發布的一項數據顯示，Twitter系統可以響應30萬的QPS來讀取TwitterTimelines。這里Twitter系統給出的就是他們對于系統容量（Capacity）的SLA。那要怎么給自己設計的系統架構定義出準確的QPS呢？可以有下面這幾種方式。第一種，是使用限流（Throttling）的方式。如果你是使用Java語言進行編程的，就可以使用GoogleGuava庫中的RateLimiter類來定義每秒最多發送多少請求到后臺處理。假設在每臺服務器都定義了一個每秒最多處理1000個請求的RateLimiter，而一共有N臺服務器，在最理想的情況下，QPS可以達到1000*N。這里要注意的雷區是，這個請求數并不是設置得越多越好。因為每臺服務器的內存有限，過多的請求堆積在服務器中有可能會導致內存溢出（Out-Of-Memory）的異常發生，也就是所有請求所需要占用的內存超過了服務器能提供的內存，從而讓整個服務器崩潰。第二種，是在系統交付前進行性能測試（PerformanceTest）?？梢允褂孟馎pacheJMeter又或是LoadRunner這類型的工具對系統進行性能測試。這類工具可以測試出系統在峰值狀態下可以應對的QPS是多少。這里也是有雷區的。有的開發者可能使用同一類型的請求參數，導致后臺服務器在多數情況下命中緩存（CacheHit）。這個時候得到的QPS可能并不是真實的QPS。打個比方，服務器處理請求的正常流程需要查詢后臺數據庫，得到數據庫結果后再返回給用戶，這個過程平均需要1秒。在第一次拿到數據庫結果后，這個數據就會被保存在緩存中，而如果后續的請求都使用同一類型的參數，導致結果不需要從數據庫得到，而是直接從緩存中得到，這個過程假設只需要0.1秒。那這樣，計算出來的QPS就會比正常的高出10倍。所以在生成請求的時候，要格外注意這一點。第三種，是分析系統在實際使用時產生的日志（Log）。系統上線使用后可以得到日志文件。一般的日志文件會記錄每個時刻產生的請求?？梢酝ㄟ^系統每天在最繁忙時刻所接收到的請求數，來計算出系統可以承載的QPS。不過，這種方法不一定可以得到系統可以承載的最大QPS。想要得到系統能承受的最大QPS，更多的是性能測試和日志分析相結合的手段。延遲（Latency）延遲指的是系統在收到用戶的請求到響應這個請求之間的時間間隔。在定義延遲的SLA時，常常看到系統的SLA會有p95或者是p99這樣的延遲聲明。這里的p指的是percentile，也就是百分位的意思。如果說一個系統的p95延遲是1秒的話，那就表示在100個請求里面有95個請求的響應時間會少于1秒，而剩下的5個請求響應時間會大于1秒。假設一個社交軟件，在接收到用戶的請求之后，需要讀取數據庫中的內容返回給用戶。為了降低系統的延遲，它會將數據庫中內容放進緩存（Cache）中，以此來減少數據庫的讀取時間。在系統運行了一段時間后，得到了一些緩存命中率（CacheHitRatio）的信息。有90%的請求命中了緩存，而剩下的10%的請求則需要重新從數據庫中讀取內容。這時服務器的p95或者p99延遲恰恰就衡量了系統的最長時間，也就是從數據庫中讀取內容的時間。我們可以通過改進緩存策略從而提高緩存命中率，也可以通過優化數據庫的Schema或者索引（Index）來降低p95或p99延遲?？偠灾?，當p95或者p99過高時，總會有5%或者1%的用戶抱怨產品的用戶體驗太差，這都是要通過優化系統來避免的。定義好一個系統架構的SLA對于一個優秀的架構師來說是必不可少的一項技能，也是一種基本素養。特別是當系統架構在不停迭代的時候，有了一個明確的SLA，我們可以知道下一代系統架構的改進目標以及優化好的系統架構是否比上一代的系統SLA更加優秀。分布式系統三大指標可擴展性分布式系統的核心就是可擴展性（Scalability）。最基本而且最流行的增加系統容量的模型有兩種:水平擴展（HorizontalScaling）和垂直擴展（VerticalScaling）。所謂水平擴展，就是指在現有的系統中增加新的機器節點。垂直擴展就是在不改變系統中機器數量的情況下，“升級”現有機器的性能，比如增加機器的內存。水平擴展的適用范圍更廣，操作起來更簡單，并且會提升系統的可用性（Availability）。如果你的系統部署在AWS或者其他主流的云服務上，你只需要點幾個按鈕，就可以在現有的機器集群中增加一個新的節點。但是，無節制地增加機器數量也會帶來一些問題，比如機器的管理、調度、通信會變得更加復雜，出錯的可能性會更高，更難保證數據的一致性等等。與之相反，垂直擴展并沒有讓整個系統變得更加復雜，控制系統的代碼也不需要做任何調整，但是它受到的限制比較多。多數情況下，單個機器的性能提升是有限的。而且受制于摩爾定律，提高機器的性能往往比購買新的機器更加昂貴。所以在工作中，我們要對這兩種模式進行取舍，要具體情況具體分析。同樣地，在大數據的時代，數據增長速度越來越快，數據規模越來越大，對數據存儲系統的擴展性要求也越來越高。傳統的關系型數據庫因為表與表之間的數據有關聯，經常要進行Join操作，所有數據要存放在單機系統中，很難支持水平擴展。而NoSQL型的數據庫天生支持水平擴展，所以這類存儲系統的應用越來越廣，如BigTable、MongoDB和Redis等。一致性可用性對于任何分布式系統都很重要。一般來說，構成分布式系統的機器節點的可用性要低于系統的可用性。舉個例子，如果我們想要構建一個可用性99.999%的分布式系統（每年約5分鐘的宕機時間），但是我們使用的單臺機器節點的可用性是99.9%（每年約8個小時的宕機時間）。那么想要達到我們的目標，最簡單的辦法就是增加系統中機器節點的數量。這樣即使有部分機器宕機了，其他的機器還在持續工作，所以整個系統的可用性就提高了。這種情況下，我們要思考一個問題：如何保證系統中不同的機器節點在同一時間，接收到和輸出的數據是一致的呢？這時就要引入一致性（Consistency）的概念?；氐街暗睦?，要保證分布式系統內的機器節點有相同的信息，就需要機器之間定期同步。然而，發送信息也會有失敗的可能，比如信息丟失或者有的節點正好宕機而無法接收。因此，一致性在高可用性的系統里是非常核心的概念。在工程中常用的一致性模型包括：強一致性（StrongConsistency），弱一致性（WeakConsistency），最終一致性（EventualConsistency）。強一致性系統中的某個數據被成功更新后，后續任何對該數據的讀取操作都將得到更新后的值。所以在任意時刻，同一系統所有節點中的數據是一樣的。在強一致性系統中，只要某個數據的值有更新，這個數據的副本都要進行同步，以保證這個更新被傳播到所有備份數據庫中。在這個同步進程結束之后，才允許服務器來讀取這個數據。所以，強一致性一般會犧牲一部分延遲性，而且對于全局時鐘的要求很高。弱一致性系統中的某個數據被更新后，后續對該數據的讀取操作可能得到更新后的值，也可能是更改前的值。但經過“不一致時間窗口”這段時間后，后續對該數據的讀取都是更新后的值。最終一致性是弱一致性的特殊形式。存儲系統保證，在沒有新的更新的條件下，最終所有的訪問都是最后更新的值。在最終一致性系統中，無需等到數據更新被所有節點同步就可以讀取。盡管不同的進程讀同一數據可能會讀到不同的結果，但是最終所有的更新會被按時間順序同步到所有節點。所以，最終一致性系統支持異步讀取，它的延遲比較小。比如亞馬遜云服務的DynamoDB就支持最終一致的數據讀取。除了以上三個，分布式系統理論中還有很多別的一致性模型，如順序一致性（SequentialConsistency），因果一致性（CasualConsistency）等。在實際應用系統中，強一致性是很難實現的，應用最廣的是最終一致性。持久性數據持久性（DataDurability）意味著數據一旦被成功存儲就可以一直繼續使用，即使系統中的節點下線、宕機或數據損壞也是如此。不同的分布式數據庫擁有不同級別的持久性。有些系統支持機器/節點級別的持久性，有些做到了集群級別，而有些系統壓根沒有持久性。想要提高持久性，數據復制是較為通用的做法。因為把同一份數據存儲在不同的節點上，即使有節點無法連接，數據仍然可以被訪問。在分布式數據處理系統中，還有一個持久性概念是消息持久性。在分布式系統中，節點之間需要經常相互發送消息去同步以保證一致性。對于重要的系統而言，常常不允許任何消息的丟失。分布式系統中的消息通訊通常由分布式消息服務完成，比如RabbitMQ、Kafka。這些消息服務能支持（或配置后支持）不同級別的消息送達可靠性。消息持久性包含兩個方面：當消息服務的節點發生了錯誤，已經發送的消息仍然會在錯誤解決之后被處理；如果一個消息隊列聲明了持久性，那么即使隊列在消息發送之后掉線，仍然會在重新上線之后收到這條消息。設計分布式系統所要考慮的量化指標存在一定程度上的沖突。不可能有一個分布式處理系統在不犧牲某一指標的前提下，讓每一個指標都達到最好。作為優秀的系統架構師，一定要學會具體情況具體分析，找到最適合自己系統的指標，適當做出取舍。CAP定理CAP這個概念最初是由埃里克·布魯爾博士（Dr.EricBrewer）在2000年的ACM年度學術研討會上名為“TowardsRobustDistributedSystems”的演講提出的。在兩年之后，塞思·吉爾伯特（SethGilbert）和麻省理工學院的南?！ち制娼淌冢∟ancyAnnLynch）在他們的論文“Brewer’sconjectureandtheFeasibilityofConsistent,Available,Partition-TolerantWebServices”中證明了這一概念。他們在這篇論文中證明了：在任意的分布式系統中，一致性（Consistency），可用性（Availability）和分區容錯性（Partition-tolerance）這三種屬性最多只能同時存在兩個屬性。C：一致性一致性在這里指的是線性一致性（LinearizabilityConsistency）。在線性一致性的保證下，所有分布式環境下的操作都像是在單機上完成的一樣，也就是說圖中SeverA、B、C的狀態一直是一致的。假設我們設計了一個分布式的購物系統，在這個系統中，商品的存貨狀態分別保存在服務器A和服務器B中。我們把存貨狀態定義為“有貨狀態”或者“無貨狀態”。在最開始的時候，服務器A和服務器B都會顯示商品為有貨狀態。等一段時間過后，商品賣完了，后臺就必須將這兩臺服務器上的商品狀態更新為無貨狀態。因為是在分布式的環境下，商品狀態的更新在服務器A上完成了，顯示為無貨狀態。而服務器B的狀態因為網絡延遲的原因更新還未完成，還是顯示著有貨狀態。這時，恰好有兩個用戶使用著這個購物系統，先后發送了一個查詢操作（QueryOperation）到后臺服務器中查詢商品狀態。我們假設是用戶A先查詢的，這個查詢操作A被發送到了服務器A上面，并且成功返回了商品是無貨狀態的。用戶B在隨后也對同一商品進行查詢，而這個查詢操作B被發送到了服務器B上面，并且成功返回了商品是有貨狀態的。我們知道，對于整個系統來說，商品的系統狀態應該為無貨狀態。而操作A又是在操作B之前發送并且成功完成的，所以如果這個系統有線性一致性這個屬性的話，操作B所看到的系統狀態理論上應該是無貨狀態。但在我們這個例子中，操作B卻返回了有貨狀態。所以我們說，這個分布式的購物系統并不滿足論文里所講到的線性一致性。A：可用性可用性的概念比較簡單，在這里指的是在分布式系統中，任意非故障的服務器都必須對客戶的請求產生響應。當系統滿足可用性的時候，不管出現什么狀況（除非所有的服務器全部崩潰），都能返回消息。也就是說，當客戶端向系統發送請求，只要系統背后的服務器有一臺還未崩潰，那么這個未崩潰的服務器必須最終響應客戶端。P：分區容錯性分區容錯性分為兩個部分，“分區”和“容錯”。在一個分布式系統里，如果出現一些故障，可能會使得部分節點之間無法連通。由于這些故障節點無法聯通，造成整個網絡就會被分成幾塊區域，從而使數據分散在這些無法連通的區域中的情況，可以認為這就是發生了分區錯誤。如圖所示，如果你要的數據只在SeverA中保存，當系統出現分區錯誤，在不能直接連接SeverA時，你是無法獲取數據的?！胺謪^容錯”，意思是即使出現這樣的“錯誤”，系統也需要能“容忍”。也就是說，就算錯誤出現，系統也必須能夠返回消息。分區容錯性，在這里指的是我們的系統允許網絡丟失從一個節點發送到另一個節點的任意多條消息。在現代網絡通信中，節點出現故障或者網絡出現丟包這樣的情況是時常會發生的。如果沒有了分區容錯性，我們日常所用到的很多系統就不能再繼續工作了。所以在大部分情況下，系統設計都會保留P屬性，而在C和