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