How Tinyid Generates Globally Unique IDs with Segment Allocation

Tinyid is a distributed ID system developed by Didi, based on Meituan's Leaf segment algorithm, supporting multi‑master DB mode and providing a tinyid‑client for easy integration. Unlike Leaf, Tinyid only supports segment mode, not snowflake.

Tinyid Features

Globally unique long IDs

Trend‑increasing IDs

HTTP and Java client access

Batch ID retrieval

Support for odd‑numbered sequences (1,3,5…)

Multiple DB configuration

Suitable scenarios: Systems that only need numeric, trend‑increasing IDs and can tolerate non‑continuous or wasted IDs.

Unsuitable scenarios: Order‑ID use cases where IDs are mostly continuous and can be inferred.

Tinyid Principle

Tinyid uses a segment‑allocation mode: a range of auto‑increment IDs is fetched from the database, e.g., (1,1000] representing 1000 IDs. The service loads the segment into memory and generates IDs locally. When the current segment is near exhaustion, a new segment is loaded asynchronously.

The following diagram illustrates the architecture:

Tinyid Implementation

The GitHub repository is https://github.com/didi/tinyid.git . Two access methods are provided: HTTP via Tinyid‑server and a Java client (tinyid‑client). Both require the tables tiny_id_info and tiny_id_token to be created.

CREATE TABLE `tiny_id_info` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT 'auto increment primary key',
  `biz_type` varchar(63) NOT NULL DEFAULT '' COMMENT 'business type, unique',
  `begin_id` bigint(20) NOT NULL DEFAULT '0' COMMENT 'initial ID',
  `max_id` bigint(20) NOT NULL DEFAULT '0' COMMENT 'current max ID',
  `step` int(11) DEFAULT '0' COMMENT 'segment length',
  `delta` int(11) NOT NULL DEFAULT '1' COMMENT 'increment per ID',
  `remainder` int(11) NOT NULL DEFAULT '0' COMMENT 'remainder',
  `create_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT 'creation time',
  `update_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT 'update time',
  `version` bigint(20) NOT NULL DEFAULT '0' COMMENT 'version',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uniq_biz_type` (`biz_type`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='ID info table';

CREATE TABLE `tiny_id_token` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT 'auto increment id',
  `token` varchar(255) NOT NULL DEFAULT '' COMMENT 'token',
  `biz_type` varchar(63) NOT NULL DEFAULT '' COMMENT 'business type the token can access',
  `remark` varchar(255) NOT NULL DEFAULT '' COMMENT 'remark',
  `create_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT 'creation time',
  `update_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT 'update time',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='token info table';

The tiny_id_info table stores segment data. The max_id field is updated with UPDATE tiny_id_info SET max_id = max_id + step WHERE ... to allocate a new segment (max_id, max_id+step]. The tiny_id_token table defines which tokens can access which business types.

Configuration for multiple master databases is placed in offline/application.properties, for example:

datasource.tinyid.primary.driver-class-name=com.mysql.jdbc.Driver
datasource.tinyid.primary.url=jdbc:mysql://127.0.0.1:3306/xin-master?autoReconnect=true&useUnicode=true&characterEncoding=UTF-8
datasource.tinyid.primary.username=junkang
datasource.tinyid.primary.password=junkang
datasource.tinyid.primary.maxActive=10

datasource.tinyid.secondary.driver-class-name=com.mysql.jdbc.Driver
datasource.tinyid.secondary.url=jdbc:mysql://localhost:3306/db2?autoReconnect=true&useUnicode=true&characterEncoding=UTF-8
datasource.tinyid.secondary.username=root
datasource.tinyid.secondary.password=123456
datasource.tinyid.secondary.maxActive=10

HTTP Interface

Tinyid‑server exposes four HTTP endpoints: nextId, nextIdSimple, nextSegmentId, and nextSegmentIdSimple. The first two return IDs, while the latter two return segment information.

nextId:
http://localhost:9999/tinyid/id/nextId?bizType=test&token=0f673adf80504e2eaa552f5d791b644c
Response:
{
  "data": [2],
  "code": 200,
  "message": ""
}

nextIdSimple:
http://localhost:9999/tinyid/id/nextIdSimple?bizType=test&token=0f673adf80504e2eaa552f5d791b644c
Response: 3

Tinyid‑client

When HTTP is not preferred, the Java client can be used. Add the dependency:

<dependency>
  <groupId>com.xiaoju.uemc.tinyid</groupId>
  <artifactId>tinyid-client</artifactId>
  <version>${tinyid.version}</version>
</dependency>

Configure the server address and token in application.properties:

tinyid.server=127.0.0.1:9999
tinyid.token=0f673adf80504e2eaa552f5d791b644c

Usage in Java:

// Get a single ID
Long id = TinyId.nextId("test");

// Get a batch of 10 IDs
List<Long> ids = TinyId.nextId("test", 10);

The source code interacts with the database via JdbcTemplate, for example:

@Override
public TinyIdInfo queryByBizType(String bizType) {
    String sql = "select id, biz_type, begin_id, max_id, step, delta, remainder, create_time, update_time, version from tiny_id_info where biz_type = ?";
    List<TinyIdInfo> list = jdbcTemplate.query(sql, new Object[]{bizType}, new TinyIdInfoRowMapper());
    if (list == null || list.isEmpty()) {
        return null;
    }
    return list.get(0);
}

Conclusion

Both HTTP and client modes are supported, but the client mode is recommended because IDs are generated locally; a larger step yields higher QPS (up to millions). Using the client reduces load on Tinyid‑server.