我最近剛把一套企業(yè)級商城系統(tǒng)的源碼從頭到尾梳理完技術(shù)棧正好就是標(biāo)題里那套SpringBoot Vue MyBatis MySQL。項目代號叫“米家商城”配套的運(yùn)營后臺我們內(nèi)部叫“ABO”全稱是 Admin-Back-office-Operations就是給運(yùn)營、客服、倉儲人員用的管理操作平臺。如果你正準(zhǔn)備做類似的全棧電商項目或者只是想把前后端分離的這套組合吃透那么這篇東西應(yīng)該能幫你少踩幾天的坑。我盡量不寫教科書式的廢話直接講項目里真實(shí)遇到的設(shè)計決策、代碼思路和上線前必須留意的細(xì)節(jié)。先說結(jié)論這個組合放在今天依然是非常穩(wěn)妥的工業(yè)化選擇。SpringBoot負(fù)責(zé)快速封裝業(yè)務(wù)接口Vue負(fù)責(zé)前端交互和工程化MyBatis把SQL操作權(quán)完全還給開發(fā)人員MySQL則穩(wěn)扎穩(wěn)打地扛住核心業(yè)務(wù)數(shù)據(jù)。別看網(wǎng)上天天吹微服務(wù)、吹云原生對于絕大多數(shù)年交易額在千萬級別的商城項目來說這套架構(gòu)的性價比其實(shí)是最高的。原因很簡單團(tuán)隊招聘成本低、排錯鏈路短、部署運(yùn)維也輕。下面我按整個項目的落地順序把關(guān)鍵設(shè)計一步步拆開講。1. 一個真實(shí)電商項目的技術(shù)選型與設(shè)計取舍1.1 項目為什么鎖定這四件套立項之初我們也討論過用不用Spring Cloud、要不要上MongoDB之類的選項。最后拍板用SpringBootVueMyBatisMySQL不是因?yàn)楸Ｊ囟腔谌齻€硬指標(biāo)團(tuán)隊熟悉度、交付周期、運(yùn)維成本。項目團(tuán)隊一共六個人后端三個、前端兩個、測試一個。后端里真正精通Spring Cloud整套組件的其實(shí)只有一個如果強(qiáng)行上微服務(wù)光搭基礎(chǔ)設(shè)施就要拉長兩周。而SpringBoot可以在一天之內(nèi)把骨架工程跑起來加上它內(nèi)置的Tomcat和自動配置能讓團(tuán)隊集中精力寫業(yè)務(wù)而不是調(diào)框架。前端用Vue也是一樣的邏輯大家熟組件生態(tài)全招聘市場上也容易補(bǔ)人。MyBatis和MySQL的搭配則更多是從SQL可控性考慮的。商城類業(yè)務(wù)有很多復(fù)雜的多表關(guān)聯(lián)查詢比如“根據(jù)規(guī)格參數(shù)篩選SKU”、“查詢訂單時帶上商品快照和物流信息”這些用JPA/Hibernate寫起來非常別扭最后還得補(bǔ)原生SQL。MyBatis允許我們直接維護(hù)SQL同時用動態(tài)SQL處理不確定的查詢條件剛好命中電商場景。MySQL則讓數(shù)據(jù)庫容量和熟練度都處在舒適區(qū)先用主從緩存頂住壓力真到了海量數(shù)據(jù)再考慮分庫也不遲。1.2 商城核心鏈路與ABO管理系統(tǒng)的定位整個米家商城分兩個端用戶端商城和ABO后臺管理系統(tǒng)。用戶端的核心鏈路很常規(guī)瀏覽商品 - 加購物車 - 下單 - 支付 - 發(fā)貨 - 確認(rèn)收貨。ABO這邊的核心鏈路則圍繞運(yùn)營動作展開商品上下架、價格調(diào)整、庫存同步、訂單改價、退款審核、物流單號回填等。我特別想強(qiáng)調(diào)ABO系統(tǒng)的定位因?yàn)樗?jīng)常被當(dāng)作普通CRUD后臺來做結(jié)果上線后運(yùn)營抱怨一堆。ABO的核心不是“能管理數(shù)據(jù)”而是“能高效、安全地完成業(yè)務(wù)操作”。比如客服在ABO里給用戶退款系統(tǒng)需要同時完成訂單狀態(tài)變更、支付渠道退款請求、庫存回滾、操作日志記錄四個動作。如果只做了數(shù)據(jù)庫字段更新那就會出現(xiàn)訂單顯示已退款但用戶沒收到錢的問題。所以ABO在設(shè)計上必須和商城共用同一套Service層不能簡單復(fù)制一份Mapper去讀寫訂單表。2. 米家商城業(yè)務(wù)域拆分從商品到訂單的狀態(tài)流轉(zhuǎn)設(shè)計2.1 商品與庫存模型SKU/SPU的落地商城第一個要建模的是商品域。我們采用了SPUStandard Product Unit標(biāo)準(zhǔn)產(chǎn)品單元和SKUStock Keeping Unit庫存量單位兩層模型。SPU是商品的概念層比如“米家臺燈1S”SKU是具體可下單的規(guī)格層比如“白色插電版”庫存和價格都掛在SKU上。這個模型本身不新鮮但落地時有幾個坑要提前處理。第一是規(guī)格屬性的JSON存儲問題我見過有人把規(guī)格拆成十幾個字段結(jié)果每次加規(guī)格都要改表。我們采用的是規(guī)格名稱為鍵、規(guī)格值為值的JSON字符串存儲MySQL的json類型直接支持索引和查詢前端渲染時直接解析兼容性很好。第二是商品詳情的多端聯(lián)動詳情頁由富文本、圖片輪播、視頻地址、參數(shù)表格組成我建議單獨(dú)建一張商品詳情表和SPU一對一關(guān)聯(lián)避免在SPU表里塞大字段。庫存數(shù)據(jù)我分了兩個維度SKU可用庫存和SKU鎖定庫存?？捎脦齑媸钦嬲苜u的鎖定庫存是下單但未支付時的暫扣。這樣設(shè)計方便處理“超賣”問題后面會講到具體的扣減邏輯。2.2 訂單與支付流程的狀態(tài)機(jī)設(shè)計訂單狀態(tài)是最容易寫崩的部分。我們定義了如下狀態(tài)集待支付、待發(fā)貨、待收貨、已完成、已關(guān)閉、售后中。所有狀態(tài)變更都必須經(jīng)過一個獨(dú)立的訂單狀態(tài)機(jī)類不允許在Mapper層隨便改狀態(tài)字段。下面這張表格展示了核心狀態(tài)流轉(zhuǎn)路徑當(dāng)前狀態(tài)觸發(fā)動作下一狀態(tài)涉及系統(tǒng)待支付用戶付款待發(fā)貨支付回調(diào)、訂單服務(wù)待支付超時未付已關(guān)閉定時任務(wù)、庫存服務(wù)待發(fā)貨商家發(fā)貨待收貨物流服務(wù)、訂單服務(wù)待收貨用戶確認(rèn)收貨已完成訂單服務(wù)待收貨超時自動確認(rèn)已完成定時任務(wù)已完成用戶申請售后售后中售后工單、支付渠道狀態(tài)機(jī)的好處是讓流轉(zhuǎn)路徑清晰可控每個動作后面都可以加鉤子函數(shù)。比如從“待支付”到“待發(fā)貨”鉤子函數(shù)里要先解鎖庫存并扣減可用庫存再生成履約單推給倉儲系統(tǒng)。如果先改狀態(tài)再扣庫存一旦扣失敗訂單就卡在狀態(tài)錯亂里了。我們在代碼里把狀態(tài)變更和庫存操作放在同一個事務(wù)里后面事務(wù)部分會細(xì)講。2.3 多級分銷與會員價本次實(shí)現(xiàn)中的業(yè)務(wù)擴(kuò)展點(diǎn)米家商城這個項目里還接了一個分銷需求用戶A推薦用戶B下單A能拿到一定比例的傭金。這個邏輯并不復(fù)雜但要注意兩點(diǎn)。第一推薦關(guān)系表里要記錄“上下線關(guān)系生效時間”避免歷史訂單的傭金計算混亂。第二傭金結(jié)算做成異步任務(wù)用戶確認(rèn)收貨后再觸發(fā)避免在主訂單事務(wù)里做太多計算。會員價則是在SKU價格之外再加一檔“會員售價”。我們把價格放在單獨(dú)的price表中包含SKU_ID、價格類型普通/會員/活動、價格值、生效時間。這樣比直接在SKU上加會員價字段靈活得多雙十一時可以增加“活動價”類型而不改表結(jié)構(gòu)。3. MySQL數(shù)據(jù)庫設(shè)計核心表結(jié)構(gòu)、索引與分庫分表思路3.1 商品、訂單、用戶核心表結(jié)構(gòu)詳解數(shù)據(jù)庫是整套商城的心臟我給出幾個核心表的關(guān)鍵字段設(shè)計方便你直接參考。商品表spuid主鍵spu_codeSPU編碼唯一索引title標(biāo)題cover_url主圖detail_id關(guān)聯(lián)詳情表status上下架狀態(tài)created_time / updated_time時間戳SKU表skuidspu_id關(guān)聯(lián)SPUsku_codeSKU編碼唯一索引specs規(guī)格JSON比如 {顏色:白色,版本:插電版}可用庫存、鎖定庫存用int非負(fù)數(shù)price_id關(guān)聯(lián)價格表status訂單表ordersidorder_sn訂單號唯一索引用全局ID生成器user_id下單用戶spu_id、sku_id下單時的核心信息sku_snapshot下單時的SKU快照J(rèn)SON防止后續(xù)修改影響歷史quantity數(shù)量order_status狀態(tài)字段total_amount / pay_amount金額用decimal(10,2)receiver_info收貨人JSONcreated_time用戶表t_useridphone手機(jī)號唯一索引nicknameinvite_code邀請碼parent_id上級推薦人ABO后臺表后臺員工、角色、權(quán)限、操作日志sys_user后臺賬號密碼用BCrypt存儲sys_role角色sys_menu菜單/按鈕權(quán)限sys_operation_log操作日志3.2 索引策略從慢查詢?nèi)罩痉赐扑饕O(shè)計索引不是建得越多越好而是要從實(shí)際查詢路徑出發(fā)。上線第一周我們開了MySQL慢查詢?nèi)罩鹃撝翟O(shè)置為1秒然后收集了一天里最慢的20條SQL。結(jié)果發(fā)現(xiàn)兩類查詢最危險一是按用戶ID查詢訂單列表時如果只建了user_id普通索引ORDER BY created_time會讓文件排序非常慢二是后臺運(yùn)營按訂單號模糊查詢時用了LIKE %xxx%直接導(dǎo)致全表掃描。對第一個問題建議建聯(lián)合索引user_id, created_time可以同時滿足WHERE和ORDER BY。對第二個問題我們的方案是讓運(yùn)營盡可能使用完整訂單號并給order_sn建唯一索引如果實(shí)在要模糊搜就單獨(dú)建一張訂單搜索輔助表用Elasticsearch或簡單的關(guān)鍵字表來兜底避免在核心訂單表上跑模糊查詢。另外一個容易被忽視的點(diǎn)是索引列上的函數(shù)操作比如WHERE DATE_FORMAT(created_time, %Y-%m-%d) 2025-01-01這種寫法讓索引直接失效。正確做法是查詢范圍created_time 2025-01-01 00:00:00 AND created_time 2025-01-02 00:00:00。3.3 數(shù)據(jù)量增長后的問題分庫分表與讀寫分離預(yù)留雖然單庫單表能撐一陣子但我們要提前預(yù)留擴(kuò)展點(diǎn)。我的建議是訂單表按照user_id哈希分成256張子表分表鍵用user_id這樣可以保證同一個用戶的訂單都在同一個表里方便分頁查詢。商品表數(shù)據(jù)量相對小可以先做讀寫分離不急著分表。讀寫分離的話我們在SpringBoot里配置了動態(tài)數(shù)據(jù)源利用DataSource注解把只讀方法路由到從庫。注意要點(diǎn)事務(wù)必須是只讀的才能走從庫否則主從延遲會帶來臟讀。我們實(shí)際遇到過一次問題用戶支付成功后跳轉(zhuǎn)訂單詳情結(jié)果讀從庫延遲頁面顯示“待支付”把用戶嚇一跳。后來做了“支付成功后強(qiáng)制主庫讀”的標(biāo)記才解決。4. SpringBoot MyBatis 落地細(xì)節(jié)Mapper、事務(wù)與緩存4.1 XML與注解的選擇為什么推薦XML管理復(fù)雜SQL我接手項目后把團(tuán)隊里的規(guī)則統(tǒng)一了簡單CRUD用MyBatis注解復(fù)雜聯(lián)動查詢一律使用XML Mapper。原因是XML可以顯式地管理SQL并且支持動態(tài)SQL的標(biāo)簽比如 、 、 。當(dāng)查詢條件超過三個時注解方式會變得極其難以閱讀而XML配合縮進(jìn)和注釋代碼評審時可以非常清晰地看到SQL全貌。舉一個我們經(jīng)常用的動態(tài)更新案例ABO后臺編輯商品時只更新非空字段update idupdateSkuSelective parameterTypemap UPDATE sku set if testprice ! nullprice_id #{price},/if if teststatus ! nullstatus #{status},/if if testspecs ! nullspecs #{specs},/if updated_time NOW() /set WHERE id #{id} /update這是把“部分字段更新”的控制權(quán)全部拉到SQL層避免了寫一堆Java if判斷來拼接Update對象。4.2 事務(wù)邊界下單場景的分布式事務(wù)隱患下單接口是最典型的需要精確定義事務(wù)邊界的地方。簡化版代碼如下Transactional(rollbackFor Exception.class) public OrderResult createOrder(CreateOrderDTO dto) { // 1. 鎖定庫存 int updated skuStockMapper.lockStock(dto.getSkuId(), dto.getQuantity()); if (updated 0) { throw new BizException(庫存不足); } // 2. 創(chuàng)建訂單 Order order buildOrder(dto); orderMapper.insert(order); // 3. 清空購物車 cartMapper.deleteByUserAndSku(dto.getUserId(), dto.getSkuId()); return success(order); }這里每個步驟都依賴同一個數(shù)據(jù)庫連接事務(wù)所以從理論上講中間出現(xiàn)異常都能回滾庫存和訂單不會不一致。但要注意兩個隱藏風(fēng)險第一lockStock方法里的SQL是UPDATE sku SET locked_stock locked_stock #{quantity}, available_stock available_stock - #{quantity} WHERE id #{skuId} AND available_stock #{quantity}。這行SQL本身在MySQL的InnoDB引擎下會鎖住那一行SKU記錄。如果同一時間很多用戶搶購?fù)籗KU后續(xù)請求都會阻塞在這把行鎖上造成吞吐量下降。我們的應(yīng)對方式是在高并發(fā)場景下改成Redis預(yù)扣庫存異步扣減數(shù)據(jù)庫庫存或者使用樂觀鎖加版本號重試。第二事務(wù)里盡量不要做遠(yuǎn)程調(diào)用比如下單成功后再調(diào)用第三方支付接口這會拖長數(shù)據(jù)庫事務(wù)讓連接池迅速耗盡。我們在項目里把支付動作放在訂單創(chuàng)建成功之后不在同一個事務(wù)里訂單狀態(tài)先置為“待支付”然后去調(diào)支付網(wǎng)關(guān)。即使支付網(wǎng)關(guān)超時也能通過定時任務(wù)去對賬保證最終一致。4.3 MyBatis緩存機(jī)制與一次緩存失效問題的追查MyBatis的二級緩存我們一開始沒打算用但為了提升熱點(diǎn)SKU的查詢性能給商品模塊開了二級緩存。結(jié)果上線后出現(xiàn)一個詭異的Bug后臺運(yùn)營改了某個商品的標(biāo)題前臺頁面過了一個小時還是舊標(biāo)題。排查鏈路是這樣走的先懷疑是瀏覽器緩存清掉后仍然復(fù)現(xiàn)然后看Vue端是否有狀態(tài)緩存也沒有最后查MyBatis的二級緩存發(fā)現(xiàn)默認(rèn)的PerpetualCache是進(jìn)程內(nèi)本地緩存后臺管理系統(tǒng)和商城服務(wù)是同一個SpringBoot進(jìn)程理論上應(yīng)該能更新。問題出在我們的緩存命名空間設(shè)置商品查詢Mapper的namespace是com.xxx.mapper.SpuMapper但后臺更新商品時更新的是SpuDetailMapper兩個Mapper各自的緩存沒有聯(lián)動導(dǎo)致SpuMapper的二級緩存里還是一小時前的舊數(shù)據(jù)。最后方案很簡單要么關(guān)閉商品查詢的二級緩存要么在更新時手動調(diào)用清空相關(guān)緩存。我們最終選擇了用Spring Cache注解 Redis緩存來做統(tǒng)一緩存管理因?yàn)镸yBatis的二級緩存跟Transactional結(jié)合時如果有多數(shù)據(jù)源還容易出現(xiàn)臟數(shù)據(jù)不如緩存統(tǒng)一走Redis可控。5. Vue前端工程化動態(tài)路由、狀態(tài)管理與移動端適配5.1 基于Vue Router的動態(tài)路由與權(quán)限控制用戶端商城的前端相對簡單ABO管理系統(tǒng)倒是花了不少心思。ABO要求不同角色的登錄用戶看到不同的菜單甚至同一菜單下按鈕的可見性也由權(quán)限控制。我們采用動態(tài)路由方案用戶登錄后后端返回當(dāng)前角色能訪問的路由配置前端用router.addRoute動態(tài)掛載。具體流程是用戶輸入賬號密碼登錄成功后拿到token請求 /sys/user/permissions 接口返回菜單樹和按鈕權(quán)限標(biāo)識前端把菜單樹遞歸轉(zhuǎn)換成Vue Router的RouteRecordRaw數(shù)組通過router.addRoute注冊側(cè)邊欄渲染時也基于同一份菜單樹保證路由和菜單一致。這里一定要提防一個問題動態(tài)路由只在全局前置守衛(wèi)里判斷了一次如果用戶刷新頁面Vue Router的緩存會被清空必須重新拉取權(quán)限。我們當(dāng)時的做法是在main.js初始化時檢查本地是否已有token并有用戶信息如果沒有完整路由就重新走一遍動態(tài)添加邏輯。否則就會出現(xiàn)“登錄后能訪問一刷新就白屏”的經(jīng)典坑。5.2 狀態(tài)管理Vuex與Pinia的取舍商城這個項目啟動時我們還用的是Vue2所以狀態(tài)管理用的Vuex。如果你是Vue3新項目我建議直接用Pinia更簡潔且天然支持組合式API。不過這里的核心不是選哪個而是明確哪些狀態(tài)需要放到全局Store哪些不需要。我把購物車、用戶信息、當(dāng)前訂單的支付倒計時放到了全局Store。商品列表頁的篩選條件、詳情頁的當(dāng)前SKU規(guī)格選擇等盡量不要放全局否則切換頁面時狀態(tài)殘留會導(dǎo)致各種莫名其妙的問題。有一個典型例子用戶從商品詳情頁選好規(guī)格加入購物車成功后跳轉(zhuǎn)購物車頁面購物車頁面讀取到了上一個頁面殘留的規(guī)格狀態(tài)導(dǎo)致展示異常。后來我們增加了狀態(tài)重置邏輯進(jìn)入頁面時主動清空非必要緩存。5.3 組件庫選型與移動端適配實(shí)戰(zhàn)用戶端商城的移動端我們選擇了uni-app一套代碼同時覆蓋H5和小程序。ABO管理系統(tǒng)則使用桌面端組件庫Element UI配合Vue2的生態(tài)非常成熟。兩個端分開維護(hù)避免在同一個工程里混用組件庫導(dǎo)致包體積失控。移動端適配方面我建議規(guī)范使用viewport單位配合rem方案。我們的基準(zhǔn)是設(shè)計稿750px寬根字號設(shè)置37.5px組件庫內(nèi)部自帶響應(yīng)式則直接用百分比。有一個實(shí)際經(jīng)驗(yàn)圖片列表使用懶加載但懶加載組件在低端Android機(jī)上容易出現(xiàn)閃爍后來我們把圖片區(qū)域的高度提前用占位比例鎖定寬度以容器為準(zhǔn)解決了滾動時的高度跳動問題。這類細(xì)節(jié)對商城首屏體驗(yàn)影響很大值得多花時間打磨。6. ABO管理系統(tǒng)權(quán)限模型、操作審計與低代碼思路6.1 ABO系統(tǒng)的整體功能結(jié)構(gòu)ABO覆蓋的功能包括商品管理、訂單管理、用戶管理、營銷管理、財務(wù)結(jié)算、系統(tǒng)設(shè)置、操作日志。每個模塊在導(dǎo)航上都有對應(yīng)的菜單子頁面則承載各類明細(xì)操作。我用一張表格列出主要模塊和核心交互模塊核心交互商品管理商品上下架、SKU編輯、審核、批量改價訂單管理訂單查詢、發(fā)貨、改價、關(guān)閉、備注用戶管理用戶列表、等級設(shè)置、邀請關(guān)系查看營銷管理優(yōu)惠券創(chuàng)建、活動配置、分銷傭金設(shè)置財務(wù)結(jié)算訂單對賬、退款審核、數(shù)據(jù)報表系統(tǒng)設(shè)置管理員維護(hù)、角色權(quán)限、數(shù)據(jù)字典ABO的頁面請求頻率不高但對數(shù)據(jù)一致性要求極高所以前端在提交操作時要有確認(rèn)提示后端則需要對每個寫操作做冪等校驗(yàn)。6.2 基于RBAC的權(quán)限模型擴(kuò)展數(shù)據(jù)權(quán)限與操作日志權(quán)限模型我們采用經(jīng)典RBAC用戶-角色-權(quán)限。權(quán)限細(xì)化到按鈕級別比如“商品管理-編輯按鈕”就是一個權(quán)限碼。后端使用Spring Security的PreAuthorize注解做接口控制PreAuthorize(hasAuthority(product:edit)) PostMapping(/product/edit) public Result editProduct(RequestBody ProductEditDTO dto) { return productService.edit(dto); }但RBAC只解決了“能不能操作”的問題沒解決“能操作哪些數(shù)據(jù)”的問題。比如運(yùn)營A只能管理自己負(fù)責(zé)的商品分類客服B只能查看自己創(chuàng)建的售后工單。我們擴(kuò)展了“數(shù)據(jù)權(quán)限”配置角色上增加數(shù)據(jù)范圍字段取值包括全部、本部門、本人。后端在查詢時自動拼接SQL條件例如select idselectProductPage resultType... SELECT * FROM spu where if testdataScope SELF AND created_by #{userId} /if if testdataScope DEPT AND created_by IN (SELECT user_id FROM sys_user WHERE dept_id #{deptId}) /if /where /select操作日志是審計必需項。我們在ABO統(tǒng)一封裝了一個OperationLog注解在需要記錄的方法上標(biāo)注操作類型通過AOP自動記錄操作人、操作時間、請求參數(shù)、響應(yīng)結(jié)果和IP地址。這個日志不能只寫成功記錄異常操作也要記錄否則運(yùn)營誤操作后沒有證據(jù)扯皮都扯不清。6.3 用設(shè)計稿驅(qū)動前端頁面后臺系統(tǒng)的標(biāo)準(zhǔn)化開發(fā)流程做ABO這類后臺系統(tǒng)最浪費(fèi)時間的不是寫代碼而是界面規(guī)范不統(tǒng)一。今天這個程序員給表格加了個“導(dǎo)出”按鈕明天那個程序員把彈窗按鈕放在左側(cè)運(yùn)營用起來非常別扭。我們的做法是固定一套頁面模板列表頁統(tǒng)一左上方搜索區(qū)、右側(cè)表格、底部翻頁編輯頁統(tǒng)一彈出式Dialog或抽屜詳情頁統(tǒng)一只讀描述列表。前端寫了一批通用組件——SearchForm、DataTable、ModalForm、DetailDescriptions。新頁面通過配置這些組件的字段數(shù)組即可完成80%的開發(fā)量相當(dāng)于一個輕量的低代碼方案。這樣也帶來了一個好處新增菜單時后端只需提供對應(yīng)的CRUD接口前端復(fù)制一個現(xiàn)有頁面改改配置半小時就能上線一個新功能。運(yùn)營和產(chǎn)品都非常喜歡這種效率。7. 上線前必做的壓測、安全加固與問題排查7.1 壓測過程中發(fā)現(xiàn)的熱點(diǎn)行鎖問題我們的下單接口在壓測到200并發(fā)時數(shù)據(jù)庫出現(xiàn)大量鎖等待。原因前面提過庫存扣減SQL鎖定同一行SKU記錄。當(dāng)時用JMeter壓測TPS卡在80左右thread dump里大量線程處于等待鎖狀態(tài)。解決思路有三個第一把“可用庫存”和“鎖定庫存”字段拆到單獨(dú)一張庫存流水表每次操作插入一條流水然后匯總計算剩余庫存這樣避免在同一行上反復(fù)update第二引入Redis預(yù)扣庫存用Lua腳本保證原子性數(shù)據(jù)庫庫存通過異步任務(wù)最終扣減第三熱門SKU切割庫存行比如一個SKU拆成10個子庫存記錄隨機(jī)選一個扣減減少行鎖競爭。最終實(shí)戰(zhàn)我選了方案二因?yàn)閷?shí)現(xiàn)相對簡單對業(yè)務(wù)代碼改動小。Redis key設(shè)計為stock:{skuId}值就是可用庫存。下單時執(zhí)行Lua腳本if redis.call(get, KEYS[1]) - ARGV[1] 0 then return redis.call(decrby, KEYS[1], ARGV[1]) else return -1 end數(shù)據(jù)庫中則把庫存扣減放到異步任務(wù)里。壓測結(jié)果表明TPS從80提升到700以上效果明顯。7.2 安全加固參數(shù)校驗(yàn)、SQL注入與XSS的防護(hù)實(shí)踐電商系統(tǒng)比較容易成為攻擊目標(biāo)所以安全加固這塊我單獨(dú)提一下。第一所有對外接口要經(jīng)過參數(shù)校驗(yàn)框架使用javax.validation的NotNull、Size、Pattern等注解。最容易被忽視的是金額和數(shù)量字段必須限制范圍比如訂單數(shù)量不能超過99單價不能為負(fù)數(shù)。我們曾遇到一個測試小伙伴用負(fù)數(shù)的數(shù)量下單結(jié)果金額變成負(fù)數(shù)還好是測試環(huán)境不然就是事故。第二SQL注入。由于MyBatis的#{}會轉(zhuǎn)義參數(shù)所以大部分注入漏洞被天然堵住。但有一次開發(fā)圖方便把動態(tài)排序字段直接拼接了Order By后面的部分這地方不能使用#{}如果不對字段做白名單校驗(yàn)就會產(chǎn)生注入風(fēng)險。我的做法是維護(hù)一個排序字段白名單orderBy只能是allowedMap中的key否則強(qiáng)制使用默認(rèn)排序。第三XSS攻擊。后臺系統(tǒng)的輸入框比較多運(yùn)營可能會直接粘貼一些包含腳本的內(nèi)容。我們使用全局過濾器對請求體中的字符串進(jìn)行HTML標(biāo)簽轉(zhuǎn)義存儲時保持轉(zhuǎn)義后的內(nèi)容展示時再通過富文本組件的安全配置過濾。需要注意如果富文本需要保留圖片和超鏈接不能簡單全文轉(zhuǎn)義而是要按需配置白名單標(biāo)簽。7.3 一次內(nèi)存溢出排查從OOM到dump分析的思路上線后大概第三周ABO系統(tǒng)某天下午突然頻繁Full GC最后直接OutOfMemoryError。當(dāng)時我從表象判斷是導(dǎo)出功能引起的因?yàn)檫\(yùn)營在使用“導(dǎo)出全部訂單”時系統(tǒng)會在內(nèi)存里把全部訂單列表一次性生成Excel數(shù)據(jù)量達(dá)到幾十萬條時HashMap和List對象把堆撐爆了。這也是一個很典型的教訓(xùn)后臺列表的“導(dǎo)出”必須帶去異步化。壓縮回方案后我們把導(dǎo)出改成異步任務(wù)先生成CSV臨時文件再通過消息推送提示運(yùn)營下載。對內(nèi)存里的查詢結(jié)果則必須做分頁循環(huán)去讀取而不是一次性List裝入內(nèi)存while (true) { ListOrder pageList orderMapper.selectPage(page, 1000); if (CollectionUtils.isEmpty(pageList)) break; appendToCsv(pageList, writer); page; }此外我們給JVM加了-Xmx4g并配置了HeapDumpOnOutOfMemoryError參數(shù)。出問題時直接拿到dump文件用MAT分析出是org.apache.poi.xssf.usermodel.XSSFWorkbook占用了超過80%的空間這才定位到根因。排查內(nèi)存問題就是這么枯燥先看參數(shù)再看dump最后對應(yīng)到代碼熱點(diǎn)。踩完這一圈坑整個項目的穩(wěn)定性才算真正立住了。最后再分享一點(diǎn)個人體會企業(yè)級商城項目最考驗(yàn)人的不是某個單一技術(shù)而是把所有技術(shù)串起來后的數(shù)據(jù)一致性和邊界梳理能力。SpringBoot、Vue、MyBatis、MySQL這套東西你大概率都認(rèn)識但真正把它們組合成一套能穩(wěn)定運(yùn)營的系統(tǒng)需要大量“摳細(xì)節(jié)”的時刻。比如訂單狀態(tài)機(jī)的每一步校驗(yàn)、事務(wù)的邊界、SQL的索引、前端路由的權(quán)限控制每一個點(diǎn)都可能成為上線后的定時炸彈。希望這篇梳理能給你一些提前預(yù)判的參考少走幾段彎路。