• 👽
    2022-12-27 来自北京
    文中的这一段,如何保证数据一致性的解释: “这里有个小技巧,就是 Follower 在收到查询请求时,会顺便问一下 Leader 当前最新 commit 的 log index 是什么。” 这里是不是意味着每次对从节点的查询,一定会伴随对主节点的查询?这么来看的话,性能岂不是会很差?不单单是要求修改量小,查询量多了主节点是否也容易承受不住? 另外一个问题是,我们有一个大佬说,现在的分布式一致性都是扯的,我们追求的只能是最终一致性。这样说有道理吗?我们是否还应该追求分布式数据的强一致性?

    作者回复: 从某个角度来说,这和我们的需求有很大关系。用户量大的服务业务对性能要求高,不管多大的公司投入硬件都是有限的,所以基本能看到的都是最终一致是主流(常见的读多写少服务是主流)。而分布式一致性如果不考虑性能是能做到的,只是不值得,因为还要考虑高可用等事宜。

    共 4 条评论
    4
  • Layne
    2022-11-30 来自北京
    老师,主从之间通信不上的时候,怎么确定是主还是从出问题了呢?这种情况下主从分别会做些啥操作呀?

    作者回复: 你好,Layne,一般来说主从同步,都是从主库复制变更过程到从库执行,所以看从库同步状态的错误原因就可以了。

    共 3 条评论
    2
  • HappyHasson
    2022-11-04 来自北京
    收到投票申请的服务,并且申请服务(即“发送投票申请的服务”)的任期和同步进度都比它超前或相同,那么它就会投申请服务一票 原文中这句话意思是,如果一个follower收到了自荐投票请求,任期比自己大但是同步进度没有自己大,这时候会拒绝投票?

    作者回复: 你好,HappyHasson,很高兴收到你的留言,是的!这个机制是为了保证,拥有最新进度的leader能够被选中,这样可以减少损失,因为leader是可以强制其他follower和他一致的,这就导致如果leader进度不如其他follower会强制覆盖丢失掉这个差异

    共 3 条评论
    2
  • HappyHasson
    2022-11-04 来自北京
    有两个问题, 一,这里没有主观下线和客观下线的区分吗,就是当一个follower检测到leader下线,但是不一定真的下线了,而且网络抖动引起的 二,我看到的理论都是说投票过半数就选举成功了,这里说是三分之二,为什么

    作者回复: 你好,HappyHasson,很高兴再次收到你的留言 第一个问题:网络抖动引起的下线也会影响数据的同步,所以从某个角度来说他已经不是同步更新的节点了,如果是下线的是leader那么会导致更新数据卡住等待其他follower回馈,这很影响服务稳定。第二个问题,一般来说是一半,但是从以往经验来看,一半容易出现脑裂,为了减少避免这个问题的概率,所以是三分之二,当然缺点是大规模掉线会卡住服务。

    
    2
  • 一步
    2022-11-15 来自北京
    如果集群中的 Follower 节点在指定时间内没有收到 Leader 的心跳 ---------- 这里是不是有数量的限制,比如说至少一半的 Follow 节点?

    作者回复: 你好,一步,Follower只会收到leader的心跳,同时一半是指leader自己统计有一半Follower消失吗?

    共 3 条评论
    1
  • 千锤百炼领悟之极限
    2022-11-14 来自北京
    可以说了解了 Raft,就相当于了解了分布式强一致性数据服务的半壁江山。另一半是ZAB吗?

    作者回复: 你好,很高兴收到你的留言,还有一些但是没有他复杂,比如gossip

    
    1
  • Mr.Tree
    2022-11-12 来自北京
    对于Raft保证数据读取的强一致性,follower的读取都会向leader发送一个版本确认请求,如果是高并发的情况下,leader的压力岂不是会很大,会不会把它打崩,或者客户端出现延迟,对于这种主从结构系统;出现写冲突是如何处理呢?想到一个场景:张三人在国外,银行账户里存有1w,通过手机银行APP转帐给李四8k,于此同时,张三媳妇在国内通过ATM机查询账户1w,想要取5k,这种同时发生,对于这种强一致性要求系统会怎么处理?

    作者回复: 你好,Mr.Tree,很高兴收到你的疑问,事实上大部分交易系统为了保证数据的强一致都是用本地主库去做的,当进行交易的时候跨区域通讯到核心机房去做交易。你的开户行决定了你的数据在哪里做决策,在下一节课你会看到Raft算法,这里会对这个疑问有很大的帮助。

    
    1
  • Geek_499240
    2022-11-10 来自北京
    如果leader收到了一个请求,并把日志同步到了大部分的follower上,如果leader 还没来得及commit就奔溃了,那么新选举出来的leader会commit这条消息吗?

    作者回复: 你好,很高兴收到你的提问,你问到了一个额外的知识点,这里新选举出来的leader在选举成功后会立刻写一个no-op日志,这个操作会把之前没有commit的都提交。这么做是因为不想让新leader提交前任的内容,会产生数据冲突等问题。no-op是一个知识点,可以查一查

    共 3 条评论
    1
  • OAuth
    2022-11-10 来自北京
    单节点变更,一次变更一个节点

    作者回复: 你好,oauth,很高兴收到你的思考,同时这个节点不能参加竞选

    
    1
  • 花花大脸猫
    2022-11-06 来自北京
    思考题中增加节点因为需要同步的数据量会比较大,所以 特殊去做,以防影响集群对外提供的服务稳定性。减少节点需要特殊处理是不是怕由于脑裂导致的选举异常,直接导致服务对外不可用,不知道这么理解对不对?

    作者回复: 你好,花花大脸猫,有这方面的原因,同时如果加的节点过多也会造成选举出现问题~

    
    1