1. Component Overview
JD-HotKey is a real-time hot key detection and caching middleware open-sourced by JD.com (source). It does one thing: in high-concurrency scenarios, it automatically discovers hot keys and pushes them to every application node’s JVM memory within milliseconds, so hot requests are served directly from local memory instead of hitting Redis or the database.
Classic scenario: a celebrity suddenly announces something, and a flood of requests hits the related products. You had no way to predict which product ID would go hot. A Redis node gets hammered by these requests and its CPU spikes — this is a textbook unpredictable burst hot key.
That’s where JD-HotKey comes in: it automatically detects these hot spots, mirrors the data into every application server’s local memory, and subsequent requests are served straight from memory — RT drops from tens of milliseconds to under 1ms.
Compared to using a local cache directly (like Caffeine), JD-HotKey’s core advantages:
| Capability |
Caffeine Local Cache |
JD-HotKey |
| Hot key detection |
Manual configuration — you need to know which keys to cache upfront |
Automatic detection — determines hot keys based on real-time access volume |
| Dynamism |
Static, stays once configured |
Automatically joins/exits hot status, releases memory when cold |
| Multi-node consistency |
Each node is independent, unaware of others |
Global unified detection, all nodes synchronize |
| Use case |
Known high-frequency data (dictionaries, configs) |
Unpredictable burst hot keys (flash sales, trending searches) |
| Deployment complexity |
Low (pure SDK) |
Medium (requires etcd + worker) |
| Hot user / hot endpoint detection |
Not supported |
Supported (not limited to keys — endpoints and users too) |
In short: known hot keys are fine with local cache; unpredictable hot keys need JD-HotKey.
2. Core Architecture