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