分布式环境下订单号的生成策略

1. 1. 1. 什么是分布式

 

如项目分布：订单模块，商品模块，支付模块。由于每个模块之间的访问压力的不同，可以根据需要各自部署在不同数量的服务器上，如订单模块3台，商品4台，支付模块2台。

 

1. 1. 1. 分布式环境下订单号的生成要求

必要：全局唯一

其他的：趋势递增，高并发，高可用，信息安全，长度（过长会造成存储压力过大）

1. 1. 1. 生成策略：
         1. UUID

组成：当前日期+时间+时钟序列+机器识别码

优点：实现简单，不占用带宽

缺点：无序，不适合建立索引。

优点：生成简单，不占用宽带，本地生成，数据迁移不影响。

缺点：字母存储，无序，无法保证趋势递增，查询慢，不可读

场景：Token，图片id等

 

 

1. 1. 1. 1. 数据库自增

关系型数据库都实现了主键自增的特点；如在集群环境下，有3台数据库，分别设置其起始值为1,2,3，以及步长为3；进而实现集群环境下数据库的主键唯一的要求。

设置语法：

Set global auto_increment_increment = 3;

Set gloabl auto_increment_offset = ;

 

缺点：位数不确定，有溢出风险，高并发情况下有性能瓶颈。

适应场景：并发小，数据增长慢的情况

1. 1. 1. 1. Snowflake

组成：41位时间戳 + 10为机器ID + 12位序列号（自增），并转化为18位的长整型。

 

优点：本地生成，不占宽带，毫秒在高位，低位是趋势递增。

缺点：依赖时钟 如果时间回拨可能会重复，效率比uuid慢

场景：Elk，mq，并发大的业务系统

1. 1. 1. 1. Redis自增ID

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

优点：不依赖数据库，灵活，没有单点故障，性能优于数据库

缺点：占用网络资源，需要增加额外服务插件

场景：并发大的业务系统

1. 1. 1. 对比

UUID	实现简单，不占用带宽	Id是无序的，查询慢，不适合建立索引	32字节
数据库自增	代码简单，数据递增	DB单点故障，新增加DB时有瓶颈	递增
snowflake	低位趋势递增，不占带宽，性能到	依赖于服务器时间	18字节
Redis自增id	无单点故障，性能高，递增	占用带宽，redis集群维护	自定义