ouyangyiwen的博客

Log persist是将raft的Log、currentTerm和voterfor这三个数据持久化存储在磁盘里，这样当系统崩溃时，我们能从磁盘中读取持久化的数据。在本文的实现中，因为是在一台电脑中通过网络模拟了分布式场景。所以，本文是通过Go的bytes.buffer实现持久化存储。一. bytes.bufferbytes.buffer是一个缓冲byte类型的缓冲器，其存放数据都是byte。而buffer是bytes中的一个type buffer struct{}。其是一个变长的buffer，..

一. 参考paper对于raft协议 《In Search of an Understandable Consensus Algorithm (Extended Version)》一文做了非常细致且严谨的论述，且对如何实现也做了非常细致的指导，兼具学术与工程，强烈推荐直接阅读英文原文，另MIT6.824课程的Robert Morris教授对其做了非常细致的讲解。英文原文：https://pdos.csail.mit.edu/6.824/papers/raft-extended.pdf中文译文：h

在raft论文中，有且仅有三个数据需要持久化存储，分别是Log、currentTerm和votefor。对于Log我们能够很好的理解，因为其记录了应用程序的状态。当服务重启时，我们能通存储的Log重建应用程序的状态。那为什么必须存储currentTerm和votefor呢？还有为什么仅仅只需存储这三个数据？一. 为什么必须存储currentTerm和votefor?1.1为什么存储voterfor？保证每个任期最多只有一个Leader！考虑如下一种场景：因为在raft协议中每个任期内..

一. 问题背景在raft协议中，Leader使所有的follower的log与其保持一致，出现不一致的情况时，Leader就会改动follower的日志。其实现保持一致原理为：每个Leader会为每个follower维护一个nextIndex，其初始值为每个新任Leader的最后一条日志的下一条日志Index。并且，Leader向follower发现的广播消息中，包含了一prevLogIndex、prevLogTerm，并且preLogIndex = nextIndex -1、preLogTer

一. 问题背景在raft协议的运行中，可能会由于网络故障、机器故障等等原因使先前的Leader挂掉。而raft有一个timeout机制，即如果follower超过timeout时间没有收到来自Leader的广播，便会成为Candidate开始选举试图成为Leader。1.1 Leader选举Leader选举的流程如代码所示，首先执行Candidate逻辑，决定哪个raft节点成为Candidatem，并通过随机时间机制保证每个时间点有劲仅有一个节点成为Candidate；然后，Candida