每年一到做項目的旺季總有人問“Spring Boot旅游景點推薦管理系統(tǒng)”該怎么做。大多數(shù)人第一反應(yīng)是景點表加用戶表套幾個增刪改查接口再寫個前臺頁面和后臺管理頁這不就完了話是沒錯但你要是真照著這個思路做下去交付出來的大概率只是一個大號管理系統(tǒng)離標題里“推薦”這兩個字差了十萬八千里。這篇文章就以Spring Boot MyBatis-Plus MySQL Redis這套主流技術(shù)組合為例把這個系統(tǒng)的設(shè)計思路、數(shù)據(jù)庫建模、推薦算法落地、后臺管理和上線前后的優(yōu)化完整拆一遍。項目我已經(jīng)實際開發(fā)過一輪也踩過不少坑下面這些內(nèi)容基本屬于“照著做就能少走一半彎路”的程度。如果你正在做類似選題或想把普通CRUD項目升級成帶推薦能力的完整產(chǎn)品這篇可以直接當參考。1. 需求拆解與整體架構(gòu)設(shè)計1.1 項目到底要解決什么問題很多同學(xué)拿到“旅游景點推薦管理系統(tǒng)”這個題目第一件事就是打開數(shù)據(jù)庫工具建表這是典型的順序搞反。一個項目能不能站得住腳不在于表建得多花哨而在于需求有沒有被真正拆透。這個標題里藏著三個角色游客、運營人員和管理員。游客要的是“打開系統(tǒng)后不用費勁搜索系統(tǒng)能主動告訴我哪些地方適合我”運營要的是“把優(yōu)質(zhì)景點推給合適的人最終提升收藏量、評論量和到訪量”管理員要的是“景點信息維護、分類調(diào)整、用戶管理、評論審核這些日常工作能在一個后臺里高效完成”。一句話總結(jié)推薦不是錦上添花而是系統(tǒng)的核心業(yè)務(wù)能力。它要解決的是旅游信息過載的問題——當用戶面對成百上千個景點時如何快速篩出他最可能感興趣的若干條。再往細了說推薦功能不是拍腦袋從數(shù)據(jù)庫里隨機撈幾條數(shù)據(jù)展示給用戶。它至少需要覆蓋四個場景新用戶注冊進來系統(tǒng)還沒有他的行為數(shù)據(jù)怎么推薦老用戶瀏覽收藏過一些景點系統(tǒng)怎么根據(jù)他的歷史行為推薦新內(nèi)容一個景點發(fā)布很久了瀏覽量高但收藏轉(zhuǎn)化低怎么處理同一個分類下一次性推太多內(nèi)容用戶看膩了怎么辦這些場景如果能在設(shè)計階段就想清楚后面的開發(fā)就會非常順。反之等代碼寫了一半再去思考“推薦”到底是什么多半只能拿熱門榜單糊弄過去。1.2 前端與后端的功能邊界怎么劃分這個系統(tǒng)我建議采用前后端分離的結(jié)構(gòu)后端統(tǒng)一提供RESTful接口前端獨立部署。原因不復(fù)雜旅游系統(tǒng)的用戶端需要頻繁調(diào)整展示樣式和交互方式管理端又要面對復(fù)雜表單和多維度的篩選條件兩者風(fēng)格差異很大硬耦合在一起會非常難受。用戶端的功能列表大致是這樣的注冊、登錄、個人偏好設(shè)置景點分類瀏覽、關(guān)鍵詞搜索、多條件篩選景點詳情頁包含圖片、介紹、開放時間、票價等收藏景點、發(fā)表評論、瀏覽歷史記錄首頁推薦、分類推薦、附近推薦管理端的功能列表相對更集中景點信息的增刪改查、上下架管理景點分類的樹形結(jié)構(gòu)維護用戶賬號的管理與禁用評論內(nèi)容的審核與刪除數(shù)據(jù)看板訪問量、收藏量、推薦位點擊量等核心指標推薦位的運營配置比如設(shè)置熱門景點和置頂內(nèi)容技術(shù)選型上后端我用Spring Boot MyBatis-Plus數(shù)據(jù)庫MySQL緩存Redis權(quán)限認證用JWT。這套組合的好處在于生態(tài)成熟、上手資料多、出了問題容易排查而且MyBatis-Plus能把單表CRUD代碼量壓縮一大半把精力省下來放到推薦算法實現(xiàn)上性價比非常高。1.3 一次完整請求的鏈路理清鏈路比寫代碼更重要。以“首頁推薦列表”為例一次請求會經(jīng)過這樣一條路瀏覽器發(fā)起請求Nginx轉(zhuǎn)發(fā)給后端網(wǎng)關(guān)網(wǎng)關(guān)先校驗JWT合法后進入ControllerController調(diào)用推薦ServiceService先查Redis緩存緩存沒有則查數(shù)據(jù)庫數(shù)據(jù)庫返回后按照推薦規(guī)則組合數(shù)據(jù)最后包裝成統(tǒng)一格式返回給前端。這條鏈路里最需要注意的有三點。第一權(quán)限校驗要前置不能等業(yè)務(wù)代碼執(zhí)行完再判斷。第二緩存和數(shù)據(jù)庫的讀取順序要統(tǒng)一避免出現(xiàn)“先查庫再回填緩存”和“先查緩存再查庫”兩種邏輯并存的情況。第三接口返回值必須一套格式前端才能統(tǒng)一處理否則一個項目里幾百個接口各自返回不同結(jié)構(gòu)聯(lián)調(diào)階段會讓你懷疑人生。這里提前說一下我見過不少人把推薦接口直接做成“查景點表按瀏覽量排序”然后把熱門榜標成推薦。這不是推薦這是列表排序。真正的推薦系統(tǒng)即使第一版很簡單也要包含用戶行為和內(nèi)容特征的采集這部分在第3章我會詳細展開。2. 數(shù)據(jù)庫建模核心表結(jié)構(gòu)與建模細節(jié)2.1 用戶、景點、分類三類基礎(chǔ)表數(shù)據(jù)庫設(shè)計是這個系統(tǒng)中最不能圖快的環(huán)節(jié)。一張表少一個字段后期補起來就得改代碼、寫數(shù)據(jù)遷移腳本成本成倍上升。我的建議是建表之前先把業(yè)務(wù)對象完整盤一遍。用戶表是最簡單的基本字段如下CREATE TABLE tb_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL COMMENT 登錄賬號, password VARCHAR(100) NOT NULL COMMENT BCrypt加密后的密碼, nickname VARCHAR(50) DEFAULT COMMENT 昵稱, avatar VARCHAR(255) DEFAULT COMMENT 頭像地址, gender TINYINT DEFAULT 0 COMMENT 0未知 1男 2女, city VARCHAR(50) DEFAULT COMMENT 常駐城市, preference_tags VARCHAR(255) DEFAULT COMMENT 偏好標簽逗號分隔, status TINYINT DEFAULT 1 COMMENT 1正常 0禁用, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );密碼不要用MD5MD5撞庫太容易了直接用Spring Security提供的BCryptPasswordEncoder安全性高一個檔次。preference_tags這個字段很關(guān)鍵它在用戶注冊時收集一次后續(xù)會作為內(nèi)容推薦的種子數(shù)據(jù)所以設(shè)計時要預(yù)留充足長度。景點表是信息量最大的表。這里我建議把圖片字段拆開封面圖一個字段詳細圖集一個字段用JSON字符串存URL數(shù)組避免為了多張圖片單獨建一張子表導(dǎo)致查詢復(fù)雜度上升。CREATE TABLE tb_scenic ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL COMMENT 景點名稱, category_id BIGINT NOT NULL COMMENT 所屬分類, province VARCHAR(30) DEFAULT COMMENT 省份, city VARCHAR(30) DEFAULT COMMENT 城市, address VARCHAR(255) DEFAULT COMMENT 詳細地址, cover_url VARCHAR(255) DEFAULT COMMENT 封面圖, images TEXT COMMENT 圖集JSON數(shù)組, price DECIMAL(10,2) DEFAULT 0.00 COMMENT 票價, score DECIMAL(3,1) DEFAULT 0.0 COMMENT 評分, open_time VARCHAR(50) DEFAULT COMMENT 開放時間, description TEXT COMMENT 詳細介紹, view_count INT DEFAULT 0 COMMENT 瀏覽量, fav_count INT DEFAULT 0 COMMENT 收藏量, comment_count INT DEFAULT 0 COMMENT 評論量, weight INT DEFAULT 100 COMMENT 人工權(quán)重運營可調(diào), status TINYINT DEFAULT 0 COMMENT 0下架 1上架, is_hot TINYINT DEFAULT 0 COMMENT 是否熱門, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );weight字段是運營給景點設(shè)置的“人工推薦力度”優(yōu)先級高于算法自動計算的分數(shù)。這個字段會直接參與推薦結(jié)果的排序后面講算法時會用到。分類表用樹形結(jié)構(gòu)設(shè)計不做枚舉。原因是旅游景點的分類粒度經(jīng)常會調(diào)整比如“自然風(fēng)光”下面可能要拆出“山岳”“湖泊”“森林”用枚舉寫死在代碼里運營每次想調(diào)整都得找開發(fā)改版本極不友好。CREATE TABLE tb_category ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, parent_id BIGINT DEFAULT 0 COMMENT 父分類ID, sort INT DEFAULT 0 COMMENT 排序號 );2.2 用戶行為數(shù)據(jù)怎么存推薦系統(tǒng)需要的用戶行為數(shù)據(jù)主要有三類收藏、評論、瀏覽記錄。這些數(shù)據(jù)不僅是頁面上展示的功能更是推薦算法判斷用戶興趣最重要的依據(jù)。收藏表要注意唯一索引防止同一個用戶重復(fù)收藏同一個景點CREATE TABLE tb_favorite ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, scenic_id BIGINT NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_user_scenic (user_id, scenic_id) );評論表用自關(guān)聯(lián)設(shè)計支持回復(fù)功能CREATE TABLE tb_comment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, scenic_id BIGINT NOT NULL COMMENT 景點ID, user_id BIGINT NOT NULL COMMENT 評論人ID, content VARCHAR(500) NOT NULL COMMENT 評論內(nèi)容, parent_id BIGINT DEFAULT 0 COMMENT 回復(fù)的評論ID0表示頂評, like_count INT DEFAULT 0 COMMENT 點贊數(shù), status TINYINT DEFAULT 1 COMMENT 1顯示 0隱藏, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );瀏覽記錄表是推薦算法訓(xùn)練的核心數(shù)據(jù)源。用戶點擊了哪個景點、停留了多久這些信息比用戶自己填寫的偏好標簽更真實。設(shè)計上不要做物理刪除保留全部歷史記錄后續(xù)如果要升級推薦策略這些原始數(shù)據(jù)就是最寶貴的資產(chǎn)。CREATE TABLE tb_browse_history ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, scenic_id BIGINT NOT NULL, browse_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_user_browse (user_id, browse_time) );我開發(fā)的時候在瀏覽記錄表上加了聯(lián)合索引 idx_user_browse因為之后查“某用戶最近看過的景點”非常多沒這個索引數(shù)據(jù)只要上萬條查詢延遲立刻翻好幾倍。2.3 建模時最常見的幾個坑第一個是時間字段類型。有人圖省事用VARCHAR存字符串時間結(jié)果排序和區(qū)間查詢?nèi)砍鰡栴}。時間字段一律用DATETIME且建表時設(shè)置默認值CURRENT_TIMESTAMP更新時用ON UPDATE CURRENT_TIMESTAMP自動刷新。第二個是價格字段。景區(qū)票價一定會打折、改價用FLOAT或DOUBLE存儲會造成精度丟失必須用DECIMAL(10,2)。第三個是狀態(tài)字段。景點表的status是上下架狀態(tài)user表的status是賬號狀態(tài)評論表的status是顯示狀態(tài)不要偷懶省字段。推薦接口條件里永遠要帶著status判斷避免把下架景點和隱藏評論推給用戶。第四個是跟地理位置有關(guān)的字段。如果要實現(xiàn)“附近景點推薦”經(jīng)緯度字段必須在設(shè)計階段預(yù)留后面再加字段還要同步更新歷史數(shù)據(jù)非常折騰。3. 推薦引擎的四種落地算法3.1 冷啟動新用戶進系統(tǒng)先推薦什么推薦系統(tǒng)第一個繞不開的問題就是冷啟動。用戶剛注冊行為表里空空如也這時候給任何精確的個性化推薦都沒有數(shù)據(jù)支撐。我的方案是“城市優(yōu)先 熱門兜底 隨機打散”三層遞進。第一層根據(jù)用戶注冊時填寫的城市字段篩選出該城市的景點。第二層同一城市內(nèi)將景點按熱度分值排序但不要全部按分數(shù)降序。第三層在熱門景點中做隨機擾動保證每次推薦列表都不完全一樣。具體來說熱度分我放在Redis里維護用一個ZSet存儲。Score的計算可以先用一個簡單公式熱度分 瀏覽量 0.3 收藏數(shù) 0.5 評論數(shù) 0.2。運營手動加權(quán)的景點在Score基礎(chǔ)上再加上weight值。實現(xiàn)時我會維護一個定時任務(wù)每30分鐘重新計算一次全量景點的熱度分并寫回Redis。新用戶進入首頁時后端接口直接從Redis里讀取該城市熱度最高的前10個景點加上隨機偏移量返回。這套邏輯代碼量不大但效果立竿見影。用戶打開系統(tǒng)第一眼看到的是自己所在城市的熱門景點推薦的可接受度遠高于全國范圍的隨機內(nèi)容。3.2 基于標簽的內(nèi)容推薦可解釋性最強當用戶產(chǎn)生了瀏覽、收藏行為后推薦系統(tǒng)就能開始“學(xué)習(xí)”興趣了。第一種推薦策略是基于標簽的內(nèi)容推薦核心思路是找出用戶喜歡過景點的共同標簽然后推薦帶這些標簽的其他景點。這個策略在旅游場景下特別管用。比如用戶收藏過“西湖”“烏鎮(zhèn)”很容易推斷出他對“江南水鄉(xiāng)”和“自然風(fēng)光”這類標簽感興趣。系統(tǒng)再推送同類標簽下的其他景點解釋起來也自然“因為你喜歡江南水鄉(xiāng)類景點為你推薦以下內(nèi)容”。實現(xiàn)時我給每個景點關(guān)聯(lián)分類ID。用戶在收藏或瀏覽景點后給該景點所屬分類累加權(quán)重。分類權(quán)重的計算放在用戶表或單獨一張用戶偏好表里。定期執(zhí)行標簽權(quán)重更新任務(wù)把結(jié)果存到Redis或一張user_tag_weight表里查詢時直接取出Top5分類然后在景點表里按這些分類做召回最終用熱度分排序。 這個方案理解成本低代碼量少效果也不差。我這里給出一段簡化的后端Service代碼供參考public ListScenic recommendByTag(Long userId) { // 獲取用戶興趣標簽權(quán)重key為分類IDvalue為權(quán)重 MapLong, Integer tagWeight userTagService.getUserTagWeight(userId); if (tagWeight.isEmpty()) { return getHotScenicListByCity(cityOf(userId), 20); } ListLong categoryIds new ArrayList(tagWeight.keySet()); // 按分類召回待候選的景點池 ListScenic candidateList scenicMapper.selectByCategoryIds(categoryIds); // 按熱度人工權(quán)重綜合排序取前20 return candidateList.stream() .sorted(Comparator.comparing(this::hotScore).reversed()) .limit(20) .collect(Collectors.toList()); }3.3 基于用戶的協(xié)同過濾從行為里找相似用戶基于標簽內(nèi)容推薦有一個缺陷它只能推薦與用戶歷史興趣相似的景點容易讓人停留在“舒適區(qū)”。這時就要用到協(xié)同過濾它解決的是“發(fā)現(xiàn)新興趣”的問題。協(xié)同過濾的基本思想是找與你行為模式相似的用戶把那些用戶喜歡但你還沒看過的景點推薦給你。我在這個項目里用的是最簡單的基于用戶的協(xié)同過濾而且做出了適合課程設(shè)計和中小型項目落地的方式。第一步從收藏表和瀏覽記錄表拉取所有用戶-景點行為矩陣。第二步計算當前用戶與其他用戶的行為相似度這里我采用Jaccard系數(shù)兩個用戶收藏景點的交集數(shù)量除以兩個用戶收藏景點的并集數(shù)量。第三步找出最相似的N個用戶他們收藏過但當前用戶未收藏的景點作為候選。第四步對候選景點按熱門程度和相似用戶的數(shù)量加權(quán)生成推薦列表。這個過程的計算量集中在第二步所以生產(chǎn)環(huán)境不能實時計算。我在項目中采用離線計算策略每日凌晨定時任務(wù)跑一次相似用戶計算把結(jié)果寫入RedisKey為 userId:similar_usersValue是相似用戶ID列表。用戶請求推薦時會直接讀取這些列表再動態(tài)召回景點數(shù)據(jù)。下面是相似度計算的簡化邏輯public ListUserSimilarity calcSimilarity(Long userId, ListUserItem allUsers) { SetLong myItems getFavoriteScenicIds(userId); ListUserSimilarity result new ArrayList(); for (UserItem other : allUsers) { if (other.getUserId().equals(userId)) continue; SetLong otherItems other.getItemIds(); // Jaccard系數(shù) double intersection myItems.stream().filter(otherItems::contains).count(); double union myItems.size() otherItems.size() - intersection; if (union 0) continue; result.add(new UserSimilarity(other.getUserId(), intersection / union)); } result.sort(Comparator.comparingDouble(UserSimilarity::getScore).reversed()); return result.stream().limit(10).collect(Collectors.toList()); }3.4 熱度衰減與多樣性控制推薦的最后一公里是排序和打散。如果一個景點發(fā)布后熱度一直靠前它就會永久霸榜導(dǎo)致新景點永遠沒有出頭之日。所以熱度分一定不能是單純的累加值需要引入時間衰減。我在項目里用的是類似評論排序的公式熱度分 (瀏覽量 0.3 收藏數(shù) 0.5 評論數(shù) 0.2) / pow((發(fā)布至今的小時數(shù) 2), 1.5)這個公式的含義就是內(nèi)容發(fā)布越久分母越大熱度分會自然衰減。而瀏覽量等指標越高的內(nèi)容抗衰減能力越強保證真正優(yōu)質(zhì)的內(nèi)容依然能留在榜單上。另外推薦結(jié)果的多樣性也要控制。如果推薦列表里8個景點全部是“山水自然”用戶第一時間就會覺得系統(tǒng)只會做一種推薦。我的方案是同一分類下的推薦結(jié)果最多占列表數(shù)量的30%超過的部分用下一分類候補替換。實現(xiàn)時我維護一個HashMap記錄每個分類已經(jīng)出現(xiàn)的次數(shù)按熱度分降序遍歷候選景點當某個分類名額已滿就跳過直到選滿推薦列表長度。4. 后端核心業(yè)務(wù)接口實現(xiàn)4.1 統(tǒng)一返回格式與全局異常處理開發(fā)過程中最影響體驗的事情之一就是接口返回格式不統(tǒng)一。有的接口返回直接是List有的返回對象有的報錯時返回一段字符串到了前端聯(lián)調(diào)階段全是麻煩。我在設(shè)計接口時要求所有返回都走同一個Result統(tǒng)一封裝類。Data public class ResultT { private Integer code; private String message; private T data; private Long timestamp; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); result.setTimestamp(System.currentTimeMillis()); return result; } public static T ResultT error(Integer code, String message) { ResultT result new Result(); result.setCode(code); result.setMessage(message); result.setTimestamp(System.currentTimeMillis()); return result; } }為了統(tǒng)一處理業(yè)務(wù)報錯我會配合一個全局異常處理器讓不同錯誤類型返回不同的狀態(tài)碼。比如參數(shù)校驗失敗返回400未登錄返回401無權(quán)限返回403服務(wù)器異常返回500。前端只判斷Result的code字段即可不用到處寫try catch處理不同的異常結(jié)構(gòu)。4.2 景點檢索接口搜索、篩選、分頁景點列表接口是使用頻率最高的接口之一。用戶在首頁搜索框里輸入關(guān)鍵詞或者在分類頁勾選城市、價格區(qū)間、評分星級系統(tǒng)要根據(jù)這些條件動態(tài)拼接查詢。使用MyBatis-Plus的LambdaQueryWrapper可以很干凈地完成多條件拼接從根本上杜絕SQL注入問題public PageScenic searchScenic(ScenicQuery query) { PageScenic page new Page(query.getPageNum(), query.getPageSize()); LambdaQueryWrapperScenic wrapper new LambdaQueryWrapper(); wrapper.eq(Scenic::getStatus, 1) .and(StringUtils.hasText(query.getKeyword()), w - w .like(Scenic::getName, query.getKeyword()) .or().like(Scenic::getDescription, query.getKeyword())) .eq(query.getCategoryId() ! null, Scenic::getCategoryId, query.getCategoryId()) .eq(StringUtils.hasText(query.getCity()), Scenic::getCity, query.getCity()) .ge(query.getMinPrice() ! null, Scenic::getPrice, query.getMinPrice()) .le(query.getMaxPrice() ! null, Scenic::getPrice, query.getMaxPrice()) .ge(query.getMinScore() ! null, Scenic::getScore, query.getMinScore()) .orderByDesc(Scenic::getWeight) .orderByDesc(Scenic::getViewCount); return scenicMapper.selectPage(page, wrapper); }排序上我默認把運營人工置頂?shù)木包c放最前面然后是瀏覽量高的自然排后面。搜索接口的響應(yīng)時間必須控制住尤其是關(guān)鍵詞搜索這種掃描范圍較大的查詢一定要在name和description字段上建立全文索引否則數(shù)據(jù)量上了十萬條之后接口會非常吃力。4.3 推薦接口的多源數(shù)據(jù)拼裝推薦列表不能只調(diào)用一種算法我用“多種召回 統(tǒng)一排序”的方式實現(xiàn)。具體來說推薦Service同時請求三個數(shù)據(jù)源基于標簽內(nèi)容推薦的召回結(jié)果基于協(xié)同過濾的召回結(jié)果基于熱門榜單的兜底結(jié)果拿到三份候選數(shù)據(jù)后先做去重按景點ID合并。接著給每個數(shù)據(jù)源一個權(quán)重系數(shù)標簽推薦權(quán)重最高協(xié)同過濾次之熱門兜底最低。最終排序字段是綜合權(quán)重乘以熱度分加時間衰減取出前N條作為首頁推薦列表。這樣的好處是即使協(xié)同過濾召回的數(shù)據(jù)為空也有標簽推薦頂上。標簽推薦為空時還有熱門推薦兜底。三個邏輯層層遞進系統(tǒng)幾乎不會給用戶返回空列表。推薦接口還有一個細節(jié)接口需要返回推薦理由字段。我在響應(yīng)對象中設(shè)計了reason字段比如“因為你關(guān)注了自然風(fēng)光”或者“和你有相似喜好的用戶也很喜歡這里”。這個字段成本很低但用戶感知度提升非常明顯。4.4 收藏與評論的并發(fā)事務(wù)處理收藏景點是一個典型的寫操作。我的實現(xiàn)思路是先插入收藏記錄靠唯一索引防重插入成功后對應(yīng)景點的fav_count加一。代碼里用事務(wù)包裝這兩個操作保證要么同時成功要么同時失敗。但高并發(fā)情況下直接用一條SQL在收藏表執(zhí)行insert另一個線程同時給fav_count做update可能出現(xiàn)計數(shù)不準確。一個簡單的辦法是直接把收藏數(shù)量的更新放在同一事務(wù)里Transactional(rollbackFor Exception.class) public void favorite(Long userId, Long scenicId) { try { Favorite favorite new Favorite(); favorite.setUserId(userId); favorite.setScenicId(scenicId); favoriteMapper.insert(favorite); scenicMapper.incrementFavCount(scenicId); } catch (DuplicateKeyException e) { throw new BizException(5001, 請勿重復(fù)收藏); } }評論的審核邏輯也要注意。用戶提交評論后status先設(shè)為0管理端審核通過后改為1。未審核的評論前臺一律不展示這個邏輯不寫管理端的存在感就少了一半。5. 管理后臺與運營數(shù)據(jù)看板5.1 權(quán)限控制與景點上下架流程管理后臺使用的權(quán)限模型比較簡單我采用的是角色標識加攔截器校驗的方式?jīng)]有引入整套用戶權(quán)限框架避免給項目徒增復(fù)雜度。用戶表增加role字段0代表普通游客1代表運營人員2代表管理員。管理接口統(tǒng)一在WebMvcConfig注冊自定義攔截器專門攔截路徑中包含/admin/的請求校驗當前用戶的角色權(quán)限沒有權(quán)限直接返回403。前端再配合路由守衛(wèi)把管理入口藏起來雙端都做校驗避免只靠前端隱藏而接口裸奔的問題。景點上下架功能看起來簡單但它涉及到一個很容易被忽略的環(huán)節(jié)緩存清理。一個景點從“上架”改為“下架”后如果推薦列表已經(jīng)緩存到Redis用戶那邊還是會看到這個景點點擊詳情才發(fā)現(xiàn)已經(jīng)下架。所以我在上下架接口里必須同時刪除該景點相關(guān)的Redis緩存Key包括推薦列表Key、詳情緩存Key和熱門榜單Key。圖片上傳也是一個容易出問題的模塊。本地存儲時圖片文件名不能直接存原始中文名必須用UUID重命名防止跨平臺編碼問題。上傳后返回給前端的不要是物理磁盤路徑而是項目配置的虛擬訪問路徑后續(xù)如果切換到云存儲改動成本會很低。5.2 運營看板的統(tǒng)計口徑與SQL數(shù)據(jù)看板是運營人員的主要工作臺包括用戶總量、今日新增、訪問趨勢、收藏榜、熱門景點排名這幾個模塊。統(tǒng)計SQL的核心是分組聚合。比如近7天的新增用戶數(shù)SELECT DATE(create_time) AS day, COUNT(*) AS cnt FROM tb_user WHERE create_time DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY DATE(create_time) ORDER BY day;熱門景點排名直接查景點表的view_count、fav_count字段按綜合權(quán)重排序。這里要注意一個問題如果每次看板請求都實時掃描全表數(shù)據(jù)量大時很慢。我的做法是每日凌晨把統(tǒng)計結(jié)果跑好存入一張統(tǒng)計匯總表運營后臺第二天看到的全是昨天的數(shù)據(jù)。實時性要求不高的場景下完全夠用。6. 緩存優(yōu)化與常見問題排查6.1 Redis緩存熱點數(shù)據(jù)的正確姿勢推薦系統(tǒng)在技術(shù)層面最大的性能瓶頸往往是熱點數(shù)據(jù)的重復(fù)查詢。同一個熱門景點可能同時被成千上萬個用戶點擊查看詳情每次都查MySQL顯然扛不住。我的方案是給景點詳情、首頁推薦列表、城市熱門榜都加上Redis緩存。緩存策略我用經(jīng)典的Cache Aside模式讀請求先查Redis未命中則查MySQL然后回填Redis寫請求先更新數(shù)據(jù)庫再刪除Redis緩存。為什么不更新緩存而直接刪除因為更新緩存還要考慮并發(fā)情況下的中間狀態(tài)太容易出錯刪除后下次讀請求自然回填簡單可靠。緩存過期時間不是固定值。我給熱門榜設(shè)置10分鐘過期景點詳情設(shè)置30分鐘過期并加上隨機過期時間防止大批量Key在同一時間失效導(dǎo)致MySQL被打滿。隨機范圍一般控制在60秒到300秒之間這個細節(jié)在流量高的場景尤其重要。6.2 慢查詢與深分頁優(yōu)化數(shù)據(jù)庫層面的問題一般出現(xiàn)在列表接口。常見的深分頁寫法limit 100000, 20會讓MySQL從第一行開始掃到十萬行再跳過性能極差。我推薦兩種優(yōu)化方式。第一種是游標分頁利用主鍵順序跳轉(zhuǎn)查詢條件帶上上次返回的最大ID直接執(zhí)行WHERE id ? ORDER BY id DESC LIMIT 20。這種方式適合信息流推薦場景因為用戶是不斷往下刷不需要跳頁。第二種是限制最大頁碼超過一定頁數(shù)進行全表掃描也沒意義直接提示“請使用篩選條件縮小范圍”。運營后臺的列表接口通常有大量篩選條件配合聯(lián)合索引基本不會出問題。排查慢查詢時我習(xí)慣先在MySQL執(zhí)行explain查看執(zhí)行計劃重點看type字段是不是到了range或ref級別。如果全是ALL全表掃描第一件事就是檢查索引是否生效而不是盲目改代碼。6.3 幾個真實的排坑經(jīng)驗第一個坑推薦結(jié)果里出現(xiàn)下架景點。這個問題我在聯(lián)調(diào)時才遇到。原因是推薦列表緩存了景點數(shù)據(jù)但景點的狀態(tài)已經(jīng)在后臺改為下架推薦接口讀緩存時并沒有校驗狀態(tài)字段。解決方法是推薦列表緩存里只存ID查詢詳情時再校驗狀態(tài)和緩存詳情避免臟數(shù)據(jù)透出。第二個坑登錄狀態(tài)的token過期時間太短用戶正在瀏覽景點詳情突然彈出重新登錄體驗非常差。最后我把token有效期調(diào)整到7天同時加了Redis續(xù)期機制用戶在活躍狀態(tài)下不會被打斷。第三個坑定時任務(wù)重復(fù)執(zhí)行導(dǎo)致熱門榜數(shù)據(jù)異常。部署時多個實例同時跑任務(wù)結(jié)果Redis里熱門榜被反復(fù)覆蓋。解決方法是給定時任務(wù)加分布式鎖或者直接指定單實例執(zhí)行具體用公司基礎(chǔ)設(shè)施里現(xiàn)成的分布鎖服務(wù)。第四個坑統(tǒng)計報表數(shù)據(jù)對不上。運營反饋后臺收藏數(shù)和景點表fav_count不一致。排查后發(fā)現(xiàn)是事務(wù)沒包住收藏記錄插入成功但計數(shù)更新時出現(xiàn)異常導(dǎo)致數(shù)據(jù)不一致。加上事務(wù)后問題解決同時異常時拋錯讓前端也能感知。一個小總結(jié)做這類系統(tǒng)我個人的體會是別把推薦想得太玄乎。真正的推薦能力是從最簡單的地方長出來的先有行為數(shù)據(jù)采集再有規(guī)則推薦然后逐步引入標簽相似度和協(xié)同過濾。好多組件的升級不是推翻重來而是在原打法上不斷疊加。只要數(shù)據(jù)和緩存設(shè)計留好了余地后續(xù)算法升級就是多寫幾個類的事。如果你現(xiàn)在正卡在項目開發(fā)的某個環(huán)節(jié)優(yōu)先檢查三個地方數(shù)據(jù)庫索引有沒有建全、推薦接口有沒有兜底邏輯、管理端操作有沒有把緩存清理干凈。這三個地方不出問題整個系統(tǒng)基本就能穩(wěn)定跑起來了。