面對(duì)千萬(wàn)級(jí)、億級(jí)流量怎么處理？

這是一道很常見的面試題，但是大多數(shù)人并不知道怎么回答，這種問(wèn)題其實(shí)可以有很多形式的提問(wèn)方式，你一定見過(guò)而且感覺無(wú)從下手：

面對(duì)業(yè)務(wù)急劇增長(zhǎng)你怎么處理？

業(yè)務(wù)量增長(zhǎng)10倍、100倍怎么處理？

你們系統(tǒng)怎么支撐高并發(fā)的？

怎么設(shè)計(jì)一個(gè)高并發(fā)系統(tǒng)？

高并發(fā)系統(tǒng)都有什么特點(diǎn)？

... ...

諸如此類，問(wèn)法很多，但是面試這種類型的問(wèn)題，看著很難無(wú)處下手，但是我們可以有一個(gè)常規(guī)的思路去回答，就是圍繞支撐高并發(fā)的業(yè)務(wù)場(chǎng)景怎么設(shè)計(jì)系統(tǒng)才合理？如果你能想到這一點(diǎn)，那接下來(lái)我們就可以圍繞硬件和軟件層面怎么支撐高并發(fā)這個(gè)話題去闡述了。本質(zhì)上，這個(gè)問(wèn)題就是綜合考驗(yàn)?zāi)銓?duì)各個(gè)細(xì)節(jié)是否知道怎么處理，是否有經(jīng)驗(yàn)處理過(guò)而已。

面對(duì)超高的并發(fā)，首先硬件層面機(jī)器要能扛得住，其次架構(gòu)設(shè)計(jì)做好微服務(wù)的拆分，代碼層面各種緩存、削峰、解耦等等問(wèn)題要處理好，數(shù)據(jù)庫(kù)層面做好讀寫分離、分庫(kù)分表，穩(wěn)定性方面要保證有監(jiān)控，熔斷限流降級(jí)該有的必須要有，發(fā)生問(wèn)題能及時(shí)發(fā)現(xiàn)處理。這樣從整個(gè)系統(tǒng)設(shè)計(jì)方面就會(huì)有一個(gè)初步的概念。

微服務(wù)架構(gòu)演化

在互聯(lián)網(wǎng)早期的時(shí)候，單體架構(gòu)就足以支撐起日常的業(yè)務(wù)需求，大家的所有業(yè)務(wù)服務(wù)都在一個(gè)項(xiàng)目里，部署在一臺(tái)物理機(jī)器上。所有的業(yè)務(wù)包括你的交易系統(tǒng)、會(huì)員信息、庫(kù)存、商品等等都夾雜在一起，當(dāng)流量一旦起來(lái)之后，單體架構(gòu)的問(wèn)題就暴露出來(lái)了，機(jī)器掛了所有的業(yè)務(wù)全部無(wú)法使用了。

于是，集群架構(gòu)的架構(gòu)開始出現(xiàn)，單機(jī)無(wú)法抗住的壓力，最簡(jiǎn)單的辦法就是水平拓展橫向擴(kuò)容了，這樣，通過(guò)負(fù)載均衡把壓力流量分?jǐn)偟讲煌臋C(jī)器上，暫時(shí)是解決了單點(diǎn)導(dǎo)致服務(wù)不可用的問(wèn)題。

但是隨著業(yè)務(wù)的發(fā)展，在一個(gè)項(xiàng)目里維護(hù)所有的業(yè)務(wù)場(chǎng)景使開發(fā)和代碼維護(hù)變得越來(lái)越困難，一個(gè)簡(jiǎn)單的需求改動(dòng)都需要發(fā)布整個(gè)服務(wù)，代碼的合并沖突也會(huì)變得越來(lái)越頻繁，同時(shí)線上故障出現(xiàn)的可能性越大。微服務(wù)的架構(gòu)模式就誕生了。

把每個(gè)獨(dú)立的業(yè)務(wù)拆分開獨(dú)立部署，開發(fā)和維護(hù)的成本降低，集群能承受的壓力也提高了，再也不會(huì)出現(xiàn)一個(gè)小小的改動(dòng)點(diǎn)需要牽一發(fā)而動(dòng)全身了。

以上的點(diǎn)從高并發(fā)的角度而言，似乎都可以歸類為通過(guò)服務(wù)拆分和集群物理機(jī)器的擴(kuò)展提高了整體的系統(tǒng)抗壓能力，那么，隨之拆分而帶來(lái)的問(wèn)題也就是高并發(fā)系統(tǒng)需要解決的問(wèn)題。

RPC

微服務(wù)化的拆分帶來(lái)的好處和便利性是顯而易見的，但是與此同時(shí)各個(gè)微服務(wù)之間的通信就需要考慮了。傳統(tǒng)HTTP的通信方式對(duì)性能是極大的浪費(fèi)，這時(shí)候就需要引入諸如Dubbo類的RPC框架，基于TCP長(zhǎng)連接的方式提高整個(gè)集群通信的效率。

我們假設(shè)原來(lái)來(lái)自客戶端的QPS是9000的話，那么通過(guò)負(fù)載均衡策略分散到每臺(tái)機(jī)器就是3000，而HTTP改為RPC之后接口的耗時(shí)縮短了，單機(jī)和整體的QPS就提升了。而RPC框架本身一般都自帶負(fù)載均衡、熔斷降級(jí)的機(jī)制，可以更好的維護(hù)整個(gè)系統(tǒng)的高可用性。

那么說(shuō)完RPC，作為基本上國(guó)內(nèi)普遍的選擇Dubbo的一些基本原理就是接下來(lái)的問(wèn)題。

Dubbo工作原理

1. 服務(wù)啟動(dòng)的時(shí)候，provider和consumer根據(jù)配置信息，連接到注冊(cè)中心register，分別向注冊(cè)中心注冊(cè)和訂閱服務(wù)

2. register根據(jù)服務(wù)訂閱關(guān)系，返回provider信息到consumer，同時(shí)consumer會(huì)把provider信息緩存到本地。如果信息有變更，consumer會(huì)收到來(lái)自register的推送

3. consumer生成代理對(duì)象，同時(shí)根據(jù)負(fù)載均衡策略，選擇一臺(tái)provider，同時(shí)定時(shí)向monitor記錄接口的調(diào)用次數(shù)和時(shí)間信息

4. 拿到代理對(duì)象之后，consumer通過(guò)代理對(duì)象發(fā)起接口調(diào)用

5. provider收到請(qǐng)求后對(duì)數(shù)據(jù)進(jìn)行反序列化，然后通過(guò)代理調(diào)用具體的接口實(shí)現(xiàn)

Dubbo負(fù)載均衡策略

1. 加權(quán)隨機(jī)：假設(shè)我們有一組服務(wù)器 servers = [A, B, C]，他們對(duì)應(yīng)的權(quán)重為 weights = [5, 3, 2]，權(quán)重總和為10?，F(xiàn)在把這些權(quán)重值平鋪在一維坐標(biāo)值上，[0, 5) 區(qū)間屬于服務(wù)器 A，[5, 8) 區(qū)間屬于服務(wù)器 B，[8, 10) 區(qū)間屬于服務(wù)器 C。接下來(lái)通過(guò)隨機(jī)數(shù)生成器生成一個(gè)范圍在 [0, 10) 之間的隨機(jī)數(shù)，然后計(jì)算這個(gè)隨機(jī)數(shù)會(huì)落到哪個(gè)區(qū)間上就可以了。

2. 最小活躍數(shù)：每個(gè)服務(wù)提供者對(duì)應(yīng)一個(gè)活躍數(shù) active，初始情況下，所有服務(wù)提供者活躍數(shù)均為0。每收到一個(gè)請(qǐng)求，活躍數(shù)加1，完成請(qǐng)求后則將活躍數(shù)減1。在服務(wù)運(yùn)行一段時(shí)間后，性能好的服務(wù)提供者處理請(qǐng)求的速度更快，因此活躍數(shù)下降的也越快，此時(shí)這樣的服務(wù)提供者能夠優(yōu)先獲取到新的服務(wù)請(qǐng)求。

3. 一致性hash：通過(guò)hash算法，把provider的invoke和隨機(jī)節(jié)點(diǎn)生成hash，并將這個(gè) hash 投射到 [0, 2^32 - 1] 的圓環(huán)上，查詢的時(shí)候根據(jù)key進(jìn)行md5然后進(jìn)行hash，得到第一個(gè)節(jié)點(diǎn)的值大于等于當(dāng)前hash的invoker。

4. 加權(quán)輪詢：比如服務(wù)器 A、B、C 權(quán)重比為 5:2:1，那么在8次請(qǐng)求中，服務(wù)器 A 將收到其中的5次請(qǐng)求，服務(wù)器 B 會(huì)收到其中的2次請(qǐng)求，服務(wù)器 C 則收到其中的1次請(qǐng)求。

集群容錯(cuò)

1. Failover Cluster失敗自動(dòng)切換：dubbo的默認(rèn)容錯(cuò)方案，當(dāng)調(diào)用失敗時(shí)自動(dòng)切換到其他可用的節(jié)點(diǎn)，具體的重試次數(shù)和間隔時(shí)間可用通過(guò)引用服務(wù)的時(shí)候配置，默認(rèn)重試次數(shù)為1也就是只調(diào)用一次。

2. Failback Cluster快速失?。涸谡{(diào)用失敗，記錄日志和調(diào)用信息，然后返回空結(jié)果給consumer，并且通過(guò)定時(shí)任務(wù)每隔5秒對(duì)失敗的調(diào)用進(jìn)行重試

3. Failfast Cluster失敗自動(dòng)恢復(fù)：只會(huì)調(diào)用一次，失敗后立刻拋出異常

4. Failsafe Cluster失敗安全：調(diào)用出現(xiàn)異常，記錄日志不拋出，返回空結(jié)果

5. Forking Cluster并行調(diào)用多個(gè)服務(wù)提供者：通過(guò)線程池創(chuàng)建多個(gè)線程，并發(fā)調(diào)用多個(gè)provider，結(jié)果保存到阻塞隊(duì)列，只要有一個(gè)provider成功返回了結(jié)果，就會(huì)立刻返回結(jié)果

6. Broadcast Cluster廣播模式：逐個(gè)調(diào)用每個(gè)provider，如果其中一臺(tái)報(bào)錯(cuò)，在循環(huán)調(diào)用結(jié)束后，拋出異常。

消息隊(duì)列

對(duì)于MQ的作用大家都應(yīng)該很了解了，削峰填谷、解耦。依賴消息隊(duì)列，同步轉(zhuǎn)異步的方式，可以降低微服務(wù)之間的耦合。

對(duì)于一些不需要同步執(zhí)行的接口，可以通過(guò)引入消息隊(duì)列的方式異步執(zhí)行以提高接口響應(yīng)時(shí)間。在交易完成之后需要扣庫(kù)存，然后可能需要給會(huì)員發(fā)放積分，本質(zhì)上，發(fā)積分的動(dòng)作應(yīng)該屬于履約服務(wù)，對(duì)實(shí)時(shí)性的要求也不高，我們只要保證最終一致性也就是能履約成功就行了。對(duì)于這種同類性質(zhì)的請(qǐng)求就可以走M(jìn)Q異步，也就提高了系統(tǒng)抗壓能力了。

對(duì)于消息隊(duì)列而言，怎么在使用的時(shí)候保證消息的可靠性、不丟失？

消息可靠性

消息丟失可能發(fā)生在生產(chǎn)者發(fā)送消息、MQ本身丟失消息、消費(fèi)者丟失消息3個(gè)方面。

生產(chǎn)者丟失

生產(chǎn)者丟失消息的可能點(diǎn)在于程序發(fā)送失敗拋異常了沒(méi)有重試處理，或者發(fā)送的過(guò)程成功但是過(guò)程中網(wǎng)絡(luò)閃斷MQ沒(méi)收到，消息就丟失了。

由于同步發(fā)送的一般不會(huì)出現(xiàn)這樣使用方式，所以我們就不考慮同步發(fā)送的問(wèn)題，我們基于異步發(fā)送的場(chǎng)景來(lái)說(shuō)。

異步發(fā)送分為兩個(gè)方式：異步有回調(diào)和異步無(wú)回調(diào)，無(wú)回調(diào)的方式，生產(chǎn)者發(fā)送完后不管結(jié)果可能就會(huì)造成消息丟失，而通過(guò)異步發(fā)送+回調(diào)通知+本地消息表的形式我們就可以做出一個(gè)解決方案。以下單的場(chǎng)景舉例。

1. 下單后先保存本地?cái)?shù)據(jù)和MQ消息表，這時(shí)候消息的狀態(tài)是發(fā)送中，如果本地事務(wù)失敗，那么下單失敗，事務(wù)回滾。
2. 下單成功，直接返回客戶端成功，異步發(fā)送MQ消息
3. MQ回調(diào)通知消息發(fā)送結(jié)果，對(duì)應(yīng)更新數(shù)據(jù)庫(kù)MQ發(fā)送狀態(tài)
4. JOB輪詢超過(guò)一定時(shí)間（時(shí)間根據(jù)業(yè)務(wù)配置）還未發(fā)送成功的消息去重試
5. 在監(jiān)控平臺(tái)配置或者JOB程序處理超過(guò)一定次數(shù)一直發(fā)送不成功的消息，告警，人工介入。

一般而言，對(duì)于大部分場(chǎng)景來(lái)說(shuō)異步回調(diào)的形式就可以了，只有那種需要完全保證不能丟失消息的場(chǎng)景我們做一套完整的解決方案。

MQ丟失

如果生產(chǎn)者保證消息發(fā)送到MQ，而MQ收到消息后還在內(nèi)存中，這時(shí)候宕機(jī)了又沒(méi)來(lái)得及同步給從節(jié)點(diǎn)，就有可能導(dǎo)致消息丟失。

比如RocketMQ：

RocketMQ分為同步刷盤和異步刷盤兩種方式，默認(rèn)的是異步刷盤，就有可能導(dǎo)致消息還未刷到硬盤上就丟失了，可以通過(guò)設(shè)置為同步刷盤的方式來(lái)保證消息可靠性，這樣即使MQ掛了，恢復(fù)的時(shí)候也可以從磁盤中去恢復(fù)消息。

比如Kafka也可以通過(guò)配置做到：

acks=all 只有參與復(fù)制的所有節(jié)點(diǎn)全部收到消息，才返回生產(chǎn)者成功。這樣的話除非所有的節(jié)點(diǎn)都掛了，消息才會(huì)丟失。
replication.factor=N,設(shè)置大于1的數(shù)，這會(huì)要求每個(gè)partion至少有2個(gè)副本
min.insync.replicas=N，設(shè)置大于1的數(shù)，這會(huì)要求leader至少感知到一個(gè)follower還保持著連接
retries=N，設(shè)置一個(gè)非常大的值，讓生產(chǎn)者發(fā)送失敗一直重試

雖然我們可以通過(guò)配置的方式來(lái)達(dá)到MQ本身高可用的目的，但是都對(duì)性能有損耗，怎樣配置需要根據(jù)業(yè)務(wù)做出權(quán)衡。

消費(fèi)者丟失

消費(fèi)者丟失消息的場(chǎng)景：消費(fèi)者剛收到消息，此時(shí)服務(wù)器宕機(jī)，MQ認(rèn)為消費(fèi)者已經(jīng)消費(fèi)，不會(huì)重復(fù)發(fā)送消息，消息丟失。

RocketMQ默認(rèn)是需要消費(fèi)者回復(fù)ack確認(rèn)，而kafka需要手動(dòng)開啟配置關(guān)閉自動(dòng)offset。

消費(fèi)方不返回ack確認(rèn)，重發(fā)的機(jī)制根據(jù)MQ類型的不同發(fā)送時(shí)間間隔、次數(shù)都不盡相同，如果重試超過(guò)次數(shù)之后會(huì)進(jìn)入死信隊(duì)列，需要手工來(lái)處理了。（Kafka沒(méi)有這些）

消息的最終一致性

事務(wù)消息可以達(dá)到分布式事務(wù)的最終一致性，事務(wù)消息就是MQ提供的類似XA的分布式事務(wù)能力。

半事務(wù)消息就是MQ收到了生產(chǎn)者的消息，但是沒(méi)有收到二次確認(rèn)，不能投遞的消息。

實(shí)現(xiàn)原理如下：

1. 生產(chǎn)者先發(fā)送一條半事務(wù)消息到MQ
2. MQ收到消息后返回ack確認(rèn)
3. 生產(chǎn)者開始執(zhí)行本地事務(wù)
4. 如果事務(wù)執(zhí)行成功發(fā)送commit到MQ，失敗發(fā)送rollback
5. 如果MQ長(zhǎng)時(shí)間未收到生產(chǎn)者的二次確認(rèn)commit或者rollback，MQ對(duì)生產(chǎn)者發(fā)起消息回查
6. 生產(chǎn)者查詢事務(wù)執(zhí)行最終狀態(tài)
7. 根據(jù)查詢事務(wù)狀態(tài)再次提交二次確認(rèn)

最終，如果MQ收到二次確認(rèn)commit，就可以把消息投遞給消費(fèi)者，反之如果是rollback，消息會(huì)保存下來(lái)并且在3天后被刪除。

數(shù)據(jù)庫(kù)

對(duì)于整個(gè)系統(tǒng)而言，最終所有的流量的查詢和寫入都落在數(shù)據(jù)庫(kù)上，數(shù)據(jù)庫(kù)是支撐系統(tǒng)高并發(fā)能力的核心。怎么降低數(shù)據(jù)庫(kù)的壓力，提升數(shù)據(jù)庫(kù)的性能是支撐高并發(fā)的基石。主要的方式就是通過(guò)讀寫分離和分庫(kù)分表來(lái)解決這個(gè)問(wèn)題。

對(duì)于整個(gè)系統(tǒng)而言，流量應(yīng)該是一個(gè)漏斗的形式。比如我們的日活用戶DAU有20萬(wàn)，實(shí)際可能每天來(lái)到提單頁(yè)的用戶只有3萬(wàn)QPS，最終轉(zhuǎn)化到下單支付成功的QPS只有1萬(wàn)。那么對(duì)于系統(tǒng)來(lái)說(shuō)讀是大于寫的，這時(shí)候可以通過(guò)讀寫分離的方式來(lái)降低數(shù)據(jù)庫(kù)的壓力。

讀寫分離也就相當(dāng)于數(shù)據(jù)庫(kù)集群的方式降低了單節(jié)點(diǎn)的壓力。而面對(duì)數(shù)據(jù)的急劇增長(zhǎng)，原來(lái)的單庫(kù)單表的存儲(chǔ)方式已經(jīng)無(wú)法支撐整個(gè)業(yè)務(wù)的發(fā)展，這時(shí)候就需要對(duì)數(shù)據(jù)庫(kù)進(jìn)行分庫(kù)分表了。針對(duì)微服務(wù)而言垂直的分庫(kù)本身已經(jīng)是做過(guò)的，剩下大部分都是分表的方案了。

水平分表

首先根據(jù)業(yè)務(wù)場(chǎng)景來(lái)決定使用什么字段作為分表字段(sharding_key)，比如我們現(xiàn)在日訂單1000萬(wàn)，我們大部分的場(chǎng)景來(lái)源于C端，我們可以用user_id作為sharding_key，數(shù)據(jù)查詢支持到最近3個(gè)月的訂單，超過(guò)3個(gè)月的做歸檔處理，那么3個(gè)月的數(shù)據(jù)量就是9億，可以分1024張表，那么每張表的數(shù)據(jù)大概就在100萬(wàn)左右。

比如用戶id為100，那我們都經(jīng)過(guò)hash(100)，然后對(duì)1024取模，就可以落到對(duì)應(yīng)的表上了。

分表后的ID唯一性

因?yàn)槲覀冎麈I默認(rèn)都是自增的，那么分表之后的主鍵在不同表就肯定會(huì)有沖突了。有幾個(gè)辦法考慮：

1. 設(shè)定步長(zhǎng)，比如1-1024張表我們分別設(shè)定1-1024的基礎(chǔ)步長(zhǎng)，這樣主鍵落到不同的表就不會(huì)沖突了。
2. 分布式ID，自己實(shí)現(xiàn)一套分布式ID生成算法或者使用開源的比如雪花算法這種
3. 分表后不使用主鍵作為查詢依據(jù)，而是每張表單獨(dú)新增一個(gè)字段作為唯一主鍵使用，比如訂單表訂單號(hào)是唯一的，不管最終落在哪張表都基于訂單號(hào)作為查詢依據(jù)，更新也一樣。

主從同步原理

1. master提交完事務(wù)后，寫入binlog
2. slave連接到master，獲取binlog
3. master創(chuàng)建dump線程，推送binglog到slave
4. slave啟動(dòng)一個(gè)IO線程讀取同步過(guò)來(lái)的master的binlog，記錄到relay log中繼日志中
5. slave再開啟一個(gè)sql線程讀取relay log事件并在slave執(zhí)行，完成同步
6. slave記錄自己的binglog

由于mysql默認(rèn)的復(fù)制方式是異步的，主庫(kù)把日志發(fā)送給從庫(kù)后不關(guān)心從庫(kù)是否已經(jīng)處理，這樣會(huì)產(chǎn)生一個(gè)問(wèn)題就是假設(shè)主庫(kù)掛了，從庫(kù)處理失敗了，這時(shí)候從庫(kù)升為主庫(kù)后，日志就丟失了。由此產(chǎn)生兩個(gè)概念。

全同步復(fù)制

主庫(kù)寫入binlog后強(qiáng)制同步日志到從庫(kù)，所有的從庫(kù)都執(zhí)行完成后才返回給客戶端，但是很顯然這個(gè)方式的話性能會(huì)受到嚴(yán)重影響。

半同步復(fù)制

和全同步不同的是，半同步復(fù)制的邏輯是這樣，從庫(kù)寫入日志成功后返回ACK確認(rèn)給主庫(kù)，主庫(kù)收到至少一個(gè)從庫(kù)的確認(rèn)就認(rèn)為寫操作完成。

緩存

緩存作為高性能的代表，在某些特殊業(yè)務(wù)可能承擔(dān)90%以上的熱點(diǎn)流量。對(duì)于一些活動(dòng)比如秒殺這種并發(fā)QPS可能幾十萬(wàn)的場(chǎng)景，引入緩存事先預(yù)熱可以大幅降低對(duì)數(shù)據(jù)庫(kù)的壓力，10萬(wàn)的QPS對(duì)于單機(jī)的數(shù)據(jù)庫(kù)來(lái)說(shuō)可能就掛了，但是對(duì)于如redis這樣的緩存來(lái)說(shuō)就完全不是問(wèn)題。

以秒殺系統(tǒng)舉例，活動(dòng)預(yù)熱商品信息可以提前緩存提供查詢服務(wù)，活動(dòng)庫(kù)存數(shù)據(jù)可以提前緩存，下單流程可以完全走緩存扣減，秒殺結(jié)束后再異步寫入數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)承擔(dān)的壓力就小的太多了。當(dāng)然，引入緩存之后就還要考慮緩存擊穿、雪崩、熱點(diǎn)一系列的問(wèn)題了。

熱key問(wèn)題

所謂熱key問(wèn)題就是，突然有幾十萬(wàn)的請(qǐng)求去訪問(wèn)redis上的某個(gè)特定key，那么這樣會(huì)造成流量過(guò)于集中，達(dá)到物理網(wǎng)卡上限，從而導(dǎo)致這臺(tái)redis的服務(wù)器宕機(jī)引發(fā)雪崩。

針對(duì)熱key的解決方案：

1. 提前把熱key打散到不同的服務(wù)器，降低壓力
2. 加入二級(jí)緩存，提前加載熱key數(shù)據(jù)到內(nèi)存中，如果redis宕機(jī)，走內(nèi)存查詢

緩存擊穿

緩存擊穿的概念就是單個(gè)key并發(fā)訪問(wèn)過(guò)高，過(guò)期時(shí)導(dǎo)致所有請(qǐng)求直接打到db上，這個(gè)和熱key的問(wèn)題比較類似，只是說(shuō)的點(diǎn)在于過(guò)期導(dǎo)致請(qǐng)求全部打到DB上而已。

解決方案：

1. 加鎖更新，比如請(qǐng)求查詢A，發(fā)現(xiàn)緩存中沒(méi)有，對(duì)A這個(gè)key加鎖，同時(shí)去數(shù)據(jù)庫(kù)查詢數(shù)據(jù)，寫入緩存，再返回給用戶，這樣后面的請(qǐng)求就可以從緩存中拿到數(shù)據(jù)了。
2. 將過(guò)期時(shí)間組合寫在value中，通過(guò)異步的方式不斷的刷新過(guò)期時(shí)間，防止此類現(xiàn)象。

緩存穿透

緩存穿透是指查詢不存在緩存中的數(shù)據(jù)，每次請(qǐng)求都會(huì)打到DB，就像緩存不存在一樣。

針對(duì)這個(gè)問(wèn)題，加一層布隆過(guò)濾器。布隆過(guò)濾器的原理是在你存入數(shù)據(jù)的時(shí)候，會(huì)通過(guò)散列函數(shù)將它映射為一個(gè)位數(shù)組中的K個(gè)點(diǎn)，同時(shí)把他們置為1。

這樣當(dāng)用戶再次來(lái)查詢A，而A在布隆過(guò)濾器值為0，直接返回，就不會(huì)產(chǎn)生擊穿請(qǐng)求打到DB了。

顯然，使用布隆過(guò)濾器之后會(huì)有一個(gè)問(wèn)題就是誤判，因?yàn)樗旧硎且粋€(gè)數(shù)組，可能會(huì)有多個(gè)值落到同一個(gè)位置，那么理論上來(lái)說(shuō)只要我們的數(shù)組長(zhǎng)度夠長(zhǎng)，誤判的概率就會(huì)越低，這種問(wèn)題就根據(jù)實(shí)際情況來(lái)就好了。

緩存雪崩

當(dāng)某一時(shí)刻發(fā)生大規(guī)模的緩存失效的情況，比如你的緩存服務(wù)宕機(jī)了，會(huì)有大量的請(qǐng)求進(jìn)來(lái)直接打到DB上，這樣可能導(dǎo)致整個(gè)系統(tǒng)的崩潰，稱為雪崩。雪崩和擊穿、熱key的問(wèn)題不太一樣的是，他是指大規(guī)模的緩存都過(guò)期失效了。

針對(duì)雪崩幾個(gè)解決方案：

1. 針對(duì)不同key設(shè)置不同的過(guò)期時(shí)間，避免同時(shí)過(guò)期
2. 限流，如果redis宕機(jī)，可以限流，避免同時(shí)刻大量請(qǐng)求打崩DB
3. 二級(jí)緩存，同熱key的方案。

穩(wěn)定性

熔斷

比如營(yíng)銷服務(wù)掛了或者接口大量超時(shí)的異常情況，不能影響下單的主鏈路，涉及到積分的扣減一些操作可以在事后做補(bǔ)救。

限流

對(duì)突發(fā)如大促秒殺類的高并發(fā)，如果一些接口不做限流處理，可能直接就把服務(wù)打掛了，針對(duì)每個(gè)接口的壓測(cè)性能的評(píng)估做出合適的限流尤為重要。

降級(jí)

熔斷之后實(shí)際上可以說(shuō)就是降級(jí)的一種，以熔斷的舉例來(lái)說(shuō)營(yíng)銷接口熔斷之后降級(jí)方案就是短時(shí)間內(nèi)不再調(diào)用營(yíng)銷的服務(wù)，等到營(yíng)銷恢復(fù)之后再調(diào)用。

預(yù)案

一般來(lái)說(shuō)，就算是有統(tǒng)一配置中心，在業(yè)務(wù)的高峰期也是不允許做出任何的變更的，但是通過(guò)配置合理的預(yù)案可以在緊急的時(shí)候做一些修改。

核對(duì)

針對(duì)各種分布式系統(tǒng)產(chǎn)生的分布式事務(wù)一致性或者受到攻擊導(dǎo)致的數(shù)據(jù)異常，非常需要核對(duì)平臺(tái)來(lái)做最后的兜底的數(shù)據(jù)驗(yàn)證。比如下游支付系統(tǒng)和訂單系統(tǒng)的金額做核對(duì)是否正確，如果收到中間人攻擊落庫(kù)的數(shù)據(jù)是否保證正確性。

總結(jié)

其實(shí)可以看到，怎么設(shè)計(jì)高并發(fā)系統(tǒng)這個(gè)問(wèn)題本身他是不難的，無(wú)非是基于你知道的知識(shí)點(diǎn)，從物理硬件層面到軟件的架構(gòu)、代碼層面的優(yōu)化，使用什么中間件來(lái)不斷提高系統(tǒng)的抗壓能力。但是這個(gè)問(wèn)題本身會(huì)帶來(lái)更多的問(wèn)題，微服務(wù)本身的拆分帶來(lái)了分布式事務(wù)的問(wèn)題，http、RPC框架的使用帶來(lái)了通信效率、路由、容錯(cuò)的問(wèn)題，MQ的引入帶來(lái)了消息丟失、積壓、事務(wù)消息、順序消息的問(wèn)題，緩存的引入又會(huì)帶來(lái)一致性、雪崩、擊穿的問(wèn)題，數(shù)據(jù)庫(kù)的讀寫分離、分庫(kù)分表又會(huì)帶來(lái)主從同步延遲、分布式ID、事務(wù)一致性的問(wèn)題，而為了解決這些問(wèn)題我們又要不斷的加入各種措施熔斷、限流、降級(jí)、離線核對(duì)、預(yù)案處理等等來(lái)防止和追溯這些問(wèn)題。

—————END—————

喜歡本文的朋友，歡迎關(guān)注公眾號(hào)?程序員小灰，收看更多精彩內(nèi)容

       

        

         

          

           

            

             

              
             
             

              點(diǎn)個(gè)[在看]，是對(duì)小灰最大的支持！