廊坊市做网站的公司有哪些,教师网站建设企业实践总结,保定市网站制作公司,东莞关键词优化平台对于分布式Id来说#xff0c;在面试过程中也是高频面试题#xff0c;所以主要针对分布式id实现方案进行详细分析下。
应用场景
对于无论是单机还是分布式系统来说#xff0c;对于很多场景需要全局唯一ID#xff0c;
数据库id唯一性日志traceId 可以方便找到日志链#… 对于分布式Id来说在面试过程中也是高频面试题所以主要针对分布式id实现方案进行详细分析下。
应用场景
对于无论是单机还是分布式系统来说对于很多场景需要全局唯一ID
数据库id唯一性日志traceId 可以方便找到日志链一般使用uuid 更多一点幂等场景下mq、api接口层面 保证幂等下业务系统订单id
UUID
最简单的就是使用UUIDUUID的规则是一组32位16进制数字构成形式就是8-4-4-4-8主要就是利用当前时间和时钟序列 和 全局唯一的IEEE机器识别。
UUID uuid UUID.randomUUID();307e16d0-26d4-4fff-ab06-a9397b8369fb优点实现简单全局唯一缺点是不具有连续性并且占用空间比较大对于mysql主键来说不具备友好。
数据库自增ID
就目前公司内部其实还是使用的数据库自增id进行处理对于数据库来说的话就是多个实例操作表自增id对于业务来说使用自定义时间戳来实现。
还有一种方式就是创建一个单独的表通过数据库本身的自增id来保证。
CREATE TABLE test_order_id (id bigint NOT NULL AUTO_INCREMENT,title char(1) NOT NULL,PRIMARY KEY (id),UNIQUE KEY title (title)
) ENGINE InnoDB AUTO_INCREMENT1 DEFAULT CHARSET utf8;BEGIN;REPLACE INTO test_order_id (title) values (p) ;
SELECT LAST_INSERT_ID();COMMIT;这种方式的优点就是 实现比较简单但是缺点就是不具备高可用性如果mysql是单节点部署的话那么整体就不可用。
高可用数据库实例
部署多个数据库实例通过设置不同的自增比如mysql实例1自增是2从1开始mysql实例2 从2开始那么就是 实例1 1、3、5、7实例2: 2、4、6、8。
对于并发量不高的场景来说可以解决但是对于高并发场景来说数据库实例就是成为瓶颈。如果1秒1000个订单那么就需要频繁访问1000次数据库显然这个网络以及IO就成为短板。
号段模型
号段模式其实就是通过在一个表中唯一一条记录然后通过业务区分每次获取一个区间的号这样比如获取1-1000的号段那么就只需要交互一次数据库并且通过添加version来避免出现并发修改数据的问题。
Redis
除了借助于mysql还可以通过redis的自增 incr命令来实现自增ID并且可以部署一主多从的架构来保证高可用性。 public long nextId(String item){// 1.生成时间戳LocalDateTime now LocalDateTime.now();// 格林威治时间差long nowSecond now.toEpochSecond(ZoneOffset.UTC);// 我们需要获取的 时间戳 信息long timestamp nowSecond - BEGIN_TIMESTAMP;// 2.生成序号 --》 从Redis中获取// 当前当前的日期String date now.format(DateTimeFormatter.ofPattern(yyyy:MM:dd));// 获取对应的自增的序号Long increment redisTemplate.opsForValue().increment(id: item : date);return timestamp 32 | increment;}具体原理其实就是 当前时间戳-制定时间 32 | 自增的id 这样输出的就是连续的id了
雪花算法
雪花算法整体结构就是 64位 0-41位位毫秒值5位是数据中心id5位机器id最后12位是毫秒级别内的自增id
分析源码 可以大概了解其核心流程
雪花算法时钟回拨
在实际的生产环境中分布式环境下其实时钟是很难保证统一的所以就可能实现时间不一样的情况导致时钟回拨问题我们来分析两类问题
情况1:UTC时间是8点01实例机器是8点整 情况2:UTC时间是8点01 实例机器是8点03
对于情况1来说其实就调整一下时间就好1分钟内的id生成不用就可以。但是对于第二种情况相当于需要从3分回退到01分那么其中的2分钟的时间已经生成了对应的id如果在次生成就会出现id重复的问题
如何解决呢 其实比较简单大方向就是如果时间短那么就等得阻塞对应的时间就可以如果超过1S以上服务直接下线通过其他实例获取id就可以。
其他
业界有主流的其他方案具体可以详细看 百度、美团对应的解决方案这里自己查看对应文档就可以。
总结
从上面的分析可以知道 目前业界主流的方案我们来抽丝剥茧下对于设计一个分布式id来说需要哪些核心点 1.需要顺序 这样可以简单清晰 2.依赖的服务需要高可用、高性能 3.全局唯一 4.有具体的业务含义比如针对订单号11xxx 开始还款订单21xxx借款订单31xxx。就比较清晰。
