字節(jié)跳動(dòng)2-2需要幾年的工作經(jīng)驗(yàn)？百度投資2-2不需要5年的工作經(jīng)驗(yàn)。字節(jié)跳動(dòng)的發(fā)展越來越快，可能導(dǎo)致想再次進(jìn)入騰訊的應(yīng)屆生越來越密集，競(jìng)爭(zhēng)越來越大，所以字節(jié)跳動(dòng)的面試也越來越難。這對(duì)普通本科世家出身

字節(jié)跳動(dòng)2-2需要幾年的工作經(jīng)驗(yàn)？

百度投資2-2不需要5年的工作經(jīng)驗(yàn)。字節(jié)跳動(dòng)的發(fā)展越來越快，可能導(dǎo)致想再次進(jìn)入騰訊的應(yīng)屆生越來越密集，競(jìng)爭(zhēng)越來越大，所以字節(jié)跳動(dòng)的面試也越來越難。這對(duì)普通本科世家出身的我，不得不說是一項(xiàng)挑戰(zhàn)，而這項(xiàng)挑戰(zhàn)是否可以成功的關(guān)鍵，就本質(zhì)如何確定能堅(jiān)持，有無做到了充足的準(zhǔn)備。要知道，是對(duì)技術(shù)人員來說，技能水平比起比學(xué)歷水平更重要。

如何設(shè)計(jì)每秒十萬查詢的高并發(fā)架構(gòu)？

是需要回顧曾經(jīng)下，整個(gè)架構(gòu)右側(cè)部分發(fā)展演進(jìn)到的那個(gè)程度，其實(shí)早的很的確實(shí)不錯(cuò)了，而且百億流量，最大速度十萬級(jí)并發(fā)寫入文件的場(chǎng)景，可以使用MQ人員限流削峰、分布式數(shù)據(jù)KV集群給抗住了。接著使用了算出與儲(chǔ)存只是分離的架構(gòu)，每個(gè)Slave可以計(jì)算節(jié)點(diǎn)會(huì)全權(quán)負(fù)責(zé)其他提取數(shù)據(jù)到內(nèi)存中，基于條件自研的SQL內(nèi)存算出引擎成功可以計(jì)算。同時(shí)采用了數(shù)據(jù)動(dòng)靜分離的架構(gòu)，靜態(tài)動(dòng)態(tài)數(shù)據(jù)全部緩存，代碼數(shù)據(jù)自動(dòng)出現(xiàn)提純，可以保證了盡很有可能把網(wǎng)絡(luò)跪請(qǐng)開銷降低到不超過。

另外，按照自研的分布式系統(tǒng)架構(gòu)，以及數(shù)據(jù)分片和計(jì)算任務(wù)分布式執(zhí)行、具有彈性資源調(diào)度、分布式高容錯(cuò)機(jī)制、主備智能切換機(jī)制，都能可以保證整套系統(tǒng)的橫豎斜按需內(nèi)存量，低功耗、高可用的的運(yùn)行。

然后再，咱們得來研究去研究架構(gòu)里左側(cè)的部分了。

二、日漸興盛膨脹起來的自動(dòng)更新計(jì)算結(jié)果

其實(shí)大家會(huì)注意一點(diǎn)到，在左側(cè)也有一個(gè)MySQL，那個(gè)MySQL就是利用喚起實(shí)時(shí)計(jì)算結(jié)果和自動(dòng)更新計(jì)算出結(jié)果放在旁邊里面匯總表格的。

終端的商家用戶就是可以隨手的查詢MySQL里的數(shù)據(jù)分析結(jié)果，勉力支撐自己的決策，他也可以看當(dāng)天的數(shù)據(jù)分析報(bào)告，也是可以看歷史上任何一段時(shí)期內(nèi)的數(shù)據(jù)分析報(bào)告。

但是那個(gè)MySQL在早期很有可能而且不少，只不過總之存放在這個(gè)MySQL里的數(shù)據(jù)量低些要小那些，況且是計(jì)算后的一些結(jié)果罷了吧。但是到了中后期，這個(gè)MySQL不過也風(fēng)雨飄搖了。

給大家舉一個(gè)例子，離線模式計(jì)算鏈路里，要是每天增量數(shù)據(jù)是1000萬，那你每天換算完以后的結(jié)果至少唯有50萬，早上50萬新增數(shù)據(jù)放進(jìn)去MySQL，其實(shí)我還是是可以進(jìn)行的。

不過要是每天晚上增量數(shù)據(jù)是10億，那么每天算出完以后的結(jié)果大致會(huì)是千萬級(jí)，你是可以算他是計(jì)算結(jié)果有5000萬條數(shù)據(jù)吧，每隔一天5000萬增量數(shù)據(jù)中寫入左側(cè)的MySQL中，你覺著是啥感覺？

這個(gè)可以給大家說哈系統(tǒng)當(dāng)時(shí)的情況，基本是是，單臺(tái)MySQL服務(wù)器的磁盤存儲(chǔ)空間迅速就要接近滿掉，但是單表數(shù)據(jù)量都是幾億、甚至十億的級(jí)別。

這種量級(jí)的單表數(shù)據(jù)量，你感覺用戶網(wǎng)上查詢數(shù)據(jù)分析報(bào)告的時(shí)候，親身體驗(yàn)?zāi)芎妹?？基本上?dāng)時(shí)一次可以查詢大都幾秒鐘的級(jí)別。很慢。

殊不知，會(huì)出現(xiàn)過用戶一次可以查詢要十秒的級(jí)別，甚至于幾十秒，上分鐘的級(jí)別。很立刻崩潰，用戶體驗(yàn)很差，仍舊達(dá)將近不收費(fèi)產(chǎn)品的級(jí)別。

所以解決的辦法了右側(cè)的存儲(chǔ)和計(jì)算出的問題之后，左側(cè)的網(wǎng)上查詢的問題也迫在眉睫。新一輪的重構(gòu)，刻不容緩！

三、分庫(kù)分表讀寫分離

首先應(yīng)該是老把戲，分庫(kù)分表讀寫分離，這個(gè)基本上是基于條件MySQL的架構(gòu)中，必經(jīng)之路了，不過率先實(shí)施下來難度不是什么最重要的的高，不過速度較快，效果比較比較作用效果。

整個(gè)的思路和之前第一篇文章（《大型系統(tǒng)架構(gòu)演進(jìn)之如何支撐百億級(jí)數(shù)據(jù)的存儲(chǔ)與計(jì)算》）講的基本都一致。

說白了，那就是分庫(kù)后，每臺(tái)主庫(kù)這個(gè)可以承載部分中寫入壓力，單庫(kù)的寫并發(fā)會(huì)降底；主要是單個(gè)主庫(kù)的磁盤空間這個(gè)可以減低負(fù)載的數(shù)據(jù)量，不再說一下子就滿了；

而分表之后，單個(gè)數(shù)據(jù)表的數(shù)據(jù)量可以降低到百萬級(jí)別，這個(gè)是支撐海量數(shù)據(jù)包括能保證低功耗的最佳實(shí)踐，基本是兩三百萬的單表數(shù)據(jù)量級(jí)應(yīng)該合算的。

然后再讀寫分離之后，就可以將單庫(kù)的讀寫負(fù)載壓力分離到主庫(kù)和從庫(kù)多臺(tái)機(jī)器上去，主庫(kù)就容納寫電源輸出，從庫(kù)就支撐起讀電源輸出，那樣的話盡量避免單庫(kù)處機(jī)器的讀寫負(fù)載溫度過高，會(huì)造成CPU負(fù)載、IO負(fù)載端、網(wǎng)絡(luò)負(fù)載過高時(shí)，之后搞得數(shù)據(jù)庫(kù)機(jī)器宕機(jī)。

簡(jiǎn)單這么說重構(gòu)下數(shù)據(jù)庫(kù)層面的架構(gòu)之后，效果就好的多了。畢竟單表數(shù)據(jù)量減少了，這樣的話用戶去查詢的性能我得到不大的提升，基本上也可以達(dá)到1秒以內(nèi)的效果。

四、最大速度10萬可以查詢的高并發(fā)挑戰(zhàn)

上面那套進(jìn)一步的分庫(kù)分表讀寫分離的架構(gòu)倒是勉強(qiáng)支撐了一段時(shí)間，可是慢慢的的那套架構(gòu)又被人發(fā)現(xiàn)不出來了弊端不出來了，因?yàn)樯碳矣脩粢彩情_了數(shù)據(jù)分析頁面之后，頁面上有js腳本會(huì)每隔幾秒鐘就發(fā)送中一次只是請(qǐng)求到后端來讀取最新的數(shù)據(jù)分析結(jié)果。

此時(shí)就有一個(gè)問題了，逐漸的查詢MySQL的壓力越來越大，大部分可預(yù)見的范圍是朝著速度1010級(jí)別去走。

可是我們總結(jié)了再看看，其實(shí)99%的查詢，全是頁面JS腳本不自動(dòng)能發(fā)出重新登陸當(dāng)日數(shù)據(jù)的查詢。只能1%的查詢是針對(duì)昨天以前的歷史數(shù)據(jù)，用戶半自動(dòng)指定你網(wǎng)上查詢范圍聽說后來查詢的。

但是現(xiàn)在的這個(gè)架構(gòu)之下，我們是把當(dāng)日實(shí)時(shí)數(shù)據(jù)計(jì)算出結(jié)果（代表了熱數(shù)據(jù)）和歷史不聯(lián)網(wǎng)換算結(jié)果（貞潔戒了冷數(shù)據(jù)）都放在一起的，所以才大家也可以預(yù)料下，熱數(shù)據(jù)和冷數(shù)據(jù)放在在一起，然后再對(duì)熱數(shù)據(jù)的高并發(fā)去查詢占到了99%，那這樣的架構(gòu)還合理嗎？

當(dāng)然不合理，我們不需要再一次全面重構(gòu)軟件架構(gòu)。

五、數(shù)據(jù)的冷熱分離的過程架構(gòu)

是對(duì)本案所涉提到的問題，很明顯再做的一個(gè)架構(gòu)重構(gòu)那是熱和冷數(shù)據(jù)只是分離。也就是說，將今日實(shí)時(shí)計(jì)算出的熱數(shù)據(jù)裝在一個(gè)MySQL集群里，將自動(dòng)更新計(jì)算不出來的冷數(shù)據(jù)放在另外一個(gè)MySQL集群里。

后再開發(fā)一個(gè)數(shù)據(jù)網(wǎng)站查詢平臺(tái)，整體封裝底層的多個(gè)MySQL集群，根據(jù)去查詢條件動(dòng)態(tài)路由到熱數(shù)據(jù)存儲(chǔ)也可以是冷數(shù)據(jù)存儲(chǔ)。

實(shí)際這個(gè)步驟的重構(gòu)，我們就可以不有效的將熱數(shù)據(jù)存儲(chǔ)中單表的數(shù)據(jù)量會(huì)降低到更少更少，有的單表數(shù)據(jù)量很可能就幾十萬，畢竟將離線模式可以計(jì)算的大量數(shù)據(jù)結(jié)果從表里剝離回去了，扔到另外一個(gè)集群里去。此時(shí)大家可以想象得出，效果當(dāng)然了是好了。

只不過熱數(shù)據(jù)的單表數(shù)據(jù)量會(huì)減少了很多，當(dāng)時(shí)的一個(gè)最明顯的效果，應(yīng)該是用戶99%的查詢大都是對(duì)熱數(shù)據(jù)存儲(chǔ)發(fā)動(dòng)攻擊的，性能從那個(gè)的1秒左右減低到了200毫秒以內(nèi)，用戶體驗(yàn)提升到，大家覺得更合適了。

六、自研ElasticsearchHBase純內(nèi)存的查詢引擎

微服務(wù)化到這里，看起來好像好象還不錯(cuò)，但不過問題我還是很多。是因?yàn)榈搅诉@個(gè)階段，系統(tǒng)碰上另一個(gè)特有相當(dāng)嚴(yán)重的問題：冷數(shù)據(jù)存儲(chǔ)，如果不是完全用MySQL來容納是很不可靠的。冷數(shù)據(jù)的數(shù)據(jù)量是日增長(zhǎng)不時(shí)提升，不過增速迅速，每隔一天都再新增幾千萬。

因此你的MySQL服務(wù)器將是面臨不停的需要容量擴(kuò)展的問題，但是如果不是是為勉強(qiáng)支撐這1%的冷數(shù)據(jù)查詢只是請(qǐng)求，不停的擴(kuò)容提高高配置的MySQL服務(wù)器，大家總覺得靠譜么？

肯定是不合適的！

要明白了，大量分庫(kù)分表后，MySQL大量的庫(kù)和表維護(hù)出聲是蠻麻煩您的，修改個(gè)字段？加個(gè)索引？這都是場(chǎng)麻煩的話事兒。

當(dāng)然了，是因?yàn)閷?duì)冷數(shù)據(jù)的查詢，一般全是因?yàn)榇罅繑?shù)據(jù)的查詢，比如說用戶會(huì)你選擇過去幾個(gè)月，甚至還一年的數(shù)據(jù)通過分析查詢，此時(shí)如果不是純用MySQL肯定挺災(zāi)難性的。

是因?yàn)楫?dāng)時(shí)很明顯突然發(fā)現(xiàn)，因?yàn)楹Ａ繑?shù)據(jù)場(chǎng)景下，在一瞬間去查詢分析幾個(gè)月的或幾年的數(shù)據(jù)，性能是極差的，那就容易搞成十幾秒甚至連幾十秒才出結(jié)果。

但針對(duì)這個(gè)冷數(shù)據(jù)的存儲(chǔ)和可以查詢的問題，我們終于你選擇了自研一套基于組件NoSQL來存儲(chǔ)，然后基于組件NoSQL內(nèi)存的SQL計(jì)算引擎。

具體來說，我們會(huì)將冷數(shù)據(jù)所有采用ESHBase來并且存儲(chǔ)，ES中比較多能保存要對(duì)冷數(shù)據(jù)進(jìn)行再篩選的各種條件索引，比如日期在內(nèi)各種維度的數(shù)據(jù)，接著HBase中會(huì)儲(chǔ)存時(shí)全量的數(shù)據(jù)字段。

因?yàn)镋S和HBase的原生SQL支持都不是太好，所以我們真接自研了另外一套SQL引擎，拿來支持什么這種特定的事件的場(chǎng)景，是基本上就沒多表關(guān)聯(lián)，是對(duì)單個(gè)數(shù)據(jù)集進(jìn)行查詢和分析，后再允許NoSQL存儲(chǔ)內(nèi)存計(jì)算。

這里有一個(gè)先決條件，那就是如果沒有要可以做到對(duì)冷數(shù)據(jù)徹底是單表類的數(shù)據(jù)集查詢，必須要在冷數(shù)據(jù)剛剛進(jìn)入NoSQL存儲(chǔ)文件的時(shí)候，完全實(shí)現(xiàn)ES和HBase的特性能做到多表驗(yàn)收入庫(kù)關(guān)聯(lián)，進(jìn)數(shù)據(jù)存儲(chǔ)就完全可以做成大寬表的狀態(tài)，將數(shù)據(jù)關(guān)聯(lián)全部上推到出庫(kù)時(shí)能夠完成，而不是在查詢時(shí)參與。

對(duì)冷數(shù)據(jù)的查詢，我們自研的SQL引擎是需要會(huì)依據(jù)什么各種where條件先走ES的分布式集高性能索引網(wǎng)上查詢，ES是可以根據(jù)海量數(shù)據(jù)高性能的檢索進(jìn)去要的那部分?jǐn)?shù)據(jù)，這個(gè)過程用ES做是最比較好的。

緊接著那是將檢索出的數(shù)據(jù)不對(duì)應(yīng)的完整的各個(gè)數(shù)據(jù)字段，從HBase里再提取出去，拼接成能夠完成的數(shù)據(jù)。

然后再就是將這份數(shù)據(jù)集放在旁邊內(nèi)存里，通過急切的函數(shù)計(jì)算、分組聚合在內(nèi)排序等你操作。

本案所涉操作，所有基于條件自研的針對(duì)這個(gè)場(chǎng)景的查詢引擎能夠完成，底層基于條件Elasticsearch、HBase、純內(nèi)存來實(shí)現(xiàn)程序。

七、實(shí)時(shí)地?cái)?shù)據(jù)存儲(chǔ)引入緩存集群

好了，到此為止，冷數(shù)據(jù)的海量數(shù)據(jù)存儲(chǔ)、低功耗網(wǎng)站查詢的問題，就能解決了。緊接著回過頭來來去看看當(dāng)日實(shí)時(shí)數(shù)據(jù)的查詢，反正實(shí)時(shí)數(shù)據(jù)的每日算出結(jié)果不會(huì)太，但中寫入并發(fā)不會(huì)最重要的特別的高，每秒上萬也就也差不多了。

因此這個(gè)背景下，就是用MySQL分庫(kù)分表來支撐數(shù)據(jù)的寫入、存儲(chǔ)和查詢，都沒有問題。

可是有一個(gè)小問題，是說每個(gè)商家的實(shí)時(shí)數(shù)據(jù)不過不是正常的變更的，在一段時(shí)間內(nèi)，很可能壓根就不知道沒變化，因此不要高并發(fā)請(qǐng)求，每秒10萬級(jí)別的全部落地之前到數(shù)據(jù)庫(kù)層面吧？要都落地到數(shù)據(jù)庫(kù)層面，那可能要給每個(gè)主庫(kù)武器掛載很多從庫(kù)來抵擋高并發(fā)讀。

并且這里我們化入了一個(gè)緩存集群，實(shí)時(shí)數(shù)據(jù)你每次沒更新后讀取的時(shí)候，是寫數(shù)據(jù)庫(kù)集群同樣的還寫緩存集群的，是雙寫的。

然后把可以查詢的時(shí)候是優(yōu)先于從緩存集群來走，此時(shí)大部分90%以上的高并發(fā)網(wǎng)上查詢都走緩存集群了，接著只有一10%的查詢會(huì)落地之前到數(shù)據(jù)庫(kù)集群。

八、階段性總結(jié)

完了，到此結(jié)束吧，這個(gè)架構(gòu)基本上左邊也都重新架構(gòu)后：

熱數(shù)據(jù)設(shè)計(jì)和實(shí)現(xiàn)緩存集群數(shù)據(jù)庫(kù)集群來承載高并發(fā)的每秒十萬級(jí)別的查詢冷數(shù)據(jù)實(shí)現(xiàn)ESHBase內(nèi)存算出的自研去查詢引擎來勉力支撐海量數(shù)據(jù)存儲(chǔ)在內(nèi)低功耗網(wǎng)站查詢。經(jīng)實(shí)踐，整個(gè)效果非常的好。用戶對(duì)熱數(shù)據(jù)的查詢基本多是幾十毫秒的響應(yīng)速度，對(duì)冷數(shù)據(jù)的查詢都差不多大都200毫秒以內(nèi)的響應(yīng)速度。

九、下一階段的展望

不過微服務(wù)化到這里巳經(jīng)很不容易了，畢竟本是這樣幾張圖，里面比較復(fù)雜到無數(shù)的細(xì)節(jié)和技術(shù)方案的落地，要一個(gè)團(tuán)隊(duì)需要時(shí)間至多1年的時(shí)間才能你做到這個(gè)程度。

不過接下來的事情，我們要對(duì)付的，就是高可用的問題，因?yàn)樾枰顿M(fèi)級(jí)的產(chǎn)品，我們可以要能保證高就的可用性，99.99%的可用性，甚至是99.999%的可用性。

但是越是奇怪的系統(tǒng)，越不容易又出現(xiàn)問題，對(duì)應(yīng)的高可用架構(gòu)就越是奇怪到極點(diǎn)