有人在氛围里使用分布式系统吗？

2 年 ago
韵, 科
3 minutes

？？？：有人使用氛围分散系统吗!？
？？？：没有啊！！！！！

木曹:根本没那回事，是有的啊!!就在这里呢!! (完)

首先

我觉得很多人虽然会使用一些类似分散系统的东西，但是对于具体的细节并不了解。我也是这样。

即使不了解分散系统的原理也没有问题，但当系统发生故障时，有时会感到毫无能力，因为根本不了解这个系统的机制。有时会遇到非常严重的错误。

我計劃整理一些關於分散系統的鏈接，這對於對分散系統感興趣的新手來說是一種很好的了解方式，並且寫下一些感想。

开始考虑分散系统的契机

对不起我不明白你说的是什么。

实施之前的事件

在我们目前正在开发的产品中，有以下处理过程：
（过去的前辈们遗留下来的东西，造成了不太理想的架构。）

在前端UI中，触发了hoge项目的变更事件
⇒ 使用REST API（更新hoge项目的状态）
⇒ 获取处理结果
⇒ 使用REST API（更新hoge项目的历史记录）
⇒ 获取处理结果
⇒ 在前端UI中通知结果

顺便说一下，A REST API和B REST API都以以下代码的方式更新了DynamoDB中相同表中的相同hoge项目。

# DynamoDBからアイテムを取得
unique_id = "hoge"
record = table.get_item(
    Key={ "unique_id": unique_id }
)

# いろいろと処理を実行する
...

# DynamoDBのアイテムを更新
response = table.update({
    "Key": {"unique_id": unique_id},
    "UpdateExpression": update_expr,
    "ExpressionAttributeValues": update_values,
    "ReturnValues": "ALL_NEW",
})

而且，发生了事件…

发生DynamoDB泄漏事件

顾客支持代表：顾客报告说“我在UI上进行了更改操作，但状态没有变化”，你知道是什么问题吗？
穆苏：我稍微调查一下实现的情况。
（进行日志调查中）
穆苏：嗯，A REST API和B REST API的DynamoDB更新处理都返回了200，说明更新处理本身应该是成功的吧…
（在AWS DynamoDB控制台上确认中）
穆苏：喂喂，A REST API的DynamoDB更新处理在数据库表中有反映，但B REST API的DynamoDB更新处理却没有反映。DynamoDB真是太虚假了…

所以，我先去咨询了一下AWS的支持。

来自AWS支持的回复

我收到了AWS支持的回复。简单来说，他们告诉我以下内容：

AWS Support has responded to me, and they provided the following summary:

AWS支持回复(摘要)DynamoDB默认在写入到多个可用区后会返回“写入成功”的响应。
所有可用区的写入结果将在一段时间后（在DynamoDB中为1秒内）得到写入（结果一致性），这意味着数据在逻辑上会被写入。
由于在读取时无法确定从哪个可用区读取数据，如果从未反映前一次更改的可用区读取数据，可能会读取到旧数据。
如果想在所有可用区的写入完成后再进行读取（进行强一致性读取），请启用ConsistentRead参数。

来源：https://docs.aws.amazon.com/zh_cn/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html

换句话说，如果要寻求强一致性而不是默认的结果一致性，可以通过以下方式修改代码来实现。

# DynamoDBからアイテムを取得(強力な整合性)
record = table.get_item(
    Key={ "unique_id": unique_id },
    ConsistentRead=True
)

不过，由于在A REST API和B REST API中瞬间两次修改相同的表项这样的设计本身就不好，所以我们决定将修改操作统一集中在A REST API中来解决问题。

我在这件事情上意识到的事情

    • NoSQLをRDBみたいな強力な整合性と思って、テーブルを更新しまくるといずれバグ死する

 

    • そもそもの仕組みを知ってないと、変な実装をする可能性が高くなっていずれバグ死する

 

    DynamoDBは分散システムだし、時代的にも分散システムがアーキテクチャの基本となっているのでちゃんと勉強したい。エアプ卒業したい

希望大家都能小心注意。真的。

就这样，在这篇文章中，我想通过引用一些好的网站链接，以及尽情地发表我的感想，来学习分布式系统。如果参考资料过时或不是最新信息，或者有很大的解释错误，请留下评论告诉我…

由于依然不擅长筛选信息，所以这篇文字充斥着许多内容。希望您可以根据目录选择您感兴趣的内容并阅读。

分散系统是什么？

分散系统的含义是什么？

    分散システムとは？

分散系统是指各种组件分布在网络上多台计算机（或其他计算设备）上的计算环境。通过在分散设备上共同协作和调度，能够比在单一设备上更高效地完成任务。

这个系统是由多台计算机协同工作的，我觉得它更像是社会科学（政治/经济/管理学）而不是计算机科学，因为在学习分散系统时会出现诸如”选举领导者”和”分布式一致性”之类的词汇。

以人的方式理解并融入其中可能会很有趣。

    詳説 データベース ―ストレージエンジンと分散データシステムの仕組み(本)

如果您想更加系统地理解分散系统，那么阅读本书的第二部分：关于分散系统的部分可能是一个很好的选择。

由于整体内容较为复杂，且有很多解释性的文字，因此如果是想通过代码理解的人或者是想通过图表理解的人，可以在网上找到一些易懂的资料，辅助学习这本书可能是一个不错的选择。
（顺便一提，我自己还没有完全读完，对不起我很不勤奋。）

    データ指向アプリケーションデザイン(本)

这本书也被称为是一本相当不错的好书。虽然只是在书店里翻了一下，但看起来非常有系统地整理好了。(因为书太厚了，所以没有买。)

我认为这本书对于想要深入了解分散系统的人来说是一本好书。

(NoSQL/NewSQL) 的分散系统实例

    【第14回】NoSQL(1)-基礎-CAP定理を元にしたデータベースの分類とデータ特性

近来，有一些数据库服务器组成了集群，采用了NoSQL分布式系统，这种做法很流行。

据以下CAP定理对所有数据库进行分类时，原则上重视两个特性会导致另一个特性丧失。俗称没有所谓的银弹。

CAP theorem and database classificationCAP theorem:
Consistency: Reading data on any node will always return the result of the most recent write for that data, or return an error.
Availability: Even if there are failures in the nodes that make up the system, reading and writing are always possible.
Partition tolerance: Even if communication between nodes in the system is temporarily interrupted, functionality is maintained.

Databases are classified based on which two they adopt.

CA-type databases: RDB
CP-type databases: Apache HBase, MongoDB, Redis
AP-type databases: Amazon DynamoDB, Apache Cassandra

嘘松事件中的Amazon DynamoDB是一种AP类型的数据库，因此放弃了一致性（Consistency）(虽然有强一致性选项)。

不过，我觉得这个分类本身有点不太合适。

如果网络断裂了，整体的一致性不就无法保持了吗？
或者在主/从结构中，如果主服务器挂了，可用性不就会稍微受到损害了吗？
不同类型的故障可能会破坏我们的前提，这些杂念开始浮现。

如果感到有些沮丧和困惑，我在这篇文章里找到了答案。

 

根据报道，当发生数据库服务器之间的网络分断时，
1. 为了牺牲可用性而中断处理。
2. 为了牺牲一致性而继续进行处理。

据现在的看法来看，有时候可能需要在两个选项中做出选择，这完全取决于时间和情况，并不简单地只能从三个选项中选择两个。

    2020年現在のNewSQLについて

我的理解仅限于NoSQL，但似乎还有一种叫做NewSQL的东西。
NewSQL是一种新形态的SQL数据库，具有可扩展性和分布式架构等过去的关系型数据库所没有的特性，所以我觉得我需要跟上最新的动态。

分散系统的问题 de

分散系统的错误

    分散コンピューティングの落とし穴

据说从英文书籍《分布式计算的谬误》进口到日本后，日语中将其翻译为「分散コンピューティングの誤謬（ごびゅう）」或「分散コンピューティングの落とし穴」。这些谬误包括以下八个方面。

分散计算的误区网络是可靠的。
延迟是零。
带宽是无限的。
网络是安全的。
网络配置不会变化，始终保持一致。
仅有一个管理员。
传输成本是零。
网络是均匀的。

由於分散系统是由多台计算机协同工作形成的集群，所以在集群中可能有老旧服务器和性能强大的年轻服务器等。因此，我认为延迟等因素可能会有所不同。

    Navigating the 8 fallacies of distributed computing

⇒中文写作很困难，但其中讲述了在构建分布式系统时如何避免分布式计算的陷阱。

通过构建冗余网络结构，提高网络的容错性，并根据负载自动进行扩展等功能。我想，如果按照AWS等云服务提供商推荐的架构进行构建，这些问题应该可以相对地避免。

拜占庭将军问题

    ビザンチン将軍問題

拜占庭将军问题是指在一组相互通信的对象中，如果存在通信或者个别对象可能通过故障或者故意传递错误信息的情况下，能否形成整体上正确的共识的问题。

东罗马帝国（拜占庭帝国、拜占庭帝国）的将军们各自率领着军团围困着一个城市。将军们希望对城市进攻计划达成一致。最简单的形式是，将军们只需决定进攻还是撤退。

一些将军可能会表示希望进攻，而其他人可能会希望撤退。重要的一点是，这些将军们必须达成一个共识。换句话说，仅仅由一部分将军发起进攻显然会导致失败，因此他们必须一致决定是进攻还是撤退。此外，这些将军们还将各自的军团部署在不同的地方，通过彼此派遣信使来达成共识。

使问题复杂化的是，一些将军们是叛逆者，有时会投票支持不合适的战略，从而造成混乱。

⇒這是一個將地理上相距遙遠的伺服器人格化並進行比喻的例子，談論了達成共識的困難。

在战斗之前，请事先达成共识。
在领导的指示下，确定进攻还是撤退。
为什么是东罗马帝国呢？

或许会有各种吐槽的地方，但这种分散系统的主题确实存在，就这样记录下来吧。

大脑分裂问题

    スプリットブレインシンドローム

分割脳症候群（split-brain syndrome）またはネットワークパーティション問題は、複数のコンピュータ（ノード）を相互接続して1台のサーバのように動作させるシステム（密結合クラスター）において、ハードウェアやインターコネクトの障害によりシステムが分割され、1つのサービス（仮想IPを含む）がクラスタ内の複数のノード群で同時に起動してしまい、サービス供給が停止する状況を指します。

⇒如果按照字面意思理解的话，就是指右脑和左脑分离，右脑和左脑之间彼此需要沟通来控制这个身体，但我们却处在”我们应该怎么办？谁来指挥呢？”这样的状态。

当出现这个分脑问题时，就会出现“我是主人！！”之类的感觉，主人会大量冒出，导致多个主人同时写入数据库，引发严重的竞争状态，情况变得非常糟糕。

    クラスタに3ノード必要な理由

当发生网络分区时，例如在一个由3台服务器构成的集群中，如果分区形成了1对2，少数派将放弃成为主节点的机会，这样就可以避免出现脑裂问题。

为了确保多数决的有效性，最好将集群服务器数量设定为奇数。这让我想起了政治学，挺有趣的，像是服务器议会呢。

其他分散系统的挑战

    本当は恐ろしい分散システムの話

我认为这是一张必读的幻灯片，有助于了解分散系统。它的结构很巧妙，幽默感也很高。这充分展现了黑客的恶作剧智慧，我很喜欢这种题材。

下面写着我记忆犹新的幻灯片编号和感想。

幻灯片编号和感想
第10页到第17页，讲述了关于Redis声称能够抵御网络分断的观点以及经Jepsen测试验证后被否定的争论，非常有趣。
第49页介绍了某些类型的故障下，甚至无法保持ACID性质的数据库，这让人感到惊讶。我们得及时更新从教科书中学到的RDBMS=ACID的知识。
第58页揭示了Netflix为了确认其系统能够应对异常情况，会随机关闭系统的进程、CPU和虚拟机，并验证其是否正常运行（混沌工程）。我认为这是因为有大量优秀的工程师，才能够完成这样的功绩。
    分散処理システムの検証をサービスとして提供するJepsenに注目

这篇文章中出现的手绘资料视频，让我觉得“好新颖啊”，不过先不说这个。我真切地感受到了明确化正常性，并且测试其可行性的重要性。

我还没有读完以下的Jepsen Test分析结果，因为它很庞大，但是我觉得需要深入调查一下，我们使用的数据库是否符合商业分布式系统的要求。

 

    分散システムの課題(Amazon Builders’ Library)

⇒「分布式系统的挑战」是AWS的一篇文章，它是Amazon Builders’ Library中的一部分。该文章基于AWS的分布式系统构建经验，内容非常值得学习。

由于分散系统中服务器之间需要频繁进行意思沟通，所以必须处理意外的网络错误、服务器故障或进程终止等问题。这表达了AWS方面对于分散系统的艰难之处的想法。

解决分散系统问题的方法

分散一致和相關術語

    Raft Understandable Distributed Consensus

这个网站融合了以分散协议算法Raft为基础的动画说明，非常适合快速理解分散系统中涉及的分散合意和领导者选举过程。

首先，强烈推荐在观看这个动画时逐帧播放，这样可以更好地理解整体情况。（虽然用英语阅读可能有些困难）

    分散システムについて語らせてくれ

因为有一个叫kumagi的人在SlideShare/Qiita等平台上写了很多关于分布式系统的东西，所以感觉像是建立了一条知识高速公路。非常感激。

由于分散式一致性算法周围的术语较为复杂，因此需要理解这些术语。这份资料相对容易理解，提供了对术语进行解释等内容。

下面是我记忆深刻的幻灯片编号和感想。

幻灯片编号和感想
P5 我经常看到一些人实现时没有意识到磁盘IO/网络很慢，同时在理解分布式系统时，我觉得需要记住这个观点。
P15 这是关于多台服务器故障模型的讨论，涉及到如何定义故障的程度。
如果服务器彻底停止工作故障，那么处理错误会更容易，而服务器半途而废或是表面上看起来正常实际上却在虚假报告的情况下，处理错误就更困难了。故障级别（我的理解）

1.没有故障：不需要特别辛苦地处理错误
2.故障停止：集群中的某台服务器出故障了，整个集群都知道这个问题并且认为是故障。处理这个故障的情况会稍微困难一些
3.崩溃恢复：服务器可能出故障，同时也可能会恢复的状态。处理这个故障的情况会非常困难
4.拜占庭错误：虽然彼此之间可以通信确认，但存在虚假报告的可能性。处理这个故障的情况会非常非常困难

P19 似乎通过解决共识问题，其他问题也能得到解决。
如果共识问题得到解决
⇒ 选择领导者问题能够解决
⇒ 原子广播问题能够解决
⇒ 状态机复制问题能够解决
P22 单独看Paxos只能解决共识问题，之前错误地将Paxos与Raft看作同等重要。看来需要同时研究Paxos和Multi Paxos。
P24 – P32 似乎2PC只能在没有故障的情况下才能正常工作。
所以，这篇资料全文主张放弃2PC吗？
P44 通过比较Raft和Paxos，可以看出Raft有多么简单。能够以简单的方式解决复杂问题是程序员的技能展示之一，我觉得。
P45 真好，喜欢最后来个毒舌评价。

Raft分散一致算法

    分散合意アルゴリズム Raft を理解する

唉，这篇论文非常通俗易懂，非常有益。虽然有些地方很难理解，但我试着阅读了下方的slide share资料和Raft的Rust实现代码，还查了一些相关名词，渐渐地有些理解了。（嗯，要完全理解所有内容确实很困难）

    Raft slide share

我认为处理工程经过仔细描述，因此很容易理解。由于分散一致算法本身并不是很熟悉的算法，所以非常感谢您能仔细解释一下。

    Rust初心者がRustで全文検索サーバを作ってみた

有一個故事說明了在結合Raft算法方面的困難。

由于PingCAP也提供了raft-rs，所以我们将使用这个库来集成Raft。开始实际的集成工作，但是这个库的使用方式非常困难。Paul先生似乎也尝试过一次，他说：“我不太了解如何使用它，完全失败了”。

我也看了 Github 上的实现，感觉很辛苦地将库集成进去。(还没有读完就力不从心了)
我觉得这对于在 Rust 中实现 Raft 算法时非常有参考价值。

 

    raft-rs(RaftのRust実装)

⇒因为有Raft的Rust实现，所以我稍微看了一眼。

在下面的raft.rs文件中，通过处理MessageType::MsgHeartbeat和MessageType::MsgRequestVote等消息，在条件判断中调用become_follower和become_leader等函数。服务器似乎在进行选举和投票，非常有趣。

我对中间件系统的实现不是很熟悉，所以想好好阅读一下。如果你有兴趣的话，请务必跟进实现过程。

 

Paxos是一种分散一致性算法。

    今度こそ絶対あなたに理解させるPaxos

由于Python代码已经对其进行了解释，所以即使是以代码的形式也易于理解。此外，由于它具有类似下面这样的有趣的嘴碎，阅读起来也很有趣。

Paxos算法是一种选择“唯一不覆盖的值”的算法，不怕误解地说，它单独来看没有什么好用的地方。

Paxos可以实现共识，但它无法单独实现领导者选举、原子广播和状态机复制，所以需要依赖扩展了的Multi-Paxos等方法。

    Paxos slide share

我认为这个资料很好理解，就像Raft slide share一样，处理流程是详细说明的。它包含了提议者、接受者、学习者的讨论，以及关于学习所需参考文献的内容。

分散共识算法 PBFT（实用拜占庭容错）

    コンソーシアム型ブロックチェーンで使用できる合意形成アルゴリズム「PBFT」

根据所述, Raft/Paxos可以处理级别为3的故障：恢复崩溃, 但无法处理级别为4的拜占庭故障。然而，使用PBFT（实用拜占庭容错）算法可以处理拜占庭故障。

这篇文章的内容非常易懂，而且还通过文章内的链接详细解释了与区块链相关的技术，特别感激。

    今ビットコインのブロックチェーンを学ぶ意義とは？Pythonで作ってみたい人のための解説書から紹介

这是一篇写得很好的文章，内容涵盖了集中系统和分散系统的解释，以及区块链的历史。我原本只是想简单地了解分散系统，却没想到最终深入了解了区块链。这让我感到意外而愉快，就像点与点之间不经意间连结的极致快感。

混沌工程

    カオスエンジニアリングの原則

⇒混沌工程与分散系统的故障应对/测试方法有关。
我希望在构建分散系统时能够考虑这一原则，以便在需要进行混沌工程时进行设计。

混沌工程可能是重要的品质保证措施，但在没有开发资源的情况下进行可能会很困难。希望能够在找到合适的平衡点进行测试。

    カオスエンジニアリングで本当にカオスにならないための進め方をグラレコで解説

这篇文章的插图很有趣，易于阅读。我不知道有一个叫作AWS故障注入模拟器的东西。如果想在AWS上尝试混沌工程，我想试着使用一下。

    Chaos Engineering(oreilly)

如果從目錄上看，我會覺得這本書可能很難讀，但是如果我想要更深入且有系統地學習混沌工程，我想我會想要閱讀它。

    カオスエンジニアリングの過去と今(前編)

我觉得这是一篇很有趣的文章，它与Netflix的技术历史一起讲述了混沌工程。如果在正式环境中不进行混沌工程，那么可以在正式环境之前的暂存环境中进行吗？对于这个角度，我认为”这是现实可行的”。如果频繁地在正式环境中出现bug，我会变得心神不宁，无法入睡。

看看实际服务的分散系统

AWS DynamoDB 亚马逊云动态数据库

    Amazon がリーダーを選ぶ方法

通过采用租赁的方式，亚马逊似乎正在进行领导人的选拔。

要选择领导者，有各种方法可供选择，包括像Paxos算法、Apache ZooKeeper软件、定制硬件和租赁等方式。租赁是亚马逊最广泛使用的领导者选举机制，它相对容易理解和实施，并提供内置的容错性。

在进行资源的互斥控制时，传统的资源锁会在被锁定的客户端进程明确释放之前授予资源的控制权。

然而，如果使用资源租赁的方式，将资源租出给客户端进程并设定租期，一旦租期到期，无论客户端进程处于什么状态，资源的控制权将会转交给下一个人。大概是这样吧。

    How to do distributed locking

我认为这篇文章是对Redis Redlock算法的分布式锁方法发出警告，但它可能对理解分布式锁的复杂性和租约概念有所帮助。尽管是用英文写的，但我认为它非常值得阅读。

    Amazon DynamoDB Lock Client

Amazon DynamoDB Lock Client是一个专为DynamoDB构建的通用分布式锁库。尽管它是用Java编写的，但在租赁期间可以感觉到对资源的读写代码。如果您有兴趣，也可以阅读一下代码。

弹性搜索

    Elasticsearch as a Distributed System

可以在图中清楚地看到Elasticsearch节点的角色、搜索/索引更新的流程、故障检测以及解决脑裂问题的机制等内容，这使得理解变得非常容易。我认为这是想要了解Elasticsearch作为分布式系统的必读资料。

    新世代Elasticsearchクラスターコーディネーション

⇒据说 Elasticsearch 7版本引入了新的分布式共识系统。它不使用纯粹的Raft算法等插件，而是将各种分布式共识算法的优势结合在一起。（虽然有点担心它是否变得无法预测）

只要熟悉Paxos、Raft、Zab、Viewstamped Replication（VR）等分散一致算法家族，就能很好地理解核心的安全模块。它对单个可重写寄存器进行建模，并使用类似于Paxos的投票、Raft的任期和VR的视图的主节点术语概念。

    Elasticsearch Distributed Consistency Principles Analysis (1) – Node

可能是第一次閱讀阿里巴巴雲的博客。這篇文章對於選舉主席的機制、以及與ZooKeeper、Raft的相似點和不同之處進行了整理，並且在題為Elasticsearch的源代碼中提到了許多地方。這篇文章感覺相當不錯，真不愧是阿里巴巴呀（得翻譯一下因為是英文）。

Apache ZooKeeper：阿帕奇动物管理员

    Apache ZooKeeper vs. etcd3

⇒ZooKeeper是一种集中式的服务，用于保存配置信息、命名、分布式同步以及提供群组服务。这种类型的服务在分布式应用程序中以某种形式被广泛利用。

由于ZooKeeper和etcd（一种持久且轻量级的分布式键值存储）的角色相似，所以关于它们的对立结构的文章很多。可以说ZooKeeper是老牌的，而etcd则是后起之秀。这篇文章中也描述了它们各自的优点和缺点，是一篇很好的文章。通过这样的对比学习可能会提高学习效率。

以下是 DeepL 翻译摘录：ZooKeeper 在 Apache 的几乎所有项目中都被使用，如 Hadoop、Kafka、Solr 等。由于其优秀的记录和稳定性，ZooKeeper 已成为世界顶级的分布式协调系统。ZooKeeper 使用 ZAB (ZooKeeper Atomic Broadcast) 作为其一致性协议。

etcd 是用 Go 编写的，其主要目的是解决 ZooKeeper 的缺点。虽然没有像 ZooKeeper 那样的历史和知名度，但它是一个具有潜力的项目。被称为 Google 的容器管理平台的 Kubernetes，使用 etcd v2 作为分布式存储，并获取主组件的分布式锁。etcd 使用 RAFT 一致性算法作为其共识机制，比使用 ZAB 协议的 ZooKeeper 更容易实现。

    ZooKeeper Internals

⇒因为看起来没有太多的日语文章，所以最快的方法是好好看一下官方文档吧…

以下是DeepL翻译文章摘录：ZooKeeper的消息传递分为两个阶段。
1.领导者激活
在这个阶段，领导者确立系统的正确状态，并准备开始提议。
2.开始发送消息
在这个阶段，领导者接收并调整要提出的消息的传递。

1.领导者激活
目前，ZooKeeper有两种领导者选举算法。LeaderElection和FastLeaderElection（AuthFastLeaderElection是FastLeaderElection的变种，使用UDP并且服务器可以执行简单的身份验证以避免IP欺骗）。只要满足以下条件，ZooKeeper的消息传递就不会过于关注选举领导者的确切方法。
– 领导者在所有跟随者中观察到最高的zxid。
– 存在支持支持该领导者的服务器quorum。

⇒只要知道最高的zxid（ZooKeeper交易id），并获得多数支持的服务器可以成为领导者。大概是这样。

2.开始发送消息
领导者以相同顺序向所有跟随者发送建议。而且，这个顺序遵循接收请求的顺序。由于使用了FIFO通道，因此跟随者也会按顺序接收提议。
跟随者按接收顺序处理消息。这意味着消息将按顺序进行确认，领导者将按顺序从跟随者接收ACK，因为使用了FIFO通道。

⇒一旦确定了领导者，领导者将依次向跟随者发出指令的感觉。

etcd可以被简单地解释为“分布式键值存储系统”。

    Kubernetes

⇒由于etcd在Kubernetes内部使用，因此我建议首先了解Kubernetes。不过，Kubernetes本身是一项复杂的技术，所以需要通过查阅各种概念和术语来逐渐理解。我将附上官方文档。

    Kubernetes etcd：歴史、進化、使い方について

这篇Qiita的文章似乎是翻译自下面这篇阿里巴巴云的文章。（非常感谢阿里巴巴云，您的精彩文章一直给予我们帮助和指导。）

 

通过阅读有关etcd基于Raft算法进行领导者选举/数据同步的内容，以及了解Kubernetes如何使用etcd进行服务发现/保存Kubernetes元数据等等的内容，对我来说非常有学习价值。

    Kubernetes Leader Election in Depth

看到Kubernetes领导者的选举流程整理在幻灯片上，以及研究Go的实现，对我来说非常有学习价值。毕竟，我很想了解领导者选举的步骤，特别感激这篇文章。

分散系统这个东西，越了解就越惊艳。

因此，我挑选了一些表面上看起来不错的文章进行了简要概述。

希望这篇文章能成为对想学习分散系统的人有所帮助的好文章，虽然我的解释可能完全错了。写这篇文章时，我觉得分散系统真的非常复杂。

我像是在做竞选活动，决定竞选下一任领导者，
我们互相沟通着，互相问候说：”你们都好好地过着么？”，这种情景有点像是把我们擬人化，看起来就像是一幅小社会的缩影，感觉非常可爱呢。

感谢您阅读。

✖
广告
将在 10 秒后关闭
bannerAds