标签：Leader Follower Raft 一致性 raft 节点 分布式
分布式数据库的数据一致性管理是其最重要的内核技术之一，也是保证分布式数据库满足数据库最基本的ACID特性中的 “一致性”(Consistency)的保障。在分布式技术发展下，数据一致性的解决方法和技术也在不断的演进，本文就以作者实际研发的分布式数据库作为案例，介绍分布式数据库数据一致性的原理以及实际实现。
1.数据一致性
1.1数据一致性是什么
大部份使用传统关系型数据库的DBA在看到“数据一致性”时，***反应可能都是数据在跨表事务中的数据一致性场景。但是本文介绍的“数据一致性”，指的是“数据在多份副本中存储时，如何保障数据的一致性”场景。
1.2关系型数据库如何保障数据一致性
传统的关系型数据库对于运行环境–硬件要求都比较高，例如Oracle会建议用户使用小型机+共享存储作为数据库的运行环境，DB2 DPF也同样建议用户采用更好的服务器+高端存储来搭建数据库的运行环境。所以在数据存储安全的技术要求下，传统关系型数据库更多是依赖硬件的技术来保障数据的安全性。
因为关系型数据库的数据安全是基于硬件来保障，并且数据也不会通过同时存储多份来保障数据的安全，所以关系型数据库的用户默认认为数据存储是一致的。
1.3分布式存储如何保障数据一致性
本文在讨论分布式存储时，主要指的是大数据产品中的分布式文件系统和分布式数据库，例如：SequoiaDB和HDFS。
用户在搞明白分布式存储的数据一致性原理时，必须要先明白为什么他们就需要数据一致性，和分布式存储的数据存储与关系型数据库的数据存储又有什么区别。
大数据技术的诞生，确确实实让系统的性能有新的突破，并且支持硬件以水平扩展的方式来获得线性增长的性能和存储。这些都是过去传统关系型数据库所无法提供的。另外，大数据技术也抛弃了运行环境必须足够好的硬性要求，而是允许用户通过批量廉价X86服务器+本地磁盘的方式搭建规模集群，从而获得比过去依赖硬件垂直扩展所提供的更强的计算能力和更多的存储空间。
大数据技术的核心思想就是分布式，将一个大的工作任务分解成多个小任务，然后通过分布式并发操作的方式将其完成，从而提高整个系统的计算效率或者是存储能力。而在分布式环境下，由于硬件的要求降低，必然需要大数据产品提供另外一个重要的功能–数据安全。
大数据产品在解决数据安全的方式上，都比较接近，简单来说，就是让一份数据通过异步或者同步的方式保存在多台机器上，从而保障数据的安全。
分布式存储在解决数据安全的技术难点后，又引入了一个新的技术问题，就是如何保障多个副本中的数据一致性。目前SequoiaDB是使用Raft算法来保证数据在多个副本中一致性。
2.Raft算法
2.1Raft算法背景
在分布式环境下，***的一致性算法应该是Paxos算法，但是由于它实在过于晦涩难懂，并且实现起来极度困难，所以在2013年，Diego Ongaro、John Ousterhout两个人以易懂(Understandability)为目标设计了一套一致性算法Raft。Raft算法***的特点在于简单易懂，并且实现起来简单。
2.2Raft算法概述
与Paxos不同，Raft强调的是易懂，Raft和Paxos一样只要保证n/2+1节点正常就能够提供服务。
众所周知当问题较为复杂时可以把问题分解为几个小问题来处理，Raft也使用了分而治之的思想。Raft算法重点解决三个子问题：选举(Leader election)、日志复制(Log replication)、安全性(Safety)。
Raft算法强化了Leader节点的功能，Follower节点的数据只能够从Leader中获取，所以Follower节点的实现就变得简单，只要负责和Leader保持通信，并且接受Leader推送的数据即可。
2.3Raft算法原理
2.3.1 节点角色
Raft算法中，对节点的状态分为3种角色，分别是Leader(***)、Follower(追随者)和Candidate(候选者)。
Leader，负责处理来自客户端的请求，负责将日志同步到Follower中，并且保证与Follower之间的heartBeat联系;
Follower，当集群刚刚启动时，所有节点均为Follower状态，它的工作主要为响应Leader的日志同步请求，响应Candidate的请求，以及把请求到Follower的事务请求转发给Leader;
Candidate，选举Leader时负责投票，选举出来Leader后，节点将从Candidate状态变为Leader状态。
2.3.2 Terms
在分布式环境下，“时间同步”一直都是老大难的技术难题。Raft为了解决这个问题，将时间划分为一个一个的Term(可以理解为“逻辑时间”)来处理在不同时间段里的数据一致性。
Terms有以下原则
- 每个Term中，至多存在一个Leader
- 某些Term中，有可能存在由于选举失败，没有Leader的情况
- 每个节点自己维护本地的currentTerm
- 每个Term都是一个连续递增的编号
- 如果Follower的Term编号比别的Follower Term编号小时，该Follower Term编号将更新Term编号，以保持与其他Follower Term编号一致。
2.3.3 选举
Raft的选举由定时器触发，每个节点的触发时间都不相同。
所有的节点在开始时状态都为Follower，当定时器触发选举后Term编号递增，该节点的状态由Follower转为Candidate，并且向其他节点发起RequestVote RPC(请求投票的远程 Procedure Call Protocol)请求，这时选举有3种情况可能发生：
发起RequestVote的节点收到n/2+1(过半数)个节点的投票，该节点将从Candidate状态变为Leader状态，开始向其他节点发送HeartBeat以保持Leader的正常状态
如果收到投票请求后，该节点发现发起投票的节点Term大于自己，则该节点状态从Candidate转为Follower，否则保持Candidate状态，并且拒绝该投票请求
选举期间发生了超时，则Term编号递增，重新发起选举.
2.3.4 日志复制
日志复制主要的作用就是用来保证节点的数据一致性与高可用性。
当Leader被选举出来后，所有的事务操作都必须要经过Leader处理。这些事务操作成功后，将会被按顺序写入到LOG中，每个LOG都包含一个index编号。
Leader在LOG发生变化后，通过HeartBeat将新的LOG同步到Follower上，Follower在接收到LOG后，再向Leader发送ACK信息，当Leader接到大多数(2/n+1)Follower的ACK信息后，将该LOG设置为已提交，并且Leader将LOG追加到本地磁盘中。
同时Leader将在下一个HeartBeat中，通知所有的Follower将该LOG存储在各自的本地磁盘中。
2.3.5 安全性
安全性是用于确保每个节点都是按照相同的日志序列进行执行的安全机制。
如果当某个Follower在同步Leader的日志时失败，但是未来该Follower又可能被选举为Leader时，就有可能导致前一个Leader已经commit的日志发生覆盖，这样就导致了节点执行不同序列的日志。
Raft的安全性就是用于保证选举出来的Leader一定包含先前已经commit LOG 的机制，主要遵循的原则如下：
每个Term 只能选举一个Leader;
Leader的日志完整性，则当Candidate重新选举Leader时，新的Leader必须要包含先前已经commit的LOG;
Candidate在选举新的Leader时，使用Term来保证LOG的完整。
3.分布式数据库数据一致性技术实现
以国产原厂的分布式数据库SequoiaDB为例，SequoiaDB在多副本的部署中，采用Raft算法保证数据在多副本环境中保持一致。
SequoiaDB集群中，总共包含3中角色节点，分别是协调节点、编目节点和数据节点。由于协调节点本身不存任何数据，所以只有编目节点和数据节点存在事务操作，换言之，编目分区组和数据分区组的副本同步采用Raft算法保证数据一致性。
更多的详见：https://database.51cto.com/art/201710/554743.htm
想飞的IT猪
发布了120 篇原创文章 · 获赞 24 · 访问量 6万+
私信
关注
标签：Leader,Follower,Raft,一致性,raft,节点,分布式 来源： https://blog.csdn.net/woainilixuhao/article/details/104440279
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。