一年經(jīng)驗在二線城市面試后端的經(jīng)驗分享

作者：王中陽Go 2023-08-03 08:05:46

開發(fā) 后端

存查詢、價格計算、物流查詢等。使用協(xié)程可以并發(fā)地發(fā)送這些請求，并在所有請求完成后進(jìn)行結(jié)果的匯總和處理，提高請求的效率和響應(yīng)速度。

忠告

這篇文章只適合2年內(nèi)工作經(jīng)驗、甚至沒有工作經(jīng)驗的朋友閱讀。

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

主人公

這篇文章內(nèi)容來自「升職加薪」星球星友的投稿，坐標(biāo)二線，去年畢業(yè)，只有實習(xí)經(jīng)驗，無真實項目經(jīng)驗，自學(xué)一段時間后，在找Golang后端開發(fā)的工作。

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

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

我?guī)退隽嗣嬖噺?fù)盤之后的感受：

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

復(fù)盤面試

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

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

Q1

問：你說對服務(wù)進(jìn)行了拆分，為什么要拆分，拆分的依據(jù)是什么？

首先我們的項目不是微服務(wù)架構(gòu)，是中臺架構(gòu)。拆分的依據(jù)是站在業(yè)務(wù)和功能的模塊進(jìn)行拆分，不同的組開發(fā)不同的服務(wù)，目前我們是拆分成了：商品服務(wù)、訂單服務(wù)、支付服務(wù)、消息服務(wù)、基礎(chǔ)服務(wù)。

Q2

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

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

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

Q3

問：你說主要負(fù)責(zé)了訂單模塊，那這個訂單的狀態(tài)及流轉(zhuǎn)是怎么實現(xiàn)的？

我們是通過以下方式實現(xiàn)：

訂單狀態(tài)定義：首先，需要定義訂單的不同狀態(tài)。常見的訂單狀態(tài)包括：待支付、已支付、待發(fā)貨、已發(fā)貨、已完成、已取消等。根據(jù)業(yè)務(wù)需求，我們也可以根據(jù)實際情況定義更多的訂單狀態(tài)。
訂單流轉(zhuǎn)：訂單的狀態(tài)會隨著用戶的操作和系統(tǒng)的處理而發(fā)生變化。訂單的流轉(zhuǎn)通常包括以下幾個環(huán)節(jié)：

下單：用戶下單后，訂單狀態(tài)為待支付。

支付：用戶完成支付后，訂單狀態(tài)變?yōu)橐阎Ц丁?/p>

發(fā)貨：商家根據(jù)庫存情況進(jìn)行發(fā)貨操作，訂單狀態(tài)變?yōu)榇l(fā)貨。

物流更新：商家更新物流信息后，訂單狀態(tài)變?yōu)橐寻l(fā)貨。

確認(rèn)收貨：用戶確認(rèn)收貨后，訂單狀態(tài)變?yōu)橐淹瓿伞?/p>

取消訂單：用戶或商家取消訂單后，訂單狀態(tài)變?yōu)橐讶∠?/p>

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

Q4

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

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

庫存控制：在處理訂單時，需要對商品的庫存進(jìn)行控制。在每個訂單中，需要檢查商品的庫存數(shù)量是否足夠，如果庫存不足，則不允許繼續(xù)下單。這可以通過在數(shù)據(jù)庫中使用事務(wù)來實現(xiàn)，確保在并發(fā)情況下對庫存的準(zhǔn)確控制。
鎖機(jī)制：在并發(fā)場景下，可以使用鎖機(jī)制來保證對庫存的原子性操作。例如，可以使用數(shù)據(jù)庫的行級鎖或樂觀鎖來控制對庫存的并發(fā)訪問。這樣可以確保在多個請求同時訪問庫存時，只有一個請求能夠成功更新庫存，其他請求會等待或進(jìn)行相應(yīng)的處理。
消息隊列順序處理：在消息隊列中，可以使用順序處理的方式來確保訂單的處理順序。即使多個客戶同時下單了同一個商品，消息隊列會按照順序?qū)⒂唵蜗l(fā)送給消費(fèi)者進(jìn)行處理。這樣可以避免并發(fā)情況下的競爭條件，確保訂單的處理是有序的。
冪等性設(shè)計：在處理訂單時，可以設(shè)計冪等性操作，即使多次處理相同的訂單請求，也不會對系統(tǒng)產(chǎn)生副作用。這樣可以避免重復(fù)處理訂單，即使多個請求同時到達(dá)，也只會處理一次。

通過以上措施的組合應(yīng)用，可以在并發(fā)場景下保證商品不會多賣。具體的實現(xiàn)方式會根據(jù)系統(tǒng)架構(gòu)和業(yè)務(wù)需求的不同而有所差異。在設(shè)計和實現(xiàn)過程中，需要綜合考慮并發(fā)性、性能和數(shù)據(jù)一致性等因素。

更多的解決思路可以看我之前分享的秒殺系統(tǒng)設(shè)計

Q5

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

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

Q6

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

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

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

Q7

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

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

Q8

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

是的，我們可以維護(hù)自己本地開發(fā)的數(shù)據(jù)庫；如果要修改測試庫和正式庫的字段信息，要向領(lǐng)導(dǎo)申請。

phone是 11位的varchar

Q9

問：平時開發(fā)過程中是和數(shù)據(jù)庫直連嗎，還是中間有緩存層嗎？

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

商品可售狀態(tài)就不會走緩存，而是直接查詢數(shù)據(jù)庫，根據(jù)用戶選擇的商品規(guī)格和所在地直接查詢數(shù)據(jù)庫。

Q10

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

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

商品可售狀態(tài)就不會走緩存，而是直接查詢數(shù)據(jù)庫，根據(jù)用戶選擇的商品規(guī)格和所在地直接查詢數(shù)據(jù)庫。

Q11

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

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

使用事務(wù)：將寫入數(shù)據(jù)庫的操作放在一個事務(wù)中。事務(wù)是一組原子性的操作，要么全部成功提交，要么全部回滾。在購買商品的過程中，可以將相關(guān)的數(shù)據(jù)庫操作（如創(chuàng)建訂單、扣減庫存、記錄交易日志等）放在同一個事務(wù)中。如果在事務(wù)執(zhí)行過程中發(fā)生錯誤，可以回滾事務(wù)，確保數(shù)據(jù)的一致性。
數(shù)據(jù)庫鎖定：在寫入數(shù)據(jù)庫時，可以使用數(shù)據(jù)庫的鎖機(jī)制來保證數(shù)據(jù)的正確寫入。例如，可以使用行級鎖或表級鎖來控制并發(fā)訪問，避免多個用戶同時修改同一條數(shù)據(jù)。這樣可以確保在寫入過程中不會發(fā)生數(shù)據(jù)沖突。
異常處理和重試：在寫入數(shù)據(jù)庫時，需要進(jìn)行異常處理，并在發(fā)生錯誤時進(jìn)行適當(dāng)?shù)闹卦嚒＠纾梢圆东@數(shù)據(jù)庫操作的異常，并進(jìn)行回滾和重試操作，直到數(shù)據(jù)成功寫入數(shù)據(jù)庫為止。
數(shù)據(jù)備份和恢復(fù)：定期進(jìn)行數(shù)據(jù)庫備份，并確保備份的完整性和可靠性。如果在寫入過程中發(fā)生崩潰或數(shù)據(jù)丟失，可以通過備份進(jìn)行數(shù)據(jù)恢復(fù)，以保證數(shù)據(jù)的正確性。
監(jiān)控和報警：設(shè)置數(shù)據(jù)庫監(jiān)控和報警系統(tǒng)，及時發(fā)現(xiàn)數(shù)據(jù)庫異常和故障，并采取相應(yīng)的措施進(jìn)行修復(fù)。這樣可以減少數(shù)據(jù)丟失的風(fēng)險，并及時處理潛在的問題。

Q12

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

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

Q13

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

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

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

另外補(bǔ)充一下：

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

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

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