來(lái)自：JavaGuide(微信號(hào)：JavaGuide)

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

本文目錄：

• 1. 你使用過(guò)哪些組件或者方法來(lái)提升網(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. 性能測(cè)試了解嗎?說(shuō)說(shuō)你知道的性能測(cè)試工具?

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

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

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

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

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

• 10. 說(shuō)說(shuō)自己 CAP 定理,BASE 理論的了解

• CAP 定理

• BASE 理論

• 參考

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

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

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

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

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

數(shù)據(jù)庫(kù)分庫(kù)(讀寫(xiě)分離)、分表(水平分表、垂直分表)

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

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

瀏覽器緩存

使用合適的連接池(數(shù)據(jù)庫(kù)連接池、線(xiàn)程池等等)

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

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

降級(jí)：?服務(wù)降級(jí)是當(dāng)服務(wù)器壓力劇增的情況下，根據(jù)當(dāng)前業(yè)務(wù)情況及流量對(duì)一些服務(wù)和頁(yè)面有策略的降級(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ù)雖然有損但是總比沒(méi)有好；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我們通常把 Spring Cloud 理解為一系列開(kāi)源組件的集合，但是 Spring Cloud并不是等同于 Spring Cloud Netflix 的 Ribbon、Feign、Eureka(停止更新)、Hystrix 這一套組件，而是抽象了一套通用的開(kāi)發(fā)模式。它的目的是通過(guò)抽象出這套通用的模式，讓開(kāi)發(fā)者更快更好地開(kāi)發(fā)業(yè)務(wù)。但是這套開(kāi)發(fā)模式運(yùn)行時(shí)的實(shí)際載體，還是依賴(lài)于 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 是一套國(guó)產(chǎn)開(kāi)源產(chǎn)品集合，后續(xù)還會(huì)有中文 reference 和一些原理分析文章，所以，這對(duì)于國(guó)內(nèi)的開(kāi)發(fā)者是非常棒的一件事。阿里的這一舉動(dòng)勢(shì)必會(huì)推動(dòng)國(guó)內(nèi)微服務(wù)技術(shù)的發(fā)展，因?yàn)樵跊](méi)有 Spring Cloud Alibaba 之前，我們的第一選擇是 Spring Cloud Netflix，但是它們的文檔都是英文的，出問(wèn)題后排查也比較困難， 在國(guó)內(nèi)并不是有特別多的人精通。Spring Cloud Alibaba 由阿里開(kāi)源組件和阿里云產(chǎn)品組件兩部分組成，其致力于提供微服務(wù)一站式解決方案，方便開(kāi)發(fā)者通過(guò) Spring Cloud 編程模型輕松開(kāi)發(fā)微服務(wù)應(yīng)用。

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

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

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

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

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

6、性能測(cè)試了解嗎?說(shuō)說(shuō)你知道的性能測(cè)試工具?

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

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

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

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

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

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

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

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

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

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

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

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

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

8、大表優(yōu)化的常見(jiàn)手段

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

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

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

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

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

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

• 客戶(hù)端代理：?分片邏輯在應(yīng)用端，封裝在jar包中，通過(guò)修改或者封裝JDBC層來(lái)實(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)。

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

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

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

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

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

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

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

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

先來(lái)簡(jiǎn)單說(shuō)一下分布式服務(wù)：

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

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

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

我們最常見(jiàn)的事件驅(qū)動(dòng)架構(gòu)類(lèi)似生產(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)者)之間沒(méi)有直接耦合，消息發(fā)送者將消息發(fā)送至分布式消息隊(duì)列即結(jié)束對(duì)消息的處理，消息接受者從分布式消息隊(duì)列獲取該消息后進(jìn)行后續(xù)處理，并不需要知道該消息從何而來(lái)。對(duì)新增業(yè)務(wù)，只要對(duì)該類(lèi)消息感興趣，即可訂閱該消息，對(duì)原有系統(tǒng)和業(yè)務(wù)沒(méi)有任何影響，從而實(shí)現(xiàn)網(wǎng)站業(yè)務(wù)的可擴(kuò)展性設(shè)計(jì)。

消息接受者對(duì)消息進(jìn)行過(guò)濾、處理、包裝后，構(gòu)造成一個(gè)新的消息類(lèi)型，將消息繼續(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ā)布-訂閱模式工作，只不過(guò)在解耦這個(gè)特定業(yè)務(wù)環(huán)境下是使用發(fā)布-訂閱模式的，比如在我們的ActiveMQ消息隊(duì)列中還有點(diǎn)對(duì)點(diǎn)工作模式，具體的會(huì)在后面的文章給大家詳細(xì)介紹，這一篇文章主要還是讓大家對(duì)消息隊(duì)列有一個(gè)更透徹的了解。

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

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

CAP 定理

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

• 一致性(Consistence)?:所有節(jié)點(diǎn)訪(fǎng)問(wè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(mǎn)足一致性和可用性的服務(wù)。

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

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

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

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

我在網(wǎng)上找了很多文章想看一下有沒(méi)有文章提到這個(gè)不是所謂的3選2，用百度半天沒(méi)找到了一篇，用谷歌搜索找到一篇比較不錯(cuò)的，如果想深入學(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(最終一致性) 三個(gè)短語(yǔ)的縮寫(xiě)。BASE理論是對(duì)CAP中一致性和可用性權(quán)衡的結(jié)果，其來(lái)源于對(duì)大規(guī)模互聯(lián)網(wǎng)系統(tǒng)分布式實(shí)踐的總結(jié)，是基于CAP定理逐步演化而來(lái)的，它大大降低了我們對(duì)系統(tǒng)的要求。

BASE理論的核心思想： 即使無(wú)法做到強(qiáng)一致性，但每個(gè)應(yīng)用都可以根據(jù)自身業(yè)務(wù)特點(diǎn)，采用適當(dāng)?shù)姆绞絹?lái)使系統(tǒng)達(dá)到最終一致性。也就是犧牲數(shù)據(jù)的一致性來(lái)滿(mǎn)足系統(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è)在線(xiàn)搜索引擎需要在0.5秒之內(nèi)返回給用戶(hù)相應(yīng)的查詢(xún)結(jié)果，但由于出現(xiàn)故障，查詢(xún)結(jié)果的響應(yīng)時(shí)間增加了1~2秒；②系統(tǒng)功能上的損失：正常情況下，在一個(gè)電子商務(wù)網(wǎng)站上進(jìn)行購(gòu)物的時(shí)候，消費(fèi)者幾乎能夠順利完成每一筆訂單，但是在一些節(jié)日大促購(gòu)物高峰的時(shí)候，由于消費(fèi)者的購(gòu)物行為激增，為了保護(hù)購(gòu)物系統(tǒng)的穩(wěn)定性，部分消費(fèi)者可能會(huì)被引導(dǎo)到一個(gè)降級(jí)頁(yè)面；

軟狀態(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ù)同步的過(guò)程存在延時(shí)；

最終一致性：?最終一致性強(qiáng)調(diào)的是系統(tǒng)中所有的數(shù)據(jù)副本，在經(jīng)過(guò)一段時(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/puresoul/p/5456855.html

---

●編號(hào)746，輸入編號(hào)直達(dá)本文

●輸入m獲取文章目錄

推薦↓↓↓

前端開(kāi)發(fā)

更多推薦《25個(gè)技術(shù)類(lèi)公眾微信》

涵蓋：程序人生、算法與數(shù)據(jù)結(jié)構(gòu)、黑客技術(shù)與網(wǎng)絡(luò)安全、大數(shù)據(jù)技術(shù)、前端開(kāi)發(fā)、Java、Python、Web開(kāi)發(fā)、安卓開(kāi)發(fā)、iOS開(kāi)發(fā)、C/C++、.NET、Linux、數(shù)據(jù)庫(kù)、運(yùn)維等。

總結(jié)

以上是生活随笔為你收集整理的亿级流量网站架构核心技术_关于大型网站系统架构你不得不懂的10个问题的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。