• 1024
    2019-09-30
    两主的情况出现在集群因为网络原因,被划分了两部分局部可通信的区域。下面的链接详细讲解了Raft算法,及双主出现后集群是如何恢复的。
    https://www.infoq.cn/article/coreos-analyse-etcd/
    还有一个Raft算法动画链接
    http://thesecretlivesofdata.com/raft/#election
     6
     34
  • 每天晒白牙
    2019-09-30
    今天这篇文章赚到了
    1.分布式选举算法是为了保证数据一致性的
    在集群中存在多个节点提供服务,如果每个节点都可以写数据,这样容易造成数据的不一致,所以需要选举一个leader,往leader节点中写数据,然后同步到follower节点中。这样就能更好的保证一致性
    但因为同步数据存在延迟,所以follower节点的数据不是每时每刻都和leader节点数据保持一致的
    有的框架是由leader提供读写操作,这样能保证写和读都是最新的数据,我没记错的话kafka就属于这种,读写都发生在主副本上。
    而像mysql集群是在主节点写入数据,从节点提供读功能,即主从架构

    总之,我觉得,一个好的分布式选举算法能更好的保证数据的一致性

    2.老师说的集群中存在双主是说选举算法出了问题,出现了两个主,还是说双主是正常情况,两个主互提供写服务,然后再互相同步数据的情况呢?
    展开

    作者回复: 从你对分布式选举的总结可以看出,你很善于思考和总结。关于双主的情况,一般是因为网络故障,比如网络分区等导致的。出现双主的期间,如果双主均提供服务,可能会导致集群中数据不一致。所以,需要根据业务对数据不一致的容忍度来决定是否允许双主情况下提供服务。

     11
     19
  • cp★钊
    2019-09-30
    想问下老师,选举的性能,评判的标准是什么?为什么zab的性能最好,是指哪方面的性能?
    
     16
  • kylexy_0817
    2019-10-23
    老师,本节为何不提及一下Paxos算法?
     1
     7
  • 游弋云端
    2019-09-30
    1、分布式选举和一致性的关系是什么?
    个人理解选举本身其实就是一致性的一次协商,要求全局认可同一个节点做主节点。选举的目的是为了简化一致性协商的流程,让选出的master来协调各成员针对某项决议达成一致;
    2、你是否见到过一个集群中存在双主的场景?
    双主是可能发生的,例如原主网络与外部中断,集群发生脑裂,则老的集群主还存在,分裂的剩余节点由于与老主失联,大家重新选了新主出来。此时就会产生双主。规避双主的影响,需要通过租约机制,让老主发现在租约到期后与大多数节点失联主动降备;新主的选举也要等待超过这个租约时间后去选举新主,避免业务同一时刻看到双主。但是由于各个服务器资源、负载、调度等问题,时间并不是一个精确的可靠保障,例如定时器失真,还是可能导致同一时刻出现双主,所以每个地方的租约时间配置是个技术点。另外新主产生,生成新的epoch(+1),这样可以避免大家去处理老消息,从而进一步规避双主的问题。
    展开
    
     7
  • AllenGFLiu
    2019-10-19
    老师,在Raft算法中,每个节点只有一票可以投,要么同意要么拒绝,可是节点是基于什么条件作出的判断呢?Bully算法中我看老师又说到是论资排辈的。
     2
     6
  • 清风
    2019-10-04
    一个问题:如果初始情况下,按照约定,给与奇数节点数,但是选举是这时一个节点挂了?岂不是一定是偶数节点数?只是为了初始选举方便?不考虑故障情况?
    
     6
  • Will
    2019-09-30
    问下老师,Bully 和 ZAB 都是根据 ID 的大小投票,那 Raft 算法选举时的投票依据是什么?是随机投票么,如果是随机投的话,奇数节点好像也并不能保证投票结果不会出现同票的情况啊?
    希望老是解答一下
     3
     3
  • 王喜春
    2019-11-21
    1. https://github.com/sluk3r/Bully-Algorithm
    2. https://github.com/sluk3r/sofa-jraft
    3. http://thesecretlivesofdata.com/raft/#election 动画效果。
    4. 自己搞一个新的算法的微创新?
    
     2
  • Lugyedo
    2019-10-01
    奇数个节点的集群当一个节点故障时会变成偶数个节点吧,这个时候“多数派”算法怎么选主
     3
     2
  • 张理查rootv
    2019-12-25
    分布式技术原理与算法#Day7
    前几天我们看到了分布式集群中都会有一个协调者存在,比如那个厕所叫号员就是这么个角色。那究竟是谁能来做这个协调者或者管理者呢?选出这个负责协调和管理的主节点的过程就是分布式选举。同样我们前面也提到过多次的单点问题,很多时候就是领导者“驾崩”导致的,如何在领导者驾崩后立即再次选出下一任领导者,也是分布式选举中需要十分关注的一个点。
    选主的常见原则是基于序号以及基于投票。类似资历优先(岁数大)还是能力优先(票数高)。
    基于资历(序号)的常见算法就是Bully(恶霸)算法:就是选取所有节点中,ID最大的节点作为主节点。
    既然需要判断自己是不是最大,就需要自己来存储其他所有节点的ID。选举开始后:
    1. 宣誓主权:判断自己是不是最大的,如果是就通知各位自己是主了(向所有人发送Victory消息)
    2. 认怂:如果自己不是最大的,需要向比自己大的认怂,承认各位大佬江湖地位,并等待回复(向大佬们发送Election)
    3. 大佬收到小弟发来的Election消息,就会给小弟发送Alive,表示自己活着。(向小弟发送Alive信息)/
    4. 小弟如果没有收到大佬发来的Alive信息,说明比自己大的都死绝了,我可以登基了(向所有人发送Victory消息)
    可见其选举速度快、复杂度低、简单易实现。
    但所有节点的信息存了所有其他节点的ID,存储的冗余度较高。而且有一个风险,就是ID最大的频繁进出集群,就会频繁切换主节点。还有一个缺点没提到就是ID最大的并不一定是能力最强的。
    基于能力,民主一点的可以是Raft算法:核心思想是”少数服从多数“。
    Raft算法规定了包括Leader主节点、Candidate 候选节点以及Follower跟随节点:
    1. 开始选举时,大家都会变成候选节点,向其他节点发送选举请求
    2. 每个节点根据先后顺序回复是否同意
    3. 若同意数超过一半,则成为主节点,其他节点降为跟随节点,并与主节点互发心跳包
    4. 主节点失效活着任期结束再来一轮选举
    可见这种方式选举速度快、复杂度低、易于实现。
    但选举时的通信量是n * (n -1 )。Raft如果ID最大的频繁进出集群,虽然会触发选主,但不一定真正切主。除非得票数过半。
    基于能力,还有一种算法是ZAB算法:核心思想是“少数服从多数+ID大的优先”
    ZAB是ZK实现协调所设计的。偏向于数据更新的节点。ZAB添加了server_zxID 来表示本节点存放的数据ID,越大越新(能力越强)。选举过程与Raft算法类似,只不过Raft根据先后顺序来判断,而ZAB先比较数据ID,数据ID相同的再比较ServerID,也就是说ZAB喜欢“能力强的年轻人”。
    但同样也有广播风暴的问题,且增加了一点选举的复杂度,但会使得主节点更加稳定,因为新节点增加或故障节点(数据不会太新)恢复,触发选举后切主的可能性要更小一些。
    因此你看后两种投票少数服从多数的情况下,最好还必须候选者是单数,否则可能因为票数相同而需要多次重新投票。所以经常看到ZK、etcd、K8S都会建议奇数节点。
    展开
    
     1
  • 💢 星星💢
    2019-11-14
    老师本节开头就说为了保证分布式的协调和调度,必须要要有一个主节点。主节点的出现就是保证数据一致性。没有主节点,在分布式环境中数据就会发生混乱。根本达不到一致性。因此在分布式环境中的一致性前提是必须选择一个节点。但是由于网络的原因,或者服务器宕机的原因,而老师上面说了通过心跳机制定时检测主的状况,会触发新的选举,会产生新的主,但此时老的leader又重新恢复过来,就产生双主的情况。此时老的leader会降级成folllower。老师我有个疑问,就是在选举过程中,如果老的leader恢复过来了。那数据的写请求还是给老l的eader么?如果是老的leader又要实行数据同步问题也太复杂了。。。
    
     1
  • Mr.Brooks
    2019-10-31
    raft算法选举的时候每一轮只有一个选票,这个选票是如何确定投给哪一个节点呢?
    
     1
  • zhaozp
    2019-10-08
    打卡文章学习:
    1、选主意义:主节点负责其他节点的协调和管理,保证其他节点有序的运行。
    2、选举算法:
       (1).Bully算法,选择ID最大的节点作为主节点。需要用到3种消息:Election消息用于发起选举;Alive消息对Election消息的应答;

    Victory消息,宣誓主权。优点:选举速度快、算法复杂度低、实现简单。缺点:每个节点需要有全局的节点信息,额外存储的信息较多;有

    频繁切主的风险。
       (2).Raft算法,民主投票,少数服从多数。3种角色:Leader,Candidate,Follower。优点:选举速度快、算法复杂度低、易于实现。缺点:要求集群中每个节点都可以互相通信,且需要获取超过半数的投票才能选主成功,通信量大。
       (3).ZAB算法,具有优先级的民主投票,尽可能保证数据最新性,ID大的节点优先成为主。3种角色:Leader,Follower,Observer。4种状态:Looking,Leading,Following,Observing。。。每个节点有三元组(server_Id,server_zxID,epoch)。。。选主原则:server_zxID最大者成为Leader,若server_zxID相同,则server_id最大者成为Leader。优点:性能稳定。缺点:选举时间较长,容易出现广播风暴,需要知道所有节点的zxId和serverId,选举时间较长。
    展开

    作者回复: 积跬步,而终至千里!加油!

    
     1
  • blackpiglet
    2019-10-01
    对分布式选举算法的性能评判标准也有点疑惑,课程中感觉性能更多是指选举算法的稳定度,新加入节点或节点反复出现可用性问题对集群状态的影响是否足够可控,似乎主节点选举的速度和选举时产生的消息数量并不是主要的考虑因素。
    
     1
  • 随心而至
    2019-09-30
    1.分布式选举和一致性,感觉是密不可分的。重新选举依靠一致性提供的数据,一致性又要依靠选举出来的主节点进行。这里我只了解过raft算法
    https://www.cnblogs.com/xybaby/p/10124083.html
    2.有个brain split(脑裂),比如说两个机房原来网络想通,可以正确选主,后来网络不通,每个机房都只知道自己的小山头,他们就容易各自占山为王。
    http://www.ruanyifeng.com/blog/2018/07/cap.html
    也可以搜下维基百科brain split。

    在地铁上写的,有不对之处,请老师指出
    展开
     1
     1
  • idea
    2020-01-12
    老师:关于raft协议,之前看文章中有说raft协议也会保证拥有最多信息的节点在选举中优先获胜,这个文章中没有提及。
    拥有最新的已提交的log entry的Follower才有资格成为Leader。
    这个保证是在RequestVote RPC中做的,Candidate在发送RequestVote RPC时,要带上自己的最后一条日志的term和log index,其他节点收到消息时,如果发现自己的日志比请求中携带的更新,则拒绝投票。日志比较的原则是,如果本地的最后一条log entry的term更大,则term大的更新,如果term一样大,则log index更大的更新。
    参考链接:https://zhuanlan.zhihu.com/p/32052223
    展开
    
    
  • 空知
    2020-01-05
    老师,有两个问题请教下
    1.raft里面 同意 不同意依据是什么
    2.为啥要有任期,或者好处是啥?如果一个主节点干的好好的,不应该再去选举增加消耗呀
    
    
  • td901105
    2019-12-19
    老师有个问题不太明白,像zookeeper数据写入时只要和leader交互,然后同步到超过一半的follower节点即可.在数据没有同步完成之前,client去读取数据的时候就会存在数据不一致的情况,zookeeper是怎么处理这种情况的呢?
    
    
  • 小明
    2019-12-15
    bully跟zab很像呀,一个是节点id一个是数据库加节点id
    
    
我们在线,来聊聊吧