一面

1、自我介紹，換工作的原因是什么？

2、物流開發平臺是做什么？鏈路上都有哪些核心模塊？

一個單下過來，分配給哪個3PL？有什么要求嗎？是怎么設計的？

保證履約系統穩定性方面有做過什么事情？

軌跡推送過程中的最終一致性如何保證？

任職期間單量從多少變化到了多少？

第三方OMS/ERP可以直接請求到3PL，為什么還要通過你們平臺來做轉發？

3、Prometheus了解多少？只做接口層面的監控嗎？告警是怎么實現的？

4、下單鏈路中，從三方請求到你們，你們調用下游，再到下游調用3PL，整個流程是同步還是異步的？（例如，第三方下單請求，需不需要等待3PL給你們響應成功）

3PL物流公司系統掛了的話，你們這邊OpenAPI給三方也是返回失敗的嗎？

5、數據庫用的是MySQL嗎，ADO 10w的單量是怎么存儲的，有沒有什么設計？

6、go里頭函數參數傳參，slice，map，string這些是值傳遞還是引用傳遞？

7、如果收到一個請求，里頭有100個子任務，用go編碼時直接創建100個協程并發處理，是否合適呢，會導致什么問題？

8、Interface類型，要轉成原本的類型，怎么才能安全進行轉換？

二面

1、自我介紹

2、挑一個重點項目，主要在技術層面的挑戰、難點以及自己做的有亮點的，以及遇到的一些技術難題，是如何克服的？

3、剛提到的數據一致性通過事務保證，處理邏輯是在同一個節點上，同一個服務上去處理的嗎？用事務在性能方面會不會有一些瓶頸？里頭提到的樂觀鎖，你是怎么設計的？

4、從data service回寫數據到DB，分發不同協程去并發處理，針對budget主表和category子表，是不同數據在一個協程里頭寫2張表，還是2張表用不同協程去寫數據？

Channel的緩存大小當時定的多少，是怎么設計？

剛剛樂觀鎖的設計，除了你用的version字段，稍微發散一下，還有無其它的方式？

假設這些寫操作是在不同節點上執行的，怎么去保證一致性？

5、有了解過三階段提交嗎？兩階段(2PC)有什么弊端？有沒有聽說過那個叫Paxos算法？圍繞補償事務這個機制，你能簡單講一下TCC嗎？

6、MySQL用的多嗎，有沒有遇到什么實際問題，比如主持延遲、深度分頁等？

7、慢查詢你是如何優化的，針對這種情形，分幾方面說說你的解決思路，例如SQL語句、表結構設計的優化？

8、目前表的數據量有多少？分表后，總數據量有多少？那你們現在拆成了主表+副表（擴展表）的結構，怎么去滿足業務需求呢？

是會采用2個協程，并發去查數據，然后再組裝給到前端那邊嗎？

分表后，每個子表的數據量現在有多少？采用一下join方法去聯表，會不會有一些性能方面的影響呢？

9、MySQL的分表和分區有什么區別？什么情況采用分表，什么情況采用分區？兩者可不可以結合起來使用呢，例如我先做分表，再去做分區？

在分區的情況下，我能不能在select語句里頭指定查詢條件，只查某個分區，去加快查詢速度？

10、假設現在一張表里頭，有id主鍵，有一個（a,b）的聯合索引，你能不能說說這張表的底層數據結構是怎樣的？

Where a = ？ / a in (…)，這個SQL查詢語句，在底層的查詢過程是怎樣的，樹的遍歷是個什么順序？

11、Offset 1000000 limit 10; 這種深度分頁場景，底層的掃描過程是怎樣的，有什么優化思路？

12、B+樹如果有3層，大概支持的數據量是多少？查詢會走幾次IO？

13、假設說現在有一張大表，幾千萬的存量數據，在線添加索引或加字段的情況下，會出現什么情況，會鎖數據還是鎖表嗎？（上行鎖還是表鎖？）

對寫操作會阻塞，那讀操作呢？假設現在主從同步已經完畢的情況下

那換個問法，假設現在有一張存量數據5000w的表，你要往里頭去加一列字段，再加一個索引，應該怎么去操作呢？

14、有用過消息隊列嗎？基于MySQL和Redis，讓你實現一個延時隊列，在不考慮性能的情況下，你會怎么設計？那kafka為什么性能比較高，主要是那幾方面的原理保證？

15、有了解過sync.RWMutex的底層原理嗎

16、map為什么遍歷是不保證有序的？有了解它底層的BMap和bucket的一些機制嗎？

17、go的內存泄漏遇到過嗎，大概會有哪些場景容易發生，怎么去避免？go的GC會自動關閉channel嗎？

18、假設現在需要你快速上手一門新語言，或一門新的技術，你的學習路線大概會是什么樣？

19、對新的工作有什么期待嗎？

20、反問

“面經哥”已累計3000+條真實面試經驗，期待你的加入~