Design and Implementation of a Distributed Unique ID Generator for User IDs

Background : In distributed architectures, generating a globally unique sequence number is a frequent problem, especially when databases are sharded. During Ctrip's migration of its account database to MySQL, a new user‑ID generation scheme was needed to support massive registration traffic.

Requirement Features :

Globally unique IDs

Support high concurrency

Contain some attribute information

High reliability and fault‑tolerance

High performance

Industry Solutions :

Various approaches exist, such as using auto‑increment columns, UUIDs, Twitter's Snowflake, Redis atomic counters, and custom MySQL‑based schemes (e.g., Flicker). Each method has its own advantages and drawbacks regarding performance, ordering, and complexity.

Final Solution :

The chosen design builds on the Flicker approach, using a single‑table auto‑increment column combined with an in‑memory segment cache. The table schema is:

SEQUENCE_GENERATOR_TABLE
id   stub
1    192.168.1.1

When a new ID block is needed, the system executes:

REPLACE INTO SEQUENCE_GENERATOR_TABLE (stub) VALUES ("192.168.1.1");

and retrieves the generated ID with:

SELECT id FROM SEQUENCE_GENERATOR_TABLE WHERE stub = "192.168.1.1";

To avoid single‑point failures, each server updates only its own row (identified by its IP), ensuring atomic single‑row operations. The retrieved ID is multiplied (e.g., by 1000) to form a segment, stored in an AtomicLong :

atomic.set(n * 1000);
currentMaxId = (n + 1) * 1000;

Subsequent requests obtain IDs via:

Long uid = atomic.incrementAndGet();

If the segment is exhausted, the thread blocks while the earliest request fetches a new segment from the database and updates the atomic values. This logic fits within about 20 lines of code and solves distributed ID generation efficiently.

One caveat is that after a server restart, unused IDs in the in‑memory cache may be lost; therefore, the segment size should be tuned to balance performance and waste.

Online Effect : After more than five months in production, the service has been very stable, with average SOA response time of 0.59 ms and client call latency of 2.52 ms.