Etcd & Raft

发表于 | 更新于: | 分类于
字数统计: 1,827 | 阅读时长 ≈ 7

Etcd 简介

在笔者看来，Etcd就是一个用SDK访问的k-v存储。

官方介绍一句话，A distributed, reliable key-value store for the most critical data of a distributed system，翻译一下就是分布式系统重要的k-v数据用我准没错。

特性

  • 接口简单：可通过标准的http工具完成数据读写，使用json作为数据格式
  • k-v存储：使用有分级组织目录的方式存储数据，如文件系统一般
  • 变更监听：可以监听特定的Key / 目录的变更，可对值的更改作出反应
  • 可靠：可选SSL客户端证书作为身份鉴别
  • 性能：每个实例可支持10000次/s的写入
  • 时效性：可选地设置Key的存储超时
  • 一致性：通过Raft算法保证分布式部署下的数据一致性

Etcd 应用

数据存储

其高可用、强一致的特性，支持k-v数据的存储，不再赘述

服务发现

通过将Etcd作为注册中心，把服务名称与服务可用地址绑定，完成服务的注册和查找。

作用

  1. 保证分布式场景下，注册中心中服务目录强一致
  2. 通过Key过期机制，保持与服务间的心跳链接，监控服务健康状态
  3. 通过Proxy模式使得服务之间相互连接

分布式场景下的Master选举

可通过Etcd的事务操作( mini-transactions )完成多个服务器之间的抢主操作，实现Master服务器选举。由于Etcd能够保证强一致，因此，若对于某个key，如master_ip使用事务写，则可以保证所有服务器读取到的master_ip是一致的。而当master发生异常后，又可以通过超时机制，将master_ip淘汰，完成新master选举。

分布式并发控制

通过Etcd存储分布式信号量，完成分布式并发控制。同时，可以使用Etcd存储运行周期较长的任务数据，以便在机器故障，且需要导出执行状态时可恢复。

Etcd 总结

优势

  • 强一致性、性能较好、变更监听
  • 相比于zookeeper使用简单

劣势

  • 默认存储历史记录有限，因此更适合读多写少的场景，更新频繁会导致数据丢失

Raft 一致性算法

什么是一致性

一致性

一致性是对于可容错分布式系统必须解决的基础问题，需要多个服务器在对同一个数据的存储上保持一致，即对于集群中任何一台请求某个数据所返回的值都是一样的。经典的一致性算法需要保证只要集群中大多数服务器可用，那么就可以处理请求，也就是说，比如集群中有5台服务器，挂了2台仍可以处理请求。但是如果挂了2台以上，那么就不再处理请求，而绝不会返回错误的结果。

状态机 & Log

一致性算法通常的应用背景是在于复制状态机，同样也是构建一个可容错系统的常见方法。容错系统中，每个服务器有一个记录状态的结构，称为状态机；还有记录操作的log文件。状态机是构建容错系统的核心，并且从客户端看来，无论访问哪个服务器，即使集群中有少数服务器已经宕机，同一个请求获得的回复都是一致的。而对于每个状态机，它们都会从各自的log中获取输入命令。因此，一致性算法通常也是保证log的一致性，使得不同服务器之间有同样的操作命令序列，最终也就能实现状态机状态的一致。

算法流程

背景

可将背景设想为一个数据库服务器集群里面只存储了一个数，所有的请求都是对这个数据的操作。

概念

状态

对于集群中的服务器有以下三种状态：

  • 跟随者 Follower：一个任期中除了Leader以外的服务器，也是服务器的初始状态
  • 候选者 Candidate：任期超时后的Follower
  • 领导者 Leader：被大多数服务器认可的Candidate，所有来自客户端的请求都需通过打向Leader完成
记录 Entry

每个请求所代表的操作会以记录的形式在每个服务器的Log中保存

插入记录 Append Entries

Leader与Follower之间进行信息交互的数据结构

心跳 Heart beat

Leader会定时给所有Follower发送Append Entries，维系组织关系，保证所有Follower能感知Leader

选举 Election

通过选举，可在集群中选中一个对外交互的Leader服务器

选举超时 election timeout

每个follower服务器中有一个超时时间，用于等待成为candidate的时机，通常为150～300 ms。

流程

Leader 选举
  1. Follower选举超时后，状态变为Candidate，开启新的任期，准备任选（先给自己投一票…过于真实）
  2. Candidate发起对集群中其他服务器的投票邀请
  3. 收到邀请的服务器选举超时重置，满足以下条件对Candidate投票：
    • 当前任期内未投过票
    • Candidate的Log信息和我能够匹配
  4. 获取大多数服务器投票后，Candidate变成Leader，否则等待下一轮选举超时，直到最终选出Leader
  5. 选举成功后Leader同步心跳
日志复制 Log Replication

请求打到Leader上时，发生如下过程，完成一次日志的复制：

  1. Leader的log中写入一条记录，标记为未提交状态
  2. 下一次心跳时，向所有follower同步未提交的记录
  3. Leader等到大多数follower响应，Leader将操作记录提交，返回client请求
  4. 下一次心跳时，同步提交的记录，使得所有follow也提交本次操作
算法流程

首先经过Leader选举，在集群中选举出对外交互的Leader。Leader收到操作请求后，完成日志复制，使得集群Log一致。

发生网络故障导致脑裂时，由于过程中的操作存在“大多数”原则，因此只有大多数的请求会被响应。故障排除后，通过较高任期选举出的Leader心跳，数据就会再度同步，而之前未提交的请求则会被丢弃，集群再次达到一致状态

Raft 总结

优势

  • 相对于更早的Paxos算法易理解、易实现
  • 性能较高，只需要大多数Follower同步即可写入
  • 强调Leader的唯一性，保证了强一致性

缺点

  • 协议限制了只能有序提交，并且强调集群中只能有一个group

其他一致性协议

两阶段提交协议、三阶段提交协议、向量时钟RWN协议、Paxos协议、ZAB 算法、PBFT 算法

参考

参考资料

Etcd 官网：https://etcd.io/

Etcd repo：https://github.com/etcd-io/etcd

Etcd介绍的博客：http://blog.itpub.net/69953029/viewspace-2667738/

Raft 一致性算法图解：https://raft.github.io/

其他分布式协议：https://blog.csdn.net/chdhust/article/details/52651741

0%