How to Stress-Test a VIP Payment Callback API with Distributed Locks

After a user successfully pays for a VIP membership, the client calls a backend endpoint to create or renew the membership; the article uses this scenario to illustrate a full‑scale stress test.

The processing logic first validates the request signature, then acquires a distributed lock (implemented with redis) keyed by user and order, checks order status, updates the VIP period, and finally releases the lock.

The API specification is provided: name “购买会员或续费会员”, URL /api/member/createOrRenewMember, JSON body containing sign, orderNo, and systemId. The response returns a code (0 for success), a message, and a data object with memberId and systemId.

Testing references a previous article on message‑queue performance testing and outlines two main difficulties: the lock allows only one order per user, so each request must use a unique order number, and the test must run against existing user accounts, imposing a requirement on the user pool size.

To solve these, the author parameterises the user ID and order number with an AtomicInteger and a pre‑loaded array of user IDs. By incrementing the atomic counter for each request and cycling through a 2000‑user array, the test guarantees uniqueness without random collisions.

Additional reading on Java thread safety is cited, including articles on atomicity, the dangers of i++, and composite atomic operations.

The test script is shown in full, importing utility classes, defining a static AtomicInteger i = new AtomicInteger(111000), constructing request parameters (days, memberId, orderNo built as "F" + RString.getString(4) + i.getAndAdd(1), etc.), fetching a user via Users.getStuUser(i.getAndAdd(1) % 2000), signing the request with RSAUtilLJT.sign, sending the POST with HttpPost, and asserting that the response contains the word “success”.

A pitfall is highlighted: although AtomicInteger is thread‑safe, not all its methods are; get() is not safe under concurrent updates, so the author consistently uses getAndAdd(). Experiments confirmed that a pool of 2000 users is sufficient for the test.