The problem of the separation of truncate and append operation

[jintianfan]

raft论文中，Figure 8图展示了一种即使满足多数节点数据复制，仍然可能被覆盖的场景。
To eliminate problems like the one in Figure 8, Raft never commits log entries from previous terms by counting replicas. Only log entries from the leader’s current term are committed by counting replicas; once an entry from the current term has been committed in this way, then all prior entries are committed indirectly because of the Log Matching Property. There are some situations where a leader could safely conclude that an older log entry is committed (for example, if that entry is stored on every server), but Raft takes a more conservative approach for simplicity。
我看到dledger实现中truncate和append是分开的，是否会破坏匹配规则。

[dongeforever]

@jintianfan Raft 论文中出现 “Figure 8”的场景是因为选举时，日志高度用的是 ComittedIndex，而DLedger 用的是 endIndex（也即当前日志高度，包含所有已经 Committed 的 Entry，可能包含部分未 Committed Entry），详情参考 DLedgerLeaderElector 的 handleVote 方法。
在这种选举标准下， “Figure 8” 中的 S5 是不可能被选为 Leader 的，而一旦一个 Entry 被复制到了 a majority of servers， 则永远不会被覆盖。

[dongeforever]

@jintianfan Truncate 是在与 当前 Leader 进行比对之后进行操作的。假设选举是可靠的，那么当前 Leader 就包含了所有有效的 Entry，作为 Follower，与当前 Leader 不一致的 Entry 都应该被丢弃，然后与Leader对齐。

[watchpoints]

@dongeforever 根据endIndex最打选择领导，
假如 一个客户端发起请求请求，三个主机 A (Leader),B(Follower), C（Follower），
Committed 只提交了 A,B ，但是主机C 没有提交，

1 在领导选举，节点B 选择新领导，在同任期情况下，针对此时Committed索引，可以复制到其他节点过充中，
因为是标记commited了，是否还需要继续地业务进行判断

（从客户端角度来说），业务返回成功，还是失败呢？

问题是:对于刚刚标记commited B（只复制A B,C没有请看下），复制到其他节点过（c）中，是否还考虑对业务返回操作成功（发现切换情况下）？
因为标记commited，不清楚是全部写入，还是部分写入