How Ctrip Built a High‑Performance Distributed ID Generator for Millions of Users

Background

In a distributed architecture, generating a globally unique sequence number is a common challenge, especially when sharding databases. Ctrip needed a new user‑ID generation scheme to support its growing registration volume during a MySQL migration.

Requirements

Globally unique

Support high concurrency

Reflect certain attributes (e.g., registration channel)

High reliability and fault tolerance

High performance

Industry Solutions

Various approaches exist:

Database auto‑increment (simple but creates a single‑point load).

UUID (32‑character hex string; low DB pressure but not sortable).

Twitter Snowflake (41‑bit timestamp, 10‑bit machine ID, 12‑bit sequence; high performance, time‑ordered).

Redis INCR/INCRBY (single‑threaded atomic increment; can use clusters for higher throughput).

Flicker’s MySQL auto_increment + replace‑into (used as baseline).

Custom e‑commerce order‑ID schemes (timestamp + business info).

Final Solution

We adopted and improved the Flicker approach: a single table with an auto‑increment id and a stub column storing the server IP. Each server updates only its own row using

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

and reads the generated id.

To avoid a single‑point failure, each server gets a distinct id (e.g., 5, 2, 3, 4). The retrieved id is multiplied by a configurable segment size (e.g., 1000) and stored in an AtomicLong. The segment provides a range of IDs in memory, reducing DB round‑trips. When the segment is exhausted, the first thread fetches a new segment from the DB.

This design yields a lightweight (<20 lines) distributed ID generator with high throughput and acceptable ID waste after server restarts.

Production Results

After more than five months in production the service is stable, with average SOA response time 0.59 ms and client call latency 2.52 ms.