<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Redis on YennJ12 Engineering Blog</title><link>https://yennj12.js.org/yennj12_blog_V4/tags/redis/</link><description>Recent content in Redis on YennJ12 Engineering Blog</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Mon, 08 Jun 2026 09:00:00 +0800</lastBuildDate><atom:link href="https://yennj12.js.org/yennj12_blog_V4/tags/redis/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>FDE 面試準備指南（二十三）：RKK 實戰——多租戶 Agent 的限流、Fair-Share 與 Token 預算控制</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part23-ratelimit-fairshare-zh/</link><pubDate>Thu, 04 Jun 2026 16:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part23-ratelimit-fairshare-zh/</guid><description>傳統 SaaS 的限流是「每分鐘最多 1,000 個請求」。
AI SaaS 的限流問題是「每分鐘最多 100 萬個 Token，但一個用戶的一個請求就可能用掉 50 萬 Token」。
請求次數限流，在 AI 系統裡完全失效。
面試情境 面試官： 「你的 B2B SaaS 將 Agent 系統開放給上千家企業使用。Gemini API 有嚴格的 TPM/RPM 限制。如果某個大客戶突然發起高頻查詢，把整個 GCP 專案的 Quota 耗盡，導致其他客戶全部收到 429 Too Many Requests。你如何在架構端設計 Fair-Share 與 Token 預算控制系統？」
一、核心問題：為什麼 AI 限流和傳統 API 限流完全不同 傳統 API 的資源消耗模型： 每個請求的成本大致相同 GET /users/123 ≈ GET /orders/456 ≈ 相同的計算資源 → 限制「請求次數（RPM/RPS）」就夠了 AI API 的資源消耗模型： 請求 A：「你好！」 → input: 50 tokens, output: 30 tokens = 80 tokens 請求 B：「請分析這份 200 頁的合約並翻譯成英文」 → input: 150,000 tokens, output: 50,000 tokens = 200,000 tokens 請求 B 消耗的資源是請求 A 的 2,500 倍！ 如果只限制請求次數（RPM）： → 請求 B 讓整個系統的 Token Quota 瞬間耗盡 → 其他 99 個正常用戶全部 429 問題量化（Gemini 1.</description></item><item><title>FDE 面試指南 Part 51：百萬級多輪對話的 KV Cache 驅逐機制與記憶體架構優化</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part51-kv-cache-memory-zh/</link><pubDate>Mon, 08 Jun 2026 09:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part51-kv-cache-memory-zh/</guid><description>大多數工程師的做法：把 KV Cache 設一個固定 TTL，讓它自動過期，再出問題就加更多 GPU。 資深 FDE 的思維：把快取當分層財務決策——什麼時候該升層、什麼時候該壓縮、什麼時候主動驅逐， 每一個決策節點都有精確的數字閾值，而不是「看狀況再說」。 差距不在技術知識，在於你能不能把顯存、計費週期、對話語義三個維度同時管住。
面試情境 你的 B2B 對話式 AI 平台服務 5 萬名企業用戶，平均每位用戶每天與 Agent 進行 20–40 輪對話。 隨著上下文長度增長，GPU 顯存使用率持續攀升，高峰期 OOM（Out of Memory）崩潰率達到 3%， 同時 Vertex AI 帳單每月 $120K，CFO 要求兩個月內把成本降低 50%。 你被要求在不降低對話品質的前提下，重新設計快取架構。你的方案是什麼？
一、核心問題：為什麼 KV Cache 管理會讓 B2B SaaS 崩潰 1.1 KV Cache 的本質與代價 大型語言模型在推理時，Attention 機制需要存取所有歷史 Token 的 Key/Value 向量。每一輪新對話都要「看過」所有先前的 Token，這個快取（KV Cache）讓模型不需要重新計算，代價是它活在 GPU 顯存（VRAM）裡。
以 Gemini 1.5 Pro 為例：
每 1K tokens 的 KV Cache 佔用約 0.</description></item><item><title>Spring Boot 多環境配置完整指南：開發、測試、生產環境管理</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/spring-boot-multi-environment-configuration-guide-zh/</link><pubDate>Wed, 15 Oct 2025 10:00:00 +0000</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/spring-boot-multi-environment-configuration-guide-zh/</guid><description>深入探討 Spring Boot 多環境配置管理，包括資料庫切換、Redis 配置、以及 Docker 容器化部署的完整實作指南。</description></item><item><title>Redis Sentinel: Complete High Availability Setup Guide with Java Integration and Monitoring</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/redis-sentinel-high-availability-setup-guide/</link><pubDate>Mon, 29 Sep 2025 07:54:22 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/redis-sentinel-high-availability-setup-guide/</guid><description>🎯 Introduction Redis Sentinel provides high availability and monitoring for Redis deployments. It&amp;rsquo;s a distributed system that monitors Redis master and replica instances, performs automatic failover, and acts as a configuration provider for clients. This comprehensive guide covers Redis Sentinel architecture, setup procedures, Java integration, and production best practices.
Redis Sentinel solves critical production challenges including automatic failover, service discovery, and configuration management, making it essential for mission-critical applications that require high availability and minimal downtime.</description></item><item><title>Building Real-Time Chat Room with Spring Boot WebSocket</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/spring-boot-websocket-chat-room-application/</link><pubDate>Sat, 27 Sep 2025 10:00:00 +0000</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/spring-boot-websocket-chat-room-application/</guid><description>Comprehensive guide to building a scalable, real-time chat room application using Spring Boot WebSocket, STOMP protocol, and Redis clustering for enterprise-grade messaging solutions.</description></item><item><title>Database Performance Optimization: From Slow Queries to Sub-millisecond Response Times</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/optimizing-database-performance/</link><pubDate>Sun, 10 Aug 2025 15:28:17 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/optimizing-database-performance/</guid><description>A comprehensive guide to database performance optimization techniques that helped us reduce query response times from seconds to milliseconds.</description></item></channel></rss>