摘要：降級(jí)往往會(huì)指定不同的級(jí)別，面臨不同的異常等級(jí)執(zhí)行不同的處理。談?wù)勀銓?duì)和的認(rèn)識(shí)兩者關(guān)系具體可以看公眾號(hào)阿里巴巴中間件的這篇文章獨(dú)家解讀從微服務(wù)框架到微服務(wù)生態(tài)與并不是競爭關(guān)系，作為成熟的框架，其易用性擴(kuò)展性和健壯性已得到業(yè)界的認(rèn)可。

該文已加入筆主的開源項(xiàng)目——JavaGuide（一份涵蓋大部分Java程序員所需要掌握的核心知識(shí)的文檔類項(xiàng)目),地址:https://github.com/Snailclimb/JavaGuide 。覺得不錯(cuò)的話，記得點(diǎn)個(gè)Star。

下面這些問題都是一線大廠的真實(shí)面試問題，不論是對(duì)你面試還是說拓寬知識(shí)面都很有幫助。之前發(fā)過一篇8 張圖讀懂大型網(wǎng)站技術(shù)架構(gòu) 可以作為不太了解大型網(wǎng)站系統(tǒng)技術(shù)架構(gòu)朋友的入門文章。

1. 你使用過哪些組件或者方法來提升網(wǎng)站性能,可用性以及并發(fā)量

2. 設(shè)計(jì)高可用系統(tǒng)的常用手段

3. 現(xiàn)代互聯(lián)網(wǎng)應(yīng)用系統(tǒng)通常具有哪些特點(diǎn)?

4. 談?wù)勀銓?duì)微服務(wù)領(lǐng)域的了解和認(rèn)識(shí)

5. 談?wù)勀銓?duì) Dubbo 和 Spring Cloud 的認(rèn)識(shí)(兩者關(guān)系)

6. 性能測試了解嗎?說說你知道的性能測試工具?

7. 對(duì)于一個(gè)單體應(yīng)用系統(tǒng),隨著產(chǎn)品使用的用戶越來越多,網(wǎng)站的流量會(huì)增加,最終單臺(tái)服務(wù)器無法處理那么大的流量怎么辦?

8. 大表優(yōu)化的常見手段

9. 在系統(tǒng)中使用消息隊(duì)列能帶來什么好處?

1) 通過異步處理提高系統(tǒng)性能

2) 降低系統(tǒng)耦合性

10. 說說自己對(duì) CAP 定理,BASE 理論的了解

CAP 定理

BASE 理論

參考

提高硬件能力、增加系統(tǒng)服務(wù)器。（當(dāng)服務(wù)器增加到某個(gè)程度的時(shí)候系統(tǒng)所能提供的并發(fā)訪問量幾乎不變，所以不能根本解決問題）

使用緩存（本地緩存：本地可以使用JDK自帶的 Map、Guava Cache.分布式緩存：Redis、Memcache.本地緩存不適用于提高系統(tǒng)并發(fā)量，一般是用處用在程序中。比如Spring是如何實(shí)現(xiàn)單例的呢？大家如果看過源碼的話，應(yīng)該知道，Spiring把已經(jīng)初始過的變量放在一個(gè)Map中，下次再要使用這個(gè)變量的時(shí)候，先判斷Map中有沒有，這也就是系統(tǒng)中常見的單例模式的實(shí)現(xiàn)。）

消息隊(duì)列 （解耦+削峰+異步）

采用分布式開發(fā) （不同的服務(wù)部署在不同的機(jī)器節(jié)點(diǎn)上，并且一個(gè)服務(wù)也可以部署在多臺(tái)機(jī)器上，然后利用 Nginx 負(fù)載均衡訪問。這樣就解決了單點(diǎn)部署(All In)的缺點(diǎn)，大大提高的系統(tǒng)并發(fā)量）

數(shù)據(jù)庫分庫（讀寫分離）、分表（水平分表、垂直分表）

采用集群 （多臺(tái)機(jī)器提供相同的服務(wù)）

CDN 加速 (將一些靜態(tài)資源比如圖片、視頻等等緩存到離用戶最近的網(wǎng)絡(luò)節(jié)點(diǎn))

瀏覽器緩存

使用合適的連接池（數(shù)據(jù)庫連接池、線程池等等）

適當(dāng)使用多線程進(jìn)行開發(fā)。

降級(jí)： 服務(wù)降級(jí)是當(dāng)服務(wù)器壓力劇增的情況下，根據(jù)當(dāng)前業(yè)務(wù)情況及流量對(duì)一些服務(wù)和頁面有策略的降級(jí)，以此釋放服務(wù)器資源以保證核心任務(wù)的正常運(yùn)行。降級(jí)往往會(huì)指定不同的級(jí)別，面臨不同的異常等級(jí)執(zhí)行不同的處理。根據(jù)服務(wù)方式：可以拒接服務(wù)，可以延遲服務(wù)，也有時(shí)候可以隨機(jī)服務(wù)。根據(jù)服務(wù)范圍：可以砍掉某個(gè)功能，也可以砍掉某些模塊?？傊?wù)降級(jí)需要根據(jù)不同的業(yè)務(wù)需求采用不同的降級(jí)策略。主要的目的就是服務(wù)雖然有損但是總比沒有好；

限流： 防止惡意請(qǐng)求流量、惡意攻擊，或者防止流量超出系統(tǒng)峰值；

緩存： 避免大量請(qǐng)求直接落到數(shù)據(jù)庫，將數(shù)據(jù)庫擊垮；

超時(shí)和重試機(jī)制： 避免請(qǐng)求堆積造成雪崩；

回滾機(jī)制： 快速修復(fù)錯(cuò)誤版本。

高并發(fā)，大流量；

高可用：系統(tǒng)7×24小時(shí)不間斷服務(wù)；

海量數(shù)據(jù)：需要存儲(chǔ)、管理海量數(shù)據(jù)，需要使用大量服務(wù)器；

用戶分布廣泛，網(wǎng)絡(luò)情況復(fù)雜：許多大型互聯(lián)網(wǎng)都是為全球用戶提供服務(wù)的，用戶分布范圍廣，各地網(wǎng)絡(luò)情況千差萬別；

安全環(huán)境惡劣：由于互聯(lián)網(wǎng)的開放性，使得互聯(lián)網(wǎng)更容易受到攻擊，大型網(wǎng)站幾乎每天都會(huì)被黑客攻擊；

需求快速變更，發(fā)布頻繁：和傳統(tǒng)軟件的版本發(fā)布頻率不同，互聯(lián)網(wǎng)產(chǎn)品為快速適應(yīng)市場，滿足用戶需求，其產(chǎn)品發(fā)布頻率是極高的；

漸進(jìn)式發(fā)展：與傳統(tǒng)軟件產(chǎn)品或企業(yè)應(yīng)用系統(tǒng)一開始就規(guī)劃好全部的功能和非功能需求不同，幾乎所有的大型互聯(lián)網(wǎng)網(wǎng)站都是從一個(gè)小網(wǎng)站開始，漸進(jìn)地發(fā)展起來。

現(xiàn)在大公司都在用并且未來的趨勢(shì)都是 Spring Cloud，而阿里開源的 Spring Cloud Alibaba 也是 Spring Cloud 規(guī)范的實(shí)現(xiàn) 。

我們通常把 Spring Cloud 理解為一系列開源組件的集合，但是 Spring Cloud并不是等同于 Spring Cloud Netflix 的 Ribbon、Feign、Eureka（停止更新）、Hystrix 這一套組件，而是抽象了一套通用的開發(fā)模式。它的目的是通過抽象出這套通用的模式，讓開發(fā)者更快更好地開發(fā)業(yè)務(wù)。但是這套開發(fā)模式運(yùn)行時(shí)的實(shí)際載體，還是依賴于 RPC、網(wǎng)關(guān)、服務(wù)發(fā)現(xiàn)、配置管理、限流熔斷、分布式鏈路跟蹤等組件的具體實(shí)現(xiàn)。

Spring Cloud Alibaba 是官方認(rèn)證的新一套 Spring Cloud 規(guī)范的實(shí)現(xiàn),Spring Cloud Alibaba 是一套國產(chǎn)開源產(chǎn)品集合，后續(xù)還會(huì)有中文 reference 和一些原理分析文章，所以，這對(duì)于國內(nèi)的開發(fā)者是非常棒的一件事。阿里的這一舉動(dòng)勢(shì)必會(huì)推動(dòng)國內(nèi)微服務(wù)技術(shù)的發(fā)展，因?yàn)樵跊]有 Spring Cloud Alibaba 之前，我們的第一選擇是 Spring Cloud Netflix，但是它們的文檔都是英文的，出問題后排查也比較困難， 在國內(nèi)并不是有特別多的人精通。Spring Cloud Alibaba 由阿里開源組件和阿里云產(chǎn)品組件兩部分組成，其致力于提供微服務(wù)一站式解決方案，方便開發(fā)者通過 Spring Cloud 編程模型輕松開發(fā)微服務(wù)應(yīng)用。

另外，Apache Dubbo Ecosystem 是圍繞 Apache Dubbo 打造的微服務(wù)生態(tài)，是經(jīng)過生產(chǎn)驗(yàn)證的微服務(wù)的最佳實(shí)踐組合。在阿里巴巴的微服務(wù)解決方案中，Dubbo、Nacos 和 Sentinel，以及后續(xù)將開源的微服務(wù)組件，都是 Dubbo EcoSystem 的一部分。阿里后續(xù)也會(huì)將 Dubbo EcoSystem 集成到 Spring Cloud 的生態(tài)中。

具體可以看公眾號(hào)-阿里巴巴中間件的這篇文章:獨(dú)家解讀：Dubbo Ecosystem - 從微服務(wù)框架到微服務(wù)生態(tài)

Dubbo 與 Spring Cloud 并不是競爭關(guān)系，Dubbo 作為成熟的 RPC 框架，其易用性、擴(kuò)展性和健壯性已得到業(yè)界的認(rèn)可。未來 Dubbo 將會(huì)作為 Spring Cloud Alibaba 的 RPC 組件，并與 Spring Cloud 原生的 Feign 以及 RestTemplate 進(jìn)行無縫整合，實(shí)現(xiàn)“零”成本遷移。

在阿里巴巴的微服務(wù)解決方案中，Dubbo、Nacos 和 Sentinel，以及后續(xù)將開源的微服務(wù)組件，都是 Dubbo EcoSystem 的一部分。我們后續(xù)也會(huì)將 Dubbo EcoSystem 集成到 Spring Cloud 的生態(tài)中。

性能測試指通過自動(dòng)化的測試工具模擬多種正常、峰值以及異常負(fù)載條件來對(duì)系統(tǒng)的各項(xiàng)性能指標(biāo)進(jìn)行測試。性能測試是總稱，通常細(xì)分為：

基準(zhǔn)測試： 在給系統(tǒng)施加較低壓力時(shí)，查看系統(tǒng)的運(yùn)行狀況并記錄相關(guān)數(shù)做為基礎(chǔ)參考

負(fù)載測試：是指對(duì)系統(tǒng)不斷地增加壓力或增加一定壓力下的持續(xù)時(shí)間，直到系統(tǒng)的某項(xiàng)或多項(xiàng)性能指標(biāo)達(dá)到安全臨界值，例如某種資源已經(jīng)達(dá)到飽和狀態(tài)等 。此時(shí)繼續(xù)加壓，系統(tǒng)處理能力會(huì)下降。

壓力測試： 超過安全負(fù)載情況下，不斷施加壓力（增加并發(fā)請(qǐng)求），直到系統(tǒng)崩潰或無法處理任何請(qǐng)求，依此獲得系統(tǒng)最大壓力承受能力。

穩(wěn)定性測試： 被測試系統(tǒng)在特定硬件、軟件、網(wǎng)絡(luò)環(huán)境下，加載一定業(yè)務(wù)壓力（模擬生產(chǎn)環(huán)境不同時(shí)間點(diǎn)、不均勻請(qǐng)求，呈波浪特性）運(yùn)行一段較長時(shí)間，以此檢測系統(tǒng)是否穩(wěn)定。

后端程序員或者測試平常比較常用的測試工具是 JMeter（官網(wǎng)：https://jmeter.apache.org/）。Apache JMeter 是一款基于Java的壓力測試工具(100％純Java應(yīng)用程序)，旨在加載測試功能行為和測量性能。它最初被設(shè)計(jì)用于 Web 應(yīng)用測試但后來擴(kuò)展到其他測試領(lǐng)域。

這個(gè)時(shí)候就要考慮擴(kuò)容了?！秲|級(jí)流量網(wǎng)站架構(gòu)核心技術(shù)》這本書上面介紹到我們可以考慮下面幾步來解決這個(gè)問題：

第一步，可以考慮簡單的擴(kuò)容來解決問題。比如增加系統(tǒng)的服務(wù)器，提高硬件能力等等。

第二步，如果簡單擴(kuò)容搞不定，就需要水平拆分和垂直拆分?jǐn)?shù)據(jù)／應(yīng)用來提升系統(tǒng)的伸縮性，即通過擴(kuò)容提升系統(tǒng)負(fù)載能力。

第三步，如果通過水平拆分／垂直拆分還是搞不定，那就需要根據(jù)現(xiàn)有系統(tǒng)特性，架構(gòu)層面進(jìn)行重構(gòu)甚至是重新設(shè)計(jì)，即推倒重來。

對(duì)于系統(tǒng)設(shè)計(jì)，理想的情況下應(yīng)支持線性擴(kuò)容和彈性擴(kuò)容，即在系統(tǒng)瓶頸時(shí)，只需要增加機(jī)器就可以解決系統(tǒng)瓶頸，如降低延遲提升吞吐量，從而實(shí)現(xiàn)擴(kuò)容需求。

如果你想擴(kuò)容，則支持水平/垂直伸縮是前提。在進(jìn)行拆分時(shí)，一定要清楚知道自己的目的是什么，拆分后帶來的問題如何解決，拆分后如果沒有得到任何收益就不要為了
拆而拆，即不要過度拆分，要適合自己的業(yè)務(wù)。

當(dāng)MySQL單表記錄數(shù)過大時(shí)，數(shù)據(jù)庫的CRUD性能會(huì)明顯下降，一些常見的優(yōu)化措施如下：

限定數(shù)據(jù)的范圍： 務(wù)必禁止不帶任何限制數(shù)據(jù)范圍條件的查詢語句。比如：我們當(dāng)用戶在查詢訂單歷史的時(shí)候，我們可以控制在一個(gè)月的范圍內(nèi)。；

讀/寫分離： 經(jīng)典的數(shù)據(jù)庫拆分方案，主庫負(fù)責(zé)寫，從庫負(fù)責(zé)讀；

垂直分區(qū)： 根據(jù)數(shù)據(jù)庫里面數(shù)據(jù)表的相關(guān)性進(jìn)行拆分。 例如，用戶表中既有用戶的登錄信息又有用戶的基本信息，可以將用戶表拆分成兩個(gè)多帶帶的表，甚至放到多帶帶的庫做分庫。簡單來說垂直拆分是指數(shù)據(jù)表列的拆分，把一張列比較多的表拆分為多張表。 如下圖所示，這樣來說大家應(yīng)該就更容易理解了。垂直拆分的優(yōu)點(diǎn)： 可以使得行數(shù)據(jù)變小，在查詢時(shí)減少讀取的Block數(shù)，減少I/O次數(shù)。此外，垂直分區(qū)可以簡化表的結(jié)構(gòu)，易于維護(hù)。垂直拆分的缺點(diǎn)： 主鍵會(huì)出現(xiàn)冗余，需要管理冗余列，并會(huì)引起Join操作，可以通過在應(yīng)用層進(jìn)行Join來解決。此外，垂直分區(qū)會(huì)讓事務(wù)變得更加復(fù)雜；

水平分區(qū)： 保持?jǐn)?shù)據(jù)表結(jié)構(gòu)不變，通過某種策略存儲(chǔ)數(shù)據(jù)分片。這樣每一片數(shù)據(jù)分散到不同的表或者庫中，達(dá)到了分布式的目的。 水平拆分可以支撐非常大的數(shù)據(jù)量。 水平拆分是指數(shù)據(jù)表行的拆分，表的行數(shù)超過200萬行時(shí)，就會(huì)變慢，這時(shí)可以把一張的表的數(shù)據(jù)拆成多張表來存放。舉個(gè)例子：我們可以將用戶信息表拆分成多個(gè)用戶信息表，這樣就可以避免單一表數(shù)據(jù)量過大對(duì)性能造成影響。水平拆分可以支持非常大的數(shù)據(jù)量。需要注意的一點(diǎn)是:分表僅僅是解決了單一表數(shù)據(jù)過大的問題，但由于表的數(shù)據(jù)還是在同一臺(tái)機(jī)器上，其實(shí)對(duì)于提升MySQL并發(fā)能力沒有什么意義，所以 水平拆分最好分庫 。水平拆分能夠 支持非常大的數(shù)據(jù)量存儲(chǔ)，應(yīng)用端改造也少，但 分片事務(wù)難以解決 ，跨界點(diǎn)Join性能較差，邏輯復(fù)雜?！禞ava工程師修煉之道》的作者推薦 盡量不要對(duì)數(shù)據(jù)進(jìn)行分片，因?yàn)椴鸱謺?huì)帶來邏輯、部署、運(yùn)維的各種復(fù)雜度 ，一般的數(shù)據(jù)表在優(yōu)化得當(dāng)?shù)那闆r下支撐千萬以下的數(shù)據(jù)量是沒有太大問題的。如果實(shí)在要分片，盡量選擇客戶端分片架構(gòu)，這樣可以減少一次和中間件的網(wǎng)絡(luò)I/O。

下面補(bǔ)充一下數(shù)據(jù)庫分片的兩種常見方案：

客戶端代理： 分片邏輯在應(yīng)用端，封裝在jar包中，通過修改或者封裝JDBC層來實(shí)現(xiàn)。 當(dāng)當(dāng)網(wǎng)的 Sharding-JDBC 、阿里的TDDL是兩種比較常用的實(shí)現(xiàn)。

中間件代理： 在應(yīng)用和數(shù)據(jù)中間加了一個(gè)代理層。分片邏輯統(tǒng)一維護(hù)在中間件服務(wù)中。 我們現(xiàn)在談的 Mycat 、360的Atlas、網(wǎng)易的DDB等等都是這種架構(gòu)的實(shí)現(xiàn)。

《大型網(wǎng)站技術(shù)架構(gòu)》第四章和第七章均有提到消息隊(duì)列對(duì)應(yīng)用性能及擴(kuò)展性的提升。

如上圖，在不使用消息隊(duì)列服務(wù)器的時(shí)候，用戶的請(qǐng)求數(shù)據(jù)直接寫入數(shù)據(jù)庫，在高并發(fā)的情況下數(shù)據(jù)庫壓力劇增，使得響應(yīng)速度變慢。但是在使用消息隊(duì)列之后，用戶的請(qǐng)求數(shù)據(jù)發(fā)送給消息隊(duì)列之后立即 返回，再由消息隊(duì)列的消費(fèi)者進(jìn)程從消息隊(duì)列中獲取數(shù)據(jù)，異步寫入數(shù)據(jù)庫。由于消息隊(duì)列服務(wù)器處理速度快于數(shù)據(jù)庫（消息隊(duì)列也比數(shù)據(jù)庫有更好的伸縮性），因此響應(yīng)速度得到大幅改善。

通過以上分析我們可以得出消息隊(duì)列具有很好的削峰作用的功能——即通過異步處理，將短時(shí)間高并發(fā)產(chǎn)生的事務(wù)消息存儲(chǔ)在消息隊(duì)列中，從而削平高峰期的并發(fā)事務(wù)。 舉例：在電子商務(wù)一些秒殺、促銷活動(dòng)中，合理使用消息隊(duì)列可以有效抵御促銷活動(dòng)剛開始大量訂單涌入對(duì)系統(tǒng)的沖擊。如下圖所示：

因?yàn)?strong>用戶請(qǐng)求數(shù)據(jù)寫入消息隊(duì)列之后就立即返回給用戶了，但是請(qǐng)求數(shù)據(jù)在后續(xù)的業(yè)務(wù)校驗(yàn)、寫數(shù)據(jù)庫等操作中可能失敗。因此使用消息隊(duì)列進(jìn)行異步處理之后，需要適當(dāng)修改業(yè)務(wù)流程進(jìn)行配合，比如用戶在提交訂單之后，訂單數(shù)據(jù)寫入消息隊(duì)列，不能立即返回用戶訂單提交成功，需要在消息隊(duì)列的訂單消費(fèi)者進(jìn)程真正處理完該訂單之后，甚至出庫后，再通過電子郵件或短信通知用戶訂單成功，以免交易糾紛。這就類似我們平時(shí)手機(jī)訂火車票和電影票。

我們知道模塊分布式部署以后聚合方式通常有兩種：1.分布式消息隊(duì)列和2.分布式服務(wù)。

先來簡單說一下分布式服務(wù)：

目前使用比較多的用來構(gòu)建SOA（Service Oriented Architecture面向服務(wù)體系結(jié)構(gòu)）的分布式服務(wù)框架是阿里巴巴開源的Dubbo.如果想深入了解Dubbo的可以看我寫的關(guān)于Dubbo的這一篇文章：《高性能優(yōu)秀的服務(wù)框架-dubbo介紹》：https://juejin.im/post/5acadeb1f265da2375072f9c

再來談我們的分布式消息隊(duì)列：

我們知道如果模塊之間不存在直接調(diào)用，那么新增模塊或者修改模塊就對(duì)其他模塊影響較小，這樣系統(tǒng)的可擴(kuò)展性無疑更好一些。

我們最常見的事件驅(qū)動(dòng)架構(gòu)類似生產(chǎn)者消費(fèi)者模式，在大型網(wǎng)站中通常用利用消息隊(duì)列實(shí)現(xiàn)事件驅(qū)動(dòng)結(jié)構(gòu)。如下圖所示：

消息隊(duì)列使利用發(fā)布-訂閱模式工作，消息發(fā)送者（生產(chǎn)者）發(fā)布消息，一個(gè)或多個(gè)消息接受者（消費(fèi)者）訂閱消息。 從上圖可以看到消息發(fā)送者（生產(chǎn)者）和消息接受者（消費(fèi)者）之間沒有直接耦合，消息發(fā)送者將消息發(fā)送至分布式消息隊(duì)列即結(jié)束對(duì)消息的處理，消息接受者從分布式消息隊(duì)列獲取該消息后進(jìn)行后續(xù)處理，并不需要知道該消息從何而來。對(duì)新增業(yè)務(wù)，只要對(duì)該類消息感興趣，即可訂閱該消息，對(duì)原有系統(tǒng)和業(yè)務(wù)沒有任何影響，從而實(shí)現(xiàn)網(wǎng)站業(yè)務(wù)的可擴(kuò)展性設(shè)計(jì)。

消息接受者對(duì)消息進(jìn)行過濾、處理、包裝后，構(gòu)造成一個(gè)新的消息類型，將消息繼續(xù)發(fā)送出去，等待其他消息接受者訂閱該消息。因此基于事件（消息對(duì)象）驅(qū)動(dòng)的業(yè)務(wù)架構(gòu)可以是一系列流程。

另外為了避免消息隊(duì)列服務(wù)器宕機(jī)造成消息丟失，會(huì)將成功發(fā)送到消息隊(duì)列的消息存儲(chǔ)在消息生產(chǎn)者服務(wù)器上，等消息真正被消費(fèi)者服務(wù)器處理后才刪除消息。在消息隊(duì)列服務(wù)器宕機(jī)后，生產(chǎn)者服務(wù)器會(huì)選擇分布式消息隊(duì)列服務(wù)器集群中的其他服務(wù)器發(fā)布消息。

備注： 不要認(rèn)為消息隊(duì)列只能利用發(fā)布-訂閱模式工作，只不過在解耦這個(gè)特定業(yè)務(wù)環(huán)境下是使用發(fā)布-訂閱模式的，比如在我們的ActiveMQ消息隊(duì)列中還有點(diǎn)對(duì)點(diǎn)工作模式，具體的會(huì)在后面的文章給大家詳細(xì)介紹，這一篇文章主要還是讓大家對(duì)消息隊(duì)列有一個(gè)更透徹的了解。

這個(gè)問題一般會(huì)在上一個(gè)問題問完之后，緊接著被問到。“使用消息隊(duì)列會(huì)帶來什么問題？”這個(gè)問題要引起重視，一般我們都會(huì)考慮使用消息隊(duì)列會(huì)帶來的好處而忽略它帶來的問題！

在理論計(jì)算機(jī)科學(xué)中，CAP定理（CAP theorem），又被稱作布魯爾定理（Brewer"s theorem），它指出對(duì)于一個(gè)分布式計(jì)算系統(tǒng)來說，不可能同時(shí)滿足以下三點(diǎn)：

一致性（Consistence） :所有節(jié)點(diǎn)訪問同一份最新的數(shù)據(jù)副本

可用性（Availability）:每次請(qǐng)求都能獲取到非錯(cuò)的響應(yīng)——但是不保證獲取的數(shù)據(jù)為最新數(shù)據(jù)

分區(qū)容錯(cuò)性（Partition tolerance） : 分布式系統(tǒng)在遇到某節(jié)點(diǎn)或網(wǎng)絡(luò)分區(qū)故障的時(shí)候，仍然能夠?qū)ν馓峁M足一致性和可用性的服務(wù)。

CAP僅適用于原子讀寫的NOSQL場景中，并不適合數(shù)據(jù)庫系統(tǒng)?，F(xiàn)在的分布式系統(tǒng)具有更多特性比如擴(kuò)展性、可用性等等，在進(jìn)行系統(tǒng)設(shè)計(jì)和開發(fā)時(shí)，我們不應(yīng)該僅僅局限在CAP問題上。

注意：不是所謂的3選2（不要被網(wǎng)上大多數(shù)文章誤導(dǎo)了）:

大部分人解釋這一定律時(shí)，常常簡單的表述為：“一致性、可用性、分區(qū)容忍性三者你只能同時(shí)達(dá)到其中兩個(gè)，不可能同時(shí)達(dá)到”。實(shí)際上這是一個(gè)非常具有誤導(dǎo)性質(zhì)的說法，而且在CAP理論誕生12年之后，CAP之父也在2012年重寫了之前的論文。

當(dāng)發(fā)生網(wǎng)絡(luò)分區(qū)的時(shí)候，如果我們要繼續(xù)服務(wù)，那么強(qiáng)一致性和可用性只能2選1。也就是說當(dāng)網(wǎng)絡(luò)分區(qū)之后P是前提，決定了P之后才有C和A的選擇。也就是說分區(qū)容錯(cuò)性（Partition tolerance）我們是必須要實(shí)現(xiàn)的。

我在網(wǎng)上找了很多文章想看一下有沒有文章提到這個(gè)不是所謂的3選2，用百度半天沒找到了一篇，用谷歌搜索找到一篇比較不錯(cuò)的，如果想深入學(xué)習(xí)一下CAP就看這篇文章把，我這里就不多BB了：《分布式系統(tǒng)之CAP理論》 ： http://www.cnblogs.com/hxsyl/p/4381980.html

BASE 是 Basically Available（基本可用） 、Soft-state（軟狀態(tài)） 和 Eventually Consistent（最終一致性） 三個(gè)短語的縮寫。BASE理論是對(duì)CAP中一致性和可用性權(quán)衡的結(jié)果，其來源于對(duì)大規(guī)?；ヂ?lián)網(wǎng)系統(tǒng)分布式實(shí)踐的總結(jié)，是基于CAP定理逐步演化而來的，它大大降低了我們對(duì)系統(tǒng)的要求。

BASE理論的核心思想： 即使無法做到強(qiáng)一致性，但每個(gè)應(yīng)用都可以根據(jù)自身業(yè)務(wù)特點(diǎn)，采用適當(dāng)?shù)姆绞絹硎瓜到y(tǒng)達(dá)到最終一致性。也就是犧牲數(shù)據(jù)的一致性來滿足系統(tǒng)的高可用性，系統(tǒng)中一部分?jǐn)?shù)據(jù)不可用或者不一致時(shí)，仍需要保持系統(tǒng)整體“主要可用”。

BASE理論三要素：

基本可用： 基本可用是指分布式系統(tǒng)在出現(xiàn)不可預(yù)知故障的時(shí)候，允許損失部分可用性。但是，這絕不等價(jià)于系統(tǒng)不可用。 比如： ①響應(yīng)時(shí)間上的損失:正常情況下，一個(gè)在線搜索引擎需要在0.5秒之內(nèi)返回給用戶相應(yīng)的查詢結(jié)果，但由于出現(xiàn)故障，查詢結(jié)果的響應(yīng)時(shí)間增加了1~2秒；②系統(tǒng)功能上的損失：正常情況下，在一個(gè)電子商務(wù)網(wǎng)站上進(jìn)行購物的時(shí)候，消費(fèi)者幾乎能夠順利完成每一筆訂單，但是在一些節(jié)日大促購物高峰的時(shí)候，由于消費(fèi)者的購物行為激增，為了保護(hù)購物系統(tǒng)的穩(wěn)定性，部分消費(fèi)者可能會(huì)被引導(dǎo)到一個(gè)降級(jí)頁面；

軟狀態(tài)： 軟狀態(tài)指允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài)，并認(rèn)為該中間狀態(tài)的存在不會(huì)影響系統(tǒng)的整體可用性，即允許系統(tǒng)在不同節(jié)點(diǎn)的數(shù)據(jù)副本之間進(jìn)行數(shù)據(jù)同步的過程存在延時(shí)；

最終一致性： 最終一致性強(qiáng)調(diào)的是系統(tǒng)中所有的數(shù)據(jù)副本，在經(jīng)過一段時(shí)間的同步后，最終能夠達(dá)到一個(gè)一致的狀態(tài)。因此，最終一致性的本質(zhì)是需要系統(tǒng)保證最終數(shù)據(jù)能夠達(dá)到一致，而不需要實(shí)時(shí)保證系統(tǒng)數(shù)據(jù)的強(qiáng)一致性。

《大型網(wǎng)站技術(shù)架構(gòu)》

《億級(jí)流量網(wǎng)站架構(gòu)核心技術(shù)》

《Java工程師修煉之道》

https://www.cnblogs.com/pures...

專注Java知識(shí)和面試技能分享！我已經(jīng)整理好了一份Java 學(xué)習(xí)必備的書籍+視頻+文檔匯總，內(nèi)容比較多，你可以在公眾號(hào)后臺(tái)回復(fù)關(guān)鍵“1”，我會(huì)免費(fèi)無套路把這些都給你。