Design and Optimization of High‑Concurrency Ranking and Real‑Time Messaging Systems
The article details a comprehensive architecture for high‑concurrency services—including a Redis‑backed ranking system, distributed locking, Bloom‑filter nickname deduplication, Netty‑based reliable messaging, IoT MQTT/REST integration, live‑streaming pipelines, layered performance tuning, and automated traffic‑replay testing to ensure scalability and robustness.
This article presents a series of technical solutions for building high‑concurrency services such as ranking, real‑time messaging, IoT integration, and live‑streaming platforms.
Ranking Design : A distributed ranking system is built on Redis Zset combined with a custom JamsRanking component. The design uses weighted scores (points, time, attempts, accuracy) and a cache‑aside pattern to keep MySQL and Redis consistent. After initial optimization the throughput reached ~500 TPS, with further improvements using batch processing and queue‑based writes.
Distributed Locking : To prevent duplicate answers and race conditions, a Redis‑based distributed lock is implemented. Example code:
// Acquire lock using SET with NX and EX
String result = jedis.set(lockKey, requestId, "NX", "EX", expireTime);
// Release lock with Lua script for atomicity
String lua = "if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end";
Object release = jedis.eval(lua, Collections.singletonList(lockKey), Collections.singletonList(requestId));Bloom Filter for Nickname Deduplication : A Bloom filter stores hashed nicknames to quickly reject duplicates with low memory overhead. The filter supports insertions and membership checks before persisting to the database.
Message Ordering and Reliability : The system uses Netty for TCP communication, implementing a three‑message handshake (REQ, ACK, NOTIFY) with timeout‑based retransmission and de‑duplication. Group chat messages are stored once per group and delivered via ACK‑batching to avoid duplication.
IoT Architecture : A three‑layer model (Device, Connect, Manage) is described. MQTT is used for low‑bandwidth uplink, while HTTP/REST APIs handle control commands. Various protocols (CoAP, AMQP, XMPP, Zigbee) are compared for suitability. High‑availability is achieved with Redis Sentinel and multi‑topic message queues.
Live‑Streaming Pipeline : The end‑to‑end flow includes RTMPS ingestion at edge POP nodes, RTMP forwarding to data centers, transcoding to multiple resolutions, and MPEG‑DASH delivery to clients. Strategies for handling traffic spikes, cache‑first fetching, and request timeout tuning are discussed.
Performance Optimization : The article outlines a layered approach: database tuning, horizontal sharding, cache‑first strategies, hardware upgrades (HugePages, CPU affinity), JVM tuning, and parallel request handling with CountDownLatch.
Automated Traffic Replay Testing : Real‑user request logs are captured via Spring Interceptors and replayed against new services to detect regressions. Both offline and online replay modes are supported, with diff comparison to identify bugs.
DaTaobao Tech
Official account of DaTaobao Technology
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.