大型分布式系統(tǒng)關(guān)鍵指標(biāo)

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