分布式ID系统设计(1)

分布式ID系统设计(1)

在分布式服务中,需要对data和message进行唯一标识。
比如订单、支付等。然后在数据库分库分表之后也需要一个唯一id来表示。
基于DB的自增就肯定不能满足了。这个时候能够生成一个Global的唯一ID的服务就很有必要

我们姑且把它叫做id-server 。那么这么个id-server的设计和考虑需要什么

  1. 全局唯一:不能出现重复的id号 最基本要求。
  2. 趋势递增: 在innodb中使用的是聚集索引。B+Tree的pk最好是有序的
  3. 单调递增:保证下一个id一定要大于上一个id
  4. 安全:如果ID是连续的 被爬虫的可能性能就很大。有一些场景下会需要id的无序

上述 1 2 3对应三类场景。而且3和4是互斥的,不能使用同一个方案满足。

出了上述的对于id号码的要求。架构层还需要id-server可用性非常高。如果id-server瘫痪整个业务系统都是不可用的。基本就是业务瘫痪。

由上述的 总结出一个id-server 需要满足:

  1. 平均延迟和TP999延迟都要尽可能低;
  2. 高可用尽量满足99999
  3. QPS一定要高

常见方法介绍

UUID

uuid 标准包含32个16进制数字,以连字号为5段,形式8-4-4-4-12的36个字符。

Java下的UUID

· 优点:性能非常高 本地生成。没有任何网络消耗

. 缺点:

1.不容易存储。uuid太长 16字节128位 36长度字符串。很多场景不适用

2.信息不安全。毕竟里面包了mac地址 造成mac泄漏

3 id作pk的时候在某些场景下会有性能问题。比如MySQL-DB pk.无序的pk会导致数据位置频繁变动。严重影响性能。

类snowFlake方案

snowFlake 组成:

0(首位不用)-xxxxx(41位时间戳)-workerID(10位)-xxxx(12位序列号)

41位的时间可以表示(1L<<41) 大概是68年的时间 10位机器码可以表示1024机器。如果对idc划分有需求 可以划分一部分bit给idc 剩下的给workid。12个自增可以表示2的12次个ID。总的QPS应该能达到几百万

  • 优点:
    1. 毫秒数在高位 自增序列在低位。整个id都是趋势递增
    2. 不依赖数据库 以服务的方式部署 稳定性更高。生成ID的性能也高
    3. 可以根据自身业务特性分配bit位。较为灵活
  • 缺点:
    1. 强依赖机器时钟,如果机器上时钟回拨,会导致id重复或者服务不可用
相关推荐
色空大师10 分钟前
23种设计模式
java·开发语言·设计模式
闲人一枚(学习中)11 分钟前
设计模式-创建型-建造者模式
java·设计模式·建造者模式
2202_7544215428 分钟前
生成MPSOC以及ZYNQ的启动文件BOOT.BIN的小软件
java·linux·开发语言
蓝染-惣右介31 分钟前
【MyBatisPlus·最新教程】包含多个改造案例,常用注解、条件构造器、代码生成、静态工具、类型处理器、分页插件、自动填充字段
java·数据库·tomcat·mybatis
小林想被监督学习32 分钟前
idea怎么打开两个窗口,运行两个项目
java·ide·intellij-idea
HoneyMoose34 分钟前
IDEA 2024.3 版本更新主要功能介绍
java·ide·intellij-idea
我只会发热35 分钟前
Java SE 与 Java EE:基础与进阶的探索之旅
java·开发语言·java-ee
是老余36 分钟前
本地可运行,jar包运行错误【解决实例】:通过IDEA的maven package打包多模块项目
java·maven·intellij-idea·jar
crazy_wsp37 分钟前
IDEA怎么定位java类所用maven依赖版本及引用位置
java·maven·intellij-idea
.Ayang39 分钟前
tomcat 后台部署 war 包 getshell
java·计算机网络·安全·web安全·网络安全·tomcat·网络攻击模型