分布式协议与算法实战
韩健
腾讯资深工程师
23193 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 31 讲
分布式协议与算法实战
15
15
1.0x
00:00/00:00
登录|注册

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

设计存储系统
直面问题解决
谨慎引入中间件
成本优势
性能优势
根据场景设计系统
深入研究场景特点
技术实现
复杂性
实现强一致性
指导妥协折中
辅助分析问题
实现水平扩展
面向业务
实现最终一致性
存放具体时序数据
使用Raft算法实现一致性
一致性敏感
存放系统关键元信息
主要来自监控
数据量大
课堂思考
建议
InfluxDB企业版优势
技术与场景需求
AP型分布式系统
Raft算法
CAP理论
Quorum NWR
反熵
Hinted-handoff
自定义副本数
实现最终一致性
使用Raft算法
实现CAP中的CP模型
DATA节点
META节点
时序数据特点
存储时序数据的数据库
总结
DATA节点一致性实现
META节点一致性实现
InfluxDB企业版架构
时序数据库
InfluxDB企业版一致性实现剖析

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

你好,我是韩健。
学习了前面 15 讲的内容后,我们了解了很多常用的理论和算法(比如 CAP 定理、Raft 算法等)。是不是理解了这些内容,就能够游刃有余地处理实际系统的问题了呢?
在我看来,还远远不够,因为理论和实践的中间是存在鸿沟的,比如,你可能有这样的感受,提到编程语言的语法或者分布式算法的论文,你说起来头头是道,但遇到实际系统时,还是无法写程序,开发分布式系统。
而我常说,实战是学习的最终目的。为了帮你更好地掌握前面的理论和算法,接下来,我用 5 讲的时间,分别以 InfluxDB 企业版一致性实现、Hashicorp Raft、KV 系统开发实战为例,带你了解如何在实战中使用技术,掌握分布式的实战能力。
今天这一讲,我就以 InfluxDB 企业版为例,带你看一看系统是如何实现一致性的。有的同学可能会问了:为什么是 InfluxDB 企业版呢?因为它是排名第一的时序数据库,相比其他分布式系统(比如 KV 存储),时序数据库更加复杂,因为我们要分别设计 2 个完全不一样的一致性模型。当你理解了这样一个复杂的系统实现后,就能更加得心应手地处理简单系统的问题了。
那么为了帮你达到这个目的。我会先介绍一下时序数据库的背景知识,因为技术是用来解决实际场景的问题的,正如我之前常说的“要根据场景特点,权衡折中来设计系统”。所以当你了解了这些背景知识后,就能更好的理解为什么要这么设计了。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

InfluxDB企业版一致性实现剖析:他山之石,可以攻玉 本文深入剖析了InfluxDB企业版的一致性实现,以时序数据库为例,介绍了其背景知识和架构特点。文章首先解释了时序数据库的概念和特点,强调了时序数据的海量性和监控的重要性。随后,对InfluxDB企业版的架构进行了详细介绍,包括META节点和DATA节点的特点和功能。针对META节点的一致性实现,文章指出其需要强一致性,采用了Raft算法来实现。而对于DATA节点的一致性实现,则介绍了自定义副本数和Hinted-handoff的实现方式,以及如何处理数据的最终一致性。 通过本文的阐述,读者可以深入了解时序数据库的特点和InfluxDB企业版的架构设计,以及其一致性实现的关键技术。同时,文章通过实际案例和技术细节,帮助读者理解了分布式系统中一致性实现的复杂性和重要性,为读者提供了宝贵的技术参考和实战经验。 文章还提到了时序数据的一致性问题,强调了实现最终一致性的重要性,并介绍了反熵的实现方式。此外,针对需要强一致性的场景,文章提出了Quorum NWR的实现方法。最后,文章强调了技术的用途是解决场景需求,而不是追求完美的技术,需要根据场景特点设计适合的分布式系统。 总的来说,本文通过深入剖析InfluxDB企业版的一致性实现,帮助读者全面了解了时序数据库的特点、InfluxDB企业版的架构设计以及一致性实现的关键技术,为读者提供了宝贵的技术参考和实战经验。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《分布式协议与算法实战》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(27)

  • 最新
  • 精选
  • Geek_3894f9
    课后思考题,答案是QNWR,Wn,R1。wn是因为对写入的时间要求不高,r1是因为可以读取任意一节点,读性能好。

    作者回复: 加一颗星:)。

    2020-03-18
    2
    21
  • Michael Tesla
    我觉得思考题的场景特点是:读多写少,读的性能要求高,数据要保证强一致性。 如果使用 Raft 算法 保证强一致性,那么读写操作都应该在领导者节点上进行。这样的话,读的性能相当于单机,不是很理想。 应该采用 Quorum NWR 技术,设置 W = N,R = 1。每次都要写入全部节点,写操作的性能会比较差。但是,因为写操作比较少,所以这个缺点可以忍受。而读操作只需要读任意一个节点就能返回最新的数据,性能非常高。

    作者回复: 加一颗星:),这是个解决办法,与这个办法“类似”的二阶段提交协议,也是个办法。

    2020-04-06
    3
    15
  • 阿卡牛
    这个实战太企业了,新手完全无从下门,有没有些入门的课程

    作者回复: 主要感觉哪方面学习起来比较困难呢?能具体说说吗? 看到了反馈,我补充下,其实,技术是一点一点学习的,关键要找到一个点,在深度上进行突破,然后再在广度上扩展开来了,比如,可以先聚焦在实战篇的分布式KV系统,将代码玩起了,吃透分布式系统的架构和开发方法,多玩代码,少想理论。代码玩出了感觉后,聚焦和吃透Raft算法。最后,再聚焦和吃透其他理论。

    2020-03-25
    5
    8
  • Kvicii.Y
    1.META节点是Raft算法实现,那是不是存在这如果节点过多消息同步慢的问题呢?存在的话如何解决呢?(只能减少Raft节点?) 2.思考题使用quorum nwr可以达到最终一致性,这里说的强一致是最终一致的意思吗?

    作者回复: 1. 不推荐节点数过多,一般推荐3个节点,也就是能容错一个节点故障,就可以了。 2. 通过反熵,可以实现最终一致性。通过quorum nwr,可以让业务按需选择一致性级别,比如说,可以是强一致性,也可以是最终一致性。

    2020-03-30
    4
  • Following U
    hello,讲师好,influxdb 企业版你这边的分布式版本的github 地址吗?

    作者回复: https://github.com/freetsdb/freetsdb,现在是Alpha版,还在准备中。项目中一些有意思的技术点和设计,我也会在第一时间和大家分享同步:)。

    2020-07-12
    3
  • 每天晒白牙
    感觉自己对这些知识理解的还是不够,更不能进行实战应用,还得好好学学。 对于思考题,首先要求强一致性,读多写少,那是不是可以像 META 节点一样,采用 Raft 算法实现强一致性。但这样对性能可能就有影响了,不过这个 KV 系统是读多写少,应该也可以 然后就是从性能考虑,可以在 AP 系统中实现强一致性。根据文中提示,可以采用 Quorun NWR 实现

    作者回复: 加一颗星:),如果直接使用Raft集群,读性能满足不了,可以增加几台内存缓存服务器,来提升读性能。

    2020-03-18
    2
    3
  • 欧阳
    除了quorum NWR。kfk的分区是不是也是一种思路

    作者回复: 加一颗星:),目标不同,quorum NWR实现的是自定义一致性级别,kfk分区是为了实现水平扩展、负载均衡,提升读写性能。

    2020-03-30
    2
    2
  • 姜川
    老师,raft要实现强一致是不是就需要收到所有节点的ACK才可以,半数以上那种只能是最终一致性吧,因为会有短暂的不一致发生

    作者回复: 加一颗星:),不需要,在领导者节点上执行读操作,可以实现强一致性:)

    2020-03-26
    2
  • 夜空中最亮的星
    喜欢案例,让案例来的更猛烈些吧

    作者回复: 好的,也期待你的更多反馈:)。

    2020-03-18
    2
  • Heaven
    读多写少啊,只需要保证在每次都必须要写入到每一个节点上就可以了,然后读的时候直接去读,自然是最新的

    作者回复: 加一颗星:)

    2020-08-21
    1
收起评论
显示
设置
留言
27
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部