-
-
- 什么是分布式
-
如项目分布:订单模块,商品模块,支付模块。由于每个模块之间的访问压力的不同,可以根据需要各自部署在不同数量的服务器上,如订单模块3台,商品4台,支付模块2台。
-
-
- 分布式环境下订单号的生成要求
-
必要:全局唯一
其他的:趋势递增,高并发,高可用,信息安全,长度(过长会造成存储压力过大)
-
-
- 生成策略:
- UUID
- 生成策略:
-
组成:当前日期+时间+时钟序列+机器识别码
优点:实现简单,不占用带宽
缺点:无序,不适合建立索引。
优点:生成简单,不占用宽带,本地生成,数据迁移不影响。
缺点:字母存储,无序,无法保证趋势递增,查询慢,不可读
场景:Token,图片id等
-
-
-
- 数据库自增
-
-
关系型数据库都实现了主键自增的特点;如在集群环境下,有3台数据库,分别设置其起始值为1,2,3,以及步长为3;进而实现集群环境下数据库的主键唯一的要求。
设置语法:
Set global auto_increment_increment = 3;
Set gloabl auto_increment_offset = ;
缺点:位数不确定,有溢出风险,高并发情况下有性能瓶颈。
适应场景:并发小,数据增长慢的情况
-
-
-
- Snowflake
-
-
组成:41位时间戳 + 10为机器ID + 12位序列号(自增),并转化为18位的长整型。
优点:本地生成,不占宽带,毫秒在高位,低位是趋势递增。
缺点:依赖时钟 如果时间回拨可能会重复,效率比uuid慢
场景:Elk,mq,并发大的业务系统
-
-
-
- Redis自增ID
-
-
Redis实现了incr(key) API用于将key的值递增1,并返回结果。如果key不存在,则创建并复制为0,然后直行incr操作后返回1.
优点:不依赖数据库,灵活,没有单点故障,性能优于数据库
缺点:占用网络资源,需要增加额外服务插件
场景:并发大的业务系统
-
-
- 对比
-
UUID | 实现简单,不占用带宽 | Id是无序的,查询慢,不适合建立索引 | 32字节 |
数据库自增 | 代码简单,数据递增 | DB单点故障,新增加DB时有瓶颈 | 递增 |
snowflake | 低位趋势递增,不占带宽,性能到 | 依赖于服务器时间 | 18字节 |
Redis自增id | 无单点故障,性能高,递增 | 占用带宽,redis集群维护 | 自定义 |