springboot基于協(xié)同過濾算法的跳蚤市場商品推薦系統(tǒng)去年年底幫一個學弟做的畢業(yè)設計題目就是這個“基于協(xié)同過濾的跳蚤市場商品推薦系統(tǒng)”。他從一開始就沒想清楚自己到底要做什么跟我說“導師讓做一個帶推薦功能的商城”結果需求文檔寫得跟淘寶似的。我聽完就樂了你又沒有淘寶級別的數(shù)據(jù)量搞什么高大上的推薦系統(tǒng)呢。你一個校園二手市場用戶撐死幾百人商品幾千件你用什么深度學習、用什么大模型那都是殺雞用牛刀。協(xié)同過濾這種經典算法正好是這個場景下的最優(yōu)解?；藘芍軙r間從需求梳理、表結構設計到算法落地、接口聯(lián)調最后給他整出來一套完完整整能跑的項目。這中間踩了不少坑也總結了一些經驗今天就把整個項目從頭到尾拆解一遍從技術選型到算法實現(xiàn)從數(shù)據(jù)庫設計到部署上線都寫在這里。無論你是要做畢設、課程設計還是單純想了解推薦系統(tǒng)在真實業(yè)務里怎么落地這篇都值得你耐心看完。1. 項目整體設計與思路拆解1.1 核心需求解析先搞清楚這項目到底是干什么的。跳蚤市場說白了就是二手交易平臺學生把自己閑置的教材、數(shù)碼產品、自行車、吉他掛上去賣其他人看到合適的就買走。核心功能就是商品發(fā)布、瀏覽、下單、訂單管理、個人中心這些這些常規(guī)功能網上一抓一大把沒什么技術含量。真正有技術含量的是“推薦”兩個字。系統(tǒng)要能根據(jù)用戶的歷史行為比如瀏覽過什么、收藏過什么、買過什么主動把當前用戶可能感興趣的商品推送給他。這就是協(xié)同過濾算法的應用場景。那為什么不直接做商品分類篩選而是要做推薦呢原因很簡單跳蚤市場跟淘寶京東不一樣這里沒有海量商家和鋪天蓋地的廣告商品全靠搜索和分類很難被看到。比如某個用戶是一名大二學生他剛學完高數(shù)想賣教材另一個大四學生正好在找這本教材。如果靠傳統(tǒng)搜索兩個人必須先知道對方上傳了什么關鍵詞才能匹配。但推薦系統(tǒng)的作用是當大四學生登錄首頁時系統(tǒng)會主動把他可能需要的教材推給他用戶甚至不用搜索就能看到。推薦在這里的價值就是提升交易匹配效率和用戶粘性。1.2 技術選型背后的考量這套系統(tǒng)我選了Spring Boot 2.7 MyBatis Plus MySQL 8.0 Redis Vue 3作為主技術棧推薦算法部分用Python實現(xiàn)?？吹絇ython可能有人會問既然都用了Java為什么算法不也用Java寫因為我只取算法計算出來的推薦結果通過JSON接口返回給Java后端算法本身和主系統(tǒng)解耦。比如相似度矩陣計算、用戶商品交互數(shù)據(jù)處理這些用Python的pandas處理比Java方便得多開發(fā)效率完全不是一個量級。Spring Boot就不多說了現(xiàn)在做Java后端項目的標配自動配置省掉一大堆繁瑣的XML配置。MyBatis Plus是我個人比較喜歡的一個ORM框架它比原生MyBatis好在單表操作不需要寫SQL代碼生成器一鍵生成實體類和Mapper太香了。MySQL選8.0是因為對JSON數(shù)據(jù)類型的支持更好后面我們會用到。Redis這個很關鍵它承擔兩個任務一是分布式session存儲解決集群部署時的會話共享問題二是緩存熱點數(shù)據(jù)和推薦結果避免每次刷新頁面都重復計算推薦列表。前端用Vue 3加Element Plus這套組合適合后臺管理系統(tǒng)場景對比Vue 2的選項式APIVue 3的組合式API代碼更簡潔邏輯復用也方便。UI框架用Element Plus能快速搭出清爽的管理后臺這活干了這么多年就說句實話做這種帶后臺管理的項目Element Plus比Ant Design Vue上手更快。1.3 算法選型為什么是協(xié)同過濾協(xié)同過濾算法是推薦系統(tǒng)里最經典的算法之一核心思想就一句話人以群分物以類聚。它的實現(xiàn)主要分兩種思路?；谟脩舻膮f(xié)同過濾User-Based CF是先找到和你興趣相似的用戶看看你相似用戶都買過什么把這些商品推薦給你?；谖锲返膮f(xié)同過濾Item-Based CF則是先算出物品之間的相似度然后根據(jù)你之前買過或瀏覽過的東西給你推薦相似的物品。這兩個方案選哪個我在這里選了基于物品的協(xié)同過濾。為什么看一個具體的運營場景你就明白了某用戶在跳蚤市場瀏覽過一本《數(shù)據(jù)結構》教材基于物品協(xié)同過濾就能算出這本《數(shù)據(jù)結構》教材和《算法導論》教材的相似度很高因為經常被同一批用戶一起瀏覽和購買于是推薦算法就會給這個用戶推《算法導論》的二手書。而基于用戶的協(xié)同過濾算法更適合那種用戶量遠大于商品量、用戶興趣標簽明顯的平臺。但跳蚤市場這個場景校園里用戶就千把人商品卻能不斷新增商品之間的相似關系比用戶之間的相似關系穩(wěn)定得多。所以我最終選擇了Item-Based CF作為主力算法。不過這還不夠協(xié)同過濾有兩個繞不開的痛點一個是冷啟動問題新商品沒有任何用戶行為數(shù)據(jù)協(xié)同過濾就算不出它跟其他商品的相似度一個是數(shù)據(jù)稀疏問題跳蚤市場的用戶行為本來就少矩陣稀疏得跟漁網似的。后面實操部分我們會講怎么用數(shù)據(jù)預處理和兜底策略來處理這兩個坑。2. 數(shù)據(jù)庫設計與核心模塊實現(xiàn)2.1 表結構設計的關鍵細節(jié)數(shù)據(jù)庫是一個業(yè)務系統(tǒng)的地基這里的表結構設計花了不少心思。核心表包括用戶表、商品表、訂單表、收藏表、瀏覽記錄表、評分表、推薦結果表。說幾個關鍵設計的細節(jié)。第一個是用戶表。用戶除了常規(guī)的id、用戶名、密碼、昵稱、頭像、手機號、角色之外我特意加了一個字段叫user_type用來區(qū)分買家和賣家身份。有人可能會說跳蚤市場里每個人不都既是買家又是賣家嗎你說得對但實際運營中有一部分用戶就是只買東西不賣東西為了后續(xù)運營分析的便利還是把角色區(qū)分開了。對于既賣又買的用戶這個字段就標記為both。第二個是商品表。關鍵字段有商品標題、描述、價格、原價、成色、分類、圖片、狀態(tài)。其中成色這個字段是跳蚤市場特有的業(yè)務字段是賣家對商品新舊程度的自評一般分成全新、幾乎全新、輕微使用痕跡、明顯使用痕跡、有瑕疵這五檔這個字段在后續(xù)推薦權重計算里會有大用場。狀態(tài)字段是上架中、已下架、已售出三個值查詢時永遠只查上架中的商品。第三個是訂單表。除了常規(guī)的訂單號、買家id、賣家id、商品id、價格、下單時間、支付時間之外我把訂單狀態(tài)細化成了待付款、待發(fā)貨、已發(fā)貨、已完成、已取消、退款中、已退款七個狀態(tài)。都是做電商的為什么訂單狀態(tài)這么細你應該深有體會不細化后面統(tǒng)計經營數(shù)據(jù)的時候哭都來不及。然后是收藏表和瀏覽記錄表。這兩張表是推薦算法最重要的數(shù)據(jù)來源收藏表記錄了用戶對哪些商品感興趣瀏覽記錄表記錄了用戶看過哪些商品、看了多久。這里有個實用的設計經驗瀏覽記錄表不要只存商品id和瀏覽時間我加了一個duration字段記錄用戶在該商品詳情頁停留的秒數(shù)這個數(shù)據(jù)在后續(xù)算用戶興趣權重時非常好用停留時間長的商品說明用戶確實感興趣。評分表的設計也是推薦系統(tǒng)的重頭戲。表面上用戶可以在購買完成后給商品打分1到5分這是顯式反饋數(shù)據(jù)。但跳蚤市場這類平臺用戶主動評分的行為其實很少所以我在設計評分表時把收藏行為、瀏覽行為、購買行為都歸總到一張偏好記錄表里作為隱式評分的數(shù)據(jù)來源這樣協(xié)同過濾算法的輸入數(shù)據(jù)才夠用。最后是推薦結果表。這張表存協(xié)同過濾算法算出來的推薦結果包含用戶id、商品id、推薦分值、推薦時間、推薦來源推薦來源區(qū)分了是基于協(xié)同過濾算出來的還是用了兜底策略算出來的。為什么要存這張表一是為了方便運營人員排查一個用戶為什么看到這些推薦商品二是方便測試對比算法效果再者是避免一次首頁請求就觸發(fā)一次全量推薦計算直接把已經算好的結果查出來返回就行。2.2 Spring Boot后端架構與業(yè)務層實現(xiàn)后端項目用了經典的三層架構Controller層負責接收請求和參數(shù)校驗Service層實現(xiàn)業(yè)務邏輯Mapper層處理數(shù)據(jù)庫交互。為了避免代碼量太龐大導致后期難維護項目做了一點點領域拆分的動作把用戶、商品、訂單、推薦這四個板塊分成獨立的模塊。用戶模塊相對傳統(tǒng)主要就是注冊、登錄、個人信息修改。注冊邏輯里加了一道基礎的校驗比如用戶名是否已存在、密碼強度是否合規(guī)。密碼存儲用了BCrypt加密這是Spring Security框架提供的加密組件比MD5這種已經被撞庫撞爛的算法要安全得多對畢設項目來說這個安全級別是夠的。商品模塊除了最基礎的增刪改查核心邏輯在于發(fā)布商品的流程里做了圖片上傳和價格合理性校驗。圖片上傳這塊我用了本地存儲方案而不是對象存儲服務因為項目還處在學習演示階段沒必要上云。改一下配置文件里的路徑就行上傳的圖片通過WebMvcConfigurer配置的虛擬路徑映射暴露給前端。商品查詢列表做成分頁接口支持按分類篩選、按價格區(qū)間篩選、按關鍵字模糊搜索。這里我用了MyBatis Plus的Page分頁插件配合LambdaQueryWrapper構造動態(tài)查詢條件單個接口能應對多種組合查詢場景。這塊也沒人用ES做搜索數(shù)據(jù)量在這兒擺著呢殺雞不用牛刀。訂單模塊是業(yè)務邏輯最復雜的一塊。核心難點在于訂單狀態(tài)的流轉管理我用了狀態(tài)機模式來約束訂單狀態(tài)的合法流轉比如已發(fā)貨狀態(tài)不能直接跳到已取消必須是已發(fā)貨才能確認收貨變成已完成。這塊的代碼核心是提前把每種狀態(tài)允許跳轉的狀態(tài)集合定義好每次更新狀態(tài)前做合法性校驗這樣一來臟數(shù)據(jù)的問題就能從源頭上杜絕掉。推薦模塊是我重點設計的。推薦接口從Redis緩存里查推薦結果查不到就走數(shù)據(jù)庫里的推薦結果表數(shù)據(jù)庫里也沒有就觸發(fā)實時推薦計算。這個多級緩存的設計思路很實用避免了每次請求都打數(shù)據(jù)庫或者重復計算推薦結果。2.3 前端界面與交互流程前端部分用的是Vue 3加Element Plus做的核心頁面有首頁、商品詳情頁、購物車頁、訂單管理頁、個人中心頁、發(fā)布商品頁、后臺管理頁。首頁分兩部分頂部是推薦位中間是全部商品列表。推薦位是首頁最重要的一塊這部分直接調用后端的推薦接口推薦結果展示成一行商品卡片每張卡片展示商品封面圖、標題、價格、成色標簽。這里我花了點心思被推薦的商品要打一個“猜你喜歡”的角標因為據(jù)我觀察有推薦標簽的商品點擊率明顯高于普通商品這算是利用推薦算法加運營策略提升整體點擊率的一個小技巧。商品詳情頁展示了商品的完整信息包括圖片、描述、成色、賣家信息同時也展示了相關推薦商品相關推薦的數(shù)據(jù)來源還是協(xié)同過濾算出的相似商品。這個功能是基于物品的協(xié)同過濾的直接體現(xiàn)用戶正在看某個商品系統(tǒng)給他推相似商品促使他繼續(xù)瀏覽。訂單流程是這樣的用戶在商品詳情頁點擊“立即購買”會創(chuàng)建一筆待付款訂單支付成功進入待發(fā)貨狀態(tài)賣家發(fā)貨后進入已發(fā)貨狀態(tài)買家確認收貨后訂單完成。另外做了售后服務功能買家可以發(fā)起退款申請賣家同意后訂單狀態(tài)變成已退款。整個交互流程該有的環(huán)節(jié)一個都沒少。后臺管理頁面主要是管理員視角包括用戶管理、商品管理、訂單管理、數(shù)據(jù)統(tǒng)計管理員可以下架違規(guī)商品可以凍結違規(guī)用戶。這個后臺的權限控制用了最基礎的攔截器方案管理員接口統(tǒng)一走/admin路徑攔截器里校驗當前登錄用戶是不是管理員角色。3. 協(xié)同過濾推薦算法的詳細設計與落地3.1 數(shù)據(jù)預處理從原始行為到評分矩陣數(shù)據(jù)預處理是協(xié)同過濾算法工程質量的決定性因素比選擇算法本身還重要。所有推薦算法的輸入都是用戶對物品的評分矩陣但跳蚤市場的原始數(shù)據(jù)里根本沒有現(xiàn)成的評分數(shù)據(jù)全靠我們自己做數(shù)據(jù)加工。我們把用戶對商品的反饋分為幾個等級。收藏行為權重是3分加購物車是4分購買行為是5分瀏覽行為按停留時間折算成0.5到2分。為什么不直接用統(tǒng)一分數(shù)呢這背后的邏輯是一個用戶買了某個商品說明他對這個商品有強興趣這個信號比單純的瀏覽強得多。如果不同強度的行為統(tǒng)一記1分那算法算出來的相似度區(qū)分度就很差。具體的偏好值計算邏輯我寫成了Python的pandas代碼片段這里是核心部分import pandas as pd import numpy as np def build_user_item_matrix(): # 讀取收藏記錄 df_fav pd.read_sql(SELECT user_id, product_id, create_time FROM fav_record, engine) df_fav[action_weight] 3.0 # 讀取加購物車記錄 df_cart pd.read_sql(SELECT user_id, product_id, create_time FROM cart_record, engine) df_cart[action_weight] 4.0 # 讀取購買記錄 df_order pd.read_sql(SELECT buyer_id as user_id, product_id, create_time FROM orders WHERE status已完成, engine) df_order[action_weight] 5.0 # 讀取瀏覽記錄按停留時間折算 df_view pd.read_sql(SELECT user_id, product_id, duration FROM view_record, engine) df_view[action_weight] df_view[duration].apply( lambda x: 0.5 if x 10 else (1.0 if x 30 else 2.0) ) # 合并所有行為并聚合 df_all pd.concat([df_fav[[user_id,product_id,action_weight]], df_cart[[user_id,product_id,action_weight]], df_order[[user_id,product_id,action_weight]], df_view[[user_id,product_id,action_weight]]], ignore_indexTrue) df_score df_all.groupby([user_id,product_id])[action_weight].sum().reset_index() df_score[action_weight] df_score[action_weight].clip(upper10) # 透視成用戶-商品矩陣 matrix df_score.pivot_table(indexuser_id, columnsproduct_id, valuesaction_weight) matrix matrix.fillna(0) return matrix看著代碼不難實際踩過的坑是在寫入推薦結果表的時候如果用戶行為特別多全量寫入的耗時就會比較長容易把接口拖垮。所以我把離線計算和接口請求做了解耦離線計算出的推薦結果由后臺任務寫入推薦結果表接口只做查詢動作。這個等下面部署部分詳細說。3.2 Item-Based協(xié)同過濾的相似度計算基于物品的協(xié)同過濾核心分兩步第一步算物品之間的相似度矩陣第二步根據(jù)用戶歷史行為把相似度高的物品推薦給用戶。物品相似度的計算方式有很多種最常見的有余弦相似度、皮爾遜相關系數(shù)、Jaccard相似度。我這里用的是余弦相似度因為這個指標計算簡單效果穩(wěn)定對數(shù)據(jù)稀疏場景的容忍度也相對更高。余弦相似度的公式看著抽象但其實通俗解釋一下就是兩個向量夾角的余弦值夾角越小說明兩個向量越相似。放在場景里理解就是計算兩件商品被同一群用戶產生過行為的一致程度。比如商品A被用戶甲、乙、丙瀏覽或購買過商品B也被用戶甲、乙、丙瀏覽或購買過那么這兩件商品的向量就很接近相似度就高。在Python里計算也很簡單直接調用scikit-learn庫的pairwise_distances函數(shù)就能得到物品之間的相似度矩陣。from sklearn.metrics.pairwise import cosine_similarity # 矩陣轉置變成商品-用戶的矩陣行列原來是用戶-商品 item_matrix matrix.T # 計算商品之間的余弦相似度 item_similarity cosine_similarity(item_matrix) # 轉成DataFrame便于處理 item_sim_df pd.DataFrame(item_similarity, indexitem_matrix.index, columnsitem_matrix.index)算完相似度矩陣后關鍵一步是做相似商品的篩選。一刀切地把所有相似商品都算作候選是不行的一定要設置相似度閾值做過濾我用的閾值是0.5低于0.5的相似度不參與推薦。同時每個商品的相似商品最多保留Top 20。這里控制一下計算量和推薦精度不然相似度矩陣全量算下來容易內存爆炸。3.3 生成推薦列表的核心邏輯有了物品相似度矩陣接下來就是為用戶生成Top N的推薦列表了。核心邏輯是找出用戶最近有過正反饋行為的商品然后去相似度矩陣里找出這些商品的相似商品按相似度加權求和排個序取前N個。我在實現(xiàn)的時候專門加了一個時間衰減函數(shù)。理由是跳蚤市場這類平臺用戶在一個月前瀏覽過的商品和昨天剛瀏覽過的商品在當前時刻的興趣權重不應該是一樣的。時間衰減函數(shù)距離今天越近的行為權重越高越久遠的行為權重越低用指數(shù)衰減來模擬這個規(guī)律效果明顯好于不衰減的方案。核心代碼是這一段import math from datetime import datetime def generate_recommendations(user_id, user_item_matrix, item_sim_df, top_n10, decay_factor0.98): # 用戶歷史行為 if user_id not in user_item_matrix.index: return [] user_row user_item_matrix.loc[user_id] # 找出用戶有行為的商品 interacted_items user_row[user_row 0].index.tolist() if not interacted_items: return [] # 計算每個候選商品的推薦得分 scores {} for item in interacted_items: # 獲取當前商品相似度最高的幾個商品 sim_scores item_sim_df[item].drop(labelsinteracted_items, errorsignore) sim_scores sim_scores[sim_scores 0.5].sort_values(ascendingFalse)[:20] # 用戶對當前商品的興趣強度 user_interest user_row[item] for sim_item, sim_value in sim_scores.items(): if sim_item not in user_row or user_row[sim_item] 0: scores[sim_item] scores.get(sim_item, 0) user_interest * sim_value # 按得分排序取TopN ranked sorted(scores.items(), keylambda x: x[1], reverseTrue)[:top_n] return ranked還記得前面對瀏覽記錄做了時長折算嗎在這里就用上了瀏覽時間長的商品user_interest值高一些直接影響推薦得分這樣用戶只看了一眼的商品就不會成為推薦的主參考而認認真真看了五分鐘的商品則會成為主參考。這個細節(jié)不算很難但就是這些細節(jié)決定了算法的推薦質量是普通水平還是相對優(yōu)良。運營的A同學做了測試同一個用戶用帶時間衰減和不帶時間衰減兩版算法跑出來的結果第一屏的推薦商品準確率差了大概15%。很直觀的效果差異。3.4 冷啟動問題的兜底方案協(xié)同過濾算法最惡心的坑就是冷啟動。系統(tǒng)剛上線商品和用戶行為數(shù)據(jù)都很少矩陣稀疏到幾乎每行每列都是0這時候算法就算跑出來結果也基本等于瞎推薦。冷啟動分為用戶冷啟動和物品冷啟動。新注冊的用戶沒有任何行為數(shù)據(jù)推薦算法拿什么算相似度新上架的商品沒有任何人看過買過相似度矩陣里它跟誰都不相似。我的兜底方案分了三層來做。第一次兜底對于完全沒有行為數(shù)據(jù)的新用戶直接推薦平臺的熱門商品。熱門商品怎么定義就是最近7天瀏覽次數(shù)最多、收藏次數(shù)最多的商品按權重排序取前20個。這個策略簡單粗暴但極其有效新用戶進來看到大家都在看的商品至少不會覺得推薦完全不相關。第二次兜底對于有少量行為的用戶如果行為數(shù)據(jù)不足以支撐協(xié)同過濾就用基于內容的推薦方式。具體實現(xiàn)是將商品分成若干個分類比如“教材教輔”、“數(shù)碼產品”、“生活用品”、“運動戶外”等然后對用戶瀏覽過的商品類別做統(tǒng)計找出用戶最感興趣的Top3品類在這些品類下按價格、熱度綜合排序推薦一些好商品。這套基于內容的方案原理不復雜但實現(xiàn)后對冷啟動用戶的推薦效果立竿見影。第三次兜底新上架的商品在新品期內也就是上架后72小時內在推薦結果里做一個加權操作。具體做法是給新商品一個初始曝光權重這樣它們在用戶生成個性化推薦列表時有機會被帶上。雖然新商品沒有協(xié)同過濾的相似度數(shù)據(jù)但我們可以在Item-Based協(xié)同過濾的基礎上額外附加一批新商品推薦設置20%的推薦位留給這類商品。這樣就同時照顧了用戶體驗和新品曝光。這三層兜底方案加起來的實現(xiàn)成本不高但對整個系統(tǒng)的推薦可用性提升是決定性的。沒有兜底方案的推薦系統(tǒng)在早期階段基本是廢的。4. 熱門問題與性能優(yōu)化實錄4.1 推薦結果不準確怎么辦在調這個系統(tǒng)時被問得最多的問題就是推薦結果不準推出來的商品用戶根本不想看。這類問題基本可以按下面的思路逐層排查。第一步先檢查數(shù)據(jù)量。如果用戶行為記錄不到50條那協(xié)同過濾效果不好是正常的沒有足夠的歷史數(shù)據(jù)任何推薦算法都白搭。解決辦法是用前面說的兜底策略優(yōu)先走熱門推薦或基于內容推薦。第二步檢查評分矩陣的稀疏度。要算一個數(shù)據(jù)指標矩陣中非零元素占總元素的比例如果低于1%那協(xié)同過濾的效果就會打折。跳蚤市場數(shù)據(jù)天生稀疏解決辦法是對行為數(shù)據(jù)進行加權比如購買過的商品權重調高到5分瀏覽只有1分提高強信號數(shù)據(jù)的占比。第三步檢查相似度閾值。我默認設置0.5但這個值不是固定的。如果發(fā)現(xiàn)推薦的相似商品太少可以適當降低到0.3如果推薦的相似商品明顯沒多大相關性就調高到0.6。這個參數(shù)需要在不同數(shù)據(jù)集上反復試驗。第四步看推薦結果表的兜底來源占比。我們每一條推薦記錄都帶一個來源字段如果發(fā)現(xiàn)大量推薦走的都是熱門推薦而不是協(xié)同過濾說明協(xié)同過濾的有效覆蓋率不足需要針對性排查是數(shù)據(jù)稀疏還是相似度矩陣計算錯誤。4.2 Redis緩存與接口響應優(yōu)化推薦接口和首頁接口是性能考量的重中之重。首頁接口要聚合推薦商品、熱門商品、最新商品等多個數(shù)據(jù)源如果沒有緩存數(shù)據(jù)庫壓力會非常大。我用Redis做了一個兩級緩存的方案。第一級緩存存推薦商品的Id列表Key設計成recommend:user:{userId}有效時間設成了30分鐘。為什么是30分鐘而不是更長因為推薦結果如果太久不更新用戶每次打開看到的東西都一模一樣時間長了就會產生審美疲勞30分鐘算是一個兼顧實時性和緩存命中率的折中值。第二級緩存存了商品本身的詳細信息Key設計成product:info:{productId}有效時間設成2小時。第一級緩存存儲推薦id列表第二級緩存存儲商品詳細信息。三級緩存把商品詳情從數(shù)據(jù)庫里挪到Redis里商品詳情的查詢壓力大幅下降實測下來首頁的接口響應時間從150毫秒降到了50毫秒以下流暢度大幅提升。還有一點要注意的細節(jié)修改商品信息、下架商品時必須同步刪除對應的商品緩存不然用戶看到的還是舊的商品信息這就是經典的一致性維護問題。我實現(xiàn)方式是在商品更新的Service方法里統(tǒng)一調用Redis刪除操作寧多刪勿漏刪。4.3 并發(fā)扣減庫存與訂單一致性跳蚤市場和常規(guī)電商有一個本質區(qū)別每件商品只有一個庫存量。這意味著如果兩個用戶同時下單購買同一個商品只能有一個人成功另一個人必須收到“手慢了商品已被購買”的提示。如果只是減庫存不加控制用常規(guī)的先查庫存再更新庫存的方式高并發(fā)場景下就會產生超賣問題。兩個請求同時查到庫存是1都判斷可以買都執(zhí)行了下單最后庫存變成-1這就是超賣。解決辦法是用數(shù)據(jù)庫行鎖配合樂觀鎖。在扣減庫存時執(zhí)行一條帶條件更新的SQL語句只有當前庫存大于0時才允許扣減同時受影響的行數(shù)為1才代表更新成功沒成功就說明已經被別人搶了。UPDATE product SET stock stock - 1 WHERE id #{productId} AND stock 0MyBatis加不加Transactional這個細節(jié)也要留意。扣減庫存、創(chuàng)建訂單這兩個操作必須加事務任何一個失敗都要回滾保證數(shù)據(jù)一致性。這段代碼是整個訂單流程里最容易出bug的地方一定要把單元測試寫好模擬并發(fā)場景反復壓測。4.4 定時任務與離線計算調優(yōu)推薦結果的計算不需要實時跑更合理的做法是定時任務離線計算。我用了Spring Boot內置的Scheduled注解實現(xiàn)定時任務固定在每天凌晨3點全量計算一次這個時間點服務器負載最低。每天凌晨計算的是全量推薦結果寫入推薦結果表。另外內部做了一套增量計算邏輯每30分鐘計算一次只算最近30分鐘內有新行為數(shù)據(jù)的那些用戶更新他們的推薦結果保證推薦列表的時效性。兩套計算邏輯配合起來全量保證數(shù)據(jù)基礎增量保證實時反饋服務器壓力也不會太大。離線計算的核心數(shù)據(jù)結構是物品相似度矩陣全量計算時我會把它序列化保存到本地文件。增量計算時加載這個相似度矩陣只更新行為發(fā)生變化的用戶避免每次都要全量重新加載所有數(shù)據(jù)。這個優(yōu)化直接把定時任務的平均執(zhí)行時間從十幾分鐘壓到了幾分鐘。5. 部署上線與運營落地5.1 項目部署與安全合規(guī)部署方案選了一臺2核4G的云服務器Linux系統(tǒng)。后端項目打成JAR包通過systemd配置成守護進程開機自啟加崩潰自動重啟。前端用Nginx托管靜態(tài)文件后端接口用反向代理映射到域名路徑下Nginx是前端構建產物最經典的托管方案后端接口也走Nginx代理順便解決跨域問題。Java啟動參數(shù)里-Xms和-Xmx設為512m配合上G1垃圾回收器。2核4G的服務器配置跑這套系統(tǒng)完全可以駕馭實測并發(fā)在50左右時CPU占用率大約40%響應延遲在100毫秒內對校園場景來說綽綽有余。這里要多提一句合規(guī)問題。一個跳蚤市場交易平臺不管規(guī)模大小該做的合規(guī)操作一樣不能少用戶實名注冊手機號驗證碼校驗必須有商品發(fā)布要做敏感詞過濾違規(guī)內容條目要提前準備交易糾紛要有申訴機制和客服入口。我特別提醒了學弟平臺方對發(fā)布違禁品的用戶要及時警告和處理這些不是可選項而是必選項。隱私數(shù)據(jù)這塊用戶的手機號和地址在數(shù)據(jù)庫里需要做加密存儲日志打印也要脫敏處理。5.2 數(shù)據(jù)冷啟動后的運營節(jié)奏系統(tǒng)剛上線的最初兩周是冷啟動期數(shù)據(jù)量自然是很貧乏的。這個階段推薦系統(tǒng)的核心任務不是算法優(yōu)化而是制造初始數(shù)據(jù)。我的做法是在正式運營前先導入一批模擬數(shù)據(jù)。用Python的Faker庫生成模擬用戶、模擬商品、模擬瀏覽和模擬購買記錄大概構造成500個用戶、2000件商品、3萬條行為數(shù)據(jù)。這波操作對冷啟動階段的推薦系統(tǒng)至關重要——協(xié)同過濾算法的效果和輸入數(shù)據(jù)的規(guī)模強相關沒有這批模擬數(shù)據(jù)系統(tǒng)上線后運行一整周也未必能收集到足以支撐算法的數(shù)據(jù)量也就談不上推薦效果。這些模擬數(shù)據(jù)的生成不是隨機亂造的要符合跳蚤市場的業(yè)務規(guī)律。比如大四學生購買英語考研資料的記錄相對集中大二學生瀏覽高數(shù)教材的記錄多一些這樣人為構造出幾類標簽清晰的用戶群體協(xié)同過濾才有足夠的行為交集可以計算推薦結果才能顯得相對合理。6. 常見問題排查與避坑指南微服務權限管理系統(tǒng)是這幾年非常經典的一套畢業(yè)設計選題但我見過太多人把它做成純粹的CRUD后臺那樣反而顯得沒深度。我這套跳蚤市場系統(tǒng)的設計思路不一樣它的加分項在于推薦算法的運用——不是給用戶堆功能頁面而是把底層算法和業(yè)務系統(tǒng)結合成一個整體。最近有學弟問這套系統(tǒng)能不能擴充成校園綜合二手教學系統(tǒng)這個想法完全可以做把商品對象抽象成類型字段加上閑置教材、尋求輔導、尋找拼車伙伴這些業(yè)務場景就能復用現(xiàn)成框架。完成一個基礎版本之后還可以繼續(xù)優(yōu)化算法參數(shù)調整、重構相似度計算、引入更細的行為權重策略等持續(xù)打磨細節(jié)比推倒重來做花哨的新功能要更值錢。復盤自己這幾年做過的項目有推薦算法的價值感確實會高很多這類系統(tǒng)在面試考察中對項目深度的體現(xiàn)非常加分。最后分享一個排查問題的技巧。有用戶反饋推薦列表刷不出來我的排查思路按這個順序進行先看請求有沒有打到后端是用瀏覽器開發(fā)者工具的Network面板看的再查Redis里有沒有緩存數(shù)據(jù)用tkey的命令然后查數(shù)據(jù)庫推薦結果表有沒有數(shù)據(jù)最后看定時任務日志有沒有正常執(zhí)行。查了幾次就發(fā)現(xiàn)是定時任務在數(shù)據(jù)量大的時候執(zhí)行超時任務被跳過導致推薦結果表沒有更新。解決方式是給定時任務加一個分布式鎖同時把全量計算改成增量計算這個問題就徹底解決了。如果打開一篇文章到這里你正在為推薦系統(tǒng)相關的項目發(fā)愁這套思路和代碼實現(xiàn)完全可以復用到你自己的業(yè)務場景里核心是掌握“數(shù)據(jù)預處理 - 相似度計算 - 推薦生成 - 兜底策略”這條主線邏輯剩下的都只是實現(xiàn)細節(jié)問題。