作者回复: 从某个角度来说,这和我们的需求有很大关系。用户量大的服务业务对性能要求高,不管多大的公司投入硬件都是有限的,所以基本能看到的都是最终一致是主流(常见的读多写少服务是主流)。而分布式一致性如果不考虑性能是能做到的,只是不值得,因为还要考虑高可用等事宜。
作者回复: 你好,Layne,一般来说主从同步,都是从主库复制变更过程到从库执行,所以看从库同步状态的错误原因就可以了。
作者回复: 你好,HappyHasson,很高兴收到你的留言,是的!这个机制是为了保证,拥有最新进度的leader能够被选中,这样可以减少损失,因为leader是可以强制其他follower和他一致的,这就导致如果leader进度不如其他follower会强制覆盖丢失掉这个差异
作者回复: 你好,HappyHasson,很高兴再次收到你的留言 第一个问题:网络抖动引起的下线也会影响数据的同步,所以从某个角度来说他已经不是同步更新的节点了,如果是下线的是leader那么会导致更新数据卡住等待其他follower回馈,这很影响服务稳定。第二个问题,一般来说是一半,但是从以往经验来看,一半容易出现脑裂,为了减少避免这个问题的概率,所以是三分之二,当然缺点是大规模掉线会卡住服务。
作者回复: 你好,一步,Follower只会收到leader的心跳,同时一半是指leader自己统计有一半Follower消失吗?
作者回复: 你好,很高兴收到你的留言,还有一些但是没有他复杂,比如gossip
作者回复: 你好,Mr.Tree,很高兴收到你的疑问,事实上大部分交易系统为了保证数据的强一致都是用本地主库去做的,当进行交易的时候跨区域通讯到核心机房去做交易。你的开户行决定了你的数据在哪里做决策,在下一节课你会看到Raft算法,这里会对这个疑问有很大的帮助。
作者回复: 你好,很高兴收到你的提问,你问到了一个额外的知识点,这里新选举出来的leader在选举成功后会立刻写一个no-op日志,这个操作会把之前没有commit的都提交。这么做是因为不想让新leader提交前任的内容,会产生数据冲突等问题。no-op是一个知识点,可以查一查
作者回复: 你好,oauth,很高兴收到你的思考,同时这个节点不能参加竞选
作者回复: 你好,花花大脸猫,有这方面的原因,同时如果加的节点过多也会造成选举出现问题~