JD-Hotkey: High-Performance Backend Hot Data Detection Framework
JD-Hotkey is a backend framework that detects and pushes hot keys at millisecond precision, handling billions of keys daily with up to 370,000 detection tasks per second and 600,000 push operations per second, dramatically reducing data‑layer pressure and improving application performance across various caching and rate‑limiting scenarios.
JD‑hotkey is JD's APP backend hot‑data detection framework, proven through multiple high‑pressure stress tests and the 2020 JD 618 promotion.
During operation it monitors tens of billions of keys per day, accurately capturing crawlers, abusive users, and hot items, then pushes these hot keys to all service JVMs within milliseconds, greatly lowering query load on the data layer and boosting performance.
Performance metrics:
1. Detection performance: an 8‑core worker can handle 160,000 key detection tasks per second; a 16‑core worker processes over 300,000 tasks per second, with peak tests reaching 370,000 tasks while keeping CPU stable.
2. Push performance: under high‑concurrency writes, the framework pushes 100,000–120,000 updates per second; with 1,000 servers each generating 100 hot keys per second, it reliably pushes 100,000 updates per second, and in push‑heavy scenarios can sustain 400,000–600,000 pushes per second, peaking at 800,000 for short bursts.
Overall throughput (write + push) stabilizes around 700,000 operations per second, and a single worker can support a 1:1000 ratio of workers to business services, saving substantial storage resources such as Redis cluster expansion.
Introduction: The framework detects sudden hot requests—hot data, hot users, hot interfaces—and pushes them to all JVMs, enabling local caching, user throttling, or circuit‑breaking while maintaining consistency across the cluster.
Core functions: hot‑data detection and cluster‑wide push.
Applicable scenarios:
MySQL hot‑data local cache
Redis hot‑data local cache
Blacklist user local cache
Crawler user rate limiting
Interface/user dimension rate limiting
Single‑machine and cluster‑wide rate limiting
Worker performance highlights: Every 10 seconds the worker logs processing 2.7–3.1 million keys (≈30 K QPS), achieving massive real‑time detection with minimal hardware.
The UI demonstrates the framework’s monitoring and control capabilities.
Architecture Digest
Focusing on Java backend development, covering application architecture from top-tier internet companies (high availability, high performance, high stability), big data, machine learning, Java architecture, and other popular fields.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.