經過半年的沉積，加上對MySQL，redis和分佈式這塊的補齊，總算開端重拾面試決心，再次出征。
鵝廠
面試職位：go後端開發工程師，承受從Java轉言語。
都知道鵝廠是cpp的主戰場，而以cpp為背景的工程師大都對os，network這塊要求特別高，不像是Java這種偏重事務層的言語，之前面試Java的公司偏重仍是在數據結構、網絡、結構、數據庫和分佈式。所以OS這塊吃的虧比較大。
一面基礎技能面
電話面試，隨便問了些技能問題，最終還問了個LeetCode裡邊medium級別的算法題，偏簡略。
1、redis有沒有用過，常用的數據結構以及在事務中使用的場景，redis的hash怎樣完成的，rehash進程講一下和JavaHashMap的rehash有什麼差異？redis cluster有沒有了解過，怎樣做到高可用的？redis的耐久化機制，為啥不能用redis做專門的耐久化數據庫存儲？
2、了不瞭解tcp/udp，說下兩者的定義，tcp為什麼要三次握手和四次揮手？tcp怎樣確保有序傳輸的，講下tcp的快速重傳和擁塞機制，知不知道time_wait狀態，這個狀態呈現在什麼當地，有什麼用（參閱quic）？
3、知道udp是不牢靠的傳輸，如果你來規劃一個根據udp差不多牢靠的算法，怎樣規劃？
4、http與https有啥差異？說下https解決了什麼問題，怎樣解決的？說下https的握手進程。
5、看你項目裡邊用了etcd，解說下etcd幹什麼用的，怎樣確保高可用和一致性？
6、既然你說到了raft算法，講下raft算法的根本流程？raft算法裡邊如果呈現腦裂怎樣處理？有沒有了解過paxos和zookeeper的zab算法，他們之前有啥差異？
7、你們後端用什麼數據庫做耐久化的？有沒有用到分庫分表，怎樣做的？
8、索引的常見完成方法有哪些，有哪些差異?MySQL的存儲引擎有哪些，有哪些差異？InnoDB使用的是什麼方法完成索引，怎樣完成的？說下聚簇索引和非聚簇索引的差異？
9、有沒有了解過協程？說下協程和線程的差異？
10、算法題一個，劍指offer第51題，數組中的重複數字？
自己的答覆狀況，redis這塊沒啥問題，詳細rehash有印象是漸進式的，可是詳細原理或許答的有點出入。tcp的time_wait這塊答的不是很好，之前沒有了解過quic機制的完成，所以問牢靠性udp的時分，根本上腦子裡就照著tcp的完成在說。https這塊沒啥說的，之前項目裡邊有用到類似的東西，研討的比較清楚了。raft算法這個因為剛好在刷6.824（才刷到lab2。。。），答的也將就，不過paxos和zab算法的確不瞭解，直接說不會。MySQL這塊很熟了，包括索引，鎖，事務機制以及mvcc等等，沒啥說的，都現已補齊了。協程和線程，首要說了go程和Java線程的差異以及go程的調度模型。面試官提示沒有說到線程的有內核態的切換，go程只在用戶態調度。最終一個算法題，首先說使用HashMap來做，說空間複雜度能不能降到O(1)，後邊想了大約5min才想出來原地置換的思路。
二面項目技能面
1、首要針對自己最瞭解的項目，畫出項目的架構圖，首要的數據表結構，項目中使用到的技能點，項目的總峰值qps，時延，以及有沒有分析過時延呈現的耗時別離呈現在什麼當地，項目有啥改進的當地沒有？
2、如果請求呈現問題沒有響應，如何定位問題，說下思路？
3、tcp 粘包問題怎樣處理？
4、問了下緩存更新的模式，以及會呈現的問題和應對思路？
5、除了公司項目之外，事務有沒有研討過聞名項目或做出過貢獻？
根本都沒有啥問題，除了面試官說項目經歷稍弱之外，其餘還不錯。
三面歸納技能面
這面面的是陣腳大亂，面試官選用刨根問底的方法發問，終究是面試經歷不行，導致面試的節奏有點亂。 舉個比如，其中有個題是：go程和線程有什麼差異？
答：起一個go程大約只需求4kb的內存，起一個Java線程需求1.5MB的內存；go程的調度在用戶態十分輕量，Java線程的切換本錢比較高。接著問為啥本錢比較高？因為Java線程的調度需求在用戶態和內核態切換所以本錢高？為啥在用戶態和內核態之間切換調度本錢比較高？簡略說了下內核態和用戶態的定義。接著問，仍是沒有明白為啥本錢高？心裡瞬間潰散，沒完沒了了呀，OS這塊依舊是痛呀，支支吾吾半響放棄了。
後邊所有的發問都是這種模式，成果答覆的節奏全無，感覺被套路了。大多度都能答覆個一二甚至是一二三，可是再往後或者再深化的OS層面就GG了。
後邊問了下項目進程中遇到的最大的應戰，以及時怎樣解決的？
後邊還問了一個問題定位的問題，服務器CPU 100%怎樣定位？或許是因為平常定位事務問題的思想定勢，加之處於矇蔽狀態，隨口就是：先檢查監控面板看有無突發流量反常，接著檢查事務日誌是否有反常，針對CPU100%那個時間段，取一個典型事務流程的日誌檢查。最終才說到使用 top指令來監控看是哪個進程佔用到100%。果然陣腳大亂，張口就來，捂臉。。。 原本正確的思路應該是先用 top定位出問題的進程，再用 top定位到出問題的線程，再打印線程堆棧檢查運轉狀況，這個流程換平常肯定能答出來，可是，可是沒有可是。仍是得好好總結。
最終問了一個體系規劃題目（朋友圈的規劃），白板上面畫出體系的架構圖，首要的表結構和解說首要的事務流程，如果用戶變多流量變大，架構將怎樣擴展，怎樣應對？這個答的也有點亂，直接上來自顧自的用了一個通用的架構，感覺毫無亮點。後邊反思應該先定位事務的特色，這個事務明顯是讀多寫少，然後和麵試官交流一期剛開端的計劃的用戶量，性能要求，單機目標qps是什麼等等？在清晰體系的特色和約束之後再來規劃，而不是一開端就是用典型互聯網的那種通用架構自顧自己搞自己的計劃。
總結
1、tcp/udp，http和https還有網絡這塊（各種網絡模型，現已select，poll和epoll）一定要十分了解。
2、一定要有拿的出手的項目經歷，而且要可以講清楚，講清楚項目中取捨，規劃模型和數據表。
3、分佈式要十分了解。
4、常見問題定位一定要有思路。
5、操作體系，仍是操作體系，重要的事情說三遍。
6、體系規劃，思路，思路，思路，一定要思路清晰，一定要總結下體系規劃的流程。
7、一點很重要的心得，平常blog和專欄看的再多，如果沒有自己的考慮不過是曇花一現，根本不會成為自己的東西，就像內核態和用戶態，平常也看過，可是沒細想，俄然要自己說，還真說不出來，這就很為難了。勿以浮沙築高臺，基礎這種東西仍是需求時間去漸漸打牢，多去考慮和總結。
相關材料彌補學習資料，轉發+關注。私信我“資料”即可獲取。
閱讀更多 java高級架構 的文章
