Hdfs3的纠删码机制，通过矩阵运算分块存储，任意部分丢失，都可以用其他的部分计算得出。是典型的网络io+cpu计算 换 存储空间的做法。

对Redis的主从复制知道一些，所以抛砖引玉说一下。Redis有两种复制方法，一种是复制指令流，Redis将写操作记录在一个环形的内存buffer中，然后将buffer中的指令异步同步到从库，从库也会告诉主库自己同步的buffer位置。当网络阻塞严重时，有可能存在没有同步的buffer被覆盖掉，这样会导致数据丢失，Redis就会采用快照同步的方式。将主库的所有key生成一个快照同步给从库，然后再继续从buffer同步。

异步复制可以做到1个RTT的处理时间,但是主节点如果crash,未同步的数据就没了。NSDI今年有篇《Exploiting Commutativity For Practical Fast Replication》，这篇论文很有意思，有兴趣的可以看一下。

给的例子是不是有问题，还是我理解有问题
比如，对于变量 X，Leader 节点记录的操作是{(Index 1, X = 1, Version:0), (Index 2, X=2, Version:1), (Index3 , X=3, Version:2)}，其中，Follower 节点 2 记录的操作为{(Index 2, X=1, Version:0)

这里Follower 节点 2 不应该是{(Index 1, X=1, Version:0) 吗？为什么例子是 {(Index 2, X=1, Version:0)

MySQL的主备之间的同步不是通过binary log吗？那和这里的raft算法有关系吗？没有看太懂？
还有本节的数据复制来保证一致性，和之前几节的超过半数节点同意选主的那种一致性是一回事吗？本质都是数据一致性吗？

好文，最后的raft算法部分没看明白，再看。

我之前了解过一些中间件的复制策略，对比今天的内容，又有更深入的认识了。