快速,持续,稳定,傻瓜式
支持Mysql,Sqlserver数据同步

我们如何将多区域读取延迟和网络流量减少50%

请联系QQ:1793040 索取软件

在金融行业等对数据至关重要的行业中,数据存储和访问需要高可用性架构。在此体系结构内,如果服务器出现故障,系统仍可以提供服务。但是,如果发生像地震这样的自然灾害,则可能存在网络分区,甚至更糟的是,数据中心(DC)中的所有服务器都可能发生故障。在这种情况下,为了保证系统可用性,我们需要一个远程灾难恢复架构。而且,最好在数据中心之间保持远距离,这样一个地区的灾难不会对另一个地区造成巨大影响。

但是,此体系结构有两个限制:

  • 高读取延迟。通常,跨区域网络往返时间(RTT)为几十甚至数百毫秒(ms)。
  • 跨区域网络设施涉及高昂的硬件成本。此外,现有设施的服务能力还不够强。因此,分布式数据库的性能不高。跨区域建立或租赁专用网络的成本很高,并且带宽有限。在多区域双活体系结构中,在多个区域之间复制数据可能会导致瓶颈。

在PingCAP的TiDB Hackathon 2019上,我们很有趣地破解了一个项目来缓解这些问题。我们使用Raft算法减轻了TiDB多区域延迟,并且能够优化以下内容:

  • 多区域SQL查询的读取延迟降低了50%
  • 跨区域消息的数量减少了50%。这意味着网络流量减少了一半

在本文中,我们将介绍如何针对多区域架构将读取延迟和网络流量减少一半。如果您有类似的问题,我们希望这篇文章对您有所帮助。

示例多区域架构

在解释技术实现之前,让我们假设一个示例多区域架构如下:

我们如何将多区域读取延迟和网络流量减少50%

一级和二级数据中心

在图中,两个虚线框表示两个DC。

左侧的框是城市A中的主要DC。此DC部署以下内容:

  • 某些TiDB服务器(集群的SQL层)
  • 多数TiKV服务器(用于底层存储引擎TiDB)
  • 在放置驱动器(PD)的服务器(整个集群的管理组件)
  • 筏系列的领先复制品

右边的框是城市B中的辅助DC。其余的TiKV服务器和TiDB服务器在此DC中。用户可以从任何一个DC读取数据,但只能将数据写入主要的城市A。

只能向主DC中的TiDB服务器提出写入请求,然后再将其发送到主DC中的TiKV服务器。这些新更新通过Raft协议复制到辅助DC中的其他TiKV服务器。如果您熟悉此协议,则很容易意识到,如果辅助DC中有N个TiKV服务器,则一次数据更新将被发送到辅助DC N次。这种方法导致高网络流量。

然后,让我们考虑阅读。在TiDB内部,从城市B读取数据的典型过程如下:

  1. 城市B中的TiDB服务器向城市A中的PD服务器发送请求,以获取时间戳Oracle(TSO)信息。它获取交易开始ID start_ts

    此步骤需要一个往返时间(RTT)。

  2. 如下图所示,城市B中的TiDB服务器针对此过程涉及的每个范围,向城市A中的TiKV负责人发送多个并行读取请求。

    此步骤还需要一个RTT。

我们如何将多区域读取延迟和网络流量减少50%

阅读请求处理

我们可以看到,B市的TiKV 追随者没有参与此过程。

此实现有两个问题:

  • 多区域网络带宽高度占用
  • 读取延迟(两个RTT)很高

现在,让我们看看如何解决这些问题。

如何减少多区域网络流量

TiDB 3.1 Beta引入了新的开源功能Follower Read,以减少多区域网络带宽。此外,我们的项目引入了Follower Replication,并成功地将多区域网络流量减少了一半。

通过Follower Read减少多区域网络流量

正如我们之前的文章所讨论的那样,Follower Read允许Region中的任何Follower副本在强一致性读取的前提下满足读取请求。此功能减轻了领导者的负担并提高了TiDB集群的吞吐量。

禁用“从属读取”后,TiKV负责人需要处理每个读取请求。启用该功能后,TiKV负责人仅需要处理一个read_index请求,而不是整个读取请求。通常,read_index请求仅涉及位置信息交互,而无需数据交换,因此它是轻量级的。因此,TiKV引线上的负载应力显着降低。

优化是有效的,如下图所示:

我们如何将多区域读取延迟和网络流量减少50%

启用了追随者读取的读取请求处理

通过跟随者复制减少多区域网络流量

我们之前的帖子提到TiKV集群实现了Raft协议以确保数据一致性。在筏组中,领导者将条目复制到所有关注者,以保持日志一致。将条目复制到Raft组中的大多数对等方时,表示已成功将其写入TiKV。

但是可能会出现问题:有时TiKV服务器在全球部署在不同的DC中,因此跨DC网络的成本和等待时间都很高。由于只有一个领导者,因此消息通常在DC之间传输。

例如,我们需要五个副本以确保生产环境中的数据可用性,以容忍两个副本失败。让我们将城市A中的三个副本命名为A1,A2和A3,将城市B中的三个副本命名为B1和B2。

注意:因为我们必须在数据中心发生故障时确保数据完整性,所以在实际生产环境中,不应将City A中的A1,A2和A3部署在一个数据中心中。但是,这里我们只关心不同城市之间的网络传输,因此让我们忽略这些细节。

在由这些副本组成的Raft组中,城市A中的A1是领导者。A1需要广播进入城市B的B1和B2的条目。此广播至少涉及两次跨DC(跨区域)网络传输,如下图所示:

我们如何将多区域读取延迟和网络流量减少50%

信息广播

对于此问题,我们引入了追随者复制功能,旨在最大程度地减少多区域网络传输。

要实施追随者复制,领导者应了解所有Raft对等方及其DC。

在这里,我们介绍一个新概念:组。每个Raft对等方都有一个对应的组ID。具有相同组ID的对等体位于同一DC中。领导者知道每个筏对等体的组ID。领导者广播消息时,它会选择一个对等方作为组中的关注者代理,并将组成员所需的信息发送给该代理。然后,委托将数据复制到组中的其他成员,如下图所示:

我们如何将多区域读取延迟和网络流量减少50%

跟从者委托进行消息广播

引入跟随者复制后,领导者发送的消息下降了一半。这大大减少了多区域带宽压力,并减少了领导者发送网络消息的开销。

我们如何将多区域读取延迟和网络流量减少50%

邮件下降了一半

实际上,“跟随者复制”实现很复杂。我们将在以后的文章中对其进行详细描述。

我们已经起草了一个评论请求(RFC)文档,以优化Raft协议,并向raft-rs提出了拉取请求(PR)。我们也做出了贡献,以ETCD,筏-RS的上游项目。

如何减少多区域读取延迟

如上文所述,启用“跟随者读取”后,我们可以大幅减少多区域网络流量。但是在我们的示例架构中,TiDB仍然需要跨区域的两个RTT。高延迟是由工程实现引起的:TiDB从PD获得TSO(一个RTT)并读取索引(另一个RTT)。

为了减少高读取延迟,我们在城市A中添加了代理服务,该服务可以处理get_ts_and_read_index请求:

我们如何将多区域读取延迟和网络流量减少50%

优化跟随者之前和之后阅读

通过优化,多区域读取请求的延迟从两个RTT下降到一个RTT。这是因为城市B中的客户端向get_ts_and_read_index城市A中的代理发送一个请求,而不是read_index在收到get_ts响应后发送请求。尽管城市A中的代理仍然需要分配时间戳并ReadIndex一一获取,但可以节省一个RTT。

我们模拟了网络延迟为100毫秒的跨区域网络环境。在优化“跟随者读取”之后,读取延迟从200毫秒减少到100毫秒。

我们如何将多区域读取延迟和网络流量减少50%

将读取延迟降低一半

我们模拟了另一个高延迟网络环境,并测试了准备语句的读取延迟。该执行隐式包含跨区域网络交互操作。因此,如下图所示,读取等待时间从300毫秒降至200毫秒。

我们如何将多区域读取延迟和网络流量减少50%

模拟的高延迟网络环境中的基准

当没有原子时钟可用时,为了保证线性化,需要一个请求来获得TSO。考虑到这一事实,一个RTT是当前架构的最佳结果。

项目评估

TiDB Hackathon 2019第二名

TiDB Hackathon 2019第二名

我们的项目在TiDB Hackathon 2019上获得了第二名,并收到了积极的评价:

“我们很高兴看到多区域读写优化项目使TiDB增强了其多区域架构功能。”

“在社区贡献者的共同合作下,我相信TiDB将来会为客户提供Google Spanner级的用户体验。”

-晓光孙(后端搜索经理制壶)

“通常,我们建议用户在同一个城市或两个城市中的三个DC中部署TiDB组件,并具有五个副本。在三个DC中,一个具有单个副本,其他每个具有两个副本。网络租赁成本是此体系结构的主要投资。在压力测试中,我们发现网络带宽在极端压力下被完全占用。”

“这个Hackathon项目显着减少了DC之间的网络带宽,并减少了TiDB客户的费用。”

–秦天双(PingCAP的高级技术支持总监)

进一步的想法

上面讨论的优化不是最终的实现。除了这些问题外,我们还有更多问题要在多区域体系结构中解决或优化。例如:

  • 减少交互式读取事务到一个RTT的等待时间

    优化跟随者读取后,我们将非交互式读取事务的延迟从两个RTT减少到一个RTT。但是,在交互式读取事务中,直到事务开始才知道涉及的范围。此外,我们无法预测read_index读取请求中涉及的每个范围。因此,我们只能get_tso并行处理第一个读取请求。因此,N + 1个RTT减少为N个RTT,其中N是用于交互式事务的读取语句的数量。

    如果执行以下操作,我们还可以将读取事务的等待时间减少到一个RTT:

    • 查找时间戳和已提交索引之间的关系。
    • 定期维护安全时间戳。时间戳小于安全时间戳的事务已提交或中止。
  • 实施跨DC可扩展性

    在跨DC读取请求的常见方案中,我们不需要最新数据。我们应该弄清楚的是,我们必须提供什么语法,以便在这种情况下,读取请求可以以零RTT本地读取数据。因此,读取数据将不再依赖于主DC,我们可以在不同区域的数据中心之间实现数据库水平扩展。

通过硬件实现的可伸缩性受到限制。只有不断优化软件,我们才能在给定的硬件条件下获得最高的性能。

目前,我们的项目处于孵化阶段。在我们将项目投入运营之后,我们希望TiDB的多区域网络延迟和带宽能够得到显着优化。

相关推荐

咨询软件
 
QQ在线咨询
售前咨询热线
QQ1793040