关于Raft算法自动提交旧日志的疑问 about raft-zh_cn

[mygaochunming]

这里的情况，不管怎么说都是告诉客户端成功或者失败，失败了客户端可以重试，客户端得到了“正确”的反馈。上面的情况，客户端被告知失败了，可是后面又“被”成功了！感觉像幽灵一样！

除非出现“被”提交的情况下，客户端没有得到成功的反馈，会不断的重试。假设重试有一次肯定会成功，那么就跟“客户端”重试的效果是一样的。状态机在处理的时候因为前面这个序列号的指令已经被执行了，不会重复执行。

[mygaochunming]

包括multi paxos，都有这种“幽灵”情况，是不是分布式存储不用考虑这些情况，只需要保证所有节点在同一个位置存储相同的值就行。

[maemual]

@mygaochunming 实际生产可用的 raft 库是怎么实现的我没有仔细研究过，按照我做 mit 6.824 里面实现的简单版本的 raft 协议来看，实际的客户端-服务端的交互方式不是 request-response 的模式。

6.824 里面的方式是，客户端提交了一个需要达成的共识命令 A 给 raft 的服务端，然后就立即返回了。然后客户端会有另外的一个 channel 监听来自 raft 服务端的指令，会对外传出已经达成共识的命令 A 出来。

[He-XiaoLong]

---

我的理解：作为客户端是要去保证操作的安全性的。当客户端向数据库(比如mysql)发送一系列操作后，这时候客户端只能收到两种情况：成功或者失败。对于失败情况，又可能是由很多原因引起的，但总体上分为两种。第一种是数据库操作已经成功，但由于网络等原因返回失败，此时客户端并不能仅仅就以操作失败重试处理。对于第二种可能数据库操作失败，那么一般会返回错误码，客户端会根据不同的错误码进行处理。这种处理在基于raft 协议实现的分布式存储系统中是一样的。raft保证在能够提高正常服务时所有被commit的log是能够被客户端感知到的（需要等到apply到状态机）。

@mygaochunming 在你举的例子，当2开始没有commit，后续又被commit中。 客户端需要做如下处理，当开始操作生成2时，应该会被返回超时。当2被写入多数派但还没commit时，这时客户端去查询2的状态，此时数据库应该是处于不可访问的状态。当2被commit后，客户端再去查询2的状态，就能够查询到2的状态，就知道上次操作是否成功了。