HotArmor
Intelligent Hotspot Data Protection Framework · Solving High-Concurrency Cache Penetration One annotation, automatic promotion of hotspot data to local cache
Install / Use
/learn @bafuka/HotArmorREADME
<div align="center">
HotArmor 🛡️
Intelligent Hotspot Data Protection Framework · Solving High-Concurrency Cache Penetration
One annotation, automatic promotion of hotspot data to local cache
💡 What Problem Does It Solve?
HotArmor is a hotspot data protection middleware designed for high-concurrency scenarios. In flash sales, trending events, and similar scenarios, a small number of hotspot data (such as popular products or trending topics) can cause serious performance issues:
| Problem | Typical Scenario | Technical Impact | HotArmor Solution | |---------|-----------------|------------------|-------------------| | ⚡ Cache Breakdown | Moment when hot key expires | Thousands of requests simultaneously bypass cache and hit database, overwhelming DB | L4 distributed lock + Double-Check ensures single-point source loading | | 🔥 Hotspot Overload | Celebrity products frequently accessed | Redis connection pool exhausted, bandwidth saturated, slow response | L1-L3 intelligently identifies hotspots and promotes to local cache (microsecond level) | | 🔄 Distributed Cache Consistency | Multi-node cluster deployment | Node A updates data, nodes B/C/D have stale local cache causing dirty reads | Pub/Sub invalidation broadcast + hotspot promotion broadcast, full-node synchronization | | 🗑️ DB-Cache Consistency | High-concurrency read-write race conditions | After updating DB and deleting cache, concurrent queries write old data back to Redis | Delayed double-delete strategy eliminates write-after-read race window |
🚀 Core Features
// Just one annotation, framework handles hotspot protection automatically
@HotArmorCache(resource = "product:detail", key = "#id")
public Product getProduct(Long id) {
return productMapper.selectById(id); // Hotspot data automatically promoted to local cache
}
- ✨ Out-of-the-Box - Declarative annotation usage, zero-intrusion integration
- 🧠 Intelligent Recognition - Based on Sentinel's hotspot parameter flow control, precise hotspot identification
- 🔄 Four-Level Protection - L1 Local Cache → L2 Noise Filter → L3 Hotspot Detection → L4 Safe Source Loading
- 📡 Eventual Consistency - Delayed double-delete + Redis Pub/Sub broadcast ensures cluster cache synchronization
- ⚡ Ultimate Performance - Hotspot data from Redis millisecond-level → Caffeine microsecond-level response
🏗️ Architecture Design
System Architecture
┌─────────────────────────────────────────────────────────────────────┐
│ Application Layer │
│ │
│ @HotArmorCache(resource="...", key="...") ← Query cache │
│ @HotArmorEvict(resource="...", key="...") ← Invalidate cache │
└──────────────────────────┬──────────────────────────────────────────┘
│
│ AOP Interception
↓
┌─────────────────────────────────────────────────────────────────────┐
│ HotArmor Core Engine │
│ │
│ ┌───────────────────────────────────────────────────────────────┐ │
│ │ Aspect Layer │ │
│ │ • HotArmorAspect - AOP interceptor │ │
│ │ • SpEL expression parser - Parse key/condition │ │
│ │ • HotArmorContext - Request context object │ │
│ └─────────────────────────┬─────────────────────────────────────┘ │
│ ↓ │
│ ┌───────────────────────────────────────────────────────────────┐ │
│ │ Handler Layer │ │
│ │ • DefaultHotArmorAspectHandler │ │
│ │ - handleCache() : Read flow four-level funnel │ │
│ │ - handleEvict() : Write flow cache invalidation │ │
│ └─────────────────────────┬─────────────────────────────────────┘ │
│ ↓ │
│ ┌───────────────────────────────────────────────────────────────┐ │
│ │ Data Plane │ │
│ │ │ │
│ │ ┌─────────────────────────────────────────────────────────┐ │ │
│ │ │ L1: Local Cache Layer (CaffeineL1CacheEngine) │ │ │
│ │ │ • Caffeine high-performance local cache │ │ │
│ │ │ • Microsecond-level response (~1μs) │ │ │
│ │ │ • Independent capacity and expiration configuration │ │ │
│ │ └─────────────────────────────────────────────────────────┘ │ │
│ │ ↓ Miss │ │
│ │ ┌─────────────────────────────────────────────────────────┐ │ │
│ │ │ L2: Noise Filter Layer (CaffeineL2NoiseFilter) │ │ │
│ │ │ • Lightweight access counter │ │ │
│ │ │ • Filter cold data (access frequency < threshold) │ │ │
│ │ │ • Protect Sentinel resources │ │ │
│ │ └─────────────────────────────────────────────────────────┘ │ │
│ │ ↓ Pass │ │
│ │ ┌─────────────────────────────────────────────────────────┐ │ │
│ │ │ L3: Hotspot Detection Layer (SentinelL3HotspotDetector) │ │ │
│ │ │ • Sentinel parameter flow control │ │ │
│ │ │ • Hotspot determination (QPS > threshold) │ │ │
│ │ │ • Automatic hotspot promotion trigger │ │ │
│ │ └─────────────────────────────────────────────────────────┘ │ │
│ │ ↓ Block (Hotspot!) │ │
│ │ ┌─────────────────────────────────────────────────────────┐ │ │
│ │ │ L4: Safe Source Loading Layer (RedissonL4SafeLoader) │ │ │
│ │ │ • Redisson distributed lock │ │ │
│ │ │ • Double-Check mechanism │ │ │
│ │ │ • Retry + exponential backoff │ │ │
│ │ │ • Prevent cache breakdown │ │ │
│ │ └─────────────────────────────────────────────────────────┘ │ │
│ └───────────────────────────────────────────────────────────────┘ │
│ │
│ ┌───────────────────────────────────────────────────────────────┐ │
│ │ Control Plane │ │
│ │ │ │
│ │ • DefaultRuleManager - Rule manager │ │
│ │ - loadRules() : Load rule configuration │ │
│ │ - updateRules() : Dynamic rule updates │ │
│ │ - validateRule() : Rule validation │ │
│ │ • HotArmorRule - Rule model (L1-L4 configuration) │ │
│ └───────────────────────────────────────────────────────────────┘ │
│ │
│ ┌───────────────────────────────────────────────────────────────┐ │
│ │ Consistency Engine │ │
│ │ │ │
│ │ • DefaultConsistencyManager - Consistency manager │ │
│ │ - handleUpdate() : Handle cache updates │ │
│ │ - handlePromotion() : Handle hotspot promotion broadcast │ │
│ │ - invalidateCache() : Immediate cache deletion │ │
│ │ • RedisBroadcastNotifier - Redis Pub/Sub broadcast │ │
│ │ - Cache invalidation broadcast │ │
│ │ - Hotspot promotion broadcast (NEW) │ │
│ │ • DelayedDeleteProducer - Delayed double-delete (RocketMQ) │ │
│ └───────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘
│
┌────────────────┼────────────────┐
│ │ │
↓ ↓ ↓
┌──────────────────┐ ┌────────────┐ ┌─────────────────┐
│ Redis │ │ RocketMQ │ │ Database │
│ • L2 cache │ │ • Delayed │ │ • MySQL │
│ • Pub/Sub │ │ messages│ │ • PostgreSQL │
│ • Distributed │ │ (optional)│ │ etc. │
│ lock │ └────────────┘ └─────────────────┘
└──────────────────┘
───────────────────────────────────────────────────────────────────────
Data Flow Description:
Read Flow:
User request → AOP interception → L1 local cache → L2 noise filter → L3 hotspot detection
→ L4 safe source loading → Redis/DB → Promote to L1 (hotspot) → Send promotion broadcast
→ Other nodes receive broadcast and promote to L1 → Return
Write Flow:
User request → AOP interception → Update DB → Delete L1+Redis → Send invalidation broadcast
→ Other nodes clear L1 → Delayed double-delete (optional) → Complete
───────────────────────────────────────────────────────────────────────
Core Processes
Read Flow (Four-Level Funnel)
User Request
↓
┌─────
