Raft 共识算法通过一系列的机制来确保系统的安全性，包括领导者选举、日志复制和日志同步等方面。以下是 Raft 算法保证安全性的一些关键机制：
- 领导者选举：Raft 确保只有一个活跃的领导者，从而防止出现分裂的情况。在选举过程中，候选者必须获得大多数节点的选票才能成为领导者，这就要求任何一个节点成为领导者，必须拥有多数节点的支持。这样可以防止多个领导者同时存在，从而保证系统的一致性。
- 日志复制和同步：Raft 确保领导者的日志是其他节点所接受的，从而确保数据的一致性。领导者负责将新的日志条目追加到其自己的日志中，并通过心跳信号通知跟随者。跟随者在收到心跳信号时响应，并将领导者的日志复制到自己的日志中，确保跟随者和领导者的日志一致。
- 持久化：Raft 节点需要将其状态持久化到稳定的存储介质，以防止数据丢失。这包括持久化节点的当前任期（term）、已提交的日志索引和日志条目等信息。这确保了即使节点故障或重启，它们仍然能够从之前的状态继续运行，而不会丢失数据。
- 日志一致性：Raft 确保所有的日志条目按照相同的顺序在各个节点之间复制和应用。领导者会等待多数节点确认已经复制了特定的日志条目，然后再将该条目标记为已提交。这确保了所有节点在相同的日志顺序上达成一致。
总之，Raft 算法的设计目标之一就是确保系统在各种情况下的安全性和可靠性。通过领导者选举、日志复制、持久化和日志一致性等机制，Raft 算法能够应对节点故障、网络分区和其他异常情况，保障系统的数据一致性和正确性。
Election restriction
在任何基于领导者的共识算法中，领导者最终必须存储所有提交的日志条目。在一些共识算法中，如Viewstamped Replication[22]，即使leader最初不包含所有提交的条目，也可以被选举出来。这些算法包含额外的机制来识别丢失的条目，并在选举过程中或之后不久将它们传送给新的领导者。不幸的是，这会导致相当多的额外机制和复杂性。Raft使用了一种更简单的方法，它保证所有来自前任期的承诺条目在每个新的leader选举时就存在，而不需要将这些条目转移到leader。这意味着日志条目只向一个方向流动，从领导者到追随者，领导者不会覆盖其日志中已有的条目。
Raft使用投票过程来阻止候选人赢得选举，除非它的日志包含所有提交的条目。候选人必须联系集群的大多数成员才能当选，这意味着每个提交的条目必须至少出现在其中一个服务器中。如果候选者的日志至少与多数票中的任何其他日志一样是最新的(下面精确地定义了“最新的”)，那么它将保存所有提交的条目。RequestVote RPC实现了这个限制:RPC包含关于候选人日志的信息，如果投票者自己的日志比候选人的日志更最新，那么他就拒绝投票。
Raft通过比较日志中最后一个条目的索引和项来确定两个日志中哪个更为最新。如果日志的最后一个条目具有不同的任期，则具有较大的任期的日志更为最新。如果日志以相同的任期结尾，则以较长的日志为准。
Committing entries from previous terms
如第5.3节所述，leader知道，一旦当前任期中的条目存储在大多数服务器上，就会提交该条目。如果一个领导者在提交一个条目之前崩溃，那么未来的领导者将尝试完成对该条目的复制。然而，一个领导者不能立即断定上一个任期中的条目是否被提交了，即使日志条目存储在大多数服务器上。图8说明了一种情况，旧的日志条目存储在大多数服务器上，但仍然可以被未来的领导者覆盖。（不能认为一个日志条目复制到了大多数节点就认为日志已经提交了，因为这样的日志条目可能被覆盖，再次回顾日志提交的含义：日志能够安全的应用于状态机，很显然，被覆盖的日志条目不能安全地应用于状态机，也就是没有提交，虽然被复制到了大多数节点上。这样说明了一点：日志条目被复制到大多数节点和日志条目提交是两个事情。日志条目被复制到大多数节点不能推导出日志已经提交，日志已经提交能推导出日志条目复制到了大多数节点。）
