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

Introduction

In distributed systems, generating IDs that are highly available, high‑performance, and globally unique is critical, especially when business data grows rapidly.

Technical Background

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

Drawbacks of the database‑centric approach include:

Database pressure spikes under high QPS.

Cross‑region latency increases.

Framework‑specific constraints (e.g., Hibernate GenerationType.TABLE) complicate sharding.

Occasional deadlocks causing insert failures.

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

Existing Distributed ID Solutions

UUID : Simple to generate via UUID.randomUUID(), but the 128‑bit string is large, non‑incremental, and can degrade database write performance.

Snowflake : Twitter’s 64‑bit algorithm provides high throughput (millions of IDs per second) without external dependencies, but suffers from time‑rollback issues and does not guarantee strict increment.

Baidu uid‑generator : A Snowflake‑inspired library with customizable bit allocations and cached mode for better performance, yet it requires MyBatis integration and still produces trend‑incremental IDs.

Meituan Leaf : Offers Snowflake and segment modes; the segment mode reduces database reads by allocating blocks of IDs to memory, but strict increment cannot be guaranteed across multiple machines.

Other approaches (Zookeeper sequential nodes, Didi TinyID, etc.) are also available.

Strictly Incremental Distributed ID Scheme

To meet our strict‑increment requirement without maintaining a Zookeeper cluster, we designed a solution that combines a database segment mode with Redis caching and a Nacos switch.

Key components :

MySQL sequence table (fields: bizId, maxId, step).

Redis keys: currentId, maxId, step.

Nacos feature flag to toggle between cache mode (Redis) and DB mode.

Workflow :

On application startup, if the Nacos switch is on, check Redis for the business‑specific keys; if missing, load the next segment from MySQL into Redis (updating the DB to the next segment first).

When a write request arrives:

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

Increment currentId in Redis via INCR.

Validate the ID against a configurable threshold; if it exceeds, synchronize Redis with MySQL (advance DB segment, then set currentId = oldMaxId + step*0.1, maxId = oldMaxId + step).

After generating an ID, an asynchronous task checks whether 30 % of the current segment is used; if so, pre‑fetch the next segment.

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

Special cases:

If Redis becomes unavailable, the heartbeat task disables the Nacos switch, forcing DB mode (still fast enough and prevents business blockage).

When Redis recovers, toggling the Nacos switch back on triggers a switch to cache mode after updating the next segment to avoid duplicates.

Conclusion

The Redis‑based approach leverages its atomic increment to produce strictly increasing IDs with sub‑millisecond latency, handling high QPS workloads efficiently. Performance tests show a 10× improvement within the same data center and a 7× gain across regions compared to the pure MySQL sequence method.

In case strict increment is not required, any of the reviewed frameworks (UUID, Snowflake, uid‑generator, Leaf, etc.) can be adopted.

Diagram: