关于Raft算法自动提交旧日志的疑问

[mygaochunming]

根据这里的描述，那个2在开始的时候没有被提交，在后面被自动提交
站在客户端的角度，在开始的时候，那个2没有被提交，那么客户端是不是就认为是失败了。后来又自动被被提交了，那客户端也不知道啊，会不会造成“安全性”问题？
比如说，你从账户里扣了10块钱，开始的时候没成功。你又从账户里扣20块钱，成功了。后面查看账户被扣了30块钱。

难道这需要在客户端实现的时候自己来处理？比如客户端没有收到成功的标识可以重复发送命令，如果一段时间后确实不成功就告诉分布式系统这个日志我已经反馈给“最终用户”失败了，你们要确保它不成功。

[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的状态，就知道上次操作是否成功了。