注册中心

• etcd注册中心

  • 分布式一致性系统
  • 基于raft一致性协议

• etcd使用场景

  • 服务注册和发现
  • 共享配置
  • 分布式锁
  • Leader选举

• 服务注册和发现的思考

  • 一定需要一致性么？不一定，例如Eureka就是高可用Ap
  • Eureka 是一个AP系统，netflix开发，用来做高可用的注册中心

Raft协议详解

• 应用场景
  • 解决分布式系统一致性的问题
  • 基于复制的
• 工作机制
  • leader选举
  • 日志复制
  • 安全性

基本概念

• 角色

  • Follower角色
  • Leader角色
  • Candicate(候选者)角色，任何Follower都可以成为候选者

• Term（任期）概念

  • 在raft协议中，将时间分成一个个term（任期）

    
    2.jpg

复制状态机

3.jpg 4.jpg

心跳（heartbeats）和超时机制（timeout）

5.jpg

Leader选举

• 触发条件：
  • 一般情况下，追随者接到领导者的心跳时，把选举定时器清零，不会触发
  • 追随者的选举定时器超时发生时（比如leader故障了），会变成候选者，触发领导人选取
• 选举过程
  • 一开始，所有节点都是以Follower角色启动，同时启动选举定时器（时间随机，降低冲突概率）

动画 http://thesecretlivesofdata.com/raft/

• 选举过程
  • 当定时器到期时，转为candidate角色
  • 把当前任期加+1，并为自己进行投票
  • 发起RequestVote的RPC请求，要求其他的节点为自己投票
  • 如果得到半数以上节点的同意，就成为Leader（Leader）。
  • 如果选举超时，还没有Leader选出，则进入下一任期，重新选举。
• 限制条件
  • 每个节点在一个任期内，最多能给一个候选人投票，采用先到先服务原则
  • 如果没有投过票， 则对比candidate的log和当前节点的log哪个更新，比较方式为谁的lastLog的term越大谁越新，如果term相同，谁的lastLogindex越大谁越新。如果当前节点更新，则拒绝投票。

总结：首先比较任期，任期相同得话就比较log得index，如果申请成为leader得节点还没有收到投票得节点log索引高，则该节点会拒绝投票

日志复制

• Client向Leader提交指令（如：SET 5），Leader收到命令后，将命令追加到本地日志中。此时，这个命令处于“uncomitted”状态，复制状态机不会执行该命令。

  
  6.jpg

• Leader将命令（SET 5）并发复制给其他节点，并等待其他其他节点将命令写入到日志中，如果此时有些节点失败或者比较慢，Leader节点会一直重试，知道所有节点都保存了命令到日志中。之后Leader节点就提交命令（即被状态机执行命令，这里是：SET 5），并将结果返回给Client节点。

  
  7.jpg

• Leader节点在提交命令后，下一次的心跳包中就带有通知其他节点提交命令的消息，其他节点
  收到Leader的消息后，就将命令应用到状态机中（State Machine），最终每个节点的日志都保持了一致性。

  
  8.jpg

安全性

• 一个Candidate节点要成为赢得选举，就需要跟网络中大部分节点进行通信，这就意味着每一条已经提交的日志条目最少在其中一台服务器上出现。如果候选人的日志至少和大多数服务器上的日志一样新，那么它一定包含有全部的已经提交的日志条目。RequestVote RPC 实现了这个限制：这个RPC包括候选人的日志信息，如果它自己的日志比候选人的日志要新，那么它会拒绝候选人的投票请求。
• 最新判断标准
  • 如果两个日志的任期号不同，任期号大的日志内容更新
  • 如果任期号一样大，则根据日志中最后一个命令的索引（index），谁大谁最新

实例分析(脑裂)

这是一个网络隔离得案例,网络断了，导致集群分割完全无法相连，成了多个网络环境，这种情况被称为脑裂，而应对脑裂得方案，一般就是过半选举机制

1.jpg 2.jpg

网络隔离后会自动再重新选举，CDE一组AB一组，其中AB只有两个，例如B申请成为master，但是A和B都一样新(long index)所以拒绝给B投票，所以AB无法选举出master

3.jpg

最终C成为主节点

4.jpg 5.jpg

此时有写入指令，子网2没有主节点肯定无法写入，子网1写入成功

6.jpg

网络隔离解除，开始选举，但是AB得日志记录比较旧，依旧C是master

发生了网络分区或者网络通信故障，使得Leader不能访问大多数Follwers了，那么Leader只能正常更新它能访问的那些Follower服务器，而大多数的服务器Follower因为没有了Leader，他们重新选举一个候选者作为Leader，然后这个Leader作为代表于外界打交道，如果外界要求其添加新的日志，这个新的Leader就按上述步骤通知大多数Followers，如果这时网络故障修复了，那么原先的Leader就变成Follower，在失联阶段这个老Leader的任何更新都不能算commit，都回滚，接受新的Leader的新的更新。

发现原理

1.jpg

注册中心选型

2.jpg