大家好，我是小林。

分享一篇騰訊春招二面面經(jīng)，崗位是C++后端，考察的內(nèi)容是C++、Redis、網(wǎng)絡(luò)。

c++

shared_ptr的原理

答：內(nèi)部的共享數(shù)據(jù)和引用計(jì)數(shù)實(shí)現(xiàn)

補(bǔ)充：

shared_ptr多個(gè)指針指向相同的對象。shared_ptr使用引用計(jì)數(shù)，每一個(gè)shared_ptr的拷貝都指向相同的內(nèi)存。每使用他一次，內(nèi)部的引用計(jì)數(shù)加1，每析構(gòu)一次，內(nèi)部的引用計(jì)數(shù)減1，減為0時(shí)，自動刪除所指向的堆內(nèi)存。shared_ptr內(nèi)部的引用計(jì)數(shù)是線程安全的，但是對象的讀取需要加鎖。

shared_ptr的一個(gè)最大的陷阱是循環(huán)引用，循環(huán)引用會導(dǎo)致堆內(nèi)存無法正確釋放，導(dǎo)致內(nèi)存泄漏，可以通過 weak_ptr 來解決這個(gè)問題。

多線程怎么保證引用計(jì)數(shù)的安全的

答：引用計(jì)數(shù)這個(gè)變量是std::atomic，操作時(shí)自帶鎖

常見的鎖有哪些

答：讀寫鎖、互斥鎖這些，再就是一些鎖思想，比如樂觀鎖、悲觀鎖、自旋鎖

valotile關(guān)鍵字的用處

答：避免編譯器額外優(yōu)化

Redis

微博上的熱度排行榜用什么數(shù)據(jù)結(jié)構(gòu)

答：Zset，講了講zrangebyscore

補(bǔ)充：

Zset 類型（Sorted Set，有序集合） 可以根據(jù)元素的權(quán)重來排序，我們可以自己來決定每個(gè)元素的權(quán)重值。比如說，我們可以根據(jù)元素插入 Sorted Set 的時(shí)間確定權(quán)重值，先插入的元素權(quán)重小，后插入的元素權(quán)重大。

在面對需要展示最新列表、排行榜等場景時(shí)，如果數(shù)據(jù)更新頻繁或者需要分頁顯示，可以優(yōu)先考慮使用 Sorted Set。

有序集合比較典型的使用場景就是排行榜。例如學(xué)生成績的排名榜、游戲積分排行榜、視頻播放排名、電商系統(tǒng)中商品的銷量排名等。

我們以博文點(diǎn)贊排名為例，小林發(fā)表了五篇博文，分別獲得贊為 200、40、100、50、150。

# arcticle:1 文章獲得了200個(gè)贊
> ZADD user:xiaolin:ranking 200 arcticle:1
(integer) 1
# arcticle:2 文章獲得了40個(gè)贊
> ZADD user:xiaolin:ranking 40 arcticle:2
(integer) 1
# arcticle:3 文章獲得了100個(gè)贊
> ZADD user:xiaolin:ranking 100 arcticle:3
(integer) 1
# arcticle:4 文章獲得了50個(gè)贊
> ZADD user:xiaolin:ranking 50 arcticle:4
(integer) 1
# arcticle:5 文章獲得了150個(gè)贊
> ZADD user:xiaolin:ranking 150 arcticle:5
(integer) 1

文章 arcticle:4 新增一個(gè)贊，可以使用 ZINCRBY 命令（為有序集合key中元素member的分值加上increment）：

> ZINCRBY user:xiaolin:ranking 1 arcticle:4
"51"

查看某篇文章的贊數(shù)，可以使用 ZSCORE 命令（返回有序集合key中元素個(gè)數(shù)）：

> ZSCORE user:xiaolin:ranking arcticle:4
"50"

獲取小林文章贊數(shù)最多的 3 篇文章，可以使用 ZREVRANGE 命令（倒序獲取有序集合 key 從start下標(biāo)到stop下標(biāo)的元素）：

# WITHSCORES 表示把 score 也顯示出來
> ZREVRANGE user:xiaolin:ranking 0 2 WITHSCORES
1) "arcticle:1"
2) "200"
3) "arcticle:5"
4) "150"
5) "arcticle:3"
6) "100"

獲取小林 100 贊到 200 贊的文章，可以使用 ZRANGEBYSCORE 命令（返回有序集合中指定分?jǐn)?shù)區(qū)間內(nèi)的成員，分?jǐn)?shù)由低到高排序）：

> ZRANGEBYSCORE user:xiaolin:ranking 100 200 WITHSCORES
1) "arcticle:3"
2) "100"
3) "arcticle:5"
4) "150"
5) "arcticle:1"
6) "200"

rehash的過程講一下

答：新舊表雙寫，逐漸遷移

補(bǔ)充：

為了避免 rehash 在數(shù)據(jù)遷移過程中，因拷貝數(shù)據(jù)的耗時(shí)，影響 Redis 性能的情況，所以 Redis 采用了漸進(jìn)式 rehash，也就是將數(shù)據(jù)的遷移的工作不再是一次性遷移完成，而是分多次遷移。

漸進(jìn)式 rehash 步驟如下：

• 給「哈希表 2」 分配空間，一般會比「哈希表 1」 大 2 倍；
• 在 rehash 進(jìn)行期間，每次哈希表元素進(jìn)行新增、刪除、查找或者更新操作時(shí)，Redis 除了會執(zhí)行對應(yīng)的操作之外，還會順序?qū)ⅰ腹１?1 」中索引位置上的所有 key-value 遷移到「哈希表 2」 上；
• 隨著處理客戶端發(fā)起的哈希表操作請求數(shù)量越多，最終在某個(gè)時(shí)間點(diǎn)會把「哈希表 1 」的所有 key-value 遷移到「哈希表 2」，從而完成 rehash 操作。

這樣就巧妙地把一次性大量數(shù)據(jù)遷移工作的開銷，分?jǐn)偟搅硕啻翁幚碚埱蟮倪^程中，避免了一次性 rehash 的耗時(shí)操作。

在進(jìn)行漸進(jìn)式 rehash 的過程中，會有兩個(gè)哈希表，所以在漸進(jìn)式 rehash 進(jìn)行期間，哈希表元素的刪除、查找、更新等操作都會在這兩個(gè)哈希表進(jìn)行。

比如，查找一個(gè) key 的值的話，先會在「哈希表 1」 里面進(jìn)行查找，如果沒找到，就會繼續(xù)到哈希表 2 里面進(jìn)行找到。

另外，在漸進(jìn)式 rehash 進(jìn)行期間，新增一個(gè) key-value 時(shí)，會被保存到「哈希表 2 」里面，而「哈希表 1」 則不再進(jìn)行任何添加操作，這樣保證了「哈希表 1 」的 key-value 數(shù)量只會減少，隨著 rehash 操作的完成，最終「哈希表 1 」就會變成空表。

遷移過程中老表是什么時(shí)候釋放，怎么知道老表可以釋放了

答：通過數(shù)據(jù)長度

補(bǔ)充：

每個(gè) hash table 都有存著一個(gè) used 字段，每次單步 rehash 完成的時(shí)候，最后都會檢查老表即  ht[0].used 是否變成了 0，變成 0 后，就說明老的哈希表里已經(jīng)沒有數(shù)據(jù)了，此時(shí)就會去 free 掉老表，交換老表新表的指針，rehashidx 置為 -1，然后就完成了整個(gè) rehash。

網(wǎng)絡(luò)

不同地區(qū)的用戶的請求怎么打到附近的地區(qū)呢？

答：講了CDN

補(bǔ)充：

CDN 將內(nèi)容資源分發(fā)到位于多個(gè)地理位置機(jī)房中的服務(wù)器上，這樣我們在訪問內(nèi)容資源的時(shí)候，不用訪問源服務(wù)器。而是直接訪問離我們最近的 CDN 節(jié)點(diǎn) ，這樣一來就省去了長途跋涉的時(shí)間成本，從而實(shí)現(xiàn)了網(wǎng)絡(luò)加速。

找到離用戶最近的 CDN 節(jié)點(diǎn)是由 CDN 的全局負(fù)載均衡器（*Global Sever Load Balance，GSLB*）負(fù)責(zé)的。

那 GSLB 是在什么時(shí)候起作用的呢？在回答這個(gè)問題前，我們先來看看在沒有 CDN 的情況下，訪問域名時(shí)發(fā)生的事情。

在沒有 CDN 的情況下，當(dāng)我們訪問域名時(shí)，DNS 服務(wù)器最終會返回源服務(wù)器的地址。

比如，當(dāng)我們在瀏覽器輸入 www.xiaolin.com 域名后，在本地 host 文件找不到域名時(shí)，客戶端就會訪問本地 DNS 服務(wù)器。

這時(shí)候:

• 如果本地 DNS 服務(wù)器有緩存該網(wǎng)站的地址，則直接返回網(wǎng)站的地址；
• 如果沒有就通過遞歸查詢的方式，先請求根 DNS，根 DNS 返回頂級 DNS（.com）的地址；再請求 .com 頂級 DNS 得到 xiaolin.com 的域名服務(wù)器地址，再從 xiaolin.com 的域名服務(wù)器中查詢到 www.xiaolin.com 對應(yīng)的 IP 地址，然后返回這個(gè) IP 地址，同時(shí)本地 DNS 緩存該 IP 地址，這樣下一次的解析同一個(gè)域名就不需要做 DNS 的迭代查詢了。

但加入 CDN 后就不一樣了。

會在 xiaolin.com 這個(gè) DNS 服務(wù)器上，設(shè)置一個(gè) CNAME 別名，指向另外一個(gè)域名 www.xiaolin.cdn.com，返回給本地 DNS 服務(wù)器。

接著繼續(xù)解析該域名，這個(gè)時(shí)候訪問的就是 xiaolin.cdn.com 這臺 CDN 專用的 DNS 服務(wù)器，在這個(gè)服務(wù)器上，又會設(shè)置一個(gè) CNAME，指向另外一個(gè)域名，這次指向的就是 CDN 的 GSLB。

接著，本地 DNS 服務(wù)器去請求 CDN 的 GSLB 的域名，GSLB 就會為用戶選擇一臺合適的 CDN 節(jié)點(diǎn)提供服務(wù)，選擇的依據(jù)主要有以下幾點(diǎn)：

• 看用戶的 IP 地址，查表得知地理位置，找相對最近的 CDN 節(jié)點(diǎn)；
• 看用戶所在的運(yùn)營商網(wǎng)絡(luò)，找相同網(wǎng)絡(luò)的 CDN 節(jié)點(diǎn)；
• 看用戶請求 URL，判斷哪一臺服務(wù)器上有用戶所請求的資源；
• 查詢 CDN 節(jié)點(diǎn)的負(fù)載情況，找負(fù)載較輕的節(jié)點(diǎn)；

GSLB 會基于以上的條件進(jìn)行綜合分析后，找出一臺最合適的 CDN 節(jié)點(diǎn)，并返回該 CDN 節(jié)點(diǎn)的 IP 地址給本地 DNS 服務(wù)器，然后本地 DNS 服務(wù)器緩存該 IP 地址，并將 IP 返回給客戶端，客戶端去訪問這個(gè) CDN 節(jié)點(diǎn)，下載資源。

TCP的close_wait在哪端，如果我們場景中出現(xiàn)了大量的close_wait，你覺得要怎么排查

答：被動方，代碼邏輯有問題，沒close

補(bǔ)充：

CLOSE_WAIT 狀態(tài)是「被動關(guān)閉方」才會有的狀態(tài)，而且如果「被動關(guān)閉方」沒有調(diào)用 close 函數(shù)關(guān)閉連接，那么就無法發(fā)出 FIN 報(bào)文，從而無法使得 CLOSE_WAIT 狀態(tài)的連接轉(zhuǎn)變?yōu)?LAST_ACK 狀態(tài)。

所以，當(dāng)服務(wù)端出現(xiàn)大量 CLOSE_WAIT 狀態(tài)的連接的時(shí)候，說明服務(wù)端的程序沒有調(diào)用 close 函數(shù)關(guān)閉連接。

那什么情況會導(dǎo)致服務(wù)端的程序沒有調(diào)用 close 函數(shù)關(guān)閉連接？這時(shí)候通常需要排查代碼。

我們先來分析一個(gè)普通的 TCP 服務(wù)端的流程：

1. 創(chuàng)建服務(wù)端 socket，bind 綁定端口、listen 監(jiān)聽端口
2. 將服務(wù)端 socket 注冊到 epoll
3. epoll_wait 等待連接到來，連接到來時(shí)，調(diào)用 accpet 獲取已連接的 socket
4. 將已連接的 socket 注冊到 epoll
5. epoll_wait 等待事件發(fā)生
6. 對方連接關(guān)閉時(shí)，我方調(diào)用 close

可能導(dǎo)致服務(wù)端沒有調(diào)用 close 函數(shù)的原因，如下。

第一個(gè)原因：第 2 步?jīng)]有做，沒有將服務(wù)端 socket 注冊到 epoll，這樣有新連接到來時(shí)，服務(wù)端沒辦法感知這個(gè)事件，也就無法獲取到已連接的 socket，那服務(wù)端自然就沒機(jī)會對 socket 調(diào)用 close 函數(shù)了。

不過這種原因發(fā)生的概率比較小，這種屬于明顯的代碼邏輯 bug，在前期 read view 階段就能發(fā)現(xiàn)的了。

第二個(gè)原因：第 3 步?jīng)]有做，有新連接到來時(shí)沒有調(diào)用 accpet 獲取該連接的 socket，導(dǎo)致當(dāng)有大量的客戶端主動斷開了連接，而服務(wù)端沒機(jī)會對這些 socket 調(diào)用 close 函數(shù)，從而導(dǎo)致服務(wù)端出現(xiàn)大量 CLOSE_WAIT 狀態(tài)的連接。

發(fā)生這種情況可能是因?yàn)榉?wù)端在執(zhí)行 accpet 函數(shù)之前，代碼卡在某一個(gè)邏輯或者提前拋出了異常。

第三個(gè)原因：第 4 步?jīng)]有做，通過 accpet 獲取已連接的 socket 后，沒有將其注冊到 epoll，導(dǎo)致后續(xù)收到 FIN 報(bào)文的時(shí)候，服務(wù)端沒辦法感知這個(gè)事件，那服務(wù)端就沒機(jī)會調(diào)用 close 函數(shù)了。

發(fā)生這種情況可能是因?yàn)榉?wù)端在將已連接的 socket 注冊到 epoll 之前，代碼卡在某一個(gè)邏輯或者提前拋出了異常。之前看到過別人解決 close_wait 問題的實(shí)踐文章，感興趣的可以看看：一次 Netty 代碼不健壯導(dǎo)致的大量 CLOSE_WAIT 連接原因分析

第四個(gè)原因：第 6 步?jīng)]有做，當(dāng)發(fā)現(xiàn)客戶端關(guān)閉連接后，服務(wù)端沒有執(zhí)行 close 函數(shù)，可能是因?yàn)榇a漏處理，或者是在執(zhí)行 close 函數(shù)之前，代碼卡在某一個(gè)邏輯，比如發(fā)生死鎖等等。

可以發(fā)現(xiàn)，當(dāng)服務(wù)端出現(xiàn)大量 CLOSE_WAIT 狀態(tài)的連接的時(shí)候，通常都是代碼的問題，這時(shí)候我們需要針對具體的代碼一步一步的進(jìn)行排查和定位，主要分析的方向就是服務(wù)端為什么沒有調(diào)用 close。

TCP粘包問題怎么解決

• 答：特殊標(biāo)記
• 追問：打斷，如果使用特殊標(biāo)記解決會遇到什么問題
• 答：正文轉(zhuǎn)義字符

補(bǔ)充：

1、固定長度的消息

這種是最簡單方法，即每個(gè)用戶消息都是固定長度的，比如規(guī)定一個(gè)消息的長度是 64 個(gè)字節(jié)，當(dāng)接收方接滿 64 個(gè)字節(jié)，就認(rèn)為這個(gè)內(nèi)容是一個(gè)完整且有效的消息。

但是這種方式靈活性不高，實(shí)際中很少用。

2、特殊字符作為邊界

我們可以在兩個(gè)用戶消息之間插入一個(gè)特殊的字符串，這樣接收方在接收數(shù)據(jù)時(shí)，讀到了這個(gè)特殊字符，就把認(rèn)為已經(jīng)讀完一個(gè)完整的消息。

HTTP 是一個(gè)非常好的例子。

HTTP 通過設(shè)置回車符、換行符作為 HTTP 報(bào)文協(xié)議的邊界。

有一點(diǎn)要注意，這個(gè)作為邊界點(diǎn)的特殊字符，如果剛好消息內(nèi)容里有這個(gè)特殊字符，我們要對這個(gè)字符轉(zhuǎn)義，避免被接收方當(dāng)作消息的邊界點(diǎn)而解析到無效的數(shù)據(jù)。

3、自定義消息結(jié)構(gòu)

我們可以自定義一個(gè)消息結(jié)構(gòu)，由包頭和數(shù)據(jù)組成，其中包頭包是固定大小的，而且包頭里有一個(gè)字段來說明緊隨其后的數(shù)據(jù)有多大。

比如這個(gè)消息結(jié)構(gòu)體，首先 4 個(gè)字節(jié)大小的變量來表示數(shù)據(jù)長度，真正的數(shù)據(jù)則在后面。

struct { 
    u_int32_t message_length; 
    char message_data[]; 
} message;

當(dāng)接收方接收到包頭的大?。ū热?4 個(gè)字節(jié)）后，就解析包頭的內(nèi)容，于是就可以知道數(shù)據(jù)的長度，然后接下來就繼續(xù)讀取數(shù)據(jù)，直到讀滿數(shù)據(jù)的長度，就可以組裝成一個(gè)完整到用戶消息來處理了。

protobuf了解嗎

答：不了解

補(bǔ)充：

Protobuf 是用于數(shù)據(jù)序列化和反序列化的格式，類似于 json。但它們有以下幾點(diǎn)區(qū)別：

• 數(shù)據(jù)大?。篜rotobuf是一種二進(jìn)制格式，相對于JSON來說，數(shù)據(jù)大小更小，序列化和反序列化的效率更高，因此在網(wǎng)絡(luò)傳輸和存儲方面具有一定的優(yōu)勢。
• 性能：由于Protobuf是二進(jìn)制格式，相對于JSON來說，解析速度更快，占用的CPU和內(nèi)存資源更少，因此在高并發(fā)場景下，性能更優(yōu)。
• 可讀性：JSON是一種文本格式，可讀性更好，易于調(diào)試和排查問題。而Protobuf是一種二進(jìn)制格式，可讀性較差。

Protobuf適用于高性能、大數(shù)據(jù)量、高并發(fā)等場景，而JSON適用于數(shù)據(jù)交換、易讀性要求高的場景。

說一下代碼里使用異步的思路

答：舉了個(gè)客戶端異步connect，使用select檢測結(jié)果的例子

順勢問select/epoll的區(qū)別

答：常規(guī)八股回答

補(bǔ)充：

select 和 poll 的缺陷在于，當(dāng)客戶端越多，也就是 Socket 集合越大，Socket 集合的遍歷和拷貝會帶來很大的開銷，因此也很難應(yīng)對 C10K。

epoll 是解決 C10K 問題的利器，通過兩個(gè)方面解決了 select/poll 的問題。

• epoll 在內(nèi)核里使用「紅黑樹」來關(guān)注進(jìn)程所有待檢測的 Socket，紅黑樹是個(gè)高效的數(shù)據(jù)結(jié)構(gòu)，增刪改一般時(shí)間復(fù)雜度是 O(logn)，通過對這棵黑紅樹的管理，不需要像 select/poll 在每次操作時(shí)都傳入整個(gè) Socket 集合，減少了內(nèi)核和用戶空間大量的數(shù)據(jù)拷貝和內(nèi)存分配。
• epoll 使用事件驅(qū)動的機(jī)制，內(nèi)核里維護(hù)了一個(gè)「鏈表」來記錄就緒事件，只將有事件發(fā)生的 Socket 集合傳遞給應(yīng)用程序，不需要像 select/poll 那樣輪詢掃描整個(gè)集合（包含有和無事件的 Socket ），大大提高了檢測的效率。

IO特別密集時(shí)epoll效率還高嗎

答：可以考慮select/poll，這種情況輪詢也很高效，且結(jié)構(gòu)簡單。

補(bǔ)充：

可以先解釋io特別密集時(shí)為什么 epoll 效率不高。原因是：

• 連接密集（短連接特別多），使用epoll的話，每一次連接需要發(fā)生epoll_wait->accpet->epoll_ctl調(diào)用，而使用select只需要select->accpet，減少了一次系統(tǒng)調(diào)用。
• 讀寫密集的話，如果收到數(shù)據(jù)，我們需要響應(yīng)數(shù)據(jù)的話，使用epoll的情況下， read 完后也需要epoll_ctl 加入寫事件，相比select多了一次系統(tǒng)調(diào)用

講一講ET模式

答：常規(guī)八股回答

補(bǔ)充：

epoll 支持兩種事件觸發(fā)模式，分別是邊緣觸發(fā)（edge-triggered，ET）和水平觸發(fā)（level-triggered，LT）。

這兩個(gè)術(shù)語還挺抽象的，其實(shí)它們的區(qū)別還是很好理解的。

• 使用邊緣觸發(fā)模式時(shí)，當(dāng)被監(jiān)控的 Socket 描述符上有可讀事件發(fā)生時(shí)，服務(wù)器端只會從 epoll_wait 中蘇醒一次，即使進(jìn)程沒有調(diào)用 read 函數(shù)從內(nèi)核讀取數(shù)據(jù)，也依然只蘇醒一次，因此我們程序要保證一次性將內(nèi)核緩沖區(qū)的數(shù)據(jù)讀取完；
• 使用水平觸發(fā)模式時(shí)，當(dāng)被監(jiān)控的 Socket 上有可讀事件發(fā)生時(shí)，服務(wù)器端不斷地從 epoll_wait 中蘇醒，直到內(nèi)核緩沖區(qū)數(shù)據(jù)被 read 函數(shù)讀完才結(jié)束，目的是告訴我們有數(shù)據(jù)需要讀取；

舉個(gè)例子，你的快遞被放到了一個(gè)快遞箱里，如果快遞箱只會通過短信通知你一次，即使你一直沒有去取，它也不會再發(fā)送第二條短信提醒你，這個(gè)方式就是邊緣觸發(fā)；如果快遞箱發(fā)現(xiàn)你的快遞沒有被取出，它就會不停地發(fā)短信通知你，直到你取出了快遞，它才消停，這個(gè)就是水平觸發(fā)的方式。

這就是兩者的區(qū)別，水平觸發(fā)的意思是只要滿足事件的條件，比如內(nèi)核中有數(shù)據(jù)需要讀，就一直不斷地把這個(gè)事件傳遞給用戶；而邊緣觸發(fā)的意思是只有第一次滿足條件的時(shí)候才觸發(fā)，之后就不會再傳遞同樣的事件了。

如果使用水平觸發(fā)模式，當(dāng)內(nèi)核通知文件描述符可讀寫時(shí)，接下來還可以繼續(xù)去檢測它的狀態(tài)，看它是否依然可讀或可寫。所以在收到通知后，沒必要一次執(zhí)行盡可能多的讀寫操作。

如果使用邊緣觸發(fā)模式，I/O 事件發(fā)生時(shí)只會通知一次，而且我們不知道到底能讀寫多少數(shù)據(jù)，所以在收到通知后應(yīng)盡可能地讀寫數(shù)據(jù)，以免錯(cuò)失讀寫的機(jī)會。因此，我們會循環(huán)從文件描述符讀寫數(shù)據(jù)，那么如果文件描述符是阻塞的，沒有數(shù)據(jù)可讀寫時(shí)，進(jìn)程會阻塞在讀寫函數(shù)那里，程序就沒辦法繼續(xù)往下執(zhí)行。所以，邊緣觸發(fā)模式一般和非阻塞 I/O 搭配使用，程序會一直執(zhí)行 I/O 操作，直到系統(tǒng)調(diào)用（如 read 和 write）返回錯(cuò)誤，錯(cuò)誤類型為 EAGAIN 或 EWOULDBLOCK。

一般來說，邊緣觸發(fā)的效率比水平觸發(fā)的效率要高，因?yàn)檫吘売|發(fā)可以減少 epoll_wait 的系統(tǒng)調(diào)用次數(shù)，系統(tǒng)調(diào)用也是有一定的開銷的的，畢竟也存在上下文的切換。

對于一個(gè)后端服務(wù)怎么提升性能

• 回答：講了存儲層面的使用中間緩存、網(wǎng)絡(luò)框架設(shè)計(jì)優(yōu)化
• 追問：提示長連接短連接
• 追問：怎么避免拷貝呢，不同的層面說說
• 回答：C++移動語義、零拷貝
• 追問：零拷貝的使用場景
• 追問：kafka了解嗎
• 回答：不了解
• 追問：建議關(guān)注一下kafka，很快很好用

算法

手撕：合并兩個(gè)有序鏈表

感受

基礎(chǔ)問題大部分還好，面試官最后評價(jià)還不錯(cuò)。