大数据经典论文解读
徐文浩
bothub 创始人
13844 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 59 讲
大数据经典论文解读
15
15
1.0x
00:00/00:00
登录|注册

24 | Spanner(三):严格串行化的分布式系统

你好,我是徐文浩。
Spanner 在设计时候的目标之一,就是需要保障外部一致性(external consistency)。而这个外部一致性,其实也就是我们之前说过的可线性化(Linearizability)。通过上节课的学习,现在我们已经知道了,这是一个非常有挑战的目标。其中最大的挑战,在于不同服务器的时钟的差异。
Spanner 采用了两个主要的策略来解决这个问题,第一个是通过原子钟和 GPS 时钟,尽可能地缩短服务器之间的时钟差异。另一个,则是在实现分布式事务的时候,把时钟差异考虑进去,实际的事务提交会进行一定的等待,确保数据写入一定是考虑了最大误差和参与者最快的时钟下,才会实际提交事务。
那么,今天我们这节课,就会深入来讲解 Spanner 的这个分布式事务具体是怎么实现的。并且在这个过程中,我们会深入探讨分布式事务的可串行化和可线性化两个概念的差异在哪里。在学完这节课之后,我希望你能够收获两点:
第一个,自然是 Spanner 的分布式事务,具体是怎么实现的。这个也有助于你了解最新一代的分布式数据库的实现,现在已经有不少新的数据库,都是师从 Spanner 的论文了。
第二个,是深入理解分布式数据库的可串行化和可线性化概念的相关性和差别。分布式数据库的主要挑战,就来自这两方面。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

Spanner是一个严格串行化的分布式系统,旨在保障外部一致性。为了解决不同服务器时钟的差异,Spanner采用了原子钟和GPS时钟,并在实现分布式事务时考虑了时钟差异,确保数据写入时考虑了最大误差和参与者最快的时钟下才会实际提交事务。文章深入探讨了分布式事务的可串行化和可线性化两个概念的差异,以及Spanner事务的具体实现。可串行化是数据库事务隔离性的概念,而可线性化是分布式系统中对单个对象上操作的实时性要求。Spanner需要同时保障可串行化和可线性化,称之为严格串行化,以确保事务在外部看来是串行执行的,并且一旦一个事务执行成功,立刻去读取数据就能读取到最新数据。为了支持严格串行化,Spanner采用了TrueTime API接口,提供了一个有误差范围的时间概念。这些特点使得Spanner成为一个外部一致的数据库,为读者提供了深入了解分布式系统和数据库实现的机会。Spanner的TrueTime API保障了绝对时间的概念,确保数据读取只能看到在特定时间点之前已经提交成功的数据写入。Spanner支持多种读写事务类型,包括读写事务、快照读事务和普通快照读。其中,读写事务通过多个Paxos组参与的二阶段提交来确保事务的顺序性和一致性。Spanner的机制能够确保并发事务对同一记录的写入具有明确的先后关系,从而保障了数据的一致性和可靠性。Spanner的论文对于分布式数据库系统具有重要意义,为实现强一致性、高性能、全球分布式的数据库提供了可行性。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《大数据经典论文解读》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(5)

  • 最新
  • 精选
  • 在路上
    徐老师好,在Spanner论文的最后一页,描述了Paxos Leader-Lease Management,证明了Leader切换后时间戳的单调递增性。Leader选举需要多数Paxos成员的支持,所以一定存在一个Paxos成员同时参与了前后两轮选举,假设这个成员为r0,任何Paxos成员参与Leader选举之后,10秒之内不会再参与选举,Leader租期的结束时间由投支持票的Paxos成员的投票时间决定,选择最小的投票时间加上10秒。如果r0的投票时间是最小时间,那么下一轮Leader选举响应时间在10秒后,Leader切换后时间戳单调递增。如果r0的投票时间不是最小时间,那么下一轮Leader选举响应时间更在10秒后,Leader切换后时间戳单调递增。这个说明过程省略了earliest和latest之分,更详细的可以看看论文。
    2021-11-30
    10
  • 在路上
    徐老师好,论文第4.2.2节提到,如果只读事务只涉及一个paxos group,读操作的时间戳选择Leader的LastTS(),如果涉及多个paxos group,读操作的时间戳选择本地的TT.now().latest(),这个时间可能会超过t_paxos_safe,需要等待safe time的推进。在没有新的事务发生时,如果依靠每8秒钟更新一次的MinNextTS(n)推进safe time,我觉得读操作太慢了。我在Life of Cloud Spanner Reads & Writes中读到多节点的Strong Read,副本不知道自己是不是最新的情况会去请求Leader,我觉得这是更快的方法。
    2021-12-02
    4
  • Eternal
    粗浅理解:所有事务请求都是按照全局绝对时间来顺序执行的,通过在不同事务时间点前后插入误差时间来使得事务之间是按照绝对时间串行执行。然后通过原子钟+GPS来保障绝对时间误差足够小,最坏情况是7毫秒,也就是极限情况2阶段来算,每个事务可能浪费2阶段*14ms=28毫秒,这是最坏的情况,实际可能更小;那这样来的话,全局时间就是一个单点了,如果后续技术进步,全局时间的误差能控制得更小,比如1ms内,那简直就是完美
    2023-03-28归属地:重庆
    1
  • Helios
    一般的数据中心没有原子钟和 GPS 时钟,是不是就不适合使用spanner这类的数据库了呢。或者用了话,导致时间区间会很大
    2021-12-29
    1
  • 霍彦文
    老师我们会有这批论文的解读吗? lightning: HTAP as a service - ACM Digital Library
    2022-01-03
收起评论
显示
设置
留言
5
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部