一、为什么需要请求去重
考虑一次Append("name", "A")：
1. 客户端发送 Append 请求 2. Leader 将请求提交到 Raft 日志 3. KV 状态机执行成功，name 变成 "A" 4. 服务端返回响应 5. 但响应在网络中丢失 6. 客户端超时，重新发送同一个请求如果服务端无法识别重试，Append会再次执行：
第一次执行：name = "A" 第二次执行：name = "AA"客户端实际上只请求了一次，状态机却执行了两次，这会破坏客户端期望的语义。因此必须给每个逻辑请求一个唯一身份。
二、ClientId和CommandId分别是什么
图中每个客户端维护两个重要信息。
ClientId表示客户端身份，例如：
客户端A：ClientId = C1001 客户端B：ClientId = C2001项目中，Clerk创建时会生成客户端 ID，并将请求序号初始化为 0：
Clerk::Clerk() : m_clientId(Uuid()), m_requestId(0), m_recentLeaderId(0) {}CommandId在项目中叫RequestId，表示该客户端发出的第几个逻辑请求：
(C1001, 1) -> Put("x", "A") (C1001, 2) -> Append("x", "B") (C1001, 3) -> Get("x")每次产生一个新的逻辑请求时，客户端将m_requestId加一：
m_requestId++; auto requestId = m_requestId;三、为什么必须是二元组
唯一请求标识是：
(ClientId, RequestId)不能只使用ClientId，因为一个客户端会发送很多请求。
不能只使用RequestId，因为不同客户端都可能存在RequestId = 1：
(C1001, 1) (C2001, 1)这显然是两个不同请求。
因此，ClientId + RequestId共同构成一个类似“幂等键”的东西。
项目中的 Raft 命令Op包含这两个字段：
class Op { public: std::string Operation; std::string Key; std::string Value; std::string ClientId; int RequestId; };四、重试时 RequestId 不能增加
这是图中非常关键的一点。
新的逻辑请求才增加RequestId：
第一次业务操作：RequestId = 10 第二次业务操作：RequestId = 11同一个请求因为超时而重试时，必须继续使用原来的 ID：
发送请求：(C1001, 11) 超时重试：(C1001, 11) 再次重试：(C1001, 11)不能变成 12、13，否则服务端会认为它们是三个不同请求。
这个项目做得是对的：requestId在进入重试循环之前保存，循环中始终复用它：
m_requestId++; auto requestId = m_requestId; while (true) { args.set_requestid(requestId); // 向不同服务器重试 }五、服务端如何判断重复请求
每个 KV Server 保存：
std::unordered_map<std::string, int> m_lastRequestId;含义是：
ClientId -> 该客户端已经执行过的最大 RequestId例如：
C1001 -> 15 C2001 -> 8表示C1001的 1 到 15 号请求已经处理过。
判断重复请求的逻辑是：
return RequestId <= m_lastRequestId[ClientId];假设：
m_lastRequestId["C1001"] = 15那么：
请求 16：新请求，可以执行 请求 15：重复请求，不能再次执行 请求 14：旧请求，也不能再次执行这就是图中“只执行递增的 CommandId”的具体含义。
六、完整的丢包重试过程
客户端 C7 发送： (C7, 12, Append("x", "A")) Leader 写入 Raft 日志 ↓ 多数节点复制成功 ↓ 日志被提交 ↓ KV 状态机执行 Append ↓ lastRequestId[C7] = 12 ↓ 响应丢失 ↓ 客户端重试同一个 (C7, 12) ↓ 服务端发现 12 <= lastRequestId[C7] ↓ 不再执行 Append，直接返回成功项目在 Raft 提交命令后，调用ifRequestDuplicate()，只有非重复请求才操作 KV 数据：
if (!ifRequestDuplicate(op.ClientId, op.RequestId)) { if (op.Operation == "Put") { ExecutePutOpOnKVDB(op); } if (op.Operation == "Append") { ExecuteAppendOpOnKVDB(op); } }执行 KV 操作时还会更新：
m_lastRequestId[op.ClientId] = op.RequestId;KV 状态和去重信息在同一把互斥锁保护下更新，这一点很重要。
七、它与线性一致性的关系
线性一致性要求每个操作看起来都在某一个瞬间原子完成，而且不能违反真实时间顺序。
Raft主要解决：
所有节点按照相同的日志顺序执行命令请求去重解决：
客户端的一次逻辑操作，即使多次重试，也只产生一次状态变化二者缺一不可。
例如没有去重时，Raft可能完全正确地提交两条相同的Append日志。Raft不知道它们是同一次请求的重试，因为对 Raft 来说，它们只是两条合法命令。
所以更准确地说：
Raft提供一致的提交顺序，
ClientId + RequestId提供重试情况下的至多一次执行语义，二者共同支撑线性一致的客户端体验。
网络层无法真正保证消息“只发送一次”，这里只能保证重复消息不会导致状态机重复生效。