raft是为了解决分布式系统各节点数据一致性的问题。
功能描述：主节点接受客户端的写请求，然后将数据以日志的形式发送给从节点。从节点按照日志顺序去更新数据库。保证每个节点的数据是一致的。 存在问题：1.主节点挂了，存储服务就不可用
raft共识算法
功能：增加选举功能，主节点挂了，可以通过共识算法，选举一个新的主节点，超过一半的节点同意就可以了。
2.主节点会定时发送心跳给从节点，这样表示自己的存活。
3.追随者没有收到主节点心跳，会发起选举，自己成为候选人，让其它节点投票。
4.选举不成功，也可能多个选举产生，但是每次选举的id会增加1，所以没有提交的选举，最终以id最大的为准，其它废弃，最终选举一个新的主节点；这里就是采用了paxos的核心思想。
5.追随者会参与投票；
6.旧的主节点恢复以后，发现id已经是旧的，则放弃自己的主节点身份，成为追随者。
Raft 适用于「强一致性需求 + 非恶意故障 + 中低延迟」的分布式场景，典型案例：
- 分布式配置中心（etcd、Consul）：存储全局统一配置，需确保所有节点读取到相同配置；
- 分布式数据库（TiDB、CockroachDB）：主从节点数据同步，主节点故障后快速切换；
- 主从选举（K8s Controller Manager、Elasticsearch Master）：确保同一时间仅存在一个主节点，避免逻辑冲突；
- 分布式锁（etcd 分布式锁）：通过日志一致性确保锁的唯一性，避免并发冲突。
2. 局限性
- 无法应对拜占庭故障：仅能容忍节点宕机、网络延迟等非恶意故障，若节点存在恶意篡改数据、伪造请求（如区块链中的恶意节点），需用 PBFT、PoS 等拜占庭容错算法；
- 性能开销：需多轮网络交互（选举、日志同步），延迟高于最终一致性算法（如 Gossip），不适合对实时性要求极高的场景（如高频交易）；
- 节点数量限制：节点数量越多，选举和日志同步的延迟越高，通常建议集群节点数为 3、5 或 7（奇数，便于多数投票）。
