# raptor-gid

**Repository Path**: lmhitysu/raptor-gid

## Basic Information

- **Project Name**: raptor-gid
- **Description**: 全局唯一ID实现
- **Primary Language**: Java
- **License**: Apache-2.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 3
- **Created**: 2021-05-20
- **Last Updated**: 2021-05-20

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

#raptor-gid

# 简介
Raptor-gid是一个全局ID生成组件（Global ID），可以完全替代数据库序列，并提供更为丰富的序列类型，更高的可用性保障。业界有多种称呼：发号器、ID生成器、序列发生器......

常用于分布式系统环境下需要保证序列全局唯一的场景：
* 主键
* 消息ID
* 订单ID
* 事务ID
* 日志ID
* ......


目前支持2大类型的序列：

* 本地计算型  

*snowflake*
> 来源于Twitter，宏观上按时间自增，由3部分二进制数据构成`42位timestamp | 10位 workerid |  12位 seq`，总长度固定在64bit，workerid和seq位数可适当调整。

*ticktock*
> 是snowflake的变种，将snowflake的3个部分改为十进制表达，`12位timestamp(yyMMddHHmmss) + 3位workerid + 4位seq`，workerid和seq位数可适当调整。

* 远程计算型   
 
*dbseq* (暂未实现)  
> 采用数据库机制实现（MySQL自增字段、Oracle sequence等）

*breadcrumb*
> 采用Zookeeper计数器实现，功能上类似于Oracle sequence，由name（序列名称）、incr（增长步长）、 start（起始大小）、 cache（缓冲大小）4个参数来描述一个breadcrumb序列。

注：与Oracle sequence的区别是序列值无法循环。

# 快速对比

| 类型 | 全局唯一 | 连续 | 单调递增 | 可循环 | 时间相关 | 可制造 | 可反解 | 
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| snowflake | Y | N[粗略有序] | N[宏观上单调递增] | N | Y | Y | Y | 
| ticktock | Y | N[粗略有序]| N[宏观上单调递增] | N | Y | Y | Y | 
| breadcrumb | Y | Y | Y | N | N | Y | N | N |

* **全局唯一**： 同一序列的所有使用者不会出现唯一性冲突，而不是局部唯一，比如某个使用者（模块或子系统）内部唯一。
* **连续**：如果本次取值为 n，下一次取值一定是 n + 1，则是连续的；如果下一次取值不能保证为 n + 1，则是非连续的；
* **单调递增**：如果本次取值为 n，下一次取值一定是一个比 n 大的数，则是单调递增的；
* **可制造**：当系统不可用时某些未被处理的请求，在后续处理过程中需要模拟制造出当时的ID;
* **可反解**：序列中通常会包含一些元信息，比如时间、产生的主机等，用于排错等场景；

## snowflake 
### 特性
**关键词**：全局唯一/粗略有序/时间相关/趋势递增/可制造/可反解

基于”时间戳+节点编号+序列号“共计64bit组合而成的序列，可以保证全局唯一和宏观自增，不依赖于数据库等组件，仅本地计算即可，性能非常高；**默认情况下（序列号占12bit），理论上每秒可产生4096000个序列值**。

注意：序列值对应java的long类型，数据库的BIGINT类型。

> 样例：576982432306171904,576982432310366208,576982432310366209 ......

###优缺点
【优】
* 趋势递增：毫秒数在高位，序列号在低位
* 性能高无单点：本地计算不依赖数据库等第三方
* 使用灵活：三个组成部分的位数可按需调整

【缺】
* 人工不可读
* 序列不连续
* 无法控制生成规则（比如序列起始等）
* 强依赖机器时钟，如果时钟回拨，会导致序列重复或者系统不可用

### 使用场景
需要高性能而又对序列值的可读性要求不高的场景，比如性能跟踪用的traceid、日志编号、消息编号等。


## ticktock
### 特性
**关键词**：全局唯一/粗略有序/时间相关/趋势递增/可制造/可反解

跟snowflake类似，**默认情况下（序列号占4位），理论上每秒可产生10000个序列值**。

注意：序列值对应java的long类型。

>样例：1704241912300011563,1704241912300011567,1704241912310013091 ......

###优缺点
【优】
* 可读性高
* 趋势递增：时间戳在高位，序列号在低位
* 性能高无单点：本地计算不依赖数据库等第三方
* 使用灵活：三个组成部分的位数可按需调整

【缺】
* 序列不连续
* 无法控制生成规则（比如序列起始等）
* 强依赖机器时钟，如果时钟回拨，会导致序列重复或者系统不可用

### 使用场景
需要高性能，高可读性要求的场景，比如订单号，业务流水号等。


## breadcrumb
### 特性
基于zookeeper生成的序列，序列值的生成类似于数据库的序列（Oralce的序列或MySQL的自增字段）。
> 样例：1、2、3、4、5 ......

###优缺点
【优】全局唯一、严格有序，可以完全替换数据库序列
【缺】依赖zookeeper，性能和可用性没有本地计算型序列高，序列值不能循环。
### 使用场景
传统使用数据库序列的场景。

#性能


# 快速使用
## 引入依赖
## 编写配置
## 获取序列

# 路线图