「面試」拿到小紅書的意向書

上一篇給大家分享了B站的面試之旅，大家的反響還不錯，居然催更了，小手不禁顫抖，所以決定把剩下的這些公司給安排明白了，這不，今天就看看小紅書服務端/后臺面了啥，不為別的，就想遇到漂亮的HR小姐姐，開工，

一面

一面面試官看著二十七八歲，文質彬彬，這哪里是寫代碼的，頭發都飄起來了好么，上來就干專案，由于大家的專案都不太一樣，所以對于專案部分我就說說我面試的時候經常遇到的問題

• 描述下專案

一口是吃不了胖子的，描述之前先憋著氣掂量掂量自己所說的東西能不能唬住自己，然后唬住面試官，

• 專案中擔任的角色

對于大多數的我們而言，就是開發的角色，同樣的道理，角色對應相應的職務，闡述自己做的內容能引面試官上鉤，拉鉤上吊一百年不許變，

• 在專案遇到什么困難

這三個問題，是不是可以拎著腳趾拇都可以想出來，除非不是你做的，哈哈哈哈哈，不慌，不是我們做的也不怕，我們必須知道有個網站叫做Github，大牛這么多，自己不是大牛，難道不會學學人家麥，Clone下來，搭建環境跑起來，開始除錯修改，通過將模塊拆分，進一步修改，這不就是你的專案嗎，當然我不怎么建議大家這么操作啦，

專案被問的差不多了，開始懟基礎知識，基礎知識老四套，計算機網路，資料庫，作業系統，資料結構(來吧，時刻準備著，真沒吹牛逼)

我看你簡歷中寫著網路流量的還原，你應該對計算機網路比較熟悉？(注意哈，簡歷上寫上去的東西，自己心里一定要有點B數)，那我們說說計算機網路

• 說說計算機網路中TCP的三次握手吧

首先 Client 給 Server 發送一個SYN包，Server 接收到 SYN 回復 SYN+ACK，然后客戶端回復 ACK 表示收到，

你這樣回答肯定是不會讓面試官滿意的，那就加點配料，不放佐料的菜怎么香？那就詳細的安排一下

首先客戶端的協議堆疊向服務端發送SYN包，同時告訴服務端當前發送的序列號是X，此時客戶端進入 SYNC_SENT狀態

服務端的協議堆疊收到這個包以后，使用 ACK 應答，此時應答的值為 X+1，表示對 SYN 包 J 的確認，同時服務端也發送一個SYN包，告訴客戶端當前我的發送序列號是Y，此時服務端進入SYNC_RCVD狀態

客戶端協議堆疊收到 ACK 以后，應用程式通過connect呼叫表示服務端的單向連接成功，此時狀態為ESTABLISHED，同時客戶端協議堆疊對服務器端的 SYN 進行應答，此時資料為Y+1

服務端收到客戶端的應答包，通過accept阻塞呼叫回傳，此時服務端到客戶單的單向連接也建立成功，服務器將進入ESTABLISHED狀態

這樣是不是稍微有B格一點呢，而且還比較形象，當然為了加深大家對這個程序的印象，我再舉個例子

***第一次握手：***小藍給某女娃告白，說我喜歡你，然后我傻乎乎的等著回應

第二次握手：女生看我這顏值，秒回，自然就答應我啊，并回復我也喜歡你拉

第三次握手：我收到女生的回應說：“那晚上去吃火鍋，看電影，理療”

就這樣在一起啦，那么后續是啥樣呢？是不是得往下看看什么是四次揮手了(渣男石錘)，非也，還在熱戀期呢，專一的好嗎，面試官會繼續問你三次握手

面試官說：“那我問你，如果客戶端發送的SYN丟失了或者其他原因導致Server無法處理，是什么原因？

這個場景非常常見，沒有萬無一失，在TCP的可靠傳輸中，如果SYN包在傳輸的程序中丟失，此時Client段會觸發重傳機制，但是也不是無腦的一直重傳過去，重傳的次數是受限制的，可以通過 tcp_syn_retries 這個配置項來決定，如果此時 tcp_syn_retries 的配置為3，那么其程序如下

當 Client 發送 SYN 后，如果過了1s還沒有收到 Server 的回應，那么進行第一次的重傳，如果經過了2s沒有收到Sever的回應進行第二次的重傳，一直重傳tcp_syn_retries次，這里的重傳三次，意味著當第一次發送SYN后，需要等待(1 +2 +4 +8)秒，如果還是沒有回應，connect就會通過ETIMEOUT的錯誤回傳，

說說四次揮手吧，哎，卑微的藍藍

第一次揮手：女生覺得和這個男生不太合適，但是是個好人，決定提出分手，等待男生回應

第二次揮手：這男生吧，也是會玩兒，直接說：”分就分“

第三次揮手：過了一段時間，男生覺得好沒得面子：“我一個大老爺們，應該是我提出分手啊”，于是給女生說：我們分手吧

第四次揮手：女生看到這個訊息，你是「憨批」還是「神經病」？

TIMEWAIT了解哈，過多的TIMEWAIT怎么辦，什么原因造成的?

回答問題的方法無外乎即是什么，為什么會出現以及可以解決的方案

在TCP的四次揮手程序中，發起連接斷開的一方會進入TIME_WAIT的狀態，通常一個TCP連接通過對外開發埠的方式提供服務，在高并發的情況下，每個連接占用一個埠，但是埠是有限的以致于可能導致埠耗盡，所以就會出現’“服務時而好時而壞的情況”，

如下圖所示的TCP四次揮手，TCP連接準備終止的時候會發送FIN報文，主機2進入CLOSE_WAIT狀態并發送ACK應答，主機1會在TIMEWAIT停留2MSL的時間，

為什么不直接進入CLOSE轉態，而是需要先等待2MSL，這段時間在干啥？

第一個原因是為了確保最后的ACK能夠正常接收，從而有效的正常關閉，怎么理解，科學家們在設計TCP的時候，假設TCP】 報文會出錯從而開始重傳，如果主機1的報文沒有傳輸成功，那么主機2就會重發FIN報文，此時主機1沒有維護TIME_WAIT狀態，就會失去背景關系從而恢復RST，導致服被動關閉一方出現錯誤，

第二個原因是讓舊鏈接的重復分節在網路中自然消失，

一次網路通信可能經過無數個路由器，交換機，不知道到底會是哪個環節出問題，我們為了標識一個連接，通過四元組的方式[源IP，源埠，目的IP，目的埠]，假設此時兩個連接A，B，A連接在中途中斷了，此時重新創建B連接，這個B連接的四元組和A連接一樣，如果A連接經過一段時間到達了目的地，那么B連接很有可能被認為是A連接的一部分，這樣就會造成混亂，所以TCP設定了這樣一個機制，讓兩個方向的分組都被丟棄，

那么TIME_WAIT有哪些危害？

過多的連接勢必造成記憶體資源的浪費

對埠的占用，可開啟的埠也就32768~61000

有沒有對TCP進行優化過

開玩笑，這東西復習過，盡管問，錘子不怕，優化的點很多，隨便提一點，讓后比較深的描述下這個程序就行比如調整哪些引數在某些特定的條件下會最優

我們應該都知道半連接，即收到SYN以后沒有回復SYN+ACK的連接，那么Server每收到新的SYN包，都會創建一個半連接，然后將這個半連接加入到半連接的佇列(syn queue)中，syn queue的長度又是有限的，可以通過tcp_max_syn_backlog進行配置，當佇列中積壓的半連接數超過了配置的值，新的SYN包就會被拋棄，對于服務器而言，可能瞬間多了很多新的連接，所以通過調大該值，以防止SYN包被丟棄而導致Client收不到SYN+ACK，

就這樣是不是就可以讓面試官感覺，這小伙子有點東西，那怎么配置呢

你以為面試官是傻子？當然不是，萬一面試官問你：半連接積壓較多，還有其他的原因？

哈哈哈，這說明面試官上鉤了哇，來，我們看看還有啥原因

還有可能是因為惡意的Client在進行SYN Flood攻擊，

SYN Flood攻擊是個啥程序？

首先Client以較高頻率發送SYN包，且這個SYN包的源IP不停的更換，對于Server來說，這是新的鏈接，就會給它分配一個半連接

Server的SYN+ACK會根據之前的SYN包找IP，發現不是原來的IP，所以無法收到Client的ACK包，從而導致無法正確的建立連接，自然就讓Server的半連接佇列耗盡，無法回應正常的SYN包

那有沒有什么方案解決這個問題？

那必須，畢竟面試嘛，需要讓面試官問我們知道的內容，在Linux內核中引入了SYN Cookies機制，那看看這個機制是啥意思

首先Server收到SYN包，不分配資源保存Client的資訊，而是根據SYN計算出Cookie值，然后將Cookie記錄到SYN ACK并發送出去

如果是正常的情況，這個Cookies值會伴隨著Client的ACK報文帶回來

Server會根據這個Cookies檢查ACK包的合法性，合法則創建連接

那么開啟SYN Cookies的方法？

網路問到這就差不多了，挺好的，完全按照我的套路出牌，開始懟我作業系統

• 說下什么是大頁記憶體

我擦，我差點沒反應過來，“大爺記憶體”，不過確實牛逼，大頁記憶體，記住了，是大頁記憶體，

我們知道作業系統堆記憶體的管理采用多級頁表和分頁進行管理，作業系統給每個頁的默認大小是4KB，假設當前行程使用的記憶體比較大為1GB，那么此時在頁表中會占用1GB/4KB=26211個頁表項，但是系統的TLB可容乃的頁表項遠遠小于這個數量，所以當多個記憶體密集型應用訪問記憶體的時候，就會導致過多的TLB沒有命中，因此在特定的情況下會需要減少未命中次數，一個可行的辦法即是增大每個頁的尺寸，

作業系統默認支持的大頁為2MB，當使用1GB記憶體的時候，頁表將占用512頁表項，大大的提高TLB命中率從而提高性能，另外需要注意的是，大頁記憶體分配的是物理記憶體，所以不會有換出磁盤的操作，所以沒有缺頁中斷，也就不會引入訪問磁盤的時延，

行，差不多時間了，寫個簡單代碼吧，實作一個無重復字符的最長子串

思路：使用滑動視窗保證每個視窗的字母都是唯一的

• 使用 vector m 來記錄一個字母如果后面出現重復時，i 應該調整到的新位置

• 所以每次更新的時候都會保存 j + 1 ，即字母后面的位置

• j 表示子串的最后一個字母，計算子串長度為 j - i + 1

二面

一面感徑訓不錯，果不其然二面來了，HR小姐姐打電話通知周三二面，行，對于從來不遲到的暖藍，肯定守時，拿著咖啡，等到2:30，至于為什么拿著茶，這是我的習慣，面試前喝杯茶等待面試官的哦訓(面試官其實大部分很溫柔的啦)，

可耐，面試官到點了居然還沒來，等不及的我打電話給HR，HR說不好意思，得等幾分鐘，行，對這甜美的聲音我忍了，可是等了十分鐘都沒音信，我下午還有個筆試，無奈給HR說，我下午還有事兒，要不改天面？

不知道什么情況，直接說，我馬上給你換個面試官，我擦，還有這種事兒，我這鄉卡卡的娃兒有這種的待遇？是我一面表現的太太突出？不會吧，反正小紅書我愛了，

“staty with me”響起，這正是我的手機鈴聲，，

"您好”

“你好，請問是XX？”

“嗯嗯，你好面試官”

“我是你的二面面試官，先自我介紹吧”

我叫小藍，來自XX大學，本科XX，碩士XXX，期間做了XX，謝謝面試官，自我介紹不用那么花里胡哨，挑重點說，不會在意你本科談了幾次戀愛，也不會在意你XXXX，簡單明了完事，開始二面

• 應該學過C的吧，用C實作多型怎么個思路

至于這個題，我還是比較驚訝的，怎么突然問到了C，想了想可能還是考慮對于面向物件中多型，繼承等的理解，

多型無外乎就是編譯時多型和運行時多型，編譯時多型理解為多載，運行時多型理解為重寫，那么要實作多載，需要用到c中的宏，V_ARGS，

理解上面的方法，實作多型就更輕松了

感覺沒啥問的，先寫個代碼，二路歸并

哈哈，讓我想起了歌詞"來左邊跟我花個龍，在你右邊畫一道彩虹"(腦補畫面)

停！！這是我之前說過的常考演算法之一，中心思想即分治，可通過遞回一直拆分，遞回的結束條件即不可再分，即分為1個的時候就停止，從第一個開始時將每一個模塊當作一個已經排序好的陣列，有如雙指標，在兩個陣列頭設立指標，進行值的比較，然后插入到新陣列中，上代碼咯

倒排索引了解不？

假設我這里有幾十本檔案，每個檔案題目不一樣，如果我給你檔案的題目，你可能很快就可以找到相應的檔案，但是如果我讓你找論文中包含"暖"和“藍”這兩個字，你可能直接給我"兩兒巴“，因為多半很難很快就找出來，從稍微專業的角度來分，前一種是正排索引，后一個是倒排索引，

我們先看簡單的正排索引，此時給每個檔案一個唯一ID，然后使用哈希表將檔案的ID作為鍵，將檔案內容作為鍵對應的值，這樣我們就可以在O(1)的時間代價完成key的檢索，這也正是正排索引

這里遍歷哈希表的時間代價為O(n)，每遍歷一個檔案都需要遍歷每個字符判斷是否包含兩字，假設每個檔案的平均長度為k，那么遍歷一個檔案的時間代價為O(K)，

有沒有什么優化的方法？

其實以上就是兩種方案，一種是根據題目找到內容，另一種是根據關鍵字查找題目，這完全相反的方案，那我們反著試試

我們將關鍵字當做key，將包含這個關鍵字的檔案的串列當做存盤的內容，同樣建立一個哈希表，在O(1)的時間我就可以找到包含該關鍵字的檔案串列，這種根據內容或者欄位反過來的索引結構即倒排索引，

如何創建倒排索引？

• 首先給檔案編個號表示唯一表示，然后排序遍歷檔案
• 決議每個檔案的關鍵字并生成<關鍵字，檔案ID，關鍵字位置>，這里的關鍵字位置主要是為了檢索的時候顯示關鍵字前后資訊
• 將關鍵字key插入哈希表，如果哈希表已存在這個key，就在對應的posting list中追加節點，記錄檔案ID，如果哈希表沒有回應的key則插入該key并創建posting list和對應的節點
• 重復2 3步處理完所以檔案

如果要查詢同時包含"暖"“藍”兩個key怎么辦？

順藤摸瓜啦，分別用兩個key去倒排索引中檢索，這樣使用的兩個不同list：A和B，A中的檔案都包含了"暖"字，B中的檔案都包含了"藍"字，如果檔案即出現"暖"也出現"藍"，是不是就正好包含了兩個字？所以只需要找到AB公共元素即可

如何找到AB兩個鏈表的公共元素？希望小伙伴們思考下，經常在手撕演算法中被問到

• 首先使用兩個指標P1 P2分別指向有序鏈表AB的第一個元素
• 然后對比兩個指標所指節點是否相同，這可能出現三種情況
  • 兩者id相同則是公共元素，直接歸并即可，然后P1 P2后移
  • p1元素小于p2元素，p1后裔，指向A鏈表的下一個元素
  • p1元素大于p2元素，p2后裔，指向B鏈表中下一個元素
• 重復第二步 直到p1和p2移動到鏈表尾

你說使用過kafka，那么使用訊息佇列的時候如何保證只消費一次？

首先引入kafka等訊息佇列是為了對峰值寫流量做削峰填谷，對不同系統做解耦合，

舉個例子，我們開發了一個電商系統，其中一個功能是當用戶購買了A產品5份就送一個紅包從而鼓勵用戶消費，但是如果在訊息傳遞的程序中丟失了，用戶很可能會因為沒有收到紅包而不開心，甚至取消訂單，在這里如何保證訊息被消費到且一次？

我們先看看這個訊息寫入訊息佇列會有幾個階段，首先有訊息從生產者寫入訊息到佇列，訊息存盤在訊息佇列，訊息被消費者消費這個階段，任何一個階段都有可能丟失，我們分別查看這幾個階段

第一個階段：訊息生產

訊息的生產通常會是業務服務器，業務服務器和獨立部署的訊息佇列服務器通過內網通信，很可能因為網路抖動導致訊息的丟失，這樣可以采用訊息重傳的機制保證訊息的送達，但是容易出現重復消費的情況，意思收到兩個紅包，用戶開心了，但是，，，

第二個階段：在佇列中丟失

kafka為了減少訊息存盤對磁盤的隨機IO，采用的異步刷盤的方式將訊息存盤在磁盤中，

我看你簡歷上打過acm，說說你的策略或者經歷吧

哈哈哈，終于到我正兒八經吹水的時候了，低調，才是最牛逼的炫耀

寫個驗證郵箱的正則

當時沒有寫出來，確實記不住，每次都是用的時候才去查，誰知道面試的時候遇見誰呢，手撕KMP?這里給大家個答案，后續我詳細安排一篇正則的套路

了解記憶體映射？說說，盡量說

既然是盡量說，就不客氣了，從什么是記憶體到如何查看服務器記憶體，最后怎么能夠更好地用好記憶體來答就完事

首先記憶體作為存盤系統和應用程式的指令，資料等，在Linux中，管理記憶體使用到了記憶體映射，平時我們經常說的記憶體容量，主要指的是物理記憶體，也叫做主存，只有內核才能直接訪問，那么問題來了，進城如果要訪問記憶體怎么辦呢？

Linux內核為每個行程提供了一個虛擬地址空間且空間地址連續，這樣的話，行程訪問虛擬記憶體將非常的方便，

虛擬地址又分為內核空間和用戶空間，不同字長的處理器地址范圍也不同，我們下面分別看看32位和64位的虛擬地址空間

從這個圖很明顯的看出32位系統中內核空間1G，而64位的內核空間與用戶空間都是128T，

記憶體映射即虛擬記憶體地址映射到物理記憶體地址，完了順利完成映射，需要給每個行程維護一張頁表記錄兩者的關系，

這樣，如果行程訪問的虛擬地址不在則通過缺頁例外進入內核空間分配物理記憶體，更新行程頁表，最侄訓傳用戶空間，

說到虛擬記憶體又不得不說說用戶空間的各個段

忍不住悄悄咪咪問了下HR，二面面試官對我的評價，基礎和code的能力不錯，專案講述的不清楚

• 我自己可能沒有把專案更本質的東西理解清楚
• 從事的不同的方向，有些專業術語的理解的不同）

三面

三面面試官，真的不能用"禿"來描述了，就感覺我的眼睛被閃了一分鐘，怎么說，面嘛

執行緒的鎖有哪些，我說到了讀寫鎖打斷我了，問我讀寫鎖會有什么些問題，無非就是寫鎖饑餓問題，我說沒看過內核原始碼，然后如果讓我來實作，我怎么來避免

分布式Hash表，當進行擴容的時候（會花費很長的時間），我說P肯定一定要保證的，CA只能選其一，但是我們可以使用弱一致性來保證其可用性

多個隨機Request請求，然后不同的請求有不同的權重，進行隨機抽樣，要求權重大更可能被抽到

有了解過RPC？

RPC翻譯過來為遠程程序呼叫，幫助我們屏蔽網路細節，實作呼叫遠程方法就跟呼叫本地一樣的體驗，舉個例子，如果沒有橋，我們要過河只好劃船，繞道等方式，如果有橋，我們就像在路面行走一樣自如到目的地，

RPC的通信流程是怎樣的？

剛才說RPC屏蔽了網路細節，也就是意味著它處理好了網路部分，它為了保證可靠性，默認采用TCP傳輸，網路傳輸的資料是二進制，但是呼叫所請求的引數是物件，所以需要將物件轉換為二進制，這就需要用到序列化技術

服務提供方接收到資料以后，并不知道哪里是結尾，所以需要一些邊界條件來標識請求的資料哪里是開始，哪里是結束，就像高速路上各種指路牌引領我們前進的方向，這種格式的約定叫做“協議”

根據協議規定的格式，就可以正確的提取出相應的請求，根據請求的型別和序列化的型別，將二進制訊息體逆向還原為請求物件，這叫做反序列化

服務提供方通過反序列化的物件找到對應的實作類完成整正的呼叫，這樣就是一次rcp的呼叫，畫個圖加深下印象

其他問的一些問題感覺在前面的面試問過了就沒有寫在這部分內容了，還問了幾個資料庫的問題，很常規的了，之前的文章寫過，篇幅太長，看著累，要不先三連，我們下期再見？么么噠

5 總結

請記下以下幾點:

• 公司招你去是干活了，不會因為你怎么怎么的而降低對你的要求標準，
• 工具上面寫代碼和手撕代碼完全不一樣，
• 珍惜每一次面試機會并學會復盤，
• 對于應屆生主要考察的還是計算機基礎知識的掌握，專案要求沒有那么高，是自己做的就使勁摳細節，做測驗，只有這樣，才知道會遇到什么問題，遇到什么難點，如何解決的，從而可以侃侃而談了，
• 非科班也不要怕，怕了你就輸了！一定要多嘗試，

我是小藍，一個專為大家分享面試經驗的藍人，如果覺得文章不錯或者對你有點幫助，感謝分享給你的朋友，也可在下方給小藍給個在看，這對小藍非常重要，謝謝你們，下期再會，