分布式协议与算法实战
韩健
腾讯资深工程师
立即订阅
4634 人已学习
课程目录
已更新 19 讲 / 共 22 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 想成为分布式高手?那就先把协议和算法烂熟于心吧
免费
理论篇 (4讲)
01 | 拜占庭将军问题:有叛徒的情况下,如何才能达成共识?
02 | CAP理论:分布式系统的PH试纸,用它来测酸碱度
03 | ACID理论:CAP的酸,追求一致性
04 | BASE理论:CAP的碱,追求可用性
协议和算法篇 (11讲)
05 | Paxos算法(一):如何在多个节点间确定某变量的值?
06 | Paxos算法(二):Multi-Paxos不是一个算法,而是统称
07 | Raft算法(一):如何选举领导者?
08 | Raft算法(二):如何复制日志?
09 | Raft算法(三):如何解决成员变更的问题?
10 | 一致哈希算法:如何分群,突破集群的“领导者”限制?
11 | Gossip协议:流言蜚语,原来也可以实现一致性
12 | Quorum NWR算法:想要灵活地自定义一致性,没问题!
13 | PBFT算法:有人作恶,如何达成共识?
14 | PoW算法:有办法黑比特币吗?
15 | ZAB协议:如何实现操作的顺序性?
实战篇 (3讲)
16 | InfluxDB企业版一致性实现剖析:他山之石,可以攻玉
17 | Hashicorp Raft(一):如何跨过理论和代码之间的鸿沟?
18 | Hashicorp Raft(二):如何以“集群节点”为中心使用API?
分布式协议与算法实战
登录|注册

16 | InfluxDB企业版一致性实现剖析:他山之石,可以攻玉

韩健 2020-03-18
你好,我是韩健。
学习了前面 15 讲的内容后,我们了解了很多常用的理论和算法(比如 CAP 定理、Raft 算法等)。是不是理解了这些内容,就能够游刃有余地处理实际系统的问题了呢?
在我看来,还远远不够,因为理论和实践的中间是存在鸿沟的,比如,你可能有这样的感受,提到编程语言的语法或者分布式算法的论文,你说起来头头是道,但遇到实际系统时,还是无法写程序,开发分布式系统。
而我常说,实战是学习的最终目的。为了帮你更好地掌握前面的理论和算法,接下来,我用 5 讲的时间,分别以 InfluxDB 企业版一致性实现、Hashicorp Raft、KV 系统开发实战为例,带你了解如何在实战中使用技术,掌握分布式的实战能力。
今天这一讲,我就以 InfluxDB 企业版为例,带你看一看系统是如何实现一致性的。有的同学可能会问了:为什么是 InfluxDB 企业版呢?因为它是排名第一的时序数据库,相比其他分布式系统(比如 KV 存储),时序数据库更加复杂,因为我们要分别设计 2 个完全不一样的一致性模型。当你理解了这样一个复杂的系统实现后,就能更加得心应手地处理简单系统的问题了。
那么为了帮你达到这个目的。我会先介绍一下时序数据库的背景知识,因为技术是用来解决实际场景的问题的,正如我之前常说的“要根据场景特点,权衡折中来设计系统”。所以当你了解了这些背景知识后,就能更好的理解为什么要这么设计了。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《分布式协议与算法实战》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(10)

  • 每天晒白牙
    感觉自己对这些知识理解的还是不够,更不能进行实战应用,还得好好学学。

    对于思考题,首先要求强一致性,读多写少,那是不是可以像 META 节点一样,采用 Raft 算法实现强一致性。但这样对性能可能就有影响了,不过这个 KV 系统是读多写少,应该也可以

    然后就是从性能考虑,可以在 AP 系统中实现强一致性。根据文中提示,可以采用 Quorun NWR 实现
    2020-03-18
    2
  • Geek_3894f9
    课后思考题,答案是QNWR,Wn,R1。wn是因为对写入的时间要求不高,r1是因为可以读取任意一节点,读性能好。
    2020-03-18
    1
  • Fs
    AP型的实现大框架是类似的,influxDB的介绍和Cassandra的实现非常相似。那么支持时序这一特点,influxDB有什么不一样的设计呢
    2020-03-23
  • Scream!
    多来点实战案例
    2020-03-22
  • 唔多志
    懵懵懂懂,似懂非懂,还是要多学习。
    2020-03-19
  • 羽翼1982
    在AP的系统中,使用Quorum NWR理论
    如果写少读多,假设有3个副本,可以将策略调整为3个副本写成功才返回,读则可以只读取一个副本的内容;如果网络不稳定,3副本写成功到时失败率高,99线的延迟大,可以退一步使用2写2读的策略;不过很少在实际系统上看到类似3副本,允许1副本写不成功时缓存本地等待Hinted-handoff后续同步这样的策略,InfluxDB中不太清楚,至少Cassandra里面没有

    PS: 我们公司今年刚刚把时序数据库从InfluxDB转到VictoriaMetrics上,据说性能更高,与Promeheus的适配也更好,不知道老师对VM是否有研究可以简单分享下
    2020-03-18
  • hello
    给老师大大的赞,对实战部分很是期待,我现在就希望快点更新!
    2020-03-18
  • 小晏子
    课后思考:这个里面有几个点是设计这个系统的关键,读请求(百万级)远大于写请求(千级),要求读的强一致性。
    因为写请求很低,可以仿照influxDB的设计,分成meta节点和data节点,meta节点使用cp模型,使用raft算法,data节点使用ap模型,使用quorum NWR和反墒算法保证强一致性,因为写少,所以只要少量meta节点即可满足要求,比如三个,对于大量读请求,data节点可以保障一致性和百万级请求。
    2020-03-18
  • pedro
    前面的十几讲都在为这一讲做铺垫,快更新,看看后面的实战部分😃
    2020-03-18
  • 夜空中最亮的星(华仔)
    喜欢案例,让案例来的更猛烈些吧
    2020-03-18
收起评论
10
返回
顶部