How to Build a Strictly Incremental Distributed ID System with Redis, MySQL, and Nacos

Introduction

In distributed systems with rapidly growing business data, ID generation must be highly available, fault‑tolerant, high‑performance, and globally unique.

Technical Background

Initially we used a single‑row sequence table in MySQL: each request opened a transaction, locked the row, read the current value, and incremented it. Tests showed an average of 1.46 ms per ID locally and 5.32 ms across data centers.

Drawbacks of the database‑read approach include:

Database pressure spikes when QPS is high.

Increased latency across data centers.

Complications with sharding when using frameworks like Hibernate’s TABLE strategy.

Occasional deadlocks causing insert failures.

The main advantage is that IDs are strictly increasing, which is critical for our business.

Existing Distributed ID Solutions

Common approaches:

UUID : Simple to generate via UUID.randomUUID(), but 128‑bit length, poor readability, and not sequential.

Snowflake : Twitter’s 64‑bit algorithm using timestamp, machine ID, and sequence; high throughput but only roughly incremental and suffers from clock rollback.

Baidu uid‑generator : Snowflake‑inspired with customizable bit allocation; good performance but requires MyBatis integration and also only trend‑incremental.

Meituan Leaf : Offers Snowflake mode and segment mode; segment mode reduces DB load by allocating blocks of IDs to memory, yet only guarantees trend‑incremental IDs and may overload a single server.

Other options include Zookeeper sequential nodes and Didi’s TinyID.

Strictly Incremental Distributed ID Scheme

To achieve strict incrementality we designed a solution based on a database segment model combined with Redis caching and a Nacos switch.

Two generation modes:

Cache‑based generation.

Database‑table generation.

Implementation details:

MySQL sequence table fields: bizId (business identifier), maxId (current segment max), step (segment size).

Redis stores three keys per business: currentId, maxId, step.

Nacos switch controls the active mode: on = cache mode, off = DB mode; listeners automatically switch modes.

Startup: if the Nacos switch is on, the system checks Redis for the keys; if missing, it loads the next segment from MySQL into Redis.

On each write request:

If Redis heartbeat is healthy and the switch is on, use cache mode:

Increment currentId via INCR.

Validate the ID; if it exceeds a configurable threshold, synchronize Redis with the database (advance to the next segment).

An asynchronous task monitors usage; when 30 % of the segment is consumed, the next segment is pre‑loaded.

Otherwise, fall back to DB mode: lock the sequence row, read maxId, increment it, and use it as the ID.

Failure handling:

If Redis becomes unavailable, the heartbeat task disables the switch, forcing DB mode.

When Redis recovers, toggling the Nacos switch re‑enables cache mode after loading a fresh segment.

Conclusion

The Redis‑based approach provides strictly incremental IDs without adding new third‑party dependencies, leveraging Redis’s atomic increment and high QPS capability (most IDs generated in ≤ 1 ms). The fallback DB mode adds resilience, increasing latency only by a few milliseconds, which is acceptable.

Performance tests show roughly a 10× improvement for intra‑data‑center ID retrieval and a 7× improvement across data centers compared with the pure MySQL sequence method, while also eliminating previous deadlock issues.

For scenarios that do not require strict incrementality, any of the reviewed frameworks (UUID, Snowflake, uid‑generator, Leaf, etc.) can be used.