分布式协议与算法
文章平均质量分 93
分布式协议与算法
_Rye_
左手代码右手诗
一行代码一行诗
展开
-
20 | 基于Raft的分布式KV系统开发实战(二):如何实现代码?
学完上一讲后,相信你已经了解了分布式 KV 系统的架构设计,同时应该也很好奇,架构背后的细节代码是怎么实现的呢?别着急,今天这节,会带你弄明白这个问题。会具体讲解核心功能点的实现细节。比如,如何实现读操作对应的 3 种一致性模型。希望能在课下反复运行程序,多阅读源码,掌握所有的细节实现。话不多说,我们开始今天的学习。在上一讲中,咱们将系统划分为三大功能块(接入协议、KV 操作、分布式集群),那么今天会按顺序具体说一说每块功能的实现,帮助你掌握架构背后的细节代码。首先,先来了解一下,如何实现接入协议。原创 2024-03-05 14:15:27 · 793 阅读 · 0 评论 -
19 | 基于Raft的分布式KV系统开发实战(一):如何设计架构?
学完前面 2 讲之后,相信你已经大致了解了 Raft 算法的代码实现(Hashcorp Raft),也掌握了常用 API 接口的用法,对 Raft 算法的理解也更深刻了。那么,是不是掌握这些,就能得心应手的处理实际场景的问题了呢?在我看来,掌握的还不够,因为 Raft 算法的实现只是工具。而掌握了工具的用法,和能使用工具得心应手地处理实际场景的问题,是两回事。也就是说,我们还需要掌握使用 Raft 算法开发分布式系统的实战能力,然后才能游刃有余的处理实际场景的问题。原创 2024-03-05 11:21:16 · 859 阅读 · 0 评论 -
18 | Hashicorp Raft(二):如何以“集群节点”为中心使用API?
上一讲结束后,相信有的同学已经跃跃欲试,想把 Hashicorp Raft 使用起来了。不过,也有一些同学跟我反馈,说自己看到 Hashicorp Raft 的,阅读完接口文档后,感觉有些不知所措,无从下手,Hashicorp Raft 支持了那么多的函数,自己却不知道如何将这些函数使用起来。这似乎是一个共性的问题,在我看来,之所以出现这个问题,是因为文档里虽然提到了 API 的功能,但并没有提如何在实际场景中使用这些 API,每个 API 都是孤立的点,缺乏一些场景化的线将它们串联起来。原创 2024-03-05 10:18:46 · 858 阅读 · 0 评论 -
17 | Hashicorp Raft(一):如何跨过理论和代码之间的鸿沟?
很多同学在开发系统的时候,都会有这样的感觉:明明自己看了很多资料,掌握了技术背后的原理,可在开发和调试的时候还是很吃力,这是为什么呢?答案很简单,因为理论和实践本来就是两回事,实践不仅需要掌握 API 接口的用法,还需要理解 API 背后的代码实现。所以,如果你在使用 Raft 开发分布式系统的时候,仅仅阅读 Raft 论文或者 Raft 实现的 API 手册,是远远不够的。原创 2024-03-05 08:58:05 · 828 阅读 · 0 评论 -
16 | InfluxDB企业版一致性实现剖析:他山之石,可以攻玉
可以这么理解,时序数据库,就是存储时序数据的数据库,就像 MySQL 是存储关系型数据的数据库。在我看来,时序数据最大的特点是数据量很大,可以不夸张地说是海量。时序数据主要来自监控(监控被称为业务之眼),而且在不影响业务运行的前提下,监控埋点是越多越好,这样才能及时发现问题、复盘故障。那么作为时序数据库,InfluxDB 企业版的架构是什么样子呢?你可能已经了解过,它是由 META 节点和 DATA 节点 2 个逻辑单元组成的,而且这两个节点是 2 个单独的程序。那你也许会问了,为什么不能合成到一个程序呢。原创 2024-03-04 20:33:13 · 831 阅读 · 0 评论 -
TCC如何实现指令执行的原子性?
在04 讲,我们介绍了 TCC,你如果对 TCC 不熟悉,或者忘记了,那么可以回过头复习一下。在这里,我只想补充一点,那就是:你可以对比二阶段提交协议来理解,TCC 包含的预留、确认或撤销这 2 个阶段,比如:Try 是指预留,它和二阶段提交协议中,提交请求阶段的操作类似,具体来说就是,系统会将需要确认的资源预留、锁定,确保确认操作一定能执行成功。Confirm 是指确认,它呢和二阶段提交协议中,提交执行阶段的操作类似,具体是指,系统将最终执行的操作。原创 2024-03-04 18:09:17 · 800 阅读 · 0 评论 -
MySQL XA是如何实现分布式事务的?
提到 XA 规范,就不得不说 DTP 模型( Distributed Transaction Processing),因为 XA 规范约定的是 DTP 模型中 2 个模块(事务管理器和资源管理器)的通讯方式,那 DTP,就是分布式事务处理,就像下图的样子:为了更好的理解 DTP 模型,来解释一下 DTP 各模块的作用。原创 2024-03-04 17:24:33 · 817 阅读 · 0 评论 -
ZAB协议(三):如何处理读写请求?
你应该有这样的体会,如果你想了解一个网络服务,执行的第一个功能肯定是写操作,然后才执行读操作。比如,你要了解 ZooKeeper,那么肯定会在 zkCli.sh 命令行中执行写操作(比如“create /geekbang 123”)写入数据,然后再是读操作(比如“get /geekbang”)查询数据。这样一来,你才会直观地理解 ZooKeeper 是如何使用的了。在我看来,任何网络服务最重要的功能就是处理读写请求,因为我们访问网络服务本质上都是在执行读写操作,ZooKeeper 也不例外。。原创 2024-03-04 16:36:52 · 890 阅读 · 0 评论 -
ZAB协议(二):如何从故障中恢复?
我们上一讲提到了 ZAB 的领导者选举,在我看来,它只是选举了一个适合当领导者的节点,然后把这个节点的状态设置成 LEADING 状态。此时,这个节点还不能作为主节点处理写请求,也不能使用领导职能(比如,它没办法阻止其他“领导者”广播提案)。也就是说,集群还没有从故障中恢复过来,而成员发现和数据同步会解决这个问题。总的来说,成员发现和数据同步不仅让新领导者正式成为领导者,确立了它的领导关系,还解决了各副本的数据冲突,实现了数据副本的一致性。这样一来,集群就能正常处理写请求了。原创 2024-03-04 15:50:01 · 870 阅读 · 0 评论 -
ZAB协议(一):主节点崩溃了,怎么办?
咱们都知道,系统在运行中,不可避免会出现各种各样的问题,比如进程崩溃了、服务器死机了,这些问题会导致很严重的后果,让系统没办法运行。学完了 15 讲后,你应该还记得,在 ZAB 中,写请求是必须在主节点上处理的,而且提案的广播和提交,也是由主节点来完成的。既然主节点那么重要,如果它突然崩溃宕机了,该怎么办呢?答案是选举出新的领导者(也就是新的主节点)。在我看来,领导者选举,关乎着节点故障容错能力和集群可用性,是 ZAB 协议非常核心的设计之一。原创 2024-03-04 11:00:46 · 788 阅读 · 0 评论 -
15 | ZAB协议:如何实现操作的顺序性?
很多同学应该使用过 ZooKeeper,它是一个开源的分布式协调服务,比如你可以用它进行配置管理、名字服务等等。在 ZooKeeper 中,数据是以节点的形式存储的。我们分别创建了配置"/geekbang"和"/geekbang/time",对应的值分别为 123 和 456。那么在这里我提个问题:你觉得在 ZooKeeper 中,能用兰伯特的 Multi-Paxos 实现各节点数据的共识和一致吗?当然不行。原创 2024-03-04 11:00:04 · 904 阅读 · 0 评论 -
PBFT算法:如何替换作恶的领导者?
上一讲,我们了解到,PBFT 可以防止备份节点作恶,因为这个算法是主节点和备份节点组成的,那你想象一下,如果主节点作恶(比如主节点接收到了客户端的请求,但就是默不作声,不执行三阶段协议),这时无论正常节点数有多少,备份节点肯定没办法达成共识,整个集群都没办法正常运行。这么大的问题,你该怎么解决呢?答案是视图变更(View Change),也就是通过领导者选举,选举出新的主节点,并替换掉作恶的主节点。(其中的“视图”你可以理解为领导者任期的,不同的视图值对应不同的主节点。原创 2024-03-03 14:51:35 · 840 阅读 · 0 评论 -
13 | PBFT算法:有人作恶,如何达成共识?
学完了01 讲的拜占庭将军问题之后,有同学在留言中表达了自己的思考和困惑:口信消息型拜占庭问题之解在实际项目中是如何落地的呢?能在学习的同时思考落地实战。不过事实上,它很难在实际项目落地,因为口信消息型拜占庭问题之解是一个非常理论化的算法,没有和实际场景结合,也没有考虑如何在实际场景中落地和实现。比如,它实现的是在拜占庭错误场景下,忠将们如何在叛徒干扰时,就一致行动达成共识。但是它并不关心结果是什么,这会出现一种情况:现在适合进攻,但将军们达成的最终共识却是撤退。很显然,这不是我们想要的结果。原创 2024-03-03 13:48:50 · 805 阅读 · 0 评论 -
12 | Quorum NWR算法:想要灵活地自定义一致性,没问题!
不知道你在工作中有没有遇到这样的事儿:你开发实现了一套 AP 型的分布式系统(在04 讲提到了 AP 型系统的特点,你可以回顾一下),实现了最终一致性。业务也接入了,运行正常,一起看起来都那么美好。可是,突然有同事说,我们要拉这几个业务的数据做实时分析,希望数据写入成功后,就能立即读取到新数据,也就是要实现强一致性(,不是指线性一致性),数据更改后,要保证用户能立即查询到。这时你该怎么办呢?首先你要明确最终一致性和强一致性有什么区别。强一致性能保证写操作完成后,任何后续访问都能读到更新后的值;原创 2024-03-02 17:22:51 · 853 阅读 · 0 评论 -
11 | Gossip协议:流言蜚语,原来也可以实现一致性
有一部分同学的业务在可用性上比较敏感,比如监控主机和业务运行的告警系统。这个时候,相信你希望自己的系统能在极端情况下(比如集群中只有一个节点在运行)也能运行。回忆了二阶段提交协议和 Raft 算法之后,你发现它们都需要全部节点或者大多数节点正常运行,才能稳定运行,那么它们就不适合了。而根据 Base 理论,你需要实现最终一致性,怎么样才能实现最终一致性呢?在我看来,可以通过 Gossip 协议实现这个目标。原创 2024-03-02 15:56:43 · 894 阅读 · 0 评论 -
10 | 一致哈希算法:如何分群,突破集群的“领导者”限制?
学完前面几讲后,有些同学可能有这样的疑问:如果我们通过 Raft 算法实现了 KV 存储,虽然领导者模型简化了算法实现和共识协商,但写请求只能限制在领导者节点上处理,导致了集群的接入性能约等于单机,那么随着业务发展,集群的性能可能就扛不住了,会造成系统过载和服务不可用,这时该怎么办呢?其实这是一个非常常见的问题。在我看来,这时我们就要通过分集群,突破单集群的性能限制了。说到这儿,有同学可能会说了,分集群还不简单吗?原创 2024-03-02 15:00:08 · 799 阅读 · 0 评论 -
09 | Raft算法(三):如何解决成员变更的问题?
在日常工作中,可能会遇到服务器故障的情况,这时就需要替换集群中的服务器。如果遇到需要改变数据副本数的情况,则需要增加或移除集群中的服务器。总的来说,在日常工作中,集群中的服务器数量是会发生变化的。讲到这儿,也许你会问:“Raft 是共识算法,对集群成员进行变更时(比如增加 2 台服务器),会不会因为集群分裂,出现 2 个领导者呢?原创 2024-03-01 18:27:51 · 773 阅读 · 0 评论 -
08 | Raft算法(二):如何复制日志?
通过上一讲的学习,你应该知道 Raft 除了能实现一系列值的共识之外,还能实现各节点日志的一致,不过你也许会有这样的疑惑:“什么是日志呢?它和我的业务数据有什么关系呢?想象一下,一个木筏(Raft)是由多根整齐一致的原木(Log)组成的,而原木又是由木质材料组成,所以你可以认为日志是由多条日志项(Log entry)组成的,如果把日志比喻成原木,那么日志项就是木质材料。原创 2024-03-01 17:58:12 · 925 阅读 · 0 评论 -
07 | Raft算法(一):如何选举领导者?
我们知道,议会选举中的领导者是有任期的,领导者任命到期后,要重新开会再次选举。Raft 算法中的领导者也是有任期的,每个任期由单调递增的数字(任期编号)标识,比如节点 A 的任期编号是 1。任期编号是随着选举的举行而变化的,这是在说下面几点。1. 跟随者在等待领导者心跳信息超时后,推举自己为候选人时,会增加自己的任期号,比如节点 A 的当前任期编号为 0,那么在推举自己为候选人时,会将自己的任期编号增加为 1。原创 2024-03-01 17:13:23 · 1040 阅读 · 0 评论 -
06 | Paxos算法(二):Multi-Paxos不是一个算法,而是统称
经过上节课的学习,应该知道,Basic Paxos 只能就单个值(Value)达成共识,一旦遇到为一系列的值实现共识的时候,它就不管用了。虽然兰伯特提到可以通过多次执行 Basic Paxos 实例(比如每接收到一个值时,就执行一次 Basic Paxos 算法)实现一系列值的共识。但是,很多同学读完论文后,应该还是两眼摸黑,虽然每个英文单词都能读懂,但还是不理解兰伯特提到的 Multi-Paxos,为什么 Multi-Paxos 这么难理解呢?原创 2024-03-01 16:06:12 · 858 阅读 · 0 评论 -
05 | Paxos算法(一):如何在多个节点间确定某变量的值?
提到分布式算法,就不得不提 Paxos 算法,在过去几十年里,它基本上是分布式共识的代名词,因为当前最常用的一批共识算法都是基于它改进的。比如,Fast Paxos 算法、Cheap Paxos 算法、Raft 算法等等。而很多同学都会在准确和系统理解 Paxos 算法上踩坑,比如,只知道它可以用来达成共识,但不知道它是如何达成共识的。这其实侧面说明了 Paxos 算法有一定的难度,可分布式算法本身就很复杂,Paxos 算法自然也不会例外,当然了,除了这一点,还跟兰伯特有关。原创 2024-03-01 15:15:04 · 755 阅读 · 0 评论 -
04 | BASE理论:CAP的碱,追求可用性
(比如 All、Quorum、One、Any,更多信息你可以看一下12 讲), 让用户可以自主选择相应的一致性级别,比如可以通过设置一致性级别为 All,来实现强一致性。现在,想必你了解了 BASE 理论的核心内容了吧?不过这是理论层面上的,那么在实践中,该如何使用 BASE 理论的呢?原创 2024-03-01 14:16:25 · 867 阅读 · 0 评论 -
03 | ACID理论:CAP的酸,追求一致性
提到 ACID,我想你并不陌生,很多同学也会觉得它容易理解,在单机上实现 ACID 也不难,比如可以通过锁、时间序列等机制保障操作的顺序执行,让系统实现 ACID 特性。但是,一说要实现分布式系统的 ACID 特性,很多同学就犯难了。那么问题来了,为什么分布式系统的 ACID 特性在实现上,比较难掌握呢?在我看来,ACID 理论是对事务特性的抽象和总结,方便我们实现事务。你可以理解成:如果实现了操作的 ACID 特性,那么就实现了事务。而大多数人觉得比较难,是因为分布式系统涉及多个节点间的操作。原创 2024-03-01 10:45:11 · 853 阅读 · 0 评论 -
02 | CAP理论:分布式系统的PH试纸,用它来测酸碱度
很多同学可能都有这样的感觉,每次要开发分布式系统的时候,就会遇到一个非常棘手的问题,那就是如何根据业务特点,为系统设计合适的分区容错一致性模型,以实现集群能力。这个问题棘手在当发生分区错误时,应该如何保障系统稳定运行,不影响业务。这和之前经历的一件事比较像,当时,负责自研 InfluxDB 系统的项目,接手这个项目后,。因为 InfluxDB 有 META 和 DATA 两个节点,它们的功能和数据特点不同,所以我还需要考虑这两个逻辑单元的特点,然后分别设计分区容错一致性模型。原创 2024-03-01 09:17:47 · 850 阅读 · 0 评论 -
拜占庭将军问题:如何基于签名消息实现作战计划的一致性?
签名消息指的就是带有数字签名的消息,你可以这么理解“数字签名”:类似在纸质合同上进行签名来确认合同内容和证明身份。在这里我想说的是,数字签名既可以证实内容的完整性,又可以确认内容的来源,实现不可抵赖性(Non-Repudiation)。既然签名消息优点那么多,那么如何实现签名消息呢?原创 2024-02-29 18:22:47 · 862 阅读 · 0 评论 -
01 | 拜占庭将军问题:有叛徒的情况下,如何才能达成共识?
在日常工作中,常听到有人吐槽“没看懂拜占庭将军问题”“中文的文章看不懂,英文论文更看不下去”。想必你也跟他们一样,有类似的感受。在我看来,拜占庭将军问题(The Byzantine Generals Problem),它其实是借拜占庭将军的故事展现了分布式共识问题,还探讨和论证了解决的办法。而大多数人觉得它难理解,除了因为分布式共识问题比较复杂之外,还与莱斯利·兰伯特(Leslie Lamport)的讲述方式有关,他在一些细节上(比如,口信消息型拜占庭问题之解的算法过程上)没有说清楚。原创 2024-02-29 18:21:35 · 958 阅读 · 0 评论 -
学习路径 | 分布式协议与算法你应该这么学
在正式开始学习这门课之前,想先和你聊一聊怎么学,因为掌握了学习路径、建立了全局观之后,才能达到事半功倍的效果。我们都知道,分布式协议和算法(为了不啰嗦,咱们下文都简称分布式算法)很实用、也很火,很多后端工程师在面试的时候,都会被问及分布式、高可用、一致性这些专业名词背后的算法原理和实现方式。但是分布式算法也是比较新的,快速发展的。原创 2024-02-29 18:20:29 · 916 阅读 · 0 评论 -
开篇词 | 想成为分布式高手?那就先把协议和算法烂熟于心吧
课程的每一讲都是干货,也会第一时间和你交流答疑。只要你紧跟脚步,不懂就问,课后多加思考和练习,相信你一定会学有所成。与此同时,希望所有对技术有追求的工程师,都能在学完课程之后,顺利攻下这一关。再具体一点说,就是能够在工作中根据场景特点,灵活地设计架构和使用分布式算法开发出适合该场景的分布式系统,并且对架构设计的理解更上一层。姑且把这段话当成我们的教学目标吧。原创 2024-02-29 18:19:43 · 873 阅读 · 0 评论