Mastering Global Unique ID Generation: 7 Proven Strategies for Distributed Systems

Two Main Approaches

When databases are sharded, the traditional auto‑increment primary key no longer works, so we need new solutions. The problem can be tackled either by letting the database handle ID generation or by generating IDs in Java code.

1. Database‑Level Solutions

1.1 Adjust MySQL Auto‑Increment Settings

After sharding with MyCat, each physical database (db1, db2, db3) can have its own auto‑increment start value and step size. Use the following SQL to view and modify the variables:

<code>SHOW VARIABLES LIKE 'auto_increment%';</code>

<code>SET @@auto_increment_increment=9;</code>

When creating tables, you can set the initial auto‑increment value directly:

<code>CREATE TABLE test01(id INTEGER PRIMARY KEY AUTO_INCREMENT, username VARCHAR(255)) AUTO_INCREMENT=8;</code>

By assigning start values 1, 2, 3 and a common step of 3 to db1, db2, and db3 respectively, you can achieve global uniqueness, though this method is cumbersome and not recommended for large‑scale systems.

1.2 MySQL + MyCat + Zookeeper

If you use MyCat as the sharding middleware, you can configure Zookeeper to provide distributed auto‑increment IDs. The key steps are:

Set the primary‑key generation mode to 4 (Zookeeper) in

server.xml

.

Configure the table auto‑increment and primary key in

schema.xml

.

Specify Zookeeper connection details in

myid.properties

.

Define the target table in

sequence_conf.properties

.

After restarting MyCat, the database will generate globally unique IDs without additional Java code.

2. Java‑Based ID Generation

2.1 UUID

UUIDs are easy to generate locally but have drawbacks: they are long strings unsuitable for MySQL indexing, cause random I/O patterns, and may expose MAC addresses, making them less secure for many applications.

2.2 Snowflake Algorithm

Twitter's Snowflake algorithm creates 64‑bit IDs composed of a sign bit, 41‑bit timestamp, 10‑bit worker ID, and 12‑bit sequence. It guarantees uniqueness and roughly increasing order, which is friendly to database indexes.

<code>public class IdWorker {
    private static final long twepoch = 1288834974657L;
    private static final long workerIdBits = 5L;
    private static final long datacenterIdBits = 5L;
    private static final long maxWorkerId = -1L ^ (-1L << workerIdBits);
    private static final long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);
    private static final long sequenceBits = 12L;
    private static final long workerIdShift = sequenceBits;
    private static final long datacenterIdShift = sequenceBits + workerIdBits;
    private static final long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;
    private static final long sequenceMask = -1L ^ (-1L << sequenceBits);
    private long lastTimestamp = -1L;
    private long sequence = 0L;
    private final long workerId;
    private final long datacenterId;
    // constructors and methods omitted for brevity
    public synchronized long nextId() {
        long timestamp = timeGen();
        if (timestamp < lastTimestamp) {
            throw new RuntimeException("Clock moved backwards. Refusing to generate id.");
        }
        if (lastTimestamp == timestamp) {
            sequence = (sequence + 1) & sequenceMask;
            if (sequence == 0) {
                timestamp = tilNextMillis(lastTimestamp);
            }
        } else {
            sequence = 0L;
        }
        lastTimestamp = timestamp;
        return ((timestamp - twepoch) << timestampLeftShift)
                | (datacenterId << datacenterIdShift)
                | (workerId << workerIdShift) | sequence;
    }
    // helper methods omitted
}
</code>

Usage example:

<code>IdWorker idWorker = new IdWorker(0, 0);
for (int i = 0; i < 1000; i++) {
    System.out.println(idWorker.nextId());
}
</code>

2.3 Meituan’s Leaf Service

Leaf provides two modes: segment mode (database‑backed) and Snowflake mode (Zookeeper‑backed). In segment mode, a proxy server fetches ID segments from a MySQL table

leaf_alloc

, reducing database load. In Snowflake mode, Leaf uses Zookeeper for coordination.

2.3.1 Segment Mode

Create the

leaf_alloc

table:

<code>CREATE DATABASE leaf;
CREATE TABLE `leaf_alloc` (
  `biz_tag` varchar(128) NOT NULL DEFAULT '',
  `max_id` bigint NOT NULL DEFAULT '1',
  `step` int NOT NULL,
  `description` varchar(256) DEFAULT NULL,
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`biz_tag`)
) ENGINE=InnoDB;
INSERT INTO leaf_alloc(biz_tag, max_id, step, description) VALUES('leaf-segment-test', 1, 2000, 'Test leaf Segment Mode Get Id');
</code>

After starting the service, request

http://localhost:8080/api/segment/get/leaf-segment-test

to obtain an ID. Monitoring is available at

http://localhost:8080/cache

.

2.3.2 Snowflake Mode

Enable Snowflake with Zookeeper in

leaf.properties

:

<code>leaf.snowflake.enable=true
leaf.snowflake.zk.address=192.168.91.130
leaf.snowflake.port=2183
</code>

Then access

http://localhost:8080/api/snowflake/get/test

for IDs.

2.4 Redis Counter

Redis can generate IDs using the

INCRBY

command, which is simple and fast.

2.5 Zookeeper Sequential Nodes

Create a sequential node under a designated path (e.g.,

job-

). Zookeeper returns a name like

job-0000000003

. Combine it with a type prefix to form a globally unique ID.

Conclusion

The article presents seven distinct global unique ID generation strategies—database auto‑increment tuning, MyCat + Zookeeper, UUID, Snowflake, Leaf (segment and Snowflake modes), Redis counters, and Zookeeper sequential nodes—providing practical code snippets and configuration guidance for system designers.