今天帶來我的好友健哥面試拼多多海外電商Java崗的一個覆盤

前言

大家好，我是健哥。今天跟大家覆盤一下自己面試拼多多的一個情況。我投的是拼多多的海外電商部門Java崗，大家其實也知道現在這個互聯網的大環境不太好，拼多多算是HC比較多的，現在還在大規模招人的一家公司。海外電商可以説是整個拼多多未來的一個經濟增長點或者説是整個拼多多最看好的或者説寄厚望的一個業務。

拼多多的面試主要是兩輪技術面加上一輪HR面。技術面的第一輪是你的小組長，第二輪是你總監，並且拼多多技術面是要手撕代碼的。而且他們是有自己的代碼平台，你需要在這個平台上去寫代碼。

兩輪技術面都有一道代碼題，我的第一輪面試官主要還是圍繞基礎知識展開，項目其實聊的並不多。一面重點全部都圍繞在了數據庫上，聊得很多，也很集中。基本都是mysql和redis，我不知道是這個面試官特別擅長數據庫還是特別喜歡數據庫，我感覺他特別愛問這個，就集中火力的問，非常可怕。

一面

1.索引

第一部分是索引，像innodb存儲引擎，聚簇索引和非聚簇索引。像innodb是必然有一個聚簇索引，先問一下它的聚簇索引是怎麼構建的，然後非聚簇索引和聚簇索引有什麼區別。

接下來就問回表，索引覆蓋，聯合索引的最左前綴匹配規則，就是連着問，緊挨着問你。而且還不是那種面經，不是你只説出這個面經的這些話就行了，他還會給你一個聯合索引，然後給你很多個SQL，請問這個SQL哪些查詢條件命中了這個索引。

然後接下來又問了一下索引的這個設計原則，就是我們在設計這個索引的時候要注意什麼東西，然後設計高效的索引你有哪些原則要去遵守。

2.mysql事務

第二部分主要mysql的事務。首先逃不了的就是事務的四大特性。a c i d（一致性、隔離性、持久性和原子性），然後又問了這四大特性它是靠什麼來保證的。像隔離性是用鎖機制來保證，持久性通過redo日誌來保證，一致性和原子性是通過undo日誌來保證的。

接下來又深入問了redo日誌和undo日誌的區別，它的一些實現原理，具體怎麼工作的，就是具體怎麼保證這個四大特性的實現。

3.數據庫併發

然後第三部分是數據庫的併發。併發也繞不開那個點，就是四大隔離級別，首先你要把四大隔離級別講清楚。什麼情況下會併發，讀讀是不可能有併發問題；讀寫，寫寫它都會存在併發衝突的。

聊完這個之後又問你mvcc，innodb它是怎麼解決幻讀的；mvcc的實現原理是什麼；接下來又問悲觀鎖和樂觀鎖，什麼情況下該用悲觀鎖，什麼情況下該用樂觀鎖。

mysql就主要問這些，問了很久，確實問了很久。就是不停地問，最後我都答得不耐煩了，然後問完mysql之後他就開始問緩存了，就redis

4.redis緩存

緩存問的沒有那麼多，就是主要聊了一下緩存穿透，緩存擊穿，這兩個的區別。它怎麼解決，它解決方案是啥。然後再聊了一下redis的兩種持久化機制，aof和rdb。就是一個是快照，一個是日誌。

然後也細問了一下aof的這個工作原理和工作流程，這個問得還挺深的。最後一個問題就是緩存和數據庫的一致性，你怎麼保證。這個問題我回答的時間很長，因為它的方案有很多，比如：先刪除後修改或者先修改後刪除。

雖然有多種方案，但是最好要把這些方案的優缺點，可能會出現的問題，怎麼去規避這個問題，儘可能的答出來，我感覺應該就差不多了，其實我一面整體的問題上應該都答出來了，感覺面試官還挺滿意的。

5.算法題

一面的最後就是寫了一道算法題，我的那道算法題是一道螺旋矩陣。大家其實可以去看一下有個網站叫CodeTop，拼多多的最高頻的算法題就是螺旋矩陣，我正好就問到了，我當時刷CodeTop的時候正好刷過，所以我寫得很快，最後一個小時多一點點的時間就結束了這個第一輪面試。

二面

1.聊項目

二面的話其實就不問這些八股了，重點全部圍繞到了你的項目。我的項目其實蠻多的，但是感覺面試官就只看中了我一個技術點，就那個技術點聊了半個小時

因為我那個項目中有一個數據庫到elastic search的一個數據同步技術方案，就是我自己設計了一個技術方案，因為數據庫的查詢能力是有限的，然後很多表之間的join查詢是很慢的，所以一般我們在工業界都會選擇大寬表。就是把幾張表建一張大寬表，就join在一起建一張大寬表，然後放到一個elastic search上面去，然後我們如果要去查這些複雜的查詢或者一些詳情的查詢，本來是需要mysql表與表之間做join，但是現在你不需要了，你直接走elastic search去查這個大寬表就行了。因為elastic search它支持海量查詢，所以它查詢速度很快，所以一般工業界就是這麼做的。

2.如何保證數據同步

但是這就有個問題了，數據庫和elastic search這個數據同步怎麼保證，我當時是採用Binlog的那個方式去做的，我還跟面試官講了一下數據同步就是mysql到elastic search的這個數據同步有哪些方案我都給他列舉了一下。最後我選擇了Binlog監聽，通過卡夫卡消費的方式去解決了這個數據同步的問題。為什麼選擇這個方案，主要是它邏輯的耦合度比較低，就是它這個代碼是不耦合的，你只是監聽那個Binlog就完全解耦了。

3.數據實時性

講完了這個之後，面試官又問了我很多實現細節上的一些問題，比如説你數據同步的這個過程中，你如何保證這個實時性。因為我這個項目不是強一致性，是最終一致性，所以我對這個時效性要求沒有那麼嚴格，就一兩秒都是可以容忍的。

如果要嚴格保證，那麼同步方法就只能雙寫。通過事務把它給綁在一起雙寫，但是這種代碼的耦合度太高了，相當於只要有個地方修改了這個數據，那你也得去用代碼去修改那個elastic search的數據。所以綁在一起耦合度太高了，後期的代碼的維護也不太方便。

4.算法題

第二面的最後也是算法題，其實也比較簡單，是一個二叉樹的寬度，就是輸入一棵二叉樹，求這個二叉樹的寬度，這個其實是leetcode的一道經典題了。我感覺大廠的算法題也不會太難，一般都是中等題，我到現在遇到的主要還是中等題居多。

以上就是整個拼多多的一個面試覆盤。