Hello，大家好，我是陽哥。失蹤人口回歸，最近太忙，好久沒有更文啦。

本文先分享2段面經(jīng)，文末總結(jié)了關(guān)鍵問題的復(fù)盤筆記。一定要看到最后！

求職者情況

分享一下好友的最新面經(jīng)。

簡單說下這位好友的情況：坐標(biāo)成都，游戲行業(yè)，3年開發(fā)經(jīng)驗(yàn)，最近2年做Go語言開發(fā)，1年Java/PHP工作經(jīng)驗(yàn)。

手撕CSAPP選手，半年前堅(jiān)持打卡手寫的學(xué)習(xí)筆記。（最近半年被公司摧殘，沒時(shí)間了....）

面經(jīng)分享

第一家

Golang后端，3年+經(jīng)驗(yàn)，游戲行業(yè)，成都，15~25K

下面以對話的方式大概描述問題：

A--->面試官

B--->我

A：自我介紹

B：巴拉巴拉

A：Actor 模型你是怎么理解的？

B：無鎖的并發(fā)計(jì)算模型，Actor 有自己的狀態(tài)，只能通過 mailBox 去收發(fā)消息、異步消息傳遞~

A：你不是百度了吧？

B：沒有。因?yàn)槲矣X得它的一部分思想和 Go 的 GMP 挺像的，好記（這里我就給自己挖坑了，擦嘞~）

A：你能說說它們哪里像嗎？

B：Go 的調(diào)度器全局隊(duì)列和它的 MailBox 挺像的

A：那你的意思是，實(shí)現(xiàn) MailBox，你會(huì)使用隊(duì)列嗎？

B：是的，用 chan 關(guān)鍵字，元素類型為 Interface

A：這樣是可以，那么我給你一個(gè)場景，在同一時(shí)刻，有 1 萬個(gè)消息打進(jìn)來呢？

B：增加緩沖區(qū)大小、無鎖隊(duì)列、批量處理消息、背壓機(jī)制

A：能從數(shù)據(jù)結(jié)構(gòu)的角度說說嗎？

B：chan 底層是數(shù)組，線性結(jié)構(gòu)，我想用非線性結(jié)構(gòu)紅黑樹接收消息

A：為什么？

B：因?yàn)?epoll 模型就是這么做的

A：優(yōu)勢是什么

B：忘了...

A：你再想想，比如動(dòng)態(tài)調(diào)整緩沖區(qū)，可是是一瞬間打進(jìn)來的，你怎么知道調(diào)整的多大，預(yù)留也不好做，巴拉巴拉

B：額，不知道

A：用環(huán)形隊(duì)列

B：啊？我沒想到，因?yàn)槲业挠∠罄?，它的特定是固定大小，消息太多了，不是?huì)覆蓋嗎，會(huì)導(dǎo)致消息丟失。（我提出這個(gè)疑問的時(shí)候，他沒有繼續(xù)給我聊了，如果只用環(huán)形隊(duì)列肯定有這個(gè)問題）我確實(shí)沒有想到，很少用到它...

A：你能聊聊分布式嗎？

B：巴拉巴拉，有擴(kuò)展性、容錯(cuò)、很多節(jié)點(diǎn)，不同地域、數(shù)據(jù)共享，巴拉巴拉

A：你提到了數(shù)據(jù)共享，那你說說一致性你怎么做？

B：我會(huì)先想到用 etcd 吧，因?yàn)樗?raft 可以保證一致性

A：繼續(xù)...

B：etcd Leader選舉、數(shù)據(jù)復(fù)制、心跳、然后讀取，保證一致性，巴拉巴拉它們的細(xì)節(jié)

A：etcd 是鍵值數(shù)據(jù)庫呀，主要場景是配置之類的吧，那我現(xiàn)在有一個(gè)場景，就是 10w qps 如何承載 50w qps 的場景，同時(shí)保證它們的數(shù)據(jù)一致性

B：啥？（我有點(diǎn)沒聽懂這個(gè)問題，硬來）首先是能夠承載這個(gè)量級吧，考慮主從復(fù)制，然后用分片技術(shù)水平擴(kuò)展、異步處理、加緩存巴拉巴拉

A：主從同步你能說說典型的應(yīng)用嗎？

B：（我已經(jīng)被前面那個(gè)問題問蒙蔽了，想說 Redis 的，有點(diǎn)開不了口）額...

A：Redis 就是主從吧！

B：是....是的

然后就下來就是 Redis 拷打小皮鞭了，不多說了，謝謝大家。

第二家

Golang后端，坐標(biāo)成都，游戲行業(yè)，15~20k

先說感受，總體不是很難。下面聽我慢慢聊：

A -> 面試官

B -> 我

A：自我介紹

B：巴拉巴拉

A：我看你簡歷上提到力扣做了挺多題的。

B：是的，但是已經(jīng)有段時(shí)間沒做了，做過的題我都有基本思路。

A：你能說說你知道哪些排序嗎？

B：冒泡、選擇、插入、快速、歸并、堆、桶

A：快排你能說一下它的思路嗎？

B：通過選擇一個(gè)基準(zhǔn)元素，將數(shù)組分割成左右兩個(gè)子數(shù)組，再對子數(shù)組進(jìn)行遞歸排序，直到整個(gè)數(shù)組有序。

A：穩(wěn)定排序和不穩(wěn)定排序的概念能換說一下嗎？

B：假如排序前后兩個(gè)元素的相對順序在排序后仍然不變，那么這種算法就是穩(wěn)定排序。不穩(wěn)定排序反之。（這里答的其實(shí)不太好，可以結(jié)合前面提到的排序算法說一下，哪些具體的算法是穩(wěn)定的）

A：你對二叉樹了解嗎？

B：了解的，樹形結(jié)構(gòu)，有根節(jié)點(diǎn)、父節(jié)點(diǎn)、子節(jié)點(diǎn)、葉子節(jié)點(diǎn)、度、高度、深度這些概念。

A：常見的二叉樹有哪些？

B：平衡二叉樹、二叉搜索樹，巴拉巴拉。

A：能說一下前序遍歷和后序遍歷嗎？

B：前序遍歷，遍歷順序是根節(jié)點(diǎn)、左子樹、右子樹。后序遍歷是左子樹、右子樹、根節(jié)點(diǎn)。

A：前序遍歷和后續(xù)遍歷能夠構(gòu)建一顆二叉樹嗎？

B：額，這個(gè)問題我不太理解。。。

A：沒事，換一個(gè)問題。Go 語言中的 Map 是如何實(shí)現(xiàn)的，你能聊一聊嗎？

B：Map 是使用哈希表、鏈表來實(shí)現(xiàn)的。然后我從散列函數(shù)、解決哈希沖突、動(dòng)態(tài)擴(kuò)容、并發(fā)安全性聊

A：Go 的并發(fā)模式你了解嗎？

B：請問是指的扇入扇出模式、for select 循環(huán)模式這種嗎？（后來回憶一下，面試官想讓我聊的應(yīng)該是CSP并發(fā)模型）

A：不是，你可以說一說你了解的 Go 的并發(fā)原語

B：好的，我從兩個(gè)部分簡單說一下，一個(gè)就是關(guān)鍵字，另一個(gè)是包。像關(guān)鍵字有 go，創(chuàng)建協(xié)程。channel，進(jìn)行通信。select，處理 channel 的收發(fā)。mutex，鎖。context，上下文。包的話 atomic。

A：你知道 csp 嗎，能簡單說一下嘛？

B：（我腦子里第一時(shí)間和 cap 搞混了，但還是拉回來了）csp 是一種通信協(xié)作模型。在 Go 里面有一句很經(jīng)典的話，不要用共享內(nèi)存來通信，要用通信來共享內(nèi)存。

A：（露出了滿意的笑容，扭頭看向旁邊的同事）我沒什么問的了，你有什么問的嗎？

B：你之前用過 mongodb，存儲在 mongodb 中的索引你是怎么設(shè)計(jì)的？

A：不好意思，我之前沒有關(guān)注過這個(gè)部分，因?yàn)橹暗恼w架構(gòu)都是將需要落盤的數(shù)據(jù)放在內(nèi)存，然后標(biāo)記臟位，通過一些策略來異步落盤，而需要查詢數(shù)據(jù)時(shí)，也是直接從內(nèi)存查詢，因?yàn)轫?xiàng)目啟動(dòng)時(shí)，會(huì)把所有的玩家數(shù)據(jù)加載到內(nèi)存中。

B：沒事，那我們聊一下 redis 吧，你知道 redis 的落盤方案嗎？

A：知道，AOF、RDB（然后開始介紹它們的特點(diǎn)）巴拉巴拉

B：你會(huì)如何評估 redis 的落盤方案？

A：我會(huì)從數(shù)據(jù)安全性、可恢復(fù)性、性能、硬盤空間成本、使用場景來評估。

B：硬盤空間成本？你能具體說說嗎？

A：AOF占用空間大等....巴拉巴拉。

B：redis 的 Key 過長會(huì)影響性能嗎？

A：額，我覺得應(yīng)該會(huì)影響性能，因?yàn)槟銌柫诉@個(gè)問題，但是這個(gè)我沒太關(guān)注過，對于 Key 我更在意的是可讀性。

最后聊了一些 Redis 的數(shù)據(jù)結(jié)構(gòu)，又繼續(xù)聊了一下一些特定二叉樹的概念，還問了我對于矩陣、向量的理解，我就圍繞以前做過的天賦系統(tǒng)聊了一下矩陣。

復(fù)盤！復(fù)盤！

為了對大家更有幫助，我把面試中回答的關(guān)鍵問題，做了復(fù)盤和調(diào)研，總結(jié)如下：

Actor模型

Actor模型是一種并發(fā)計(jì)算模型，用于描述并發(fā)系統(tǒng)中的實(shí)體和它們之間的通信。在Actor模型中，系統(tǒng)中的每個(gè)實(shí)體被稱為一個(gè)Actor，每個(gè)Actor都有自己的狀態(tài)和行為，并且可以通過消息傳遞與其他Actor進(jìn)行通信。

在Actor模型中，每個(gè)Actor都是獨(dú)立的，它們之間沒有共享的內(nèi)存。Actor之間通過異步消息傳遞進(jìn)行通信，一個(gè)Actor可以向其他Actor發(fā)送消息，也可以接收其他Actor發(fā)送的消息。當(dāng)一個(gè)Actor接收到消息時(shí)，它可以根據(jù)消息內(nèi)容和自身的狀態(tài)來決定如何處理消息，并可能改變自身的狀態(tài)或向其他Actor發(fā)送消息。

Actor模型的特點(diǎn)包括：

1. 并發(fā)性： 每個(gè)Actor都可以獨(dú)立地執(zhí)行，不受其他Actor的影響，從而實(shí)現(xiàn)并發(fā)執(zhí)行。

2. 無共享狀態(tài)： 每個(gè)Actor都有自己的狀態(tài)，不與其他Actor共享內(nèi)存，避免了共享狀態(tài)帶來的并發(fā)問題。

3. 異步消息傳遞： Actor之間通過異步消息傳遞進(jìn)行通信，消息的發(fā)送和接收是非阻塞的，提高了系統(tǒng)的響應(yīng)性能。

4. 面向?qū)ο螅?nbsp;每個(gè)Actor都可以看作是一個(gè)對象，具有自己的狀態(tài)和行為，可以封裝數(shù)據(jù)和方法。

總結(jié)一下：通過使用Actor模型，可以簡化并發(fā)系統(tǒng)的設(shè)計(jì)和實(shí)現(xiàn)，提高系統(tǒng)的可擴(kuò)展性和可維護(hù)性。同時(shí)，Actor模型也能夠有效地處理并發(fā)問題，避免了傳統(tǒng)并發(fā)編程中常見的共享狀態(tài)和鎖競爭的問題。

對比Go的GMP模型和Actor模型

Go的GMP（Goroutine, M, P）模型和Actor模型都是用于并發(fā)編程的模型，但在一些方面有所不同。

Go的GMP模型是Go語言并發(fā)編程的基礎(chǔ)，它通過goroutine（輕量級線程）和調(diào)度器（scheduler）來實(shí)現(xiàn)并發(fā)。GMP模型中的goroutine是Go語言中的并發(fā)執(zhí)行單元，它可以獨(dú)立地執(zhí)行函數(shù)或方法。調(diào)度器負(fù)責(zé)將goroutine分配給線程（P），以便并行執(zhí)行。線程（P）是操作系統(tǒng)線程的抽象，它負(fù)責(zé)執(zhí)行g(shù)oroutine。M（Machine）是Go語言運(yùn)行時(shí)系統(tǒng)的一部分，它管理線程的創(chuàng)建和銷毀，并提供與操作系統(tǒng)的交互。GMP模型的優(yōu)點(diǎn)是輕量級的goroutine和高效的調(diào)度器，使得并發(fā)編程變得簡單且高效。

Actor模型是一種并發(fā)編程模型，它通過將并發(fā)執(zhí)行的單元（稱為actor）之間的通信和狀態(tài)封裝在一起來實(shí)現(xiàn)并發(fā)。在Actor模型中，每個(gè)actor都是獨(dú)立的實(shí)體，它們通過消息傳遞進(jìn)行通信。每個(gè)actor都有自己的狀態(tài)和行為，并且只能通過接收和發(fā)送消息來與其他actor進(jìn)行通信。Actor模型的優(yōu)點(diǎn)是提供了一種結(jié)構(gòu)化的方式來處理并發(fā)，避免了共享狀態(tài)和鎖的問題。

雖然GMP模型和Actor模型都是用于并發(fā)編程，但它們在實(shí)現(xiàn)方式和語義上有所不同。GMP模型更加底層，直接操作線程和goroutine，適用于需要更細(xì)粒度控制的場景。而Actor模型更加高級，通過消息傳遞來實(shí)現(xiàn)并發(fā)，適用于需要更結(jié)構(gòu)化和可擴(kuò)展的場景。

總結(jié)起來，GMP模型適用于Go語言中的并發(fā)編程，提供了輕量級的goroutine和高效的調(diào)度器；而Actor模型適用于一般的并發(fā)編程，通過消息傳遞來實(shí)現(xiàn)并發(fā)。

epoll模型

epoll是一種在Linux系統(tǒng)中用于高效處理大量并發(fā)連接的I/O事件通知機(jī)制。它具有以下特點(diǎn)：

1. 支持高并發(fā)：epoll使用事件驅(qū)動(dòng)的方式，能夠同時(shí)處理大量的并發(fā)連接，適用于高并發(fā)的網(wǎng)絡(luò)應(yīng)用場景。
2. 高效的事件通知機(jī)制：epoll采用了基于事件驅(qū)動(dòng)的方式，當(dāng)有事件發(fā)生時(shí)，內(nèi)核會(huì)將事件通知給應(yīng)用程序，而不需要應(yīng)用程序輪詢檢查事件是否發(fā)生，從而減少了系統(tǒng)資源的消耗。
3. 支持邊緣觸發(fā)和水平觸發(fā)：epoll提供了兩種工作模式，邊緣觸發(fā)（EPOLLET）和水平觸發(fā)（EPOLLIN/EPOLLOUT）。邊緣觸發(fā)模式只在狀態(tài)發(fā)生變化時(shí)通知應(yīng)用程序，而水平觸發(fā)模式則在狀態(tài)可讀或可寫時(shí)都會(huì)通知應(yīng)用程序。
4. 支持多種I/O事件類型：epoll可以同時(shí)監(jiān)控多種I/O事件類型，包括讀事件、寫事件、錯(cuò)誤事件等。
5. 高效的內(nèi)核數(shù)據(jù)結(jié)構(gòu)：epoll使用紅黑樹和雙向鏈表等高效的數(shù)據(jù)結(jié)構(gòu)來管理大量的文件描述符，提高了事件的處理效率。

總之，epoll模型具有高并發(fā)、高效的事件通知機(jī)制和多種I/O事件類型的支持，適用于處理大量并發(fā)連接的網(wǎng)絡(luò)應(yīng)用場景。

etcd保證數(shù)據(jù)一致性

etcd通過使用Raft一致性算法來保證數(shù)據(jù)的一致性。 Raft是一種分布式一致性算法，它將集群中的節(jié)點(diǎn)分為Leader、Follower和Candidate三種角色，通過選舉機(jī)制選出Leader節(jié)點(diǎn)來處理客戶端的請求。

當(dāng)客戶端向etcd發(fā)送寫請求時(shí)，Leader節(jié)點(diǎn)會(huì)將該請求復(fù)制到其他節(jié)點(diǎn)的日志中，并等待大多數(shù)節(jié)點(diǎn)確認(rèn)接收到該日志條目。一旦大多數(shù)節(jié)點(diǎn)確認(rèn)接收到該日志條目，Leader節(jié)點(diǎn)會(huì)將該請求應(yīng)用到自己的狀態(tài)機(jī)中，并將結(jié)果返回給客戶端。同時(shí)，Leader節(jié)點(diǎn)會(huì)通知其他節(jié)點(diǎn)將該請求應(yīng)用到自己的狀態(tài)機(jī)中。

如果Leader節(jié)點(diǎn)失去連接或崩潰，剩余的節(jié)點(diǎn)會(huì)通過選舉機(jī)制選出新的Leader節(jié)點(diǎn)。新的Leader節(jié)點(diǎn)會(huì)根據(jù)自己的日志和其他節(jié)點(diǎn)的日志進(jìn)行比較，保證自己的日志是最新的，并將缺失的日志條目復(fù)制給其他節(jié)點(diǎn)，以保持?jǐn)?shù)據(jù)的一致性。

通過Raft算法，etcd能夠保證數(shù)據(jù)在集群中的一致性，并且在Leader節(jié)點(diǎn)失效時(shí)能夠快速選舉出新的Leader節(jié)點(diǎn)，保證系統(tǒng)的可用性和數(shù)據(jù)的一致性。

redis的落盤方案

Redis的落盤方案主要有兩種：RDB（Redis Database）和AOF（Append Only File）。

1. RDB（Redis Database）：RDB是Redis默認(rèn)的持久化方式。它通過將Redis的內(nèi)存數(shù)據(jù)快照保存到磁盤上的二進(jìn)制文件中來實(shí)現(xiàn)持久化。RDB的優(yōu)點(diǎn)是快速和緊湊，適合用于備份和恢復(fù)數(shù)據(jù)。RDB的缺點(diǎn)是在發(fā)生故障時(shí)可能會(huì)丟失一部分?jǐn)?shù)據(jù)，因?yàn)镽DB是定期進(jìn)行持久化的，而不是實(shí)時(shí)的。
2. AOF（Append Only File）：AOF是另一種持久化方式，它通過將Redis的寫操作追加到文件末尾來記錄數(shù)據(jù)的變化。AOF的優(yōu)點(diǎn)是可以提供更好的數(shù)據(jù)安全性，因?yàn)樗涗浟嗣總€(gè)寫操作，可以在發(fā)生故障時(shí)進(jìn)行恢復(fù)。AOF的缺點(diǎn)是相對于RDB來說，文件體積較大，恢復(fù)數(shù)據(jù)的速度較慢。

在實(shí)際應(yīng)用中，可以根據(jù)需求選擇適合的落盤方案。如果對數(shù)據(jù)的安全性要求較高，可以選擇AOF方式；如果對數(shù)據(jù)的實(shí)時(shí)性要求較高，可以選擇RDB方式。另外，也可以同時(shí)使用RDB和AOF兩種方式，以提供更好的數(shù)據(jù)保護(hù)和恢復(fù)能力。

本文轉(zhuǎn)載自微信公眾號「 程序員升級打怪之旅」，作者「王中陽Go」，可以通過以下二維碼關(guān)注。

轉(zhuǎn)載本文請聯(lián)系「 程序員升級打怪之旅」公眾號。