簡介尚品甄選電商平臺全棧開發(fā)項目資料包面向具備Java基礎(chǔ)并希望掌握微服務(wù)架構(gòu)的開發(fā)者用于解決從零搭建可擴展、可維護電商系統(tǒng)的實踐需求。內(nèi)容涵蓋基于Java17與Spring Cloud微服務(wù)的前后端代碼、用戶與商品訂單管理系統(tǒng)以及Redis緩存、MinIO對象存儲、Docker容器化部署等完整集成方案覆蓋用戶注冊登錄、商品瀏覽、購物車、訂單管理等核心業(yè)務(wù)流程。壓縮包共505個文件整體約3.06MB主要包含185個Java源碼、99個JS腳本、52個Vue組件、52個XML配置、17個YAML環(huán)境配置及圖片、SQL、Dockerfile、開發(fā)說明文檔等目錄結(jié)構(gòu)清晰便于按模塊對照學(xué)習(xí)。目前已有82人學(xué)習(xí)下載適合用于電商項目實戰(zhàn)練習(xí)、微服務(wù)架構(gòu)設(shè)計參考或畢業(yè)設(shè)計拓展。同時附帶詳細開發(fā)文檔與附贈資源可幫助理解代碼結(jié)構(gòu)、部署流程及各微服務(wù)組件的協(xié)作方式快速遷移應(yīng)用到自有項目之中。1. 這個項目是什么一套把 Java17、SpringCloud 和中間件串起來的電商全棧實踐很多做后臺或全棧的同學(xué)看到“Java17 與 SpringCloud 微服務(wù)架構(gòu)”這個組合第一反應(yīng)是“我是不是要裝一堆中間件、連不連得起來”。實際上這套電商平臺項目的實踐價值就是把一條完整鏈路講清楚了Java17 編譯器與 SpringBoot 3.x 的匹配、SpringCloud 里注冊中心與網(wǎng)關(guān)的分工、Redis 緩存和 MinIO 文件存儲的接入以及最后的 Docker 容器化部署。適合兩類人一類是畢業(yè)設(shè)計或課設(shè)要交微服務(wù)作品的學(xué)生另一類是在單體系統(tǒng)里待久了、想看看典型分布式方案怎么落地的開發(fā)者。它不像是“造一個淘寶”更像是一條可以反復(fù)復(fù)現(xiàn)走通的技術(shù)主線值得照著敲一遍再按自己的業(yè)務(wù)改。2. 架構(gòu)拆解五類基礎(chǔ)服務(wù)怎么分工選型理由與版本匹配2.1 Java17 不是換個 JDK 版本那么簡單Spring Boot 3.x 的兼容矩陣標題把 Java17 放在最前面是有原因的。Java17 是 LTS 版本但在 Spring Boot 3.x 之前很多團隊只在把玩階段用過它。真正讓 Java17 成為微服務(wù)基線的是 Spring Boot 3.x它把整個運行時基線抬到了 Java17同時把javax.*包遷移到了jakarta.*。這意味著你從 Java8 項目直接拷貝代碼過來大概率會遇到兩個問題javax.servlet找不到、Lombok 版本太老直接報編譯錯。我一般會在父 POM 里固定這樣一組參數(shù)properties java.version17/java.version maven.compiler.source17/maven.compiler.source maven.compiler.target17/maven.compiler.target spring-boot.version3.2.5/spring-boot.version spring-cloud.version2023.0.3/spring-cloud.version spring-cloud-alibaba.version2023.0.1.2/spring-cloud-alibaba.version lombok.version1.18.32/lombok.version /properties這里最關(guān)鍵的是 Spring Cloud 與 Spring Cloud Alibaba 的版本要和 Spring Boot 3.2.x 對齊否則 Nacos 客戶端啟動時會報包沖突。Lombok 必須用到 1.18.26 以上因為舊版本對 Java17 的 record 和密封類支持不完整。另一個容易翻車的點是依賴樹里殘留了老的javax.annotation-apiSpring Boot 3.x 下應(yīng)該統(tǒng)一走jakarta.annotation不然運行期會看到NoClassDefFoundError。Java17 本體除了配合框架也值得在業(yè)務(wù)代碼里實際用起來。比如 DTO 可以寫成 recordpublic record SkuDTO(Long id, String name, BigDecimal price, Integer stock) { }這段代碼替代了傳統(tǒng)的手寫 getter/setter/構(gòu)造器反編譯后仍然是完整的類文件。要注意 record 不能被繼承也不適合放 JPA 實體只適合做傳輸對象和接口返回值。如果你在項目里看到CglibAopProxy報錯先檢查是不是把 record 當成了被代理的 Bean。2.2 SpringCloud 組件的角色分工注冊、網(wǎng)關(guān)、配置與遠程調(diào)用SpringCloud 是一組組件集合不是單一框架。這個電商項目里的典型組合是 Nacos 做注冊中心和配置中心、Spring Cloud Gateway 做統(tǒng)一入口、OpenFeign 做服務(wù)間調(diào)用。相比 Eureka 加 Zuul 的老組合Nacos 自帶了配置管理可以少部署一個配置服務(wù)Gateway 基于 WebFlux不占 Tomcat 線程適合做路由轉(zhuǎn)發(fā)和統(tǒng)一鑒權(quán)。這個項目的服務(wù)劃分不復(fù)雜常見做法是拆成用戶、商品、訂單、網(wǎng)關(guān)四個可獨立啟動的模塊服務(wù)名端口核心職責主要依賴gateway8080統(tǒng)一入口、路由轉(zhuǎn)發(fā)、登錄鑒權(quán)Gateway、Nacos Discoveryuser-service8101用戶注冊登錄、收貨地址、后臺管理員Spring MVC、Redis、MinIOproduct-service8102商品分類、SKU 管理、商品緩存、圖片上傳Spring MVC、Redis、MinIOorder-service8103購物車、訂單創(chuàng)建、庫存扣減、支付回調(diào)預(yù)留Spring MVC、Redis、OpenFeignGateway 端口對外是 8080業(yè)務(wù)服務(wù)端口不直接暴露只在 Docker 內(nèi)網(wǎng)互通。前端請求先到網(wǎng)關(guān)網(wǎng)關(guān)按路徑前綴把/api/user/**轉(zhuǎn)發(fā)到 user-service把/api/product/**轉(zhuǎn)發(fā)到 product-service。這種方式在本地開發(fā)時也能跑通只是需要把網(wǎng)關(guān)的routes配置從 Nacos 拉取而不是寫死在 yml 里。2.3 Redis 和 MinIO 在電商模塊里的落點緩存、會話、鎖與對象存儲Redis 在這個項目里承擔了三件事驗證碼與 Token 的臨時存儲、熱點商品緩存、庫存預(yù)扣減。不要把 Redis 當成數(shù)據(jù)庫用它的價值在于把高頻讀寫的壓力從 MySQL 上扛走。MinIO 則負責商品圖片、品牌 Logo、用戶頭像這類靜態(tài)文件文件本身不落數(shù)據(jù)庫數(shù)據(jù)庫只存 URL。RedisTemplate 的序列化方式直接決定你能不能從 Redis Desktop Manager 里看到可讀數(shù)據(jù)。默認的 JdkSerializationRedisSerializer 會把 key 變成一串二進制亂碼排查問題時非常痛苦。我一般會單獨配置一個 StringRedisTemplate 處理 key再配一個帶 Jackson 序列化的 RedisTemplate 處理 ValueConfiguration public class RedisConfig { Bean public RedisTemplateString, Object redisTemplate(RedisConnectionFactory factory) { RedisTemplateString, Object template new RedisTemplate(); template.setConnectionFactory(factory); GenericJackson2JsonRedisSerializer serializer new GenericJackson2JsonRedisSerializer(); template.setKeySerializer(RedisSerializer.string()); template.setHashKeySerializer(RedisSerializer.string()); template.setValueSerializer(serializer); template.setHashValueSerializer(serializer); template.afterPropertiesSet(); return template; } }參數(shù)說明RedisSerializer.string()直接使用 UTF-8 字符集key 在客戶端工具里可讀GenericJackson2JsonRedisSerializer會把對象的類型信息作為class字段寫進 JSON反序列化時才能還原成原類型。代價是 JSON 體積稍大、包含類型元數(shù)據(jù)適合緩存結(jié)構(gòu)簡單的商品 DTO。如果你的緩存對象里帶 LocalDateTime還要額外注冊 JavaTimeModule否則反序列化會報InvalidDefinitionException這也是個高頻踩坑點。3. 跑通最小工程Maven 依賴、Redis 緩存與 MinIO 配置模板3.1 搭建工程骨架父 POM 與 Java17 編譯參數(shù)項目建議采用多模塊 Maven 結(jié)構(gòu)父模塊只放依賴管理和公共插件不寫業(yè)務(wù)代碼。子模塊按gateway、user-service、product-service、order-service、common劃分。common里只放統(tǒng)一返回體、異常碼、分頁對象不引入 Spring Cloud 組件避免業(yè)務(wù)服務(wù)被迫多加載一堆網(wǎng)關(guān)依賴。父 POM 的依賴管理里最值得注意的不是數(shù)量而是 Spring Cloud Alibaba 的 BOM 必須排在其他 Spring Cloud 組件之前。Alibaba BOM 會覆蓋部分組件版本如果聲明順序反了Nacos Client 和 Spring Cloud Commons 之間會出現(xiàn)版本倒掛dependencyManagement dependencies dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-alibaba-dependencies/artifactId version2023.0.1.2/version typepom/type scopeimport/scope /dependency dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-dependencies/artifactId version2023.0.3/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement子模塊里只需要聲明用到的 starter不需要寫版本號。這里建議所有服務(wù)都只引入spring-boot-starter-web和spring-cloud-starter-alibaba-nacos-discovery需要配置中心的服務(wù)再加spring-cloud-starter-alibaba-nacos-config。不要把spring-boot-starter-data-redis放進 common因為它會觸發(fā)自動配置讓沒有 Redis 需求的網(wǎng)關(guān)服務(wù)也去嘗試連接 Redis。3.2 三份基礎(chǔ)配置模板bootstrap、application.yml 與 Docker ComposeSpring Cloud Alibaba 項目的配置文件通常分兩份bootstrap.yml負責連接 Nacos 配置中心application.yml負責本地數(shù)據(jù)源和中間件連接。bootstrap.yml在 Spring Boot 3.x 里默認不再自動加載需要額外引入依賴dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-bootstrap/artifactId /dependency如果不加這個依賴你寫的bootstrap.yml會被靜默忽略Nacos 配置中心永遠連不上服務(wù)注冊倒是正常。這個坑非常隱蔽表現(xiàn)是啟動日志里完全沒有 Nacos Config 相關(guān)輸出。application.yml的核心配置如下注意區(qū)分環(huán)境spring: data: redis: host: 127.0.0.1 port: 6379 password: timeout: 3s lettuce: pool: max-active: 16 max-idle: 8 min-idle: 2 servlet: multipart: max-file-size: 10MB max-request-size: 30MB minio: endpoint: http://127.0.0.1:9000 access-key: minioadmin secret-key: minioadmin bucket: mall-images參數(shù)說明timeout: 3s指的是獲取連接的超時時間不是讀寫超時。池參數(shù)max-active: 16在并發(fā)不高時足夠如果商品列表接口每秒 QPS 超過 500建議調(diào)大到 64否則 Lettuce 會頻繁等待連接。MinIO 的endpoint要寫 API 端口 9000不是控制臺端口 9001很多人把這兩者搞混導(dǎo)致本地能開管理頁面但代碼一直連不上。3.3 商品緩存回源的最小實現(xiàn)緩存穿透、擊穿與失效商品詳情是電商項目里最適合做緩存的接口。一個 SKU 的詳情讀取頻率遠高于寫入頻率而且數(shù)據(jù)維度簡單。下面這段代碼是商品詳情接口的常見實現(xiàn)邏輯不復(fù)雜但把緩存穿透和擊穿都擋住了public SkuDTO getSkuDetail(Long skuId) { String key sku:detail: skuId; String cached stringRedisTemplate.opsForValue().get(key); if (cached ! null) { return JSON.parseObject(cached, SkuDTO.class); } // 加鎖只允許一個線程回源數(shù)據(jù)庫 String lockKey sku:lock: skuId; Boolean locked stringRedisTemplate.opsForValue() .setIfAbsent(lockKey, 1, Duration.ofSeconds(10)); if (Boolean.TRUE.equals(locked)) { try { SkuDTO sku skuMapper.selectById(skuId); if (sku null) { // 空值緩存防止穿透 stringRedisTemplate.opsForValue() .set(key, , Duration.ofSeconds(60)); } else { stringRedisTemplate.opsForValue() .set(key, JSON.toJSONString(sku), Duration.ofMinutes(30)); } return sku; } finally { stringRedisTemplate.delete(lockKey); } } else { // 沒搶到鎖的請求短暫睡眠后重試 Thread.sleep(50); return getSkuDetail(skuId); } }代碼邏輯是標準的 Cache Aside 模式先查緩存緩存未命中就通過setIfAbsent搶鎖搶到鎖的線程回源數(shù)據(jù)庫并重建緩存其他線程睡眠 50 毫秒后遞歸重試。setIfAbsent加過期時間這一步是原子的不會出現(xiàn)“加了鎖但沒設(shè)過期時間”的死鎖場景也不用手動拼接 SETNX 和 EXPIRE 兩條命令?？罩稻彺娌荒苁÷苑駝t惡意請求用一個不存在的 ID 就能打穿到數(shù)據(jù)庫。要注意的是鎖粒度。這里的鎖 key 是skuId意思是同一個 SKU 只有一個線程回源不同 SKU 之間互不影響。如果把鎖粒度做到整個商品列表那么列表接口一旦緩存失效所有商品的詳情請求會全部排隊延遲會被放大到不可接受。4. 避坑與排查Redis 超時、MinIO 啟動失敗、Docker 虛擬化檢查4.1 Redis 連接報 Command timed out 或 Connection reset先查這些參數(shù)現(xiàn)象服務(wù)啟動正常第一次訪問接口時拋出io.lettuce.core.RedisCommandTimeoutException: Command timed out after 3 second(s)或者Connection reset by peer。原因Windows 上使用 Redis 內(nèi)存版時沒有配置最大堆內(nèi)存服務(wù)端在內(nèi)存抖動時無法響應(yīng)更常見的另一個原因是不小心把spring.redis.timeout配成了 3000 毫秒以下而接口里同時做了多個 Redis 操作累計等待超過閾值。解決如果能打開 Redis 命令行窗口先執(zhí)行CONFIG GET timeout確保服務(wù)端沒有默認掛起。然后檢查連接池配置把獲取連接超時設(shè)為 3 秒把 Lettuce 讀寫超時放到 5 秒兩者不要混用。Windows 上運行 redis-server 時建議加參數(shù)redis-server --maxheap 256mb否則 Redis 在內(nèi)存壓力下會直接卡死。這個坑在 Docker 里不明顯因為 Linux 容器會動態(tài)分配內(nèi)存但在本地 Windows 開發(fā)時很容易碰到。4.2 MinIO 啟動后前端訪問失敗端口、桶策略與啟動參數(shù)現(xiàn)象Docker 里 MinIO 容器起來了瀏覽器能打開 9001 端口的管理界面但前端或后端訪問 9000 端口上傳文件時總是連接失敗或者上傳成功但圖片 URL 打開報 403。原因第一MinIO 有兩個端口9000 是 S3 API 端口9001 是控制臺端口代碼里必須用 9000 作為 endpoint第二桶權(quán)限是 private生成的 URL 沒有簽名瀏覽器自然無權(quán)限讀取第三Docker 啟動時環(huán)境變量MINIO_ROOT_USER和MINIO_ROOT_PASSWORD寫在兩行但 yml 文件縮進錯誤導(dǎo)致只生效了一半。解決容器啟動后先確認端口映射正確然后單獨建桶并設(shè)置訪問策略。常見做法是上傳時生成預(yù)簽名 URL或者把圖片桶設(shè)為 publicdocker exec -it minio sh mc alias set local http://127.0.0.1:9000 minioadmin minioadmin mc mb --ignore-existing local/mall-images mc anonymous set download local/mall-images參數(shù)說明anonymous set download是把桶設(shè)置為公開下載適合商品圖片這類不需要鑒權(quán)的靜態(tài)資源。頭像、身份證照片等隱私文件不能這樣處理應(yīng)該在上傳時生成預(yù)簽名 URL 并設(shè)置有效期。4.3 Docker Desktop 報 virtualisation support wasnt detectedBIOS 與 WSL2 排查現(xiàn)象Windows 11 上安裝 Docker Desktop 后啟動失敗彈窗提示virtualization support wasnt detected或者直接提示Docker Desktop failed to start because virtualisation support wasnt detected。原因最常見的是 BIOS 里 Intel VT-x 或 AMD-V 沒有開啟其次是 Windows 的 Hyper-V 功能沒有啟用。Docker Desktop 依賴虛擬化能力跟電腦內(nèi)存、硬盤空間關(guān)系不大。解決先打開任務(wù)管理器在“性能”頁查看“虛擬化”是否顯示“已啟用”。如果顯示“已禁用”需要重啟電腦進 BIOS 開啟 Intel Virtualization Technology不同主板位置不一樣一般藏在 Advanced 或 Security 菜單下。如果 BIOS 已開啟但 Docker 仍報錯再執(zhí)行以下命令啟用 Windows 功能然后重啟dism.exe /Online /Enable-Feature /FeatureName:Microsoft-Hyper-V-All /All dism.exe /Online /Enable-Feature /FeatureName:VirtualMachinePlatform /All注意啟用 Hyper-V 后如果還用 Vmware 或 VirtualBox兩者可能沖突。另一個思路是 Docker Desktop 設(shè)置里把后端從 Hyper-V 切換到 WSL2但前提是 WSL2 已安裝。沒有安裝的話執(zhí)行wsl --install重啟后再打開 Docker Desktop。這個坑的解決路徑不只一條關(guān)鍵是先把“虛擬化是否可用”這個問題定位清楚后面才談得上拉鏡像。4.4 docker pull minio 失敗鏡像 tag 與平臺架構(gòu)匹配現(xiàn)象執(zhí)行docker pull minio/minio時進度條卡住或者拉取完成后啟動容器立刻退出日志里出現(xiàn)exec format error。原因exec format error說明鏡像架構(gòu)與主機不匹配常見于 Apple Silicon 或 ARM 設(shè)備上拉了 amd64 鏡像。而拉取卡住的原因往往不是版本號錯誤而是 tag 寫了一個不存在或很少人用的具體版本號Docker Hub 上解析不到。解決先確認主機架構(gòu)然后顯式指定平臺參數(shù)和標準 tag。常見做法是使用官方最新穩(wěn)定 tagminio/minio:latest在多數(shù) Docker 版本下會自動選擇對應(yīng)架構(gòu)的鏡像。如果在 ARM 設(shè)備上必須要 x86 鏡像可以加--platform linux/amd64docker pull --platform linux/amd64 minio/minio:latest這里不建議在 Compose 文件里寫死一個冷門 tag因為你換一臺機器可能就拉不到了。用latest雖然可重復(fù)性差一些但作為本地開發(fā)環(huán)境可獲取性優(yōu)先級更高。4.5 Java17 編譯啟動時遇到的 Lombok 與 SLF4J 沖突現(xiàn)象代碼在 IDEA 里編譯正常mvn clean package也成功但java -jar啟動后立刻報java.lang.ExceptionInInitializerError或ClassNotFoundException: org.slf4j.Logger。原因Lombok 的注解處理器版本低于 1.18.26無法正確識別 Java17 的字節(jié)碼版本會在 class 文件里留下無效的引用SLF4J 的問題則是項目里同時引入了log4j-slf4j-impl和logback-classic兩個綁定同時存在啟動時互相爭搶。解決Lombok 統(tǒng)一升到 1.18.32并把 Lombok 的provided作用域?qū)懬宄LF4J 沖突使用 Maven 依賴樹排查把多余的綁定排除掉。排除后執(zhí)行mvn dependency:tree檢查確保slf4j-api只保留一個版本這是最直接的驗證方式。5. 容器化部署與驗證用 Docker Compose 編排五個基礎(chǔ)服務(wù)5.1 編排文件設(shè)計把 MySQL、Redis、MinIO 和 Nacos 放在同一網(wǎng)絡(luò)本地跑通之后容器化部署是把項目從“能運行”變成“能被別人運行”的關(guān)鍵一步。用 Docker Compose 管理的好處是所有中間件和業(yè)務(wù)服務(wù)都能一鍵拉起不用在每臺機器上手動裝 MySQL、Redis、Nacos。Compose 文件里要把所有服務(wù)放進同一個自定義網(wǎng)絡(luò)這樣服務(wù)名就是主機名例如mysql、redis、minio可以直接作為連接地址。先看中間件部分的編排services: mysql: image: mysql:8.0 container_name: mall-mysql environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: mall ports: - 3306:3306 volumes: - ./data/mysql:/var/lib/mysql - ./sql/init.sql:/docker-entrypoint-initdb.d/init.sql healthcheck: test: [CMD, mysqladmin, ping, -h, localhost] interval: 10s retries: 5 redis: image: redis:7.2 container_name: mall-redis command: [redis-server, --appendonly, yes] ports: - 6379:6379 volumes: - ./data/redis:/data minio: image: minio/minio:latest container_name: mall-minio command: server /data --console-address :9001 environment: MINIO_ROOT_USER: minioadmin MINIO_ROOT_PASSWORD: minioadmin ports: - 9000:9000 - 9001:9001 volumes: - ./data/minio:/data參數(shù)說明MySQL 的docker-entrypoint-initdb.d目錄下只執(zhí)行首次初始化腳本如果數(shù)據(jù)卷里已經(jīng)有舊數(shù)據(jù)重新創(chuàng)建容器時不會再次執(zhí)行。Redis 的--appendonly yes開啟 AOF 持久化避免容器重啟后緩存數(shù)據(jù)丟失但注意這會增加磁盤寫入量本地開發(fā)可以接受。MinIO 的command里server /data是 API 服務(wù)入口--console-address :9001指定控制臺端口兩個端口缺一不可漏掉console-address會導(dǎo)致控制臺默認端口沖突。5.2 構(gòu)建腳本模板等待就緒再啟動業(yè)務(wù)服務(wù)業(yè)務(wù)服務(wù)依賴 Nacos 和數(shù)據(jù)庫如果 Compose 里所有服務(wù)同時啟動業(yè)務(wù)服務(wù)可能在 Nacos 還沒注冊好時就退出重試。Compose 的depends_on只控制啟動順序不保證 Nacos 已就緒。我一般會在啟動腳本里寫一個簡單的等待循環(huán)#!/bin/bash echo 等待 Nacos 啟動... until curl -s http://127.0.0.1:8848/nacos/v1/console/health/readiness | grep -q true; do sleep 2 done echo Nacos 已就緒開始構(gòu)建并啟動業(yè)務(wù)服務(wù) docker compose up -d --build gateway user-service product-service order-service docker compose logs -f --tail100 gateway邏輯說明curl請求 Nacos 的 health 接口返回內(nèi)容里包含true才繼續(xù)執(zhí)行否則每 2 秒重試。把“等待基礎(chǔ)設(shè)施就緒”和“啟動業(yè)務(wù)服務(wù)”分成兩個階段比在 Compose 里堆depends_on更可靠。注意docker compose up -d --build會重新構(gòu)建鏡像如果你只是改了配置沒改代碼直接docker compose restart更快。5.3 部署后的驗證清單緩存命中、存儲桶可達、網(wǎng)關(guān)路由部署完成不代表業(yè)務(wù)可用建議按以下順序驗證最終效果docker compose ps docker exec -it mall-redis redis-cli ping curl -s http://127.0.0.1:8080/api/product/sku/1 redis-cli --scan --pattern sku:detail:* curl -s -X PUT http://127.0.0.1:9000/mall-images/test.png \ -H Content-Type: image/png --data-binary test.png參數(shù)說明redis-cli ping驗證 Redis 可寫訪問商品詳情接口后在 Redis 里掃描sku:detail:*前綴能查到鍵說明緩存已經(jīng)寫入對 MinIO 的 9000 端口發(fā)起 PUT 請求能返回 200 說明 API 端口和桶權(quán)限都正常。這四個檢查點覆蓋了中間件、緩存回源、網(wǎng)關(guān)路由和文件存儲任何一個失敗都能快速縮小問題范圍。6. 進階與驗證把庫存扣減做成防超賣并給簡歷留一個能講的技術(shù)點6.1 用 Redis 原子操作把庫存扣減改成防超賣訂單服務(wù)的核心難點是庫存扣減。如果直接用 MySQL 的update stock set count count - 1 where sku_id ?在高并發(fā)下會出現(xiàn)行鎖競爭如果用 Java 代碼先查再寫就必然存在超賣窗口。常見做法是把庫存預(yù)扣減放到 Redis 里用原子腳本處理再異步同步到 MySQLString script if tonumber(redis.call(get, KEYS[1])) tonumber(ARGV[1]) then return redis.call(decrby, KEYS[1], ARGV[1]) else return -1 end ; DefaultRedisScriptLong redisScript new DefaultRedisScript(script, Long.class); Long result stringRedisTemplate.execute( redisScript, Collections.singletonList(stock:sku: skuId), String.valueOf(count) );邏輯說明腳本先取出庫存值如果充足就執(zhí)行decrby扣減否則返回 -1。整個判斷和扣減在 Redis 里是原子的不涉及 Java 層面的并發(fā)問題。返回 -1 時客戶端直接提示庫存不足返回正數(shù)時再生成訂單并發(fā)送消息給 MySQL 異步落庫。這套方案的好處是扣減性能接近 Redis 的極限壞處是 Redis 和 MySQL 之間存在短暫不一致需要引入定時對賬或 MQ 最終一致性處理這也是面試時可以展開講三分鐘的技術(shù)點。6.2 壓測和觀察手段別只盯著接口通不通部署完成后建議做一輪簡單壓測觀察接口在并發(fā)下的表現(xiàn)。用ab工具就能看出緩存是否有效ab -n 5000 -c 100 -k http://127.0.0.1:8080/api/product/sku/1壓測時重點看三個指標Redis 命中率、接口平均響應(yīng)時間、Docker 容器 CPU 占用。緩存命中率可以在 Redis 里執(zhí)行INFO stats查看keyspace_hits和keyspace_misses的比值。如果命中率低于 90%說明緩存 key 的設(shè)計或過期時間不合理優(yōu)先檢查是不是把用戶維度數(shù)據(jù)放進了公共商品緩存。如果 Redis CPU 高但 MySQL CPU 低說明查詢邏輯沒問題瓶頸可能出在序列化方式上可以考慮換更緊湊的 JSON 序列化或直接緩存二進制字節(jié)。6.3 一個值得長期保留的習(xí)慣我做完這類項目后的習(xí)慣是留一個獨立的docs/目錄里面記錄每個中間件的啟動命令、端口約定和踩過的坑尤其是版本兼容矩陣和 Compose 啟動順序這類信息。下次重新部署或換機器時不至于從零摸索。一句話收尾微服務(wù)項目的復(fù)雜度不在代碼量而在“服務(wù)連起來之后的表現(xiàn)”希望這個項目能幫你真正跑通一條完整的電商鏈路也祝你少踩幾個我踩過的坑。本文還有配套的精品資源點擊獲取