Mastering High‑Concurrency: From Thread Pitfalls to Distributed Inventory Architecture

Introduction

In modern internet applications the “three highs” – high concurrency, high availability and high performance – are essential, especially for large‑scale events such as JD.com’s 618 promotion.

Single‑machine dimension

Hardware upgrades are straightforward, but code‑level optimisations are often ignored. Multithreading can increase CPU utilisation but does not automatically improve overall performance, especially when the number of CPU cores is limited. Using a thread pool inside a servlet (e.g., Tomcat) may improve TP99 for low traffic but will cause excessive context switching and lock contention under thousands of QPS.

Multithreading vs. asynchronous methods

Multithreading creates multiple threads within a process, while asynchronous methods (e.g., Java CompletableFuture) allow a call to return immediately and continue processing later. Multithreading can raise concurrency for CPU‑bound tasks, but asynchronous programming is better for I/O‑bound workloads.

Multi‑machine dimension

Horizontal scaling through load‑balanced clusters (expansion) and vertical splitting into micro‑services are common ways to handle massive traffic. Distributed systems introduce challenges such as circuit breaking, rate limiting and timeout handling.

Database and business‑application considerations

Relational databases like MySQL require sharding and read‑write separation (e.g., using Redis for reads and Elasticsearch for queries). Inventory‑heavy scenarios need careful locking to avoid overselling.

Practical inventory‑deduction solution

Cache inventory in Redis, update MySQL asynchronously, and use a partitioned stock‑pool design similar to Kafka partitions. Each partition holds a pre‑allocated stock sub‑domain; a scheduler activates sub‑domains, switches when thresholds are reached, and synchronises changes via MQ.

Partition scheduler

The scheduler maintains a registry of partition keys, stock levels and sub‑domain status, selects partitions randomly or round‑robin, and removes exhausted partitions.

Asynchronous stock update

Stock‑deduction details are stored in a table with a sync flag. When the number of records exceeds a threshold or a time interval elapses, an MQ message is sent to update MySQL, ensuring idempotent synchronization.

Pre‑allocated stock management

Actual stock = pre‑allocated pool + reserved stock. When the pre‑allocated pool is empty, the partition is taken out of service. MQ updates adjust both actual and reserved stock transactionally.

Conclusion

Combining caching, asynchronous processing and partitioned design yields a high‑concurrency system with horizontal scalability, but concrete business requirements must drive the final architecture.