後端工程師求職實錄：二線城市就業攻略與心得分享

這篇文章內容來自 「升職加薪」星球星友 的投稿，座標二線，去年畢業，只有實習經驗，無真實專案經驗，自學一段時間後，在找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進行視覺化和查詢。

總結

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

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

要麼去花時間惡補專案經驗，要麼找個明白人針對專案多做模擬面試，這才是找工作的正途。可別想著走捷徑。

一起進步

​獨行難，眾行易，一個人刻意練習是​孤獨的。

歡迎加入我們的小圈子，一起刻意練習，結伴成長！

微訊號：wangzhongyang1993

公眾號：程式設計師升職加薪之旅

也歡迎大家關注我的賬號，點贊、留言、轉發。你的支援，是我更文的最大動力！