Backend Development 16 min read

JdHotkey: A Lightweight Hotkey Detection Framework – Architecture, Workflow, and Performance

The article introduces the JdHotkey framework, a lightweight, real‑time hotkey detection solution for Redis and other services, detailing the risks of hot keys, prior mitigation methods, core design components, operational workflow, and performance benchmarks across various hardware configurations.

JD Retail Technology
JD Retail Technology
JD Retail Technology
JdHotkey: A Lightweight Hotkey Detection Framework – Architecture, Workflow, and Performance

In high‑concurrency systems, hot keys—sudden spikes in access to specific keys such as popular product SKUs, user IDs, or API endpoints—pose severe risks to both data and service layers, potentially overwhelming a Redis shard or saturating Tomcat instances.

The article enumerates risky hot keys, including frequently accessed MySQL rows, Redis keys, bot users, specific API URLs, and composite keys like userId+/sku/query , emphasizing the need for a unified detection framework.

Traditional mitigation approaches (secondary caches, client‑side modifications, custom Redis builds, blacklist propagation, local or centralized rate limiting) are fragmented and often insufficient, prompting the design of a universal, real‑time hotkey detection system.

Key detection metrics are defined as real‑time (detect within 1 s), accuracy (precise threshold‑based counting), cluster consistency (uniform hot‑key state across nodes), and high performance (minimal resource consumption).

The JdHotkey architecture comprises four parts: an etcd cluster for configuration and rule storage, a client‑side Java JAR for key reporting and local caching, a worker cluster that aggregates and evaluates keys, and a dashboard UI for rule management and hot‑key monitoring.

The workflow involves setting up etcd, configuring rules via the dashboard (e.g., "20 occurrences in 2 s"), launching workers, and having clients batch‑send keys every 500 ms; workers push detected hot keys back to clients and etcd, ensuring consistent in‑memory hot‑key caches.

Performance tests show that an 8‑core, 8 GB worker can process ~160 k keys per second (≈1.6 M per 10 s) with CPU usage around 70 %, while a 16‑core, 16 GB machine handles double the load with lower CPU pressure, confirming the framework’s scalability for large‑scale traffic spikes.

The framework is production‑tested at JD.com, open‑sourced on Gitee, and positioned as a generic solution for any scenario requiring rapid hot‑key detection and mitigation.

distributed systemsJavaperformanceHotKeyRedisEtcd
JD Retail Technology
Written by

JD Retail Technology

Official platform of JD Retail Technology, delivering insightful R&D news and a deep look into the lives and work of technologists.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.