<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>High Concurrency on YennJ12 Engineering Blog</title><link>https://yennj12.js.org/yennj12_blog_V4/tags/high-concurrency/</link><description>Recent content in High Concurrency on YennJ12 Engineering Blog</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Mon, 25 May 2026 09:00:00 +0800</lastBuildDate><atom:link href="https://yennj12.js.org/yennj12_blog_V4/tags/high-concurrency/feed.xml" rel="self" type="application/rss+xml"/><item><title>購物車系統的高並發改造（一）：Virtual Threads、HikariCP 與 Redis 快取三管齊下</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/shopping-cart-high-concurrency-part1-zh/</link><pubDate>Sun, 24 May 2026 09:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/shopping-cart-high-concurrency-part1-zh/</guid><description>前言 電商系統有一個非常典型的流量特徵：平時風平浪靜，一到促銷活動瞬間湧入幾千上萬個並發請求。
如果你的購物車系統跑在默認的 Spring Boot 設定上，這個瞬間幾乎必定會讓系統崩潰——不是 OOM，就是資料庫連線耗盡，要不然就是 Tomcat 執行緒池打滿、請求開始逾時。
這篇文章深入剖析我們在 PR #227 中對一個 Spring Boot 購物車系統進行的高並發改造，涵蓋三個核心技術方向：
JDK 21 Virtual Threads：讓每個請求都跑在輕量級虛擬執行緒上 HikariCP 連線池調校：消除資料庫連線成為瓶頸的問題 Redis 分層快取：把熱點讀取從資料庫移到記憶體 系統架構概述 先看清楚我們在改什麼。這是一個標準的 Spring Boot 電商後端：
Client (Web/App) ↓ HTTP Spring Boot API (port 9999) ├── CartController → CartService → MySQL (cart table) ├── ProductController → ProductService → MySQL (products table) ├── OrderController → OrderService → MySQL (orders/order_items) │ → Stripe API (付款) ├── UserController → UserService → MySQL (users) └── AuthController → AuthenticationService → MySQL (auth_tokens) 技術棧：Spring Boot 3.</description></item><item><title>購物車系統的高並發改造（二）：Redisson 分散式鎖、讀寫分離路由與 Docker HA 水平擴展</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/shopping-cart-high-concurrency-part2-zh/</link><pubDate>Mon, 25 May 2026 09:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/shopping-cart-high-concurrency-part2-zh/</guid><description>前言 第一篇解決了系統的吞吐量問題：Virtual Threads 讓執行緒不再阻塞在 I/O 上，HikariCP 調校讓資料庫連線不再是瓶頸，Redis 快取讓熱點讀取從記憶體直接回傳。
但吞吐量提升後，反而暴露出一個更深層的問題：
並發請求同時寫入同一份資料，怎麼保證正確性？
想像雙十一活動開始的那一秒，同一個用戶的兩個 Tab 同時按下「加入購物車」；或者同一個人網路不穩，重試了兩次「立即結帳」——這兩種場景都會導致重複訂單或資料不一致。
這篇介紹 PR #228 帶來的三個進階改造：
Redisson 分散式鎖：防止同一用戶的並發寫入互相干擾 讀寫分離路由：把讀請求分流到 Replica，Primary 只處理寫入 Docker HA 水平擴展：Nginx + 多個 App 實例 + MySQL 主從複製 方案四：Redisson 分散式鎖 為什麼需要分散式鎖？ 第一篇的 CartService.addToCart() 在高並發下有一個隱患：
1// Part 1 的版本（沒有鎖） 2public void addToCart(AddToCartDto addToCartDto, Product product, User user) { 3 Cart cart = new Cart(product, addToCartDto.getQuantity(), user); 4 cartRepository.save(cart); // ← 多個執行緒可能同時執行這一行 5} 當同一個用戶同時發出兩個「加入購物車」請求時：
Thread A: new Cart(productX, qty=1, user) → save → 購物車有 1 個 productX Thread B: new Cart(productX, qty=1, user) → save → 購物車有 2 個 productX（重複！） cartRepository.</description></item></channel></rss>