国产一级a片免费看高清,亚洲熟女中文字幕在线视频,黄三级高清在线播放,免费黄色视频在线看

上一篇文章 億級(jí)流量系統(tǒng)架構(gòu)之如何在上萬(wàn)并發(fā)場(chǎng)景下設(shè)計(jì)可擴(kuò)展架構(gòu)（上），給大家初步講述了一套大規(guī)模復(fù)雜系統(tǒng)中，兩個(gè)核心子系統(tǒng)之間一旦耦合，會(huì)發(fā)生哪些令人崩潰的場(chǎng)景。如果還沒(méi)看上篇文章的，建議先看一下。

這篇文章，咱們就給大家來(lái)說(shuō)一說(shuō)通過(guò)MQ消息中間件的使用，如何重構(gòu)系統(tǒng)之間的耦合，讓系統(tǒng)具備高度的可擴(kuò)展性。

首先來(lái)回看一下之前畫(huà)的一張兩個(gè)系統(tǒng)之間進(jìn)行耦合的一個(gè)大圖，從這個(gè)圖里我們可以看到兩個(gè)系統(tǒng)完全通過(guò)一套共享存儲(chǔ)（數(shù)據(jù)庫(kù)集群+緩存集群）進(jìn)行了耦合。

只要有耦合，一旦要解決耦合，那么第一個(gè)要干的事兒就是先劃分清楚系統(tǒng)之間的邊界。

比如上面那兩套系統(tǒng)都共享了一套存儲(chǔ)集群，那么大家可以先思考一下，兩個(gè)系統(tǒng)之間的邊界應(yīng)該如何劃分？也就是說(shuō)，中間那套緩存集群和數(shù)據(jù)庫(kù)集群，到底應(yīng)該是屬于哪個(gè)系統(tǒng)？

首先我們看一下，緩存集群和數(shù)據(jù)庫(kù)集群主要是給誰(shuí)用的？

很明顯就是給數(shù)據(jù)查詢平臺(tái)用的，說(shuō)白了，那兩套集群都是數(shù)據(jù)查詢平臺(tái)賴以生存的核心底層數(shù)據(jù)存儲(chǔ)，這里存儲(chǔ)的數(shù)據(jù)也都是屬于數(shù)據(jù)查詢平臺(tái)的核心數(shù)據(jù)。

對(duì)于實(shí)時(shí)計(jì)算平臺(tái)來(lái)說(shuō)，他只不過(guò)是將自己計(jì)算后的結(jié)果寫(xiě)入到緩存集群和數(shù)據(jù)庫(kù)集群罷了。

實(shí)時(shí)計(jì)算平臺(tái)只要寫(xiě)入過(guò)后，后續(xù)就不會(huì)再管那些數(shù)據(jù)了，所以這兩套集群明顯是不屬于實(shí)時(shí)計(jì)算平臺(tái)的。

好，那么系統(tǒng)之間的邊界就很清晰的劃分清楚了，大家看一下如下的圖。首先從系統(tǒng)整體架構(gòu)的架構(gòu)而言，兩套系統(tǒng)之間的關(guān)系應(yīng)該是下面這樣子的。

只要?jiǎng)澐智宄讼到y(tǒng)之間的邊界，接著下一步，就是引入消息中間件來(lái)進(jìn)行解耦了。

如果大家對(duì)消息中間件的使用場(chǎng)景還不太熟悉的，可以參考之前的一篇文章：哥們，你們的系統(tǒng)架構(gòu)中為什么要引入消息中間件？這篇文章里面，對(duì)消息中間件的各種使用場(chǎng)景都有說(shuō)明。

我們只要引入一個(gè)消息中間件，然后讓實(shí)時(shí)計(jì)算平臺(tái)將計(jì)算好的數(shù)據(jù)按照預(yù)設(shè)的格式直接寫(xiě)入到消息中間件即可。

同時(shí)，數(shù)據(jù)查詢平臺(tái)需要增加一個(gè)數(shù)據(jù)接入服務(wù)，這個(gè)數(shù)據(jù)接入服務(wù)就是負(fù)責(zé)將消息中間件里的數(shù)據(jù)消費(fèi)出來(lái)，然后落地寫(xiě)入到本地的緩存集群和數(shù)據(jù)庫(kù)集群。

如上圖所示，此時(shí)兩個(gè)系統(tǒng)之間已經(jīng)不再直接基于共享數(shù)據(jù)存儲(chǔ)進(jìn)行耦合了，中間加入了MQ消息中間件。

這個(gè)消息中間件僅僅就是用于兩個(gè)系統(tǒng)之間的數(shù)據(jù)交互和傳輸，職責(zé)簡(jiǎn)單，清晰明了。

這樣做最大的好處，就是數(shù)據(jù)查詢平臺(tái)自身可以對(duì)涌入自身平臺(tái)的數(shù)據(jù)按照自己的需求進(jìn)行定制化的管控了，不會(huì)像之前那樣的被動(dòng)。

實(shí)際上在上述架構(gòu)之下，涌入數(shù)據(jù)查詢平臺(tái)的所有數(shù)據(jù)，都需要經(jīng)過(guò)數(shù)據(jù)接入服務(wù)那一關(guān)。在數(shù)據(jù)接入服務(wù)那里就可以隨意根據(jù)自己的情況進(jìn)行管理。

還記得上一篇文章我們提到，這兩個(gè)系統(tǒng)之間第一個(gè)大痛點(diǎn)，就是實(shí)時(shí)計(jì)算平臺(tái)會(huì)高并發(fā)寫(xiě)入數(shù)據(jù)查詢平臺(tái)，之前不做任何管控的時(shí)候，導(dǎo)致各種意外發(fā)生。

舉個(gè)例子，比如快速增長(zhǎng)的寫(xiě)庫(kù)壓力導(dǎo)致數(shù)據(jù)查詢平臺(tái)必須優(yōu)先cover住分庫(kù)分表那塊的架構(gòu)，打破自己的架構(gòu)演進(jìn)節(jié)奏；

比如突然意外出現(xiàn)的熱數(shù)據(jù)因?yàn)椴蛔鋈魏螌?xiě)入管控，一下子差點(diǎn)把數(shù)據(jù)庫(kù)服務(wù)器擊垮。

因此一旦用消息中間件在中間擋了一層之后，我們就可以進(jìn)行削峰填谷了。

那什么叫做削峰填谷呢？其實(shí)很簡(jiǎn)單，我們先來(lái)看看，如果不做任何管控，實(shí)時(shí)計(jì)算平臺(tái)寫(xiě)入數(shù)據(jù)庫(kù)集群的寫(xiě)并發(fā)曲線圖，大概如下面所示。

在高峰期，寫(xiě)入會(huì)有一個(gè)陡然上升的尖峰。

就好比說(shuō)，平時(shí)每秒寫(xiě)入并發(fā)就500，但是高峰期寫(xiě)入并發(fā)請(qǐng)求有5000，那么大家就會(huì)看到上面的那張圖，在高峰期突然冒出來(lái)一個(gè)尖峰，一下子涌入并發(fā)5000請(qǐng)求，此時(shí)數(shù)據(jù)查詢平臺(tái)的數(shù)據(jù)庫(kù)集群可能就會(huì)受不了。

但是，如果我們?cè)跀?shù)據(jù)接入服務(wù)里做一個(gè)限流控制呢？

也就是說(shuō)，在數(shù)據(jù)接入服務(wù)里，根據(jù)當(dāng)前數(shù)據(jù)查詢平臺(tái)的數(shù)據(jù)庫(kù)集群能承載的并發(fā)上限，比如說(shuō)就是最多承載每秒3000。

好！那么數(shù)據(jù)接入服務(wù)自己就控制好，每秒最多就往自己本地的數(shù)據(jù)庫(kù)集群里寫(xiě)入最多每秒3000的請(qǐng)求壓力。

此時(shí)就會(huì)出現(xiàn)削峰填谷的效果，大家看下面的圖。

因?yàn)樵诟叻迤谒矔r(shí)寫(xiě)入壓力最大有5000/s，但是數(shù)據(jù)接入服務(wù)做了流量控制，最多就往本地?cái)?shù)據(jù)庫(kù)集群寫(xiě)入3000/s，那么每秒就會(huì)有2000條數(shù)據(jù)在消息中間件里做一個(gè)積壓。

但是積壓一會(huì)兒不要緊，最起碼保證說(shuō)在高峰期，這個(gè)向上的尖峰被削平了，這就是所謂的削峰。

然后在高峰期過(guò)了之后，本來(lái)每秒可能就100/s的寫(xiě)入壓力，但是此時(shí)數(shù)據(jù)接入服務(wù)會(huì)持續(xù)不斷的從消息中間件里取出來(lái)數(shù)據(jù)然后持續(xù)以最大3000/s的寫(xiě)入壓力往本地?cái)?shù)據(jù)庫(kù)集群里寫(xiě)入。

那么在低峰期，大家看到還會(huì)持續(xù)一段時(shí)間是3000/s的寫(xiě)入速度往本地?cái)?shù)據(jù)庫(kù)里寫(xiě)。

原來(lái)的圖里在低峰期是谷底，現(xiàn)在谷底被填平了，這就是所謂的填谷。

通過(guò)這套削峰填谷的機(jī)制，就可以保證數(shù)據(jù)查詢平臺(tái)完全能夠以自己接受的了的速率，均勻的把MQ里的數(shù)據(jù)拿出來(lái)寫(xiě)入自己本地?cái)?shù)據(jù)庫(kù)集群中。

這樣子無(wú)論實(shí)時(shí)計(jì)算平臺(tái)多高的并發(fā)請(qǐng)求壓力過(guò)來(lái)，哪怕是那種異常的熱數(shù)據(jù)，瞬間上萬(wàn)并發(fā)請(qǐng)求過(guò)來(lái)也無(wú)所謂了。

因?yàn)镸Q中間件可以抗住瞬間高并發(fā)寫(xiě)入，但是數(shù)據(jù)查詢平臺(tái)永遠(yuǎn)都是穩(wěn)定勻速的寫(xiě)入自己本地?cái)?shù)據(jù)庫(kù)。

這樣的話，數(shù)據(jù)查詢平臺(tái)就不需要去過(guò)多的care實(shí)時(shí)計(jì)算平臺(tái)帶給自己的壓力了，可以按照自己的節(jié)奏規(guī)劃好整體架構(gòu)的演進(jìn)策略，按照自己的腳本去迭代架構(gòu)。

說(shuō)了那么多，老規(guī)矩！給大家來(lái)一張圖，此時(shí)的架構(gòu)圖如下所示。

大伙兒可以直觀的感受一下，在數(shù)據(jù)接入服務(wù)中多了一個(gè)限流的模塊。

現(xiàn)在基于消息中間件將兩個(gè)系統(tǒng)隔離開(kāi)來(lái)之后，另外一個(gè)大的好處就是：數(shù)據(jù)查詢平臺(tái)做任何數(shù)據(jù)運(yùn)維的操作，比如說(shuō)DDL、分庫(kù)分表擴(kuò)容、數(shù)據(jù)遷移，等等諸如此類的操作，已經(jīng)跟實(shí)時(shí)計(jì)算平臺(tái)徹底無(wú)關(guān)了。

實(shí)時(shí)計(jì)算平臺(tái)主要就是簡(jiǎn)單的往消息中間件寫(xiě)入，其他的就不用管了。

然后如果數(shù)據(jù)查詢平臺(tái)要做一些數(shù)據(jù)庫(kù)運(yùn)維的操作，此時(shí)就可以通過(guò)在數(shù)據(jù)接入服務(wù)中加入一個(gè)手動(dòng)流量開(kāi)關(guān)，臨時(shí)將流量開(kāi)關(guān)關(guān)閉一會(huì)兒。

比如選擇一個(gè)下午大家都在工作或者午睡的時(shí)候，相對(duì)低峰的時(shí)期，半小時(shí)內(nèi)關(guān)閉流量開(kāi)關(guān)。

然后此時(shí)數(shù)據(jù)接入服務(wù)就不會(huì)繼續(xù)往本地?cái)?shù)據(jù)庫(kù)寫(xiě)入數(shù)據(jù)了，此時(shí)寫(xiě)入操作就會(huì)停止，然后就在半小時(shí)內(nèi)迅速完成數(shù)據(jù)庫(kù)運(yùn)維操作。

等相關(guān)操作完成之后，再次打開(kāi)流量開(kāi)關(guān)，繼續(xù)從MQ里消費(fèi)數(shù)據(jù)再快速寫(xiě)入到本地?cái)?shù)據(jù)庫(kù)內(nèi)即可。

這樣，就可以完全避免了同時(shí)寫(xiě)入數(shù)據(jù)，還同時(shí)進(jìn)行數(shù)據(jù)庫(kù)運(yùn)維操作的窘境。否則在早期耦合的狀態(tài)下，每次進(jìn)行數(shù)據(jù)庫(kù)運(yùn)維操作，還得實(shí)時(shí)計(jì)算平臺(tái)團(tuán)隊(duì)的同學(xué)配合一起進(jìn)行各種復(fù)雜操作，才能避免線上出現(xiàn)故障，現(xiàn)在完全不需要人家的參與了，自己團(tuán)隊(duì)就可以搞定。

整個(gè)過(guò)程，我們還是用一張圖，給大家呈現(xiàn)一下：

引入消息中間件之后，還有另外一個(gè)好處，就是其他的一些系統(tǒng)也可以按照自己的需要去MQ里訂閱實(shí)時(shí)計(jì)算平臺(tái)計(jì)算好的數(shù)據(jù)。

舉個(gè)例子，在這套平臺(tái)里，還有數(shù)據(jù)質(zhì)量監(jiān)控系統(tǒng)，需要獲取計(jì)算數(shù)據(jù)進(jìn)行數(shù)據(jù)結(jié)果準(zhǔn)確性和質(zhì)量的監(jiān)控。

另外，還有數(shù)據(jù)鏈路監(jiān)控系統(tǒng)，同樣需要將MQ里的數(shù)據(jù)作為數(shù)據(jù)計(jì)算鏈路中的一個(gè)核心點(diǎn)數(shù)據(jù)采集過(guò)來(lái)，進(jìn)行數(shù)據(jù)全鏈路的監(jiān)控和自動(dòng)追蹤。

如果沒(méi)有引入MQ消息中間件概念的話，那么是不是就會(huì)導(dǎo)致實(shí)時(shí)計(jì)算平臺(tái)除了將數(shù)據(jù)寫(xiě)入一份到數(shù)據(jù)庫(kù)集群，還需要通過(guò)接口發(fā)送給數(shù)據(jù)質(zhì)量監(jiān)控系統(tǒng)？還需要發(fā)送給數(shù)據(jù)鏈路監(jiān)控系統(tǒng)？這樣簡(jiǎn)直是坑爹到不行，N個(gè)系統(tǒng)全部耦合在一起。

之前的文章《哥們，你們的系統(tǒng)架構(gòu)中為什么要引入消息中間件？》就闡述了這種多系統(tǒng)訂閱同一份數(shù)據(jù)，但是通過(guò)接口調(diào)用耦合在一起的窘境。

這樣每次要是有一點(diǎn)變動(dòng)，各個(gè)系統(tǒng)的負(fù)責(zé)人都在一起開(kāi)會(huì)商討，修改代碼，修改接口，考慮各種調(diào)用細(xì)節(jié)，等等。

但是現(xiàn)在有了消息中間件，完全可以通過(guò)MQ支持的“Pub/Sub”消息訂閱模型，不同的系統(tǒng)都可以來(lái)訂閱同一份數(shù)據(jù)，大家自己按需消費(fèi)，按需處理，各個(gè)系統(tǒng)之間完全解耦。

整個(gè)系統(tǒng)的可擴(kuò)展性瞬間提升了很多，因?yàn)楦鱾€(gè)系統(tǒng)各自迭代和演進(jìn)架構(gòu)，都不需要強(qiáng)依賴其他的系統(tǒng)了。

云開(kāi)霧散！各個(gè)團(tuán)隊(duì)的同學(xué)終于不用天天扯皮，今天說(shuō)你的系統(tǒng)影響了我，明天是我的系統(tǒng)影響了你。

同時(shí)也壓根兒不用去關(guān)注其他的系統(tǒng)，只要有一個(gè)總架構(gòu)師把控好整體架構(gòu)，各個(gè)team都按照這個(gè)分工協(xié)作來(lái)做即可。

消息中間件的引入，消除了系統(tǒng)的耦合性，大幅度提升了系統(tǒng)的可擴(kuò)展性，各個(gè)team都可以快速的獨(dú)立的迭代擴(kuò)展自己的架構(gòu)和系統(tǒng)。

PS：最重要的，不同team的同學(xué)，再也不用為了一些雞毛蒜皮的事兒加班到深更半夜，導(dǎo)致他們的女朋友覺(jué)得他們要在一起了。。。

下一篇文章，是關(guān)于可擴(kuò)展架構(gòu)的最后一篇。我們把整體架構(gòu)梳理完畢了之后，就可以來(lái)看一看具體到MQ消息中間件的層面，他是怎么通過(guò)“Pub/Sub”的訂閱模型，讓一份數(shù)據(jù)發(fā)布出去，然后讓多個(gè)不同的系統(tǒng)來(lái)訂閱同一份數(shù)據(jù)的。

敬請(qǐng)期待：

• 億級(jí)流量系統(tǒng)架構(gòu)之如何在上萬(wàn)并發(fā)場(chǎng)景下設(shè)計(jì)可擴(kuò)展架構(gòu)（下）

END