数据规模越来越大？看看如何选择合适的数据库代理

2019-06-18 本文已影响57人 ce2a5fc7b1e4

数据库发展到今天，其高可用性已经变成了人们关心的头等话题。一个项目（比如一个复杂的、需要频繁读写各种数据的量化交易系统）的数据往往分布在不同的数据库实例、甚至是不同的数据中心中。多数据库节点形成的集群可以扩展更多节点，单个节点的失败往往会导致集群需要重新配置拓扑规则。这就引出了一个问题——应用程序如何知道要访问哪个数据库节点？应用程序如何检测数据库拓扑已更改？我们如何保护应用程序免受底层数据库架构复杂性的影响？

不知道从什么时候开始，“中间人技术”的概念变得很流行，而数据库环境开始集成代理。这篇文章将会讨论什么是数据库代理，它们的用途以及如何使用现代代理构建高度可用且高度可控的数据库环境。

一、什么是数据库代理？

代理是处理双方连接通信的软件。在数据库的语境中，代理是位于应用程序和数据库的中间层。应用程序连接到代理，代理将连接转发到数据库。让我们尝试分析这个模式，看看使用代理可能会有什么好处？

对于初学者来说，一个比较大的好处是应用程序仅需要连接代理。在数据库领域，要确定应该将连接引入何处并不容易。很多数据库架构存在可写主库或是存在集群核心角色的主库，也有只读副本。这种需要复制的拓扑结构不断发展。Hardcode（“代码写死”）连接模式不是一个好主意。另一方面，编写代码来跟踪拓扑变化需要仔细规划、设计和测试。这是代理的来源，通过使用代理，应用程序可以连接到它（或代理池），我们希望应用程序能将访问流量从出现故障的数据库路由到还正常运行的数据库。

由于流量由代理中继，后者（代理）也可以是流量本身的重要信息源。它可以提供有关流量的统计信息，例如每秒执行的查询数，执行时间等，还有关于执行时间的统计数据，如95%执行时间，执行时间的最大值、最小值、平均值，所有这些统计数据都基于收集的指标给出来。

高级的代理也可以改变流量本身，当所有内容都通过它们时，这些代理可以为管理员提供对查询的高度控制，查询可以被缓存、重写、重新路由、挂起或终止。这使得DBA可以立即调整流量并对问题作出反应，有时甚至不需要应用程序开发人员修改应用程序并重新部署它。

最后总结一下，数据库代理不仅可以通过向多个数据库路由流量来帮助维持数据库的架构环境，还可以使用代理中创建的流量路由逻辑帮助构建分片设置。如上文所说，高级数据库代理不仅仅是一个数据包路由设备，而且可以通过多种方式的使用，从而改进运营团队管理数据库层的选项。还可以使用代理中创建的流量路由逻辑帮助构建分片设置。

二、数据库代理类型

在我们深入研究如何使用数据库代理的细节之前，本章我们将讨论代理的两种主要类型，将介绍每种类型的示例，和它们之间的主要区别。

第4层代理模型

最初也是最古老的代理模型是工作在ISO / OSI网络模型（传输层）的第4层操作的代理。

这些代理在包级别上工作。它们接收TCP会话，并将流量路由到已经预定义好的后端数据库服务。

这种模型的代理服务器并不关心它路由的内容，它只需要将流量发送到后端并且保持负载均衡就可以了。通常情况下我们可以选择轮询，从一个前端服务到后端服务器建立最少的连接。这种代理的最著名的例子是HAProxy，还有一个更出名的Nginx。

这种代理的主要问题是它们仅在网络层运行。这些代理不感知MySQL协议，也不了解MySQL或MariaDB后端所处的状态。对于复制关系的设置来说，它只可能是主或者副本。但对于Galera集群来说，复制关系将变得更加复杂（Primary, non-Primary, donor or desynced, joining, joiner等）。必须开发外部脚本，才能使这些代理能够理解MySQL后端的状态。

这种脚本的一个例子是Percona的clustercheck及其所有改进版本。缺乏对MySQL协议的理解会导致与代理的连接更加复杂。正如我们前面提到的，理想情况下应用程序将连接到代理并在其中发送所有流量，代理将直接写入单个主机并对所有MySQL后端进行扩展读取。

不幸的是，如果代理无法理解MySQL协议，它就无法将SELECT与其他查询区分开来，这是一个严重的问题。在复制环境中，通常只有一个主机将您的写入发送给主服务器。Galera可以在多写入主机的设置中工作，但有时会有一些情况要求应用程序将所有写入指向一个节点，以减少写入之间的冲突。因此，这种设置对应用程序的透明度较低，因为应用程序必须对SELECT和其他查询进行排序并将它们发送到代理上的正确端口（假设已定义了单独的写入和只读端口）。

SQL-AWARE代理

另一种类型的代理是SQL感知代理。该软件可以理解MySQL协议，并且通常提供与该协议相关的一系列功能。首先，这样的代理应该能够理解MySQL状态。它们设计为区分主设备和从设备。其中一些人还可以跟踪和了解Galera集群的状态。所有这些设计都导致这种代理可以更快，更可靠地响应MySQL拓扑结构。

此外这种代理最受人欢迎的特性可能是，鉴于他们对MySQL协议的理解，代理可以执行读写分离。这使得实现透明代理层成为可能，并确保应用程序不必跟踪与数据库层相关的任何内容。它只会连接到预设好的主机和端口，这就是它需要知道的全部内容。

当然，基于代理可以处理所有通往数据库流量，代理也可以被用于其他事情，例如流量整形（流量整形的典型作用是限制流出某一网络的某一连接的流量与突发，使这类报文以比较均匀的速度向外发送）、查询路由、查询阻塞等。需要注意的是，不同代理之间的特性相差很大。有些像MySQL路由器一样可以进行查询路由，但其他代理不具备这个特性。其他如ProxySQL或MaxScale可用于执行高级任务，并且可以帮助用户改变流量发送到数据库的方式。

通常，SQL感知代理不使用外部脚本来监视或跟踪数据库的状态，它们依赖于内置的测试代码来实现这个功能，ProxySQL和Galera集群监控就是一个例外。ProxySQL 2.0版本依赖于外部脚本，该脚本用来在跟踪Galera节点的状态。内部支持是在ProxySQL v2.0中引入的，直到本文在编写时，它还在处在beta测试版本的状态。

— — — — — — E N D — — — — — —

往期文章：