上一篇給你們分享了B站的面試之旅，你們的反響還不錯，竟然催更了，小手不由顫抖。因此決定把剩下的這些公司給安排明白了。這不，今天就看看小紅書服務端/後臺面了啥，不爲別的，就想遇到漂亮的HR小姐姐，開工。面試
大綱算法
一面
一面面試官看着二十七八歲，溫文爾雅，這哪裏是寫代碼的，頭髮都飄起來了好麼。上來就幹項目，因爲你們的項目都不太同樣，因此對於項目部分我就說說我面試的時候常常遇到的問題數據庫
描述下項目數組
一口是吃不了胖子的，描述以前先憋着氣掂量掂量本身所說的東西能不能唬住本身，而後唬住面試官。服務器
項目中擔任的角色網絡
對於大多數的咱們而言，就是開發的角色，一樣的道理，角色對應相應的職務，闡述本身作的內容能引面試官上鉤，拉鉤上吊一百年不準變。數據結構
在項目遇到什麼困難併發
這三個問題，是否是能夠拎着腳趾拇均可以想出來，除非不是你作的，哈哈哈哈哈。不慌，不是咱們作的也不怕，咱們必須知道有個網站叫作Github，大牛這麼多，本身不是大牛，難道不會學學人家麥。Clone下來，搭建環境跑起來，開始調試修改，經過將模塊拆分，進一步修改，這不就是你的項目嗎，固然我不怎麼建議你們這麼操做啦。異步
項目被問的差很少了，開始懟基礎知識，基礎知識老四套，計算機網絡，數據庫，操做系統，數據結構(來吧，時刻準備着，真沒吹牛逼)tcp
我看你簡歷中寫着網絡流量的還原，你應該對計算機網絡比較熟悉？(注意哈，簡歷上寫上去的東西，本身內心必定要有點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，那麼其過程以下
TCP重傳
當 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。
就這樣是否是就可讓面試官感受，這小夥子有點東西。那怎麼配置呢
配置syn queue
你覺得面試官是傻子？固然不是，萬一面試官問你：半鏈接積壓較多，還有其餘的緣由？
哈哈哈，這說明面試官上鉤了哇，來，咱們看看還有啥緣由
還有多是由於惡意的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的方法？
SYN Cookies
網絡問到這就差很少了，挺好的，徹底按照個人套路出牌。開始懟我操做系統
說下什麼是大頁內存
我擦，我差點沒反應過來，"大爺內存"，不過確實牛逼，大頁內存，記住了，是大頁內存。
咱們知道操做系統堆內存的管理採用多級頁表和分頁進行管理，操做系統給每一個頁的默認大小是4KB。假設當前進程使用的內存比較大爲1GB，那麼此時在頁表中會佔用1GB/4KB=26211個頁表項，可是系統的TLB可容乃的頁表項遠遠小於這個數量。因此當多個內存密集型應用訪問內存的時候，就會致使過多的TLB沒有命中，所以在特定的狀況下會須要減小未命中次數，一個可行的辦法便是增大每一個頁的尺寸。
操做系統默認支持的大頁爲2MB，當使用1GB內存的時候，頁表將佔用512頁表項，大大的提升TLB命中率從而提升性能。另外須要注意的是，大頁內存分配的是物理內存，因此不會有換出磁盤的操做，因此沒有缺頁中斷，也就不會引入訪問磁盤的時延。
行，差很少時間了，寫個簡單代碼吧，實現一個無重複字符的最長子串
思路：使用滑動窗口保證每一個窗口的字母都是惟一的
使用 vectorm 來記錄一個字母若是後面出現重複時，i 應該調整到的新位置
因此每次更新的時候都會保存 j + 1 ，即字母后面的位置
j 表示子串的最後一個字母，計算子串長度爲 j - i + 1
無重複字符的最長子串
二面
一面感受還不錯，果不其然二面來了，HR小姐姐打電話通知週三二面，行，對於歷來不遲到的暖藍，確定守時。拿着茶，等到2:30，至於爲何拿着茶，這是個人習慣，面試前喝杯茶等待面試官的捧擊(面試官其實大部分很溫柔的啦)。
可耐，面試官到點了竟然還沒來，等不及的我打電話給HR，HR說很差意思，得等幾分鐘，行，對這甜美的聲音我忍了，但是等了十分鐘都沒音信，我下午還有個筆試，無奈給HR說，我下午還有事兒，要不改天面？
不知道什麼狀況，直接說，我立刻給你換個面試官，我擦，還有這種事兒，我這鄉卡卡的娃兒有這種的待遇？是我一面表現的太太突出？不會吧，反正小紅書我愛了。
「staty with me」響起，這正是個人手機鈴聲。。
"您好」
「你好，請問是XX？」
"嗯嗯，你好面試官"
"我是你的二面面試官，先自我介紹吧"
我叫XX，來自XX大學，本科XX，碩士XXX，期間作了XX，謝謝面試官。自我介紹不用那麼花裏胡哨，挑重點說，不會在乎你本科談了幾回戀愛，也不會在乎你XXXX，簡單明瞭完事，開始二面
應該學過C的吧，用C實現多態怎麼個思路
至於這個題，我仍是比較驚訝的，怎麼忽然問到了C，想了想可能仍是考慮對於面向對象中多態，繼承等的理解。
多態無外乎就是編譯時多態和運行時多態，編譯時多態理解爲重載，運行時多態理解爲重寫。那麼要實現重載，須要用到c中的宏，V_ARGS。
c實現重載
理解上面的方法，實現多態就更輕鬆了
c實現多態
感受沒啥問的，先寫個代碼，二路歸併
哈哈，讓我想起了歌詞"來左邊跟我花個龍，在你右邊畫一道彩虹"(腦補畫面)
停！！這是我以前說過的常考算法之一，中心思想即分治，可經過遞歸一直拆分，遞歸的結束條件即不可再分，即分爲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的調用。畫個圖加深下印象
RPC過程
其餘問的一些問題感受在前面的面試問過了就沒有寫在這部份內容了，還問了幾個數據庫的問題，很常規的了，以前的文章寫過，篇幅太長，看着累，要不先三連，咱們下期再見？麼麼噠
總結
請記下如下幾點:
公司招你去是幹活了，不會由於你怎麼怎麼的而下降對你的要求標準。
工具上面寫代碼和手撕代碼徹底不同。
珍惜每一次面試機會並學會覆盤。
對於應屆生主要考察的仍是計算機基礎知識的掌握，項目要求沒有那麼高，是本身作的就使勁摳細節，作測試，只有這樣，才知道會遇到什麼問題，遇到什麼難點，如何解決的。從而能夠侃侃而談了。
非科班也不要怕，怕了你就輸了！必定要多嘗試。