叮。。。。。美團(tuán)來(lái)電。這次不是外賣而是電話面試。所報(bào)崗位為后端/服務(wù)端開發(fā)，但是從我的復(fù)盤來(lái)看，這和 Java 后端開發(fā)的內(nèi)容差不多，除了部分的語(yǔ)言特性外，還是四大件基礎(chǔ)知識(shí)為重，下面我們來(lái)看看都問(wèn)了啥，小心下次面你的時(shí)候就有這些問(wèn)題哦

如果你問(wèn)我，看了這些題就完事了？非也，這只是開始，你需要學(xué)習(xí)的還有很多，知道路子是怎么走才是重要的勒。

開始之前，我們先看提綱，大家默默的想一想，如果是你，你將怎么去回答這個(gè)問(wèn)題，然后再看我的回答也許更佳哈。

提綱

1 一面(40分鐘)

• 自我介紹

老規(guī)矩，我叫啥，啥專業(yè)，技術(shù)棧是啥，能做啥

• 怎么理解分布式

其實(shí)如果沒(méi)有去實(shí)習(xí)，可能很少接觸分布式的內(nèi)容。對(duì)于面試官而言，也沒(méi)多期望你們對(duì)分布式的理解到多深的地步，只是希望你們能對(duì)其有個(gè)初步的了解即可。

不管是高登摩爾提出的摩爾定律還是Gordon Moore堅(jiān)持的2版本是啥，總之如果你的系統(tǒng)需承載的計(jì)算量的增長(zhǎng)速度大于摩爾定律的預(yù)測(cè)，那么在未來(lái)的某一個(gè)時(shí)間點(diǎn)，集中式系統(tǒng)將無(wú)法承載你所需的計(jì)算 量。

在整個(gè)計(jì)算機(jī)系統(tǒng)發(fā)展的過(guò)程中，最實(shí)際的還是經(jīng)濟(jì)的元素。人們發(fā)現(xiàn)使用更加廉價(jià)的機(jī)器，組合在一起的分布式系統(tǒng)，除了可以獲得超過(guò)CPU發(fā)展速度的性能以外，還可以有更好的性價(jià)比，所以得出如下結(jié)論：

無(wú)論是要以低價(jià)格獲得普通的性能，還是要以較高的價(jià)格獲 得極高的性能，分布式系統(tǒng)都能夠滿足。并且受規(guī)模效應(yīng)的影響，系統(tǒng)越大，性價(jià)比帶來(lái) 的收益越高。

隨著計(jì)算機(jī)的飛速發(fā)展，科學(xué)家們發(fā)現(xiàn)分布式系統(tǒng)相比于集中式系統(tǒng)的另一個(gè)很明顯的優(yōu)勢(shì)就是：具有更高的可用性。假設(shè)使用10個(gè)能夠承載10000流量相同的節(jié)點(diǎn)，其中的兩個(gè)節(jié)點(diǎn)掛了，只要實(shí)際的流量不超過(guò)8000，那么系統(tǒng)仍然正常運(yùn)轉(zhuǎn)。

說(shuō)這么多，分布式系統(tǒng)還是建立在「分治」和「冗余」的基礎(chǔ)上，這也就是分布式系統(tǒng)的本質(zhì)

那么分治是什么？

這和我們大腦解決問(wèn)題類似，大問(wèn)題分解為小問(wèn)題，然后治理最后歸并。

分治

為什么要這樣做？

• 小問(wèn)題容易解決，解決了眾多的子問(wèn)題，大問(wèn)題也就更容易解決啦

如果拆分的父子問(wèn)題有依賴關(guān)系怎么辦？

大問(wèn)題拆分的過(guò)程中，非常重要的即不同分支的子問(wèn)題不能相互依賴，需要各自獨(dú)立，因?yàn)槿绻嬖谝蕾囮P(guān)系，父子問(wèn)題就失去了「歸并」的意義，那么在開發(fā)中，這就是「聚合度」和「內(nèi)聚度」的問(wèn)題。

什么是聚合度和內(nèi)聚度？

所謂聚合度即軟件系統(tǒng)中各個(gè)模塊的相互依賴程度。比如在調(diào)用A方法的時(shí)候都需要同步調(diào)用方法B，顯然這樣的耦合度就高

所謂內(nèi)聚度即模塊之間具有共同點(diǎn)的相似程度，所以在拆分的時(shí)候要尤其注意這兩點(diǎn)。

什么是冗余？

這里的冗余不是代碼的冗余，而是容許系統(tǒng)在一定范圍內(nèi)出現(xiàn)故障，但對(duì)系統(tǒng)的影響很小

冗余

如上圖將冗余的節(jié)點(diǎn)部署在單獨(dú)的服務(wù)器，完全是為了備用而做的冗余，如果不出現(xiàn)故障，那么資源是不是就浪費(fèi)了，所以大多數(shù)情況會(huì)使用諸如雙主多活、讀寫分離之類的概念提高資源利用率

其實(shí)在生活中冗余也很常見(jiàn)，比如大部分的汽車系統(tǒng)中的底層控制系統(tǒng)也是有冗余機(jī)制，飛機(jī)發(fā)動(dòng)機(jī)為什么是偶數(shù)，也是同樣的道理。還有更多的關(guān)于后端的基礎(chǔ)總結(jié)要點(diǎn)則參考另一篇文章42圖揭秘，「后端技術(shù)學(xué)些啥」

寫個(gè)代碼熱熱身----棧實(shí)現(xiàn)隊(duì)列

class?MyQueue?{ public:stack<int>?stIn;stack<int>?stOut;/**?Initialize?your?data?structure?here.?*/MyQueue()?{}/**?Push?element?x?to?the?back?of?queue.?*/void?push(int?x)?{stIn.push(x);}/**?Removes?the?element?from?in?front?of?queue?and?returns?that?element.?*/int?pop()?{//?只有當(dāng)stOut為空的時(shí)候，再?gòu)膕tIn里導(dǎo)入數(shù)據(jù)（導(dǎo)入stIn全部數(shù)據(jù)）if?(stOut.empty())?{//?從stIn導(dǎo)入數(shù)據(jù)直到stIn為空while(!stIn.empty())?{stOut.push(stIn.top());stIn.pop();}}int?result?=?stOut.top();stOut.pop();return?result;}/**?Get?the?front?element.?*/int?peek()?{int?res?=?this->pop();?//?直接使用已有的pop函數(shù)stOut.push(res);?//?因?yàn)閜op函數(shù)彈出了元素res，所以再添加回去return?res;}/**?Returns?whether?the?queue?is?empty.?*/bool?empty()?{return?stIn.empty()?&&?stOut.empty();} };

介紹下第一個(gè)項(xiàng)目

注意：校招的的面試在我看來(lái)寫兩個(gè)項(xiàng)目差不多了，印象更深刻且自己的理解程度更好的放在上面。面試之前一定要搞懂這三個(gè)問(wèn)題，且在練習(xí)的時(shí)候想想怎么能引面試官上鉤

• 項(xiàng)目的描述

• 自己在項(xiàng)目中擔(dān)任的角色，做了什么

• 在項(xiàng)目中遇到什么難點(diǎn)，怎么處理，有沒(méi)有測(cè)試過(guò)

說(shuō)說(shuō)快排思想？

如果我們的每一次分區(qū)操作都能正好將數(shù)組分成大小接近相等的兩個(gè)小區(qū)間，那么快排的時(shí)間復(fù)雜度和歸并是差不多的，所以其時(shí)間復(fù)雜度為O(nlogn)

這里特別注意所謂的每次分區(qū)操作有個(gè)前提條件，即選擇的pivot很合適，能掙好的將大區(qū)間對(duì)等的一分為二，如果原來(lái)的數(shù)據(jù)是一件排好序的，我們選擇最后一個(gè)元素為pivot，這樣每次分區(qū)得到的兩個(gè)區(qū)間是不均等，我們需要進(jìn)行大約n次分區(qū)操作，每次分區(qū)平均掃描n/2個(gè)元素，此時(shí)的復(fù)雜度將退化為0(n ^ 2)

注：一定要能手撕快排啊，這真是無(wú)數(shù)次會(huì)被考！！！

public?class?QuickSort?{public?static?void?main(String[]?args)?{int[]?arr?=?{?49,?38,?65,?97,?23,?22,?76,?1,?5,?8,?2,?0,?-1,?22?};quickSort(arr,?0,?arr.length?-?1);System.out.println("排序后:");for?(int?i?:?arr)?{System.out.println(i);}}private?static?void?quickSort(int[]?arr,?int?low,?int?high)?{if?(low?<?high)?{//?找尋基準(zhǔn)數(shù)據(jù)的正確索引int?index?=?getIndex(arr,?low,?high);//?進(jìn)行迭代對(duì)index之前和之后的數(shù)組進(jìn)行相同的操作使整個(gè)數(shù)組變成有序//quickSort(arr,?0,?index?-?1);?之前的版本，這種姿勢(shì)有很大的性能問(wèn)題，謝謝大家的建議quickSort(arr,?low,?index?-?1);quickSort(arr,?index?+?1,?high);}}private?static?int?getIndex(int[]?arr,?int?low,?int?high)?{//?基準(zhǔn)數(shù)據(jù)int?tmp?=?arr[low];while?(low?<?high)?{//?當(dāng)隊(duì)尾的元素大于等于基準(zhǔn)數(shù)據(jù)時(shí),向前挪動(dòng)high指針while?(low?<?high?&&?arr[high]?>=?tmp)?{high--;}//?如果隊(duì)尾元素小于tmp了,需要將其賦值給lowarr[low]?=?arr[high];//?當(dāng)隊(duì)首元素小于等于tmp時(shí),向前挪動(dòng)low指針while?(low?<?high?&&?arr[low]?<=?tmp)?{low++;}//?當(dāng)隊(duì)首元素大于tmp時(shí),需要將其賦值給higharr[high]?=?arr[low];}//?跳出循環(huán)時(shí)low和high相等,此時(shí)的low或high就是tmp的正確索引位置//?由原理部分可以很清楚的知道low位置的值并不是tmp,所以需要將tmp賦值給arr[low]arr[low]?=?tmp;return?low;?//?返回tmp的正確位置} }

半連接了解吧，如果SYN半連接隊(duì)列滿了怎么處理，只能丟棄連接？

如果你看過(guò)我之前寫的文章，這個(gè)問(wèn)題應(yīng)該就非常容易解決了。SYN半連接隊(duì)列已滿，通過(guò)開啟cookies功能就可以在不使用SYN隊(duì)列的情況下成功建立連接

syncookies是怎么操作的？

服務(wù)端返回 ACK 的時(shí)候會(huì)計(jì)算一個(gè)值放在發(fā)出的SYN+ACK報(bào)文中，當(dāng)客戶端返回ACK的時(shí)候取出該值進(jìn)行驗(yàn)證，如果合法即連接成功

半連接隊(duì)列

Linux如何開啟syncookies呢？

通過(guò)將參數(shù)tcp_cookies設(shè)置1即可。如果參數(shù)值為2，表示無(wú)條件開啟這個(gè)功能。如果為1表示僅當(dāng)SYN半連接隊(duì)列放不下的時(shí)候，再開啟。

開啟syncookies

那可不可以繞過(guò)三次握手?

還有這種操作？

三次握手中，一個(gè)較大的問(wèn)題是HTTP請(qǐng)求必須在一次的RTT后才能發(fā)送。從而谷歌提出了TFO。想要繞過(guò)三次握手過(guò)程，如果是客戶端發(fā)起連接，想要在SYN的請(qǐng)求報(bào)文中放入數(shù)據(jù)，需要得到服務(wù)端的認(rèn)可，所以事先需要有個(gè)約定。

• 首次建立連接走正常的三次握手，客戶端會(huì)在SYN報(bào)文中明確告訴服務(wù)器要使用TFO功能，服務(wù)端答應(yīng)后就會(huì)將客戶端的IP地址用自己的密鑰加密(cookie)攜帶在返回的SYN+ACK中，客戶端收到后將cookie緩存到本地

• 下次客戶端再建立連接，就可以在SYN中攜帶請(qǐng)求的數(shù)據(jù)+緩存的cookie

繞過(guò)三次握手

剛才你說(shuō)的密鑰是不會(huì)變的？

當(dāng)然變化，不然就很容易產(chǎn)生SYN泛洪攻擊了。

Linux中如何打開TFO?

這里要注意了，需要客戶端和服務(wù)端都支持，TFO才會(huì)生效，當(dāng)tcp_fastopen設(shè)置為3的時(shí)候才生效

net.ipv4.tcp_fastopen=3

舉幾個(gè)使用緩存的例子

這里涉及面就非常廣了，什么數(shù)據(jù)庫(kù)緩存，如何選擇緩存的讀寫策略，如何做到緩存高可用，緩存穿透的怎么處理以及CDN相關(guān)，我們先舉幾個(gè)緩存的例子

• 我們知道虛擬地址到物理地址轉(zhuǎn)換的時(shí)候需要通過(guò)一個(gè)叫做MMU的硬件，每次這樣的轉(zhuǎn)換無(wú)疑會(huì)造成性能的轉(zhuǎn)換，所以接住了TLB來(lái)緩存最近轉(zhuǎn)換過(guò)的，下一次轉(zhuǎn)換的時(shí)候，如果緩存存在就直接轉(zhuǎn)換即可

• 在路由尋址的時(shí)候，會(huì)有個(gè)映射表讓我們知道該訪問(wèn)哪個(gè)目的地址，同樣存在于緩存中

• HTTP緩存機(jī)制。通過(guò)緩存協(xié)商方式減少網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)大小從而提升頁(yè)面展示的性能

緩存怎么個(gè)分類？

緩存分類分為三種，分別為靜態(tài)緩存、分布式緩存與本地緩存。

靜態(tài)緩存

通常使用靜態(tài)HTML實(shí)現(xiàn)靜態(tài)緩存。通過(guò)在Nginx上部署靜態(tài)緩存減少對(duì)于后臺(tái)應(yīng)用服務(wù)器的壓力。當(dāng)然你也可以存放數(shù)據(jù)庫(kù)，然后前端穿透查詢，但是對(duì)于后端的服務(wù)器壓力是非常大的。比如內(nèi)容系統(tǒng)，通常在錄入文章的時(shí)候先渲染成靜態(tài)頁(yè)面，然后放在前端Ngix服務(wù)器上，這樣用戶會(huì)直接訪問(wèn)前端靜態(tài)頁(yè)面，但是如果是動(dòng)態(tài)請(qǐng)求，這樣就需要分布式緩存了

分布式緩存

面試中高頻的Redis和Memchache，就是通過(guò)集群的方式突破單機(jī)瓶頸

熱點(diǎn)本地緩存

熱點(diǎn)嘛，微博每天都有熱點(diǎn)，尤其是什么XX明星出軌，這樣的查詢通常會(huì)命中某一個(gè)緩存節(jié)點(diǎn)，短時(shí)間內(nèi)極高的緩存熱點(diǎn)查詢。這個(gè)時(shí)候就會(huì)在代碼中使用一些本地本地緩存方案。如hashmap

緩存的不足

從上面基本上知道，緩存的主要作用是提升訪問(wèn)的速度，提升并發(fā)的能力。

• 緩存最好適用于讀多寫少且?guī)в幸欢ǖ臒狳c(diǎn)屬性

因?yàn)榧热皇蔷彺媸芟抻诖鎯?chǔ)介質(zhì)，不可能緩存所有數(shù)據(jù)，只有當(dāng)數(shù)據(jù)有一定的熱點(diǎn)屬性才能有更高的緩存命中率

• 緩存讓系統(tǒng)更加復(fù)雜，容易出現(xiàn)數(shù)據(jù)不一致的現(xiàn)象

比如更新數(shù)據(jù)庫(kù)成功了，但是更新緩存失敗了。這個(gè)時(shí)候可以考慮固定時(shí)間清理或者手動(dòng)清理。

• 給運(yùn)維帶來(lái)一定的成本

運(yùn)維小哥需要了解一些緩存組件的使用

一面小結(jié)

一面面試涉及到了項(xiàng)目，計(jì)算機(jī)網(wǎng)絡(luò)，數(shù)據(jù)結(jié)構(gòu)和后端的基本知識(shí)，也基本覆蓋了校招的各科且有一定的是實(shí)踐性考察，不同公司面試當(dāng)然不一樣，看多了你會(huì)發(fā)現(xiàn)重點(diǎn)就是這些了，繼續(xù)復(fù)盤二面

2 二面

慢慢的到了10月，面試的越多不知道的越多，感覺(jué)需要學(xué)習(xí)的越多，當(dāng)然越戰(zhàn)越勇，面完一面是一面，積累一面是一面。團(tuán)團(tuán)既然給臉，那就面唄

寫個(gè)代碼-----數(shù)組中數(shù)字出現(xiàn)的次數(shù)

我擦，上來(lái)就是寫代碼，不過(guò)大家習(xí)慣就好，每個(gè)面試官套路不同，資本社會(huì)接受即可，寫唄，準(zhǔn)備這么久的你還怕啥。管他三七二十一，能上位運(yùn)算就上位運(yùn)算，盤它完事，小伙伴說(shuō)能不能寫個(gè)python版本，那就py唄。如果這個(gè)題目還要猶豫，趕緊再去練練《劍指offer》和leetcode100題呀

class?Solution(object):def?singleNumbers(self,?nums):""":type?nums:?List[int]:rtype:?List[int]"""temp?=?0for?i?in?nums:#得到用于區(qū)分的數(shù)字temp?^=?inum?=?1while?not?(num?&?temp):#找到用于區(qū)分的數(shù)字中從右到左的第一位為1的值num?=?num?<<?1result1?=?0result2?=?0for?i?in?nums:if?num?&?i:#?劃分兩個(gè)數(shù)組result1?^=?i#兩個(gè)數(shù)組分別取異或else:result2?^=?ireturn[result1,result2]?

說(shuō)說(shuō)TCP的收發(fā)包可通過(guò)哪些配置？

這個(gè)題就有點(diǎn)大了，我可以扯很久，而且只要問(wèn)到TCP發(fā)送或者接受的類似問(wèn)題，真是可以大干好幾百個(gè)回合。在這里就稍微詳細(xì)的說(shuō)說(shuō)，在以后的面試過(guò)程中，遇到此題講不在多說(shuō)哈，還答不上來(lái)就打自己幾耳巴可好，別別，還是不能這么對(duì)自己，好了，不多BB了，上干貨

收包是數(shù)據(jù)到達(dá)網(wǎng)卡后交給應(yīng)用程序處理的過(guò)程，發(fā)包則調(diào)用相應(yīng)的發(fā)包函數(shù)將數(shù)據(jù)包從網(wǎng)卡發(fā)出的場(chǎng)景。

我們?cè)倏纯搭愃频膸讉€(gè)問(wèn)題

• 我明明是用了write和send進(jìn)行發(fā)包，但是總是發(fā)不出去

• 通過(guò)抓包發(fā)現(xiàn)數(shù)據(jù)包已經(jīng)到網(wǎng)卡了，但是應(yīng)用程序?yàn)槭裁淳褪鞘詹坏?/p>

• 調(diào)整了緩沖區(qū)大小，不失效的原因

和前面一樣，都是需要了解相應(yīng)的系統(tǒng)參數(shù)才能較好的回答這些問(wèn)題且能體現(xiàn)你對(duì)網(wǎng)絡(luò)的了解深度

TCP數(shù)據(jù)包在發(fā)送的過(guò)程中會(huì)受到哪些影響？

TCP數(shù)據(jù)包發(fā)送過(guò)程

這個(gè)圖畫了一個(gè)小時(shí)，一定要好好看看，順便記得給我一個(gè)贊，么么噠，下面我們?cè)敿?xì)看看這個(gè)圖

當(dāng)我們通過(guò)write等發(fā)包函數(shù)進(jìn)行發(fā)包的時(shí)候，這些系統(tǒng)調(diào)用都是將數(shù)據(jù)包先從用戶緩沖區(qū)拷貝到TCP發(fā)送緩沖區(qū)中，可是這個(gè)TCP緩沖區(qū)是有大小限制的，正是這個(gè)限制就會(huì)產(chǎn)生各種問(wèn)題。

TCP發(fā)送緩沖區(qū)的默認(rèn)受到 net.ipv4.tcp_wmen 控制

TCP發(fā)送緩沖區(qū)設(shè)置

這三個(gè)參數(shù)分別的叫做是min，default，max。TCP發(fā)送緩沖區(qū)會(huì)在min和max中浮動(dòng)，初始的大小為default。

為什么需要自動(dòng)調(diào)整，是不是越大越好？

首先這個(gè)動(dòng)態(tài)調(diào)整是由內(nèi)核來(lái)完成，不需要應(yīng)用程序的干預(yù)，而且每次發(fā)包的大小不一樣，數(shù)據(jù)太小，緩沖區(qū)卻很大自然就浪費(fèi)了內(nèi)存，所以通過(guò)動(dòng)態(tài)調(diào)整的方式滿足發(fā)包的需要。

TCP緩沖區(qū)設(shè)置太小或者太大有什么標(biāo)志？

TCP的發(fā)送緩沖區(qū)設(shè)置太小，最明顯的特征即導(dǎo)致業(yè)務(wù)延遲。如何發(fā)現(xiàn)呢，可以通systemtap等工具在內(nèi)核打點(diǎn)完成觀察，如果發(fā)現(xiàn)了有sk_stream_wait_memory就認(rèn)為這發(fā)送緩沖區(qū)太小了，需要調(diào)大tcp_wemem:max

可不可以開發(fā)的時(shí)候指定需要發(fā)送的大小？

當(dāng)然可以呀，通過(guò)setsockopt中的SO_SNDBUF設(shè)置固定的緩沖區(qū)大小。但是設(shè)置了這個(gè)參數(shù)，tcp_wmem就會(huì)失效，也就沒(méi)有了動(dòng)態(tài)調(diào)整，設(shè)置的值不能超過(guò)net.core.wmem_max，如果超過(guò)了，內(nèi)核會(huì)強(qiáng)制設(shè)置為wmem_max。所以通常情況下，我們不會(huì)通過(guò)SO_SNDBUF設(shè)置TCP緩沖區(qū)的大小，設(shè)置太大浪費(fèi)內(nèi)存，設(shè)置太小引起緩沖區(qū)不足的問(wèn)題。

上面所說(shuō)的tcp_wmem和wmem_max都是針對(duì)單個(gè)tcp連接，其單位是字節(jié)。系統(tǒng)中通常有非常多的tcp連接，連接太多可能導(dǎo)致內(nèi)存耗盡

我們能不能設(shè)置tcp消耗內(nèi)存的大小？所謂上限

tcp_mem

當(dāng)所消耗的內(nèi)存達(dá)到max就不會(huì)再發(fā)包

可以通過(guò)什么方式觀測(cè)到這種情況？

Linux內(nèi)核給我們?cè)缇吐窳它c(diǎn)，sock_exceed_buf_limit。觀察的時(shí)候只需要打開tracepoint即可

sock_exceed_buf_limit

然后在日志中查看是否發(fā)生了事件

trace_pipe

伴隨tcp層數(shù)據(jù)包的處理完畢來(lái)到ip層，在IP層需要考慮端口范圍的問(wèn)題，太小可能導(dǎo)致無(wú)法創(chuàng)建連接。

net.ipv4.ip_local_port_range = 1024

為了實(shí)現(xiàn)tcp/ip數(shù)據(jù)流進(jìn)行流控，Linux內(nèi)核在ip層實(shí)現(xiàn)了qdisc(排隊(duì)規(guī)則)。我們平時(shí)見(jiàn)的比較多的TC即是基于qdisc的流控工具，實(shí)際上我們通過(guò)ipconfig看到的txqueuelen即qdisc的隊(duì)列長(zhǎng)度。它太小就會(huì)導(dǎo)致數(shù)據(jù)包被丟失

我們?nèi)绾斡^察到這個(gè)現(xiàn)象？

觀察現(xiàn)象

如果發(fā)現(xiàn)dropped不為0，則很可能是txqueuelen太小導(dǎo)致，此時(shí)就需要調(diào)大這個(gè)值

調(diào)大txqueuelen

經(jīng)過(guò)ip層后就進(jìn)入網(wǎng)卡了，此時(shí)需要發(fā)送的數(shù)據(jù)包走完TCP/IP協(xié)議棧

那么對(duì)于接受放而言，是怎么接受的？

同樣，先看看圖

TCP數(shù)據(jù)包接受過(guò)程

從上圖可以發(fā)現(xiàn)其接受流程和發(fā)送流程基本相反。當(dāng)數(shù)據(jù)包到達(dá)接受方的網(wǎng)卡，就會(huì)觸發(fā)中斷,高速CPU讀取數(shù)據(jù)包，但是在高速網(wǎng)絡(luò)中，大量的數(shù)據(jù)包，如果每來(lái)一個(gè)數(shù)據(jù)包就觸發(fā)一次中斷勢(shì)必讓CPU的處理效率大大折扣，所以提出了NAPI技術(shù)，讓CPU一次性輪詢多個(gè)數(shù)據(jù)包，通過(guò)批量的方式來(lái)提升效率，降低中斷帶來(lái)的性能開銷

在poll的時(shí)候，一次輪詢多少個(gè)？

這個(gè)poll通過(guò)sysctl選項(xiàng)控制

netdev_budget

此值默認(rèn)大小為300，通常會(huì)增加此值到600使得一次性能處理更多的的數(shù)據(jù)包

可以無(wú)限增大此值？

當(dāng)然不行，系統(tǒng)存在太多進(jìn)程，CPU需要權(quán)衡自己的時(shí)間照顧其他的進(jìn)程，如果CPU在poll的時(shí)間太多，其他任務(wù)的調(diào)度就會(huì)延遲。

當(dāng)poll了數(shù)據(jù)包就會(huì)到IP層處理，隨后到達(dá)tcp層，從而遇到我們之前所說(shuō)的TCP接受緩沖區(qū)

默認(rèn)通過(guò)tcp_rmem控制緩沖區(qū)的大小，通過(guò)適當(dāng)?shù)恼{(diào)整該值來(lái)獲取更好的網(wǎng)絡(luò)性能

tcp_rmem

TCP的默認(rèn)緩沖區(qū)大小會(huì)在min和max之間動(dòng)態(tài)的調(diào)整，不過(guò)和發(fā)送緩沖區(qū)不同的是，這個(gè)動(dòng)態(tài)調(diào)整時(shí)通過(guò)選項(xiàng)tcp_moderade_rcvbuf。通常我們都會(huì)打開它

tcp_moderade_rcvbuf

為什么接受緩沖區(qū)時(shí)通過(guò)選項(xiàng)來(lái)自動(dòng)調(diào)節(jié)，而發(fā)送緩沖區(qū)不是

因?yàn)閠cp接受緩沖區(qū)會(huì)直接影響tcp擁塞控制，從而影響對(duì)端的發(fā)包，所以通過(guò)選項(xiàng)控制的方式更加靈活的控制對(duì)端的發(fā)包行為

還有其他方式控制tcp的接受緩沖區(qū)？

當(dāng)然有，可以通過(guò)setsockopt()的配置選項(xiàng)SO_RECVBUF控制，如果設(shè)置了此值，那么tcp緩沖區(qū)的自動(dòng)調(diào)整將關(guān)閉，總之只有當(dāng)tcp_moderate_rcvbuf 為 1，并且應(yīng)用程序沒(méi)有通過(guò) SO_RCVBUF 來(lái)配置緩沖區(qū)大小的情況下，TCP 接收緩沖區(qū)才會(huì)動(dòng)態(tài)調(diào)節(jié)

總結(jié)：

TCP/IP協(xié)議棧復(fù)雜無(wú)比，此文介紹了很多配置選析，后續(xù)給大家總結(jié)一個(gè)常用的參數(shù)表

好了，這個(gè)題目也許啰嗦，但是你會(huì)發(fā)現(xiàn)確實(shí)有點(diǎn)東西哈，盤它呀，接著面試

小伙子對(duì)這個(gè)問(wèn)題的理解比較深刻，差不多都答在了點(diǎn)上，你說(shuō)說(shuō)一致性哈希是什么？

說(shuō)一致性哈希是什么，那我們肯定需要告訴面試官為啥要用一致性哈希，直接使用哈希不香？有什么問(wèn)題嘛？

我先用個(gè)簡(jiǎn)單的例子讓大伙看一波為啥使用一致性哈希

現(xiàn)在我們有一個(gè)分布式緩存，需要存放6w張美女照片，別問(wèn)我干啥，就是存著

三節(jié)點(diǎn)存儲(chǔ)image

方案1:直接采用哈希算法，對(duì)每個(gè)圖片進(jìn)行分片

哈希

余數(shù)正好對(duì)應(yīng)每個(gè)機(jī)器節(jié)點(diǎn)

這樣子會(huì)出現(xiàn)什么問(wèn)題？

通過(guò)哈希算法，每個(gè)key可以尋址對(duì)應(yīng)服務(wù)器，假設(shè)發(fā)過(guò)來(lái)的請(qǐng)求為key01，計(jì)算公式為hash(key01)%3

經(jīng)過(guò)計(jì)算后尋址編號(hào)為1的服務(wù)器節(jié)點(diǎn)，如下圖所示

節(jié)點(diǎn)1服務(wù)器

此時(shí)加入新的服務(wù)器節(jié)點(diǎn)，就會(huì)出現(xiàn)路由失敗的情況。此時(shí)從三個(gè)節(jié)點(diǎn)變化為4個(gè)節(jié)點(diǎn)，之前的hash(kley01)%3=1就變化為 hash(key-01) % 4 = X，因?yàn)槿∧＿\(yùn)算發(fā)生了變化，所以這個(gè) X 大概率不是 1，這時(shí)你再查詢，就會(huì)找不到數(shù)據(jù)了，因?yàn)?key-01 對(duì)應(yīng)的數(shù)據(jù)，存儲(chǔ)在節(jié)點(diǎn) A 上，而不是節(jié)點(diǎn) B。同樣的道理，如果我們需要下線 1 個(gè)服務(wù)器節(jié)點(diǎn)（也就是縮容），也會(huì)存在類似的可能查詢不到數(shù)據(jù)的問(wèn)題

對(duì)于這個(gè)問(wèn)題怎么解決呢

我們就需要遷移數(shù)據(jù)，基于新的計(jì)算公式 hash(key-01) % 4 ，來(lái)重新對(duì)數(shù)據(jù)和節(jié)點(diǎn)做映射。需要注意的是，數(shù)據(jù)的遷移成本是非常高的。

如何解決這個(gè)問(wèn)題---一致性哈希

一致性哈希也是使用了取模運(yùn)算，但是和傳統(tǒng)的取摸運(yùn)算不同，一致性哈希算法是對(duì)2^32 - 1進(jìn)行取模運(yùn)算

即使這些數(shù)據(jù)均勻，但是數(shù)據(jù)的活躍度不同，存放熱點(diǎn)數(shù)據(jù)多的節(jié)點(diǎn)訪問(wèn)量非常大，就很容易的達(dá)到CPU瓶頸。一致性哈希算法即將整個(gè)哈希值空間組織成一個(gè)虛擬的圓環(huán)---哈希環(huán)

通過(guò)哈希算法，將節(jié)點(diǎn)映射到哈希環(huán)上，通常是節(jié)點(diǎn)主機(jī)名，ip地址等如下圖

哈希環(huán)

在尋址的過(guò)程就只需要兩步

• 將key作為參數(shù)執(zhí)行c-hash計(jì)算出哈希值，確定key在環(huán)的位置

• 從這個(gè)位置沿著哈希環(huán)順時(shí)針走，遇到的第一個(gè)節(jié)點(diǎn)即key對(duì)應(yīng)的節(jié)點(diǎn)

如下圖所示

尋址案例

從上圖可以發(fā)現(xiàn)，key01對(duì)應(yīng)節(jié)點(diǎn)A，key03對(duì)應(yīng)節(jié)點(diǎn)C，如果此時(shí)C宕機(jī)了，只需要將key03定位到節(jié)點(diǎn)A即可，key01和key02并不需要改變。所以一致性哈希算法在增加和減少節(jié)點(diǎn)的時(shí)候，只需要重新定位一小部分?jǐn)?shù)據(jù)而不需要重新定位所有數(shù)據(jù)，這樣就實(shí)現(xiàn)了"增加/減少節(jié)點(diǎn)需要大規(guī)模遷移"這個(gè)問(wèn)題

節(jié)點(diǎn)B失效

如果節(jié)點(diǎn)比較少，是不是很容易就將請(qǐng)求數(shù)據(jù)打到一個(gè)節(jié)點(diǎn)呢？

這個(gè)問(wèn)題即"數(shù)據(jù)傾斜問(wèn)題"，由于節(jié)點(diǎn)的不均勻是的大量你的請(qǐng)求訪問(wèn)到節(jié)點(diǎn)A上，造成負(fù)載不均衡。

數(shù)據(jù)傾斜

鑒于這個(gè)問(wèn)題引入了虛擬節(jié)點(diǎn)，簡(jiǎn)單的來(lái)說(shuō)通過(guò)增加節(jié)點(diǎn)的個(gè)數(shù)來(lái)緩解節(jié)點(diǎn)的不均勻現(xiàn)象

所謂虛擬節(jié)點(diǎn)即對(duì)每個(gè)服務(wù)器節(jié)點(diǎn)計(jì)算多個(gè)哈希值，假設(shè)一個(gè)真實(shí)的節(jié)點(diǎn)有2個(gè)虛擬節(jié)點(diǎn)，此時(shí)我的三個(gè)節(jié)點(diǎn)就共有6個(gè)虛擬節(jié)點(diǎn)，如下圖所示

引入虛擬節(jié)點(diǎn)

此時(shí)如果在環(huán)上順時(shí)針尋找虛擬節(jié)點(diǎn)，假設(shè)key01選擇虛擬節(jié)點(diǎn)nodeB02，那么此時(shí)將請(qǐng)求映射到真是節(jié)點(diǎn)B即可

所以通過(guò)虛擬節(jié)點(diǎn)擴(kuò)充節(jié)點(diǎn)數(shù)量的方式解決節(jié)點(diǎn)較少情況下數(shù)據(jù)傾斜的問(wèn)題，代價(jià)非常小，只需要增加一個(gè)字典map維護(hù)真實(shí)節(jié)點(diǎn)和虛擬節(jié)點(diǎn)的映射關(guān)系即可

• 說(shuō)說(shuō)HTTP1.0 1.1 2 3的演進(jìn)

之前有一篇文章單獨(dú)說(shuō)了這個(gè)問(wèn)題，現(xiàn)在粗略總結(jié)下，希望讀者們?cè)偃ゲ椴橄嚓P(guān)資料

http/1.1 相對(duì)于http/1.0性能上的改進(jìn)：

• http/1.0 采用的是短連接，會(huì)有較大的三次握手和四次揮手的開銷

• 支持管道傳輸，http/1.0 只有第一個(gè)響應(yīng)回來(lái)才能發(fā)這個(gè)請(qǐng)求，但是http/1.1 可以連續(xù)發(fā)送，并不需要等待其回來(lái)，減少了整體響應(yīng)時(shí)間

http/1.1 性能瓶頸：

• 請(qǐng)求/響應(yīng)的頭部沒(méi)有經(jīng)改壓縮就發(fā)送，只能壓縮body部分

• 發(fā)送冗長(zhǎng)的首部，每次互相發(fā)送相同的首部造成的浪費(fèi)較多

• 服務(wù)器是按順序響應(yīng)的，會(huì)出現(xiàn)隊(duì)頭擁塞的情況

• 沒(méi)有請(qǐng)求優(yōu)先級(jí)控制

• 請(qǐng)求只能從客戶端開始，服務(wù)器只能被動(dòng)響應(yīng)

http/2

• 采用了HPACK算法避免傳送相同的頭部，并且對(duì)頭部數(shù)據(jù)進(jìn)行了壓縮

• 對(duì)傳輸?shù)臄?shù)據(jù)采用二進(jìn)制的方式傳輸，分為頭部幀和數(shù)據(jù)幀

• 對(duì)連接進(jìn)行了復(fù)用，只要訪問(wèn)同一個(gè)域名下的資源，不必進(jìn)行TCP連接的重新建立

• 支持服務(wù)端push

• 對(duì)于服務(wù)端的響應(yīng)也不會(huì)不會(huì)出現(xiàn)隊(duì)頭擁塞的情況，可以根據(jù)優(yōu)先級(jí)進(jìn)行響應(yīng)

http/3 QUIC

• 采用了基于UDP的傳輸層協(xié)議，希望取代TCP

• 仍然也有隊(duì)頭阻塞的情況，例如當(dāng)TCP出現(xiàn)丟包重傳時(shí)

• 支持應(yīng)用層級(jí)別的重傳，而且在只丟失一個(gè)數(shù)據(jù)包的情況下不需要重傳，使用糾錯(cuò)機(jī)制恢復(fù)丟失的包

• 說(shuō)說(shuō)數(shù)據(jù)庫(kù)事務(wù)的四大特性

事務(wù)時(shí)一個(gè)可執(zhí)行的邏輯單元，該邏輯單元的操作要么都執(zhí)行，要么都不執(zhí)行，事務(wù)具有ACID四個(gè)性質(zhì)

• 原子性：指事務(wù)包含的所有操作，要么都被執(zhí)行成功，如果中間有一條語(yǔ)句失敗，則進(jìn)行回滾。

• 一致性：指事務(wù)執(zhí)行前和執(zhí)行后都必須處于一致性狀態(tài)

• 隔離性：事務(wù)之間是相互獨(dú)立的，中間狀態(tài)對(duì)外是不可見(jiàn)的

• 持久性：數(shù)據(jù)的修改是永久的

• 多加索引一定很好嗎

索引主要用于加速查詢速度，但并發(fā)越多越好，因?yàn)樗饕枰加梦锢砜臻g的，且索引的維護(hù)需要時(shí)間的，所以如果建索引，一般來(lái)說(shuō)，應(yīng)該查詢的次數(shù)大于插入的次數(shù)，同時(shí)我們一般只對(duì)例如where或者h(yuǎn)aving子句中涉及的字段進(jìn)行設(shè)置索引，因?yàn)槠渌牡胤骄退憬⒘怂饕?#xff0c;一般也用不到，只是浪費(fèi)。

• 請(qǐng)問(wèn)TCP哪些保證了數(shù)據(jù)傳輸?shù)目煽啃?/p>

序列號(hào)、確認(rèn)重傳、超時(shí)重傳、擁塞控制(ps 看過(guò)我之前文章的小伙伴，問(wèn)這個(gè)問(wèn)題如果不能扯上一小時(shí)，自罰三杯)

• 三個(gè)線程順序打印A-Z

#include?<unistd.h> #include?<pthread.h> #include?<iostream> using?namespace?std;char?ch?=?'A'?-?1;pthread_cond_t??cond??=?PTHREAD_COND_INITIALIZER; pthread_mutex_t?mutex?=?PTHREAD_MUTEX_INITIALIZER;void*?print_fun(void?*?args){int?i?=?*((int*)args);char?next_ch?=?'A'?+?i;?while(next_ch?<=?'Z'){pthread_mutex_lock(&mutex);while(ch?+?1?!=?next_ch)pthread_cond_wait(&cond,?&mutex);ch++;cout<<?pthread_self()?<<?":"<<?ch?<<?endl;next_ch?=?ch?+?3;pthread_mutex_unlock(&mutex);pthread_cond_broadcast(&cond);}return?nullptr; }int?main(){pthread_t?tids[3];int?pos?=?0;for(int?i?=?0;?i?<?3;?++i){pthread_create(tids?+?i,?nullptr,?print_fun,?&pos);sleep(1);pos++;}for(int?i?=?0;?i?<?3;?++i){pthread_join(tids[i],?nullptr);}return?0; }

5 總結(jié)

請(qǐng)記下以下幾點(diǎn):

• 公司招你去是干活了，不會(huì)因?yàn)槟阍趺丛趺吹亩档蛯?duì)你的要求標(biāo)準(zhǔn)。

• 工具上面寫代碼和手撕代碼完全不一樣。

• 珍惜每一次面試機(jī)會(huì)并學(xué)會(huì)復(fù)盤。

• 對(duì)于應(yīng)屆生主要考察的還是計(jì)算機(jī)基礎(chǔ)知識(shí)的掌握，項(xiàng)目要求沒(méi)有那么高，是自己做的就使勁摳細(xì)節(jié)，做測(cè)試，只有這樣，才知道會(huì)遇到什么問(wèn)題，遇到什么難點(diǎn)，如何解決的。從而可以侃侃而談了。

• 非科班也不要怕，怕了你就輸了！一定要多嘗試。

有道無(wú)術(shù)，術(shù)可成；有術(shù)無(wú)道，止于術(shù)

歡迎大家關(guān)注Java之道公眾號(hào)

好文章，我在看??

總結(jié)

以上是生活随笔為你收集整理的「面试」美团肝了我30+问题的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。