zoukankan      html  css  js  c++  java
  • Consul实现原理系列文章1: 用Raft来实现分布式一致性

     

    工作中用到了Consul来做服务发现,之后一段时间里,我会陆续发一些文章来讲述Consul实现原理。在前一篇文章中,我介绍了Raft算法。这篇文章会讲讲Consul是如何使用Raft算法来实现分布式一致性的。

    Consul中的Raft

    只有以server模式运行的Consul节点,才会被认为是Raft节点集的一部分。所有的client节点会把收到的请求转发到server节点中。这么设计的原因主要是出于性能方面的考虑:节点集中的个数越多,那么法定个数的值也就越大,这会导致leader节点可能需要等待数百个follower节点对一条log entry的agree信息。

    在开始的时候,单个Consul server进入到bootstrap模式,这种模式允许它把自己选举为leader。当leader被选举出来之后,别的server就可以被加入到节点集中,从而保障了一致性和安全性。最终,当最初的几台server被加进来后,bootstrap模式可以被关闭。

    consul server加入节点集之后,他们会知道哪台机器是当前的leader。当一个RPC请求到达一台非leader server上时,这个请求会被转发到leader上。如果这个请求是一个查询类型(只读),leader会基于现在的状态机生成结果。如果这个请求是一个事物类型的请求(会修改状态),leader会生成一个新的log entry,并用Raft的方法去处理它。当这个log entry被提交并且被应用到状态机上时,这个事物就算完成了。

    Raft会把log entry复制到多台机器上,因此网络延迟对于性能的影响很大。因为这个原因,每个数据中心选出一个独立的leader并且维护一份不相交的节点集。数据通过数据中心的方式做分割,因此每个leader只对自己这个数据中心内的数据负责。当一个请求到达一个数据中心,这个请求会被转发到正确的leader那里。这种设计下,我们可以做到低延迟事物以及高可用,而不用牺牲一致性。

    一致性模式

    尽管所有的log entry的写入都会通过Raft来实现,读取却要灵活的多。为了支持开发者可能需要的多种权衡取舍,Consul对于读取,提供了三种不同的一致性模式。

    这三种模式是:

    default

    Raft用到了leader约期的概念,意思是,在一个时间窗口中,leader认为自己的角色是稳定的。但是,如果leader节点与别的节点被分隔,即发生所谓“脑裂”现象,那么会有一个新的leader节点被选举出来。旧的leader节点将不能提交任何新的log entry, 但是如果它提供了对数据的读取,那么客户端读到的这些值可能是过期的。

    默认模式是基于leader约期的,因此客户端可能读到过期的值。但是这种模式是对读取速度和一致性的一种取舍,牺牲了某些情况下的强一致性,以换取更高的读取速度。

    consistent

    这种模式是强一致性模式。这种模式要求leader节点每次做读和写操作时都要与法定个数的节点去确认自己仍然是leader。 牺牲读的速度,保障了强一致性。

    stale

    这种模式允许任何Consul server向外部提供读取操作,无论它是不是leader节点。  
    这种模式特别快,但是读到过期数据的可能性非常大。这种模式允许在没有leader节点的情况下对读请求做出相应,尽管实际上这时候Raft集群已经是处于不可用状态了。

    参考:

    https://www.consul.io/docs/internals/consensus.html

  • 相关阅读:
    企业如何推行白盒测试
    Java命名规范
    MobileVLC for iphoneos4.3
    用Android NDK编译FFmpeg
    Linux 下Android 开发环境搭建 ---CentOS
    为什么要做白盒测试
    vlc的第三方库contrib的修改之一:live库的修改
    VC命名规范
    POJ 1470 Closest Common Ancestors (LCA入门题)
    HDU 4407 Sum 第37届ACM/ICPC 金华赛区 第1008题 (容斥原理)
  • 原文地址:https://www.cnblogs.com/williamjie/p/9369786.html
Copyright © 2011-2022 走看看