1.分布式根本实践

  • cap实践：
     
    consistency： 一致性
     
    availablity：可用性
     
    partition tolerance： 分区容错
     
    分布式服务在零碎呈现肯定故障的时候，还能够对外提供服务。根本所有分布式系统都能够满足此要求。c和a之间存在矛盾，如果谋求一致性就须要摈弃可用性，如果谋求可用性，数据一致性就不会被满足。
     
  • base实践：
     
    basic available：根本可用
     
    softstatue： 软状态
     
    eventually： 最终一致性
     
    零碎能够处于一致性中间状态，但可用，零碎能够达到最终一致性状态，其实现办法能够应用基于消息中间件+定时工作补发音讯来实现。
     

2.分布式一致性算法

 
    在cap实践中，如果保证数据强一致性，就须要所有正本同步主节点的所有数据，在数据同步过程中，对外不可用，在所有分布式一致性算法中，解决此的思维是大多数正本同步（个别都是过半）主节点的数据后，主节点就能够应用对客户端进行相应。
 

  • basic paxos算法
     
    basic paxos算法有prepare、accept和learn三个阶段，以及提案者，决策者和学习者。
     
    prepare阶段：提案者发出请求到过半的决策者，申请中携带生成的全局惟一递增id,该id能够是工夫戳+机器id。
     
    accept阶段：决策者接管到提案者的id信息后，通过比拟保留的id和申请的id大小，如果申请的id大于保留的id，就会把保留中的最大的id及对应的提案值作为响应发送给提案者。而且之后决策者会回绝所有id小于以后的id的提案申请，只承受大于以后id的申请。当提案者接管到决策者过半的响应后，就会在所有响应中获取最大id的提案值作为提案值，发送给过半决策者，此过半决策者能够与提案决策者不同，决策者收到申请后，就会提交申请。
     
    learn阶段：所有learner同步决策者的数据。具体形式能够是每一个learner去申请accept，也能够所有learner抉择一个主learner，主learner同步accept的数据，其余learner同步主learner。

     
    上述paxos算法是basic paxos算法，如果有多个提案者，就会导致活锁问题。为了解决此问题，提出只有一个主提案者，在多个提案者中，先抉择一个主提案者，所有的提案都由该主提案者进行提交。
     

  • Raft算法
     
    leader选举
     
    日志同步
     

  • zab算法
     

    • 启动选举leader
      每台机器发送(myid，zxid)到别的机器，别的机器查看是否是在选举过程中，而后比拟zxid，投票给zxid大的，如果zxid雷同就投票给myid大的，等到有机器接管到一半以上的投票后即成为leader

 

  • 运行中选举
    逻辑大抵同启动时选举leader,只不过换成sid和zxid，过半投票机制。而后再同步数据。

 

  • kafka 选举
     
    isr列表
     
    高水位HW
     
    过半机制