Comprehensive Overview of Distributed ID Generation Strategies in Java

In complex distributed systems, unique identifiers are required for massive data, and traditional database auto‑increment IDs often cannot meet the needs of sharding, ordering, or security. This article introduces several distributed ID solutions, compares their pros and cons, and provides Java code samples.

1. UUID

UUID (Universally Unique Identifier) is generated from timestamp, counter, and hardware MAC address, producing a 36‑character string. Java provides java.util.UUID for generation:

import java.util.UUID;

public class Test {
    public static void main(String[] args) {
        System.out.println(UUID.randomUUID());
    }
}

Example output: b0378f6a-eeb7-4779-bffe-2a9f3bc76380 . UUID guarantees global uniqueness but has drawbacks such as high storage cost, potential information leakage, and poor performance as a MySQL primary key.

2. Database Auto‑Increment ID

MySQL auto‑increment IDs work per table and cannot guarantee global uniqueness after sharding. Two common solutions are presented:

2.1 Primary‑Key Table

A dedicated table stores a single auto‑increment column. Applications obtain an ID by inserting a row and reading LAST_INSERT_ID() :

CREATE TABLE `unique_id` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `biz` char(1) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `biz` (`biz`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

BEGIN;
REPLACE INTO unique_id (biz) values ('o');
SELECT LAST_INSERT_ID();
COMMIT;

2.2 Setting Auto‑Increment Step

By configuring different step sizes on each MySQL instance, IDs can be made unique across instances. The step can be inspected with show variables like '%increment%' , but high concurrency may still cause scalability issues.

3. Segment Mode

Segment mode fetches a range of IDs from the database into memory, allowing the service to allocate IDs locally until the range is exhausted. The range is updated using an optimistic‑lock version field.

CREATE TABLE id_generator (
  id int(10) NOT NULL,
  max_id bigint(20) NOT NULL COMMENT 'current max id',
  step int(20) NOT NULL COMMENT 'segment length',
  biz_type int(20) NOT NULL COMMENT 'business type',
  version int(20) NOT NULL COMMENT 'optimistic lock version',
  PRIMARY KEY (`id`)
);

This approach reduces database load but may produce non‑continuous IDs after server restarts.

4. Redis INCR

Redis's atomic INCR command can generate globally unique IDs. A simple Java implementation uses StringRedisTemplate to increment a key per day and combine it with a timestamp:

@Component
public class RedisDistributedId {
    @Autowired
    private StringRedisTemplate redisTemplate;
    private static final long BEGIN_TIMESTAMP = 1659312000L;
    public long nextId(String item) {
        LocalDateTime now = LocalDateTime.now();
        long nowSecond = now.toEpochSecond(ZoneOffset.UTC);
        long timestamp = nowSecond - BEGIN_TIMESTAMP;
        String date = now.format(DateTimeFormatter.ofPattern("yyyy:MM:dd"));
        Long increment = redisTemplate.opsForValue().increment("id:" + item + ":" + date);
        return timestamp << 32 | increment;
    }
}

Redis‑based IDs are fast but require persistence handling for Redis failures.

5. Snowflake Algorithm

Twitter's Snowflake splits a 64‑bit number into timestamp, datacenter ID, worker ID, and sequence fields, allowing up to 4096 IDs per millisecond. The Java implementation below follows the original design:

public class SnowflakeIdWorker {
    private final long twepoch = 1604374294980L;
    private final long workerIdBits = 5L;
    private final long datacenterIdBits = 5L;
    private final long maxWorkerId = -1L ^ (-1L << workerIdBits);
    private final long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);
    private final long sequenceBits = 12L;
    private final long workerIdShift = sequenceBits;
    private final long datacenterIdShift = sequenceBits + workerIdBits;
    private final long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;
    private final long sequenceMask = -1L ^ (-1L << sequenceBits);
    private long workerId;
    private long datacenterId;
    private long sequence = 0L;
    private long lastTimestamp = -1L;
    // constructors, nextId(), tilNextMillis(), timeGen() omitted for brevity
}

Clock rollback can cause duplicate IDs; typical solutions record the last timestamp to avoid this.

6. Meituan (Leaf)

Leaf is an open‑source project from Meituan that supports both segment mode and Snowflake mode (the latter relies on ZooKeeper for worker ID allocation). It can switch between the two strategies.

7. Baidu (UidGenerator)

UidGenerator is Baidu's Java implementation based on Snowflake, offering higher QPS (over 6 million) and using MySQL to allocate worker IDs. Its timestamp field is 28 bits, giving about 8.5 years of range by default.

8. Didi (TinyID)

TinyID builds on Meituan's leaf‑segment algorithm, adds multi‑master database support, and provides both HTTP and client SDK integration. It only supports segment mode, not Snowflake.

Summary Comparison

The article concludes with a comparative table (image) summarizing the trade‑offs of each solution regarding uniqueness, ordering, performance, scalability, and operational complexity.

Thank you for reading; hope it helps you choose the right distributed ID strategy for your system.