忠告

這篇文章只適合2年內工作經驗、甚至沒有工作經驗的朋友閱讀。

如果你是2年以上工作經驗，請果斷劃走，對你沒啥幫助~

主人公

這篇文章內容來自 「升職加薪」星球星友 的投稿，坐標二線，去年畢業，只有實習經驗，無真實項目經驗，自學一段時間后，在找Golang后端開發的工作。

先說下這位朋友的自我面評：

1. 上周在二線城市大概約到了4個面試，自我感覺八股文回答的還可以，因為星球中的面試題沒少背。
2. 但是問項目的問題就很垮，或者說是特別垮，因為并沒有真實的一年工作經驗，有很多東西不知道怎么說，經不起推敲。

我幫他做了面試復盤之后的感受：

1. 基礎確實還可以，但是項目經驗真的拉胯，很多概念都不清楚。
2. 很重要的一點：很不自信，碰到不會的就懷疑自己，就去惡補。你才一年的工作經驗，難道要什么都會嗎！？不管你是幾年工作經驗，有些不是你負責的，你就是不會，這沒啥丟人的，不用瞎編，再去惡補，這么搞，總也準備不完。
3. 如果是自信的應聘者，會很明確自己的技能邊界在哪里？ 哪些是我負責的，我精通的；哪些是組內其他人負責的，我有打過配合。有哪些是我知道有在用，但是沒實操過，但是我能和你聊聊我的實現思路，如果讓我做的話，我會這樣設計：巴拉巴拉...

復盤面試

下面是結合他“1年工作經驗”的情況，整理的一部分面試問題和答案，希望對缺少項目經驗的小伙伴們有所啟發。

這位朋友在前公司做了一個toB的電商SAAS平臺，業務難度不高，而且他實際參與的開發工作并不多，并沒有整體視野，也不懂得“開黑”。（咱可以不真實開發，但是和朋友抽煙吹水的時候，也聊聊項目的技術難點，為以后寫簡歷做做準備，避免到時候抓瞎~）

Q1

問：你說對服務進行了拆分，為什么要拆分，拆分的依據是什么？

首先我們的項目不是微服務架構，是中臺架構。拆分的依據是站在業務和功能的模塊進行拆分，不同的組開發不同的服務，目前我們是拆分成了：商品服務、訂單服務、支付服務、消息服務、基礎服務。

Q2

問：和前端交互的頁面是在哪個模塊？

整體項目都是前后端分離的設計，每個模塊都會和前端交互，go寫服務和接口。

（我就很好奇，這個面試官到底想問啥....）

Q3

問：你說主要負責了訂單模塊，那這個訂單的狀態及流轉是怎么實現的？

我們是通過以下方式實現：

1. 訂單狀態定義：首先，需要定義訂單的不同狀態。常見的訂單狀態包括：待支付、已支付、待發貨、已發貨、已完成、已取消等。根據業務需求，我們也可以根據實際情況定義更多的訂單狀態。
2. 訂單流轉：訂單的狀態會隨著用戶的操作和系統的處理而發生變化。訂單的流轉通常包括以下幾個環節：

下單：用戶下單后，訂單狀態為待支付。

支付：用戶完成支付后，訂單狀態變為已支付。

發貨：商家根據庫存情況進行發貨操作，訂單狀態變為待發貨。

物流更新：商家更新物流信息后，訂單狀態變為已發貨。

確認收貨：用戶確認收貨后，訂單狀態變為已完成。

取消訂單：用戶或商家取消訂單后，訂單狀態變為已取消。

3. 狀態變更觸發：訂單狀態的變更通常由用戶的操作、系統的自動處理或商家的操作觸發。例如，用戶支付成功后，系統會自動將訂單狀態更新為已支付；商家發貨后，系統會自動將訂單狀態更新為已發貨。
4. 狀態流轉記錄：為了跟蹤訂單狀態的變化，通常會在數據庫中記錄訂單狀態的流轉歷史。每次訂單狀態發生變化時，會記錄相應的狀態變更時間和操作人員等信息。
5. 后臺管理界面：為了方便商家管理訂單，通常會提供一個后臺管理界面，用于查看訂單列表、處理訂單狀態變更、更新物流信息等操作。

Q4

問：你說訂單完成后接入消息隊列異步更新庫存銷量，那多個客戶下單了一個商品，如何保證商品不會多賣，在并發場景下是如何處理的，類似于兩個請求同時買一件商品。

在并發場景下，確保商品不會多賣是一個常見的問題。為了解決這個問題，可以采取以下措施：

1. 庫存控制：在處理訂單時，需要對商品的庫存進行控制。在每個訂單中，需要檢查商品的庫存數量是否足夠，如果庫存不足，則不允許繼續下單。這可以通過在數據庫中使用事務來實現，確保在并發情況下對庫存的準確控制。
2. 鎖機制：在并發場景下，可以使用鎖機制來保證對庫存的原子性操作。例如，可以使用數據庫的行級鎖或樂觀鎖來控制對庫存的并發訪問。這樣可以確保在多個請求同時訪問庫存時，只有一個請求能夠成功更新庫存，其他請求會等待或進行相應的處理。
3. 消息隊列順序處理：在消息隊列中，可以使用順序處理的方式來確保訂單的處理順序。即使多個客戶同時下單了同一個商品，消息隊列會按照順序將訂單消息發送給消費者進行處理。這樣可以避免并發情況下的競爭條件，確保訂單的處理是有序的。
4. 冪等性設計：在處理訂單時，可以設計冪等性操作，即使多次處理相同的訂單請求，也不會對系統產生副作用。這樣可以避免重復處理訂單，即使多個請求同時到達，也只會處理一次。

通過以上措施的組合應用，可以在并發場景下保證商品不會多賣。具體的實現方式會根據系統架構和業務需求的不同而有所差異。在設計和實現過程中，需要綜合考慮并發性、性能和數據一致性等因素。

更多的解決思路可以看我之前分享的 秒殺系統設計

Q5

問：這個項目是從0到1還是已經有完整的項目在正常迭代？

不是從0到1的，這個項目之前是PHP開發的。我們使用Go語言進行重寫的。

Q6

問：用戶人群是什么樣的，用戶量是多少?

我們是一個Saas系統，我接觸到的客戶是B端客戶，會和技術支持一起解決一些客戶反饋的問題和需求。

B端用戶大概十幾家在對接，B端用戶對應的C端用戶不是很清楚。因為我們項目是支持私有化獨立部署的，

Q7

問：訂單會做日志嗎，比如說每天成交了多少訂單。

會做持久化存儲，存儲到MySQL中；也會做日志，公司有負責數據分析的同事。大概幾千單吧，我主要是負責商品中心的，訂單這部分不是很了解。

Q8

問：你們數據庫是自己維護嗎，存儲phone字段用什么類型？

是的，我們可以維護自己本地開發的數據庫；如果要修改測試庫和正式庫的字段信息，要向領導申請。

phone是 11位的varchar

Q9

問：平時開發過程中是和數據庫直連嗎，還是中間有緩存層嗎？

有直連的也有加入redis緩存層的，不同的場景處理方式不一樣。比如我負責的商品中心，熱點商品接口是會用緩存的。

商品可售狀態就不會走緩存，而是直接查詢數據庫，根據用戶選擇的商品規格和所在地直接查詢數據庫。

Q10

問：你用說redis緩存，什么時候查庫呢？

看場景和具體的需求，就像前面提到的：

商品可售狀態就不會走緩存，而是直接查詢數據庫，根據用戶選擇的商品規格和所在地直接查詢數據庫。

Q11

問：一個場景，用戶購買商品，寫入數據庫到一半時崩了，如何保證正確寫入？

在處理用戶購買商品的場景中，確保正確寫入數據庫是非常重要的。為了保證數據的完整性和一致性，可以采取以下措施：

1. 使用事務：將寫入數據庫的操作放在一個事務中。事務是一組原子性的操作，要么全部成功提交，要么全部回滾。在購買商品的過程中，可以將相關的數據庫操作（如創建訂單、扣減庫存、記錄交易日志等）放在同一個事務中。如果在事務執行過程中發生錯誤，可以回滾事務，確保數據的一致性。
2. 數據庫鎖定：在寫入數據庫時，可以使用數據庫的鎖機制來保證數據的正確寫入。例如，可以使用行級鎖或表級鎖來控制并發訪問，避免多個用戶同時修改同一條數據。這樣可以確保在寫入過程中不會發生數據沖突。
3. 異常處理和重試：在寫入數據庫時，需要進行異常處理，并在發生錯誤時進行適當的重試。例如，可以捕獲數據庫操作的異常，并進行回滾和重試操作，直到數據成功寫入數據庫為止。
4. 數據備份和恢復：定期進行數據庫備份，并確保備份的完整性和可靠性。如果在寫入過程中發生崩潰或數據丟失，可以通過備份進行數據恢復，以保證數據的正確性。
5. 監控和報警：設置數據庫監控和報警系統，及時發現數據庫異常和故障，并采取相應的措施進行修復。這樣可以減少數據丟失的風險，并及時處理潛在的問題。

Q12

問：在你們的項目中，哪種場景下可以用協程？

1. 并發請求：在電商項目中，可能需要同時向多個服務發送請求，如商品庫存查詢、價格計算、物流查詢等。使用協程可以并發地發送這些請求，并在所有請求完成后進行結果的匯總和處理，提高請求的效率和響應速度。
2. 并發數據處理：電商項目通常需要對大量的數據進行處理，如訂單數據、用戶數據等。使用協程可以并發地處理這些數據，提高數據處理的效率。例如，可以使用協程并發地讀取和寫入數據庫，進行數據的批量插入或更新。
3. 異步任務處理：電商項目中可能存在一些耗時的任務，如發送郵件、生成報表、處理圖片等。使用協程可以將這些任務轉化為異步操作，提高系統的并發能力和響應性能。例如，可以使用協程異步地處理訂單的郵件通知，而不會阻塞主線程的執行。
4. 并發庫存更新：在電商項目中，庫存的更新是一個重要的操作。使用協程可以并發地更新庫存，避免因為庫存更新操作的串行執行而導致的性能瓶頸。通過使用協程，可以同時處理多個庫存更新請求，提高庫存更新的效率。

Q13

問：linux命令操作會嗎，平時操作日志是怎么查，在db上還是有專門的日志庫？

管理后臺的操作日志在管理后臺能直接查看，有表進行記錄。

錯誤日志和請求日志是通過查看log日志的方式查看的：比如，tail -f xxx.log

另外補充一下：

• cat：用于查看文件的內容，可以使用cat filename命令來查看日志文件的內容。
• tail：用于查看文件的末尾內容，可以使用tail filename命令來實時查看日志文件的最新內容。
• grep：用于在文件中搜索指定的字符串，可以使用grep pattern filename命令來搜索日志文件中的特定內容。
• less：用于分頁查看文件的內容，可以使用less filename命令來逐頁查看日志文件的內容。

在實際應用中，日志通常會記錄在文件中，可以通過上述命令來查看和分析日志。日志文件的位置和命名方式可能因不同的應用程序和配置而有所不同。

此外，有些應用程序會將日志記錄在數據庫中，以便更方便地進行查詢和分析。這些應用程序通常會提供專門的日志庫或工具，用于管理和查詢日志數據。例如，Elasticsearch、Logstash和Kibana（ELK Stack）是一套常用的日志管理和分析工具，可以將日志數據存儲在Elasticsearch中，并使用Kibana進行可視化和查詢。

總結

我個人是覺得上面這些問題比較簡單，比較符合“一年工作經驗”的求職設定。

為什么這位朋友會覺得無從下手，說不好呢？究其原因還在于缺少真實的項目經歷。

要么去花時間惡補項目經驗，要么找個明白人針對項目多做模擬面試。

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

轉載本文請聯系「 程序員升級打怪之旅」公眾號。