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

1. 提高硬件能力膳犹、增加系統(tǒng)服務(wù)器蛇受。（當服務(wù)器增加到某個程度的時候系統(tǒng)所能提供的并發(fā)訪問量幾乎不變，所以不能根本解決問題）
2. 使用緩存（本地緩存：本地可以使用JDK自帶的 Map、Guava Cache.分布式緩存：Redis稚矿、Memcache.本地緩存不適用于提高系統(tǒng)并發(fā)量白热，一般是用處用在程序中敛助。比如Spring是如何實現(xiàn)單例的呢？大家如果看過源碼的話屋确，應(yīng)該知道纳击，S把已經(jīng)初始過的變量放在一個Map中续扔，下次再要使用這個變量的時候，先判斷Map中有沒有焕数，這也就是系統(tǒng)中常見的單例模式的實現(xiàn)纱昧。）
3. 消息隊列 （解耦+削峰+異步）
4. 采用分布式開發(fā) （不同的服務(wù)部署在不同的機器節(jié)點上，并且一個服務(wù)也可以部署在多臺機器上堡赔，然后利用 Nginx 負載均衡訪問识脆。這樣就解決了單點部署(All In)的缺點，大大提高的系統(tǒng)并發(fā)量）
5. 數(shù)據(jù)庫分庫（讀寫分離）善已、分表（水平分表灼捂、垂直分表）
6. 采用集群 （多臺機器提供相同的服務(wù)）
7. CDN 加速 (將一些靜態(tài)資源比如圖片、視頻等等緩存到離用戶最近的網(wǎng)絡(luò)節(jié)點)
8. 瀏覽器緩存
9. 使用合適的連接池（數(shù)據(jù)庫連接池换团、線程池等等）
10. 適當使用多線程進行開發(fā)纵东。

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

1. 降級： 服務(wù)降級是當服務(wù)器壓力劇增的情況下，根據(jù)當前業(yè)務(wù)情況及流量對一些服務(wù)和頁面有策略的降級啥寇，以此釋放服務(wù)器資源以保證核心任務(wù)的正常運行偎球。降級往往會指定不同的級別，面臨不同的異常等級執(zhí)行不同的處理辑甜。根據(jù)服務(wù)方式：可以拒接服務(wù)衰絮，可以延遲服務(wù)，也有時候可以隨機服務(wù)磷醋。根據(jù)服務(wù)范圍：可以砍掉某個功能猫牡，也可以砍掉某些模塊〉讼撸總之服務(wù)降級需要根據(jù)不同的業(yè)務(wù)需求采用不同的降級策略淌友。主要的目的就是服務(wù)雖然有損但是總比沒有好；
2. 限流： 防止惡意請求流量骇陈、惡意攻擊震庭，或者防止流量超出系統(tǒng)峰值；
3. 緩存： 避免大量請求直接落到數(shù)據(jù)庫你雌，將數(shù)據(jù)庫擊垮器联；
4. 超時和重試機制： 避免請求堆積造成雪崩；
5. 回滾機制： 快速修復(fù)錯誤版本婿崭。

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

1. 高并發(fā)拨拓，大流量；
2. 高可用：系統(tǒng)7×24小時不間斷服務(wù)氓栈；
3. 海量數(shù)據(jù)：需要存儲渣磷、管理海量數(shù)據(jù)，需要使用大量服務(wù)器授瘦；
4. 用戶分布廣泛醋界，網(wǎng)絡(luò)情況復(fù)雜：許多大型互聯(lián)網(wǎng)都是為全球用戶提供服務(wù)的祟身，用戶分布范圍廣，各地網(wǎng)絡(luò)情況千差萬別物独；
5. 安全環(huán)境惡劣：由于互聯(lián)網(wǎng)的開放性袜硫，使得互聯(lián)網(wǎng)更容易受到攻擊，大型網(wǎng)站幾乎每天都會被黑客攻擊挡篓；
6. 需求快速變更婉陷，發(fā)布頻繁：和傳統(tǒng)軟件的版本發(fā)布頻率不同，互聯(lián)網(wǎng)產(chǎn)品為快速適應(yīng)市場官研，滿足用戶需求秽澳，其產(chǎn)品發(fā)布頻率是極高的；
7. 漸進式發(fā)展：與傳統(tǒng)軟件產(chǎn)品或企業(yè)應(yīng)用系統(tǒng)一開始就規(guī)劃好全部的功能和非功能需求不同戏羽，幾乎所有的大型互聯(lián)網(wǎng)網(wǎng)站都是從一個小網(wǎng)站開始担神，漸進地發(fā)展起來。

4. 談?wù)勀銓ξ⒎?wù)領(lǐng)域的了解和認識

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

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

Spring Cloud Alibaba 是官方認證的新一套 Spring Cloud 規(guī)范的實現(xiàn),Spring Cloud Alibaba 是一套國產(chǎn)開源產(chǎn)品集合讹弯，后續(xù)還會有中文 reference 和一些原理分析文章况既，所以，這對于國內(nèi)的開發(fā)者是非常棒的一件事组民。阿里的這一舉動勢必會推動國內(nèi)微服務(wù)技術(shù)的發(fā)展棒仍，因為在沒有 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)驗證的微服務(wù)的最佳實踐組合。在阿里巴巴的微服務(wù)解決方案中爽彤，Dubbo养盗、Nacos 和 Sentinel，以及后續(xù)將開源的微服務(wù)組件适篙，都是 Dubbo EcoSystem 的一部分往核。阿里后續(xù)也會將 Dubbo EcoSystem 集成到 Spring Cloud 的生態(tài)中。

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

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

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

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

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

性能測試指通過自動化的測試工具模擬多種正常敬矩、峰值以及異常負載條件來對系統(tǒng)的各項性能指標進行測試。性能測試是總稱蠢挡，通常細分為：

1. 基準測試： 在給系統(tǒng)施加較低壓力時弧岳，查看系統(tǒng)的運行狀況并記錄相關(guān)數(shù)做為基礎(chǔ)參考
2. 負載測試： 是指對系統(tǒng)不斷地增加壓力或增加一定壓力下的持續(xù)時間，直到系統(tǒng)的某項或多項性能指標達到安全臨界值业踏，例如某種資源已經(jīng)達到飽和狀態(tài)等 禽炬。此時繼續(xù)加壓，系統(tǒng)處理能力會下降勤家。
3. 壓力測試： 超過安全負載情況下腹尖，不斷施加壓力（增加并發(fā)請求），直到系統(tǒng)崩潰或無法處理任何請求伐脖，依此獲得系統(tǒng)最大壓力承受能力热幔。
4. 穩(wěn)定性測試： 被測試系統(tǒng)在特定硬件乐设、軟件、網(wǎng)絡(luò)環(huán)境下绎巨，加載一定業(yè)務(wù)壓力（模擬生產(chǎn)環(huán)境不同時間點近尚、不均勻請求，呈波浪特性）運行一段較長時間场勤，以此檢測系統(tǒng)是否穩(wěn)定肿男。

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

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

這個時候就要考慮擴容了窗价∪缤ィ《億級流量網(wǎng)站架構(gòu)核心技術(shù)》這本書上面介紹到我們可以考慮下面幾步來解決這個問題：

• 第一步，可以考慮簡單的擴容來解決問題撼港。比如增加系統(tǒng)的服務(wù)器坪它，提高硬件能力等等。
• 第二步帝牡，如果簡單擴容搞不定往毡，就需要水平拆分和垂直拆分數(shù)據(jù)／應(yīng)用來提升系統(tǒng)的伸縮性，即通過擴容提升系統(tǒng)負載能力靶溜。
• 第三步开瞭，如果通過水平拆分／垂直拆分還是搞不定，那就需要根據(jù)現(xiàn)有系統(tǒng)特性罩息，架構(gòu)層面進行重構(gòu)甚至是重新設(shè)計嗤详，即推倒重來。

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

如果你想擴容烘绽，則支持水平/垂直伸縮是前提淋昭。在進行拆分時，一定要清楚知道自己的目的是什么诀姚，拆分后帶來的問題如何解決响牛，拆分后如果沒有得到任何收益就不要為了
拆而拆，即不要過度拆分赫段，要適合自己的業(yè)務(wù)呀打。

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

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

1. 限定數(shù)據(jù)的范圍： 務(wù)必禁止不帶任何限制數(shù)據(jù)范圍條件的查詢語句贬丛。比如：我們當用戶在查詢訂單歷史的時候，我們可以控制在一個月的范圍內(nèi)给涕；
2. 讀/寫分離： 經(jīng)典的數(shù)據(jù)庫拆分方案豺憔，主庫負責寫，從庫負責讀够庙；
3. 垂直分區(qū)： 根據(jù)數(shù)據(jù)庫里面數(shù)據(jù)表的相關(guān)性進行拆分恭应。 例如，用戶表中既有用戶的登錄信息又有用戶的基本信息耘眨，可以將用戶表拆分成兩個單獨的表昼榛，甚至放到單獨的庫做分庫。簡單來說垂直拆分是指數(shù)據(jù)表列的拆分剔难，把一張列比較多的表拆分為多張表胆屿。 如下圖所示，這樣來說大家應(yīng)該就更容易理解了偶宫。
   image.png
   
   垂直拆分的優(yōu)點： 可以使得行數(shù)據(jù)變小非迹，在查詢時減少讀取的Block數(shù)，減少I/O次數(shù)纯趋。此外憎兽，垂直分區(qū)可以簡化表的結(jié)構(gòu)，易于維護吵冒。垂直拆分的缺點： 主鍵會出現(xiàn)冗余唇兑，需要管理冗余列，并會引起Join操作桦锄，可以通過在應(yīng)用層進行Join來解決扎附。此外，垂直分區(qū)會讓事務(wù)變得更加復(fù)雜结耀；
4. 水平分區(qū)： 保持數(shù)據(jù)表結(jié)構(gòu)不變留夜，通過某種策略存儲數(shù)據(jù)分片。這樣每一片數(shù)據(jù)分散到不同的表或者庫中图甜，達到了分布式的目的碍粥。 水平拆分可以支撐非常大的數(shù)據(jù)量。 水平拆分是指數(shù)據(jù)表行的拆分黑毅，表的行數(shù)超過200萬行時嚼摩，就會變慢，這時可以把一張的表的數(shù)據(jù)拆成多張表來存放。舉個例子：我們可以將用戶信息表拆分成多個用戶信息表枕面，這樣就可以避免單一表數(shù)據(jù)量過大對性能造成影響愿卒。
   image.png
   
   水平拆分可以支持非常大的數(shù)據(jù)量。需要注意的一點是:分表僅僅是解決了單一表數(shù)據(jù)過大的問題潮秘，但由于表的數(shù)據(jù)還是在同一臺機器上琼开，其實對于提升MySQL并發(fā)能力沒有什么意義，所以 水平拆分最好分庫 枕荞。水平拆分能夠 支持非常大的數(shù)據(jù)量存儲柜候，應(yīng)用端改造也少，但 分片事務(wù)難以解決 躏精，跨界點Join性能較差渣刷，邏輯復(fù)雜〈Ｖ颍《Java工程師修煉之道》的作者推薦 盡量不要對數(shù)據(jù)進行分片辅柴，因為拆分會帶來邏輯、部署高诺、運維的各種復(fù)雜度 碌识，一般的數(shù)據(jù)表在優(yōu)化得當?shù)那闆r下支撐千萬以下的數(shù)據(jù)量是沒有太大問題的。如果實在要分片虱而，盡量選擇客戶端分片架構(gòu)筏餐，這樣可以減少一次和中間件的網(wǎng)絡(luò)I/O。

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

• 客戶端代理： 分片邏輯在應(yīng)用端牡拇，封裝在jar包中魁瞪，通過修改或者封裝JDBC層來實現(xiàn)。 當當網(wǎng)的 Sharding-JDBC 惠呼、阿里的TDDL是兩種比較常用的實現(xiàn)导俘。
• 中間件代理： 在應(yīng)用和數(shù)據(jù)中間加了一個代理層。分片邏輯統(tǒng)一維護在中間件服務(wù)中剔蹋。 我們現(xiàn)在談的 Mycat 旅薄、360的Atlas、網(wǎng)易的DDB等等都是這種架構(gòu)的實現(xiàn)泣崩。

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

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

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

image.png

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

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

image.png

因為用戶請求數(shù)據(jù)寫入消息隊列之后就立即返回給用戶了文搂，但是請求數(shù)據(jù)在后續(xù)的業(yè)務(wù)校驗、寫數(shù)據(jù)庫等操作中可能失敗秤朗。因此使用消息隊列進行異步處理之后煤蹭，需要適當修改業(yè)務(wù)流程進行配合，比如用戶在提交訂單之后取视，訂單數(shù)據(jù)寫入消息隊列硝皂，不能立即返回用戶訂單提交成功，需要在消息隊列的訂單消費者進程真正處理完該訂單之后作谭，甚至出庫后稽物，再通過電子郵件或短信通知用戶訂單成功，以免交易糾紛折欠。這就類似我們平時手機訂火車票和電影票贝或。

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

我們知道模塊分布式部署以后聚合方式通常有兩種：1.分布式消息隊列和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

再來談我們的分布式消息隊列：

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

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

image.png

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

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

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

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

這個問題一般會在上一個問題問完之后，緊接著被問到表伦”暮撸“使用消息隊列會帶來什么問題？”這個問題要引起重視妆丘，一般我們都會考慮使用消息隊列會帶來的好處而忽略它帶來的問題！

10. 說說自己對 CAP 定理,BASE 理論的了解

CAP 定理

image.png

在理論計算機科學(xué)中奶赠，CAP定理（CAP theorem）药有，又被稱作布魯爾定理（Brewer's theorem），它指出對于一個分布式計算系統(tǒng)來說苇经，不可能同時滿足以下三點：

• 一致性（Consistence） :所有節(jié)點訪問同一份最新的數(shù)據(jù)副本
• 可用性（Availability）:每次請求都能獲取到非錯的響應(yīng)——但是不保證獲取的數(shù)據(jù)為最新數(shù)據(jù)
• 分區(qū)容錯性（Partition tolerance） : 分布式系統(tǒng)在遇到某節(jié)點或網(wǎng)絡(luò)分區(qū)故障的時候羊苟，仍然能夠?qū)ν馓峁M足一致性和可用性的服務(wù)蜡励。

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

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

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

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

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

BASE 理論

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

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

BASE理論三要素：

image.png

1. 基本可用： 基本可用是指分布式系統(tǒng)在出現(xiàn)不可預(yù)知故障的時候承绸，允許損失部分可用性。但是，這絕不等價于系統(tǒng)不可用荡澎。 比如： ①響應(yīng)時間上的損失:正常情況下晤锹，一個在線搜索引擎需要在0.5秒之內(nèi)返回給用戶相應(yīng)的查詢結(jié)果，但由于出現(xiàn)故障或衡，查詢結(jié)果的響應(yīng)時間增加了1~2秒车遂；②系統(tǒng)功能上的損失：正常情況下舶担，在一個電子商務(wù)網(wǎng)站上進行購物的時候，消費者幾乎能夠順利完成每一筆訂單柄瑰，但是在一些節(jié)日大促購物高峰的時候，由于消費者的購物行為激增蒲跨，為了保護購物系統(tǒng)的穩(wěn)定性授翻，部分消費者可能會被引導(dǎo)到一個降級頁面；
2. 軟狀態(tài)： 軟狀態(tài)指允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài)隆箩，并認為該中間狀態(tài)的存在不會影響系統(tǒng)的整體可用性捌臊，即允許系統(tǒng)在不同節(jié)點的數(shù)據(jù)副本之間進行數(shù)據(jù)同步的過程存在延時兜材；
3. 最終一致性： 最終一致性強調(diào)的是系統(tǒng)中所有的數(shù)據(jù)副本，在經(jīng)過一段時間的同步后糠爬，最終能夠達到一個一致的狀態(tài)举庶。因此户侥，最終一致性的本質(zhì)是需要系統(tǒng)保證最終數(shù)據(jù)能夠達到一致，而不需要實時保證系統(tǒng)數(shù)據(jù)的強一致性屋摔。

參考

• 《大型網(wǎng)站技術(shù)架構(gòu)》
• 《億級流量網(wǎng)站架構(gòu)核心技術(shù)》
• 《Java工程師修煉之道》
• https://www.cnblogs.com/puresoul/p/5456855.html