网络虚拟化:高效通信协议-InfiniBand介绍

作者：木木大佬  美团数据转发面高级研发专家

大佬主页：

https://www.zhihu.com/people/mu-mu-67-87-35

文章链接：

https://zhuanlan.zhihu.com/p/645049597

摘要：

分布式系统通常是在网络是主要瓶颈的假设下构建的，但是数据中心中新兴的高性能 RDMA 支持协议不再支持这一假设。与传统协议（即 TCP/IP）相比，通过此类协议设计分布式应用程序需要对通信组件进行根本性的重新思考。在本文中，研究了现有系统中的通信范式和新的可能范式。对每种范式的优点和缺点进行了全面分析和实验评估。实验结果表明，与其他通信范例相比，将请求写入服务器并读取响应的性能提高了 10 倍。为了进一步扩大研究范围，所提出的通信范例已被替换为现实世界的分布式应用程序，并且性能提高了七倍。

1.介绍

硬件、软件和网络方面不断的技术突破导致了分布式应用的增长。分布式应用程序需要在组件之间进行通信以访问远程资源。随着时间的推移，分布式环境中的潜在挑战已经发生了多次变化。如今，设计现代现实世界分布式应用程序的一个重要方面是连接其各个组件的通信模型。本文重点关注分布式应用程序中的通信，以强调每种通信范例的优点和缺点。

由于大量的 CPU 和内存使用，基于 TCP/IP 协议的通信不适合高速数据传输。这种限制催生了一种新的网络结构，它使用一种称为远程直接内存访问 (RDMA) 的技术。RDMA 通过在集群中连接的节点之间创建虚拟分布式共享内存来解开每台机器的边界。它允许从一台主机的内存到另一台主机的内存的直接内存访问。此类网络结构的示例包括互联网广域 RDMA 协议 (iWARP) [1]、融合以太网上的 RDMA (RoCE) [2] 和 InfiniBand [2]。与传统协议相比，RDMA 在网络接口卡（通常称为主机通道适配器 (HCA)）中实现整个传输逻辑，以提高性能。

最近，现代集群拥有足够的主内存来以分布式方式存储数据应用程序，因此它们在其网络基础设施中采用 RDMA 技术来加速分布式内存访问。

本文的动机是基于 RDMA 的分布式应用程序中通信类型之间的表面对比。它解释了几种通信范例中网络流量、连接类型和同步性的根本差异。为了解决通用性问题，对核心通信进行了评估。

本文致力于回答现代集群上分布式数据中心应用程序设计的重要研究问题，做出以下贡献：

• 全面讨论RDMA协议的挑战、机遇和适用性

• 提出一些提高性能的优化技术

• 对交换请求/响应的最佳通信设计的研究

RDMA系统

• 在现实世界的分布式应用程序中评估所提出的通信范例

在提议的通信中，RDMA 被视为发送和接收请求和响应的手段。所有通信均已实施和评估，结果表明，通过 RDMA 写入将请求写入服务器内存并通过 RDMA 读取读取响应，与其他通信范例相比，性能提高了 10 倍。

本文的其余部分安排如下。第 2 节介绍了 RDMA 机制的背景。第 3 节提供了 RDMA 的机遇、挑战和适用性。第 4 节介绍了通信范例的全面分析以及如何利用 RDMA 的关键性能挑战。第 5 节讨论了实验和结果。第 6 节评估了现实世界的分布式应用程序。最后，第 7 节得出结论。

2.背景

尽管 iWARP、RoCE 和 InfiniBand 协议提供了一组独特的操作，但是采用适当的协议需要了解每种协议的优点和缺点。iWARP [1] 是由互联网工程任务组 (IETF) 发布的复杂协议，仅支持可靠的连接传输（参见第 4.2 节）[12]。它旨在将 TCP 转换为 RDMA 语义，这限制了 iWARP 产品的效率。相反，RoCE是InfiniBand贸易协会（ITA）发布的基于以太网的RDMA解决方案，支持可靠和不可靠的传输。InfiniBand 是一种先进的网络协议，具有低延迟和高带宽，常用于商用服务器。

OpenFabrics 联盟 (OFA) 发布并维护 RDMA 协议（即 iWARP、RoCE 和 InfiniBand）[13] 的用户级应用程序编程接口 (API) 以及称为 OpenFabrics Enterprise Distribution (OFED) 的有用实用程序。

如图 1 所示，RDMA 允许应用程序对一系列由 HCA 执行的请求进行排队。队列成对创建，称为队列对 (QP)，用于发送和接收操作。应用程序在适当的队列上提交工作队列元素（WQE）。然后，通道适配器按照队列中的 FIFO 顺序执行 WQE。每个 WQE 可以使用多个分散/聚集条目来读取多个内存缓冲区，并将它们作为一个流发送并将它们写入多个内存缓冲区。当通道适配器完成 WQE 时，完成队列元素 (CQE) 将在完成队列 (CQ) 上排队。RDMA 提供由不同操作组成的各种工作请求，例如：

SEND/RECV 向远程节点发送消息/从远程节点接收消息

Fetach-And-Add(FAA) 以原子方式递增远程计算机中虚拟内存位置的值并返回

Compare-and-Swap(CAS) 原子地比较虚拟内存地址的值与指定值，如果它们相等，则将在指定地址存储新值

READ/WRITE 利用远程计算机的直接内存访问 (DMA) 引擎从远程节点读取数据或向远程节点写入数据（即绕过 CPU 和内核）

图2显示了机器A和B之间可能的RDMA通信。首先，用户应用程序在步骤1中发出发送请求，以便在步骤3中通过CPU与通道适配器进行通信。步骤2中的内核空间操作仅用于启动RDMA连接，连接建立时没有任何操作或缓冲。此外，第四操作的存在取决于请求类型。如果数据是内联的（参见第 4.3 节），HCA 不需要执行额外的 DMA 操作来从用户空间内存读取有效负载。然后，该请求将被放入发送队列中，等待网络处理器 (NP) 处理该请求。当机器 B 收到消息时，可以在内存地址上执行该消息（步骤 4），而不需要对机器 A 进行任何回复，或者对机器 A 进行回复（步骤 5）。

3. 机遇/挑战/适用性

利用 RDMA 的下一代高性能网络正在为这些新协议带来极其重要的机遇和挑战。下面描述这些问题以及支持 RDMA 的网络的适用性。

3.1 机遇

持 RDMA 的协议提供了加速数据传输的重要功能，无需网络软件堆栈参与（零复制）、上下文切换（内核旁路）以及远程处理器的任何干预（例如缓存污染、CPU 周期）（无 CPU 参与） 。与传统的分布式系统不同，这些功能允许 RDMA 应用程序使用很少的内核来使网络饱和。RDMA 应用程序以有效的方式使用 CPU，这在共享 CPU 环境（即云解决方案）中是有益的。此外，这些功能丰富了支持 RDMA 的应用程序，以实现最高的通信吞吐量，特别是对于小消息。RDMA 通过基于硬件的丢失数据包重传，在可靠的无损基础设施上提供分布式共享内存 [8]。

与传统协议的兼容性是支持 RDMA 的协议的一项重要功能。例如，iWARP 和 RoCE 旨在与传统以太网协议兼容，InfiniBand 通过 IP over InfiniBand (IPOIB) 支持传统套接字应用。

3.2 挑战

尽管与传统协议相比，RDMA 提供了更高的性能，但 RDMA 性能实现与根据 RDMA 语义重新设计现有应用程序成本之间的困境可能是一项具有挑战性的任务。重新设计的范围可以是整个系统，也可以仅限于与 RDMA 发送/接收对应部分的通信组件。应当指出的是，后一种方法的性能实现是有限的。

支持 RDMA 的分布式应用程序中的挑战性问题之一是协调本地和远程内存访问，因为这些访问彼此是透明的。实际上，同步这些并发访问会通过并发控制机制阻碍 RDMA 性能。通常，应用并发控制会导致访问放大以保证数据一致性。然而，有一些有限的基于硬件的解决方案，例如硬件事务内存（HTM）。此外，这种并发问题不仅限于远程和本地内存访问，远程内存访问之间也存在竞争。对于这种情况，RDMA支持CAS和FAA等原子操作。这些原子操作的性能本质上取决于其在硬件中的实现[14]。此外，原子操作的大小是有限的（例如，64 位）。RDMA 原子操作可以配置为全局 (IBV_ATOMIC_GLOB) 或本地 (IBV_ATOMIC_HCA) 粒度。局部粒度保证对同一 HCA 内特定地址的所有原子操作都将被原子处理，全局粒度保证对系统内（即多个 HCA）特定地址的所有原子操作都将被原子处理。然而，到目前为止，现有的 HCA 中仅实现了本地模式。

3.3 适应性

RDMA 可以在每个往返时间 (RTT) 中执行一项操作，但传统协议通过完成多项操作来提供更大的灵活性。因此，它使得RDMA更适合单一且快速操作的环境。此外，RDMA更适合小且相似的消息大小。此外，由于 RDMA 的初始成本很高，因此利用动态连接来利用 RDMA 并没有什么好处。此外，虽然RDMA提供了高速通信，但它限制了距离和大小的扩展，这意味着节点之间的距离和节点数量不能任意大[15]。

RDMA 提供简单的read、write和原子操作（CAS 和 FAA）以及发送消息（SEND）的操作。然而，它不支持复杂的操作，例如解引用、遍历列表、条件读取、动态操作（例如压缩和解压缩）、直方图计算、结果合并[16]。因此，在这样的环境中利用 RDMA 需要精确和精细的机制来实现最佳性能。

4 通信

RDMA 允许基于其原语的多种通信范例。每次通信都有两个主要参与者，即发出请求的参与者（客户端）和响应请求的参与者（服务器）。在本节中，描述了 RDMA 原语、可能的通信范例和 RDMA 优化。

4.1 通信原语

RDMA操作可以分为单侧通信和双向通信。在单向通信（即读、写、原子 FAA 和 CAS）中，接收方的 CPU 在传输过程中完全处于被动状态。然而，双向通信（即发送）需要双方都采取行动。

WRITE 是一种单方面的操作，不会通知远程主机。但是，使用 WRITE 发送立即数据会通知远程主机有关操作的信息。WRITE 和立即通知是一个原子单元，要么都到达，要么都不到达。需要注意的是，在立即操作中，会消耗一个接收请求，并在消息中发送立即数据。该即时数据将在为远程端所使用的接收请求生成的 CQE 中可用。即时数据在写入之后竞争，即在写入完成和即时数据到达之间。

READ 是一种单方面操作，从远程端读取连续的内存块（在虚拟地址空间中）并将其写入指定的本地内存缓冲区。需要注意的是，READ 并不消耗远端的接收请求。

SEND携带要写入远程存储器地址的本地存储器缓冲区的内容，该远程存储器地址在远程侧的预先发布的接收请求中指定。由于双方都需要发送工作请求，因此 SEND 被视为双边通信。在远程端，将为所消耗的接收请求生成工作完成。此外，SEND 支持立即数据以及 WRITE。

4.2 通信范式

根据消息传递的类型，通信可以分为同步或异步。在同步通信中，客户端发送消息，并被阻塞，直到响应到达，然后返回正常执行。在这种模式下，消息代表两个进程之间的同步点。在异步通信中，客户端发送消息，然后继续执行，直到响应准备好。

由于在基于 RDMA 的同步通信中，客户端和服务器之间没有公共时钟来就数据传输速度达成一致，因此会利用繁忙轮询或阻塞功能。同时，可以通过带有通知的事件来实现基于RDMA的异步通信。

图 3 显示了可能的同步和异步 RDMA 通信。首先，客户端通过 ibv_post_send() 将工作请求发布到发送队列来发送其请求。然后，它通过 ibv_get_cq_event() 或 ibv_poll_cq() 接收其工作请求的完成情况。ibv_get_cq_event() 是一个阻塞函数，而 ibv_poll_cq() 不能使用任何标志或超时参数进行阻塞，因此可以通过繁忙轮询来阻塞。根据通信类型，客户端可以使用 ibv_post_recv() 或忙轮询来获取其响应。一般来说，服务器接收请求并以相同的方式但顺序相反的方式响应它。

当事务中的语句需要顺序执行时，就会利用同步通信。同步通信由于其阻塞本质而具有挑战性。这种阻塞机制会导致系统出现瓶颈。因此，需要更多的关注来选择合适的同步通信范例以实现最佳性能。因此，本文重点关注主要通信范式的同步实现。然而，还讨论了每个范例异步实现的可能性。

图 4 显示了没有利用上述通信原语的中间件层的主要通信范例。在模型 (a) 中，客户端和服务器交换请求和回复的预定义内存地址。服务器正在轮询内存地址以获取新请求，客户端将其请求写入服务器中预定义的内存地址。然后，服务器通过写入客户端内存地址来回复。在模型 (b) 中，客户端将其请求写入本地内存地址，服务器轮询该内存以查找新请求。之后，服务器通过写入客户端中预定义的内存来回复客户端。在模型（c）中，服务器几乎是被动的，客户端将其请求写入服务器中预定义的内存地址并轮询以检查响应。在模型 (d) 中，客户端将其请求写入本地内存地址，服务器轮询该内存以查找新请求。然后，客户端轮询服务器中预定义的内存以检查响应。在模型(e)中，客户端向服务器发送请求消息，然后服务器向客户端返回响应消息。最后，模型(f)是传统的socket通信请求和回复。

型（a）-（c）依赖于持续轮询机制进行同步通信，可以通过不同的方式实现[9,17]。通常，轮询依赖于写入消息的最后一个数据包来检测请求完成情况。然而，这种基于轮询的方法的正确性取决于消息的传递，以避免预期的最后一个数据包传递或内存被旧消息覆盖[18]。

根据上述定义，模型(a)可以通过立即数据的WRITE以异步方式完全实现，并通过轮询机制以同步方式实现。虽然模型(b)中的客户端可以异步实现，但由于READ中缺少通知，服务器无法异步实现。模型（d）不支持任何一方的异步通信。模型（e）和（f）可以用两种方式实现。

可以看出，每种范式都有其独特的特征，使其适合特定的环境。模型（a）和（d）以公平的方式分担沟通的努力。模型（c）将通信负担放在客户端，模型（b）将通信负担放在服务器端。由于轮询，模型 (a) 在客户端和服务器端都会产生较高的 CPU 使用率。模型 (b)–(d) 生成更多网络流量用于轮询远程端。模型（e）和（f）不产生预定义的内存地址，但它们需要同步发送和接收消息。

每个通信范例根据所采用的RDMA操作支持一系列连接类型。RDMA 支持不可靠和可靠连接类型。与不可靠连接不同，可靠连接通过接收方的确认消息来保证数据包的传送和顺序。此外，RDMA 支持未连接和已连接的连接。与未连接的情况不同，连接通信中的每个 QP 恰好连接到远程节点的一个 QP。本文仅考虑已连接的连接，即可靠连接（RC）和不可靠连接（UC）。表 1 根据客户端和服务器开销、网络流量、通信和连接类型比较了不同的通信范例。每个模型根据图 4 中所示的操作进行命名。

4.3 优化考虑因素

由于 RDMA 完全在 HCA 中实现，计算和内存资源有限，因此优化技术会对性能产生显着影响。在本节中，简要描述了可能的优化。

数据内联：WQE 根据请求的操作从不同的段构建。一个重要的段是数据，它指向包含有效负载的内存。WQE 可以选择包含称为内联数据的数据。内联数据将节省用于收集有效负载的内存读取访问。WQE 可以包含单个或多个内存指针以及内联数据或这些的任意组合。尽管内联数据可以消除内存访问的开销，但它对有效负载大小施加了限制。无论如何，这对于小有效载荷来说是一种有效的优化。

有效payload大小：有效负载大小对性能起着至关重要的作用。它会增加 CPU、内存和 HCA 之间的通信数量，从而降低性能。例如，在 64 字节高速缓存线大小的情况下，如果有效负载从 64 字节增加到 65 字节，则在将有效负载传输到 HCA 时必须访问两个 CAN 线。此外，性能可能会受到主机总线（即外围组件互连 Express (PCIe)）参数的影响。例如，最大有效负载大小 (MPS) 定义每个 PCIe 通信中的最大传输大小。如果MPS较低，可以增加HCA和内存之间的通信次数[19]。

传输类型：RMDA 支持三种不同的连接类型：可靠连接 (RC)、不可靠连接 (UC) 和不可靠数据报 (UD)。UD 是一种不可靠且无连接的连接，不保证消息的传递以及消息的顺序。连接类型不仅影响网络通信流量，还影响 HCA 中消耗的资源量[14]。例如，与 RC 和 UC 连接相比，UD 连接消耗的资源要少得多。与 RC 相比，UC/UD 可能具有更高的性能，但代价是失去可靠性。然而，Kalia 等人在通过不可靠的连接传输 50 PB 数据时实现了零丢包。[20]。此外，应该注意的是，每种连接类型并不支持所有 RDMA 操作。表 2 显示了每种连接类型支持的操作。

无信号工作请求：处理工作请求时，HCA 会生成工作完成元素。生成此元素会增加应用程序收集它的开销。RDMA 允许在不接收完成元素的情况下发送工作请求。但由于资源枯竭，这种方法无法持续采用。因此，必须定期请求完成工作请求以释放占用的资源。此外，RDMA 允许一次读取多个完成元素。

5. 实验评估

RDMA 在双方（即客户端和服务器）上呈现出不对称的性能特征[14]；但是，对客户端的性能进行了调查。所有实验均使用 gcc 版本 4.4.7 进行编译，预热时间为 50 秒，测量时间为 25 秒。实验在一个小型集群上运行，该集群具有 2 个插槽 AMD Opteron 6276 (Bulldozer) 2.3 GHz，配备 PCI-E 2.0 上的 20 Gbps DDR ConnectX Mellanox。网络拓扑是与 Infiniscale-III Mellanox 交换机直接连接。每台机器都有四个 NUMA 节点连接到两个套接字。Libibverbs（OFED 的一部分）被用来管理 RDMA 资源。此外，每台机器有一个轮询线程来处理请求。为了将 RDMA 范例与传统对应范例进行比较，还研究了基于套接字的方法。此外，实验的实施是公开的（https://github.com/mashemat/Communication）。在每种通信范例中，都对吞吐量、延迟和可扩展性进行了研究。

为了测量 RDMA 操作吞吐量的变化，四个客户端进程驻留在连接到一台服务器的一台主机上，执行连续的 RDMA 操作。这个实验重复了100次，每次执行一个客户端50秒。测量每个客户端的吞吐量，然后将它们合并起来找出总价值。图 5 显示了该实验的结果。可以看出，观察到的吞吐量之间的差异可以忽略不计，只有少数异常值。

实验结果

4.3 节中描述的优化对基于 RDMA 的应用程序的整体性能产生了重大影响。因此，主要评估应用优化的实验结果。然后，讨论了通信范式的结果。

图 6 显示了有效负载大小对吞吐量的影响。在实验中，一个客户端以不同的有效负载大小执行 RDMA 操作。可以看出，增加有效负载大小会导致性能下降，因为有效负载大小会影响 CPU-HCA 交互以及交换消息的数量。此外，图 6 表明，尽管两种操作具有相同的 InfiniBand 路径，但 WRITE 提供的吞吐量高于 READ。背后的原因是 WRITE 需要在 RDMA 和 PCIe 级别维护更少的状态 [8]。在WRITE操作中，客户端不需要等待响应。但是，READ 请求必须保留在客户端的内存中，直到响应到达。此外，在 PCIe 级别，与 WRITE 相比，READ 是使用更重的事务来执行的。此外，与 READ 和 WRITE 相比，SEND 的性能要低得多，因为它不绕过远程 CPU，并且需要在服务器端进行 RECV，由于其写入数据和 CQE 的 DMA 交互，这是一个缓慢的操作 [8]。

当 WQE 完成其操作时，它会通过 DMA 写入将完成信号推送到 CQ。由于 PCIe 交互，推送此信号会增加操作的额外开销 [8]。图 7 显示了使用选择性信号时 RDMA 操作的吞吐量。在本实验中，具有 8 字节有效负载大小的连续操作以无信号方式发送，即，不会为这些操作生成完成信号，然后发送有信号操作以释放所占用的资源。需要注意的是，无信号操作的数量不能超过队列对的大小，本实验中设置为2048个单元。如图 7 所示，增加无信号操作可以提高性能。

WQE 可以将其有效负载内联到最大编程输入/输出大小，否则可以通过 DMA 读取来获取有效负载 [8]。尽管可靠和不可靠连接（RC/UC）类型具有相同的报头大小（即 36 B），但它们呈现不同的性能。例如，与未连接的连接相比，两种连接的传输 (RC/UC) 都需要与 HCA 中的连接数量一样多的队列对。这些队列对会增加 HCA 中的内存消耗，并可能因缓存未命中次数增加而影响性能。

图 8 和图 9 显示了内联消息和连接类型对 SEND 和 WRITE 的影响，同时增加了无信号操作的数量。READ 操作不会被报告，因为它只支持可靠的连接。此外，它不传输有效负载，因此不支持内联功能。在此实验中，一个客户端以 8 字节有效负载大小执行 RDMA 操作。可以看出，内联和连接类型对SEND和WRITE操作的影响并不相同。WRITE 对内联更敏感，SEND 对连接类型更敏感。在这两种情况下，这些功能都可以将性能提高多达 4.9 倍。

图 10 和 11 说明了可靠和不可靠连接中 READ 与 SEND 和 WRITE 的比较。可以看出，在 RC 和 UC 连接中，具有内联有效负载的 WRITE 优于其他 RDMA 操作。

扩展是一项重要的实验，因为在实际情况下，通常有多个客户端连接到服务器。因此，设计了一个实验来研究缩放对性能的影响。在此实验中，多个客户端向服务器发送请求。服务器以循环方式处理新请求。如果服务器发现来自客户端的请求，则会响应该请求。每个客户端都映射到一个专用核心以避免上下文切换。每个客户端发送 8 字节消息请求，其中包含 512 个无信号操作。

图 12 显示了增加客户端数量后的性能。SEND 和 WRITE 吞吐量下降是因为 SEND 和 WRITE 没有发出信号，即客户端进程没有得到操作完成的指示。这会导致客户端进程因过多的未完成操作而不堪重负，从而导致 HCA 内的缓存未命中。可以看出，WRITE 和 READ 的性能优于其他操作。此外，在客户端较少的情况下，WRITE 的性能优于 READ 操作。令人惊讶的是，当客户端数量较多时，SEND 的套接字通信性能较差。需要注意的是，本次实验中socket是以非阻塞方式实现的。此外，仅采用一台机器来部署客户端进程。然而，增加客户端机器的数量可能会改变性能，因为维护 QP 状态的开销分布在不同的机器之间 [14]。

下面对通信范例进行评估和讨论。图 13 和 14 分别显示了通信范例的性能和延迟。根据图 12 中报告的实验，WRITE 操作具有最佳性能，因此预计 WRITE-WRITE 优于其他通信范例。令人惊讶的是，WRITE-READ 的吞吐量比 WRITE-WRITE 大得多（即 2.4 倍）。原因是，在 WRITE-WRITE 通信中，客户端发送请求并轮询响应区域，客户端数量的增加会使服务器不堪重负，无法处理请求并通过 WRITE 操作回复它们。然而，写-读范式减轻了服务器的负担，因为服务器通过写入本地内存来回复请求。因此，它可以处理更多的请求并减少客户端的响应时间，从而实现更好的吞吐量。此外，图 14 表明，WRITE-READ 范例的延迟是其他范例中最低的。与 WRITE-READ 不同，READ-WRITE 通过 READ 读取请求并通过 WRITE 回复来使服务器超载。因此，读-写的性能低于写-读。READ-READ 比 READ-WRITE 具有更好的吞吐量，因为与 READ-WRITE 范例中的 READ 和 WRITE 相比，服务器仅执行 READ 操作。如图 13 所示，SEND-SEND 和 SOCKET-SOCKET 由于操作繁重而表现不佳，这是根据图 12 中的结果所预期的。

WRITE-READ是实验中唯一可以通过增加客户端数量来很好地扩展的范例，但是这种方法的主要缺点是客户端需要付出更多的努力来交换请求-响应。因此，对于客户端与其他进程位于同一台计算机上的环境来说，这是一个不错的选择，因为必须分配给客户端进程的 CPU 量非常高。READ – READ 是在客户端和服务器端公平行事的好选择。然而，它的执行速度比 WRITE-READ 慢 3.9 倍。此外，READ-READ 会产生巨大的网络流量来轮询远程主机。

6. 内存中键值存储

内存中键值存储对于加速以内存为中心和以磁盘为中心的分布式系统至关重要[21]。它们广泛应用于大规模互联网服务中，能够管理大规模分布式数据。它们提供了一种具有较弱一致性的灵活数据模型，可以在计算机网络上的许多节点之间划分数据。内存中键值存储支持由 Get 或 Put 组成的单语句事务来读取或更新数据。最近，内存中键值存储正在利用 RDMA 来减少通信开销 [7-9,17,22]。

HydraDB 是一种基于 RDMA 的通用内存键值存储，专为低延迟和高可用性环境而设计[17]。HydraDB 将数据分区到称为分片的不同实例中。每个分片维护一个缓存友好的（即缓存行对齐的存储桶大小）哈希表来存储键值的位置而不是其实际内容。图15展示了HydraDB的示意图。该方案显示了索引、通信协议和支持的操作（Get 和 Put）。

客户端使用 WRITE-WRITE 来发送和接收请求/响应。对于Get来说，shard首先在哈希表中找到对应的key-value地址。然后，它向客户端回复键值对的地址。因此，对于来自客户端的相同密钥的下一个请求，它利用基于缓存地址的读取。

put操作完全依赖服务器；服务器在哈希表中找到键，然后更新键值对。为了数据一致性和内存回收，分片利用异地更新与基于租约的时间相结合[23]。

为了在实际应用中探索本文的发现，部分实现了 HydraDB，并且在 Put 事务中用 WRITE-READ 通信取代了 WRITE-WRITE 通信。不考虑Get，因为它主要执行READ操作。随后，设计了一些实验来将新方法与原始方法进行比较。

查询分布是在内存键值存储上执行实验的主要参数之一。Facebook 分析报告称，网络请求遵循类似 Zipfian 的分布，并且大多数内存系统都基于具有高 α 比率（α = 0.99）的 Zipfian 分布进行实验，表明倾斜曲线。在本文中，为了全面性，考虑了两种分布（Uniform 和 Zipfian）来紧密模拟现实世界的流量。

键的数量是实验中的一个重要参数。例如，服务器需要根据键的数量注册相应的内存大小，这会增加HCA中获取页表条目的缓存未命中率并影响性能。在本文中，使用了 400 万个密钥，密钥和值的大小分别为 16 和 32 字节，接近实际值。

图16显示了实验结果。可以看出，修改后的 HydraDB 具有 WRITE-READ 通信，其性能比原始实现高出七倍之多。此外，写-读通信通过增加客户端数量提供了更好的可扩展性。

7 结论

本文探讨了设计高性能分布式系统的通信范例，重点关注数据中心应用中基于 RDMA 的通信。讨论了 RDMA 协议的机遇、挑战和适用性。对几种基于 RDMA 的通信范例进行了实验评估。本文详细分析了如何使用RDMA操作来构建基于RDMA的通信。结果鼓励研究人员和开发人员通过 RDMA 优化开发改进的系统。对不同通信范式的调查表明，WRITE-READ 的性能比其他范式高出 10 倍。在现实世界中的分布式内存键值存储中，WRITE-READ 已被 WRITE-WRITE 取代，性能提高了七倍。然而，实验的教训表明，未来的分布式系统在 CPU 不是客户端计算机中的关键资源的环境中使用写-读通信。

作为未来的工作，将研究定义发送请求和回复响应的窗口大小的影响。此外，应用多个服务器进程和每个进程多个轮询线程被认为是未来的方向。此外，将所提出的通信应用于 Paxos [24,25] 和 Raft [26] 等众所周知的协议被认为是未来的方向。

-END-

欢迎关注通信行业搬砖工的笔记

 一个分享和通信_vpp_读书_吃瓜的账号