我在 github 上新建了一個倉庫 日問,每天一道面試題,有關前端,後端,devops以及軟技能,促進職業成長,敲開大廠之門,歡迎交流
並且記錄我的面試經驗
ali 為 ali,為避內容檢查
以下是總結的問題,我將在本週末補充答案,另外也歡迎各位補充答案
分類
計算機與程式設計基礎
計算機網路 | 演算法與資料結構 | 作業系統 | Linux基礎 | http | vim | git
前端
CSS | Javascript | html | React | Vue | Webpack | 前端工程化
後端
DevOps
DevOps | Docker | kubernetes
開放式問題
歷史記錄
01 生產環境的某個介面報錯,如何定位
在 Issue 中交流與討論: Issue 地址
- 測試環境有沒有問題,有問題可以在測試環境測試
- 有沒有異常報警系統,如
sentry
,如果有在sentry
中檢視堆疊資訊以及相關上下文,定位程式碼 - 如果堆疊資訊不足夠找到問題,看有沒有鏈路追蹤工具,如
zipkin
。從sentry
中找到requestId
,在資料庫日誌/上下游鏈路日誌中查詢對應requestId
的日誌 - 檢視介面相關程式碼
既然報錯,那麼一定會在異常上報系統中找到 Issue
進行定位。最怕的是那種介面沒報錯,但是業務方反饋資料有誤的問題了,只能開了 debug,進行程式碼除錯了
02 後端的敏感資料在生產環境是如何配置的
更多描述: 後端的敏感資料在生產環境是如何配置的,如資料庫的賬號密碼,jwt 的 secret,聯調上游服務的 token 等
在 Issue 中交流與討論: Issue 地址
目前我們的方式是在每次部署之前,在 vault 和 consul 拉取敏感資料,寫在配置檔案中
另外,還有幾種可選的方案
- 跟隨
CI/CD
的環境變數,敏感配置放在 CI 平臺 - 跟隨 k8s
secret
/configMap
,敏感配置放在 k8s 叢集 - 跟隨專有的配置服務,如
consul
/vault
03 如何實現一個分散式鎖
在 Issue 中交流與討論: Issue 地址
04 websocket 服務多節點部署時會有什麼問題,怎麼解決
在 Issue 中交流與討論: Issue 地址
多節點問題
在開始思考分散式會有什麼問題時,先來回答一個問題: 服務端如何與客戶端交流?
在 ws 服務端,當與客戶端連線成功後,會生成一個物件 connection
,ws 會維護一個與客戶端所有連線的 connections
。如果想要主動推送訊息到客戶端,只需要呼叫API connection.sendText(message)
。
那如何給所有人廣播訊息呢?
伺服器只需要與它自身的所有連線 server.connections
挨個發訊息就是廣播,所以它只是一個偽廣播:我要給群裡所有人發訊息,但我不能在群裡發,只能挨個私發。
單節點
當單節點時所有使用者都能正常受到通知,流程如下
這時所有使用者都能收到訊息通知
多節點
當多節點時,就會有部分使用者無法正常受到通知,從以下流程圖中可以很清楚地看到問題所在
負載到節點2的所有使用者都沒有收到訊息通知
如何解決
多節點伺服器就會有分散式問題,解決分散式問題就找一個大家都能找到的地,比如說 Redis
,比如說 Kafka
等訊息件
改進後流程圖如下
- 需要向所有使用者推送訊息,請求 websocket 服務
- 負載均衡到某個節點
- 該節點向 redis/kafka 推送訊息: 向所有使用者推送訊息通知
- 所有節點在 redis/kafka 上訂閱訊息
- 訂閱成功後所有節點向客戶端 push 訊息
redis PUBSUB
其中有一個細節是 pub/sub 那裡,redis 的 pubsub
較 Kafka
等訊息中介軟體更為輕便,最主要的是與ws整合的社群方案比較成熟,這點很重要,如 Node 中的以下兩個
pubsub
在 redis 中的命令如下
- pub:
publish channel message
- sub:
subscribe
如果我們要訂閱 eat
這個 channel
的話,圖示如下
進一步追問
面試官見我回答完問題後,又一次追問
那 websocket 如何向特定的使用者組推送訊息?
假如一個學校有以下資料結構
Class
: 代表班級Student
: 代表學生,每個學生都在其中一個班級
那假如要向 Class:201901
班級的所有學生髮送通知,應該如何實現
歡迎在 Issue 中討論: 【Q029】websocket 如何向特定使用者組推送訊息
小結
借用解決方案的圖作為小結
05 如何對介面進行壓力測試
在 Issue 中交流與討論: Issue 地址
$ ab
複製程式碼
06 websocket 如何向特定的使用者組推送訊息
更多描述: 假如一個學校有以下資料結構
Class
: 代表班級Student
: 代表學生,每個學生都在其中一個班級那假如要向
Class:201901
班級的所有學生髮送通知,應該如何實現
在 Issue 中交流與討論: Issue 地址
在 redis
處維護一個物件,記錄每個 group 所對應的 connections
/sockets
{
'Class:201901': [student1Socket, student2Socket]
}
複製程式碼
當 client 剛連入 server 時,便加入某個特定的組,或者叫 room,比如 student01,剛開始連入 server,可能要加入 room:Student:01
,Class:201901
,Group:10086
07 如何對介面進行限流
在 Issue 中交流與討論: Issue 地址
一般採用漏桶演算法:
- 漏桶初始為空
- API 呼叫是在往漏桶裡注水
- 漏桶會以一定速率出水
- 水滿時 API 拒絕呼叫
可以使用 redis
的計數器實現
- 計數器初始為空
- API 呼叫計數器增加
- 給計數器設定過期時間,隔段時間清零,視為一定速率出水
- 計數器達到上限時,拒絕呼叫
當然,這只是大致思路,這時會有兩個問題要注意
- 最壞情況下的限流是額定限流速率的2倍
- 條件競爭問題
不過實際實現時注意以下就好了(話說一般也是呼叫現成的三方庫做限流...),可以參考我以前的文章 shanyue.tech/post/rate-l…
08 如何設計一個高併發系統
在 Issue 中交流與討論: Issue 地址
09 什麼是服務降級
在 Issue 中交流與討論: Issue 地址
10 什麼是熔斷機制,微服務如何做熔斷
在 Issue 中交流與討論: Issue 地址
11 什麼是負載均衡
在 Issue 中交流與討論: Issue 地址
12 四層負載均衡與七層負載均衡有什麼區別
在 Issue 中交流與討論: Issue 地址
13 你們專案中的計劃任務是如何組織的
在 Issue 中交流與討論: Issue 地址
14 RPC 與 REST 有什麼優劣
在 Issue 中交流與討論: Issue 地址
15 如何實現服務發現 (Service Discovery)
在 Issue 中交流與討論: Issue 地址
那 k8s 的服務發現是如何實現的
16 如何設計一個短網址生成服務
在 Issue 中交流與討論: Issue 地址
17 你們後端程式碼上線部署一次需要多長時間
在 Issue 中交流與討論: Issue 地址
18 什麼是 Basic Auth 和 Digest Auth
在 Issue 中交流與討論: Issue 地址
19 如何保證內網服務的安全性
更多描述: 如 `gitlab CE` 經常暴露出重大漏洞,而它也只需要在公司內部使用。部署 `gitlab` 時我們如何保證它的安全性
在 Issue 中交流與討論: Issue 地址
basic auth,digest auth,ip whitelist,vpn
20 負載均衡有哪幾種方式,它們的原理是什麼
在 Issue 中交流與討論: Issue 地址
我是山月,可以加我微信
shanyue94
與我交流,備註交流。另外可以關注我的公眾號【全棧成長之路】