【论文阅读】Zeus: Locality-aware Distributed Transactions

目录

1. 研究背景
2. 核心目标与总体设计
3. 贡献点
4. 方案设计细节
5. 实验验证
6. 总结

1. 研究背景

随着云平台应用数量的快速增长，数据中心需要为应用提供分布式，快速且可靠的数据存储服务。其中，分布式事务的处理能力影响了系统最终性能。近些年提出的基于内存的数据存储工作（FaRM（NSDI’14），FaSST（OSDI’16），DrTM（SOSP’15））能够在数据中心内部提供百万TPS吞吐且保证副本间的强一致性。但这些工作依赖对远程访问操作原语进行优化（如RDMA），降低分布式事务处理开销，但这些工作忽略了现实应用的负载存在的访问局部性特征。

数据的访问局部性在现实应用中普遍存在，例如，在蜂窝网络中，用户一段时间内通常只与最近的基站发生交互。在银行、股票交易中，交易通常发生在固定的账户之间。另外，负载中的局部性也可能随着时间动态变化。当前一部分工作采取静态分片（Static Sharding），将相关性强的数据划分在相同分片中，尽可能减少系统中分布式事务，这类方案需要提前了解负载的局部性情况，并假设局部性特征不会发生变化。另一部分工作采取了动态分片（Dynamic Sharding）策略，随着负载的变化将数据在片间动态迁移以适应访问模式的变化，如SLOG（VLDB’19）和DynaMast（ICDE’20）。【SLOG根据负载中的访问模式变化，更改数据的主域（Master-Region），数据状态在主域更改后异步更新到其他域。通过将事务读写的数据迁移到主域，避免跨地域数据读写带来的延时。但SLOG基于确定性数据库思想来保证副本间的一致性，需要每个数据中心的协调者参与协调，协调者需对来自不同数域的局部顺序进行再排序。DynaMast也通过数据动态迁移来避免跨节点数据读写，但不能保证副本间数据的强一致性，若主节点发生故障，最新更新数据将发生丢失，不支持高可用。】

现有工作对于应用移植的支持也不够友好。如FaRM，FaSST和DrTM，当请求远端机器的数据时，为避免线程同步等待给性能造成的影响，这些系统都假设应用通过自定义用户线程进行了事务的多路复用（如FaSST中采用协程），这对于许多已停止维护应用移植到平台上是很困难的。

综上，当前仍缺乏很好的利用负载中的访问局部性来提供高性能、副本间强一致、支持非确定性事务、便于应用移植的存储服务。

2. 核心目标与总体设计

2.1 核心目标

针对具有局部性特征的OLTP负载，在shared-nothing架构数据中心中，提供高性能、强一致、支持事务、易于应用移植的数据存储服务。

2.2 总体设计

Zeus基于两个协议（ownership protocol和reliable commit protocol）来达到以上几个目标。首先通过ownership protocol将事务即将更改的数据写权限从其他副本中收回，并且将决议在所有副本之间达成一致。随后，通过reliable commit protocol将节点本地对状态的更新传播到所有副本中，过程中保证副本之间一致性满足Strict Serializable（同时满足Serializability和Linearizability）。

节点一旦从其余分片获取了所有需要修改数据的写权限，就将分布式事务转变成了单点事务。由于没有其余节点会对相同状态发起写操作，保证了提交过程无冲突。同时由于设置了容错机制，即使存在故障节点的情况下，协议也能从故障中恢复，保证了协议提交不会被终止。因此，本地对事务的修改可以无阻塞提交，提高了分布式事务处理性能的同时，应用移植无需多余重构，便于将应用移植到Zeus上。

3. 贡献点

•  提出了一种通过动态分片来适应负载的局部性特征，加速事务处理的可靠存储服务。
• 提出了支持低延时数据权限修改协议（ownership protocol），以及支持本地更新向副本流水线提交的可靠提交协议（reliable commit protocol），所有协议均能够保证副本间的强一致性。
• 实验验证在具有高度访问局部性的负载下，Zeus在未使用RDMA情况下，性能相比基于RDMA的最新工作性能提升了2倍，同时验证了应用在Zeus上的可移植性。

4. 方案设计细节

4.1 Ownership protocol

对于某个数据项而言，系统中的节点分为以下四种类型：

Directory Node：维护数据项读写权限信息的节点，不存有数据具体内容，对数据没有读写权限。为了保证高可用，Directory Node采用三副本复制。

Owner Node：同时具有数据读与写权限的节点，保存数据内容本身以及权限信息。

Reader(s) Node：保存数据内容本身，对数据只有读权限。

Non-replica：为了高可用，数据内容也使用三副本复制，其他节点存储其余数据项。

 Zeus通过ownership protocol原子地更改目录节点和原拥有者间数据的写权限信息，并且保证节点间强一致，包括以下几个步骤：

① Requester向一个保存数据项读写权限信息的目录节点（directory node）发起更改请求；② 接收Requester请求的目录节点将本地信息置为无效（Invalidation），随后将请求转发给其余目录节点和原数据拥有者，同时带上逻辑时间戳；③ 接收到请求消息的其余目录节点执行同样操作，接着直接向Requester回复ACK消息；④ Requester收齐所有节点的ACK消息后，表明节点和原拥有者的读写权限信息已经全部置为无效（Invalidation），Requester随即更新本地权限信息，并将其置为有效（valid）。接着，再将修改内容发送给所有其余节点，其余节点更新完本地信息后，也将最新权限信息置为有效（valid）。

Ownership Protocol具有低延时、强一致、可靠性高的特点。除负责请求转发的目录节点外，其余收到请求信息执行完本地操作后直接将ACK消息发送给Requester，由于所有目录节点以及原拥有者的数据状态已经为无效，Requester可以本地执行修改，不用担心副本间的不一致问题，随后将更新数据发送给其他节点。同时，由于Invalidation的幂等性，在协议运行过程中即使有节点发生故障，节点发起新一轮请求即可继续被中止的操作。最后，对于节点间并发的权限更改请求，Zeus采用一个简单策略：对逻辑时间戳按照字典排序，最终处理时间戳最大的请求。

4.2 Commit protocol

Zeus通过上述Ownership Protocol将相关数据的写权限收集到本地，将分布式事务转变成了单机事务，本地修改状态即可。而Commit protocol负责将本地修改内容传播至其他副本中去，保证副本间一致性达到Strict Serializable，包括以下几个步骤：

① 节点在本地执行事务，对状态进行修改，但对用户暂时不可见；② 节点向所有副本发送更新后的数据内容，版本号，epoch_id以及Invalidation命令；③ 副本接收到主节点的消息，检查版本号，epoch_id通过后，更新本地状态并将数据置为Invalidation，并向主节点回复ACK确认消息；④ 当主节点收齐来自所有副本的确认消息后，将本地状态置为Valid，新内容开始对用户可见，随后向副本发送Validation，副本最新状态随即也对用户可见。

Commit Protocol具有强一致、可靠性高的特点。获得所有数据写权限的主节点在向用户暴露最新状态前，会将所有副本的状态置为无效，避免用户从不同节点间读取到的最新状态不一致。由于Ownership Protocol，系统中只有单个节点拥有这部分数据的更改权限，因此Commit Protocol无冲突，同时，由于Invalidation的幂等性，在协议运行过程中即使有节点发生故障，节点发起新一轮请求即可继续原先被中止的操作。因此，主节点本地对状态的修改可以通过Commit Protocol可靠地传播至所有副本中，主节点线程无需阻塞等待远端服务器反馈消息，本地后续更新操作可以流水线提交，提高了系统整体吞吐，移植到Zeus上的应用也无需重构。

5. 实验验证

实验1测试在具有高度局部性特征的负载下，不同分布式事务比例以及节点数目下（3副本），系统吞吐的情况。可以发现Zeus性能接近理想分片下的负载。

实验2测试负载局部性变化对吞吐的影响，即负载中Zeus需要先通过ownership protocol获得写权限的事务比例上升。发现随着比例的上升，Zeus吞吐随之下降，直到最后降低到与baseline相同。

实验3测试了ownership protocol转移权限的性能，设置10个线程分别将1M个账户写权限从node1转移到node2，再从node2转移到node3。可以发现，所有账户转移消耗4s了时间，每个线程每秒可处理25k个权限更改请求。

实验4测试了ownership protocol与事务执行并行时，性能是否受影响。实现发现ownership protocol依然能够达到每秒处理25k个权限更改请求的吞吐（应该是网络还未到压瓶颈）。

实验5测试了在使用ownership protocol转移普通数据以及热点数据时的累计分布情况。可以发现，热点账户转移的平均延时和第99.9%数据转移成功的延时都比普通账户长。

支持应用移植，代码无需重构是Zeus的一个重要的特点。实验6测试了将3种应用在移植到Zeus后的性能。如下图使用Zeus做Nginx的Session持久化，同时向集群中增加和减少Zeus中的节点数目，同时测试Nginx处理的HTTP请求吞吐。可以发现Zeus性能能够不低于不使用Zeus情况下的吞吐，Zeus不是系统的性能瓶颈。

6. 总结

Zeus将事务需要修改的数据集中到单个节点，通过将分布式事务转变成单机事务来提高在具有高度访问局部性负载下系统的性能。与此同时，Zeus具有副本间强一致、支持非确定性事务、便于应用移植的特点。通过提出的两种协议（Ownership protocol与Commit Protocol）来达成。实验验证了Zeus在具有高度局部性的负载下性能接近理想分片情形，同时便于现有应用移植到Zeus上。