https://hangyan.github.io/categories/%E5%88%86%E5%B8%83%E5%BC%8F/Recent content in 分布式 on 涯余的博客Hugozhhang.yan@hotmail.com (涯余)hang.yan@hotmail.com (涯余)Tue, 10 Sep 2019 14:51:05 +0000https://hangyan.github.io/post/2019-09-10-raft-notes/Tue, 10 Sep 2019 14:51:05 +0000hang.yan@hotmail.com (涯余)https://hangyan.github.io/post/2019-09-10-raft-notes/<p>关注于 Raft 可能更多是因为 kubernetes/etcd 的原因，二者似乎变成了 raft 最大的<code>客户</code>，时不时地重新理解一下这个协议还是很有必要的。</p> <p>之所以这样讲，是因为分布式协议本身就很难理解。即使 raft 论文中一再声称它的主要目的之一便是容易理解，比 paxos 更好懂，但对于一般从业者来说，要想完整地理解它还是有困难的。所以经常需要温故而知新。并且，在网上一搜，关于 raft 协议的 blog 也是汗牛充栋，每个人都在试着理解，记录。可能后续还需要参考下别人的笔记，互相印证。</p> <blockquote> <p>论文地址: <a href="https://raft.github.io/raft.pdf">In Search of an Understandable Consensus Algorithm</a></p> </blockquote> <h2 id="基本知识">基本知识</h2> <p><code>leader</code> 的概念是核心之一。raft 作为一个分布式系统，各个 server 通过固定的算法选举出 leader , 然后 leader 负责状态的维护，处理 client 的请求，维护整个集群的状态等等。跟民主制度里面多党选举有点像， 一旦大多数投票通过，总统就拥有至高权力。</p> <p>除了 leader 之外，还有另外两个角色是 <code>follower</code>以及<code>candidate</code>。选举状态下，大家都是<code>candidate</code>,正常工作情况下，就分成了<code>leader</code>和<code>follower</code>。</p> <p>Raft 并没有使用系统时钟来作为同步机制，因为太不可靠了，而且维护起来很麻烦。raft 使用了一个 <code>term</code> 的概念来代表时序。</p> <h2 id="leader-election">Leader election</h2> <p>一般的流程如下所示:</p> <ul> <li>server 启动时，成为 follower</li> <li>如果 follower 在 election timeout 的时间内，没有收到 leader 发来的 heartbeat， 那么它就假定没有 leader, 准备开始选举</li> <li>follower 将自己变为 candidate， 然后给自己投一票， 然后发信息给其他 server 问其他 server 是否可以给自己投票。结果要么是大多数投了它，它成为 leader, 或者另外一个 candidate 成为了 leader, 或者没有 leader (splite vote,没有 server 获取到大多数 vote)，那么就进行一下次投票。</li> <li>在 election 的过程中，有可能其他的 candidate 已经成为了 leader, 并给当前的 candidate 发来了同步数据的请求。这时候就可以通过 term 的比较来判定，如果发过来的 term 数不小于自己的，那么就承认发送者的 leader 地位，并且把自己切换回 follower 状态。否则的话拒绝请求并且继续选举。</li> </ul> <p>这里面有一个问题，所有人都在给所有人发请求要求 vote 自己，怎么能达到有一个 candidate 获取到 大多数 vote 呢? raft 采用了 randomized election timeout 来解决这个问题。不同 server 的 lection timout 不一样，避免了大部分情况下的 splite vote 情况。如果发生 splite vote, 重来一次。这种机制跟 TCP 的拥塞控制有些类似。</p>https://hangyan.github.io/post/2019-07-24-sinfonia-paper/Wed, 24 Jul 2019 17:22:10 +0000hang.yan@hotmail.com (涯余)https://hangyan.github.io/post/2019-07-24-sinfonia-paper/<!-- toc --> <p>论文链接: <a href="http://www.sosp2007.org/papers/sosp064-aguilera.pdf">Sinfonia: a new paradigm for building scalable distributed systems</a></p> <p>Sinfornia 像是一个构建分布式系统的 SDK 。目前的市面上分布式系统已经非常多了，比如 etcd, zookeeper, ceph 等等。但他们都是分别实现的，彼此之间的代码并无太多借鉴。Sinfonia 的实践是很难得的，可以说比大部分的分布式软件都更有指导价值一些。</p> <p><img loading="lazy" src="https://hangyan.github.io/images/sinfonia/arc.png"></p> <p>这个图中展示了 Sinfonia 中关键的几部分</p> <ul> <li>user library: SDK 部分，隐藏了分布式系统处理内部细节的 SDK。用户基于 user library 来开发分布式应用</li> <li>minitranscations: Sinfonia 的核心概念。一个分布式的事物机制</li> <li>application node: 应用节点</li> <li>memory node: 维持分布式系统内部状态的节点。</li> </ul> <p>图中没有画出的有</p> <ul> <li>管理节点: 用于执行一些定期的 recover 任务</li> <li><code>directory node</code>: Application Node 访问 Memory Node 使用的是逻辑 id, directory node 记录了逻辑 id 与 真实地址的映射。</li> </ul> <h2 id="memory-node">Memory Node</h2> <p>Memory Node 存储了应用的状态数据，根据不同情况，可能是存在 RAM 中，也可能是在磁盘上。 user library 封装了操作 Memory Node 中数据的方式。Application Node 可以与 Memory Node 是同台机器也可以是不同机器(有些 Application 出于性能考虑会需要 Applicaiton Node 与 Memory Node 为同台机器，Sinfonia 会告知 Application 此种情况以便让其尽量把数据写在本机)。</p>