建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
你好呀，我是歪歪。
10年積累的網(wǎng)站設(shè)計(jì)制作、成都做網(wǎng)站經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶(hù)對(duì)網(wǎng)站的新想法和需求。提供各種問(wèn)題對(duì)應(yīng)的解決方案。讓選擇我們的客戶(hù)得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先網(wǎng)站設(shè)計(jì)后付款的網(wǎng)站建設(shè)流程，更有鐘樓免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。
是這樣的，前幾天有個(gè)讀者給我發(fā)消息，說(shuō)面試的時(shí)候遇到一個(gè)場(chǎng)景題：
他說(shuō)他當(dāng)時(shí)，一時(shí)間竟然找不到回答問(wèn)題的角度，感覺(jué)自己沒(méi)有回答到點(diǎn)子上。
我仔細(xì)想了一下，確實(shí)是感到這個(gè)問(wèn)題有一絲絲的奇怪，有一種讓人千言萬(wàn)語(yǔ)，又突然懵逼不知從何說(shuō)起的神奇力量。
為什么這么說(shuō)呢?
我們先讀題啊，仔細(xì)的讀一遍題，我給你翻譯一下。
如果線(xiàn)上 Redis 掛了。然后所有請(qǐng)求打到數(shù)據(jù)庫(kù)導(dǎo)致數(shù)據(jù)庫(kù)也掛了。
這是啥?
Redis 掛了，不就是緩存都沒(méi)了嗎?
緩存都沒(méi)了，不就是緩存雪崩了嗎?
緩存雪崩了，不就導(dǎo)致數(shù)據(jù)庫(kù)掛了嗎?
一提到“緩存雪崩”這四個(gè)字，緩存穿透、緩存擊穿這幾兄弟，是不是就立馬條件反射的出現(xiàn)在你的腦海里面了，還順帶著對(duì)應(yīng)的幾套解決方案。
然后就像背書(shū)似的，什么緩存全沒(méi)了，什么緩存沒(méi)有數(shù)據(jù)庫(kù)中有，什么緩存和數(shù)據(jù)庫(kù)中都沒(méi)有...
張口就是幾分鐘不帶停頓的。
另外關(guān)于緩存擊穿和緩存穿透，很多同學(xué)都會(huì)搞混。
你換一個(gè)記法，緩存戳穿、緩存戳透。
穿，只是穿過(guò)了緩存。
透，是直接干到底。
你細(xì)品，應(yīng)該就不會(huì)記混。
除了上面的“Redis 緩存三連擊”這一套八股文之外，還隱藏著另外一個(gè)八股文：
Redis 掛了，為什么掛了?怎么就掛了?是不是有單點(diǎn)問(wèn)題?
這不就是問(wèn)你 Redis 服務(wù)的高可用嗎?
說(shuō)到 Redis 的高可用，腦子里面必須馬上蹦出來(lái)主從、哨兵和集群吧?
想到這些了，張口又是幾分鐘不帶停頓的。
但是這幾分鐘的千言萬(wàn)語(yǔ)，馬上就被下面這個(gè)問(wèn)題給干懵逼了?
這時(shí)該怎么進(jìn)行恢復(fù)?
現(xiàn)在問(wèn)你怎么恢復(fù)，就是事中的事兒了。
你得先說(shuō)怎么恢復(fù)，再說(shuō)怎么預(yù)防。
你要是上來(lái)就回答前面說(shuō)的什么“緩存三連擊”、“高可用架構(gòu)”，還包括大多數(shù)同學(xué)能想到的多級(jí)緩存、限流措施、服務(wù)降級(jí)、熔斷機(jī)制，這些都有點(diǎn)牽強(qiáng)。
因?yàn)楫吘惯@些手段都是事前的預(yù)防措施，上來(lái)就說(shuō)這些背書(shū)痕跡比較明顯。
答肯定是要答的，從事中恢復(fù)過(guò)度到事前預(yù)防方案，而且重點(diǎn)就是事前預(yù)防，那么我們?cè)趺催^(guò)度的自然一點(diǎn)呢?
先說(shuō)事中怎么恢復(fù)，其實(shí)我覺(jué)得幾句話(huà)就說(shuō)完了。
服務(wù)掛了啊，老哥，還能怎么恢復(fù)，當(dāng)然是重啟服務(wù)啊。
站在運(yùn)維人員的角度，當(dāng)然優(yōu)先考慮是先把 Redis 和數(shù)據(jù)庫(kù)服務(wù)重新啟動(dòng)起來(lái)啦。
但是啟動(dòng)之前得先做個(gè)小操作，把流量摘掉，可以先把流量攔截在入口的地方，比如簡(jiǎn)單粗暴的通過(guò) Nginx 的配置把請(qǐng)求都轉(zhuǎn)到一個(gè)精心設(shè)計(jì)的錯(cuò)誤頁(yè)面，就是說(shuō)這么一個(gè)意思。
這樣做的目的是為了防止流量過(guò)大，直接把新啟動(dòng)的服務(wù)，啟動(dòng)一個(gè)打掛一個(gè)的情況出現(xiàn)。
要是啟動(dòng)起來(lái)又扛不住了，請(qǐng)?jiān)谛睦锬罘植际较到y(tǒng)三大利器：
不行就加錢(qián)，堆機(jī)器嘛。
要覺(jué)得堆機(jī)器沒(méi)啥技術(shù)含量，你就再?gòu)木彺骖A(yù)熱的角度答一個(gè)。
就是當(dāng) Redis 服務(wù)重新啟動(dòng)后，通過(guò)程序先放點(diǎn)已知的熱點(diǎn) key 進(jìn)去后，系統(tǒng)再對(duì)外提供服務(wù)，防止緩存擊穿的場(chǎng)景。
而且上面這一系列操作其實(shí)和開(kāi)發(fā)人員的關(guān)系不大，主要是運(yùn)維同學(xué)干的事兒。
開(kāi)發(fā)同學(xué)最多就是在設(shè)計(jì)服務(wù)的時(shí)候做到服務(wù)無(wú)狀態(tài)，以達(dá)到快速水平擴(kuò)容的目的。
至于怎么去快速水平擴(kuò)容，那是運(yùn)維同學(xué)的事兒，暫時(shí)不要去搶別人的飯碗。
答到這，你就可以用“但是”來(lái)過(guò)度到事前預(yù)防，開(kāi)始自己的表演了。
故作沉思的對(duì)面試官說(shuō)“but”了：
我覺(jué)得從技術(shù)方案的角度來(lái)說(shuō)，我們應(yīng)該做到事前預(yù)防。
這一切的問(wèn)題都是因?yàn)?Redis 崩了，也就是發(fā)生了緩存雪崩。
在高并發(fā)的情況下，除了緩存雪崩，我們還必須得考慮到緩存的擊穿、穿透問(wèn)題。
而且 Redis 為什么會(huì)崩了?是不是使用姿勢(shì)不對(duì)?是不是沒(méi)有保證高可用?
服務(wù)中是不是需要考慮限流或者熔斷機(jī)制，最大程度的保護(hù)程序的運(yùn)行?
或者我們是否應(yīng)該建立多級(jí)緩存的機(jī)制，防止 Redis 掛掉之后，大批流量直接打到 MySQL 服務(wù)導(dǎo)致數(shù)據(jù)庫(kù)的崩盤(pán)?
至此，“but”完成，答題的方向從事中恢復(fù)，轉(zhuǎn)向了事前預(yù)防，進(jìn)入了我們的強(qiáng)項(xiàng)，八股文專(zhuān)場(chǎng)，然后就可以開(kāi)始“背誦”了。
我這里簡(jiǎn)單的聊一下緩存問(wèn)題三連擊和 Redis 的高可用。
至于多級(jí)緩存，可以看看我之前發(fā)的這篇文章:《這波舒服了，落地多級(jí)緩存!》。
緩存擊穿
先說(shuō)一下緩存擊穿的概念。
緩存擊穿是指一個(gè)請(qǐng)求要訪(fǎng)問(wèn)的數(shù)據(jù)，緩存中沒(méi)有，但數(shù)據(jù)庫(kù)中有的情況。
這種情況一般來(lái)說(shuō)就是緩存過(guò)期了。
但是這時(shí)由于并發(fā)訪(fǎng)問(wèn)這個(gè)緩存的用戶(hù)特別多，這是一個(gè)熱點(diǎn) key，這么多用戶(hù)的請(qǐng)求同時(shí)過(guò)來(lái)，在緩存里面沒(méi)有取到數(shù)據(jù)，所以又同時(shí)去訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)取數(shù)據(jù)，引起數(shù)據(jù)庫(kù)流量激增，壓力瞬間增大，直接崩潰給你看。
所以一個(gè)數(shù)據(jù)有緩存，每次請(qǐng)求都從緩存中快速的返回了數(shù)據(jù)，但是某個(gè)時(shí)間點(diǎn)緩存失效了，某個(gè)請(qǐng)求在緩存中沒(méi)有請(qǐng)求到數(shù)據(jù)，這時(shí)候我們就說(shuō)這個(gè)請(qǐng)求就"擊穿"了緩存。
針對(duì)這個(gè)場(chǎng)景，對(duì)應(yīng)的解決方案一般來(lái)說(shuō)有三種。
第一個(gè)就是只放行一個(gè)請(qǐng)求到數(shù)據(jù)庫(kù)，然后做構(gòu)建緩存的操作。
多個(gè)請(qǐng)求只放行一個(gè)，怎么做?
就借助 Redis setNX 命令設(shè)置一個(gè)標(biāo)志位就行。設(shè)置成功的放行，設(shè)置失敗的就輪詢(xún)等待。
第二個(gè)解決方案就是后臺(tái)續(xù)命。
這個(gè)方案的思想就是，后臺(tái)開(kāi)一個(gè)定時(shí)任務(wù)，專(zhuān)門(mén)主動(dòng)更新即將過(guò)期的數(shù)據(jù)。
比如程序中設(shè)置 why 這個(gè)熱點(diǎn) key 的時(shí)候，同時(shí)設(shè)置了過(guò)期時(shí)間為 10 分鐘，那后臺(tái)程序在第 8 分鐘的時(shí)候，會(huì)去數(shù)據(jù)庫(kù)查詢(xún)數(shù)據(jù)并重新放到緩存中，同時(shí)再次設(shè)置緩存為 10 分鐘。
怎么樣，是不是有點(diǎn) Redisson 分布式鎖看門(mén)狗的味道?
我覺(jué)得思想是一脈相承的。
只是方案落地的時(shí)候，從代碼編寫(xiě)的角度來(lái)說(shuō)稍微麻煩了一點(diǎn)。
我曾經(jīng)也借助這個(gè)思想開(kāi)發(fā)過(guò)一個(gè)流水號(hào)系統(tǒng)。
大概是這樣的。
流水號(hào)系統(tǒng)，屬于非常關(guān)鍵的系統(tǒng)，為了降低數(shù)據(jù)庫(kù)異常對(duì)服務(wù)帶來(lái)的沖擊，所以服務(wù)啟動(dòng)后會(huì)就會(huì)為每種業(yè)務(wù)系統(tǒng)都預(yù)先在緩存中緩存 5000 個(gè)流水號(hào)。
然后后臺(tái) Job 定時(shí)檢查緩存中還剩下多少流水號(hào)，如果小于 1000 個(gè)，則再預(yù)先生成新的流水號(hào)，補(bǔ)充到緩存中，讓緩存中的流水號(hào)再次回到 5000 個(gè)。
這樣做的好處就是數(shù)據(jù)庫(kù)異常后，我至少保證還有 5000 個(gè)緩存可以保證上游業(yè)務(wù)，我有一定的時(shí)間去恢復(fù)數(shù)據(jù)庫(kù)。
這也算是一種后臺(tái)續(xù)命的思想。
第三個(gè)方法就簡(jiǎn)單了：永不過(guò)期。
緩存為什么會(huì)被擊穿，是不是因?yàn)樵O(shè)置了超時(shí)時(shí)間，然后被回收了?
那我不設(shè)置超時(shí)時(shí)間不就行了?
如果結(jié)合實(shí)際場(chǎng)景你用腳趾頭都能想到這個(gè) key 一定會(huì)是個(gè)熱點(diǎn) key，會(huì)有大量的請(qǐng)求來(lái)訪(fǎng)問(wèn)這個(gè)數(shù)據(jù)。而且這個(gè) key 對(duì)應(yīng)的 value 不會(huì)發(fā)生變化。
對(duì)于這樣的數(shù)據(jù)你還設(shè)置過(guò)期時(shí)間干什么?
直接放進(jìn)去，永不過(guò)期。
其實(shí)上面的后臺(tái)續(xù)命思想的最終體現(xiàn)是也是永不過(guò)期。
只是后臺(tái)續(xù)命的思想，會(huì)主動(dòng)更新緩存，適用于緩存會(huì)變的場(chǎng)景。會(huì)出現(xiàn)緩存不一致的情況，取決于你的業(yè)務(wù)場(chǎng)景能接受多長(zhǎng)時(shí)間的緩存不一致。
總之，具體情況，具體分析。
但是思路要清晰，最終方案都是常規(guī)方案的組合或者變種。
緩存穿透
那么啥又是緩存穿透呢?
緩存穿透是指一個(gè)請(qǐng)求要訪(fǎng)問(wèn)的數(shù)據(jù)，緩存和數(shù)據(jù)庫(kù)中都沒(méi)有，而用戶(hù)短時(shí)間、高密度的發(fā)起這樣的請(qǐng)求，每次都打到數(shù)據(jù)庫(kù)服務(wù)上，給數(shù)據(jù)庫(kù)造成了壓力。
一般來(lái)說(shuō)這樣的請(qǐng)求屬于惡意請(qǐng)求。
就比如說(shuō)，我這是一個(gè)技術(shù)公眾號(hào)，你明明知道我沒(méi)有，但是你非要來(lái)我這里買(mǎi)一瓶啤酒，惡意請(qǐng)求。
怎么解決呢?
兩個(gè)方案。
第一個(gè)緩存空對(duì)象。
就是在數(shù)據(jù)庫(kù)即使沒(méi)有查詢(xún)到數(shù)據(jù)，我們也把這次請(qǐng)求當(dāng)做 key 緩存起來(lái)，value 可以是 NULL。
下次同樣請(qǐng)求就會(huì)命中這個(gè) NULL，緩存層就處理了這個(gè)請(qǐng)求，不會(huì)對(duì)數(shù)據(jù)庫(kù)產(chǎn)生壓力。
這樣實(shí)現(xiàn)起來(lái)簡(jiǎn)單，開(kāi)發(fā)成本很低。
但這樣隨之而來(lái)的一個(gè)面試題必須要注意一下:
對(duì)于惡意攻擊，請(qǐng)求的時(shí)候key往往各不相同，且只請(qǐng)求一次，那你要把這些 key 都緩存起來(lái)的話(huà)，因?yàn)槊總€(gè) key 都只請(qǐng)求一次，那還是每次都會(huì)請(qǐng)求數(shù)據(jù)庫(kù)，沒(méi)有保護(hù)到數(shù)據(jù)庫(kù)呀?
這個(gè)問(wèn)題，布隆過(guò)濾器，了解一下?
關(guān)于布隆過(guò)濾器我之前寫(xiě)過(guò)這篇文章，可以看看：《布隆，牛逼!布谷鳥(niǎo)，牛逼!》
布隆過(guò)濾器的特性是說(shuō)某個(gè)值存在時(shí)，這個(gè)值可能不存在。當(dāng)它說(shuō)不存在時(shí)，那就肯定不存在。
所以可以基于這個(gè)特性，把已有數(shù)據(jù)都構(gòu)建到布隆過(guò)濾器里面去。
然后它可以幫忙擋住絕大部分的攻擊。
但是還有個(gè)比較容易忽視的連環(huán)炮問(wèn)題：
面試官：布隆過(guò)濾器容量有限且不支持刪除，隨著里面內(nèi)容的增加，誤判率就會(huì)隨之上升。請(qǐng)問(wèn)，這個(gè)問(wèn)題你們是怎么解決的?
也是兩個(gè)答題方向。
首先，不支持刪除的話(huà)，就換一個(gè)支持刪除的布隆過(guò)濾器的輪子咯。
比如我前面的文章中提到的布谷鳥(niǎo)過(guò)濾器。
或者就是提前重構(gòu)布隆過(guò)濾器。
比如在容量達(dá)到 50% 的時(shí)候，就申請(qǐng)一個(gè)新的更大的布隆過(guò)濾器來(lái)替換掉之前的過(guò)濾器。
只是需要注意的是，重建你得知道有那些數(shù)據(jù)需要進(jìn)行重建的，所以你得有個(gè)地方來(lái)記錄。
比如就是 Redis、數(shù)據(jù)庫(kù)，甚至內(nèi)存緩存都可以。
沒(méi)落地過(guò)沒(méi)關(guān)系，你底氣十足的回答就行了。
你要相信，面試官八成也沒(méi)落地過(guò)，你們看的說(shuō)不定都是同一份資料呢。
緩存雪崩
緩存雪崩是指緩存中大多數(shù)的數(shù)據(jù)在同一時(shí)間到達(dá)過(guò)期時(shí)間，而查詢(xún)數(shù)據(jù)量巨大，這時(shí)候，又是緩存中沒(méi)有，數(shù)據(jù)庫(kù)中有的情況了。
請(qǐng)求都打到數(shù)據(jù)庫(kù)上，引起數(shù)據(jù)庫(kù)流量激增，壓力瞬間增大，直接崩潰給你看。
和前面講的緩存擊穿不同的是，緩存擊穿指大量的請(qǐng)求并發(fā)查詢(xún)同一條數(shù)據(jù)。
緩存雪崩是不同數(shù)據(jù)都到了過(guò)期時(shí)間，導(dǎo)致這些數(shù)據(jù)在緩存中都查詢(xún)不到，
雪崩，還是用的很形象的。
防止雪崩的方案簡(jiǎn)單來(lái)說(shuō)就是錯(cuò)峰過(guò)期。
在設(shè)置 key 過(guò)期時(shí)間的時(shí)候，在加上一個(gè)短的隨機(jī)過(guò)期時(shí)間，這樣就能避免大量緩存在同一時(shí)間過(guò)期，引起的緩存雪崩。
如果發(fā)了雪崩，我們可以有服務(wù)降級(jí)、熔斷、限流手段來(lái)拒絕一些請(qǐng)求，保證服務(wù)的正常。
但是，這些對(duì)用戶(hù)體驗(yàn)是有一定影響的。假設(shè)我們的程序有這的邏輯，也是拿來(lái)兜底的，從用戶(hù)的角度來(lái)說(shuō)，是不希望走到這樣的邏輯中去。
所以，還是以預(yù)防雪崩為主。
最后還有一種雪崩，就是整個(gè) Redis 服務(wù)都掛了。
所以，接下來(lái)就要聊聊 Redis 服務(wù)的高可用架構(gòu)了。
Redis 高可用架構(gòu)
聊到 Redis 高可用架構(gòu)，大家基本上都能想到主從、哨兵、集群這三種模式。
主從結(jié)構(gòu)很簡(jiǎn)單，就不說(shuō)了，其弊端主要是出現(xiàn)故障的時(shí)候需要人工介入干預(yù)，需要人工介入的，就不是真正的高可用。
哨兵和集群這兩種是寫(xiě)在官網(wǎng)上的方案：
https://redis.io/topics/introduction
上面劃線(xiàn)的話(huà)翻譯過(guò)來(lái)就是：Redis 通過(guò) Redis 哨兵(Sentinel)和 Cluster 集群提供高可用性(high availability)。
其中，哨兵是官方推薦的高可用方案(official high availability solution)：
所以主要說(shuō)一下哨兵模式。
哨兵是用來(lái)管理多個(gè) Redis 服務(wù)器的，我從《Redis開(kāi)發(fā)與運(yùn)維》一書(shū)中，拍個(gè)照片給你看看：
它主要執(zhí)行三種類(lèi)型的任務(wù)：
- 監(jiān)控(Monitoring)： Sentinel 會(huì)不斷地檢查你的主服務(wù)器和從服務(wù)器是否運(yùn)作正常。
- 提醒(Notification)： 當(dāng)被監(jiān)控的某個(gè) Redis 服務(wù)器出現(xiàn)問(wèn)題時(shí)， Sentinel 可以通過(guò) API 向管理員或者其他應(yīng)用程序發(fā)送通知。
- 自動(dòng)故障遷移(Automatic failover)： 當(dāng)一個(gè)主服務(wù)器不能正常工作時(shí)， Sentinel 會(huì)開(kāi)始一次自動(dòng)故障遷移操作， 它會(huì)將失效主服務(wù)器的其中一個(gè)從服務(wù)器升級(jí)為新的主服務(wù)器， 并讓失效主服務(wù)器的其他從服務(wù)器改為復(fù)制新的主服務(wù)器; 當(dāng)客戶(hù)端試圖連接失效的主服務(wù)器時(shí)， 集群也會(huì)向客戶(hù)端返回新主服務(wù)器的地址， 使得集群可以使用新主服務(wù)器代替失效服務(wù)器。
哨兵其實(shí)也是一個(gè)分布式系統(tǒng)，我們可以運(yùn)行多個(gè)哨兵。
然后這些哨兵之間需要相互通氣，交流信息，通過(guò)投票來(lái)決定是否執(zhí)行自動(dòng)故障遷移，以及選擇哪個(gè)從服務(wù)器作為新的主服務(wù)器。
哨兵之間采用的協(xié)議是 gossip，是一種去中心化的協(xié)議，達(dá)成的是最終一致性，非常有意思，
另外，如果主節(jié)點(diǎn)掛了，哨兵到底通過(guò)什么規(guī)則選擇新的主節(jié)點(diǎn)，也就是選舉過(guò)程大致是怎么樣的，也偶現(xiàn)于面試環(huán)節(jié)。
我以前就被問(wèn)到過(guò)，幸好當(dāng)時(shí)背的熟練。
簡(jiǎn)單說(shuō)一下規(guī)則，無(wú)它，背誦就完事了：
在掛了的主節(jié)點(diǎn)下掛的從節(jié)點(diǎn)中，被標(biāo)記為主觀下線(xiàn)、已斷線(xiàn)、或者最后一次回復(fù) PING 命令的時(shí)間大于五秒鐘的從節(jié)點(diǎn)都沒(méi)有資格參與選舉。
在掛了的主節(jié)點(diǎn)下掛的從節(jié)點(diǎn)中，那些與掛了的主節(jié)點(diǎn)連接斷開(kāi)的時(shí)長(zhǎng)超過(guò) down-after 配置指定的時(shí)長(zhǎng)十倍的從節(jié)點(diǎn)都沒(méi)有資格參與選舉。
經(jīng)過(guò)上面這兩輪淘汰之后，剩下來(lái)的從服務(wù)器中，選出復(fù)制偏移量(replication offset)最大的那個(gè)從服務(wù)器作為新的主服務(wù)器。如果復(fù)制偏移量不可用，或者從服務(wù)器的復(fù)制偏移量相同，那么帶有最小運(yùn)行 ID 的那個(gè)從服務(wù)器成為新的主服務(wù)器。
其實(shí)執(zhí)行上面這些操作的，是一個(gè)哨兵。而我們的哨兵一般是三個(gè)以上，那么那個(gè)哨兵來(lái)執(zhí)行這些操作呢?
其實(shí)這個(gè)哨兵也是需要從多個(gè)哨兵中被選舉一個(gè)出來(lái)的，被選出來(lái)的這個(gè)哨兵就是領(lǐng)頭哨兵(leader Sentinel)。
選舉領(lǐng)頭哨兵的時(shí)候，采取的是 Raft 算法。
至于哨兵模式的搭建，一般來(lái)說(shuō)是運(yùn)維干的事兒。
但是網(wǎng)上的搭建教程很多，能自己跟著教程親自搭一波那就更好了。
相信我，搭建的過(guò)程中你一定會(huì)碰到各種各樣的問(wèn)題，而這些問(wèn)題就是你的收獲。
回到開(kāi)始
這一小節(jié)，我們回到最開(kāi)始的這個(gè)面試題：
其實(shí)看到這個(gè)問(wèn)題的時(shí)候，我就想到了老是被爆來(lái)爆去的微博。
剛好，這周又吃了一波吳某凡的瓜，當(dāng)時(shí)還正在看女排的直播，看到報(bào)道的時(shí)候，表情大概是這樣的：
周六的晚上基本上就是帶著這個(gè)表情瓜田里面上躥下跳的，真是太好吃了。
但是凡凡這一波，不知道是凡凡的流量不行了，還是微博的架構(gòu)經(jīng)受住了考驗(yàn)。
微博竟然還比較順滑，沒(méi)有出現(xiàn)大范圍的、非常明顯的服務(wù)掛掉的現(xiàn)象。
我印象中最近一次微博掛的死死的，就是鹿晗關(guān)曉彤那事了。
倒不是因?yàn)槲谊P(guān)注他們，而是我關(guān)注到了那天正在結(jié)婚的程序員。
要說(shuō)這位丁振凱同學(xué)也真是太慘了。
結(jié)婚的時(shí)候碰上鹿晗公布戀情。海外度假時(shí)撞上雙宋官宣。老婆待產(chǎn)的時(shí)候撞上華晨宇承認(rèn)和張碧晨未婚生有一女。
這次我去看了，表現(xiàn)比較淡定。應(yīng)該是在一手抱娃，一手?jǐn)U容，順便吃瓜。
當(dāng)年鹿晗這事，微博助手說(shuō)掛掉是因?yàn)閱螚l微博轉(zhuǎn)發(fā)、評(píng)論次數(shù)太多了。
這是不全面的，單純的轉(zhuǎn)發(fā)評(píng)論多，并不能壓垮大微博。而且鹿晗的那天微博應(yīng)該也不是他所以的微博中轉(zhuǎn)發(fā)評(píng)論最多的一條。
是因?yàn)檗D(zhuǎn)發(fā)、評(píng)論并發(fā)太高太高太高了，是我一輩子都接觸不到的瞬間流量。
吃瓜群眾也蜂擁而至，短時(shí)間內(nèi)同時(shí)在線(xiàn)迅速爆漲，把服務(wù)器干掉了：
關(guān)于這個(gè)問(wèn)題，我在知乎上看到一個(gè)評(píng)論，我覺(jué)得挺好的，搬運(yùn)截圖一下：
https://www.zhihu.com/question/66346687
你看，這個(gè)場(chǎng)景和面試官問(wèn)的問(wèn)題是不是有點(diǎn)相似?
強(qiáng)如微博，也是加了 1000 臺(tái)服務(wù)器來(lái)應(yīng)對(duì)這次流量洪峰。
所以，服務(wù)掛了怎么辦?
重啟。
重啟還不行怎么辦?
加錢(qián)，擴(kuò)機(jī)器。
要是鹿晗關(guān)曉彤事件，著名狗仔卓偉能提前爆個(gè)料，打個(gè)提前量。
也許，微博就能抵抗的住那一波流量洪峰。
要是吳簽這事，北京警方能和微博提前通通氣，在發(fā)布之前先通知一下微博的相關(guān)人員，哪怕提前10分鐘呢?
也許，就有更多的人能順暢絲滑的吃瓜。
網(wǎng)站標(biāo)題：Redis掛了，流量把數(shù)據(jù)庫(kù)也打掛了，怎么辦？
網(wǎng)站網(wǎng)址：http://www.5511xx.com/article/dhogdoo.html
