[etcd] Raft理论学习（五）（客户端交互）

8 Client interaction

This section describes how clients interact with Raft, including how clients find the cluster leader and how Raft supports linearizable semantics [10]. These issues apply to all consensus-based systems, and Raft’s solutions are similar to other systems.

8客户端交互

本节描述客户端如何与Raft交互，包括客户端如何找到集群领导者以及Raft如何支持线性化语义[10]。这些问题适用于所有基于共识的系统，并且Raft的解决方案与其他系统类似。

Clients of Raft send all of their requests to the leader. When a client first starts up, it connects to a randomlychosen
server. If the client’s first choice is not the leader, that server will reject the client’s request and supply information
about the most recent leader it has heard from (AppendEntries requests include the network address of the leader). If the leader crashes, client requests will time out; clients then try again with randomly-chosen servers.

Raft的客户将所有请求发送给领导者。客户端第一次启动时，它会连接到随机选择的 服务器。如果客户的首选不是领导者，则该服务器将拒绝客户的请求并提供信息 关于最近听到的领导者的消息（AppendEntries请求包括该领导者的网络地址）。如果领导者崩溃，客户请求将超时。客户端，然后使用随机选择的服务器重试。

Our goal for Raft is to implement linearizable semantics (each operation appears to execute instantaneously,
exactly once, at some point between its invocation and its response). However, as described so far Raft can execute
a command multiple times: for example, if the leader crashes after committing the log entry but before responding
to the client, the client will retry the command with a new leader, causing it to be executed a second time. The
solution is for clients to assign unique serial numbers to every command. Then, the state machine tracks the latest
serial number processed for each client, along with the associated response. If it receives a command whose serial
number has already been executed, it responds immediately without re-executing the request.

我们对Raft的目标是实现线性化语义（每个操作似乎都是立即执行的， 在调用和响应之间的某个时间点仅一次）。但是，到目前为止，Raft可以执行 一个命令多次：例如，如果领导者在提交日志条目之后但在响应之前崩溃了 对于客户端，客户端将使用新的领导者重试该命令，从而使其第二次执行。的 解决方案是让客户端为每个命令分配唯一的序列号。然后，状态机跟踪最新 为每个客户端处理的序列号以及相关的响应。如果收到命令的序列号 数字已经执行，它会立即响应而无需重新执行该请求。

Read-only operations can be handled without writing anything into the log. However, with no additional measures,
this would run the risk of returning stale data, since the leader responding to the request might have been superseded
by a newer leader of which it is unaware. Linearizable reads must not return stale data, and Raft needs two extra precautions to guarantee this without using the log. First, a leader must have the latest information on which entries are committed. The Leader Completeness Property guarantees that a leader has all committed entries, but at the start of its term, it may not know which those are. To find out, it needs to commit an entry from its term. Raft handles this by having each leader commit
a blank no-op entry into the log at the start of its term. Second, a leader must check whether it has been deposed
before processing a read-only request (its information may be stale if a more recent leader has been elected).
Raft handles this by having the leader exchange heartbeat messages with a majority of the cluster before responding
to read-only requests. Alternatively, the leader could rely on the heartbeat mechanism to provide a form
of lease [9], but this would rely on timing for safety (it assumes bounded clock skew).

可以执行只读操作，而无需在日志中写入任何内容。但是，如果没有其他措施， 这将带来返回陈旧数据的风险，因为响应请求的领导者可能已被取代 由一个不知道的新领导。可线性化的读取操作一定不能返回陈旧的数据，并且Raft需要采取两项额外的预防措施来保证不使用日志就可以做到这一点。首先，领导者必须掌握提交条目的最新信息。领导者完整性属性可以保证领导者拥有所有已提交的条目，但是在任期开始之初，它可能不知道这些是谁。为了找出答案，它需要从其术语中提交一个条目。筏通过让每个领导者来处理这个问题 日志开始时在日志中有一个空白的no-op条目。其次，领导者必须检查它是否已被废除 在处理只读请求之前（如果已经选择了新的领导者，其信息可能会过时）。 Raft通过使领导者在响应之前与大多数集群交换心跳消息来处理此问题 只读请求。或者，领导者可以依靠心跳机制来提供表格 租约[9]，但这将取决于时序的安全性（它假设时钟有偏斜）。