1. 項(xiàng)目整體設(shè)計(jì)先想清楚再動(dòng)手寫(xiě)代碼大概在一年前我接了一個(gè)二次元手辦與周邊交易商城的項(xiàng)目技術(shù)棧鎖定SpringBoot業(yè)務(wù)方提了兩個(gè)硬性要求一個(gè)是商城得能賣貨購(gòu)物車、訂單、庫(kù)存這些基礎(chǔ)鏈路不能少另一個(gè)是要有“聰明的”推薦和“好看的”數(shù)據(jù)看板也就是標(biāo)題里提到的個(gè)性化推薦和數(shù)據(jù)可視化。說(shuō)實(shí)話這兩塊東西一開(kāi)始很容易被當(dāng)成“錦上添花”但真正做下來(lái)你會(huì)發(fā)現(xiàn)它們才是把商城從“能用”推向“好用”的關(guān)鍵。這篇文章我不打算做那種從零開(kāi)始的保姆級(jí)教程而是把一個(gè)基于SpringBoot的二次元手辦與周邊交易商城系統(tǒng)從架構(gòu)設(shè)計(jì)到推薦落地、再到可視化報(bào)表的完整思路和踩坑經(jīng)歷拿出來(lái)聊聊。如果你是拿這類題目做畢設(shè)或者公司準(zhǔn)備從0到1搭一個(gè)垂直品類商城這篇文章應(yīng)該能幫你少走不少?gòu)澛贰?.1 為什么二次元周邊商城適合用SpringBoot落地先講個(gè)選型問(wèn)題商城系統(tǒng)很多從古老的SSH、到后來(lái)的SpringMVC、再到微服務(wù)全家桶為什么我最后選了SpringBoot我的判斷依據(jù)其實(shí)很樸素。首先手辦周邊交易商城這種業(yè)務(wù)核心是“交易鏈路 推薦 統(tǒng)計(jì)”它不是一個(gè)需要復(fù)雜分布式事務(wù)的高并發(fā)系統(tǒng)。一個(gè)團(tuán)隊(duì)也好一個(gè)人做畢設(shè)也好最重要的不是技術(shù)棧多炫而是能在有限時(shí)間內(nèi)把業(yè)務(wù)邏輯穩(wěn)定跑起來(lái)。SpringBoot最擅長(zhǎng)干這件事內(nèi)置Tomcat、自動(dòng)裝配、起步依賴能讓開(kāi)發(fā)人員把注意力放在業(yè)務(wù)本身而不是花一個(gè)禮拜去配Spring XML。其次是生態(tài)。個(gè)性化推薦要算相似度數(shù)據(jù)可視化需要聚合查詢這兩塊都有現(xiàn)成方案能嵌入SpringBoot比如Spark MLlib提供算法庫(kù)ECharts負(fù)責(zé)前端展示后端只需要提供標(biāo)準(zhǔn)JSON接口。如果換成更重量級(jí)的微服務(wù)架構(gòu)光服務(wù)發(fā)現(xiàn)、配置中心、網(wǎng)關(guān)就夠你喝一壺的了對(duì)“商城推薦看板”這個(gè)目標(biāo)來(lái)說(shuō)嚴(yán)重超配。第三個(gè)原因更現(xiàn)實(shí)這個(gè)組合的社區(qū)資料最豐富。SpringBoot MyBatis-Plus MySQL Redis Vue ECharts幾乎是目前國(guó)內(nèi)中小型項(xiàng)目和個(gè)人畢設(shè)最常見(jiàn)的組合。你在開(kāi)發(fā)中遇到的每一個(gè)報(bào)錯(cuò)幾乎都能在網(wǎng)上找到解決方案。對(duì)于一個(gè)要交付、能演示、還要長(zhǎng)期維護(hù)的系統(tǒng)來(lái)說(shuō)這太重要了。1.2 模塊劃分與核心表結(jié)構(gòu)設(shè)計(jì)我做的第一件事不是寫(xiě)代碼而是把系統(tǒng)拆模塊?；赟pringBoot的單體應(yīng)用我按業(yè)務(wù)域拆成了六個(gè)核心模塊用戶模塊注冊(cè)、登錄、收貨地址、個(gè)人信息商品模塊手辦信息、分類、SKU庫(kù)存量單位、價(jià)格、圖片、上下架交易模塊購(gòu)物車、訂單、支付回調(diào)、售后推薦模塊用戶行為采集、物品相似度計(jì)算、推薦接口統(tǒng)計(jì)模塊訂單統(tǒng)計(jì)、用戶增長(zhǎng)、商品熱度排名、畫(huà)像分析管理后臺(tái)商品管理、訂單管理、數(shù)據(jù)看板模塊化拆分不是走過(guò)場(chǎng)它決定了你后續(xù)代碼能不能持續(xù)維護(hù)。很多同學(xué)的畢設(shè)從“商品管理”寫(xiě)到“訂單”Controller已經(jīng)四五百行后面加推薦功能時(shí)根本插不下手。我習(xí)慣的做法是嚴(yán)格Controller - Service - Mapper三層每個(gè)業(yè)務(wù)域單獨(dú)建包Controller只做參數(shù)接收和結(jié)果封裝業(yè)務(wù)判斷全部下沉到Service層。表結(jié)構(gòu)是整個(gè)系統(tǒng)里最不能偷懶的部分我按照業(yè)務(wù)對(duì)象拆了大致十幾張核心表其中和推薦、可視化最相關(guān)的幾張這么設(shè)計(jì)用戶表user_id、username、gender、age_group、preference_tags、vip_level、register_time。preference_tags我存的是JSON數(shù)組比如“[高達(dá),EVA,初音未來(lái)]”這個(gè)字段后面做冷啟動(dòng)推薦會(huì)非常有用。商品表product_id、name、category_id、series_name、brand、price、stock、sold_count、avg_rating。系列名series_name對(duì)手辦行業(yè)很重要很多用戶是追著IP買的同一系列商品天然具有關(guān)聯(lián)性。用戶行為表behavior_id、user_id、product_id、behavior_type、score、create_time。behavior_type取值有view、cart、order、collect四種。這個(gè)表是推薦系統(tǒng)最核心的數(shù)據(jù)源生產(chǎn)環(huán)境數(shù)據(jù)量會(huì)非常大所以我在user_id和product_id上建了聯(lián)合索引并且按月做分區(qū)。訂單表order_id、user_id、total_amount、status、create_time。做銷售趨勢(shì)分析時(shí)create_time和status是最高頻的查詢條件。關(guān)于商品和SKU手辦周邊有一個(gè)特點(diǎn)同一個(gè)商品往往有普通版、豪華版、限定版。我踩過(guò)的坑是初期只設(shè)計(jì)了product一張表結(jié)果同一個(gè)手辦的三個(gè)版本只能硬塞三條數(shù)據(jù)導(dǎo)致商品列表非常冗余。后面我重構(gòu)成了“商品主表 SKU子表”的結(jié)構(gòu)商品表存儲(chǔ)標(biāo)題、封面圖、系列名等公共信息SKU表存儲(chǔ)價(jià)格、庫(kù)存、款式、圖片。推薦算法算相似度時(shí)基于商品主表下單和庫(kù)存扣減則基于SKU表。1.3 工程結(jié)構(gòu)一種適合快速迭代的包組織方式這部分順帶聊聊工程結(jié)構(gòu)。我用的是標(biāo)準(zhǔn)的Maven多模塊方式但不是按layercontroller/service/mapper拆模塊而是按功能域拆。我的主pom下有三個(gè)子模塊shop-common公共類統(tǒng)一返回結(jié)果、異常處理、工具類、shop-biz所有業(yè)務(wù)代碼、shop-admin后臺(tái)管理接口依賴shop-biz。理由很簡(jiǎn)單單體項(xiàng)目用包分域已經(jīng)足夠拆太多模塊會(huì)讓構(gòu)建變慢、調(diào)試變復(fù)雜。而保留shop-admin獨(dú)立模塊是為了以后萬(wàn)一要把管理后臺(tái)和用戶端拆成兩個(gè)服務(wù)遷移成本最小化。關(guān)于統(tǒng)一返回結(jié)果我從一開(kāi)始就定了規(guī)范。封裝一個(gè)Result對(duì)象包含code、message、data三個(gè)字段成功code是200業(yè)務(wù)異常用自定義異常類拋出。推薦接口、統(tǒng)計(jì)接口、普通接口全部遵守這套格式。這件事看起來(lái)小但做數(shù)據(jù)可視化的時(shí)候你就知道多重要了——前端ECharts拿數(shù)據(jù)只需要解構(gòu)res.data不用每個(gè)接口都做特殊容錯(cuò)。2. 個(gè)性化推薦模塊從協(xié)同過(guò)濾到可落地的推薦服務(wù)個(gè)性化推薦是整個(gè)系統(tǒng)第二個(gè)讓我撓頭的模塊。熱搜詞里一大堆“springboot推薦算法”但真正看完你會(huì)發(fā)現(xiàn)大多數(shù)教程講完余弦相似度公式就結(jié)束了根本不告訴你從數(shù)據(jù)庫(kù)怎么取數(shù)、怎么構(gòu)建矩陣、計(jì)算量大了怎么辦、用戶沒(méi)數(shù)據(jù)怎么辦。這一節(jié)我把完整鏈路拆開(kāi)來(lái)講。2.1 三種推薦策略與選型思路推薦算法五花八門但針對(duì)手辦周邊商城這種垂直品類我在項(xiàng)目里重點(diǎn)考慮了三種基于內(nèi)容的推薦、基于用戶的協(xié)同過(guò)濾、基于物品的協(xié)同過(guò)濾?；趦?nèi)容的推薦邏輯很直接你之前看了“初音未來(lái)”的手辦我就在初音未來(lái)的分類下再給你推類似商品。優(yōu)點(diǎn)是沒(méi)有冷啟動(dòng)問(wèn)題新商品也能推缺點(diǎn)是推薦結(jié)果太同質(zhì)化翻來(lái)覆去就是那一個(gè)IP沒(méi)有驚喜感?；谟脩舻膮f(xié)同過(guò)濾思路是“和你品味相似的人也喜歡什么”。用戶A買了EVA劇場(chǎng)版手辦用戶B也和A一樣買了那B還收藏了高達(dá)模型這臺(tái)高達(dá)就可能成為A的推薦。缺點(diǎn)是用戶數(shù)量大時(shí)計(jì)算用戶相似度的成本很高而且新用戶冷啟動(dòng)完全沒(méi)數(shù)據(jù)?；谖锲返膮f(xié)同過(guò)濾Item-CF則反過(guò)來(lái)核心是“喜歡這個(gè)商品的人也喜歡那個(gè)商品”離線算好商品之間的相似度在線推薦時(shí)直接查表。我做選型時(shí)考慮了三個(gè)維度計(jì)算成本、冷啟動(dòng)效果、結(jié)果多樣性。最后選的是“基于物品的協(xié)同過(guò)濾作為主力 基于內(nèi)容的推薦做冷啟動(dòng)兜底”的組合策略。原因有兩點(diǎn)一是商城場(chǎng)景里商品數(shù)量通常是幾千到幾萬(wàn)遠(yuǎn)小于用戶數(shù)量可能是幾十萬(wàn)甚至上百萬(wàn)商品相似度矩陣的存儲(chǔ)和計(jì)算都更可控二是手辦用戶的行為動(dòng)機(jī)非常聚焦在“IP”和“系列”上商品間相似度比用戶間相似度更有商業(yè)解釋力。2.2 用戶-物品評(píng)分矩陣怎么構(gòu)建Item-CF的第一步是構(gòu)建用戶對(duì)物品的評(píng)分但我遇到的第一個(gè)問(wèn)題是手辦商城是電商場(chǎng)景沒(méi)有“評(píng)分”這個(gè)動(dòng)作。解決辦法是把行為映射成分?jǐn)?shù)瀏覽得1分加入購(gòu)物車得3分收藏得4分下單直接得5分。這里有個(gè)細(xì)節(jié)比如用戶下單之后退款了分?jǐn)?shù)就要及時(shí)扣回來(lái)不然矩陣會(huì)被虛假行為污染。我在行為表里增加了status字段只有status1有效的記錄才參與矩陣構(gòu)建。矩陣本身我用的是稀疏矩陣存儲(chǔ)沒(méi)有直接定義二維數(shù)組。我選了開(kāi)源工具庫(kù)Mahout它的GenericUserBasedRecommender和GenericItemBasedRecommender封裝好了用戶相似度和物品相似度的計(jì)算邏輯。當(dāng)然直接調(diào)庫(kù)是不可能滿足所有場(chǎng)景的我重寫(xiě)了DataModel部分讓它直接從MySQL里的用戶行為表讀取數(shù)據(jù)通過(guò)JDBC構(gòu)建用戶-商品得分映射。減少矩陣計(jì)算量的關(guān)鍵還有一個(gè)時(shí)間窗口。我默認(rèn)只取最近180天的行為數(shù)據(jù)因?yàn)樵缬诎肽甑男袨閷?duì)預(yù)測(cè)用戶當(dāng)前興趣沒(méi)有增益而且能大幅降低內(nèi)存與計(jì)算損耗。這個(gè)值我是在對(duì)比了取30天、90天、180天三組數(shù)據(jù)的推薦效果之后結(jié)合內(nèi)容和點(diǎn)擊率反饋確定的。2.3 推薦算法實(shí)現(xiàn)與SpringBoot集成這部分給出一段核心的Item-CF實(shí)現(xiàn)思路我是把它封裝成一個(gè)SpringBoot的Service的。整體流程是定時(shí)任務(wù)離線計(jì)算商品相似度矩陣 - 存入Redis - 在線推薦時(shí)讀取相似度矩陣和用戶歷史行為 - 輸出推薦列表。離線計(jì)算相似度這部分其中核心代碼邏輯大概是這樣的Service public class ItemSimilarityService { Autowired private UserBehaviorMapper behaviorMapper; /** * 計(jì)算所有商品兩兩之間的余弦相似度 * 結(jié)果寫(xiě)入rediskey為 item:sim:{productId} */ public void calculateItemSimilarity() { // 1. 獲取近180天行為數(shù)據(jù) ListUserBehavior behaviors behaviorMapper.selectRecentValid(180); // 2. 構(gòu)建 用戶 - 商品集合 的倒排表 MapLong, SetLong userItems new HashMap(); for (UserBehavior behavior : behaviors) { userItems.computeIfAbsent(behavior.getUserId(), k - new HashSet()) .add(behavior.getProductId()); } // 3. 統(tǒng)計(jì)商品之間的共現(xiàn)次數(shù) MapString, Integer coCount new HashMap(); MapLong, Integer itemCount new HashMap(); for (SetLong items : userItems.values()) { for (Long itemA : items) { itemCount.merge(itemA, 1, Integer::sum); for (Long itemB : items) { if (!itemA.equals(itemB)) { String key itemA : itemB; coCount.merge(key, 1, Integer::sum); } } } } // 4. 計(jì)算余弦相似度保留相似度大于0.2的商品關(guān)系 coCount.forEach((key, count) - { String[] parts key.split(:); long itemA Long.parseLong(parts[0]); long itemB Long.parseLong(parts[1]); double sim count / Math.sqrt((double) itemCount.get(itemA) * itemCount.get(itemB)); if (sim 0.2) { redisTemplate.opsForZSet().add(item:sim: itemA, String.valueOf(itemB), sim); } }); } }在線推薦的時(shí)候邏輯就簡(jiǎn)單了取出用戶最近瀏覽和收藏的商品id列表對(duì)每個(gè)商品去Redis查TopN相似商品然后做加權(quán)排序、排除用戶已購(gòu)買的商品最終把得分最高的12個(gè)商品返回給前端。public ListProduct recommend(Long userId, int topN) { // 獲取用戶歷史興趣商品 ListLong interestItems behaviorMapper.selectUserPositiveItems(userId); MapLong, Double scoreMap new HashMap(); for (Long itemId : interestItems) { // 從Redis取相似商品倒序取前20 SetZSetOperations.TypedTupleString tuples redisTemplate.opsForZSet().reverseRangeWithScores(item:sim: itemId, 0, 19); for (ZSetOperations.TypedTupleString tuple : tuples) { Long simItemId Long.parseLong(tuple.getValue()); if (interestItems.contains(simItemId)) continue; // 排除已感興趣的 scoreMap.merge(simItemId, tuple.getScore(), Double::sum); } } // 按得分排序截取topN return scoreMap.entrySet().stream() .sorted(Map.Entry.Long, DoublecomparingByValue().reversed()) .limit(topN) .map(entry - productMapper.selectById(entry.getKey())) .collect(Collectors.toList()); }這段邏輯有一個(gè)我一開(kāi)始忽略的問(wèn)題如果用戶只有一兩個(gè)行為個(gè)性化推薦結(jié)果會(huì)非常窄基本上就是相似商品的重復(fù)展開(kāi)。所以我加了一個(gè)策略層——當(dāng)用戶有效行為少于5條時(shí)不走Item-CF直接走基于內(nèi)容的熱門推薦從用戶填寫(xiě)的preference_tags和最近瀏覽分類里取熱門商品。2.4 冷啟動(dòng)問(wèn)題的處理方案冷啟動(dòng)是推薦系統(tǒng)繞不開(kāi)的話題分兩種情況新用戶冷啟動(dòng)和新商品冷啟動(dòng)。新用戶冷啟動(dòng)核心思路是從注冊(cè)信息做粗粒度推薦。我在用戶表預(yù)留了preference_tags字段用戶注冊(cè)時(shí)可以勾選感興趣的IP或品類這個(gè)信息會(huì)在推薦接口里直接轉(zhuǎn)換為搜索條件比如用戶填了“初音未來(lái)”新用戶推薦列表里就會(huì)有初音專題的熱門商品。如果用戶沒(méi)填我看他登錄后前三次瀏覽行為實(shí)時(shí)更新他的推薦池。新商品冷啟動(dòng)做法是給商品打“新品扶持”標(biāo)簽。所有上架時(shí)間低于14天、有基礎(chǔ)庫(kù)存的商品在進(jìn)行排序時(shí)加權(quán)1.2倍。這樣既保證新品有曝光又不至于因?yàn)橥扑]它而影響整體轉(zhuǎn)化率。冷啟動(dòng)里還有一個(gè)很關(guān)鍵的點(diǎn)不要為了“個(gè)性”丟掉“大眾”。我的推薦列表里固定有30%的槽位給全站熱銷榜剩下70%給個(gè)性化推薦。這么做的原因很簡(jiǎn)單手辦周邊的客單價(jià)偏高新用戶第一次打開(kāi)商城時(shí)對(duì)平臺(tái)缺乏信任如果全是冷門推薦他大概率直接退出。熱銷榜告訴他“大家都在買什么”這種從眾心理在交易場(chǎng)景里極好使。注意協(xié)同過(guò)濾計(jì)算相似度建議用定時(shí)任務(wù)比如每天凌晨2點(diǎn)算一次而不是用戶請(qǐng)求時(shí)實(shí)時(shí)計(jì)算。原因很好理解離線計(jì)算結(jié)果可以提前緩存在線響應(yīng)時(shí)間能壓到50ms以內(nèi)實(shí)時(shí)算的話幾千個(gè)商品可以扛到幾萬(wàn)個(gè)商品時(shí)內(nèi)存和耗時(shí)就會(huì)明顯失控。3. 數(shù)據(jù)可視化模塊埋點(diǎn)、聚合與報(bào)表展現(xiàn)個(gè)性化推薦解決的是“怎么把貨賣出去”數(shù)據(jù)可視化解決的則是“怎么看清賣得好不好”。這兩件事看起來(lái)獨(dú)立實(shí)際是同一套數(shù)據(jù)鏈路的兩端。3.1 可視化數(shù)據(jù)從哪里來(lái)埋點(diǎn)與采集沒(méi)有數(shù)據(jù)可視化就是無(wú)水之源。我對(duì)接數(shù)據(jù)可視化模塊時(shí)定的第一條原則就是不能用SQL查不到的數(shù)據(jù)。比如用戶畫(huà)像里的年齡分布、性別比例這些信息訂單表里沒(méi)有必須用戶在注冊(cè)時(shí)就采集。對(duì)于商城而言可視化看板的數(shù)據(jù)來(lái)源主要有三個(gè)交易數(shù)據(jù)訂單表、用戶行為數(shù)據(jù)埋點(diǎn)日志、商品數(shù)據(jù)商品表。埋點(diǎn)這塊我踩過(guò)一個(gè)印象深刻的坑。最初的計(jì)劃是前端頁(yè)面每次瀏覽商品都向后端發(fā)送一條瀏覽日志直接insert進(jìn)行為表。結(jié)果首頁(yè)上線當(dāng)天行為表直接多了十萬(wàn)條數(shù)據(jù)MySQL的寫(xiě)入壓力立刻上來(lái)了商城正常業(yè)務(wù)都跟著受影響。后續(xù)我改成了異步采集用戶的瀏覽行為先由前端寫(xiě)入localStorage用戶離開(kāi)頁(yè)面或每30秒統(tǒng)一上報(bào)一次后端接收到行為數(shù)據(jù)后不直接落庫(kù)而是丟進(jìn)RabbitMQ隊(duì)列由消費(fèi)者異步批量寫(xiě)入。訂單、收藏這類高價(jià)值行為仍然實(shí)時(shí)寫(xiě)入但瀏覽行為全部走異步。這么改之后高峰期數(shù)據(jù)庫(kù)寫(xiě)入壓力降低了80%以上。3.2 后端統(tǒng)計(jì)接口的設(shè)計(jì)要點(diǎn)數(shù)據(jù)可視化最忌諱的是每個(gè)圖表都寫(xiě)一個(gè)獨(dú)立接口最后接口數(shù)量爆炸前端維護(hù)成本極高。我做這套系統(tǒng)的原則是按主題聚合接口一個(gè)主題一個(gè)接口內(nèi)部一次聚合查詢直接返回前端ECharts需要的數(shù)據(jù)結(jié)構(gòu)。我最終定了四個(gè)核心統(tǒng)計(jì)主題銷售分析按日/周/月聚合訂單金額和訂單量用于看銷售趨勢(shì)。實(shí)現(xiàn)時(shí)用MySQL的DATE_FORMAT函數(shù)對(duì)create_time做時(shí)間分組再在Java側(cè)補(bǔ)齊沒(méi)有訂單的日期空值。商品分析TOP10熱銷商品、滯銷商品列表、分類銷售額占比。分類銷售額占比用的是餅圖數(shù)據(jù)格式返回[{name: 機(jī)動(dòng)戰(zhàn)士高達(dá), value: 12500}, ...]。用戶分析用戶注冊(cè)趨勢(shì)、用戶年齡/性別分布。用戶注冊(cè)趨勢(shì)用于評(píng)估運(yùn)營(yíng)活動(dòng)的拉新效果年齡分布來(lái)自用戶表的age_group字段。運(yùn)營(yíng)畫(huà)板訪客數(shù)、轉(zhuǎn)化率、客單價(jià)、復(fù)購(gòu)率四個(gè)核心指標(biāo)。統(tǒng)計(jì)SQL有幾個(gè)常規(guī)優(yōu)化點(diǎn)。比如查“近30天每日銷售額”淘寶級(jí)別系統(tǒng)會(huì)直接查數(shù)倉(cāng)但我們這種規(guī)模用MySQL就可以。第一次寫(xiě)出來(lái)的SQL特別慢因?yàn)閷?duì)orders表全表掃描。我處理方式是先查出近30天有訂單的日期列表再按日分組匯總最后在Java里用循環(huán)補(bǔ)全缺失日期這樣比一條大SQL做日歷表join效率高得多。下面展示銷量趨勢(shì)統(tǒng)計(jì)接口的Service實(shí)現(xiàn)public ListSalesTrendVO getSalesTrend(String period) { // period: day / week / month ListSalesTrendVO list orderMapper.selectSalesTrend(period); // 補(bǔ)齊無(wú)訂單的日期 MapString, SalesTrendVO map list.stream() .collect(Collectors.toMap(SalesTrendVO::getDateStr, Function.identity())); ListString range buildDateRange(period); return range.stream().map(date - { SalesTrendVO vo map.get(date); return vo ! null ? vo : new SalesTrendVO(date, 0, 0); }).collect(Collectors.toList()); }這一個(gè)接口同時(shí)支持前端三種維度的折線圖切換參數(shù)校驗(yàn)和格式統(tǒng)一都在Service層處理完畢Controller只做透?jìng)鳌?.3 前端可視化方案ECharts接入與接口對(duì)齊可視化展示我前端用的是Vue ECharts這套組合和SpringBoot后端配合起來(lái)很順手。ECharts對(duì)JSON數(shù)據(jù)的要求非常嚴(yán)格鍵名錯(cuò)一個(gè)、數(shù)值類型不對(duì)圖表就顯示不出來(lái)。所以在后端設(shè)計(jì)數(shù)據(jù)結(jié)構(gòu)時(shí)我建議直接按照ECharts的data格式設(shè)計(jì)前端拿過(guò)來(lái)就能用不用再做二次轉(zhuǎn)換。舉一個(gè)實(shí)際例子商品分類銷售占比的接口返回結(jié)構(gòu)我是這樣設(shè)計(jì)的{ code: 200, message: success, data: { categories: [機(jī)動(dòng)戰(zhàn)士高達(dá), 新世紀(jì)福音戰(zhàn)士, 初音未來(lái)], values: [128500, 96300, 74500] } }前端拿到data之后直接塞進(jìn)ECharts的餅圖配置里不用做任何map。接口命名和字段命名我在項(xiàng)目文檔里統(tǒng)一規(guī)范過(guò)后端返回一律使用駝峰命名前端統(tǒng)一用解構(gòu)取值不單獨(dú)做二次字段映射。管理后臺(tái)的三個(gè)可視化頁(yè)面我也簡(jiǎn)單說(shuō)一下數(shù)據(jù)總覽頁(yè)面放四個(gè)核心指標(biāo)卡片和銷售趨勢(shì)折線圖商品分析頁(yè)面放熱銷排行條形圖和分類占比餅圖用戶分析頁(yè)面放注冊(cè)趨勢(shì)曲線和性別年齡堆疊柱狀圖。三個(gè)頁(yè)面共用一套接口改起來(lái)非常方便。3.4 大屏之外的日常數(shù)據(jù)看板說(shuō)完大屏看板我想補(bǔ)充一個(gè)容易被忽視的點(diǎn)數(shù)據(jù)可視化不只是管理后臺(tái)大屏還要包括運(yùn)營(yíng)人員每天看的日常報(bào)表。我做了一個(gè)定時(shí)任務(wù)每天早上9點(diǎn)統(tǒng)計(jì)昨天的關(guān)鍵指標(biāo)生成一張圖文日?qǐng)?bào)推送到釘釘群我們公司用釘釘辦公。這個(gè)日?qǐng)?bào)里包括昨日銷售額、昨日訂單量、熱銷TOP3商品、較前一天的漲跌幅。這個(gè)功能看起來(lái)輕量但實(shí)際上非?？简?yàn)后端聚合能力每一個(gè)指標(biāo)都對(duì)應(yīng)一條統(tǒng)計(jì)SQL。比如計(jì)算“昨日銷售額”排除退款訂單狀態(tài)統(tǒng)計(jì)口徑是status ! REFUNDED。這種細(xì)節(jié)如果不做數(shù)字就會(huì)和財(cái)務(wù)對(duì)不上后面被運(yùn)營(yíng)盯上就慘了。4. 交易核心鏈路與性能優(yōu)化實(shí)錄推薦和可視化是亮點(diǎn)但商城系統(tǒng)真正不能出問(wèn)題的是交易鏈路。用戶下單報(bào)個(gè)錯(cuò)比推薦算法不準(zhǔn)嚴(yán)重得多。這一節(jié)我挑幾個(gè)最重要的鏈路節(jié)點(diǎn)來(lái)講。4.1 購(gòu)物車、訂單與庫(kù)存狀態(tài)機(jī)設(shè)計(jì)購(gòu)物車模塊看起來(lái)簡(jiǎn)單但設(shè)計(jì)時(shí)要注意把“選中狀態(tài)”存下來(lái)。我見(jiàn)過(guò)很多商城項(xiàng)目進(jìn)入確認(rèn)訂單頁(yè)時(shí)才發(fā)現(xiàn)購(gòu)物車?yán)锬男┥唐繁贿x中都不知道原因是購(gòu)物車表根本沒(méi)有checked字段。我的購(gòu)物車表字段是cart_id、user_id、sku_id、quantity、checked、create_time其中check字段默認(rèn)值1用戶取消勾選就置0確認(rèn)訂單頁(yè)只查詢checked1的記錄。訂單狀態(tài)我定義了一個(gè)整型狀態(tài)機(jī)1待支付2已支付待發(fā)貨3已發(fā)貨4已完成5已取消6退款中7已退款。為什么用整型而不是字符串因?yàn)闋顟B(tài)流轉(zhuǎn)的時(shí)候整型更方便做范圍判斷。比如用戶取消訂單只允許在狀態(tài)1待支付時(shí)操作前端只需要傳訂單號(hào)后端執(zhí)行update orders set status5 where order_id? and status1用update影響行數(shù)判斷是否允許取消。這個(gè)“放行條件寫(xiě)入SQL”的技巧比先查再判斷更安全能防止并發(fā)下的狀態(tài)錯(cuò)亂。4.2 庫(kù)存扣減與防超賣庫(kù)存扣減是最典型的并發(fā)問(wèn)題。手辦圈有個(gè)特點(diǎn)熱門限定款發(fā)售時(shí)會(huì)瞬間涌入大量訂單如果庫(kù)存100個(gè)同時(shí)來(lái)了200個(gè)請(qǐng)求不加控制就會(huì)有100個(gè)用戶搶到根本不存在的手辦。我采用的方法是數(shù)據(jù)庫(kù)樂(lè)觀鎖扣減核心SQL是這樣UPDATE sku SET stock stock - #{quantity} WHERE sku_id #{skuId} AND stock #{quantity}這個(gè)SQL保證扣減是對(duì)數(shù)據(jù)庫(kù)行數(shù)據(jù)加鎖的原子操作stock quantity在數(shù)據(jù)庫(kù)層面攔截了超賣。執(zhí)行后返回受影響行數(shù)如果為0說(shuō)明庫(kù)存不足或者商品已下架直接提示用戶搶光了。這里需要提醒一句網(wǎng)上很多教程會(huì)建議你在Java代碼里先查庫(kù)存判斷庫(kù)存大于0再減。在高并發(fā)場(chǎng)景下這種做法一定不要用——兩條線程同時(shí)查到庫(kù)存為1都認(rèn)為可以購(gòu)買然后各自減1結(jié)果庫(kù)存變成-1。只有把判斷條件放到UPDATE的WHERE子句里才是安全的。至于Redis預(yù)扣庫(kù)存方案我也做過(guò)測(cè)試但因?yàn)槭洲k商城的下單流程還依賴優(yōu)惠券、收貨地址等一系列數(shù)據(jù)校驗(yàn)復(fù)雜度上升不少。如果項(xiàng)目沒(méi)有明確的超高并發(fā)壓測(cè)需求直接用數(shù)據(jù)庫(kù)樂(lè)觀鎖就夠了簡(jiǎn)單可靠不會(huì)引入數(shù)據(jù)一致性問(wèn)題。4.3 列表查詢慢的優(yōu)化商城系統(tǒng)的用戶端首頁(yè)、推薦列表、搜索結(jié)果頁(yè)都是大流量入口這些地方查詢慢直接影響轉(zhuǎn)化率。我遇到過(guò)的問(wèn)題是首頁(yè)商品列表帶上了每個(gè)商品的銷量、庫(kù)存、標(biāo)簽等所有字段一次查詢要join五張表接口響應(yīng)時(shí)間到了900ms。優(yōu)化方案我分了兩步走。第一步列表接口只返回列表頁(yè)需要的字段商品詳情信息走detail接口單獨(dú)查詢讓主查詢變成單表簡(jiǎn)單查詢。第二步對(duì)銷量、評(píng)分這類“重變化”數(shù)據(jù)加Redis緩存設(shè)置5分鐘過(guò)期時(shí)間用定時(shí)任務(wù)在數(shù)據(jù)變化后主動(dòng)清理緩存。對(duì)于動(dòng)輒幾萬(wàn)條結(jié)果的商品搜索我不建議在MySQL里直接寫(xiě)模糊查詢LIKE %關(guān)鍵詞%這種寫(xiě)法會(huì)讓索引完全失效。我在項(xiàng)目里引入了Elasticsearch作為商品搜索的專用索引商品上架、信息變更時(shí)同步索引搜索和篩選走ES保障首頁(yè)搜索體驗(yàn)。如果項(xiàng)目規(guī)模不大用MySQL的全文索引或者簡(jiǎn)單的前綴LIKE也能湊合但用戶量上來(lái)后還是要考慮上ES。4.4 事務(wù)邊界與并發(fā)控制交易鏈路里最容易犯的錯(cuò)是把無(wú)關(guān)操作塞進(jìn)同一個(gè)事務(wù)導(dǎo)致鎖范圍擴(kuò)大系統(tǒng)整體吞吐量下降。我習(xí)慣的劃分原則是用戶下單時(shí)“校驗(yàn)商品狀態(tài) 扣減庫(kù)存 生成訂單 清空購(gòu)物車”四個(gè)操作必須在一個(gè)事務(wù)里這四個(gè)是強(qiáng)一致性動(dòng)作而“發(fā)送通知短信”“寫(xiě)入推薦行為日志”“更新銷售統(tǒng)計(jì)緩存”則放到事務(wù)外異步執(zhí)行這四個(gè)不是核心數(shù)據(jù)延遲幾秒沒(méi)有任何影響。另外Spring的Transactional默認(rèn)只在拋出RuntimeException時(shí)回滾如果業(yè)務(wù)代碼捕獲了異常沒(méi)有重新拋出事務(wù)是不會(huì)回滾的。排查這種問(wèn)題非常難受因?yàn)閿?shù)據(jù)已經(jīng)臟了。我建議在事務(wù)方法里不要隨意catch異常遇到真實(shí)的業(yè)務(wù)失敗直接拋?zhàn)远x異常由全局異常處理器統(tǒng)一返回提示信息。5. 典型問(wèn)題與排坑記錄這一節(jié)我整理了做這個(gè)項(xiàng)目時(shí)遇到的高頻問(wèn)題基本都能在搜索引擎搜到但當(dāng)時(shí)每一個(gè)都花了我不少時(shí)間現(xiàn)在整理成速查表希望能幫你省點(diǎn)功夫。5.1 推薦結(jié)果怎么不更新現(xiàn)象用戶換個(gè)新商品再訪問(wèn)推薦列表內(nèi)容毫無(wú)變化。排查過(guò)程分了三步——第一步我看了日志發(fā)現(xiàn)推薦接口確實(shí)走了SpringBoot層返回的也是Redis里的數(shù)據(jù)。第二步查Redis的item:sim:前綴key發(fā)現(xiàn)商品相似度沒(méi)更新。第三步查定時(shí)任務(wù)調(diào)度日志發(fā)現(xiàn)相似度計(jì)算任務(wù)壓根就沒(méi)執(zhí)行。最后定位到是定時(shí)任務(wù)配置的cron表達(dá)式寫(xiě)錯(cuò)了凌晨2點(diǎn)的時(shí)間寫(xiě)成了凌晨2點(diǎn)但時(shí)區(qū)不對(duì)導(dǎo)致理想執(zhí)行的是UTC時(shí)間。解決辦法是統(tǒng)一用系統(tǒng)默認(rèn)時(shí)區(qū)并且把定時(shí)任務(wù)的執(zhí)行結(jié)果寫(xiě)入日志表中方便主動(dòng)檢查。這個(gè)小問(wèn)題給了一個(gè)教訓(xùn)凡是依賴定時(shí)任務(wù)的邏輯一定要有“任務(wù)是否成功執(zhí)行”的可觀測(cè)性不能只是默默運(yùn)行。5.2 統(tǒng)計(jì)SQL查詢特別慢現(xiàn)象銷售趨勢(shì)頁(yè)面加載時(shí)間超過(guò)8秒。優(yōu)化前的SQL大致是對(duì)orders表做全量掃描同時(shí)按日期分組并對(duì)金額求和而且沒(méi)有對(duì)create_time建立索引。orders表當(dāng)時(shí)大概有20萬(wàn)條數(shù)據(jù)這個(gè)查詢每次都要全表掃。優(yōu)化方案是對(duì)create_time、status兩個(gè)字段建了聯(lián)合索引讓數(shù)據(jù)庫(kù)在進(jìn)入聚合前先過(guò)濾出目標(biāo)時(shí)間段和有效狀態(tài)的數(shù)據(jù)結(jié)果查詢時(shí)間從8秒降到了300毫秒左右。這個(gè)案例值得記住的是絕大多數(shù)統(tǒng)計(jì)查詢慢不是因?yàn)榫酆虾瘮?shù)效率低而是沒(méi)有通過(guò)索引提前縮小數(shù)據(jù)掃描范圍。5.3 ECharts圖表數(shù)據(jù)一直對(duì)不上現(xiàn)象后臺(tái)看板顯示的訂單量和訂單列表頁(yè)手動(dòng)數(shù)的數(shù)量對(duì)不上。排查發(fā)現(xiàn)問(wèn)題出在統(tǒng)計(jì)口徑上。后臺(tái)看板我統(tǒng)計(jì)的是“訂單狀態(tài)不為已取消和已退款”的記錄數(shù)而訂單列表頁(yè)默認(rèn)顯示的是所有狀態(tài)的記錄數(shù)兩個(gè)數(shù)字自然不一致。解決方法是把各個(gè)統(tǒng)計(jì)模塊的“統(tǒng)計(jì)口徑”統(tǒng)一成一個(gè)數(shù)據(jù)字典在項(xiàng)目文檔里明確記錄每個(gè)指標(biāo)的統(tǒng)計(jì)維度。比如“銷售額已支付訂單金額-退款金額”這句話要把每個(gè)單詞都定義清楚。數(shù)據(jù)可視化系統(tǒng)最大的坑往往不在技術(shù)而在口徑不統(tǒng)一。5.4 完整問(wèn)題速查表問(wèn)題現(xiàn)象根本原因解決方案首頁(yè)接口響應(yīng)超800ms一次性join五張表查詢列表列表查詢只取必要字段詳情走獨(dú)立接口熱門手辦庫(kù)存變負(fù)數(shù)并發(fā)場(chǎng)景下先查庫(kù)存再扣減UPDATE ... WHERE stock quantity 原子扣減推薦列表總是不變定時(shí)任務(wù)時(shí)區(qū)配置錯(cuò)誤導(dǎo)致未執(zhí)行統(tǒng)一時(shí)區(qū)配置任務(wù)結(jié)果寫(xiě)入日志表Excel導(dǎo)出的報(bào)表中文亂碼接口返回?cái)?shù)據(jù)編碼與文件流編碼不一致統(tǒng)一UTF-8編碼文件流指定UTF-8輸出數(shù)據(jù)庫(kù)行為表增長(zhǎng)過(guò)快每次瀏覽行為都實(shí)時(shí)寫(xiě)入前端批量上報(bào) RabbitMQ異步落庫(kù)可視化看板數(shù)據(jù)對(duì)不上各接口統(tǒng)計(jì)口徑不一致建立統(tǒng)計(jì)口徑文檔統(tǒng)一所有指標(biāo)定義我在實(shí)際開(kāi)發(fā)中還有一個(gè)心得想分享這個(gè)系統(tǒng)的兩個(gè)高級(jí)功能個(gè)性化推薦和數(shù)據(jù)可視化其實(shí)不是獨(dú)立于商城之外的“附加題”而是必須和交易鏈路牢牢綁在一起。推薦算法依賴用戶行為數(shù)據(jù)行為數(shù)據(jù)來(lái)自瀏覽、收藏、下單可視化看板反映的是交易數(shù)據(jù)的聚合結(jié)果交易數(shù)據(jù)又反過(guò)來(lái)指導(dǎo)選品和運(yùn)營(yíng)策略。這個(gè)“行為 - 數(shù)據(jù) - 推薦與統(tǒng)計(jì) - 反饋業(yè)務(wù)”的閉環(huán)才是這個(gè)項(xiàng)目最有價(jià)值的地方。如果你正在推進(jìn)類似的項(xiàng)目建議優(yōu)先把基礎(chǔ)交易鏈路做扎實(shí)再逐步疊加推薦和可視化每一步都確保數(shù)據(jù)質(zhì)量經(jīng)得起推敲整個(gè)過(guò)程就會(huì)順很多。