Design and Implementation of a High‑Concurrency WeChat Red‑Envelope System Simulating 10 Billion Requests

Background: Inspired by an article about handling 10 billion red‑envelope requests, the author explores how to simulate such workload on a single machine.

Goals: support 1 million concurrent connections, achieve at least 30 k QPS and up to 60 k QPS, and simulate shaking and sending red envelopes.

Assumptions and calculations: based on user numbers, server count, and peak QPS derived from 10 billion requests over four hours, resulting in roughly 1.2 k QPS per server and a single‑machine peak of about 2.3 k–6 k QPS.

Hardware & software: Golang 1.8r3, Ubuntu 12.04, Dell R2950 8‑core 16 GB server, 17 client VMs (esxi) each with 4 core 5 GB, together establishing one million connections.

Implementation: partition connections into multiple SETs, one goroutine per connection, client coordination via NTP timestamps, monitoring with a Python script and ethtool, and a simple monitoring server to aggregate counters.

Code snippet for alias command:

Alias ss2=Ss –ant | grep 1025 | grep EST | awk –F: "{print $8}" | sort | uniq –c

Testing phases: Phase 1 – establish connections; Phase 2 – drive 30 k QPS; Phase 3 – increase to 60 k QPS. Results show stable QPS at 30 k, while 60 k QPS exhibits instability due to goroutine scheduling, network latency, and packet loss.

Analysis: identified bottlenecks such as Go scheduler overhead, network delays, and packet drops; suggested improvements like using a high‑performance Disruptor queue and more CPU resources.

Conclusion: the prototype meets its design objectives, proving a single server can handle the required load and can be horizontally scaled to achieve the full ten‑billion‑request target.