先來問一下大家，如果你現在拿到兩個offer，一個是薪資更高的中小廠，一個是規模大、技術先進的大廠，你會選擇哪個offer？
不少粉絲股東留言説上岸大廠太難了，有沒有好上岸的中小廠的最新面經。
必須安排，今天分享一位朋友社招的面經：
富途 一面
- http相較於https多了什麼步驟？
- https證書為什麼一邊是對稱加密，一邊是非對稱加密（沒有回答出來）
解析：非對稱加密是為了保護證書裏的對稱密鑰，服務器只能用對應的私鑰解密拿到裏面的對稱密鑰，後續溝通時就通過證書裏的密鑰進行對稱加密溝通
- tcp揮手為什麼有第四次
- time_wait階段在哪裏，為什麼需要2MSL的長度
- 大量連接處於time_wait階段可能有什麼與原因，怎麼解決?
回答：大量連接同時關閉，關閉連接時加上隨機偏移值 解析：當大量短連接被快速創建和關閉時，會有大量的連接同時處於TIME_WAIT狀態。解決方法：
- 調整TCP參數：在服務器上調整TCP參數，比如減少TIME_WAIT的持續時間或增加可用端口範圍。
- 使用長連接：避免頻繁建立和關閉連接。可以通過使用長連接（例如，持續的數據庫或API連接）來減少進入TIME_WAIT狀態的連接數量
- 負載均衡：使用負載均衡技術分散請求，以減少單一服務器上的連接數。這樣可以平均分配連接負載，減少任一服務器上TIME_WAIT狀態的連接數量。
- 連接池：對於數據庫或其他需要頻繁建立連接的服務，使用連接池可以避免頻繁地打開和關閉連接，因為連接池允許連接被重用。
- 瀏覽器輸入回車後，發生了什麼
- 一道算法題：分段階梯計費
- 面試官提醒了一些問題：最後一個階段是（左界限 --- .....）之前的循環條件是按右界限來計算的。回答：那應該最後一個階段，單獨判斷下
- 如果後面分了很多階段，代碼有什麼優化的地方嗎？沒有想出來，不知道咋優化
- 一道SQL：（沒寫出來，sql語法都忘了）
解析：
FROM user u
JOIN thread t ON u.uid = t.uid
GROUP BY u.uid, u.username
ORDER BY post_count DESC
LIMIT 10;索引設計 對於這個查詢，可以設計以下索引：
- 用户表 (user)：
- 主鍵索引在 uid 字段上（通常在創建表時自動設置為主鍵）。
- 帖子表 (thread)：
- 一個複合索引在 uid 和 create_time 字段上，這有助於快速篩選出每個用户的最新帖子。
確定索引的使用
要確定 SQL 會使用哪個索引，可以在執行 SQL 查詢之前使用 EXPLAIN 或 EXPLAIN ANALYZE 命令（取決於具體的數據庫管理系統）。這將顯示查詢的執行計劃，包括是否使用了索引以及使用了哪些索引。
在 MySQL 中，則可以使用：
EXPLAIN FORMAT=JSON SELECT ...查詢是否最優
雖然上述查詢可能在大多數情況下都能很好地工作，但如果數據量非常大，這個查詢可能會變得緩慢，因為需要對所有用户進行聚合和排序。為了優化這個查詢，可以考慮以下策略：
- 確保數據庫使用適當的索引進行 JOIN 和 ORDER BY 操作。
- 對 thread 表的 uid 字段創建索引可以幫助加速分組和排序操作。
- 如果查詢仍然較慢，可以考慮物化視圖，預先計算並存儲結果，特別是如果這個查詢頻繁執行而數據變化不大時。
在查詢優化和索引策略中，需要根據實際數據量和數據庫性能測試結果來不斷調整和優化。
童心制物 一面
- 彈窗推送是負責哪部分
負責從MQ拿到數據解析後給下游服務，同事做極光推送
- 有改進或者特殊的點嗎
- 數據消息體的格式化，不同的topic的消息體不一樣，代碼寫起來很麻煩，所以直接做了格式化，數據就在payload裏面，其他的也在對應字段上。
- 跟具體解析業務代碼的數據交互是通過RPC，因為一個消息可能有多種業務的處理需要，這些也都需要想用返回，所以用了RPC的服務流。
- 彈窗是有定時和實時的嗎
是的，根據設備上報的協議字段做相關推送
- 工作中併發是怎麼應用的呢，看簡歷上寫了errgroup
電量api查詢時，比如一個月的用電，可能需要查一個月的每日用電量、當前一個月的累計用電、前一個月的累計用電。把一個大的任務分成多個小的任務，去併發調用執行，增加了接口的響應速度
- 這期間會出現什麼問題嗎，比如查詢不出來，或者超時怎麼辦
查詢不出來就置為0，然後能在報表上看見。 這個地方不知道怎麼咋説。
- 又遇到過什麼併發問題嗎？
沒有，説業務的併發量比較小
- 項目中有遇到比較困難的問題嗎
同一個子任務，但是不同的升級目標，在子任務的對象里加了一個鈎子函數，每次設備升級時檢查有沒有相同mac的舊任務在升級。有，就先讓舊任務結束，直接執行新的任務。
- 在靜默升級中，用了什麼中間件做存儲呢
redis和mysql，redis做臨時的緩存，存儲每個子任務的詳細信息，mysql最後打印報表
- redis用的什麼存儲方式呢
hset，哈希存儲，mac是key，升級相關信息是value
- 説一下channel
回答了無緩存和有緩存，無緩存用於通知是在靜默升級系統裏用到，每個Task同時只能有一個處於創建升級子任務的狀態，子任務創建完後執行升級。但是創建的狀態同時只能有一個Task（沒想明白為什麼，防止併發問題？如果有同時多個任務裏，有相同mac的子任務，那麼不知道最後執行完的是哪個，可能沒法升級到最新的版本，有可能是中途有問題的版本。可能出現高版本向低版本升級的i情況，有些設備允許，但有些不允許，可能會導致設備直接不可用）。
- GC，寫屏障是解決之前三色標記法的什麼問題
直接回答的八股
深圳小鵝網絡技術 一面
- 詢問測試環境是否分開，是否是docker搭建
- 能源數據報告的優化，怎麼優化
也説了預緩存一些電量水量的數據，因為結構都一樣，這樣更快
- MQ消息的有序
回答：解析因為使用了冪等性，狀態跳轉才會有觸發推送，那麼不管是否有序或者重複消費無所謂
- App的http請求在到達後端的鏈路是什麼樣的，經過了什麼服務或者網關
- 設計一個秒殺系統，怎麼保證庫存的一致性和不超限
回答：消息隊列做請求緩存，限流熔斷限制流量，下單操作只操作緩存，並異步更新到數據庫，減輕數據庫壓力，接口限流、用户身份驗證保證流量安全。保證一致性採用多級緩存（先更新數據庫，在更本地，在更redis）
- 多級緩存的話，現在有11個請求，有可能同時讀redis，這時讀到同樣的數據。減11次會出現庫存-1的情況，怎麼解決呢
開源中國 一面
- 介紹自己項目的模塊的亮點
回答：説了一個GRPC的通信
- MQ消費端沒有正常消費的話，可能有什麼原因
- 是否瞭解mq或者kafka的具體消息機制還是原理什麼的，有點忘了
這個直接説的只是簡單的消費，不是太深
- mysql的隔離級別
- redis就在項目中用做緩存嗎
- 是否用過k8s
- nginx用過，修改過一些參數
回答：只是修改了nginx的日誌地址，還有代理的節點，其他沒用過
堅定不移，聽話照做，按部就班，早日上岸！
加我微信，免費領面經，升職加薪：wangzhongyang1993，備註：面經。
