Java 核心技术面试精讲
杨晓峰
前 Oracle 首席工程师
125942 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 44 讲
Java 核心技术面试精讲
15
15
1.0x
00:00/00:00
登录|注册

第39讲 | 谈谈常用的分布式ID的设计方案?Snowflake是否受冬令时切换影响?

暴露信息
可预测性
时钟偏斜问题
Snowflake算法
数据库自增序列
唯一、有序、有意义、高可用性、紧凑性
不受影响,依赖System.currentTimeMillis()
包括时间戳、WorkerID、序列号
64位长度
Snowflake算法并发生成数量限制的解决办法
其他分布式领域热点
分布式系统中的时序问题
主流方案的优缺点分析
业务场景需求要点
主流方案的优缺点分析
需求要素
受冬令时切换影响
结构
国内大厂的开源方案
Redis、ZooKeeper、MongoDB等中间件方案
基于Twitter的Snowflake
基于数据库自增序列
一课一练
知识扩展
考点分析
Snowflake算法
常用方案
分布式ID设计方案

该思维导图由 AI 生成,仅供参考

专栏的绝大部分主题都侧重于 Java 语言和虚拟机,基本都是单机模式下的问题,今天我会补充一个分布式相关的问题。严格来说,分布式并不算是 Java 领域,而是一个单独的大主题,但确实也会在 Java 技术岗位面试中被涉及。在准备面试时,如果有丰富的分布式系统经验当然好;如果没有,你可以选择典型问题和基础技术进行适当准备。关于分布式,我自身的实战经验也非常有限,专栏里就谈谈从理论出发的一些思考。
今天我要问你的问题是,谈谈常用的分布式 ID 的设计方案?Snowflake 是否受冬令时切换影响?

典型回答

首先,我们需要明确通常的分布式 ID 定义,基本的要求包括:
全局唯一,区别于单点系统的唯一,全局是要求分布式系统内唯一。
有序性,通常都需要保证生成的 ID 是有序递增的。例如,在数据库存储等场景中,有序 ID 便于确定数据位置,往往更加高效。
目前业界的方案很多,典型方案包括:
基于数据库自增序列的实现。这种方式优缺点都非常明显,好处是简单易用,但是在扩展性和可靠性等方面存在局限性。
基于 Twitter 早期开源的Snowflake的实现,以及相关改动方案。这是目前应用相对比较广泛的一种方式,其结构定义你可以参考下面的示意图。
整体长度通常是 64 (1 + 41 + 10+ 12 = 64)位,适合使用 Java 语言中的 long 类型来存储。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

分布式ID设计方案及Snowflake算法是否受冬令时切换影响是本文的主要内容。文章首先介绍了分布式ID的基本要求,包括全局唯一和有序性,并列举了常用的分布式ID设计方案,如基于数据库自增序列、Twitter的Snowflake算法以及各种中间件提供的唯一ID解决方案。对于Snowflake算法是否受冬令时切换影响的问题,文章通过分析Snowflake算法的实现方式得出结论,指出其不受冬令时切换影响。作者建议读者针对特定方案进行深入分析,以便在面试或实际应用中有充分准备。文章强调了分布式系统的复杂性,需要从不同角度理解适用场景、架构和细节算法,并提出了一些思考角度,如业务需求、方案局限性和解决办法等。整体而言,本文涵盖了分布式ID设计方案和Snowflake算法的相关内容,为读者提供了技术上的深入思考和应用建议。文章还提到了分布式ID设计方案的优缺点分析,以及与分布式系统相关的其他热点话题,为读者提供了更多深入学习的方向。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《Java 核心技术面试精讲》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(18)

  • 最新
  • 精选
  • 董朱明
    69年的极限问题不难解决,timestamp减个常量就可以了,对于已生成的历史id,可以导表刷id,当然,这里涉及到个数据库设计原则,系统之间传递数据不应使用物理主键,这样刷id 就容易了

    作者回复: 高手

    2018-08-10
    3
    60
  • 有铭
    为啥最后一段是12的长度而不是别的数

    作者回复: 我提到了,各部分不是固定的,看业务需求,例如,集群小,位数可以设计短点儿,seq就可以更多位,时间也未必非要41位

    2018-08-07
    3
  • 安小依
    老师自己有没有计划,针对分布式单独出一个专栏,一直以来自己都想研究分布式,但是很多问题依旧搞不懂: zookeeper 选举过程、hdfs 存储出现故障namenode是怎么处理、MapReduce 作业调度问题需要做哪些权衡,不同异常下应该怎么解决,是忽略错误,还是直接退出…各个方案背后是什么样的利弊在协调着这些…

    作者回复: 术业有专攻,有特定专家出专栏

    2018-08-08
    2
  • 卡特
    因为snowflake的可预测性,可以提前生成好放到队列里,获取的时候直接获取。相当于做了一层缓存; 理论上可以解决短时间大量获取id的需求;
    2018-09-12
    1
    30
  • 袁伟
    一直有个疑问就是Snowflake 文中说的极限问题,目前确定它只能用69年,大家都用数据库的数字类型来存储,那么到了69年之后,后来人怎么处理,也许那个时候有更大数字来表示。但我还是想不出更合理的方式,也许我想多了,这个问题交给69年后的人来考虑,但我也想知道老师您是如何思考这个问题的
    2018-08-08
    2
    11
  • 大西瓜
    缩减workID长度,增加序列号长度
    2018-08-07
    8
  • 业余草
    19 年写的《5 大分布式 ID 生成器优缺点简单对比》值得一看,https://mp.weixin.qq.com/s/OnH7Xrow5-TlkAh5gxz_XQ
    2020-07-16
    7
  • 大继
    非常感谢大佬的教程,面试是我进步最快的状态, 这种状态维持一年,估计我可以上天,终于看完了。 。 总结,大佬给出的教程非常有营养,也看到大家都要看几遍,我也是一边看一边百度。 受益匪浅。
    2019-12-22
    7
  • RoverYe
    我们这边利用zk的唯一id特性
    2018-09-15
    5
  • 影子
    生成32位的自增长Id(int)老师有什么思路嘛
    2019-01-24
    3
收起评论
显示
设置
留言
18
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部