Cockroach Design 翻译 ( 六) 混合逻辑时钟、事务执行流程

7  Hybrid Logical Clock混合逻辑时钟

Eachcockroach node maintains a hybrid logical clock (HLC) as discussed in the Hybrid Logical Clock paper. HLC time usestimestamps which are
composed of a physical component(thought of as and always close to local wall time) and a logical component(used to distinguish between events with the same physical component). Itallows us to track causality for related events
similar
to vector clocks,but with less overhead. In practice, it works much like other logical clocks:When
events are received by a node, it informs the local HLC about thetimestamp supplied with the event by the sender, and when events are sent atimestamp generated by the local HLC is attached.

每个Cockroach节点都维持了一个混合逻辑时钟(HLC)
，相关的论文见 HybridLogical Clock paper。HLC时间使用的时间戳由一个物理部件（看作总是接近本地物理时钟）和一个逻辑部件（用于区分相同物理部件上的事件）组成。它使我们能够以较少的开销跟踪相关联事件的因果性，类似于向量时钟（译注：vector
clock，可参考Leslie Lamport在1978年发表的一篇论文《Time,
Clocks, and the Ordering of Events in aDistributed System》）。在实践中，它工作起来更像一个逻辑时钟：当一个节点收到事件时，它通知本地逻辑HLC由发送者提供的事件时间戳，而当事件被发送时会附加一个由本地HLC生成的时间戳。

For a more in depth description of HLC please read thepaper. Our implementation is here.

关于混合逻辑时钟(HLC)更深入的描述请阅读相关论文。我们的实现源码见这里。

Cockroachpicks a Timestamp for a transaction using HLC time. Throughout thisdocument, timestamp always refers to the HLC time which is asingleton on each node. The HLC is updated by every read/write event on thenode, and the HLC time >= wall time.
A read/write timestamp received in acockroach request from another node is not only used to version the operation,but also updates the HLC on the node. This is useful in guaranteeing that alldata read/written on a node is at a timestamp < next HLC time.

Cockroach使用HLC时间为事务选取时间戳。本文中，所有 时间戳 都是指HLC时间，HLC时钟在每个节点上是都是单一实例的（译注：也就是说每个节点上只有唯一一个HLC时钟，不会有两个时钟，产生两个时间的问题）。HLC时钟由节点上的每个读/写事件来更新，并且HLC
时间大于等于（ >=
）系统时间（wall time）。从来自其他节点的Cockroach请求里接收到的读/写时间戳不仅仅用来标识操作的版本，也会更新本节点上的HLC时钟。这用于保证在一个节点上的所有数据读写时间戳都小于下一次HLC时间。

8  Transaction execution flow事务执行流程

Transactionsare executed in two phases:

事务的执行分为两个阶段：

1.        Start the transaction byselecting a range which is likely to be heavily involved in the transaction andwriting a new transaction record to a reserved area of that range with state"PENDING". In parallel write an "intent" value for eachdatum being
written as part of the transaction. These are normal MVCC values,with the addition of a special flag (i.e. “intent”) indicating that the valuemay be committed after the transaction itself commits. In addition, thetransaction id (unique and chosen at txn start
time by client) is stored withintent values. The txn id is used to refer to the transaction record when thereare conflicts and to make tie-breaking decisions on ordering between identicaltimestamps. Each node returns the timestamp used for the write (which
is theoriginal candidate timestamp in the absence of read/write conflicts); theclient selects the maximum from amongst all write timestamps as the final committimestamp.

通过选择一个很可能卷入事务的range并且写一个带有“PENDING”状态的新事务记录到该range的保留区来开始事务。并行为正在被写的每一条数据写一个“intent”值，该操作作为事务的一部分。这些都是正常的MVCC (多版本并发控制)值，其附加的特殊标志（如：“intent”）指示该值在事务本身提交以后可以被提交。此外，事务ID（唯一的、客户端在事务启动时间选择的）也和intent值保存在一起。当事务冲突时和在相同时间戳间采用平分决胜策略确定顺序时，事务ID用于引用事务记录。每个节点都返回用于写的时间戳（这是没有读/写冲突时的原始候选时间戳）；客户端选择所有写时间戳中最大的作为最终提交时间戳。

2.        Commit the transaction byupdating its transaction record. The value of the commit entry contains thecandidate timestamp (increased as necessary to accommodate any latest readtimestamps). Note that the transaction is considered fully committed at
thispoint and control may be returned to the client.

通过更新事务记录提交事务。提交条目的值中包含候选时间戳（必要时会增长，以适应任何最新读时间戳）。注意此点上事务已认为被完全提交，并且控制权返还给客户端。

In the caseof an SI transaction, a commit timestamp which was increased to accommodateconcurrent readers is perfectly acceptable and the commit may continue. For SSItransactions, however, a gap between candidate and commit timestampsnecessitates transaction
restart (note: restart is different than abort--seebelow).

在SI事务的场景中，为适应当前读取者而增长的提交时间戳是完全可以接受的，并且事务提交仍然继续。然而对于SSI事务，候选时间戳与提交时间戳之间的差距使得事务重新启动成为必要（注：重新启动与中止不同，下面会有讲解）。

After thetransaction is committed, all written intents are upgraded in parallel byremoving the “intent” flag. The transaction is considered fully committedbefore this step and does not wait for it to return control to the transactioncoordinator.

事务提交后，所有写意向会并行升级，方式是移除“intent”标识。在此步之前，事务已被认为是完全提交了，并且不会等待它把控制返回给事务协调者。

In theabsence of conflicts, this is the end. Nothing else is necessary to ensure thecorrectness of the system.

在没有冲突时，事务处理就结束了。不需要再做其他事情来确保系统的正确性了。