避免失業(yè)和35歲危機，把這份百度3面的面經(jīng)分享出來

部分面經(jīng)分享
以下內(nèi)容是針對特定簡歷和面試過程做的復(fù)盤總結(jié)，不是標準答案，僅供參考和討論：

1. 自我介紹感覺話術(shù)表述不是很好，需要刻意準備打磨
重點強調(diào)Go語言相關(guān)經(jīng)驗，比如X年工作經(jīng)驗，主要做后端開發(fā)。不要提旁枝末節(jié)和后端開發(fā)無關(guān)的事情
結(jié)合面試公司的情況，重點介紹相關(guān)的工作經(jīng)驗
如果有開源項目和博客最后也提一下，熱愛技術(shù)，熱愛分享比如多少star，多少粉絲等等
2. 項目介紹上表達容易卡頓或者不連貫，給人一種對項目不熟的感覺。項目是先介紹模塊劃分還是先介紹架構(gòu)好？
先介紹模塊，讓對方有個整體認識，再介紹架構(gòu)，這樣更好理解
3. 架構(gòu)是從網(wǎng)關(guān)講到底層服務(wù)層好，還是從底層講到上面好
網(wǎng)關(guān)層講到底層服務(wù)，這樣更清晰，更好理解
4. 每個層級是如何進行冗災(zāi)？
應(yīng)用層容災(zāi)：應(yīng)用層容災(zāi)主要是通過負載均衡和故障轉(zhuǎn)移來實現(xiàn)的?？梢詫?yīng)用部署在多臺服務(wù)器上，通過負載均衡器將請求分發(fā)到不同的服務(wù)器上，以實現(xiàn)負載均衡和故障轉(zhuǎn)移。同時，可以使用容器技術(shù)如 Docker，將應(yīng)用打包成鏡像，以便快速部署和遷移。
服務(wù)層容災(zāi)：服務(wù)層容災(zāi)主要是通過服務(wù)治理和容錯機制來實現(xiàn)的?？梢允褂梅?wù)注冊中心如 ZooKeeper、Consul 等來實現(xiàn)服務(wù)的注冊和發(fā)現(xiàn)，以便快速定位故障服務(wù)并進行故障轉(zhuǎn)移。同時，可以使用熔斷器、限流器等容錯機制來保護服務(wù)的穩(wěn)定性和可靠性。
數(shù)據(jù)層容災(zāi)：數(shù)據(jù)層容災(zāi)主要是通過數(shù)據(jù)備份、數(shù)據(jù)同步和數(shù)據(jù)恢復(fù)來實現(xiàn)的?？梢允褂脭?shù)據(jù)庫主從復(fù)制、分布式數(shù)據(jù)庫等技術(shù)來實現(xiàn)數(shù)據(jù)備份和同步，以保證數(shù)據(jù)的可靠性和一致性。同時，可以使用數(shù)據(jù)恢復(fù)工具如 mysqldump、pg_dump 等來進行數(shù)據(jù)恢復(fù)。
5. 看你項目是選gin作為框架的，為啥沒考慮集成度更高的go-zero, 你對go-zero了解多少？
gin入門簡單、項目時間緊
gozero作為rpc微服務(wù)框架，后來有研究，比如：xxxxx巴拉巴拉
6. 為什么你選擇Kong作為網(wǎng)關(guān)，基于什么考慮的
Kong 作為一個 API 網(wǎng)關(guān)，具有以下幾個優(yōu)勢：
高性能：Kong 使用了 Nginx 作為底層引擎，具有高性能和高并發(fā)的特點，可以處理大量的 API 請求。
可擴展：Kong 提供了一系列的插件和擴展機制，可以幫助開發(fā)者快速擴展和定制 API 網(wǎng)關(guān)的功能和性能。
易于使用：Kong 提供了一系列的管理界面和 API，可以幫助開發(fā)者快速配置和管理 API 網(wǎng)關(guān)。
安全可靠：Kong 提供了一系列的安全機制，如身份驗證、訪問控制、防止 SQL 注入等，可以保障 API 的安全性和可靠性。
社區(qū)活躍：Kong 有一個非?；钴S的社區(qū)，提供了大量的文檔、教程、插件和擴展，可以幫助開發(fā)者快速學(xué)習(xí)和使用 Kong。
7. 你在哪些層面做了限流及負載均衡？為什么這么考慮？
目前就網(wǎng)關(guān)層和srv層做了限流和負載均衡
網(wǎng)關(guān)層通過kong自帶計數(shù)器形式進行限流，比如根據(jù)IP限流，設(shè)置每分鐘能訪問50次
POST http://127.0.0.1:9001/services/audio-service/plugins
{
    "name":"rate-limiting",
    "config.minute":50,
    "config.limit_by":"ip"
}
錄入系統(tǒng)單元通過IP 黑白名單進行限流
8. kong的負載均衡該怎么描述？
Kong 的負載均衡是基于 Nginx 的負載均衡實現(xiàn)的。
Kong 使用 Nginx 作為底層引擎，通過 Nginx 的負載均衡模塊實現(xiàn)負載均衡功能。
具體來說，Kong 會將 API 請求分發(fā)到多個后端服務(wù)節(jié)點上，以實現(xiàn)負載均衡。
Kong 的負載均衡支持多種負載均衡算法，如輪詢、IP 哈希、最少連接數(shù)等。
我們可以根據(jù)自己的需求選擇合適的負載均衡算法。同時，Kong 還提供了一系列的負載均衡配置選項，如權(quán)重、健康檢查、故障轉(zhuǎn)移等，可以幫助開發(fā)者更加靈活地配置和管理負載均衡。
9. 項目中用到了gRPC，談?wù)勀銓RPC的理解，及項目中是如何使用到的？
gRPC 是一個高性能、開源的遠程過程調(diào)用（RPC）框架，它使用 Protocol Buffers 作為接口定義語言（IDL），可以幫助開發(fā)者快速構(gòu)建分布式應(yīng)用程序。gRPC 的特點包括：
高性能：gRPC 使用了基于 HTTP/2 的協(xié)議，可以提高應(yīng)用程序的性能和吞吐量。
跨語言支持：gRPC 支持多種編程語言，如 Go、Java、Python、C# 等，可以幫助開發(fā)者構(gòu)建跨語言的分布式應(yīng)用程序。
自動生成代碼：gRPC 使用 Protocol Buffers 作為接口定義語言（IDL），可以自動生成客戶端和服務(wù)器端的代碼，簡化了開發(fā)者的工作量。
安全可靠：gRPC 提供了一系列的安全機制，如身份驗證、訪問控制、加密傳輸?shù)?，可以保障?yīng)用程序的安全性和可靠性。
在項目中，gRPC 可以用于實現(xiàn)微服務(wù)之間的通信。具體來說，開發(fā)者可以使用 gRPC 定義服務(wù)接口和數(shù)據(jù)類型，然后使用 gRPC 自動生成客戶端和服務(wù)器端的代碼，最后在客戶端和服務(wù)器端之間進行遠程調(diào)用。
gRPC 可以幫助開發(fā)者實現(xiàn)高性能、跨語言、安全可靠的微服務(wù)通信，提高應(yīng)用程序的可擴展性和可維護性。
簡歷優(yōu)化&心理按摩&就業(yè)輔導(dǎo)
10. nacos做服務(wù)發(fā)現(xiàn)的原理？
Nacos 是一個開源的服務(wù)發(fā)現(xiàn)和配置管理平臺，它可以幫助開發(fā)者實現(xiàn)服務(wù)注冊、服務(wù)發(fā)現(xiàn)、配置管理等功能。Nacos 的服務(wù)發(fā)現(xiàn)原理主要包括以下幾個步驟：
服務(wù)注冊：服務(wù)提供者在啟動時向 Nacos 注冊中心注冊自己的服務(wù)信息，包括服務(wù)名稱、服務(wù)地址、服務(wù)端口等。
服務(wù)發(fā)現(xiàn)：服務(wù)消費者在啟動時向 Nacos 注冊中心查詢自己所需的服務(wù)信息，Nacos 注冊中心返回符合條件的服務(wù)提供者列表。
負載均衡：服務(wù)消費者從服務(wù)提供者列表中選擇一個服務(wù)提供者進行調(diào)用，可以使用負載均衡算法來選擇服務(wù)提供者。
心跳檢測：服務(wù)提供者定期向 Nacos 注冊中心發(fā)送心跳信息，以保證服務(wù)提供者的可用性。
服務(wù)下線：服務(wù)提供者在停止服務(wù)時向 Nacos 注冊中心注銷自己的服務(wù)信息，以保證服務(wù)提供者的及時下線。
總結(jié)一下：Nacos 的服務(wù)發(fā)現(xiàn)原理主要是通過服務(wù)注冊、服務(wù)發(fā)現(xiàn)、負載均衡、心跳檢測和服務(wù)下線等步驟來實現(xiàn)的。Nacos 注冊中心作為服務(wù)發(fā)現(xiàn)的核心組件，可以幫助開發(fā)者實現(xiàn)高可用、高性能的服務(wù)發(fā)現(xiàn)功能。
11. nacos如何感知服務(wù)故障了或者離線了
Nacos 通過心跳檢測機制來感知服務(wù)故障或者離線。具體來說，服務(wù)提供者在啟動時向 Nacos 注冊中心注冊自己的服務(wù)信息，并定期向 Nacos 注冊中心發(fā)送心跳信息。如果服務(wù)提供者在一定時間內(nèi)沒有發(fā)送心跳信息，Nacos 注冊中心會認為該服務(wù)提供者已經(jīng)故障或者離線，將其從服務(wù)列表中移除。
Nacos 的心跳檢測機制可以通過以下幾個參數(shù)進行配置：
心跳間隔（默認為 5 秒）：服務(wù)提供者向 Nacos 注冊中心發(fā)送心跳信息的時間間隔。
心跳超時時間（默認為 15 秒）：Nacos 注冊中心在服務(wù)提供者未發(fā)送心跳信息的時間超過該值時，認為服務(wù)提者已經(jīng)故障或者離線。
實例存活時間（默認為 90 秒）：Nacos 注冊中心在服務(wù)提供者未發(fā)送心跳信息的時間超過該值時，將自動注銷該服務(wù)提供者的服務(wù)實例。
通過配置這些參數(shù)，我們就可以根據(jù)自己的需求來調(diào)整心跳檢測機制的敏感度和精度，以保證服務(wù)發(fā)現(xiàn)的及時性和可靠性。
12. Nacos 如何進行故障恢復(fù)？
Nacos 通過以下幾種方式來進行故障恢復(fù)：
自動切換：Nacos 支持多個注冊中心節(jié)點的部署，當(dāng)某個節(jié)點發(fā)生故障時，Nacos 可以自動切換到其他節(jié)點進行服務(wù)發(fā)現(xiàn)和配置管理。
自動恢復(fù)：Nacos 支持多個服務(wù)提供者的部署，當(dāng)某個服務(wù)提供者發(fā)生故障時，Nacos 可以自動切換到其他服務(wù)提供者進行服務(wù)調(diào)用。
自動重試：Nacos 支持自動重試機制，當(dāng)服務(wù)調(diào)用失敗時，Nacos 可以自動重試，直到服務(wù)調(diào)用成功或者達到最大重試次數(shù)。
健康檢查：Nacos 支持健康檢查機制，可以定期檢查服務(wù)提供者的健康狀態(tài)，當(dāng)服務(wù)提供者發(fā)生故障時，Nacos 可以自動將其從服務(wù)列表中移除，直到服務(wù)恢復(fù)正常。
總結(jié)一下：Nacos 通過自動切換、自動恢復(fù)、自動重試和健康檢查等機制來進行故障恢復(fù)，可以幫助我們實現(xiàn)高可用、高性能的服務(wù)發(fā)現(xiàn)和配置管理功能。同時，Nacos 還提供了一系列的監(jiān)控和告警機制，可以幫助開發(fā)者及時發(fā)現(xiàn)和解決故障，提高應(yīng)用程序的可靠性和穩(wěn)定性。
13. 故障恢復(fù)的負載均衡是哪一部分做的？
在故障恢復(fù)的過程中，Nacos 的負載均衡是由服務(wù)消費者的負載均衡模塊來實現(xiàn)的。具體來說，當(dāng)服務(wù)消費者向 Nacos 注冊中心查詢服務(wù)提供者列表時，Nacos 注冊中心會返回符合條件的服務(wù)提供者列表，服務(wù)消費者會根據(jù)負載均衡算法從服務(wù)提供者列表中選擇一個服務(wù)提供者進行調(diào)用。如果選擇的服務(wù)提供者發(fā)生故障或者離線，服務(wù)消費者會重新選擇一個服務(wù)提供者進行調(diào)用，以實現(xiàn)故障恢復(fù)和負載均衡。
Nacos 支持多種負載均衡算法，如輪詢、隨機、最少連接數(shù)等，服務(wù)消費者可以根據(jù)自己的需求選擇合適的負載均衡算法。同時，Nacos 還提供了一系列的負載均衡配置選項，如權(quán)重、健康檢查、故障轉(zhuǎn)移等，可以幫助我們更加靈活地配置和管理負載均衡。
在故障恢復(fù)的過程中，Nacos 的負載均衡是由服務(wù)消費者的負載均衡模塊來實現(xiàn)的，服務(wù)消費者可以根據(jù)自己的需求選擇合適的負載均衡算法和配置選項，以實現(xiàn)故障恢復(fù)和負載均衡。
14. 網(wǎng)關(guān)層的緩存、限流是如何做的， 故障轉(zhuǎn)移是如何做的?
網(wǎng)關(guān)層的緩存和限流是通過網(wǎng)關(guān)層的插件來實現(xiàn)的。具體來說，網(wǎng)關(guān)層可以使用緩存插件和限流插件來實現(xiàn)緩存和限流功能。緩存插件可以將經(jīng)常請求的數(shù)據(jù)緩存到內(nèi)存中，以提高響應(yīng)速度和降低后端服務(wù)的壓力；限流插件可以限制請求的速率和數(shù)量，以保護后端服務(wù)的穩(wěn)定性和可靠性。
在故障轉(zhuǎn)移方面，網(wǎng)關(guān)層可以通過負載均衡插件來實現(xiàn)。具體來說，網(wǎng)關(guān)層可以將請求分發(fā)到多個后端服務(wù)節(jié)點上，以實現(xiàn)負載均衡和故障轉(zhuǎn)移。當(dāng)某個后端服務(wù)節(jié)點發(fā)生故障或者離線時，網(wǎng)關(guān)層可以自動將請求轉(zhuǎn)發(fā)到其他可用的后端服務(wù)節(jié)點上，以保證服務(wù)的可用性和穩(wěn)定性。
總結(jié)一下：網(wǎng)關(guān)層的緩存、限流和故障轉(zhuǎn)移是通過網(wǎng)關(guān)層的插件來實現(xiàn)的。網(wǎng)關(guān)層可以使用緩存插件和限流插件來實現(xiàn)緩存和限流功能，使用負載均衡插件來實現(xiàn)故障轉(zhuǎn)移功能。這些插件可以幫助開發(fā)者實現(xiàn)高性能、高可用、高穩(wěn)定性的網(wǎng)關(guān)層服務(wù)。
15. redis如何實現(xiàn)分布式鎖有哪些？有哪些優(yōu)缺點 ？
Redis 實現(xiàn)分布式鎖的方式主要有以下幾種：

基于 SETNX 命令：使用 SETNX 命令可以將一個鍵值對設(shè)置為鎖，如果該鍵值對不存在，則設(shè)置成功，表示獲取鎖成功；否則設(shè)置失敗，表示獲取鎖失敗。釋放鎖時可以使用 DEL 命令刪除該鍵值對。
基于 Lua 腳本：使用 Lua 腳本可以將獲取鎖和釋放鎖的操作封裝為一個原子操作，避免了多個 Redis 命令之間的競爭條件。
基于 Redlock 算法：Redlock 算法是一種分布式鎖算法，可以在多個 Redis 節(jié)點之間實現(xiàn)分布式鎖。具體來說，Redlock 算法將鎖分為多個副本，每個副本在不同的 Redis 節(jié)點上，獲取鎖時需要在多個副本上都獲取成功才算獲取鎖成功。
Redis 實現(xiàn)分布式鎖的優(yōu)缺點如下：

競爭條件：在高并發(fā)的情況下，多個客戶端同時獲取鎖可能會導(dǎo)致競爭條件，需要使用適當(dāng)?shù)乃惴ê图夹g(shù)來避免競爭條件的發(fā)生。
鎖過期問題：如果鎖的過期時間設(shè)置不合理，可能會導(dǎo)致鎖過期后其他客戶端獲取鎖，導(dǎo)致數(shù)據(jù)不一致或者死鎖等問題。因此，需要根據(jù)實際情況合理設(shè)置鎖的過期時間。
性能損失：在使用 Redlock 算法時，需要在多個 Redis 節(jié)點之間進行通信和協(xié)調(diào)，可能會導(dǎo)致性能損失和延遲增加。
高性能：Redis 是一種高性能的內(nèi)存數(shù)據(jù)庫，可以快速地進行鎖的獲取和釋放操作。
可靠性高：Redis 支持主從復(fù)制和 Sentinel 高可用方案，可以保證分布式鎖的可靠性和穩(wěn)定性。
易于使用：Redis 提供了多種實現(xiàn)分布式鎖的方式，開發(fā)者可以根據(jù)自己的需求選擇合適的方式。
優(yōu)點：
缺點：
總結(jié)一下：Redis 實現(xiàn)分布式鎖是一種高性能、可靠性高、易于使用的方式，但需要注意競爭條件、鎖過期問題和性能損失等問題。開發(fā)者可以根據(jù)自己的需求選擇合適的實現(xiàn)方式，并結(jié)合實際情況進行優(yōu)化和調(diào)整，以保證分布式鎖的可靠性和性能。

16. 目前服務(wù)大概并發(fā)是多少？
介紹并發(fā)應(yīng)該從以下幾個指標來回答：QPS PV UV 并發(fā)連接數(shù) 響應(yīng)時間

QPS（每秒查詢率）：QPS 是指每秒鐘能夠處理的查詢請求的數(shù)量，是衡量系統(tǒng)性能的重要指標之一。
TPS（每秒事務(wù)數(shù)）是指系統(tǒng)每秒鐘能夠處理的事務(wù)數(shù)量，其中事務(wù)可以是數(shù)據(jù)庫事務(wù)、HTTP 請求、RPC 調(diào)用等。
PV（頁面瀏覽量）：PV 是指用戶訪問網(wǎng)站的頁面數(shù)量，是衡量網(wǎng)站流量的重要指標之一。
UV（獨立訪客數(shù)）：UV 是指訪問網(wǎng)站的獨立用戶數(shù)量，是衡量網(wǎng)站用戶數(shù)量的重要指標之一。
并發(fā)連接數(shù)：并發(fā)連接數(shù)是指同時連接到服務(wù)器的用戶數(shù)量，是衡量系統(tǒng)并發(fā)能力的重要指標之一。
響應(yīng)時間：響應(yīng)時間是指系統(tǒng)處理請求的時間，是衡量系統(tǒng)性能和用戶體驗的重要指標之一。
舉個栗子，對于一個用戶量為100萬+的電商網(wǎng)站，以下是一些可能的指標取值范圍：

QPS：根據(jù)業(yè)務(wù)場景和系統(tǒng)設(shè)計，QPS 可能在幾百到幾千之間，甚至更高。
數(shù)據(jù)庫事務(wù)：根據(jù)業(yè)務(wù)場景和數(shù)據(jù)庫設(shè)計，TPS 可能在幾百到幾千之間，甚至更高。
HTTP 請求：假設(shè)每個用戶平均每天訪問網(wǎng)站10次，那么每天的 HTTP 請求可能在1000萬+，每秒鐘的 TPS 可能在幾百到幾千之間。
RPC 調(diào)用：假設(shè)每個用戶平均每天進行10次 RPC 調(diào)用，那么每天的 RPC 調(diào)用可能在1000萬+，每秒鐘的 TPS 可能在幾百到幾千之間。
PV：假設(shè)每個用戶平均訪問網(wǎng)站10個頁面，那么每天的 PV 可能在1000萬+。
UV：假設(shè)每個用戶平均每天訪問網(wǎng)站1次，那么每天的 UV 可能在100萬到數(shù)百萬之間。
并發(fā)連接數(shù)：根據(jù)業(yè)務(wù)場景和系統(tǒng)設(shè)計，可能需要支持數(shù)千到數(shù)萬的并發(fā)連接數(shù)。
響應(yīng)時間：根據(jù)業(yè)務(wù)場景和用戶體驗要求，響應(yīng)時間應(yīng)該控制在幾百毫秒以內(nèi)。
17. 應(yīng)用層與服務(wù)層的部署分布部署了多少節(jié)點？
仍然以用戶量100萬+作為預(yù)估：
應(yīng)用層：將應(yīng)用層部署在多臺服務(wù)器上，每臺服務(wù)器部署多個應(yīng)用實例，來實現(xiàn)負載均衡和故障轉(zhuǎn)移?？赡苄枰?0臺~100臺服務(wù)器，每臺服務(wù)器部署10個左右的應(yīng)用實例
服務(wù)層：和應(yīng)用層是一樣的，可能需要10臺~100臺服務(wù)器，每臺服務(wù)器部署10個左右的應(yīng)用實例。
18. 項目中目前是基于什么實現(xiàn)的高并發(fā)，以及在處理的時候需要注意哪些問題？遇到哪些印象比較深刻的問題？
高并發(fā)
分布式架構(gòu)
緩存技術(shù)
異步消息
需要注意的問題
慢查詢
索引
索引命中
索引類型
jaeger
數(shù)據(jù)一致性
追蹤定位分析問題的方式
數(shù)據(jù)庫優(yōu)化
負載均衡和故障轉(zhuǎn)移
容災(zāi)問題
印象深刻的問題：
備份
數(shù)據(jù)傳輸
mongo鏈接數(shù)過多
數(shù)據(jù)庫連接池過多
緩存穿透、擊穿的問題
安全性問題
三方服務(wù)對接的坑，對接上游和下游分別遇到的問題
Go語言開發(fā)和之前Python開發(fā)的對比
分布式開發(fā)和單體開發(fā)的對比




請前往：http://lygongshang.com/TeacherV2.html?id=365