正文
2.3.2 Terms
在分布式环境下，“时间同步”一直都是老大难的技术难题。Raft为了解决这个问题，将时间划分为一个一个的Term(可以理解为“逻辑时间”)来处理在不同时间段里的数据一致性。
Terms有以下原则
1 每个Term中，至多存在一个Leader
2 某些Term中，有可能存在由于选举失败，没有Leader的情况
3 每个节点自己维护本地的currentTerm
4 每个Term都是一个连续递增的编号
5 如果Follower的Term编号比别的Follower Term编号小时，该Follower
Term编号将更新Term编号，以保持与其他Follower Term编号一致
2.3.3 选举
Raft的选举由定时器触发，每个节点的触发时间都不相同。
所有的节点在开始时状态都为Follower，当定时器触发选举后Term编号递增，该节点的状态由Follower转为Candidate，并且向其他节点发起RequestVote RPC请求，这时选举有3种情况可能发生：
1 发起RequestVote的节点收到n/2+1(过半数)个节点的投票，该节点将从Candidate状态变为Leader状态，开始向其他节点发送HeartBeat以保持Leader的正常状态
2 如果收到投票请求后，该节点发现发起投票的节点Term大于自己，则该节点状态从Candidate转为Follower，否则保持Candidate状态，并且拒绝该投票请求
3 选举期间发生了超时，则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 的机制，主要遵循的原则如下：
1 每个Term 只能选举一个Leader;
2 Leader的日志完整性，则当Candidate重新选举Leader时，新的Leader必须要包含先前已经commit的LOG;
3 Candidate在选举新的Leader时，使用Term来保证LOG的完整性;
以国产原厂的分布式数据库SequoiaDB为例，SequoiaDB在多副本的部署中，采用Raft算法保证数据在多副本环境中保持一致。
SequoiaDB集群中，总共包含3中角色节点，分别是协调节点、编目节点和数据节点。由于协调节点本身不存任何数据，所以只有编目节点和数据节点存在事务操作，换言之，编目分区组和数据分区组的副本同步采用Raft算法保证数据一致性。
3.1编目节点和数据节点的事务日志介绍
编目节点和数据节点由于都是需要存储数据的，并且在集群部署中该，为了确保数据的安全，都是建议采用分布式的方式进行部署，所以在数据同步中，需要采用Raft算法的基本原理进行数据同步。
编目节点和数据节点在存储数据时，共包含两大部分，一个真实的数据文件，另一个是事务日志文件。
SequoiaDB的节点事务日志，默认情况下由20个64MB(总大小为1.25GB)的文件构成。节点的事务日志主要包含一个index编号和数据操作内容，index编号保持永远递增状态。
另外，SequoiaDB节点的事务日志不会永久保存，而是当所有的事务日志写满后，再重新从第一个文件开始进行覆盖写入。
3.2编目分区组的数据一致性
由于编目分区组是保存SequoiaDB集群的元信息，数据同步要求高，所以编目分区组的数据一致性要求为强一致性，即每次向编目分区组执行事务操作时，必须要确保所有的编目节点操作成功，才计算该操作执行成功，否则该事务操作将在整个编目分区组中回退事务日志，以保证分区组内的数据一致性。
另外，编目分区组还有一个比较重要的特性，即编目分区组必须要存在主节点才能够正常工作，如果老的主节点宕机了，编目分区组暂时没有主节点，则该编目分区组不能够对外提供任何事务操作和数据查询操作。
3.3数据分区组的数据一致性
数据分区组的数据一致性默认情况下为最终一致性性，即只要求主节点执行事务操作成功即视为操作成功，主节点将在未来异步同步ReplicaLOG到从节点上。
3.4主从节点的事务日志同步
SequoiaDB的主从节点是通过事务日志同步来保证数据一致性的，并且主从节点的事务日志同步是单线程完成。
如果当主节点和从节点的LSN差距为一条记录，则主节点会主动将最新的事务日志推送给从节点。
如果主节点和从节点的LSN差距超过一条记录，则从节点会主动向主节点请求同步事务日志，主节点收到同步请求后，会将从节点的LSN号到主节点最新的LSN号对应的事务日志打包一次性发送给从节点。
3.5从节点日志重放
当从节点获取到主节点推送过来的事务日志后，就会自动解析事务日志和重放。从节点在重放事务日志时，默认情况下会以10并发来重放事务日志。
从节点在执行并发重放日志时有条件限制，即在集合的唯一索引个数<=1的情况下，INSERT、DELETE、UPDATE、LOB
WRITE、LOBUPDATE、LOB REMOVE操作可以支持并发重放事务日志。从节点在做并发重放时，是通过记录的OID进行打散并发执行，这样就可以保证对相同记录的操作不会由于并发重放导致数据不一致。
但是用户需要注意，从节点在重放事务日志时， DROP CL操作不能够支持并发重放。
目前SequoiaDB数据分区组的数据一致性是基于集合级别进行配置的。用户在使用SequoiaDB过程中，可以随时调整数据一致性的强度。
4.1 创建集合时指定
在一个多副本的SequoiaDB集群中，集合默认的数据一致性行级别为“最终一致性”。用户可以在创建集合时显式指定该集合的“数据一致性强度”，例如可以在SequoiaDB Shell中执行以下命令
