CN113259439B

CN113259439B - 基于接收端驱动的键值调度方法

Info

Publication number: CN113259439B
Application number: CN202110537700.4A
Authority: CN
Inventors: 蒋万春; 陈宇成; 汲发; 王建新
Original assignee: Central South University
Current assignee: Central South University
Priority date: 2021-05-18
Filing date: 2021-05-18
Publication date: 2022-05-06
Anticipated expiration: 2041-05-18
Also published as: CN113259439A

Abstract

本发明公开了一种基于接收端驱动的键值调度方法。当键值操作到达客户端时，键值操作并没有被立刻发送，而是在客户端队列中等待以寻找最佳调度时机，此外，客户端分布式地调节其允许发送键值操作的阈值来控制客户端之间的并发性。故本发明能够根据服务器动态变化的性能来进行键值调度，当有些服务器性能较差时，键值操作会被压在客户端队列中以等待最佳的调度时机，性能较好的服务器处理速度快，因此能够被分配到更多的键值操作。此外，本发明分布式地调节客户端允许发送的键值操作数目，使客户端之间达成了良好的协作，有效地控制了大规模场景下的并发导致尾延时激增的问题。与现有的自适应调度方法相比，本发明有效地降低了键值操作的尾延迟。

Description

基于接收端驱动的键值调度方法

技术领域

本发明涉及分布式键值数据库领域，特别涉及一种基于接收端驱动的键值调度方法。

背景技术

随着互联网技术的不断发展，大量数据正在不断产生，分布式数据库由于其良好的可扩展性和高可用性，已经逐渐成为众多交互式应用程序的核心存储平台。而一个终端用户请求通常会产生数十个甚至数百个键值操作，这些键值操作的尾延迟决定了整个终端请求的响应时间，进而影响了用户体验与企业收益。为了提高并行存储的效率，每一份数据通常会被备份到集群中的多个节点上，同时，每台服务器的负载和性能是动态变化的，如果在高负载或低性能的服务器上处理键值操作，将会产生巨大的尾延迟。因此，客户端采用合适的调度方法能够有效地改善键值操作的尾延迟。

2015年NSDI会议提出了理想的即时调度方法ORA，ORA假设客户端能够实时知道服务器的瞬时负载Qs与服务时间ST，ORA方法为每个客户端选择Qs*ST最小的服务器，以确保此时选择的服务器具有最优的性能，这样能够有效地降低尾延迟。基于ORA的思想，该会议提出了自适应副本选择方法C3，C3主要在服务器返回键值响应时携带了服务器的等待队列长度Qs与服务时间ST，客户端收到键值响应时根据服务器的反馈信息对副本服务器进行排序，选择性能较好的服务器发送键值操作。此外，为了避免所有客户端同时将请求发送给性能较好的服务器，使得服务器负载瞬间增大，导致羊群效应，C3引入了速率控制机制，限制了每个客户端在固定时间间隔内发送键值操作的数量，以确保发送到服务器的请求数不超过服务器的容量。仿真实验结果与基于分布式数据库Cassandra集群的实验测试结果表明：相比于Cassandra数据库默认的键值调度方法DS，C3显著地降低了键值操作的尾延迟。

然而，由于服务器的性能是随时间不断波动的，ORA理想即时调度方法并不能实现最优的调度。这是因为ORA只实现了在键值响应返回给客户端这一时刻下的最优调度，如果键值操作在服务器排队等待期间，服务器性能状态发生了变化，此时之前的调度已经不是最优调度了，进而导致ORA并不能够达到最理想的效果。此外，由于每个客户端至少发送一个键值操作到服务器中，随着客户端数目增大，键值操作的并发性增大，同一时刻会有很多键值操作被发送到服务器，导致服务器瞬时负载突增，降低了键值操作的尾延迟。

发明内容

针对目前ORA无法在键值操作处于服务器排队等待期间实现最优调度，且键值操作并发性较大导致服务器瞬时负载突增时，会降低键值操作的尾延迟的技术问题，本发明提供一种让键值操作的尾延迟既不会受服务器高负载或低性能的影响，也不会受由于客户端数目增多造成高并发的影响的在键值存储系统中的基于接收端驱动的键值调度方法。

为了实现上述技术目的，本发明的技术方案是，

一种基于接收端驱动的键值调度方法RS(Receiver-driven Scheduling)，包括以下步骤：

A1：当用户请求到达客户端后，生成键值操作，然后执行步骤A2。当服务器的键值响应到达客户端时，执行步骤A3。

A2：检查当前客户端记录的OSK值，如果OSK＝0，执行步骤A4。否则将键值操作存放到客户端用于保存键值操作的键值队列中，然后返回步骤A1。其中OSK是指已从客户端发送请求但还未接收到响应的键值操作数量。

A3：根据当前Qs和TQs的大小，并基于TOSK的变化情况来调整TOSK，如果调整后的TOSK<1，执行步骤A5，否则执行步骤A6。其中TOSK为客户端允许发送键值操作数目的最大值，TQs为服务器端等待队列长度的最大值，Qs为服务器返回键值响应时携带的服务器端等待队列长度。

A4：如果当前TOSK≥1，则直接将生成的键值操作发送给目标服务器，然后执行步骤A7。如果TOSK<1，则采用概率发送机制来发送生成的键值操作，然后执行步骤A7。

A5：如果OSK＝0，则采用概率发送机制来发送客户端的键值队列中等待时间最久的键值操作，并执行步骤A7。如果OSK≠0，则不发送键值队列中的键值操作，然后返回步骤A1。

A6：如果OSK<TOSK，发送在客户端的键值队列中等待时间最久的键值操作，并执行步骤A7。如果OSK≥TOSK，则不发送键值队列中的键值操作，然后返回步骤A1。

A7：在键值操作被发送到服务器之前，将键值操作在键值队列中的等待时间携带在键值操作上，同时发送至服务器，然后执行步骤A8。

A8：当服务器收到的键值操作时将其保存在服务器端等待队列中，并对等待队列中所有的键值操作计算在客户端与服务器的等待时间之和作为优先级的值，按照优先级从大到小依次服务键值操作，将其键值响应发回给客户端，返回步骤A1。

所述的方法，所述的步骤A3中，TOSK通过以下公式进行调节：

其中，C表示比例因子，β表示乘法因子，ΔT表示上一次TOSK下降以来经过的时间间隔，TOSK_max表示上一次TOSK下降时的值，TQs基于客户端数目进行设置。

所述的方法，所述的步骤A3中，若客户端连续收到的键值响应中携带的Qs均满足Qs＞TQs，则降低TOSK调节的频率。

所述的方法，所述的降低TOSK调节的频率，是根据客户端连续收到满足Qs＞TQs的键值响应的数量，来对TOSK调节的频率进行调整：当持续收到n个满足Qs＞TQs的键值响应时，则接下来在收到2ⁿ个键值响应后才调节TOSK。

所述的方法，所述的步骤A4和A5中的概率发送机制，是以TOSK的数值来作为键值操作被直接发送至服务器端的概率值，若键值操作未被直接发送，则让其在客户端等待T_wait后再调度给服务器，T_wait＝(1-TOSK)*RPT，其中RPT表示客户端在收到键值响应时记录的当前键值操作的延迟信息。

所述的方法，所述的步骤A5中，如果OSK＝0，但客户端的键值队列中没有未发送的键值操作，则直接返回步骤A1。

所述的方法，所述的当前键值操作的延迟信息，是当前键值操作从客户端发送至服务器端起，到客户端收到该键值操作的键值响应为止所经过的时间。

本发明的技术效果在于，重新设计了键值调度框架，解决了客户端需要何时调度键值操作，调度哪些键值操作的问题。当键值操作到达客户端时，键值操作并没有被立刻发送，而是在客户端队列中等待以寻找最佳调度时机，此外，客户端分布式地调节其允许发送键值操作的阈值TOSK来控制客户端之间的并发性。仿真结果表明：相比于现有的自适应即时调度方法C3，RS具有更优的性能，有效地降低了键值操作的尾延迟。

附图说明

图1是RS键值调度方法框架图；

图2是ORA理想即时调度方法存在的问题；

图3是Poisson流量下的延迟对比图；

图4是服务器等待队列长度累积分布函数图；

图5是键值操作在客户端等待时间累积分布函数图；

图6是不同节点数目下尾延迟对比图；

图7是Pareto流量下的尾延迟对比图。

具体实施方式

下面结合附图对本发明的具体实施方式做进一步详细描述：

图1为本实施例中RS键值调度方法框架图，该方法设计的主要步骤如下：

首先，本实施例在客户端维护一个服务器等待队列长度的阈值TQs，当服务器返回键值响应给客户端时，会携带服务器的等待队列长度Qs。客户端通过比较Qs与TQs的大小分布式地调节客户端允许发送键值操作数目的上限值TOSK。对于TOSK的调节，在Qs≤TQs时，代表服务器资源还没有被充分利用，客户端需要增加TOSK值以最大化服务器的利用率，然而，如果采用线性增加的方式，可能会导致TOSK更新过大，客户端发送过多键值操作到服务器，从而使得服务器重载，因此，本实施例根据公式(1)采用相对平稳的方式缓慢增加TOSK，以探测服务器容量的最大值。当Qs＞TQs时，代表服务器已经超过负载阈值，此时需要快速降低TOSK以避免服务器超载的情况，因此根据公式(2)采用乘法减少的方式更新TOSK。

其中，C表示比例因子，本实施例中设置为4*10^-12，β表示乘法因子，本实施例中设置为0.4，ΔT表示上一次TOSK下降以来经过的时间间隔，TOSK_max表示上一次TOSK下降时的值，本实施例中其初值设置为2.5，本实施例中TOSK初值设置为1，而TQs在本实施例中设置为客户端数目的一半。

接下来，每台客户端会维护一个存放键值操作的等待队列。OSK表示客户端已经发送请求但还未接收到响应的键值操作数目。当客户端满足OSK<TOSK时，则选择在队列中等待时间最久的请求进行调度，这样能够保证在单个客户端发送的是等待时间最久的操作。服务器会将收到的键值操作暂时存放到优先级队列中，记录生命周期为键值操作在客户端与服务器的等待时间之和，服务器会为来自不同客户端的请求根据生命周期赋予优先级，并将这些请求添加到优先级队列中，优先服务生命周期最长的请求，即为所有客户端中等待时间最久的请求。

此外，由于服务器的性能是动态波动的，如果在很长一段时间内服务器的性能一直较差，此时客户端连续收到的键值响应中携带的Qs，会一直满足Qs＞TQs，此时，TOSK逐渐下降到一个很小的值，这可能会使得当服务器性能由差变好时，客户端不能够及时地调度键值操作，导致服务器利用率丢失。此时本实施例采用降低TOSK更新频率的方式避免上述情况，具体地来说，本实施例根据客户端连续收到满足Qs＞TQs的键值响应的数量，来对TOSK调节的频率进行调整：当持续收到n个满足Qs＞TQs的键值响应时，则接下来在收到2ⁿ个键值响应后才调节TOSK。例如，假设当前收到了1个满足Qs＞TQs的键值响应，那么接下来在收到2¹个即2个键值响应后才调节TOSK，如果接下来又收到1个满足Qs＞TQs的键值响应，那么改为收到2²个即4个键值响应后才调节TOSK，以此类推。

最后，在客户端数目较多的高并发场景下，即使每台客户端均发送一个键值操作也可能会导致服务器负载增大，造成很大的尾延迟，此时TOSK会被调节为一个小于1的值，本实施例采用概率发送机制。具体地，以TOSK的值来作为键值操作被直接发送到服务器端的概率值。举例来说，如果当前TOSK的值为0.7，那么当前待发送的键值操作被直接发送到服务器的概率即为70％，如果该键值操作恰好为30％的未被直接发送的情况，那么就让其在客户端等待一段时间后再进行调度，等待时间设置为(1-TOSK)*RPT，其中RPT表示客户端在收到键值响应时记录的当前键值操作的延迟信息。这里提到的延迟信息，是当前键值操作从客户端发送至服务器端起，到客户端收到该键值操作的键值响应为止所经过的时间。

图2通过一个实例阐述了理想即时调度方法ORA存在的问题，假设在T1时刻，服务器A和服务器B的瞬时服务时间分别为1ms和3ms，客户端需要将200个键值操作分配给两台服务器，此时服务器A会收到150个请求，服务器B会收到50个请求，这200个键值操作将在150ms内服务完成。然而，由于服务器的性能是动态波动的，假设在30ms后，服务器A和服务器B的瞬时服务时间分别变为3ms和1ms，此时服务器A和服务器B分别剩余120个和40个键值操作，剩余的键值操作需要在360ms内完成，完成200个请求则需要390ms，显然ORA并不能做到最优调度。这是因为ORA只实现了在键值响应返回给客户端这一时刻下的最优调度，当键值操作在服务器排队等待时，服务器性能状态发生了变化，此时之前的调度已经不是最优调度了，进而导致ORA并不能够达到最理想的效果。此外，当客户端数目增加到200时，每个客户端至少发送一个键值操作到服务器，则一共会发送200个键值操作到服务器A，此时服务器A的尾延迟就会达到200ms。这是由于随着客户端数目增大，键值操作的并发性增大，这可能会导致服务器负载突然增大进而降低键值操作的尾延迟。

那么假设现在存在一个中心调度器，并可以将所有客户端的请求全部暂时存放到中心调度器中，即不会存在由于客户端数目增大导致的并发性问题。且中心调度器能够实时地知道服务器的状态，只有当服务器的等待队列长度为0时才在中心调度器中调度请求，那么这样就可以确保服务器A和服务器B在150ms内将200个键值操作服务完成，即能让服务器在最短的时间内将键值操作服务完成，有效地避免了服务器性能随时间变化导致调度不理想的问题。那么将设置有这样一个中心调度器的理想化的方法称为C-LWTF方法，即在客户端与服务器中添加了一个中心调度器，假设中心调度器能够实时获取服务器的负载信息，同时中心调度器维护一个FIFO队列，当键值操作到达客户端之后，所有客户端中的键值操作均直接进入中心调度器中的等待队列进行排队，排队顺序即为键值操作到达客户端的先后顺序，只有当服务器的负载为空时，C-LWTF才从中心调度器中调度等待时间最久的请求执行键值操作，从而实现任何情况下的最优调度。当然，在实际情况中是并不存在也无法实现这样一个中心调度器的，故本实施例基于这一中心调度器即C-LWTF方法的思想，重新架构了键值存储系统的调度框架，提出了基于接收端驱动的键值调度方法RS。

基于以上设计，本实施例在C3方法开源仿真代码上实现了所提出的RS方法，并对RS方法进行了实验评测。默认场景的参数配置如下：首先使用400个负载生成器模拟键值操作到达客户端，其到达间隔服从Poisson分布，接下来，服务器设置可以同时处理4个请求来模拟并发处理请求的过程；服务器的平均服务时间服从以4为均值的指数分布，为了模拟服务器性能随时间动态变化的场景，仿真中模拟每隔500ms，服务器的平均服务时间有50％的概率变为原来的3倍。此外，默认场景下，客户端与服务器数目均设置为150，副本因子设置为3，每一轮测试60万个键值操作。最后，仿真中统计5次随机种子结果的均值与方差，以平滑随机因素带来的影响。本发明将RS方法与C-LWTF方法、C3方法、ORA方法进行了不同场景下的比较分析。

首先，本方法在默认的流量到达间隔服从Poisson分布场景下，测试了各方法的延迟效果，如图3所示，C-LWTF在各个百分位下，均具有最低的延迟。RS在第99分位、第99.9分位的延迟相对于C3分别改进了18.1％、26.7％，在第50分位的延迟比C3约高4ms。可以发现，RS对C3尾延迟的改进效果更加明显，在中值延迟上也只是个位数增加。接下来，本发明统计了RS与C3的等待队列长度累积分布函数图，如图4所示，RS能够将服务器的队列长度控制在130以下，而C3的队列长度最高可达到600，这是因为C3的反馈信息具有时效性问题，在服务器性能比较差的时刻，客户端与服务器的交互不够频繁，可能会影响客户端读取服务器反馈信息的准确性，而RS通过接收端驱动的方式有效地缓解了服务器重载的情况，大幅降低了服务器的队列长度。此外，本发明还统计了键值操作在客户端等待队列中等待时间的累计分布函数图，并与键值操作的延迟进行对比，如图5所示。其中约20％的键值操作到达客户端时没有被立即发送给服务器，而是选择存放在客户端等待队列中，以寻找更好的调度时机。因此RS有效控制了服务器的负载，避免了羊群效应。

其次，为了进一步验证RS效果的可扩展性，本发明测试了不同节点数目下各方法的尾延迟对比情况，如图6所示。可以发现，RS可以使用分布式算法公平地调节TOSK参数，即时在节点数目很大时，也能够有效地控制客户端之间的并发性，在不丢失服务器利用率的情况下，让请求在客户端等待更优的调度机会，有效地降低了键值操作的尾延迟。

最后，本发明在流量到达间隔服从Pareto分布的场景下测试了各方法的尾延迟效果，如图7所示。Pareto分布具有流量突发的特征，相比于Poisson分布更容易导致大量键值操作在较短时间内到达服务器引起服务器重载。这时，RS将键值操作存放在客户端等待队列中，让其等待更优的调度时机。相较于C3方法，极大地降低了键值操作的尾延迟。在99.9％分位延迟结果中，RS方法甚至优于理想的即时调度方法ORA，这是因为在流量突发的场景下，即使是ORA方法也不能够有效地控制客户端之间的并发性。

综合以上的仿真结果，本发明所述的RS方法，能够在服务器具有高负载或低性能时，通过将键值操作存放在客户端队列的方式有效地避免了服务器重载问题。此外，RS分布式地调节TOSK参数，使客户端之间达成了良好的协作性，有效地解决了键值操作的高并发问题。相比于现有的键值调度方法C3，RS在各个场景下均具有更优的性能，进一步改善了键值操作的尾延迟。

Claims

1.一种基于接收端驱动的键值调度方法，其特征在于，包括以下步骤：

A1：当用户请求到达客户端后，生成键值操作，然后执行步骤A2；当服务器的键值响应到达客户端时，执行步骤A3；

A2：检查当前客户端记录的OSK值，如果OSK＝0，执行步骤A4；否则将键值操作存放到客户端用于保存键值操作的键值队列中，然后返回步骤A1；其中OSK是指已从客户端发送请求但还未接收到响应的键值操作数量；

A3：根据当前Qs和TQs的大小，并基于TOSK的变化情况来调整TOSK，如果调整后的TOSK<1，执行步骤A5，否则执行步骤A6；其中TOSK为客户端允许发送键值操作数目的最大值，TQs为服务器端等待队列长度的最大值，Qs为服务器返回键值响应时携带的服务器端等待队列长度；

A4：如果当前TOSK≥1，则直接将生成的键值操作发送给目标服务器，然后执行步骤A7；如果TOSK<1，则采用概率发送机制来发送生成的键值操作，然后执行步骤A7；

A5：如果OSK＝0，则采用概率发送机制来发送客户端的键值队列中等待时间最久的键值操作，并执行步骤A7；如果OSK≠0，则不发送键值队列中的键值操作，然后返回步骤A1；

A6：如果OSK<TOSK，发送在客户端的键值队列中等待时间最久的键值操作，并执行步骤A7；如果OSK≥TOSK，则不发送键值队列中的键值操作，然后返回步骤A1；

A7：在键值操作被发送到服务器之前，将键值操作在键值队列中的等待时间携带在键值操作上，同时发送至服务器，然后执行步骤A8；

A8：当服务器收到的键值操作时将其保存在服务器端等待队列中，并对等待队列中所有的键值操作计算在客户端与服务器的等待时间之和作为优先级的值，按照优先级从大到小依次服务键值操作，将其键值响应发回给客户端，返回步骤A1；

所述的步骤A3中，TOSK通过以下公式进行调节：

其中，C表示比例因子，β表示乘法因子，ΔT表示上一次TOSK下降以来经过的时间间隔，TOSK_max表示上一次TOSK下降时的值，TQs基于客户端数目进行设置；

所述的步骤A4和A5中的概率发送机制，是以TOSK的数值来作为键值操作被直接发送至服务器端的概率值，若键值操作未被直接发送，则让其在客户端等待T_wait后再调度给服务器，T_wait＝(1-TOSK)*RPT，其中RPT表示客户端在收到键值响应时记录的当前键值操作的延迟信息。

2.根据权利要求1所述的方法，其特征在于，所述的步骤A3中，若客户端连续收到的键值响应中携带的Qs均满足Qs＞TQs，则降低TOSK调节的频率。

3.根据权利要求2所述的方法，其特征在于，所述的降低TOSK调节的频率，是根据客户端连续收到满足Qs＞TQs的键值响应的数量，来对TOSK调节的频率进行调整：当持续收到n个满足Qs＞TQs的键值响应时，则接下来在收到2ⁿ个键值响应后才调节TOSK。

4.根据权利要求1所述的方法，其特征在于，所述的步骤A5中，如果OSK＝0，但客户端的键值队列中没有未发送的键值操作，则直接返回步骤A1。

5.根据权利要求1所述的方法，其特征在于，所述的当前键值操作的延迟信息，是当前键值操作从客户端发送至服务器端起，到客户端收到该键值操作的键值响应为止所经过的时间。