# orderIdGeneration

**Repository Path**: t_lixiang1995/orderIdGeneration

## Basic Information

- **Project Name**: orderIdGeneration
- **Description**: 分布式ID生成方案（UUID+DB自增+Snowflake+Redis incr）
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 3
- **Forks**: 0
- **Created**: 2020-06-15
- **Last Updated**: 2022-07-27

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# orderIdGeneration
分布式ID生成方案（UUID+DB自增+Snowflake+Redis incr）
分布式环境订单ID生成方案

方案一：UUID(唯一通用识别码)

组成： 当前日期+时间+时钟序列+机器识别号（Mac地址或其他）。
在分布式系统中，所有元素都不需要通过中央控制端来判断数据唯一性。

方案二：数据库自增

关系型数据库都实现数据库自增ID；MySQL通过AUTO_INCREMENT实现、Oracle通过Sequence序列实现。 在数据库集群环境下，不同数据库节点可设置不同起步值、相同步长来实现集群下生成全局唯一、递增ID。

方案三：Snowflake(雪花算法)

组成： 41位时间戳+10位机器ID+12位序列号（自增），转换为长度为18的长整型。
Twitter为满足每秒上万条消息的创建，每条消息都必须分配全局唯一ID，这些ID需要趋势递增，方便客户端排序。

方案四：Redis(incr自增ID)

Redis实现了incr(key) API用于将key的值递增1，并返回结果。
如果key不存在，则创建并赋值为0，然后再执行incr操作。

总结：

策略一：UUID

优点： 实现简单、不占用宽带
缺点： 无序、不可读、查询慢
格式： 32位字符

策略二：DB自增

优点： 无代码、递增
缺点： DB单点故障、扩展性瓶颈
格式： 数字

策略三：Snowflake

优点： 不占用宽带、低位趋势递增
缺点： 依赖服务器时间
格式： 18位数字

策略四：Redis

优点： 无单点故障、性能优于DB、递增
缺点： 占用宽带、Redis集群维护
格式： 12位自由组合