本文來自我們技術交流羣羣友的投稿，未經授權，禁止轉載。
先聽一下TA的故事
去年10月份我就做好了離職跳槽的準備，做了3年Java後端開發的我，對自己的技術能力還是很有底氣的。之前雖不是一線大廠，也算是比較知名的中廠了。
加上前公司各種不合理的排期和需求，我感覺就是變相裁員，我這暴脾氣可不慣着這個。
我就請假約面試，沒想到，被社會毒打了，Java太捲了，要求好高，各種拷打底層。（加上我對Java確實不太感冒~）另外我不是科班出身，是文轉碼，難頂呀~
之前公司有事業部使用Go語言，那時候也瞭解了一些，加上不少Java羣都在聊Go語言，我也準備轉Go試試。做兩手準備吧，這樣能更穩妥一點。
裸辭
哎，公司各種變態需求和排期。我們心裏都清楚公司是咋想的，我的很多同事都準備耗着，等補償。
我最開始也是這個想法，但是説實話，這種上班的日子每天都是煎熬。
之前也累，是加班趕項目的累。
現在的累，是心裏累，內耗的累，太難受了，在公司工作也不痛快，新東西也學不下去，很難做跳槽準備呀。
想請假面試也不批，咋搞！？
老子不慣着，裸辭了！
2025年元旦過後沒幾天我就裸辭了！
放鬆
因為之前公司太累了，裸辭之後踏踏實實在家裏休息了半個多月，睡到自然醒，自己做飯、遛彎、打球、逛街、爽。
然後也該準備好工作了，給自己制定計劃，準備踏踏實實學Go。我準備做Java和Go做兩份簡歷出來。
我覺得只是換個語言，問題應該不大，之前的項目經驗也是很豐富的，學唄！
長遠目標
我計劃是3月底4月初能拿到Offer就行，反正手裏的錢也夠花。不着急呢。
春節也踏踏實實過，提前回家過年。
春節之後突擊一下，把Go基礎和併發編程好好搞搞，還有之前的項目經驗，好好梳理一下。然後就是各種突擊八股文，學！學！學！還是學！
另外堅持每天健身，好身體才能有好狀態嘛！
面試
春節之後，我是從3月份才開始約面的，到3月27號面試了大概20多家公司，參加了30多場面試。終於拿到合適的Offer了。
我本來是想衝一衝字節這樣的大廠的，算法也準備的挺充分的，一面自我感覺面試的不錯，但是不知道為啥沒過...
後來分析，可能是被卡學歷，卡專業了吧
目前手上有2個Offer，選擇了其中更合適的一家，薪資漲幅不小，對得起我這兩三個月的付出。
好了，下面我就給你分享一下我的Go面經，也祝大家能早日上岸，順利找到工作：
杭州默安
1.slice切片(一定看底層結構體實現)
2.GMP模型
3.聊聊什麼是鎖. Mutex, RWMutex, redis分佈式鎖。
這塊聊的很深, 差不多10分鐘,甚至問了鎖的狀態在硬件上是怎麼記錄的
4.go的GC原理以及寫屏障是什麼
5.docker的六大命名空間?
每個容器有自己的命名空間, 包括網絡,進程,IPC, 文件系統等. 通過這種方式, 容器之間相互完全隔離, 不會相互影響
- 進程命名空間: 為每個容器創建一個新的進程進程ID(PID)空間, 使得容器內的進程看起來像是獨立的操作系統中的進程
- IPC命名空間:
- 網絡命名空間
- 掛載命名空間
- UTS命名空間
- 用户命名空間
6.網絡七層模型?
應用層, 表示層, 會話層, 傳輸層, 網絡層, 數據鏈路層, 物理層
7.算法:
- 口述堆排序
- 如何判斷鏈表是否有環
8.mysql如何存儲ip地址比較合適？如何查詢效率比較高？
- 使用varchar存儲 浪費空間，無法直接實現範圍查詢
- 使用int數值存儲 佔用空間較小
- 使用binary二進制位存儲
前海匯流
1.https和http的區別?
2.https的加密是對稱加密嗎?
內容傳輸是對稱加密, 證書校驗是非對稱加密
3.瀏覽器輸入谷歌地址, 請描述整個訪問過程發生了哪些步驟?
4.tcp三次握手四次揮手? 如果只有兩次會出現哪些問題?
5.聚簇索引和非聚簇索引的區別?
6.b+樹索引的特點?
7.DNS域名解析過程
8.一道sql題
數據庫中有以下兩張數據表：
廣告表
表名：ad
字段：id, title, create\_time
訂單表
表名：order
字段：id, ad\_id, cost, create\_time
請寫一條 SQL，查詢訂單數量最多的前十條廣告，並返回以下信息：
廣告ID、廣告名稱、訂單數量總和、訂單費用總和。
雲智創心
1.grpc底層用的什麼協議?
http2.0
2.http2.0和1.1的區別?
- 多路複用: 1.1每個請求必須是獨立的TCP請求, 2.0採用多路複用, 一個TCP連接可以進行多次請求, 大大提升性能
- 數據傳輸: 2.0引入數據流的概念, 允許不同請求在同一連接交錯發送
- 頭部處理: 2.0 採用HPACK算法對頭部數據進行壓縮, 降低數據大小和網絡開銷
- 二進制協議: http/1.1報文頭信息必須是文本, 數據體可以是二進制,也可是文本。2.0 頭信息和數據體都是二進制, 更加高效的處理數據
- 錯誤處理: 1.1處理錯誤需要關閉連接, 2.0引入可以在不關閉連接的情況下處理錯誤
3.gRPC有幾種請求模式?
- 簡單模式: 客户端發起請求, 等待服務端響應. (例如普通的grpc定義message, 一次請求一次響應)
- 服務端流式(長連接): 客户端發送請求, 服務端返回一個流, 客户端持續監聽這個流, 反序列化其中的內容, 返回給用户,適用於客户端需要向服務端發送大量數據的情況, 如文件上傳
- 客户端流式(長連接): 客户端創建一個流, 將請求參數以流的方式給服務端, 服務端再返回單個響應, 適合服務端向客户端發送大量數據的情況, 例如實時數據傳輸
- 雙向流式: 允許客户端和服務端同時讀寫數據. 雙方都可以隨時開始和結束數據的發送. 適合雙向數據傳輸模式
傳統的http連接時短連接, 一次請求一次響應後, 連接就斷開了, 然而, 客户端流式RPC和服務端流式RPC模式基於TCP長連接, 用於多次數據交換.
4.protobuf瞭解過嗎? 和有什麼區別? 對比json有什麼優勢? 壓縮率對比json來説能達到多少?
和json的對比:
- protobuf使用二進制格式, json為文本格式, 所以protobuf的序列化和反序列化更加高效
- 由於使用二進制傳輸, protobuf的體積通常更小
- protobuf是強類型的, 定義數據結構時必須指定每個字段的類型, 可以減少解析時的錯誤, json是弱類型的, 不強制字段的類型
5.var定義slice, 不使用make聲明, 可以直接使用嗎? 數組可以直接使用嗎?為什麼
切片不能直接使用. 如果不進行make, 那麼切片是nil, 不能直接使用
數組可以直接使用, 數組在創建時已經固定了大小, 會被立即分配內存
6.go中有幾種方式可以解決併發安全問題?
1.併發原語2.mutex鎖3.channel
7.mysql中，如何判斷一個字段是否適合建立索引？
- 該字段是否經常作為查詢條件
- 區分度高的字段
- 列的數據類型。文本字段建立索引佔據更大空間, 數值字段效率更高
- 更新頻率。如果是經常發生寫操作的字段，由於需要維護b+樹的索引結構，會降低效率。
8.如果讓你設計一個消息隊列，你會如何設計？需要考慮哪些問題？
9.項目中限流是如何設計的，使用的是go-sentinal.
10.如果讓你設計限流器，你如何設計？
令牌桶\滑動窗口算法\漏斗算法
中軟國際
- 口述用户註冊功能的整個流程, 如果兩個請求同時使用相同用户名進行註冊, 如何保證註冊邏輯正確
- 算法: 合併區間
網心科技
1.一個訪問url是如何找到微服務的？
2.一次完整的url請求過程
3.RPC協議瞭解嗎？grpc協議瞭解嗎？
4.restful請求和RPC協議的區別？
5.rpc通常是長連接還是短連接？
6.webSocket是長連接還是短連接？
7.主鍵索引和非主鍵索引的區別？
8.mysql中union和union all的區別？
union: 對兩個結果集進行並集操作, 不包括重複行, 相當於distinct, 同時進行默認規則的排序
union all: 對兩個結果集進行並集操作, 包括重複行, 即所有結果全部顯示, 不管是否重複
9.exist和in的區別？
in函數執行的原理:
先查詢in中的語句, 講結果緩存, 然後使用主查詢結果, 匹配in中的緩存結果, 所以in中的數據量如果是比較小的, 那麼查詢效率快, 否則拖慢查詢
10.索引優化?
11.context是如何使用的?
12.引用類型有哪些?
13.map是線程安全的嗎?
14.go中的struct能否進行比較?
15.range迭代map是有序的嗎?
16.場景: 製作登錄系統, 允許手機端, pc端, 平板端多端登錄, 一旦有一端修改密碼, 其它端登陸態失效, 如何設計?
17.給定一個整數數組, 判斷該數組是否有序(注意: 升序或者降序都判斷為有序)
卓易科技
1.介紹一下gin中的中間件? (如何自定義一箇中間件)
2.gin的攔截器有c.next放行的方法, 那麼它是如何做到執行完畢鏈路方法之後, 又返回到當前攔截器位置的呢?
c.next() c.abort()
gin的中間件實際上還是gin.HandlerFunc, 和其它處理器是一樣的
執行完next之後, 又返回當前中間件的特性, 依賴go語言的閉包和函數運行棧實現.
執行next放行後, 將當前函數入棧, 直到遇到c.Abort()返回, 然後根據原來的鏈路反向執行回去, 而且閉包允許引用函數外的變量和函數,返回時可以直接正常運行
3.切片的擴容機制?
4.內存對齊?
內存對齊是計算機硬件對內存數據訪問的一個優化手段。當數據在內存中的地址是某個固定大小的整數倍時，處理器訪問該數據的速度會更快。
這種優化可以減少處理器訪問內存的次數，提高程序的運行效率。例如，一個int32類型的變量在32位處理器上通常需要對齊到4字節的邊界，而在64位處理器上可能需要對齊到8字節的邊界。如果不對齊，處理器在訪問這些數據時可能需要進行額外的內存操作，這會影響程序的性能。
5.索引? 回表查詢?
6.mysql中的數據是如何加載到內存中的, 如何寫入到磁盤中的?
7.開啓了事務, 剛執行完插入, mysql宕機, 如何保證的這條數據不插入成功
8.redis是怎麼使用的? redis的訂閲和發佈?
9.http狀態碼: 1開頭的
10.get和post的區別? (網絡層面)
11.給定兩個數組, 求兩個數組的交集
12.數組長度為30億, 最小數字為1, 最大數字為35億, 判定給定的數字是否出現在數組中
廣州山海娛樂
1.假設有一台本地及其,無法做加減乘除運算, 我們提供了一個服務器端的Http API, 可以串兩個數字類型的參數, 響應結果是這兩個參數的和, 請寫一個高效的函數, 調用遠程方法, 計算出結果
2.redis常用的類型? 以及使用用途
3.場景: 基於redis實現限流, 每分鐘限定用户只能訪問100次, 如何實現?
使用sort set, 分數設置為訪問時間, 訪問時間-60秒, 判斷有多少個請求, 如果大於100, 則不允許請求
4.mysql失效場景?
mysql自動評測,如果數據量小, 不走索引, 當使用order by時, 如果發現走索引的效率比較慢, 也會捨棄索引
5.索引優化做過哪些優化?
6.最左前綴法則的原理是什麼?
7.id, name兩個字段, where name like %abc%, 有1000萬數據, 怎麼進行優化?
先根據name查詢id, 再根據id查詢出所需要的字段
8.prometheus怎麼使用的? 存儲類型是什麼?
9.kafka如何保證的消息有序?
10.有併發場景嗎?
11.講一下整個服務的組件鏈路
貝聯珠貫
1.waitGroup, 如果有一個協程卡死了, 不返回context處理, 定義超時時間, 和公共狀態, 如果出錯了, 協程中使用context處理超時, 並且講公共裝填設置為true
2.你們的流量表數據量有多大?
3.抓取一次接口數據要響應時間要多久?
4.緩存?
5.輸出100個100以內加減法
小白羽
1.每天的線索量有多少?
2.GMP模型
3.Innodb的ACID是如何保證的?
4.微博熱搜功能如何實現? 小頂堆+redis排序
5.給定a,b兩個字符串, 判斷字符串b是否為字符串a的子串
前海匯流
1.http和https的區別?
2.https用的是對稱加密還是非對稱加密?
3.b+樹索引結構的特點? 底層的葉子節點起到的作用是什麼?
4.聚簇索引和非聚簇索引的區別?
貝聯珠貫
1.表中數據量有多大?
2.哪些適合內存存儲? 哪些適合mysql查詢?
3.索引優化?
4.開發使用的是什麼框架? 如果要實現接口鑑權效果, 怎麼實現?
5.瞭解規則引擎嗎? 如果自己設計狀態機, 如何設計?
6.場景題: 一個日誌文件, 有100萬行, 其中每一行可能出現重複的日誌, 請找出前50條重複次數最多的日誌
7.小頂堆排序的時間複雜度是多少?
8.有使用過channel嗎
9.sql執行慢的原因？ 如何排查？
- 查看是否建立了索引， 索引是否生效。解決方案： explain查看索引命中情況，以及查詢時間
- 單表數據量過多，導致查詢瓶頸。解決方案：水平分表，垂直分表，分庫： 例如已經拆分萬1000張表，將0-100放到同一數據庫實例中，將100-200放到另外一個數據庫實例中，依此類推把1000張表存放到10個數據庫實例中。 這樣根據業務主鍵將請求路由到不同的數據庫實例， 從而讓每個數據庫實例的流量比較小， 達到提高數據庫性能的目的。
- 網絡原因導致機器負載過高，可以部署一主多從的mysql集羣，提高mysql的查詢處理性能
- 熱點數據導致單點負載不均衡。
10.進程與線程的區別：
- 本質區別：進程是操作系統分配資源的最小單位，線程是處理器任務調度的最小單位
- 包含關係：一個進程至少有一個線程，線程是進程的一部分
- 資源開銷：同一進程內的線程共享進程的地址空間，每個線程都有自己獨立的運行棧和程序計數器，線程間切換的開銷小
4.影響關係：一個進程崩潰後，其它進程不受影響。 一個線程崩潰，可能導致所屬進程被系統殺掉
11.slice的擴容機制：
go1.18版本後， 擴容使用threshold為臨界點（源碼中設置為256）
當slice容量 < 256時， 每次擴容為原來的兩倍。當slice容量 > 256時， 每次增加(oldcap + 3*threshold) 3/4
12.tcp和udp的區別?
- 連接: tcp需要建立連接 udp不需建立連接
- 服務對象: tcp是一對一, udp可一對一, 一對多
- 可靠性: tcp可靠, 有序, udp不可靠, 無序
- 擁塞控制,流量控制: tcp擁有擁塞控制和流量控制, 保證數據傳輸的安全性, udp即使網絡非常擁堵, 也不影響udp的發送速率
- 傳輸方式: tcp為流式傳輸, 沒有邊界, 但保證順序和可靠, udp是一個包一個包發送, 有邊界, 但是可能丟包或亂序
- 首部開銷: tcp的首部開銷大, udp的首部只有固定的8字節,開銷小
13.restful請求?
get: 表示讀取服務器上的資源
post: 表示在服務器上創建資源
put: 表示更新或者替換服務器上的資源
delete: 表示刪除服務器上的資源
patch: 表示更新/修改資源的一部分
14.restFul請求和http請求的區別?
http 是一種應用層協議, 它定義樂客户端如何與服務器進行通信, 包括請求和響應的格式.
restFul是一種軟件架構風格, 依賴於http協議來實現, 然後根據對資源的不同操作類型, 劃分為不同的restful請求
15.什麼是grpc? protobuf/json區別與優勢？
- grpc是遠程調用框架，基於http2.0實現，允許在計算機之間進行跨語言，跨平台通信，使得構建分佈式系統更加簡介高效
- grpc使用protocol buffer作為默認序列化機制，比json更加高效
嗶哩嗶哩
算法1: 順時針旋轉矩陣
算法2: 合併區間
字節跳動
1.介紹一下業務表的字段
2.定時任務刷新字段, 是怎麼實現的?
3.分佈式鎖? 分佈式死鎖如何解決? 看門狗機制? 如何避免當前線程加的鎖, 被其它線程解鎖?
4.樂觀鎖和悲觀鎖的區別? 寫多讀少的情況, 應該使用樂觀鎖還是悲觀鎖?
5.分佈式場景下, 如何實現樂觀鎖?
6.kafka的冪等性? 如何避免消息被重複消費?
7.兩個線程, 同時向mysql中插入一條數據?
8.kafka如何保證消息不丟失
9.sql優化場景:
select id,name,balance from account where update_time > '2020-09-19' limit 100000, 10
該語句為什麼查詢慢? 有什麼優化思路?
- 算法題: 子集
客路航運
1.http和gRpc的區別?
2.mysql,redis,mongoDB,ES 説説如何根據使用場景,選擇對應的存儲組件?
3.線上的接口性能差, 如何排查和提高?
4.redis常見的數據結構?
5.找出鏈表的倒數第N個節點。如何判斷鏈表有環?
6.分庫分表如何設計?\
場景: 例如本訂單表是按照id進行的分表, 但是有的查詢, 需要根據id進行查詢, 有的查詢需要根據活動id查詢, 如何實現這個分表方案?
- 按照id進行分表 再按照活動id進行分一次表
- 如果事務要求不高, 可以將活動的數據同步到ES, 使用es進行相關查詢
- protobuf相較於json的優勢？
- 效率高：protobuf使用二進制編碼，編碼解碼速度更高，體積更小
- 可讀性: 雖然protobuf是二進制格式，但是其定義文件是可讀的，大型數據結構情況下，更加易於維護和理解
- 跨語言支持：protobuf支持多種編程語言
8.redis中的數據類型？底層結構?
redis list的邏輯類似雙向鏈表，每個節點有next，prev兩個指針，和一個value指針真正存儲值，如果單純使用雙端鏈表，會出現問題
- 如果每個node節點中，value指針指向的數據很小，比如只存儲了一個int值，那麼prev,next指針佔據的Node節點的絕大部分的空間，真正存儲數據的有效負載就很低，鏈表節點出現很多的話，就會出現很多不連續的內存碎片
- 鏈表查詢時，需要沿着鏈表順序進行查詢，所以雙端鏈表的查找效率低
redis7.0前的版本為解決上述問題，實現了quickList的結構，將Node節點的value指針，指向一個ziplist實例，ziplist是一塊連續的空間，可以存儲多個list的元素，這樣quickList與普通鏈表相比，Node節點數量會更少，內存碎片也更少，而且一個Node中存放了多個元素，prev,next指針佔據的空間比例很少，有效負載變得很高
ziplist雖然是一塊連續空間，但是不能像數據一樣進行隨機訪問，查找元素的時候同樣需要從頭開始掃描，但是ziplist是一塊連續空間，就不會像Node查找一樣有很多指針解析的開銷，數據量少時，迭代一遍的效率比較快
9.漸進式rehash?
在resis使用過程中，當哈希表已經到達容量上限，redis通過rehash進行rehash進行擴縮容。但是，redis執行命令時單線程模型，對當前哈希表進行rehash時，一次rehash操作可能導致服務器出現阻塞並停止對外服務。為解決該問題，使用漸進式rehash方案，就是將rehash分為多次完成。在redis中，字典數據結構底層使用兩個全局哈希表實現，為方便理解稱之為哈希表1和哈希表2。另外，字典還維護一個rehashIdx字段，來記錄rehash操作的下標位置，初始值為-1，代表未進行rehash操作
漸進式rehash的詳細步驟：
- 首先為哈希表2分配空間，默認長度時哈希表1長度的2倍
- 設置索引計數器變量rehashInx為0， 表示rehash工作正式開始
- 在rehash進行期間，每次對字典執行增刪改查操作時，除了執行指定的操作以外，還會把哈希表1在當前rehashInx索引上的所有鍵值對rehash到哈希表2。 當rehash操作完成之後 rehashInx屬性的值就會+1
- 隨着字典增刪改查操作的不斷執行，最終所有鍵值對都會被rehash到哈希表2中。rehash操作完成之後，哈希表1table數組的指針指向哈希表2 table數組的指針， 哈希表2 table數組的指針指向 null, 並將 rehashIdx 屬性的值設置為-1， rehash操作完成
注意：
- 在漸進式rehash進行期間，字典的刪除，查找，更新等操作，會在兩個哈希表上運行
- 在漸進式rehash執行期間，字典的添加操作權在 哈希表2 上進行
- rehash後新的下標為N或者N+size，N+為原下標，size為原數組大小
10.分庫分表:如果分表策略, 不能滿足查詢條件要求, 怎麼處理?
方案1: 按照多個查詢條件, 拆分為多個冗餘表。方案2: 例如按照id拆的,那麼正常拆,正常拆,不重要的查詢字段, 將數據同步到es中, 走es查詢
富途
1.kafka如何做的容災?
2.kafka的性能為什麼高?
3.用户態和內核態?
4.mysql的容災如何做的?
5.mysql從庫的同步模式?
- 異步複製: 默認為異步同步. 主庫提交事務後, 立即返回給客户端, 不關心從庫是否已經接收並處理.問題: 如果主庫宕機, 由於主庫數據沒有同步到從庫, 可能導致數據丟失
- 全同步複製: 主庫執行完事務, 必須等到所有從庫執行同庫完畢, 才算事務執行成功
- 半同步複製: 主庫至少需要等待一個從庫接收並寫入RelayLog文件即可.
6.數據庫的事務隔離級別是什麼? 遇到過幻讀嗎? 如何解決幻讀?
幻讀: 當前事務查詢不到對應數據, 但是插入該數據插入不進去
7.mysql中有哪些鎖?
行級鎖, 表級鎖
8.go如何啓動一個協程?
9.協程和線程的區別?
10.進程和線程的區別?
11.有線程為什麼還需要協程? 主要是對線程的哪個問題進行了優化?
12.linux的硬鏈接和軟連接?
13.go的內存逃逸?
14.interface一般都是怎麼使用的?
15.https如何保證的安全?
16.https連接的密鑰流程?
公鑰是公開的, 私鑰是服務端私有的, 客户端先發送請求,服務端接收請求後, 服務端根據公鑰對 響應回公鑰
17.time\_wait是解決什麼問題的?
18.算法: 最長迴文子串?
360
1.協程池的作用?
2.內存逃逸分析?
3.go的內存回收什麼條件會觸發? go的GC能夠手動觸發嗎?
4.channel的底層實現? 有緩衝的,無緩衝的channel, 如果管道已經關閉了, 讀取會不會發生錯誤?
5.切片使用的時候需要注意什麼?
6.go中的參數傳遞是值傳遞還是引用傳遞?
7.defer的執行順序?
8.100G的文件, 統計出所有英文字母, 按照字母表順序輸出
9.linux如何分割文件?
10.接口性能如何優化?
11.什麼情況會全表掃描?
12.主叢同步的原理? mysql還有什麼相關的log文件?
13.分佈式鎖的原理?
樂信
1.項目中用到哪些設計模式?
2.promethus如何使用的?
3.協程池自己實現的還是第三方包? 協程池的功能有哪些? sync.Pool的回收機制
4.如何獲取進程中運行的協程數量?
5.遇到的線上故障有哪些?
6.線上go程序佔用內存是多少?
7.接口優化思路?
8.線上每張表的數據量有多大?
9.如何提升數據庫層面的性能
10.ES如何使用的? 倒排索引的原理是什麼?
11.自己實現過哪些數據結構?
12.用户10分鐘內, 如何只看到同一條廣告
13.go語言和java語言的差異點
14.GC回收原理
15.項目中的難點
16.go應用突然掛了, 都有哪些原因? 如何排查?
17.recover能夠捕捉到子協程的錯誤嗎?
酷狗音樂
1.mysql存儲引擎?
2.mysql隔離級別? 分別解決了什麼問題?
3.2pc, 3pc 算法
4.10億個數據獲取前100個最大數據?
5.單個表到達多大要進行拆分? 為什麼需要拆表?
6.redis哪些使用場景?
7.服務的熔斷降級?
8.平時如何提升和學習?
9.TCP和UDP可以綁定同一個端口嗎?
10.linux如何查看cpu, 內存負載?
11.進程間通信有哪些方式?
12.redis的數據類型?
13.redis和mysql的一致性問題?
AfterShip
1.最熟悉,最有收穫的項目
2.協程池使用的第三方包還是自己實現的?
3.GMP中, P的數量大小默認是多少? P的數量是固定死的還是可以手動調整的?
cpu核心數. 可以通過設置環境變量 GOMAXPROCS來調整P的數量
4.kafka的一致性? kafka默認的ack級別?
一致性: 可靠性, 冪等性, 有序性.默認ack級別為1
5.kafka掛了, 如何保證異步消息不丟失?
- 設置ack級別為-1, 所有副本都收到才算成功寫入
- 設置重試次數, 發送失敗可以重試
- 開啓冪等性, 確保重試也不會產生重複的消息
- 將消息寫入mysql數據庫, 然後再異步發送到kafka
6.kafka事務消息?
指生產者向kafka發送消息時, 要麼全部發送成功, 要麼全部發送失敗並回滾.
確保了消息的一致性,原子性操作和精準一次消費.
生產者產生一條事務消息, 獲取一個事務id, 發送事務消息時, 是同步發送的, 保證消息一定順利寫入broker
如果發送的是異步消息, 對於生產者來説, 發送後即顯示發送成功, 但是下游broker的ack級別如果是-1, 那麼只有該消息全部副本同步成功, 才算發送成功,所以異步消息還是會受ack級別影響.
7.口述堆排序的原理?
8.聊天系統如何直到客户是否在線? 用户聊天使用的是長連接還是短連接?使用websocket連接, 還需要自己實現心跳保活嗎?
不需要, websocket自己已經實現了心跳保活機制, 只需要設置pingInterval和pingTimeout即可
百度
1.GMP模型?
2.協程創建後如何調度?
先進入p的私有隊列, 如果滿了, 進入全局隊列
3.context的結構和用法
4.一次url的請求過程?
5.請求到達項目服務器後的調用鏈路
6.nginx是否為單例的.
7.算法: 兩數相除
8.平時mysql優化的案例?
9.in, exist的使用
10.聯合索引
11.binlog日誌
12.分佈式事務: 下游兩個db使用redis, 需要更新這兩個不同的db, 如何自己實現最終一致性
13.兩階段提交, 三階段提交?
歡樂互娛
1.slice和array的區別?
2.map是否併發安全?
3.channel相關? 如果沒有初始化, 可以寫嗎? 可以讀嗎?已經關閉了, 再寫?
4.如果是無緩衝類型管道? 讀取和有緩衝的區別?
5.select監聽多個管道
6.10個goroutine想要順序執行, 如何實現?
7.10個協程同時執行, 如果其中有一個協程產生了錯誤, 其它協程停止運行, 如何實現?
8.如果controller方法中啓動了一個go協程, 如何保證該協程和方法的生命週期一致?
9.接口性能優化?
10.分庫分表? 水平分表, 垂直分表
11.項目中技術難點?
12.kafka重複消息問題?
13.ES如何使用的? ES的延遲?
14.一個服務已經跪了, 但是其它服務依賴該服務,如何在編碼層面處理?
15.nginx具體的處理過哪些問題?
16.端口有大量的time\_wait如何解決?
- 減少time\_wait的等待時間
- 檢查連接池是否夠用
17.場景題: 兑換碼永久有效, 海量玩家同時進行兑換, 如何設計?
緩存, 布隆過濾器.
18.算法題: 函數只能勝場1-5的函數, 請實現生成1-7的函數
迴響科技
1.服務註冊和發現?
2.grpc的序列化和反序列化協議?
3.設置分佈式鎖的命令? setnx
4.redis的事務? redis執行lua腳本, 為什麼lua腳本能夠保證原子性執行?
redis是單線程的, 會把當前腳本執行完後再執行其它命令
5.redis的持久化方式? AOF在持久化時的優化策略?
當文件超過某個閾值時, 保存當前文件的快照, 舊的AOF文件就捨棄不用了, 因為只需要記錄數據最新的狀態即可
6.sort set的底層實現?
7.kafka的結構? ack默認級別?
8.有序性如何保證?
9.用户表? 字段為性別, 1和2 適合建立索引嗎? 建立索引反而導致查詢變慢的原因?
10.最左前綴法則?
11.訂單列表, 越往後翻越慢, 原因是什麼? 如何進行優化?
12.es用過嗎?
13.訂單定時關閉? 延遲隊列?
rocketmq, kafka本身沒有實現延遲消息隊列的功能.
kafka:
常見的實現方式可以使用主題分區和時間戳, 可以創建一個專門用於延時消息的主題, 該主題創建多個分區, 將要延時發送的消息發送到該主題, 設置消息的期望執行時間. 消費者訂閲該主題, 按照時間順序消費消息, 判斷當前時間是否到達了消息設定的執行時間, 如果達到則執行相應的操作, 否則將該消息重新發送到延遲隊列rabbitmq:ttl+死信隊列實現延遲隊列, 可以給指定隊列或者消息設置ttl過期時間, 一旦到達過期時間, 那麼會稱為死信, 可以發送到指定的死信隊列
14.時間輪算法?
15.多協程編排? waitGroup的實現?
16.單例模式
17.層序遍歷二叉樹
好未來
1.為什麼要自己實現大頂堆? 大頂堆和小頂堆的使用場景?
2.如何利用堆, 獲取第k大的元素? 堆如何刪除某一個特定的節點? 大頂堆如何轉換為一個小頂堆?
3.引入mq, 實現異步提速, 如何理解?
4.協程池使用的是第三方包嗎? 如果自己實現一個協程池, 描述你的思路?
5.recover能捕獲到其它協程的panic嗎?
6.説一下對grpc的理解? grpc互相調用, 如何實現互相的權限驗證和授權?
7.http2.0 的tsl三次握手過程?
8.grpc中, 如果客户端需要向服務端發送大文件, 如何實現? (使用客户端流模式)
9.http2.0的相關特性? 其中的多路複用為了解決什麼問題? (解決對頭阻塞問題)
10.grpc中的deadLine和timeout, 應該怎麼用?
grpc的流控是如何處理的? 滑動窗口控制發送和接收速速率?
11.go-zero中的服務熔斷和限流是怎麼做的?
12.以下兩個代碼片段輸出的結果:
func test() int {
result := 1
defer func() {
result++
}
return 0
}
func test() (result int) {
result = 1
defer func() {
result++
}
return 0
}酷狗音樂(二面)
1.項目中涉及到哪些監控? prometheus
2.隊列出現消息積壓, 如何處理?
3.消息冪等性?
4.一個sql語句, 已經建立了索引, 但是突然查詢很慢, 如何排查?
5.索引失效場景?
6.mysql如何解決的幻讀?
select ... for update: 保證當前事務中查詢的範圍加鎖, 不被其它事務修改
7.做索引優化, 如何減少回表次數--索引下推
索引下推: 指將上層(服務層)負責的事情, 交給下層(引擎層)處理.
不使用索引下推: 根據索引中的主鍵值, 定位並讀取完整的行記錄, 然後將記錄交給server層去檢測該記錄是否滿足where條件
使用索引下推: 獲取索引, 判斷索引是否符合條件範圍, 如果滿足, 再進行對應的回表查詢獲取主鍵, 如果不滿足, 直接過濾掉
8.分佈式事務, 二階段提交, 三階段提交的區別?
9.linux查看網絡io的命令? netstat
10.如果出現大量time-wait狀態, 如何處理?
11.網絡的擁塞控制?
好未來(二面)
1.限流算法
2.redis的集羣和分片
3.cap理論
度小滿
1.限流算法 nginx默認使用的是哪種限流算法?
2.redis常用的數據結構
3.redis的緩存擊穿, 緩存穿透, 緩存雪崩 以及相關的解決方案
4.redis中內存滿了, 繼續寫入, 會發生什麼?
- LRU算法刪除數據
- 刪除帶有過期時間的鍵
- 隨機刪除鍵
- 不刪除任何鍵, 返回錯誤
5.redis清理過期key的時機? redis刪除key時, 是新啓動一個進程處理刪除任務嗎
6.redis中有大量的key都是長期有效的, 現需要掃描所有的key, 進行特殊判斷, 符合條件進行刪除
7.redis的刪除命令 del
8.redis的掃描命令: scan和keys的區別? 對redis的性能是否有損?
keys: 用於返回匹配指定規則的所有鍵, 類似mysql中的like模糊匹配功能
問題1: keys需要將所有redis中的鍵都遍歷一遍,對性能影響較大
問題2: keys命令是一個阻塞命令, 直接阻塞其它客户端對redis的訪問
線上一般嚴禁使用keys命令, 由於數據量過大, 可能一個命令直接導致redis不可用
scan命令:
- scan命令的時間複雜度也是O(N), 但是它是分次進行的, 不會阻塞線程
- scan命令提供了limit參數, 可以控制每次返回結果的最大條數
但scan命令返回的結果可能出現重複, 需要客户端去重.
9.mysql事務四大特性, 隔離級別? 是否解決了幻讀?
10.mvcc採用的是什麼日誌文件?
11.select ... for update使用的是當前讀還是快照讀?
當前讀
12.mysql的調優經驗? 索引下推?
13.主鍵索引和唯一索引的區別?
14.sql語句: 表中有name, city字段, 查詢city中人數前三的數據
15.引用類型和值類型的區別?
16.切片的擴容機制
17.map是否為併發安全的? context是否為併發安全的?
在Go語言中，context.Context 是併發安全的。
這意味着你可以在多個goroutine之間安全地共享和傳遞同一個 context.Context 實例，而無需擔心數據競爭或其他併發問題。context.Context 的設計考慮到了併發編程的需求，它內部使用了適當的同步機制來確保在多個goroutine訪問時能夠保持正確的狀態。因此，你可以放心地在多個goroutine中使用同一個 context.Context 來傳遞取消信號、超時信息或其他元數據。
感謝分享，一起上岸
感謝羣友的分享，希望這篇最新面經對大家有幫助。
更多面經請關注我，或者直接私信我，領取免費面經。
