Raft是当前分布式领域最重要的一致性算法之一，今天我们就来好好研究研究这个算法的论文, 还有对应网站, 动画, 不想看英文的也有中文的翻译，所以我这边就不翻译了，主要还是记录一下论文重点和自己的心得。

Raft算法作者的初衷是对标Paxos算法（过去十年分布式一致性的事实标准），但是要比它更易理解，主要手段有：

1. 分解，把整个一致性问题拆分为Leader选举、日志复制和安全机制这三大方面还有角色改变这个小方面。所以模块化是一个软件系统可维护、理解和扩展的不二手段。
2. 减少状态空间的状态，相比于Paxos，Raft减少了非确定性和服务器之间可以处于不一致的方式。所以在复杂的问题上做减法，可以减少很多不必要的繁琐的步骤。

Raft使用了更强的Leader，感觉这和我之前看的OceanBase是相似的，就是增强Leader（UpdateServer）或者说单点的作用，加重中心化（这也是社会的运作方式，没有Leader就是大家一盘散沙，文明是达不到今天这个程度的），要做决策就先选择一个Leader，然后让他去协调所有的决议，会更加简单快速，而Paxos就是P2P或者说弱Leader的方式。事实上，我们之所以使用分布式系统也是迫不得已，如果单台机器能搞定还要这么多系统干嘛？所以我们也要看到单点系统的好处，那就是一致性很容易保证，所以在分布式系统中使用一个增强（能力和责任）的单点既利于一致性的保证也能获得分布式的优势。

David John Wheeler有一句名言“计算机科学中的任何问题都可以通过加上一层间接层来解决”，一层不够就再加一层。后半句是我加的 (*￣︶￣) ，虽然有点玩笑的意思，但是也的确能说明一些问题。计算机科学的确是靠着一层又一层的抽象与封装解决了巨量的问题。

我们来简单回顾一下：
开始的时候是程序员直接输入二进制指令来操纵硬件的，不仅性能低下还很耗费用户时间；
于是后来出现了操作系统，用文件、进程与线程、地址空间抽象了磁盘、CPU与内存，统一和简化了硬件访问方式；
机器语言对用户不友好，于是便出现了汇编语言、中级语言（如C）、高级语言（如Java）的包装，其最终执行还是要转化为机器语言；
裸高级语言大家还用得不爽，觉得开发效率低，于是又出现了各种框架（如Spring、Hibernate）
......

这样一层一层抽象包装下来，我们要想实现一个功能比如定时写文件等已经变成了很简单的事，只需要几行代码就搞定了。
但是抽象层数过多就会导致我们顶层的用户有时候会出现一些莫名其妙的问题，我们用一个实际的案例伪共享来说明一下

我们知道java在运行的时候有两个地方可能用到重排序，一个是编译器编译的的时候，一个是处理器运行的时候。
那么我们就应该问问为啥要用指令重排序呢？

生活类比

我们从生活中举个例子，假设你有一箱红纸，现在要你剪成小红花贴在窗上。你有两种极端的选择：拿出来一个，把这个剪好，再贴上去......一个一个依次进行；另一种方式是先全部拿出来，然后全部剪好，最后全部贴上去。

那种效率更高？很明显是后者，因为前者你就需要不停地在箱子，剪刀和胶水之间切换，这个切换过程不仅浪费时间，还耗费精力。但是后者一直做一个工作也很无聊，还会导致半天了窗上一朵花都没有，会给你带来失落感，所以比较合适的做法就是拿出来一叠，把这一叠剪好，贴上去。这样既不无聊，也减少了切换次数，提高了工作效率。

再想想，如果有三个人，一个负责拿，一个负责剪，一个负责贴，就更快了。

我之前在一片文章 用Nginx+Redis实现session共享的均衡负载 中做了一个负载均衡的实验，其主要架构如下：

把debian1作为调度服务器承担请求分发的任务，即用户访问的是debian1，然后debain1把请求按照一定的策略发送给应用服务器：debian2或者debain3，甚至更多的debain4、5、6......

状态和数据可以放在外部的分布式缓存服务和分布式数据库服务中，这样应用服务本身就是无状态的，所以机器增减都是很容易的，应用的高可用是有保证的（对于有状态的高可用不仅要注意机器增减与切换、还要注意备份冗余、数据一致性等问题）。但是当时忽略了一个地方，那就是调度服务器debian1本身的高可用性没有考虑到，存在单点问题。

高可用的首要想法就是双机热备，故障时自动切换，所以我们要给debian1加一个备机debain1'。我现在按照自己的知识粗浅的把解决方案分为两类：客户端有感知的高可用、对客户端透明的高可用，并分别挑选一个示例做一下实验。

注：下面实现高可用都用的是双机热备，为了方便，把调度服务器debian1简称为主机，把调度服务器debian1的备机debian1'简称为备机。

Consistent Hashing based Key-Value Memory Storage

基于一致性哈希的分布式内存键值存储——CHKV。
目前的定位就是作为 Cache，DataBase 的功能先不考虑。

系统设计

• NameNode : 维护 DataNode节点 列表，用心跳检测 DataNode（一般被动，被动失效时主动询问三次），节点增减等系统信息变化时调整数据并通知 Client；
• DataNode : 存储具体的数据，向 NameNode 主动发起心跳并采用请求响应的方式来实现上下线，便于 NameNode 发起挪动数据指令，实际挪动操作由 DataNode 自行完成；
• Client : 负责向 NameNode 请求 DataNode 相关信息并监听其变化，操纵数据时直接向对应 DataNode 发起请求就行，
  目前支持set,get,delete,keys,expire几个操作；

NameNode 失效则整个系统不可用。

若当成内存数据库使用，则要注意持久化，而且只要有一个 DataNode 失效（未经请求与数据转移就下线了）整个系统就不可对外服务；
若当成内存缓存使用，则 DataNode 失效只是失去了一部分缓存，系统仍然可用。

DataNode 失效（未经请求与数据转移就断开了和 NameNode 的连接）则 NameNode 需要及时通知 Client。

客户 要使用 CHKV 就必须使用 Client 库或者自己依据协议（兼容redis）实现，可以是多种语言的API。
当然也可以把 Client 当做 Proxy，使得 CHKV 内部结构对 客户 透明，亦即有如下两种方式：