做短鏈接流量分析這個事我一開始是被臨時拉去救火的。業(yè)務方要做一場裂變活動投放了一堆帶參數(shù)鏈接結(jié)果后臺只能看到打開人數(shù)來源渠道、設備分布、時段趨勢全是一團黑。市面上的第三方統(tǒng)計平臺要么收費貴要么數(shù)據(jù)落地格式不自由。想自己搞一個吧翻了一圈開源項目不是太重動不動上KafkaFlink全家桶就是只有前端大屏展示數(shù)據(jù)完全不落地。最后我決定用當前最順手的那套組合——SpringBootVueMyBatisMySQL前后端分離用最短的開發(fā)周期搭一個能真正跑到線上的“短流量數(shù)據(jù)分析與可視化ABO系統(tǒng)”。這里ABO不是別的就是Analysis-Business-Optimization分析、業(yè)務、優(yōu)化把鏈路數(shù)據(jù)從采集到展示再推回業(yè)務決策走完一個完整循環(huán)。這篇把整個項目的需求拆解、技術選型、核心模塊實現(xiàn)、部署教程以及我實際踩過的坑一次性整理完整。適合已經(jīng)有Java基礎和Vue入門經(jīng)驗的開發(fā)者或者正在做前后端分離項目實戰(zhàn)練手的人。1. 項目由來與需求拆解短流量分析到底要分析什么1.1 為什么盯上“短流量”這個細分場景一般談到數(shù)據(jù)分析大家第一反應是埋點、用戶行為日志、漏斗轉(zhuǎn)化那是個大工程。但短流量不太一樣。它的本質(zhì)是“每一次點擊都是帶了明確來源訴求的”比如短信里的短鏈接、海報上的短鏈二維碼、社群分享出來的短鏈接。這些流量不像站內(nèi)瀏覽那么混沌它們的生命周期很短數(shù)據(jù)量不會大到離線計算的程度但是維度屬性非常清晰誰點的、從哪個渠道來的、用什么設備、在哪個時段點的、停留了多久。這些字段湊在一起足夠支撐運營做快速決策。而且更有意思的是短流量的用戶路徑天然就能對應上“鏈—點—覽”三段結(jié)構。鏈接生成、點擊訪問、落地頁瀏覽每一段都可以量化。如果做成長鏈加參數(shù)雖然也能查但推廣素材里經(jīng)常被截斷體驗也差。所以做這個系統(tǒng)第一步需求就定死了一定要有短鏈生成能力一定要能記錄每次點擊的元信息最后通過時間維度和屬性維度聚合出可視化報表。這些需求不復雜但對數(shù)據(jù)一致性要求不低點擊就是事實不能丟也不能重復統(tǒng)計。1.2 功能清單與數(shù)據(jù)流轉(zhuǎn)邏輯需求最終收斂成四個模塊短鏈管理、點擊采集、數(shù)據(jù)聚合、可視化展示。短鏈管理負責把原始長鏈接壓縮成短碼。點擊采集是核心埋點接口用戶每次訪問短鏈都會走一次重定向重定向之前在服務端把請求頭里的User-Agent、Referer、IP以及URL里攜帶的渠道參數(shù)記錄下來。數(shù)據(jù)聚合分實時和離線兩層實時的話我用了簡單的本地緩存做分鐘級計數(shù)離線報表則由定時任務按小時跑批把明細數(shù)據(jù)聚合成小時表、日報表。可視化展示用Vue寫了一套Dashboard包含整體趨勢、渠道占比、設備分布、最近點擊實時滾動幾個組件。整個數(shù)據(jù)流轉(zhuǎn)的核心鏈路是這樣的前端短鏈地址發(fā)起請求 → SpringBoot攔截器解析短碼 → 異步寫入點擊流水 → 重定向到原始長鏈 → 定時任務聚合到統(tǒng)計表 → 前端ECharts圖表拉取聚合接口渲染。這里最需要注意的點是“重定向和寫日志必須解耦”否則點擊一多接口延遲就上去了。我的做法是把點擊流水的寫入丟進一個線程池異步處理主線程只做一次短碼DB查詢和302跳轉(zhuǎn)。這樣寫既有實時性又不阻塞鏈路。1.3 前后端分離的總體架構設計這個項目的架構在部署形態(tài)上走的是標準的前后端分離前端Vue項目獨立開發(fā)調(diào)試通過代理訪問后端接口生產(chǎn)環(huán)境有兩種可選一種是把Vue打包后的dist目錄扔進SpringBoot的static資源下做成單Jar部署另一種是用Nginx托管靜態(tài)文件、反向代理后端接口。我最后實際線上用的是第二種因為后續(xù)還要在這個域名下掛別的服務網(wǎng)關層獨立出來會更靈活。后端按包結(jié)構劃分成controller、service、mapper、entity、common、config幾層。短鏈模塊在controller里直接返回短碼和完整短鏈地址點擊分析模塊提供趨勢、排行、實時三個大類接口。數(shù)據(jù)庫操作全部走MyBatis手寫SQL的比例高一些因為統(tǒng)計場景里的多表關聯(lián)、分組聚合、時間序列補零用注解SQL表達起來勉強XML里寫動態(tài)SQL才舒服。2. 技術選型SpringBootVueMyBatisMySQL這套組合的理由2.1 后端為什么還是SpringBoot最穩(wěn)有些項目喜歡一上來就上Spring Cloud全家桶但短流量分析這種場景業(yè)務量級也就是日百萬級點擊連CDN都還沒參與進來微服務帶來的收益基本為零反倒增加部署和運維成本。SpringBoot單應用足以扛住這個量級而且開發(fā)效率最高。我選的版本是SpringBoot 2.7.x。很多人喜歡追新上來就SpringBoot 3.x。但是3.x強制要求JDK 17而且javax命名空間改成jakarta網(wǎng)上大量老教程的代碼直接跑不通。對大多數(shù)中小項目來說2.7 JDK 1.8的組合最穩(wěn)定云服務器上CentOS自帶的JDK版本也不用折騰。如果后續(xù)真需要流量再上漲升級路徑也明確接入Nginx負載均衡、加Redis做緩存、再考慮拆服務。2.2 前端選Vue而不是React的真實原因團隊之前的技術棧里Vue和React都有用過但這個項目選Vue3有非常實在的理由一是ECharts對Vue3的封裝生態(tài)更成熟vue-echarts組件用起來比在React里手動管理chart實例要順手很多二是Vue的模板語法對后端轉(zhuǎn)前端的同事很友好模板里可以直接寫v-for、v-if不需要像JSX那樣在render函數(shù)里繞邏輯三是數(shù)據(jù)可視化場景里Vue的響應式數(shù)據(jù)天生和圖表組件契合接口返回的新數(shù)據(jù)集丟進去圖表自動刷新。腳手架我用的是Vite而不是Vue CLI速度快了不是一點半點。這里提醒一句網(wǎng)上很多教程還在用Vue CLI創(chuàng)建項目新開項目直接npm create vitelatest然后選擇vue模板就行。2.3 MyBatis在統(tǒng)計場景下的靈活性和坑MyBatis和MyBatis-Plus之間我選了前者準確說是只加了通用Mapper插件沒有用Plus的LambdaQueryWrapper。原因很直接統(tǒng)計報表的SQL幾乎都是動態(tài)拼條件、按維度分組、子查詢嵌套MyBatis-Plus的封裝在這種場景下反而繞。比如“查詢最近14天每天各渠道PV”如果全部用MP的Wrapper去套代碼能寫出一本書來。而用XML動態(tài)SQL一句if判斷一個維度直觀到不行。MyBatis的緩存機制這里得單獨提一下。默認一級緩存是SqlSession級別的二級緩存默認不開啟。統(tǒng)計系統(tǒng)的數(shù)據(jù)實時性要求其實不高報表做到分鐘級已經(jīng)足夠所以我在統(tǒng)計查詢Mapper上開啟了二級緩存并且把緩存過期時間設置成60秒。這樣熱點報表接口的數(shù)據(jù)庫壓力小了很多。但要注意如果有寫操作同時改統(tǒng)計表緩存很容易臟讀。所以我的實踐是報表查詢走二級緩存明細點擊流水查詢強制刷新兩條路互不干擾。這一塊會在第7章踩坑部分再展開講。2.4 為什么不用若依這類前后端分離腳手架很多人看到SpringBootVueMyBatisMySQL就條件反射想起若依框架。確實RuoYi這種腳手架把權限、用戶、菜單、代碼生成全都做好了拿來改改就能跑。但這個項目我堅持不用的原因有兩個。第一若依體系過于完整自帶一套RBAC權限模型和定時任務界面對短流量分析這種純內(nèi)部工具來說是負擔光刪菜單就得刪半天。第二項目里統(tǒng)計邏輯有大量自定義的SQL聚合腳手架帶的通用CRUD接口在這塊派不上用場。需要啥能力自己寫一層service就完事了。這套邏輯也跟團隊風格有關項目越貼近業(yè)務越不要套重框架保持代碼透明、可控排查問題時不需要先弄懂框架的攔截鏈。3. 數(shù)據(jù)庫設計短鏈表與點擊日志表的字段推敲3.1 核心表結(jié)構與建表SQL再來拆庫表。整整一個項目跑起來只需要四張表短鏈信息表、點擊明細表、小時聚合表、用戶表。這個設計是按數(shù)據(jù)流向來的短鏈表管映射點擊明細表管事實聚合表管分析用戶表管后臺登錄。字段上沒有刻意做垂直拆分一切以查詢路徑最短為第一原則。短鏈信息表作用是一文定音短碼和長鏈接的映射關系再加上創(chuàng)建人、有效期、狀態(tài)。我加了一個visit_count欄目作為冗余計數(shù)每次點擊異步更新一次。有人會問這個字段和明細表count(*)不是重復嗎確實是冗余但價值巨大短鏈列表頁可以直接用這個字段排序展示不需要每次都去SUM明細表。點擊明細表是體量最大的表每產(chǎn)生一次點擊就寫一條。字段包括短碼、IP、User-Agent、瀏覽器類型、操作系統(tǒng)、設備類型、渠道來源、訪問時間。渠道來源我并沒有做復雜解析而是約定短鏈生成時攜帶channel參數(shù)保存到短鏈接表訪問的時候跟隨短碼一起讀取出來寫入明細。這個設計簡單可靠不需要像獨立埋點那樣搞一套歸因引擎。聚合表是小時表和日報表二合一只保存短碼、維度類型、維度值、PV數(shù)量、獨立訪客數(shù)、統(tǒng)計時間。獨立訪客我用IPUA做了個Hash值去重雖然不及Cookie精確但這個場景已經(jīng)夠了。下面給出核心建表SQL。CREATE TABLE short_url ( id bigint(20) NOT NULL AUTO_INCREMENT, short_code varchar(16) NOT NULL COMMENT 短碼, long_url varchar(2048) NOT NULL COMMENT 原始鏈接, channel varchar(64) DEFAULT COMMENT 渠道標識, title varchar(128) DEFAULT COMMENT 活動名稱, visit_count int(11) DEFAULT 0 COMMENT 累計點擊數(shù), expire_time datetime DEFAULT NULL, status tinyint(4) DEFAULT 1 COMMENT 1有效 0失效, create_time datetime DEFAULT CURRENT_TIMESTAMP, creator varchar(64) DEFAULT , PRIMARY KEY (id), UNIQUE KEY uk_short_code (short_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT短鏈映射表; CREATE TABLE click_log ( id bigint(20) NOT NULL AUTO_INCREMENT, short_code varchar(16) NOT NULL, ip varchar(64) DEFAULT , user_agent varchar(512) DEFAULT , browser varchar(32) DEFAULT , os varchar(32) DEFAULT , device varchar(16) DEFAULT 1 COMMENT 1PC 2移動端, channel varchar(64) DEFAULT , uv_hash varchar(64) DEFAULT , click_time datetime NOT NULL, PRIMARY KEY (id), KEY idx_code_time (short_code,click_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT點擊明細表; CREATE TABLE stat_hourly ( id bigint(20) NOT NULL AUTO_INCREMENT, short_code varchar(16) NOT NULL, stat_date date NOT NULL, stat_hour tinyint(4) NOT NULL, dimension varchar(16) NOT NULL COMMENT channel/device/browser, dimension_value varchar(64) NOT NULL, pv int(11) DEFAULT 0, uv int(11) DEFAULT 0, PRIMARY KEY (id), UNIQUE KEY uk_query_line (short_code,stat_date,stat_hour,dimension,dimension_value) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT小時聚合表;3.2 聚合表不設自增值的考慮說實話我本來也想在最前面直接放一張時間維度的總表統(tǒng)計每天的總PVUV。但后來想想報表頁面的趨勢圖、渠道占比圖、設備分布圖本質(zhì)上都是“同一時間范圍、同一個short_code、按不同維度分組SUM”。所以一張聚合表用dimension字段區(qū)分分組主題反而最省事。查詢趨勢圖就是篩選dimension不可用直接按小時SUM查詢渠道占比就是篩選dimensionchannel按dimension_value分組。一張表通吃查詢SQL寫得簡單索引也建得少。不過這個設計帶來的問題是寫入量增加。原本一條點擊數(shù)據(jù)在一個小時維度上只需要寫一條記錄現(xiàn)在按channel、device、browser三個維度極端情況下要寫三條聚合記錄。但這個量級對MySQL來說毫無壓力而且我實際觀察下來單條點擊記錄的三個維度大概率落在3條聚合記錄以內(nèi)這個成本完全能接受。3.3 索引設計的實戰(zhàn)經(jīng)驗索引設計上除了唯一索引uk_short_code我最看重的是idx_code_time。這個索引的字段順序是短碼在前、時間在后因為所有報表查詢的第一步永遠是按短碼圈定數(shù)據(jù)范圍然后再加時間條件縮小范圍。如果反過來建多小時索引MySQL的索引前綴匹配特性會使時間條件沒法快速定位雖然也能走索引但效果差一個量級。有一點很多初學者容易忽略聚合表的唯一索引uk_query_line一定要建成唯一索引而不是普通索引。光看字段名可能覺得這就是為了查重實際上聚合任務重跑時要用INSERT IGNORE或者ON DUPLICATE KEY UPDATE來冪等寫入。如果沒有唯一索引兜底重跑兩次數(shù)據(jù)就翻倍了。4. 后端核心功能與實現(xiàn)鏈路4.1 短鏈生成算法與防碰撞短碼生成我踩過一輪坑最開始用的UUID截取8位做短碼結(jié)果跑到1萬條就開始出現(xiàn)碰撞。后來改成雪花算法轉(zhuǎn)62進制又發(fā)現(xiàn)生成的短碼太長落在URL里難看。最后采用的自增ID Base62混淆映射每個短鏈生成時插入短鏈表拿到自增主鍵然后把這個主鍵轉(zhuǎn)成62進制字符串長度基本控制在6~8位。這個方案的天然優(yōu)勢是主鍵唯一轉(zhuǎn)換結(jié)果必然唯一根本不用做碰撞檢測。Base62轉(zhuǎn)換的邏輯也很簡單就是用0-9a-zA-Z共62個字符做進制轉(zhuǎn)換。注意生成之后可以再做一次字符混淆比如把第一位字母隨機大小寫防止短碼太規(guī)律被人批量抓取。下面是我實際用的轉(zhuǎn)換工具類核心代碼。public class Base62Util { private static final String BASE62 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ; public static String fromDecimal(long num) { StringBuilder sb new StringBuilder(); while (num 0) { sb.append(BASE62.charAt((int) (num % 62))); num / 62; } return sb.reverse().toString(); } }4.2 點擊埋點接口的異步化設計點擊重定向接口是整個系統(tǒng)里QPS最高的入口。我把邏輯分成三段第一段查緩存拿長鏈接映射第二段構造點擊明細Entity第三段異步落庫并重定向。這里的緩存策略是Caffeine本地緩存過期時間10分鐘短鏈映射查一次DB之后基本不再查第二次。點擊明細的落庫我單獨搞了一個線程池核心線程數(shù)8、最大線程數(shù)16、阻塞隊列長度2000。線程池滿了以后的處理策略用的是CallerRunsPolicy寧可讓請求鏈路本身來寫這條日志也不能因為隊列溢出丟了點擊數(shù)據(jù)。這屬于降級處理的一種保證真實性比保證響應速度更重要。異步任務里同時做三件事插入click_log、更新short_url的visit_count、把聚合增量丟進一個內(nèi)存計數(shù)Map等待定時任務沖刷到stat_hourly。4.3 統(tǒng)計接口與動態(tài)SQL的編寫經(jīng)驗報表接口用MyBatis動態(tài)SQL落地整體思路基本相同換維度就拼SQL。以“渠道占比”接口為例前端傳shortCode、startTime、endTime三個參數(shù)后端在stat_hourly表里篩dimensionchannel然后按dimension_value分組SUM。注意SQL的黑魔法不在聚合而在“按小時補零”。如果某一天某個渠道一單點擊都沒有前端ECharts畫出來的趨勢折線會直接斷掉。補零邏輯我放在Java內(nèi)存里做后端把數(shù)據(jù)庫里已有的記錄查出來之后在循環(huán)里填充缺少的時間點PV UV置0。這個方案比SQL里做遞歸連接表簡單一百倍也容易理解。還有一個比較實用的寫法是統(tǒng)一接口返回結(jié)構時間字段全部格式化好再傳給前端。統(tǒng)計數(shù)據(jù)里最容易出現(xiàn)時區(qū)誤差我在Service層集中用LocalDateTime操作轉(zhuǎn)JSON時配上全局時間格式。這塊配置如果沒做好你會發(fā)現(xiàn)圖表上最新數(shù)據(jù)永遠缺一小時也就是第7章要講的坑之一。4.4 權限控制和參數(shù)校驗的簡化內(nèi)部工具不需要做太重的權限體系我用攔截器加一個簡單的Token機制。用戶登錄之后服務端生成Token存進Redis前端請求頭攜帶Token攔截器校驗通過則放行。這個項目不引入Shiro或者Spring Security因為對于純內(nèi)部可視化系統(tǒng)它們太重了學習成本反而高。參數(shù)校驗方面短鏈創(chuàng)建接口一定得做URL白名單校驗防止有人拿短鏈接口跳轉(zhuǎn)到釣魚站點。做法是用Hutool的UrlValidator類判斷協(xié)議和域名至少保證只能是http/https且不攔截內(nèi)網(wǎng)地址段。5. 前端可視化Vue3ECharts從零搭建儀表盤5.1 工程初始化和環(huán)境配置前端部分我用Vite創(chuàng)建Vue3工程用npm安裝依賴。這里先給一段初始化和安裝依賴的命令省得再去翻文檔。npm create vitelatest short-dashboard -- --template vue cd short-dashboard npm install npm install vue-router4 pinia axios echarts vue-echarts安裝完依賴后第一件事是配好路由?？梢暬撁嬗幸粡埧傆[大屏我配了一個根路徑直接指向Dashboard組件。路由用的history模式理論上更美觀但要注意生產(chǎn)環(huán)境部署時如果沒配Nginx的try_files刷新二級頁面會404。這個問題網(wǎng)上問的人非常多第6章部署部分會給出對應配置。5.2 開發(fā)環(huán)境跨域配置與接口層封裝前后端分離開發(fā)中最煩的就是跨域。開發(fā)環(huán)境下后端在8080端口前端在5173端口直接fetch必然被CORS攔。解決辦法是Vite的server.proxy配置把所有以/api開頭的請求代理到后端的接口地址。為什么以/api開頭就是特意給代理留的標記后端Controller統(tǒng)一加了這個路徑前綴。// vite.config.js export default defineConfig({ server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })接口層我封裝了axios實例在request攔截器里統(tǒng)一加上Token頭response攔截器里統(tǒng)一處理錯誤碼。這里有個小細節(jié)后端返回的JSON字段名用駝峰前端axios拿到的也是駝峰中間不需要afterRequest做字段轉(zhuǎn)換。但如果后端哪天改成下劃線命名就得加映射這個坑先記下。5.3 核心圖表組件落地明細總覽Dashboard我分了四個區(qū)塊第一塊是整體趨勢折線圖顯示所選時間范圍內(nèi)每天的PV和UV第二塊是渠道來源餅圖顯示各個渠道占比第三塊是設備分布環(huán)形圖區(qū)分PC和移動端第四塊是最近點擊的實時滾動表格。每個區(qū)塊都由一個接口驅(qū)動前端用Promise.all并發(fā)請求所有數(shù)據(jù)到齊后一次性更新圖表。ECharts組件的使用上我不推薦在data里存chart實例因為Vue3的響應式代理會試圖劫持ECharts實例的內(nèi)部屬性引發(fā)怪異問題。正確做法是在模板里用ref或者vue-echarts組件讓組件庫自己去管理實例生命周期。圖表容器必須設置固定高度否則初始化時寬度為0圖表畫不出來。這是初學者最常踩的坑。5.4 實時刷新策略與性能取舍實時刷新不能整頁刷新否則圖表會閃。我用setInterval每隔10秒請求一次最近點擊接口只更新滾動表格區(qū)域的數(shù)據(jù)。趨勢圖和占比圖的數(shù)據(jù)刷新頻率設置成60秒一次避免頻繁拉接口造成后端無謂壓力。前端輪詢的坑在于組件銷毀時要清理定時器否則路由切換后定時器還在跑控制臺會爆一堆警告。這里用onUnmounted鉤子清理即可。6. 完整部署教程從源碼到可訪問的線上服務6.1 環(huán)境準備與版本搭配部署前先把環(huán)境準備清楚。我線上用的是一臺2C4G的云服務器系統(tǒng)是CentOS 7。軟件版本搭配上JDK用的1.8對應SpringBoot 2.7.xMySQL用的5.7.44Nginx用的1.20Node.js只在構建前端時用到16.20版本夠用。這個組合是國內(nèi)服務器最穩(wěn)的一檔千萬別在生產(chǎn)裝MySQL 8.0然后連接方式不換后面踩坑一節(jié)會說詳細。MySQL安裝這塊建議直接用rpm包安裝不要用源碼編譯。具體步驟是下載對應版本的rpm包rpm -ivh安裝然后初始化并啟動服務。網(wǎng)上很多教程讓改my.cnf的character_set_serverutf8mb4這一步必須做而且要在初始化之前改好否則建出來的庫默認排序規(guī)則不對中文索引和排序會有很奇怪的行為。6.2 后端打包與啟動命令后端打包只需要在項目根目錄執(zhí)行Maven打包命令。Maven的配置里我把最終產(chǎn)物名設置成short-analysis.jar方便腳本里引用。打包前記得檢查application.yml數(shù)據(jù)庫連接串、Redis地址、日志路徑都要改成生產(chǎn)環(huán)境的值。mvn clean package -DskipTests nohup java -jar short-analysis.jar --spring.profiles.activeprod /data/logs/short.log 21 nohup啟動是Linux服務最樸素的實踐。有人會用systemd寫service但內(nèi)部工具不必上那么重。啟動完之后立刻看日志確認端口和數(shù)據(jù)庫連接正常curl一下健康檢查接口。6.3 前端構建與兩種部署形態(tài)前端部署有兩個選擇。第一個選擇是把dist目錄里的靜態(tài)文件復制到Nginx的html目錄再用Nginx配置反向代理轉(zhuǎn)發(fā)/api請求給后端Java服務。第二個選擇是把dist目錄整個復制到SpringBoot的src/main/resources/static目錄下重新打包最終只用一個Jar跑前端和后端。前面說了我線上用的是第一種方案好處是靜態(tài)文件走Nginx性能更好后面擴容時前端可以掛CDN。前端構建命令是npm run build產(chǎn)物在dist目錄。Nginx的關鍵配置直接看下面這段。server { listen 80; server_name analysis.example.com; location / { root /data/www/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }try_files那行就是為了解決刷新頁面404的問題。如果缺了這行瀏覽器訪問/about路由時Nginx會去磁盤找about目錄找不到就返回404。加了try_files之后所有不存在的路徑都回退到index.html由前端路由接管頁面渲染。6.4 初始化數(shù)據(jù)庫與定時任務驗證數(shù)據(jù)庫初始化和定時任務一起說。項目里我寫了一個schema.sql放在resources/db目錄首次啟動時用Spring的sql.init機制自動執(zhí)行建表語句。但生產(chǎn)環(huán)境我建議關掉自動執(zhí)行手動到服務器上用mysql命令來導入更可控。定時任務方面后端用Spring自帶的Scheduled注解實現(xiàn)了兩個任務每10分鐘把內(nèi)存里的聚合計數(shù)刷進stat_hourly表每1小時執(zhí)行一次全量重算。驗證定時任務是否正常最簡單的方法是看聚合表的最新記錄時間是不是和當前時間匹配同時看應用日志有沒有異常。7. 部署與開發(fā)中踩過的坑完整排查鏈路記錄7.1 MySQL連接失敗的完整排查過程這個坑是上生產(chǎn)環(huán)境時遇到的。本地Windows開發(fā)環(huán)境一切正常代碼部署到Linux服務器后起后端就報Communications link failure。當時第一反應是數(shù)據(jù)庫地址寫錯了檢查application.yml發(fā)現(xiàn)IP和端口都對。然后嘗試在服務器上mysql -h127.0.0.1 -uroot -p連接居然也連不上報錯是Access denied。后來才反應過來是MySQL 5.7安裝時root用戶默認只允許localhost登錄而Java應用用JDBC連接時的host是127.0.0.1跟localhost不完全是一個授權條目。解決方法是手動創(chuàng)建授權用戶。CREATE USER short_userlocalhost IDENTIFIED BY ComplexPwd123!; GRANT ALL PRIVILEGES ON short_db.* TO short_userlocalhost; FLUSH PRIVILEGES;那個報錯還有個常見變形就是MySQL 8.0的caching_sha2_password認證插件問題。舊的JDBC驅(qū)動不支持這個插件報錯是Unable to load authentication plugin。解決方法是下載最新版mysql-connector-java或者在MySQL里把認證插件改成mysql_native_password。我建議這倆方案都做尤其是云數(shù)據(jù)庫默認就是8.0完全跑不了老驅(qū)動。7.2 端口沖突與IDEA啟動參數(shù)配置有一次本地起服務時發(fā)現(xiàn)8080端口被一個Java進程占用idea啟動日志報Web server failed to start看到這句基本可以確定是端口被占。排查命令是netstat -ano | findstr 8080找到占用進程的PID后taskkill /PID /F解決。更規(guī)范的做法是后端啟動配置里帶上--server.port8083這樣臨時指定端口避免和本機其他服務沖突。IDEA里配置SpringBoot的運行參數(shù)時一定注意是Program arguments而不是VM options這兩個填錯位置效果完全不同填到VM options里啟動會被JVM當成非法參數(shù)直接拒絕。7.3 前后端聯(lián)調(diào)CORS問題和Token丟失開發(fā)環(huán)境配了Vite代理后前端理論上不會遇到CORS問題。但我有一次繞過代理直接請求了后端地址結(jié)果瀏覽器報CORS error后端接口雖然返回正常數(shù)據(jù)但被瀏覽器攔截。這里要理解CORS是瀏覽器的安全策略不是后端的強制限制。生產(chǎn)環(huán)境如果Nginx代理配置正確根本不需要在后端開啟CORS。如果硬要在開發(fā)環(huán)境放行后端寫一個CorsFilterallowOrigin設成具體的前端地址就行不要用星號否則帶Cookie的請求依然會被攔。Token丟失這個坑體現(xiàn)在登錄之后前端跳轉(zhuǎn)路由刷新頁面Token就沒了。原因是我把Token放在內(nèi)存變量里刷新后JS重新加載變量自然清空。正確做法是存在localStorage或者sessionStorage里請求攔截器每次從storage里取。這個坑很初級但陣容不齊的團隊里最容易踩到而且表現(xiàn)詭異登錄狀態(tài)一會兒有一會兒沒有。7.4 MyBatis緩存與臟讀問題的實踐復盤前面提到統(tǒng)計Mapper開了二級緩存但我一開始把所有Mapper都開了結(jié)果出了大問題短鏈點擊量接口每次查詢的累計點擊數(shù)和明細對不上。排查思路是先用日志打印SQL發(fā)現(xiàn)第一次查詢打印了SQL第二次查詢直接走緩存沒打印SQL但此時明細表里已經(jīng)新增了點擊數(shù)統(tǒng)計結(jié)果還是舊值。這就是典型的臟讀緩存命中了基于舊數(shù)據(jù)的查詢結(jié)果。解決方案如下只有統(tǒng)計報表Mapper開啟二級緩存點擊流水和短鏈映射Mapper關閉。同時在統(tǒng)計Mapper的flushInterval里設置成60000毫秒讓數(shù)據(jù)最多延遲一分鐘。這里還順帶理解了MyBatis框架里一級緩存的生命周期。一級緩存是SqlSession級別的如果同一個SqlSession里先查后寫再查會存在舊值復用的問題。Spring管理的Mapper實際上每次都創(chuàng)建新SqlSession除非用Transactional包著所以一級緩存問題在這個項目里不嚴重但知道原理是好事。7.5 時區(qū)問題導致統(tǒng)計結(jié)果差8小時這個坑是在定時任務上線第二天發(fā)現(xiàn)的。前一天18點到24點的統(tǒng)計數(shù)據(jù)顯示為0但點擊明細表里明明有數(shù)據(jù)。查看了stat_hourly表發(fā)現(xiàn)數(shù)據(jù)寫進去的時間是第二天凌晨2點到8點整整差了8個小時。這就是Java應用默認時區(qū)和MySQL時區(qū)不一致導致的。CentOS系統(tǒng)時區(qū)是UTC而MySQL連接串里的serverTimezone沒指定JDBC驅(qū)動就用系統(tǒng)時區(qū)解析DATETIME最后數(shù)據(jù)落庫整體偏移。修復方案是在JDBC連接串上明確指定serverTimezoneAsia/Shanghai同時應用啟動參數(shù)加-Duser.timezoneAsia/Shanghai。這里注意MySQL 8.0版本自帶的時區(qū)表默認內(nèi)容很少如果連接的時候指定Asia/Shanghai報錯需要用mysql_tzinfo_to_sql命令導入系統(tǒng)時區(qū)表或者干脆在MySQL配置里default-time-zone8:00。這三種方案我最后一起上了確保所有環(huán)節(jié)一致。7.6 前端圖表初始化和刷新時的心得圖表初始化那個坑是這樣的接口數(shù)據(jù)還沒返回時ECharts容器已經(jīng)渲染但尺寸為0數(shù)據(jù)回來后圖表顯示空白。排查時發(fā)現(xiàn)路Chart的option設置沒問題手動resize一下就能顯示這就是典型的“數(shù)據(jù)驅(qū)動渲染時容器尺寸未就緒”。解決方案不是很復雜在組件mounted后先對圖表實例調(diào)用一次resize或者給圖表的wrapper設置一個最小高度。常用做法是給容器固定的高度比如dashboard-trend樣式里直接height: 320px問題就沒了。另一個心得是接口數(shù)據(jù)格式和圖表數(shù)據(jù)格式一定要在前端做適配層不要把后端返回的JSON直接塞給ECharts。ECharts的series.data接受數(shù)組對象但后端返回的分組統(tǒng)計結(jié)果往往是Map或者List嵌套直接塞過去會報錯。我在utils/chartAdapter.js里寫了一套數(shù)據(jù)轉(zhuǎn)換函數(shù)專門把后端聚合結(jié)果轉(zhuǎn)成ECharts需要的格式。這樣后端接口只管數(shù)據(jù)語義前端圖表只管展示職責清晰。8. 上線后的數(shù)據(jù)校驗與后續(xù)擴展建議系統(tǒng)上線后第一件事不是看圖表漂不漂亮而是校驗數(shù)據(jù)準確性。我最常用的一套校驗邏輯是拿聚合表的24小時SUM值和點擊明細表按天的COUNT比較誤差超過1%就要查問題。誤差來源一般有兩個一是定時任務還沒跑完統(tǒng)計已經(jīng)被前端拉走二是去重UV的邏輯出錯。校驗腳本用一條SQL就能搞定。SELECT (SELECT COUNT(*) FROM click_log WHERE click_time 2024-01-01 00:00:00 AND click_time 2024-01-02 00:00:00) AS detail_pv, (SELECT IFNULL(SUM(pv), 0) FROM stat_hourly WHERE stat_date 2024-01-01) AS agg_pv;兩列數(shù)值對不上就說明鏈路有問題需要逐個環(huán)節(jié)排查。后續(xù)擴展方向上如果數(shù)據(jù)量真的漲到千萬級點擊、每天上百萬條明細那再考慮把click_log按月分區(qū)或者把統(tǒng)計模塊抽出來用Flink做實時計算。老實說以我目前線上這個量級MySQL單庫單表加定時聚合完全扛得住不需要盲目上大數(shù)據(jù)組件畢竟技術棧越復雜排查問題成本越高。這個系統(tǒng)做下來最大的體會是前后端分離項目的復雜度不在于某個單獨的框架有多難而在于數(shù)據(jù)從采集到存儲再到展示的每一環(huán)都要保持語義一致和格式統(tǒng)一。誰能在這些環(huán)節(jié)上做得細致誰的項目就能穩(wěn)定跑下去。