建站
咨詢
售后
建站咨詢
新聞中心
適合人群
這篇文章適合2年內(nèi)工作經(jīng)驗(yàn)、或者沒有工作經(jīng)驗(yàn)的朋友閱讀。
10年積累的做網(wǎng)站、成都網(wǎng)站建設(shè)經(jīng)驗(yàn)，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識你，你也不認(rèn)識我。但先網(wǎng)站制作后付款的網(wǎng)站建設(shè)流程，更有岳陽免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。
如果你是2年以上工作經(jīng)驗(yàn)，可能本文對你幫助有限~
主人公
這篇文章內(nèi)容來自 「升職加薪」星球星友 的投稿，坐標(biāo)二線，去年畢業(yè)，只有實(shí)習(xí)經(jīng)驗(yàn)，無真實(shí)項(xiàng)目經(jīng)驗(yàn)，自學(xué)一段時(shí)間后，在找Golang后端開發(fā)的工作。
先說下這位朋友的自我面評：
- 上周在二線城市大概約到了4個面試，自我感覺八股文回答的還可以，因?yàn)樾乔蛑械拿嬖囶}沒少背。
- 但是問項(xiàng)目的問題就很垮，或者說是特別垮，因?yàn)椴]有真實(shí)的一年工作經(jīng)驗(yàn)，有很多東西不知道怎么說，經(jīng)不起推敲。
我?guī)退隽嗣嬖噺?fù)盤之后的感受：
- 基礎(chǔ)確實(shí)還可以，但是項(xiàng)目經(jīng)驗(yàn)真的拉胯，很多概念都不清楚。
- 很重要的一點(diǎn)：很不自信，碰到不會的就懷疑自己，就去惡補(bǔ)。你才一年的工作經(jīng)驗(yàn)，難道要什么都會嗎?。坎还苣闶菐啄旯ぷ鹘?jīng)驗(yàn)，有些不是你負(fù)責(zé)的，你就是不會，這沒啥丟人的，不用瞎編，再去惡補(bǔ)，這么搞，總也準(zhǔn)備不完。
- 如果是自信的應(yīng)聘者，會很明確自己的技能邊界在哪里？ 哪些是我負(fù)責(zé)的，我精通的；哪些是組內(nèi)其他人負(fù)責(zé)的，我有打過配合。有哪些是我知道有在用，但是沒實(shí)操過，但是我能和你聊聊我的實(shí)現(xiàn)思路，如果讓我做的話，我會這樣設(shè)計(jì)：巴拉巴拉...
復(fù)盤面試
下面是結(jié)合他“1年工作經(jīng)驗(yàn)”的情況，整理的一部分面試問題和答案，希望對缺少項(xiàng)目經(jīng)驗(yàn)的小伙伴們有所啟發(fā)。
這位朋友在前公司做了一個toB的電商SAAS平臺，業(yè)務(wù)難度不高，而且他實(shí)際參與的開發(fā)工作并不多，并沒有整體視野，也不懂得“開黑”。（咱可以不真實(shí)開發(fā)，但是和朋友抽煙吹水的時(shí)候，也聊聊項(xiàng)目的技術(shù)難點(diǎn)，為以后寫簡歷做做準(zhǔn)備，避免到時(shí)候抓瞎~）
Q1
問：你說對服務(wù)進(jìn)行了拆分，為什么要拆分，拆分的依據(jù)是什么？
首先我們的項(xiàng)目不是微服務(wù)架構(gòu)，是中臺架構(gòu)。拆分的依據(jù)是站在業(yè)務(wù)和功能的模塊進(jìn)行拆分，不同的組開發(fā)不同的服務(wù)，目前我們是拆分成了：商品服務(wù)、訂單服務(wù)、支付服務(wù)、消息服務(wù)、基礎(chǔ)服務(wù)。
Q2
問：和前端交互的頁面是在哪個模塊？
整體項(xiàng)目都是前后端分離的設(shè)計(jì)，每個模塊都會和前端交互，go寫服務(wù)和接口。
（我就很好奇，這個面試官到底想問啥....）
Q3
問：你說主要負(fù)責(zé)了訂單模塊，那這個訂單的狀態(tài)及流轉(zhuǎn)是怎么實(shí)現(xiàn)的？
我們是通過以下方式實(shí)現(xiàn)：
- 訂單狀態(tài)定義：首先，需要定義訂單的不同狀態(tài)。常見的訂單狀態(tài)包括：待支付、已支付、待發(fā)貨、已發(fā)貨、已完成、已取消等。根據(jù)業(yè)務(wù)需求，我們也可以根據(jù)實(shí)際情況定義更多的訂單狀態(tài)。
- 訂單流轉(zhuǎn)：訂單的狀態(tài)會隨著用戶的操作和系統(tǒng)的處理而發(fā)生變化。訂單的流轉(zhuǎn)通常包括以下幾個環(huán)節(jié)：
- 下單：用戶下單后，訂單狀態(tài)為待支付。
- 支付：用戶完成支付后，訂單狀態(tài)變?yōu)橐阎Ц丁?/li>
- 發(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)橐淹瓿伞?/li>
- 取消訂單：用戶或商家取消訂單后，訂單狀態(tài)變?yōu)橐讶∠?/li>
- 狀態(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ā)生變化時(shí)，會記錄相應(yīng)的狀態(tài)變更時(shí)間和操作人員等信息。
- 后臺管理界面：為了方便商家管理訂單，通常會提供一個后臺管理界面，用于查看訂單列表、處理訂單狀態(tài)變更、更新物流信息等操作。
Q4
問：你說訂單完成后接入消息隊(duì)列異步更新庫存銷量，那多個客戶下單了一個商品，如何保證商品不會多賣，在并發(fā)場景下是如何處理的，類似于兩個請求同時(shí)買一件商品。
在并發(fā)場景下，確保商品不會多賣是一個常見的問題。為了解決這個問題，可以采取以下措施：
- 庫存控制：在處理訂單時(shí)，需要對商品的庫存進(jìn)行控制。在每個訂單中，需要檢查商品的庫存數(shù)量是否足夠，如果庫存不足，則不允許繼續(xù)下單。這可以通過在數(shù)據(jù)庫中使用事務(wù)來實(shí)現(xiàn)，確保在并發(fā)情況下對庫存的準(zhǔn)確控制。
- 鎖機(jī)制：在并發(fā)場景下，可以使用鎖機(jī)制來保證對庫存的原子性操作。例如，可以使用數(shù)據(jù)庫的行級鎖或樂觀鎖來控制對庫存的并發(fā)訪問。這樣可以確保在多個請求同時(shí)訪問庫存時(shí)，只有一個請求能夠成功更新庫存，其他請求會等待或進(jìn)行相應(yīng)的處理。
- 消息隊(duì)列順序處理：在消息隊(duì)列中，可以使用順序處理的方式來確保訂單的處理順序。即使多個客戶同時(shí)下單了同一個商品，消息隊(duì)列會按照順序?qū)⒂唵蜗l(fā)送給消費(fèi)者進(jìn)行處理。這樣可以避免并發(fā)情況下的競爭條件，確保訂單的處理是有序的。
- 冪等性設(shè)計(jì)：在處理訂單時(shí)，可以設(shè)計(jì)冪等性操作，即使多次處理相同的訂單請求，也不會對系統(tǒng)產(chǎn)生副作用。這樣可以避免重復(fù)處理訂單，即使多個請求同時(shí)到達(dá)，也只會處理一次。
通過以上措施的組合應(yīng)用，可以在并發(fā)場景下保證商品不會多賣。具體的實(shí)現(xiàn)方式會根據(jù)系統(tǒng)架構(gòu)和業(yè)務(wù)需求的不同而有所差異。在設(shè)計(jì)和實(shí)現(xiàn)過程中，需要綜合考慮并發(fā)性、性能和數(shù)據(jù)一致性等因素。
更多的解決思路可以看我之前分享的 秒殺系統(tǒng)設(shè)計(jì)
Q5
問：這個項(xiàng)目是從0到1還是已經(jīng)有完整的項(xiàng)目在正常迭代？
不是從0到1的，這個項(xiàng)目之前是PHP開發(fā)的。我們使用Go語言進(jìn)行重寫的。
Q6
問：用戶人群是什么樣的，用戶量是多少?
我們是一個Saas系統(tǒng)，我接觸到的客戶是B端客戶，會和技術(shù)支持一起解決一些客戶反饋的問題和需求。
B端用戶大概十幾家在對接，B端用戶對應(yīng)的C端用戶不是很清楚。因?yàn)槲覀冺?xiàng)目是支持私有化獨(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
問：平時(shí)開發(fā)過程中是和數(shù)據(jù)庫直連嗎，還是中間有緩存層嗎？
有直連的也有加入redis緩存層的，不同的場景處理方式不一樣。比如我負(fù)責(zé)的商品中心，熱點(diǎn)商品接口是會用緩存的。
商品可售狀態(tài)就不會走緩存，而是直接查詢數(shù)據(jù)庫，根據(jù)用戶選擇的商品規(guī)格和所在地直接查詢數(shù)據(jù)庫。
Q10
問：你用說redis緩存，什么時(shí)候查庫呢？
看場景和具體的需求，就像前面提到的：
商品可售狀態(tài)就不會走緩存，而是直接查詢數(shù)據(jù)庫，根據(jù)用戶選擇的商品規(guī)格和所在地直接查詢數(shù)據(jù)庫。
Q11
問：一個場景，用戶購買商品，寫入數(shù)據(jù)庫到一半時(shí)崩了，如何保證正確寫入？
在處理用戶購買商品的場景中，確保正確寫入數(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í)，可以使用數(shù)據(jù)庫的鎖機(jī)制來保證數(shù)據(jù)的正確寫入。例如，可以使用行級鎖或表級鎖來控制并發(fā)訪問，避免多個用戶同時(shí)修改同一條數(shù)據(jù)。這樣可以確保在寫入過程中不會發(fā)生數(shù)據(jù)沖突。
- 異常處理和重試：在寫入數(shù)據(jù)庫時(shí)，需要進(jìn)行異常處理，并在發(fā)生錯誤時(shí)進(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)控和報(bào)警：設(shè)置數(shù)據(jù)庫監(jiān)控和報(bào)警系統(tǒng)，及時(shí)發(fā)現(xiàn)數(shù)據(jù)庫異常和故障，并采取相應(yīng)的措施進(jìn)行修復(fù)。這樣可以減少數(shù)據(jù)丟失的風(fēng)險(xiǎn)，并及時(shí)處理潛在的問題。
Q12
問：在你們的項(xiàng)目中，哪種場景下可以用協(xié)程？
- 并發(fā)請求：在電商項(xiàng)目中，可能需要同時(shí)向多個服務(wù)發(fā)送請求，如商品庫存查詢、價(jià)格計(jì)算、物流查詢等。使用協(xié)程可以并發(fā)地發(fā)送這些請求，并在所有請求完成后進(jìn)行結(jié)果的匯總和處理，提高請求的效率和響應(yīng)速度。
- 并發(fā)數(shù)據(jù)處理：電商項(xiàng)目通常需要對大量的數(shù)據(jù)進(jìn)行處理，如訂單數(shù)據(jù)、用戶數(shù)據(jù)等。使用協(xié)程可以并發(fā)地處理這些數(shù)據(jù)，提高數(shù)據(jù)處理的效率。例如，可以使用協(xié)程并發(fā)地讀取和寫入數(shù)據(jù)庫，進(jìn)行數(shù)據(jù)的批量插入或更新。
- 異步任務(wù)處理：電商項(xiàng)目中可能存在一些耗時(shí)的任務(wù)，如發(fā)送郵件、生成報(bào)表、處理圖片等。使用協(xié)程可以將這些任務(wù)轉(zhuǎn)化為異步操作，提高系統(tǒng)的并發(fā)能力和響應(yīng)性能。例如，可以使用協(xié)程異步地處理訂單的郵件通知，而不會阻塞主線程的執(zhí)行。
- 并發(fā)庫存更新：在電商項(xiàng)目中，庫存的更新是一個重要的操作。使用協(xié)程可以并發(fā)地更新庫存，避免因?yàn)閹齑娓虏僮鞯拇袌?zhí)行而導(dǎo)致的性能瓶頸。通過使用協(xié)程，可以同時(shí)處理多個庫存更新請求，提高庫存更新的效率。
Q13
問：linux命令操作會嗎，平時(shí)操作日志是怎么查，在db上還是有專門的日志庫？
管理后臺的操作日志在管理后臺能直接查看，有表進(jìn)行記錄。
錯誤日志和請求日志是通過查看log日志的方式查看的：比如，tail -f xxx.log
另外補(bǔ)充一下：
- cat：用于查看文件的內(nèi)容，可以使用cat filename命令來查看日志文件的內(nèi)容。
- tail：用于查看文件的末尾內(nèi)容，可以使用tail filename命令來實(shí)時(shí)查看日志文件的最新內(nèi)容。
- grep：用于在文件中搜索指定的字符串，可以使用grep pattern filename命令來搜索日志文件中的特定內(nèi)容。
- less：用于分頁查看文件的內(nèi)容，可以使用less filename命令來逐頁查看日志文件的內(nèi)容。
在實(shí)際應(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)行可視化和查詢。
總結(jié)
我個人是覺得上面這些問題比較簡單，比較符合“一年工作經(jīng)驗(yàn)”的求職設(shè)定。
為什么這位朋友會覺得無從下手，說不好呢？究其原因還在于缺少真實(shí)的項(xiàng)目經(jīng)歷。
要么去花時(shí)間惡補(bǔ)項(xiàng)目經(jīng)驗(yàn)，要么找個明白人針對項(xiàng)目多做模擬面試，這才是找工作的正途?？蓜e想著走捷徑。
本文轉(zhuǎn)載自微信公眾號「 程序員升級打怪之旅」，作者「 Shyunn&王中陽Go」，可以通過以下二維碼關(guān)注。
轉(zhuǎn)載本文請聯(lián)系「 程序員升級打怪之旅」公眾號。
分享題目：一年經(jīng)驗(yàn)的后端開發(fā)，在二線城市的求職復(fù)盤
網(wǎng)站地址：http://www.dlmjj.cn/article/dhhsjpi.html
