这里有一份面筋请查收（六）
歡迎支持筆者新作：《深入理解Kafka:核心設計與實踐原理》和《RabbitMQ實戰指南》，同時歡迎關注筆者的微信公眾號：朱小廝的博客。
歡迎跳轉到本文的原文鏈接：https://honeypps.com/talk/interview-6/
已經寫到第六篇了，本文說的這家公司是博主投的最隨意的，屬于手滑點贊的那種。這里簡稱為V，最后也是選擇了這家。博主會把簡歷掛在獵聘網上讓獵頭來找，然后把自己的簡歷給獵頭，有心思的獵頭還會修改一下簡歷。至于在獵聘網上填寫的簡歷有很多條條框框，一般看到一家比較感興趣的也會去拉勾網上搜一下，然后在拉勾網上頭，拉勾網在這點上做的不錯。當時看到公司V覺得也是一家知名企業，就點了發送簡歷，忘了去拉勾上搜一下了，而且職位介紹也沒注意。后來面試的時候面試官解釋了一下這個職位，感覺很有吸引力。當時二面和三面之間W公司發來一個offer，差不多就拒掉了。置之死地而后生，不然沒動力繼續面試的。
一面也是電面，因為不在一個城市。之后的二三四面都是去公司面的。
###一面
當天和面試官約好晚上19:30面試的，果然也是準時的，整個面試過程持續了45mins左右。面試官人很好，問的問題比較細膩。問的大多是網絡的問題，博主寫過通訊程序，但是對計算機網絡沒有很深的了解，最近面試也沒準備過網絡相關的知識，只是看了下Java相關的，對于計算機網絡只能靠回憶啦。
1.TCP/IP協議相關的
TCP的三次握手是什么？為什么要三次握手？不是三次可不可以？
TCP的關閉連接有哪些動作？（四次揮手）？TCP和UDP的區別？端口號位于幾層協議？
以上這些TCP/IP有一定了解的人一般都能回答。
之后問了一個問題，在四次揮手的過程中有兩個狀態TIME_WAIT和CLOSE_WAIT之間會發生一些異常情況，你知道是什么么？有知道答案的小伙伴請在下方告知。
TCP的流量控制怎么解決？（滑動窗口）
TCP的擁塞控制怎么解決？（這個沒答上來，之后翻看了下資料，還是有點復雜的。涉及慢開始和擁塞避免，快重傳和快恢復。）
2.Keepalived基于幾層協議？LVS基于幾層協議？
簡歷上寫了這個所以被問也是很正常。
答案：Keepalived工作在3,4,7層上。第三層：Keepalived會定期向服務器集群中的服務器發送一個ICMP的數據包，如果發現某臺服務器的IP地址沒有激活，Keepalived便報告這臺服務器失效。并將它從服務器集群中提出。第四層：主要以TCP端口的狀態來決定服務器工作正常與否。第7層：根據用戶的設定檢查服務器程序的運行是否正常，如果與用戶的設定不相符，則Keepalived將把服務器從服務器群中剔除。LVS（LVS-TUN, LVS-NAT）工作在4層協議上，但是也有人說LVS-DR是基于物理鏈路層的，所以也是可以理解的。
3.聊聊NIO以及React模式詳解。
關于NIO網上有很多資料，可以自行查閱，也可以看一下這一篇《攻破JAVA NIO技術壁壘》。
之后好像問了個問題：NIO的Reactor模式和設計模式中的觀察者模式有什么區別？觀察者是基于單事件源的，而Reactor模式是基于多事件源的。
4.客戶端連接服務器，綁定了錯誤的IP地址和端口號會有什么現象？
這個博主再寫IO程序的時候還真沒有注意過，只蒙了一個Connection refuse的答案。細節決定成敗啊。后來通過程序BIO和NIO兩種方式分別試了一下。NIO的方式在IP不通或者端口不正確的情況下都沒有任何異常。BIO的方式在IP不通的情況下沒有異常，端口不通會報異常：Connection refused: connect。
當然也問了點純Java的，很少，記不住問什么了（好像有一題：HashMap和數據結構中HashTable的區別），應該是比較常規的問題。如果不是常規的肯定不會遺忘了。后來面試結束前問我有么有什么問題想問的。我說：有沒有什么建議？面試官說：他面過很多人，一般都不看重以前學校里學的基礎知識，認為在工作中并沒有太多的聯系。其實工作越久會發現基礎知識很重要。
###二面
二面是V公司的高級經理，管技術的，應該是這個職位的領導。問了點Java基礎的問題，比如GC相關的知識，那就從GC Roots, 分代，Serial, ParNew, Parallel Scavenge, Serial-Old, Parallel-Old, CMS等來一遍。
好像是還問了一個CMS什么時候發生Concurrent Mode Failure. Java基礎問的很少，大多數是問分布式架構相關的。
首先在位置上問了一個：分布式內存怎么和數據庫之間確保數據一致性？這個問題在前面的博文中也也有涉及。博主的回答大致是（一種解決方案）：將某個庫上的某個key要發生的寫操作，記錄在緩存中，并設置“經驗主從同步時間”的緩存超時時間為500ms，這時間是指數據庫主備同步的時間不會超過500ms，但是也有可能發生超過500ms的現象，當然可以設置的更久一點，只會偶爾發生最終一致性問題，大多數時候可以保證強一致性。由于一般數據庫是讀寫分離的，寫的時候將寫的操作在數據庫中執行并存入緩存設置超時時間500ms，當讀的時候，先查緩存Redis，如果有相關記錄則從Redis中返回，如果沒有則說明已經同步到負責讀的數據庫中了，可以直接從讀數據庫中讀取數據，這樣也能做到讀寫數據庫的分離。
有關數據一致性問題可以參考《淺析數據一致性》。
之后就找了兩支筆，一人一只，然后在黑板上畫了個圖，基本是：App-緩存-數據庫三者之間的關系，然后讓我論述下。我看過很多分布式框架之間的資料，雖然現在的工作沒有太多機會去實踐，但是還能說個一二。基本上說了一通：負載均衡，流控，冪等性設計，數據一致性，緩存命中率，緩存失效，異常處理等。最后問了個如果緩存爆了，所有流量進入了數據庫怎么處理，當時博主沒想出來，只在讀寫分離上停留，后來面完下電梯的時候想起來分表分庫的操作。
###三面
三面的面試官就是一面的面試官，問了一些價值觀，對行業的看法，以及也問了些技術性問題。比如在二面中也被問及的問題：一條數據寫入時先寫入數據庫還是先寫入緩存？
###四面
四面的面試官比較有個性，有個小胡須。對簡歷上的信息問了一遍，技術性的問題沒怎么問。
比如，看到我簡歷上的學校（211的，簡歷上寫的本碩是一個學校，年級排名都是前5%，拿過一些獎學金神馬的）問我當時怎么沒想考研？比如博主同城的兩所985學校？我說當時想過，認真研究了一番只想考上交大，但是比對前一年的入取情況，入取分數很高而且二面的通過又非常的低，所以就選擇報送本校這樣簡單很多。面試官說：原來這么難考，我還不知道，我就是上交大的。
囧。。這都能撞上。。。。看我對上交大比較憧憬是不是要加點分。哈哈。
更多鏈接請關注：
這里有一份面筋請查收（一）
這里有一份面筋請查收（二）
這里有一份面筋請查收（三）
這里有一份面筋請查收（四）
這里有一份面筋請查收（五）
這里有一份面筋請查收（六）
這里有一份面筋請查收（七）
這里有一份面筋請查收（八）
參考資料
歡迎跳轉到本文的原文鏈接：https://honeypps.com/talk/interview-6/
歡迎支持筆者新作：《深入理解Kafka:核心設計與實踐原理》和《RabbitMQ實戰指南》，同時歡迎關注筆者的微信公眾號：朱小廝的博客。
總結
以上是生活随笔為你收集整理的这里有一份面筋请查收（六）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 这里有一份面筋请查收（五）
- 下一篇： 这里有一份面筋请查收（七）