作者 | L的存在

來(lái)源 | 我是程序員小賤（ID：Lanj1995Q）

說(shuō)到后端開(kāi)發(fā)，難免會(huì)遇到各種所謂高大上的「關(guān)鍵詞 」，對(duì)于我們應(yīng)屆生小白，難免會(huì)覺(jué)得比較陌生，因?yàn)樵趯W(xué)校確實(shí)比較少遇見(jiàn)這些所謂高大上的東西，那么今天就帶著學(xué)習(xí)的態(tài)度和大家分享這些看似可以裝逼可以飛的帶逼格的關(guān)鍵詞吧。

大綱

 

分布式

在學(xué)校里的項(xiàng)目中，一個(gè) Web 系統(tǒng)可能咋們一個(gè)人就搞定，因?yàn)閹缀醪豢紤]并發(fā)量，性能咋樣，所謂「過(guò)得去 」足矣，但是為了面試考慮，我們又不得不找點(diǎn)類似秒殺系統(tǒng)作為我們簡(jiǎn)歷的支撐項(xiàng)目(即使已經(jīng)爛大街)。那么先問(wèn)你第一個(gè)問(wèn)題，為什么就采用了分布式的方案落地這個(gè)項(xiàng)目？

當(dāng)一個(gè)人或者幾十個(gè)使用你的系統(tǒng)，哎呀我去，請(qǐng)求秒回，效果倍棒，于是乎簡(jiǎn)歷砰砰寫上卻多么牛X，當(dāng)面試官就會(huì)問(wèn)你你這項(xiàng)目做了啥，測(cè)試過(guò)沒(méi)，并發(fā)量如何，性能如何？你就…..

當(dāng)訪問(wèn)系統(tǒng)的用戶越來(lái)越多，可是我們的系統(tǒng)資源有限，所以需要更多的 CPU 和內(nèi)存去處理用戶的計(jì)算請(qǐng)求，當(dāng)然也就要求更大的網(wǎng)絡(luò)帶寬去處理數(shù)據(jù)的傳輸，也需要更多的磁盤空間存儲(chǔ)數(shù)據(jù)。

資源不夠，消耗過(guò)度，服務(wù)器崩潰，系統(tǒng)也就不干活了，那么在這樣的情況怎么處理？

• 垂直伸縮

縱向生長(zhǎng)。通過(guò)提升單臺(tái)服務(wù)器的計(jì)算處理能力來(lái)抵抗更大的請(qǐng)求訪問(wèn)量。比如使用更快頻率的CPU，更快的網(wǎng)卡，塞更多的磁盤等。

其實(shí)這樣的處理方式在電信，銀行等企業(yè)比較常見(jiàn)，讓摩托車變?yōu)樾∑嚕鼜?qiáng)大的計(jì)算機(jī)，處理能力也就越強(qiáng)，但是對(duì)于運(yùn)維而言也就越來(lái)越復(fù)雜。那真的就這樣花錢買設(shè)備就完事了？

當(dāng)然不，單臺(tái)服務(wù)器的計(jì)算處理能力是有限的，而且也會(huì)嚴(yán)重受到計(jì)算機(jī)硬件水平的制約。

• 水平伸縮

一臺(tái)機(jī)器處理不過(guò)來(lái)，我就用多臺(tái)廉價(jià)的機(jī)器合并同時(shí)處理，人多力量大嘛，通過(guò)多臺(tái)服務(wù)器構(gòu)成分布式集群從而提升系統(tǒng)的整體處理能力。這里說(shuō)到了分布式，那我們看看分布式的成長(zhǎng)過(guò)程

記住一句話：系統(tǒng)的技術(shù)架構(gòu)是需求所驅(qū)動(dòng)

最初的單體系統(tǒng)，只需要部分用戶訪問(wèn)：

單體結(jié)構(gòu)

做系統(tǒng)的原因當(dāng)然是有需求，有價(jià)值，可賺錢。隨著使用系統(tǒng)的用戶越來(lái)越多，這時(shí)候關(guān)注的人越來(lái)越多，單臺(tái)服務(wù)器扛不住了，關(guān)注的人覺(jué)得響應(yīng)真慢，沒(méi)啥意思，就開(kāi)始吐槽，但是這一吐槽，導(dǎo)致用戶更多，畢竟大家都愛(ài)吃瓜。

這樣下去不得不進(jìn)行系統(tǒng)的升級(jí)，將數(shù)據(jù)庫(kù)和應(yīng)用分離。

數(shù)據(jù)庫(kù)應(yīng)用分離

這樣子，咋們將數(shù)據(jù)庫(kù)和應(yīng)用程序分離后，部署在不同的服務(wù)器中，從1臺(tái)服務(wù)器變?yōu)槎嗯_(tái)服務(wù)器，處理響應(yīng)更快，內(nèi)容也夠干，訪問(wèn)的用戶呈指數(shù)增長(zhǎng)，這多臺(tái)服務(wù)器都有點(diǎn)扛不住了，怎么辦？

加一個(gè)緩存吧，我們不每次從數(shù)據(jù)庫(kù)中讀取數(shù)據(jù)，而將應(yīng)用程序需要的數(shù)據(jù)暫存在緩沖中。緩存呢，又分為本地緩存和分布式的緩存。分布式緩存，顧名思義，使用多臺(tái)服務(wù)器構(gòu)成集群，存儲(chǔ)更多的數(shù)據(jù)并提供緩存服務(wù)，從而提升緩存的能力。

加了緩存哪些好處？

• 應(yīng)用程序不再直接訪問(wèn)數(shù)據(jù)庫(kù)，提升訪問(wèn)效率。因?yàn)榫彺鎯?nèi)容在內(nèi)存中，不用每次連接存放磁盤中的數(shù)據(jù)庫(kù)。

系統(tǒng)越來(lái)越火，于是考慮將應(yīng)用服務(wù)器也作為集群。

集群

 

緩存架構(gòu)

干啥啥不行，緩存第一名。不吹牛，緩存應(yīng)用在計(jì)算機(jī)的各個(gè)角落。緩存可說(shuō)是軟件技術(shù)中的的殺手锏，無(wú)論是程序代碼使用buffer，還是網(wǎng)絡(luò)架構(gòu)中使用緩存，虛擬機(jī)也會(huì)使用大量的緩存。

其實(shí)最初在CPU中也就開(kāi)始使用緩存。緩存分為兩種，一種是通讀緩存，一種是旁路緩存

• 通讀緩存

假設(shè)當(dāng)前應(yīng)用程序獲取數(shù)據(jù)，如果數(shù)據(jù)存在于通讀緩存中就直接返回。如果不存在于通讀緩存，那么就訪問(wèn)數(shù)據(jù)源，同時(shí)將數(shù)據(jù)存放于緩存中。

下次訪問(wèn)就直接從緩存直接獲取。比較常見(jiàn)的為CDN和反向代理。

通讀緩存

CDN

CDN稱為內(nèi)容分發(fā)網(wǎng)絡(luò)。想象我們京東購(gòu)物的時(shí)候，假設(shè)我們?cè)诔啥迹绻I的東西在成都倉(cāng)庫(kù)有就直接給我們寄送過(guò)來(lái)，可能半天就到了，用戶體驗(yàn)也非常好，就不用從北京再寄過(guò)來(lái)。

同樣的道理，用戶就可以近距離獲得自己需要的數(shù)據(jù)，既提高了響應(yīng)速度，又節(jié)約了網(wǎng)絡(luò)帶寬和服務(wù)器資源。

• 旁路緩存

應(yīng)用程序需要自己從數(shù)據(jù)源讀取數(shù)據(jù)，然后將這個(gè)數(shù)據(jù)寫入到旁路緩存中。這樣，下次應(yīng)用程序需要數(shù)據(jù)的時(shí)候，就可以通過(guò)旁路緩存直接獲得數(shù)據(jù)了。

旁路緩存

緩存的好處

• 因?yàn)榇蟛糠志彺娴臄?shù)據(jù)存儲(chǔ)在內(nèi)存中，相比于硬盤或者從網(wǎng)絡(luò)中獲取效率更高，響應(yīng)時(shí)間更快，性能更好；

• 通過(guò) CDN 等通讀緩存可以降低服務(wù)器的負(fù)載能力；

• 因?yàn)榫彺嫱ǔ?huì)記錄計(jì)算結(jié)果。如果緩存命中直接返回，否則需要進(jìn)行大量的運(yùn)算。所以使用緩存也減少了CPU 的計(jì)算小號(hào)，加快處理速度。

緩存缺點(diǎn)

我們緩存的數(shù)據(jù)來(lái)自源數(shù)據(jù)，如果源數(shù)據(jù)被修改了，俺么緩存數(shù)據(jù)很肯能也是被修改過(guò)的，成為臟數(shù)據(jù)，所以怎么辦？

• 過(guò)期失效

在每次寫入緩存數(shù)據(jù)的時(shí)候標(biāo)記失效時(shí)間，讀取數(shù)據(jù)的時(shí)候檢查數(shù)據(jù)是否失效，如果失效了就重新從數(shù)據(jù)源獲取數(shù)據(jù)。

• 失效通知

應(yīng)用程序在更新數(shù)據(jù)源的時(shí)候，通知清除緩存中的數(shù)據(jù)。

是不是數(shù)據(jù)使用緩存都有意義呢？

非也，通常放入緩存中的數(shù)據(jù)都是帶有熱點(diǎn)的數(shù)據(jù)，比如當(dāng)日熱賣商品，或者熱門吃瓜新聞，這樣將數(shù)據(jù)存放在緩存中，會(huì)被多次讀取，從而緩存的命中率也會(huì)比較高。

 

異步架構(gòu)

在前面中，通過(guò)緩存實(shí)際上很多時(shí)候是解決了讀的問(wèn)題，加快了讀取數(shù)據(jù)的能力。因?yàn)榫彺嫱ǔ：茈y保證數(shù)據(jù)的持久性和一致性，所以我們通常不會(huì)將數(shù)據(jù)直接寫入緩存中，而是寫入 RDBMAS 等數(shù)據(jù)中，那如何提升系統(tǒng)的寫操作性能呢？

此時(shí)假設(shè)兩個(gè)系統(tǒng)分別為A,B，其中A系統(tǒng)依賴B系統(tǒng)，兩者通信采用遠(yuǎn)程調(diào)用的方式，此時(shí)如果B系統(tǒng)出故障，很可能引起A系統(tǒng)出故障。

從而不得不單獨(dú)進(jìn)行升級(jí)，怎么辦？

使用消息隊(duì)列的異步架構(gòu)，也成為事件驅(qū)動(dòng)模型。

異步相對(duì)于同步而言，同步通常是當(dāng)應(yīng)用程序調(diào)用服務(wù)的時(shí)候，不得不阻塞等待服務(wù)期完成，此時(shí)CPU空閑比較浪費(fèi)，直到返回服務(wù)結(jié)果后才會(huì)繼續(xù)執(zhí)行。

同步

舉個(gè)例子，小藍(lán)今天想在系統(tǒng)中加一個(gè)發(fā)郵件的功能，通過(guò)SMTP和遠(yuǎn)程服務(wù)器通信，但是遠(yuǎn)程服務(wù)器有很多郵件需要等待發(fā)送呢，當(dāng)前郵件就可能等待比較長(zhǎng)時(shí)間才能發(fā)送成功，發(fā)送成功后反饋與應(yīng)用程序。

這個(gè)過(guò)程中，遠(yuǎn)程服務(wù)器發(fā)送郵件的時(shí)候，應(yīng)用程序就阻塞，準(zhǔn)確的說(shuō)是執(zhí)行應(yīng)用程序的線程阻塞。

這樣阻塞帶來(lái)什么問(wèn)題“？

• 不能釋放占用的系統(tǒng)資源，導(dǎo)致系統(tǒng)資源不足，影響系統(tǒng)性能

• 無(wú)法快速給用戶響應(yīng)結(jié)果

但是在實(shí)際情況中，我們發(fā)送郵件，并不需要得到發(fā)送結(jié)果。比如用戶注冊(cè)，發(fā)送賬號(hào)激活郵件，無(wú)論郵件是否發(fā)送成功都會(huì)收到"返回郵件已經(jīng)發(fā)送，請(qǐng)查收郵件確認(rèn)激活"，怎樣才能讓應(yīng)用程序不阻塞？

消息隊(duì)列的異步模型

此時(shí)就比較清晰了，調(diào)用者將消息發(fā)送給消息隊(duì)列直接返回，應(yīng)用程序收到返回以后繼續(xù)執(zhí)行，快讀響應(yīng)用戶釋放資源。

有專門的消費(fèi)隊(duì)列程序從中消息隊(duì)列取出數(shù)據(jù)并進(jìn)行消費(fèi)。如果遠(yuǎn)程服務(wù)出現(xiàn)故障，只會(huì)傳遞給消費(fèi)者程序而不會(huì)影響到應(yīng)用程序。

消息隊(duì)列

消息隊(duì)列模型中通常有三個(gè)角色，分別為生產(chǎn)者，消息隊(duì)列和消費(fèi)者。生產(chǎn)者產(chǎn)生數(shù)據(jù)封裝為消息發(fā)送給消息隊(duì)列，專門的消費(fèi)程序從消息隊(duì)列中取出數(shù)據(jù)，消費(fèi)數(shù)據(jù)。

在我看來(lái)，消息隊(duì)列主要是緩沖消息，等待消費(fèi)者消費(fèi)。其中消費(fèi)的方式分為兩種：

• 點(diǎn)對(duì)點(diǎn)

對(duì)生產(chǎn)者多消費(fèi)者的情況。一個(gè)消息被一個(gè)消費(fèi)者消費(fèi)

多生產(chǎn)消費(fèi)

上述的發(fā)郵件例子就是典型的點(diǎn)對(duì)點(diǎn)模式。互不干擾，其中某個(gè)服務(wù)出現(xiàn)問(wèn)題不會(huì)印象到全局。

• 訂閱模式

開(kāi)發(fā)人員在消息隊(duì)列中設(shè)置主題，生產(chǎn)者往相應(yīng)的主題發(fā)送數(shù)據(jù)，消費(fèi)者從對(duì)應(yīng)的主題中消費(fèi)數(shù)據(jù)，每個(gè)消費(fèi)者按照自己業(yè)務(wù)邏輯分別進(jìn)行計(jì)算

訂閱模式

這個(gè)比較好理解，比如在用戶注冊(cè)的時(shí)候，我們將注冊(cè)信息放入主題用戶中，消費(fèi)者訂閱了這個(gè)主題，可能有構(gòu)造短信消息的消費(fèi)者，也有推廣產(chǎn)品的消費(fèi)者，都可以根據(jù)自己業(yè)務(wù)邏輯進(jìn)行數(shù)據(jù)處理。

用戶注冊(cè)案例

使用異步模型的優(yōu)點(diǎn)

• 快速響應(yīng)

不在需要等待。生產(chǎn)者將數(shù)據(jù)發(fā)送消息隊(duì)列后，可繼續(xù)往下執(zhí)行，不虛等待耗時(shí)的消費(fèi)處理

• 削峰填谷(需要修改)

互聯(lián)網(wǎng)產(chǎn)品會(huì)在不同的場(chǎng)景其并發(fā)請(qǐng)求量不同。互聯(lián)網(wǎng)應(yīng)用的訪問(wèn)壓力隨時(shí)都在變化，系統(tǒng)的訪問(wèn)高峰和低谷的并發(fā)壓力可能也有非常大的差距。

如果按照壓力最大的情況部署服務(wù)器集群，那么服務(wù)器在絕大部分時(shí)間內(nèi)都處于閑置狀態(tài)。

但利用消息隊(duì)列，我們可以將需要處理的消息放入消息隊(duì)列，而消費(fèi)者可以控制消費(fèi)速度，因此能夠降低系統(tǒng)訪問(wèn)高峰時(shí)壓力，而在訪問(wèn)低谷的時(shí)候還可以繼續(xù)消費(fèi)消息隊(duì)列中未處理的消息，保持系統(tǒng)的資源利用率。

• 降低耦合

如果調(diào)用是同步，如果調(diào)用是同步的，那么意味著調(diào)用者和被調(diào)用者必然存在依賴，一方面是代碼上的依賴，應(yīng)用程序需要依賴發(fā)送郵件相關(guān)的代碼，如果需要修改發(fā)送郵件的代碼，就必須修改應(yīng)用程序，而且如果要增加新的功能

那么目前主要的消息隊(duì)列有哪些，其有缺點(diǎn)是什么？(好好記下這個(gè)高頻題目啦)

 

負(fù)載均衡

一臺(tái)機(jī)器扛不住了，需要多臺(tái)機(jī)器幫忙，既然使用多臺(tái)機(jī)器，就希望不要把壓力都給一臺(tái)機(jī)器，所以需要一種或者多種策略分散高并發(fā)的計(jì)算壓力，從而引入負(fù)載均衡，那么到底是如何分發(fā)到不同的服務(wù)器的呢？

 

砸錢

最初實(shí)現(xiàn)負(fù)載均衡采取的方案很直接，直接上硬件，當(dāng)然也就比較貴，互聯(lián)網(wǎng)的普及，和各位科學(xué)家的無(wú)私奉獻(xiàn)，各個(gè)企業(yè)開(kāi)始部署自己的方案，從而出現(xiàn)負(fù)載均衡服務(wù)器。

HTTP重定向負(fù)載均衡

也屬于比較直接，當(dāng)HTTP請(qǐng)求叨叨負(fù)載均衡服務(wù)器后，使用一套負(fù)載均衡算法計(jì)算到后端服務(wù)器的地址，然后將新的地址給用戶瀏覽器，瀏覽器收到重定向響應(yīng)后發(fā)送請(qǐng)求到新的應(yīng)用服務(wù)器從而實(shí)現(xiàn)負(fù)載均衡，如下圖所示：

HTTP重定向負(fù)載均衡

優(yōu)點(diǎn)：

• 簡(jiǎn)單，如果是JAVA開(kāi)發(fā)工程師，只需要servlet中幾句代碼即可

缺點(diǎn)：

• 加大請(qǐng)求的工作量。第一次請(qǐng)求給負(fù)載均衡服務(wù)器，第二次請(qǐng)求給應(yīng)用服務(wù)器

• 因?yàn)橐扔?jì)算到應(yīng)用服務(wù)器的 IP 地址，所以 IP 地址可能暴露在公網(wǎng)，既然暴露在了公網(wǎng)還有什么安全可言

DNS負(fù)載均衡

了解計(jì)算機(jī)網(wǎng)絡(luò)的你應(yīng)該很清楚如何獲取 IP 地址，其中比較常見(jiàn)的就是 DNS 解析獲取 IP 地址。

用戶通過(guò)瀏覽器發(fā)起HTTP請(qǐng)求的時(shí)候，DNS 通過(guò)對(duì)域名進(jìn)行即系得到 IP 地址，用戶委托協(xié)議棧的 IP 地址簡(jiǎn)歷 HTTP 連接訪問(wèn)真正的服務(wù)器。這樣不同的用戶進(jìn)行域名解析將會(huì)獲取不同的IP地址從而實(shí)現(xiàn)負(fù)載均衡。

DNS負(fù)載均衡

乍一看，和HTTP重定向的方案不是很相似嗎而且還有 DNS 解析這一步驟，也會(huì)解析出 IP 地址，不一樣的暴露？

每次都需要解析嗎，當(dāng)然不，通常本機(jī)就會(huì)有緩存，在實(shí)際的工程項(xiàng)目中通常是怎么樣的呢？

• 通過(guò) DNS 解析獲取負(fù)載均衡集群某臺(tái)服務(wù)器的地址；

• 負(fù)載均衡服務(wù)器再一次獲取某臺(tái)應(yīng)用服務(wù)器，這樣子就不會(huì)將應(yīng)用服務(wù)器的 IP 地址暴露在官網(wǎng)了。

反向代理負(fù)載均衡

這里典型的就是Nginx提供的反向代理和負(fù)載均衡功能。用戶的請(qǐng)求直接叨叨反向代理服務(wù)器，服務(wù)器先看本地是緩存過(guò)，有直接返回，沒(méi)有則發(fā)送給后臺(tái)的應(yīng)用服務(wù)器處理。

反向代理負(fù)載均衡

IP負(fù)載均衡

上面一種方案是基于應(yīng)用層的，IP很明顯是從網(wǎng)絡(luò)層進(jìn)行負(fù)載均衡。TCP./IP協(xié)議棧是需要上下層結(jié)合的方式達(dá)到目標(biāo)，當(dāng)請(qǐng)求到達(dá)網(wǎng)絡(luò)層的黑猴。

負(fù)載均衡服務(wù)器對(duì)數(shù)據(jù)包中的IP地址進(jìn)行轉(zhuǎn)換，從而發(fā)送給應(yīng)用服務(wù)器。

IP負(fù)載均衡

注意，這種方案通常屬于內(nèi)核級(jí)別，如果數(shù)據(jù)比較小還好，但是大部分情況是圖片等資源文件，這樣負(fù)載均衡服務(wù)器會(huì)出現(xiàn)響應(yīng)或者請(qǐng)求過(guò)大所帶來(lái)的瓶頸。

數(shù)據(jù)鏈路負(fù)載均衡

它可以解決因?yàn)閿?shù)據(jù)量他打而導(dǎo)致負(fù)載均衡服務(wù)器帶寬不足這個(gè)問(wèn)題。怎么實(shí)現(xiàn)的呢。它不修改數(shù)據(jù)包的IP地址，而是更改mac地址。

應(yīng)用服務(wù)器和負(fù)載均衡服務(wù)器使用相同的虛擬IP。

數(shù)據(jù)鏈路負(fù)載均衡

以上介紹了幾種負(fù)載均衡的方式，但是很重要的負(fù)載均衡算法卻沒(méi)有設(shè)計(jì)，其中包含了輪詢，隨機(jī)，最少連接，下面分別對(duì)此進(jìn)行介紹。

 

數(shù)據(jù)存儲(chǔ)

公司存在的價(jià)值在于流量，流量需要數(shù)據(jù)，可想而知數(shù)據(jù)的存儲(chǔ)，數(shù)據(jù)的高可用可說(shuō)是公司的靈魂。那么改善數(shù)據(jù)的存儲(chǔ)都有哪些手段或方法呢？

• 數(shù)據(jù)主從復(fù)制

主從復(fù)制比較好理解，需要使用兩個(gè)數(shù)據(jù)庫(kù)存儲(chǔ)一樣的數(shù)據(jù)。其原理為當(dāng)應(yīng)用程序A發(fā)送更新命令到主服務(wù)器的時(shí)候，數(shù)據(jù)庫(kù)會(huì)將這條命令同步記錄到Binlog中。

然后其它線程會(huì)從Binlog中讀取并通過(guò)遠(yuǎn)程通訊的方式復(fù)制到另外服務(wù)器。服務(wù)器收到這更新日志后加入到自己Relay Log中，然后SQL執(zhí)行線程從Relay Log中讀取次日志并在本地?cái)?shù)據(jù)庫(kù)執(zhí)行一遍，從而實(shí)現(xiàn)主從數(shù)據(jù)庫(kù)同樣的數(shù)據(jù)。

主從復(fù)制

主從復(fù)制可以方便進(jìn)行讀寫分離，可以使用一主多從的方式保證高可用，如果從數(shù)據(jù)庫(kù)A掛了，可以將讀操作遷移到從數(shù)據(jù)庫(kù)完成高可用。

但是如果主數(shù)據(jù)庫(kù)掛了咋搞，那就MySQL的主主復(fù)制。可是不管上面說(shuō)的那種方式都不是提升它的存儲(chǔ)能力，這就需要進(jìn)行數(shù)據(jù)庫(kù)的分片了。

• 數(shù)據(jù)庫(kù)分片

將一張表分成若干片，其中每一片都包含一部分行記錄，然后將每一片存儲(chǔ)在不同的服務(wù)器中，這樣就實(shí)現(xiàn)一張表存放在多臺(tái)服務(wù)器中，哪都有哪些分片存儲(chǔ)的方案？

最開(kāi)始使用"硬編碼"的方式，此方式從字面上可以理解為直接在代碼中指定。假定表為用戶表，通過(guò)ID的奇偶存放在不同的服務(wù)器上，如下圖：

這種方式的缺點(diǎn)很明顯，當(dāng)需要增加服務(wù)器的時(shí)候，就需要改動(dòng)代碼，這就不友好了。比較常見(jiàn)的數(shù)據(jù)庫(kù)分片算法是通過(guò)余數(shù)Hash算法，根據(jù)主鍵ID和服務(wù)器的數(shù)量取模，根據(jù)余數(shù)確定服務(wù)器。

 

搜索引擎

我們使用谷歌瀏覽器的時(shí)候，輸入搜索關(guān)鍵字，就會(huì)出現(xiàn)搜索到多少條結(jié)果，用時(shí)多少，它是如何做到在如此短的時(shí)間完成這么大數(shù)據(jù)量的搜索。

先來(lái)想第一個(gè)問(wèn)題，全世界這么多網(wǎng)頁(yè)在哪里？

互聯(lián)網(wǎng)的存在讓你和我隔著屏幕都知道你多帥。當(dāng)然，每個(gè)網(wǎng)頁(yè)中都會(huì)存在很多其他網(wǎng)頁(yè)的超鏈接，這樣構(gòu)成了龐大的網(wǎng)絡(luò)。

對(duì)于搜索引擎而言，目標(biāo)為解析這些網(wǎng)頁(yè)獲取超鏈接，下載鏈接內(nèi)容(過(guò)濾)，具體一些說(shuō)。

將URL存放于池子中，從池子中取出URL模擬請(qǐng)求，下載對(duì)應(yīng)的html，并存放于服務(wù)器上，解析HTML內(nèi)容時(shí)如果有超鏈接URL，檢測(cè)是否已經(jīng)爬取過(guò)，如果沒(méi)有暫存隊(duì)列，后面再依次爬取。架構(gòu)圖如下：

爬蟲(chóng)常規(guī)方法

將獲取的所有網(wǎng)頁(yè)進(jìn)行編號(hào)并得到網(wǎng)頁(yè)集合。然后通過(guò)分詞技術(shù)獲得每一個(gè)單詞，組成矩陣如下所示：

分詞

就這樣按照單詞-文檔的方式組織起來(lái)就叫做倒排索引了。

倒排索引

google通過(guò)建立<單詞，地址>這樣的文檔，主要搜索到單詞就能定位到文檔的地址列表，然后根據(jù)列表中文檔的編號(hào)就展現(xiàn)文檔信息從而實(shí)現(xiàn)快速的檢索。

如果搜索出來(lái)結(jié)果很多，Google是如何能更精準(zhǔn)的將我們需要的信息呈現(xiàn)給我們呢。它很明顯有個(gè)排序功能，那是如何排序的？

Google使用了一種叫做"PageRank"的算法，通過(guò)計(jì)算每個(gè)網(wǎng)頁(yè)的權(quán)重，并按照權(quán)重排序，權(quán)重高的自然就在顯示在前面，那問(wèn)題來(lái)了，為啥權(quán)重高的，排在前面的通常就是用戶所需要的呢？這就得了解下pagerank算法了。

在pagerank中，如果網(wǎng)頁(yè)A包含網(wǎng)頁(yè)B說(shuō)明A認(rèn)可B，即投一票。如下圖ABCD四個(gè)網(wǎng)頁(yè)所示，箭頭代表超鏈接的方向，比如A->B代表A網(wǎng)頁(yè)包含B的超鏈接

pagerank

怎么計(jì)算的？

ABCD 初始值都為1，然后根據(jù)關(guān)系計(jì)算權(quán)重。比如此時(shí)B包含了AD兩個(gè)網(wǎng)頁(yè)，那么權(quán)重1被分為兩個(gè)1/2分別給A和D，此時(shí)A包含BCD，那么此時(shí)A頁(yè)面新的權(quán)重為1/2 + 1/3 + 1 = 11/6。

pagerank 值越受推薦，代表用戶越想看到。基于每個(gè)網(wǎng)頁(yè)的 pagerank 值對(duì)倒排索引中的文檔列表排序，靠前者則是用戶想看到的文檔。

這種是因?yàn)槌溄樱霗?quán)值的方式排序。還有其他諸如對(duì)于商品售賣次數(shù)排序或者電影點(diǎn)贊或評(píng)價(jià)分?jǐn)?shù)排序。

還有通過(guò)關(guān)鍵字查找，希望找到和搜索詞相關(guān)，這個(gè)時(shí)候可能就會(huì)采用詞頻TF進(jìn)行排序，詞頻代表所查詞和文檔的相關(guān)程度。

詞頻TF

比如我們搜索"Java后端"出現(xiàn)的結(jié)果以"后端"的相關(guān)技術(shù)。

在大部分的應(yīng)用中都會(huì)涉及到搜索引擎技術(shù)，技術(shù)龐大且復(fù)雜，希望各位老鐵根據(jù)自身情況搜索相關(guān)所需學(xué)習(xí)，校招面試中不出現(xiàn)盲點(diǎn)即可。

 

微服務(wù)

技術(shù)的引進(jìn)一定是想解決某個(gè)痛點(diǎn)。我不希望在一個(gè)系統(tǒng)中，一小點(diǎn)改動(dòng)就影響到全局，希望各個(gè)功能模塊拆分清晰，不管是測(cè)試還是運(yùn)維都能節(jié)省更多的時(shí)間。

那么單體的架構(gòu)出現(xiàn)了哪些問(wèn)題？

• 代碼分支管理困難

各個(gè)部門分別完成各自的任務(wù)，但是最后需要 merge 在一起成為整個(gè)系統(tǒng)，merge過(guò)程經(jīng)歷的人都知道，問(wèn)題是真XX多。所以不再是996

• 新增功能麻煩

隨著項(xiàng)目的效益越來(lái)越好，用戶的需求也更多，招聘的人可能更多，對(duì)于新手來(lái)說(shuō)上來(lái)是一臉懵逼的，老員工忙的要死，新員工成為了摸魚專家

• 耗盡連接

用戶的增多，每個(gè)應(yīng)用都得和數(shù)據(jù)庫(kù)連接，給數(shù)據(jù)庫(kù)的連接造成太大的壓力甚至耗盡連接

微服務(wù)

“微"-------微微一笑很傾城，微笑，微小。顧名思義，講一個(gè)大的系統(tǒng)，拆分為一個(gè)個(gè)小的服務(wù)，分別對(duì)各個(gè)小服務(wù)進(jìn)行管理。這樣說(shuō)感覺(jué)太不專業(yè)了，專業(yè)點(diǎn)

• 大應(yīng)用拆分為小模塊

• 小模塊不屬于集群中

• 通過(guò)遠(yuǎn)程調(diào)用的方式依賴各個(gè)獨(dú)立的模塊完成業(yè)務(wù)的處理

這些小的模塊就叫做------微服務(wù)，整體也就是所謂的微服務(wù)架構(gòu)。

既然拆分成了小服務(wù)，這么多小服務(wù)怎么協(xié)調(diào)成為一個(gè)問(wèn)題，甚至都不知道怎么掉這個(gè)服務(wù)，所以在微服務(wù)的整體架構(gòu)中出現(xiàn)了注冊(cè)中心，誰(shuí)需要調(diào)用使用提供的接口即可。如下圖所示：

注冊(cè)中心

從上圖我們能知道主要是三個(gè)概念：

• 服務(wù)提供者

微服務(wù)的具體提供者，其他微服務(wù)通過(guò)接口調(diào)用即可

• 服務(wù)消費(fèi)者

對(duì)應(yīng)于服務(wù)提供者，按照提供者接口編程即可。這么輕松的嘛，當(dāng)然很多細(xì)節(jié)。舉個(gè)例子，注明的dubbo服務(wù)框架，服務(wù)接口通過(guò)Dubbo框架代理機(jī)制訪問(wèn)Dubbo客戶端，客戶端通過(guò)服務(wù)接口聲明去注冊(cè)中心查看有哪些服務(wù)器，并將這服務(wù)器列表給客戶端。

客戶端然后根據(jù)負(fù)載均衡策略選擇其中一個(gè)服務(wù)器，通過(guò)遠(yuǎn)程調(diào)用的方式發(fā)送服務(wù)調(diào)用。那么使用微服務(wù)需要注重哪幾點(diǎn)？

選擇中的注意事項(xiàng)

不要拿工具硬上需求，結(jié)合業(yè)務(wù)也許會(huì)更佳！

 

高可用

高可用，意味著一臺(tái)機(jī)器掛了沒(méi)事，其他機(jī)器可以照常工作，用戶體驗(yàn)一樣倍棒，用戶壓根就不知道，臥槽，你居然升級(jí)了系統(tǒng)，我居然一點(diǎn)感受都沒(méi)有。那么高可用總有個(gè)標(biāo)準(zhǔn)吧，是百分之80就行還是90？

一個(gè)系統(tǒng)突然不能訪問(wèn)的原因很多：

• 硬件故障

• 數(shù)據(jù)庫(kù)宕機(jī)

• 磁盤孫歡

• bug

• 光纜斷了

可用性指標(biāo)

通過(guò)多少個(gè)9來(lái)衡量，比如大寶系統(tǒng)可用性為4個(gè)9，意味著是99.99%，說(shuō)明它的服務(wù)保證運(yùn)行時(shí)間只有0.01不可用。

高可用涉及到技術(shù)成本和設(shè)備成本，不是說(shuō)高可用值越高越好，而是根據(jù)具體工具具體場(chǎng)景而定，這里分享一些高可用策略。

冗余備份

任何一個(gè)服務(wù)都有備份，就反復(fù)我們都會(huì)對(duì)我們筆記本電腦相關(guān)文件進(jìn)行備份一樣，以防萬(wàn)一。即使一臺(tái)服務(wù)器掛了，可以很快的切換以致于讓用戶不會(huì)覺(jué)得"這系統(tǒng)怎么這么渣"。

負(fù)載均衡

使用多臺(tái)服務(wù)器分擔(dān)一臺(tái)服務(wù)器的壓力，滿足高并發(fā)的請(qǐng)求。怎么實(shí)現(xiàn)的呢，應(yīng)用程序會(huì)有一個(gè)心跳檢測(cè)/健康檢查機(jī)制，如果發(fā)現(xiàn)不妥切換即可。上面提到的數(shù)據(jù)庫(kù)主主復(fù)制也是高可用的方案之一，技術(shù)思想果然是相通的

負(fù)載均衡

限流降級(jí)

我們的目標(biāo)不是沒(méi)有蛀牙，而是希望整個(gè)系統(tǒng)不要掛掉。限流是對(duì)部分請(qǐng)求進(jìn)行丟棄處理，保證大部分的用戶可以正常的請(qǐng)求完成任務(wù)。

降級(jí)：

可以屏蔽部分當(dāng)前看來(lái)不是很有用的任務(wù)。比如電商系統(tǒng)做秒殺活動(dòng)的過(guò)程中，確認(rèn)收貨功能給予的壓力挺大，暫時(shí)看來(lái)并不是核心任務(wù)，而且系統(tǒng)到期也會(huì)自動(dòng)確認(rèn)收貨，所以暫時(shí)關(guān)閉，將系統(tǒng)的資源留給準(zhǔn)備下單，放購(gòu)物車的太太們

異地多活：

有時(shí)候我在想要是地震，火災(zāi)等自然災(zāi)害發(fā)生的時(shí)候，很多系統(tǒng)的數(shù)據(jù)怎么辦啊。想多了撒，大些的系統(tǒng)多會(huì)在各個(gè)地方部署數(shù)據(jù)中心，采用異地多活的多機(jī)房策略。用戶可以訪問(wèn)任何數(shù)據(jù)中心，那問(wèn)題來(lái)了，用戶的請(qǐng)求是如何到達(dá)不同的機(jī)房去的？

• 域名解析

 

安全性

公司中的數(shù)據(jù)財(cái)產(chǎn)，其重要程度不言而喻。系統(tǒng)的健壯性和安全性是保證系統(tǒng)持久運(yùn)行的基礎(chǔ)。不要因?yàn)閿?shù)據(jù)泄露才去關(guān)注安全問(wèn)題。

也許說(shuō)到安全問(wèn)題，首先想到的是“用戶名密碼”泄漏，數(shù)據(jù)庫(kù)被脫褲導(dǎo)致數(shù)據(jù)泄露，hack直接拿到用戶的敏感信息，所以我們通常有哪些手段或方法來(lái)盡全力的抵抗hack嘞，辦法總比問(wèn)題多嘛。

• 數(shù)據(jù)加解密

通過(guò)對(duì)用戶密碼，身份證等敏感數(shù)據(jù)加密是常用方法。加密方法通常分為：?jiǎn)蜗蛏⒘屑用埽瑢?duì)稱加密和非對(duì)稱加密。

所謂單向散列加密，主要體現(xiàn)在單向二字，意味著對(duì)明文加密后是不可以解密，你即使是給明文加密的加密者，也無(wú)法通過(guò)密文知道其明文是什么，即加密單向，不支持解密。說(shuō)的這么絕對(duì)？這么無(wú)敵？

那只是理論上而已，常用的MD5算法就是大象散列加密，我們完全可以通過(guò)彩虹表等方式進(jìn)行破解。怎么破解？

說(shuō)個(gè)簡(jiǎn)單的道理，我們?cè)O(shè)置密碼的時(shí)候，通常會(huì)使用生日？手機(jī)號(hào)？什么love？什么520？，這些組合是有限的，我們就可以建立一個(gè)比如生日和密文的映射表，然后通過(guò)XX彩虹表就可得到密碼明文。

單向散列加密

所以，通常的情況，使用單向散列加密的時(shí)候需要加一點(diǎn)鹽，這樣一來(lái)，hack拿到密文，不知道鹽，無(wú)法建立彩虹表，就更難還原明文。

應(yīng)用場(chǎng)景：通常應(yīng)用在用戶密碼加密。其加密和校驗(yàn)過(guò)程如下：

應(yīng)用場(chǎng)景

我們通過(guò)上圖來(lái)回顧一下一個(gè)網(wǎng)站的注冊(cè)登錄模塊中的用戶部分，用戶注冊(cè)需要輸入用戶名和密碼，我們一般不會(huì)將裸露的將密碼直接存放在數(shù)據(jù)庫(kù)，不然被脫褲直接算裸奔。

所以，用戶輸入密碼，應(yīng)用服務(wù)器獲得密碼后，調(diào)用單向散列加密算法，將加密的密文存放于數(shù)據(jù)庫(kù)，用戶下一次登錄的時(shí)候，用戶依然會(huì)輸入密碼。

只是到了Web服務(wù)器后，Web服務(wù)器會(huì)對(duì)輸入的密碼再進(jìn)行一次單向散列加密，然后和數(shù)據(jù)庫(kù)中取出來(lái)的密文進(jìn)行對(duì)比，如果相同，則用戶的驗(yàn)證成功，通常這樣的方式可以保證用戶密碼的安全性，當(dāng)然如果加一點(diǎn)鹽，會(huì)增加破解的難度。

對(duì)稱加密

對(duì)稱加密是通過(guò)一個(gè)加密算法和密鑰，對(duì)一段明文進(jìn)行加密后得到密文，然后使用相同的密鑰和對(duì)應(yīng)的解密算法進(jìn)行解密得到明文。

對(duì)稱加密

舉個(gè)例子，我們不會(huì)將銀行卡卡號(hào)，有效期等直接存儲(chǔ)在數(shù)據(jù)庫(kù)，而是會(huì)通過(guò)先加密，然后存儲(chǔ)于數(shù)據(jù)庫(kù)。

使用的時(shí)候必須對(duì)密文進(jìn)行解密還原出明文。這個(gè)時(shí)候使用對(duì)稱加密算法，存儲(chǔ)的時(shí)候加密算法進(jìn)行加密，使用的時(shí)候解密算法解密。

非對(duì)稱加密

非對(duì)稱加密是說(shuō)使用一個(gè)加密算法和一個(gè)加密秘鑰進(jìn)行加密得到密文，但是在解密出明文的時(shí)候，其加解密密鑰和加密密鑰不同，通常加密密鑰叫做公鑰，解密密鑰叫做私鑰。

非對(duì)稱加密

其實(shí)我們常用的 HTTPS 即是非對(duì)稱加密的應(yīng)用場(chǎng)景。用戶在客戶端進(jìn)行通訊的時(shí)候，對(duì)數(shù)據(jù)使用的加密密鑰和加密算法進(jìn)行加密得到密文，到了服務(wù)端以后，使用解密密鑰和算法進(jìn)行解密得到明文。

但是非對(duì)稱消耗的資源比較多，所以HTTPS不是每次請(qǐng)求響應(yīng)都采用非對(duì)稱加密，而是先利用非對(duì)稱加密，在客戶單和服務(wù)器之間交換一個(gè)對(duì)稱加密的密鑰，然后每次的請(qǐng)求響應(yīng)再使用對(duì)稱加密。

綜上，使用費(fèi)對(duì)稱加密保證對(duì)稱加密迷藥的安全，使用對(duì)稱加密密鑰保證請(qǐng)求響應(yīng)數(shù)據(jù)的安全。

HTTP攻擊與防護(hù)

HTTP明文協(xié)議，咋們通過(guò)嗅探工具就可以清晰查看會(huì)話內(nèi)容，這也是hack攻擊門檻最低的方式。很常見(jiàn)的也就是SQL注入和XSS攻擊。

SQL注入是攻擊者在提交請(qǐng)求參數(shù)的時(shí)候，包含了惡意的SQL腳本：

SQL注入

server處理計(jì)算后向數(shù)據(jù)庫(kù)提交的SQL如下：

Select id from users where username='Mike';

如果是惡意攻擊，提交的HTTP請(qǐng)求如下：

http://www.a.com?username=Mike';drop table users;--

此時(shí)最終生成的SQL是：

Select id from users where username='Mike';drop table users;--';

查詢完就直接給刪除表了。怎么防護(hù)？

比較常用的解決方案是使用PrepareStaement預(yù)編譯，先將SQL交給數(shù)據(jù)庫(kù)生成執(zhí)行計(jì)劃，后面hack不管提交什么字符串也只能交給這個(gè)執(zhí)行計(jì)劃執(zhí)行，不會(huì)生成新的SQL，也就不會(huì)被攻擊啦。

XSS攻擊

跨站點(diǎn)腳本攻擊，攻擊者通過(guò)構(gòu)造惡意的瀏覽器腳本文件，使其在其他用戶的瀏覽器運(yùn)行進(jìn)而進(jìn)行攻擊。

假設(shè)小A將含有惡意腳本的請(qǐng)求給360服務(wù)器，服務(wù)器將惡意的腳本存儲(chǔ)在本地的數(shù)據(jù)庫(kù)，當(dāng)其他正常用戶通過(guò)這個(gè)服務(wù)器瀏覽信息的時(shí)候，服務(wù)器就會(huì)讀取數(shù)據(jù)庫(kù)中含有惡意腳本的數(shù)據(jù)并呈現(xiàn)給用戶，在用戶正常使用瀏覽器的時(shí)候達(dá)到攻擊的目的。

防御：

比較常見(jiàn)的是在入口處對(duì)危險(xiǎn)的請(qǐng)求比如drop table等進(jìn)行攔截，設(shè)置一個(gè)Web應(yīng)用防火墻將危險(xiǎn)隔離。

安全防御

 

大數(shù)據(jù)

其實(shí)在上面提到的分布式中就有涉及大數(shù)據(jù)相關(guān)知識(shí)。無(wú)外乎是數(shù)據(jù)量越來(lái)越大，我們?nèi)绾伪M可能使用較低的成本存儲(chǔ)更多的數(shù)據(jù)，給公司企業(yè)帶來(lái)更好的利潤(rùn)。上面說(shuō)過(guò)分布式緩存，負(fù)載均衡等技術(shù)，其共同特點(diǎn)是如何抵抗高并發(fā)的壓力，而這里的大數(shù)據(jù)技術(shù)主要談?wù)摰氖侨绾螡M足大規(guī)模的計(jì)算。

通過(guò)對(duì)數(shù)據(jù)的分析，進(jìn)而發(fā)掘海量數(shù)據(jù)中的價(jià)值，這里的數(shù)據(jù)包含數(shù)據(jù)庫(kù)數(shù)據(jù)，日志信息，用戶行為數(shù)據(jù)等等。那么這么多不同類型的數(shù)據(jù)，怎么去存儲(chǔ)呢？

分布式文件存儲(chǔ) HDFS 架構(gòu)

如何將數(shù)以萬(wàn)計(jì)的服務(wù)器組成統(tǒng)一的文件存儲(chǔ)系統(tǒng)？其中使用Namenode服務(wù)器作為控制塊，負(fù)責(zé)元數(shù)據(jù)的管理(記錄文件名，訪問(wèn)權(quán)限，數(shù)據(jù)存儲(chǔ)地址等)，而真正的文件存儲(chǔ)在DataNode中。

Mapreduce

大量的數(shù)據(jù)存儲(chǔ)下來(lái)的目的是通過(guò)相應(yīng)的算法進(jìn)行數(shù)據(jù)分析，獲得通過(guò)深度學(xué)習(xí)/機(jī)器學(xué)習(xí)進(jìn)行預(yù)測(cè)，從而獲取有效的價(jià)值，這么大的文件，我們不可能將HDFS當(dāng)做普通的文件，從文件中讀取數(shù)據(jù)然后計(jì)算，這樣子不知道算到何時(shí)何地。

大數(shù)據(jù)處理經(jīng)典的處理框架即MapReduce，分為Map和Reduce兩個(gè)階段，其中一個(gè)Map過(guò)程是將每個(gè)服務(wù)器上啟動(dòng)Map進(jìn)程，計(jì)算后輸出一個(gè)

下面以wordCount統(tǒng)計(jì)所有數(shù)據(jù)中相同的詞頻數(shù)據(jù)為例，詳細(xì)看看Map和Reduce的過(guò)程。

wordcoun計(jì)算過(guò)程

在這個(gè)例子中，通過(guò)對(duì)value中的1組成的列表，reduce對(duì)這些1進(jìn)行求和操作從而得到每個(gè)單詞的詞頻。代碼實(shí)現(xiàn)如下：

public class WordCount {

// MApper四個(gè)參數(shù)：第一個(gè)Object表示輸入key的類型；第二個(gè)Text表示輸入value的類型；第三個(gè)Text表示表示輸出鍵的類型；第四個(gè)IntWritable表示輸出值的類型。map這里的輸出是指輸出到reduce

public static class doMapper extends Mapper<Object, Text, Text, IntWritable> {

public static final IntWritable one = new IntWritable(1);//這里的IntWritable相當(dāng)于Int類型

public static Text word = new Text;//Text相當(dāng)于String類型

// map參數(shù)<keyIn key,valueIn value,Context context>，將處理后的數(shù)據(jù)寫入context并傳給reduce

protected void map(Object key, Text value, Context context) throws IOException, InterruptedException {

//StringTokenizer是Java工具包中的一個(gè)類，用于將字符串進(jìn)行拆分

StringTokenizer tokenizer = new StringTokenizer(value.toString, " ");

//返回當(dāng)前位置到下一個(gè)分隔符之間的字符串

word.set(tokenizer.nextToken);

//將word存到容器中，記一個(gè)數(shù)

context.write(word, one);

}

}

//參數(shù)同Map一樣，依次表示是輸入鍵類型，輸入值類型，輸出鍵類型，輸出值類型。這里的輸入是來(lái)源于map,所以類型要與map的輸出類型對(duì)應(yīng) 。

public static class doReducer extends Reducer<Text, IntWritable, Text, IntWritable> {

private IntWritable result = new IntWritable;

@Override

protected void reduce(Text key, Iterable<IntWritable> values, Context context)

throws IOException, InterruptedException {

int sum = 0;

//for循環(huán)遍歷，將得到的values值累加

for (IntWritable value : values) {

sum += value.get;

}

result.set(sum);

context.write(key, result);//將結(jié)果保存到context中，最終輸出形式為"key" + "result"

}

}

public static void main(String[] args) throws IOException, ClassNotFoundException, InterruptedException {

System.out.println("start");

Job job = Job.getInstance;

job.setJobName("wordCount");

Path in = new Path("hdfs://***:9000/user/hadoop/input/buyer_favorite1.txt");//設(shè)置這個(gè)作業(yè)輸入數(shù)據(jù)的路徑(***部分為自己liunx系統(tǒng)的localhost或者ip地址)

Path out = new Path("hdfs://***:9000/user/hadoop/output/wordCount"); //設(shè)置這個(gè)作業(yè)輸出結(jié)果的路徑

FileInputFormat.addInputPath(job, in);

FileOutputFormat.setOutputPath(job, out);

job.setJarByClass(WordCount.class);// 設(shè)置運(yùn)行/處理該作業(yè)的類

job.setMapperClass(doMapper.class);//設(shè)置實(shí)現(xiàn)了Map步的類

job.setReducerClass(doReducer.class);//設(shè)置實(shí)現(xiàn)了Reduce步的類

job.setOutputKeyClass(Text.class);//設(shè)置輸出結(jié)果key的類型

job.setOutputValueClass(IntWritable.class);//設(shè)置輸出結(jié)果value的類型

////執(zhí)行作業(yè)

System.exit(job.waitForCompletion(true) ? 0 : 1);

System.out.println("end");

}

}

那么這個(gè)map和reduce進(jìn)程是怎么在分布式的集群中啟動(dòng)的呢？

map/reduce啟動(dòng)過(guò)程

上圖比較清晰地闡述的整個(gè)過(guò)程，再描述一波。MR中主要是兩種進(jìn)程角色，分別為 JobTracke r和 TaskTracker 兩種。

JobTracker在集群中只有一個(gè)，而 TaskTracker 存在多個(gè)，當(dāng) JobClient 啟動(dòng)后，往 JobTracker 提交作業(yè)，JobTracker查看文件路徑?jīng)Q定在哪些服務(wù)器啟動(dòng) Map 進(jìn)程。

然后發(fā)送命令給 TaskTracker，告訴它要準(zhǔn)備執(zhí)行任務(wù)了，TaskTracker收到任務(wù)后就會(huì)啟動(dòng) TaskRunner 下載任務(wù)對(duì)應(yīng)的程序。

map計(jì)算完成，TaskTracker對(duì)map輸出結(jié)果 shuffer 操作然后加載 reduce 函數(shù)進(jìn)行后續(xù)計(jì)算，這就是各個(gè)模塊協(xié)同工作的簡(jiǎn)單過(guò)程。

 

Hive

上述過(guò)程還是比較麻煩，我們能不能直接寫SQL，然后引擎幫助我們生成mapreduce代碼，就反復(fù)我們?cè)趙eb開(kāi)發(fā)的時(shí)候，不直接寫SQL語(yǔ)句，直接交給引擎那么方便，有的，它就是HIVE。

舉個(gè)例子：

SQL

拆分

那么使用MR的計(jì)算過(guò)程完成這條SQL的處理：

MR TO SQL

 

Spark

Spark是基于內(nèi)存計(jì)算的大數(shù)據(jù)并行計(jì)算框架。基于此說(shuō)說(shuō)上面hadoop中組件的缺點(diǎn)：

• 磁盤IO開(kāi)銷大。每次執(zhí)行都需要從磁盤讀取并且計(jì)算完成后還需要將將中間結(jié)果存放于磁盤

• 表達(dá)能力有限。大多數(shù)計(jì)算都需要轉(zhuǎn)換為Map和Reduce兩個(gè)操作，難以描述復(fù)雜的數(shù)據(jù)處理

spark優(yōu)點(diǎn)：

• 編程模型不限于map和reduce，具有更加靈活的編程模型

• spark提供內(nèi)存計(jì)算，帶來(lái)更高的迭代運(yùn)算效率且封裝了良好的機(jī)器學(xué)習(xí)算法

• 采用了基于圖DAG的任務(wù)調(diào)度機(jī)制

Flink

Flink是大數(shù)據(jù)處理的新規(guī)，發(fā)展速度之快，這兩年也相繼出現(xiàn)中文資料。作為流式數(shù)據(jù)流執(zhí)行引擎，針對(duì)數(shù)據(jù)流的分布式計(jì)算提供數(shù)據(jù)分布，數(shù)據(jù)通信以及容錯(cuò)機(jī)制等功能。同時(shí)Flink也提供了機(jī)器學(xué)習(xí)庫(kù)，圖計(jì)算庫(kù)等。

附一張去年參加會(huì)議回答問(wèn)題中獎(jiǎng)的馬克杯，嘻嘻。

去年參會(huì)

關(guān)于大數(shù)據(jù)相關(guān)知識(shí)點(diǎn)可作為擴(kuò)充點(diǎn)，在面試的過(guò)程中經(jīng)常會(huì)有大數(shù)問(wèn)題，除了從算法的角度來(lái)闡述，也可以從這些框架中吸取一些經(jīng)驗(yàn)。

 

嘮嗑

對(duì)于之前從事c/c++開(kāi)發(fā)的我，很多時(shí)候是linux的開(kāi)發(fā)。在學(xué)校又沒(méi)怎么接觸系統(tǒng)性的項(xiàng)目，更不知道后端技術(shù)的博大進(jìn)深，可能文中涉及的也就一部分，不過(guò)希望還在學(xué)校的小伙伴可以知道有這些東西，然后通過(guò)強(qiáng)大的搜索引擎，給自己個(gè)比較明確的方向，也許會(huì)少走點(diǎn)彎路，這周的文章就到這了，goodbye！