分布式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重复或者服务不可用
相关推荐
七星静香23 分钟前
laravel chunkById 分块查询 使用时的问题
java·前端·laravel
Jacob程序员24 分钟前
java导出word文件(手绘)
java·开发语言·word
ZHOUPUYU24 分钟前
IntelliJ IDEA超详细下载安装教程(附安装包)
java·ide·intellij-idea
stewie627 分钟前
在IDEA中使用Git
java·git
Elaine20239142 分钟前
06 网络编程基础
java·网络
G丶AEOM44 分钟前
分布式——BASE理论
java·分布式·八股
落落鱼20131 小时前
tp接口 入口文件 500 错误原因
java·开发语言
想要打 Acm 的小周同学呀1 小时前
LRU缓存算法
java·算法·缓存
镰刀出海1 小时前
Recyclerview缓存原理
java·开发语言·缓存·recyclerview·android面试
阿伟*rui3 小时前
配置管理,雪崩问题分析,sentinel的使用
java·spring boot·sentinel