Cache Synchronization in High‑Concurrency Environments: Problems and JD's CDC‑Based Solution
The article reviews common cache‑side data‑sync patterns, highlights their inconsistency and data‑loss risks under high load, and presents JD's solution that combines Cache‑Aside, Change Data Capture, message queues, delayed consumption, versioning, and persistence to ensure eventual consistency between cache and relational databases.
Existing Technologies – Heterogeneous data systems often use Cache‑Aside, Read‑Through/Write‑Through, Write‑Back, and Write‑Around patterns to keep cache and database synchronized. Cache‑Aside reads from cache first and falls back to the database; writes either update the DB then the cache or delete the cache entry. Read‑Through/Write‑Through makes the cache the primary data source, delegating DB reads/writes to it. Write‑Back writes only to the cache and updates the DB asynchronously. Write‑Around writes directly to the DB and updates the cache only on a miss.
Drawbacks of Existing Techniques – Cache‑Aside can produce stale data under high concurrency because multiple update requests may reorder DB and cache updates, leading to dirty cache entries. Read‑Through/Write‑Through, Write‑Back, and Write‑Around rely heavily on the cache; if the cache fails, captured data may be permanently lost. (Image illustrating Cache‑Aside inconsistency)
JD Solution Overview – JD proposes a CDC (Change Data Capture)‑based approach: CDC captures database changes, which are published to a message‑queue (MQ) for delayed consumption. This decouples cache updates from immediate DB writes and removes strong cache dependency; when the cache is unavailable or empty, the system directly loads data from the DB.
Detailed Implementation – Reads continue to use Cache‑Aside: the application checks the cache first, falls back to the DB if needed, and then populates the cache. Writes update the relational database (Oracle/MySQL/SQL Server). CDC captures the change and stores it in a binlog‑style change table. The change is sent to MQ; consumers (cache‑updating services) consume the messages after a configurable delay, applying version‑controlled updates to the cache. Each table includes a version field; only messages with the next sequential version are applied, ensuring ordered, consistent cache updates even under high concurrency. (Images showing read flow and write flow diagrams)
Benefits – The combined Cache‑Aside + CDC + MQ + delayed consumption + versioning approach guarantees eventual consistency between cache and database in high‑concurrency scenarios, improves throughput by asynchronously decoupling components, and reduces response latency while preventing dirty cache writes.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
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.
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.
