|
之前更新過(guò)一個(gè)“億級(jí)流量系統(tǒng)架構(gòu)”系列，主要講述了一個(gè)大規(guī)模商家數(shù)據(jù)平臺(tái)的如下幾個(gè)方面：
接下來(lái)，我們將會(huì)繼續(xù)通過(guò)幾篇文章，對(duì)這套系統(tǒng)的可擴(kuò)展架構(gòu)、數(shù)據(jù)一致性保障等方面進(jìn)行探討。 如果沒看過(guò)本系列文章的同學(xué)可以先回過(guò)頭看看之前寫的幾篇文章：  億級(jí)流量系統(tǒng)架構(gòu) 如果大家看過(guò)之前的一系列文章，應(yīng)該依稀還記得上一篇文章最后，整個(gè)系統(tǒng)架構(gòu)大致演進(jìn)到了如下圖的一個(gè)狀態(tài)。 如果沒看過(guò)之前的系列文章，上來(lái)猛一看下面這個(gè)圖，絕對(duì)一臉懵逼，就看到一片“花花綠綠”。這個(gè)也沒辦法，復(fù)雜的系統(tǒng)架構(gòu)都是特別的龐雜的。 好，咱們正式開始！這篇文章咱們來(lái)聊聊這套系統(tǒng)里的不同子系統(tǒng)之間通信過(guò)程的一個(gè)可擴(kuò)展性的架構(gòu)處理。 這里面蘊(yùn)含了線上復(fù)雜系統(tǒng)之間交互的真實(shí)場(chǎng)景和痛點(diǎn)，相信對(duì)大家能夠有所啟發(fā)。 我們就關(guān)注一下上面的架構(gòu)圖里左側(cè)的部分，處于中間位置的那個(gè)實(shí)時(shí)計(jì)算平臺(tái)在完成了每一個(gè)數(shù)據(jù)分片的計(jì)算過(guò)后，都會(huì)將計(jì)算結(jié)果寫入到最左側(cè)的數(shù)據(jù)查詢平臺(tái)中。 出于種種考量，因?yàn)橛?jì)算結(jié)果的數(shù)據(jù)量相比于原始數(shù)據(jù)的數(shù)據(jù)量，實(shí)際上已經(jīng)少了一個(gè)數(shù)量級(jí)了。 所以，我們選擇的是實(shí)時(shí)計(jì)算平臺(tái)直接將數(shù)據(jù)寫入到數(shù)據(jù)查詢平臺(tái)的MySQL數(shù)據(jù)庫(kù)集群中，然后數(shù)據(jù)查詢平臺(tái)基于MySQL數(shù)據(jù)庫(kù)集群來(lái)對(duì)外提供查詢請(qǐng)求。 此外，為了保證當(dāng)天的實(shí)時(shí)計(jì)算結(jié)果能夠高并發(fā)的被用戶查詢，因此當(dāng)時(shí)采取的是實(shí)時(shí)計(jì)算平臺(tái)的計(jì)算結(jié)果同時(shí)雙寫緩存集群和數(shù)據(jù)庫(kù)集群。 這樣，數(shù)據(jù)查詢平臺(tái)可以優(yōu)先走緩存集群，如果找不到緩存才會(huì)從數(shù)據(jù)庫(kù)集群里回查數(shù)據(jù)。 所以上述就是實(shí)時(shí)計(jì)算平臺(tái)與數(shù)據(jù)查詢平臺(tái)之間在某一個(gè)時(shí)期的一個(gè)典型的系統(tǒng)耦合架構(gòu)。 兩個(gè)不同的系統(tǒng)之間，通過(guò)同一套數(shù)據(jù)存儲(chǔ)（數(shù)據(jù)庫(kù)集群+緩存集群）進(jìn)行了耦合。 大家看看下面的圖，再來(lái)清晰的感受一下系統(tǒng)之間耦合的感覺。 系統(tǒng)耦合痛點(diǎn)1：被動(dòng)承擔(dān)的高并發(fā)寫入壓力  大家如果仔細(xì)看過(guò)之前的系列文章，大概就該知道，在早期主要是集中精力對(duì)實(shí)時(shí)計(jì)算平臺(tái)的架構(gòu)做了大量的演進(jìn)，以便于讓他可以支撐超高并發(fā)寫入、海量數(shù)據(jù)的超高性能計(jì)算，最后就可以抗住每秒數(shù)萬(wàn)甚至數(shù)十萬(wàn)的數(shù)據(jù)涌入的存儲(chǔ)和計(jì)算。 但是因?yàn)樵缙诓捎昧松蠄D的這種最簡(jiǎn)單、最高效、最實(shí)用的耦合交互方式，實(shí)時(shí)計(jì)算平臺(tái)直接把每個(gè)數(shù)據(jù)分片計(jì)算完的結(jié)果寫入共享存儲(chǔ)中，就導(dǎo)致了一個(gè)很大的問(wèn)題。 實(shí)時(shí)計(jì)算平臺(tái)能抗住超高并發(fā)寫入沒問(wèn)題了，而且還能快速的高性能計(jì)算也沒問(wèn)題。 但是，他同時(shí)會(huì)隨著數(shù)據(jù)量的增長(zhǎng)，越來(lái)越高并發(fā)的將計(jì)算結(jié)果寫入到一個(gè)數(shù)據(jù)庫(kù)集群中。而這個(gè)數(shù)據(jù)庫(kù)集群在團(tuán)隊(duì)劃分的時(shí)候，實(shí)際上是交給數(shù)據(jù)查詢平臺(tái)團(tuán)隊(duì)來(lái)負(fù)責(zé)維護(hù)的。 也就是說(shuō)，對(duì)實(shí)時(shí)計(jì)算平臺(tái)團(tuán)隊(duì)來(lái)說(shuō)，他們是不care那個(gè)數(shù)據(jù)庫(kù)集群是什么狀態(tài)的，而就是不停的把數(shù)據(jù)寫入到那個(gè)集群里去。 但是，對(duì)于數(shù)據(jù)查詢平臺(tái)團(tuán)隊(duì)來(lái)說(shuō)，他們就會(huì)被動(dòng)的承擔(dān)實(shí)時(shí)計(jì)算平臺(tái)越來(lái)越高并發(fā)壓力寫入的數(shù)據(jù)。 這個(gè)時(shí)候數(shù)據(jù)查詢平臺(tái)團(tuán)隊(duì)的同學(xué)很可能處于這樣的一種焦躁中：本來(lái)自己這塊系統(tǒng)也有很多架構(gòu)上的改進(jìn)點(diǎn)要做，比如說(shuō)之前提到的冷數(shù)據(jù)查詢引擎的自研。 但是呢，他們卻要不停的被線上數(shù)據(jù)庫(kù)服務(wù)器的報(bào)警搞的焦頭爛額，疲于奔命。 因?yàn)閿?shù)據(jù)庫(kù)服務(wù)器單機(jī)寫入壓力可能隨著業(yè)務(wù)增長(zhǎng)，迅速變成每秒5000~6000的寫入壓力，每天到了高峰期，線上服務(wù)器的CPU、磁盤、IO、網(wǎng)絡(luò)等壓力巨大，報(bào)警頻繁。 此時(shí)數(shù)據(jù)查詢平臺(tái)團(tuán)隊(duì)的架構(gòu)演進(jìn)節(jié)奏就會(huì)被打亂，因?yàn)楸仨毐粍?dòng)的去根據(jù)實(shí)時(shí)計(jì)算平臺(tái)的寫入壓力來(lái)進(jìn)行調(diào)整，必須立馬停下手中的工作，然后去考慮如何對(duì)數(shù)據(jù)庫(kù)集群做分庫(kù)分表的方案，如何對(duì)表進(jìn)行擴(kuò)容，如何對(duì)庫(kù)進(jìn)行擴(kuò)容。 同時(shí)結(jié)合分庫(kù)分表的方案，數(shù)據(jù)查詢平臺(tái)自身的查詢機(jī)制又要跟著一起改變，大量的改造工作，調(diào)研工作，數(shù)據(jù)遷移工作，上線部署工作，代碼改造工作。 實(shí)際上，上面說(shuō)的這種情況，絕對(duì)是不合理的。 因?yàn)檎麄€(gè)這套數(shù)據(jù)平臺(tái)是一個(gè)大互聯(lián)網(wǎng)公司里核心業(yè)務(wù)部門的一個(gè)核心系統(tǒng)，他是數(shù)十個(gè)Java工程師與大數(shù)據(jù)工程師通力合作一起開發(fā)，而且里面劃分為了多個(gè)team。 比如說(shuō)數(shù)據(jù)接入系統(tǒng)是一個(gè)團(tuán)隊(duì)負(fù)責(zé)，實(shí)時(shí)計(jì)算平臺(tái)是一個(gè)團(tuán)隊(duì)負(fù)責(zé)，數(shù)據(jù)查詢平臺(tái)是一個(gè)團(tuán)隊(duì)負(fù)責(zé)，離線數(shù)據(jù)倉(cāng)庫(kù)是一個(gè)團(tuán)隊(duì)負(fù)責(zé)，等等。 所以只要分工合作了以后，那么就不應(yīng)該讓一個(gè)團(tuán)隊(duì)被動(dòng)的去承擔(dān)另外一個(gè)團(tuán)隊(duì)猛然增長(zhǎng)的寫入壓力，這樣會(huì)打破每個(gè)團(tuán)隊(duì)自己的工作節(jié)奏。 導(dǎo)致這個(gè)問(wèn)題的根本原因，就是因?yàn)閮蓚€(gè)系統(tǒng)間，沒有做任何解耦的處理。 這就導(dǎo)致數(shù)據(jù)查詢平臺(tái)團(tuán)隊(duì)根本無(wú)法對(duì)實(shí)時(shí)計(jì)算平臺(tái)涌入過(guò)來(lái)的數(shù)據(jù)做任何有效的控制和管理，這也導(dǎo)致了“被動(dòng)承擔(dān)高并發(fā)寫入壓力”問(wèn)題的發(fā)生。 這種系統(tǒng)耦合導(dǎo)致的被動(dòng)高并發(fā)寫入壓力還不只是上面那么簡(jiǎn)單，實(shí)際在上述場(chǎng)景中，線上生產(chǎn)環(huán)境還發(fā)生過(guò)各種奇葩的事情： 某一次線上突然產(chǎn)生大量的熱數(shù)據(jù)，熱數(shù)據(jù)計(jì)算結(jié)果涌入數(shù)據(jù)查詢平臺(tái)，因?yàn)闆]做任何管控，幾乎一瞬間導(dǎo)致某臺(tái)數(shù)據(jù)庫(kù)服務(wù)器寫入并發(fā)達(dá)到1萬(wàn)+，DBA焦急的擔(dān)心數(shù)據(jù)庫(kù)快宕機(jī)了，所有人也都被搞的焦頭爛額，心理崩潰。 系統(tǒng)耦合痛點(diǎn)2：數(shù)據(jù)庫(kù)運(yùn)維操作導(dǎo)致的線上系統(tǒng)性能劇烈抖動(dòng) 在這種系統(tǒng)耦合的場(chǎng)景下，反過(guò)來(lái)實(shí)時(shí)計(jì)算平臺(tái)團(tuán)隊(duì)的同學(xué)其實(shí)心里也會(huì)吶喊：我們心里也苦??！ 因?yàn)榉催^(guò)來(lái)大家可以思考一下，線上數(shù)據(jù)庫(kù)中的表結(jié)構(gòu)改變，那幾乎可以說(shuō)是再正常不過(guò)了，尤其是高速迭代發(fā)展中的業(yè)務(wù)。 需求評(píng)審會(huì)上，要是不小心碰上某個(gè)產(chǎn)品經(jīng)理，今天改需求，明天改需求。工程師估計(jì)會(huì)怒火沖天的想要砍人。但是沒辦法，最后還是得為五斗米折腰，該改的需求還是得改。該改的表結(jié)構(gòu)也還是要改，改加的索引也還是要加。 但是大家考慮一個(gè)點(diǎn)，如果說(shuō)對(duì)上述這種強(qiáng)耦合的系統(tǒng)架構(gòu)，單表基本都是在千萬(wàn)級(jí)別的數(shù)據(jù)量，同時(shí)還有單臺(tái)數(shù)據(jù)庫(kù)服務(wù)器每秒幾千的寫入壓力。 在這種場(chǎng)景下，在線上走一個(gè)MySQL的DDL語(yǔ)句試一試？奉勸大家千萬(wàn)別胡亂嘗試，因?yàn)閿?shù)據(jù)查詢團(tuán)隊(duì)里的年輕同學(xué)，干過(guò)這個(gè)事兒。 實(shí)際的結(jié)果就是，DDL咔嚓一執(zhí)行，對(duì)線上表結(jié)構(gòu)進(jìn)行修改，直接導(dǎo)致實(shí)時(shí)計(jì)算平臺(tái)的寫入數(shù)據(jù)庫(kù)的性能急劇下降10倍以上。。。 然后連帶導(dǎo)致實(shí)時(shí)計(jì)算平臺(tái)的數(shù)據(jù)分片計(jì)算任務(wù)大量的延遲。再然后，因?yàn)閷?shí)時(shí)計(jì)算之后的數(shù)據(jù)無(wú)法盡快反饋到存儲(chǔ)中，無(wú)法被用戶查詢到，導(dǎo)致了大量的線上投訴。 并且，DDL語(yǔ)句執(zhí)行的還特別的慢，耗時(shí)數(shù)十分鐘才執(zhí)行完畢，這就導(dǎo)致數(shù)十分鐘里，整套系統(tǒng)出現(xiàn)了大規(guī)模的計(jì)算延遲，數(shù)據(jù)延遲。 一直到數(shù)十分鐘之后DDL語(yǔ)句執(zhí)行完畢，實(shí)時(shí)計(jì)算平臺(tái)才通過(guò)自身的自動(dòng)延遲調(diào)度恢復(fù)機(jī)制慢慢恢復(fù)了正常的計(jì)算。 orz......于是從此之后，數(shù)據(jù)查詢平臺(tái)的攻城獅，必須得小心翼翼的在每天凌晨2點(diǎn)~3點(diǎn)之間進(jìn)行相關(guān)的數(shù)據(jù)庫(kù)運(yùn)維操作，避免影響線上系統(tǒng)的性能穩(wěn)定性。 但是，難道人家年輕工程師沒有女朋友？難道年長(zhǎng)工程師沒有老婆孩子？經(jīng)常在凌晨3點(diǎn)看看窗外的風(fēng)景，然后打個(gè)滴滴回家，估計(jì)沒任何人愿意。 其實(shí)上述問(wèn)題，說(shuō)白了，還是因?yàn)閮商紫到y(tǒng)直接通過(guò)存儲(chǔ)耦合在了一起，導(dǎo)致了任何一個(gè)系統(tǒng)只要有點(diǎn)異動(dòng)，直接就會(huì)影響另外一個(gè)系統(tǒng)。耦合！耦合！還是耦合！ 系統(tǒng)耦合痛點(diǎn)N。。。 其實(shí)上面只不過(guò)是挑了其中兩個(gè)系統(tǒng)耦合痛點(diǎn)來(lái)說(shuō)明而已，文章篇幅有限，很難把上述長(zhǎng)達(dá)數(shù)月的耦合狀態(tài)下的各種痛點(diǎn)一一說(shuō)明，實(shí)際線上生產(chǎn)環(huán)境的痛點(diǎn)還包括不限于：
下一篇文章，我們就來(lái)聊一聊針對(duì)這些痛點(diǎn)，如何靈活的運(yùn)用MQ消息中間件技術(shù)來(lái)進(jìn)行復(fù)雜系統(tǒng)之間的解耦，同時(shí)解耦過(guò)后如何來(lái)自行對(duì)流量數(shù)據(jù)進(jìn)行管控，解決各種系統(tǒng)耦合的問(wèn)題。 |
|
|
