分布式多主关系数据库的底线业务优势

当今的应用程序（包括企业应用程序）需要始终开启且始终可用，并且通常必须为全球用户提供服务，这些用户无论身在何处都希望获得几乎即时的响应时间。

应对这些挑战不仅仅意味着让用户更满意：每个能够解决低延迟和超高可用性的根本问题的企业都会获得直接的底线收益。由于数据库在每个应用程序技术堆栈中都发挥着基础作用，因此解决这些问题最合理的位置是数据库层。实现这一目标的最佳且最具成本效益的方法之一是在分布式关系数据库之上部署应用程序。

我们首先考虑数据延迟的问题。许多应用程序都使用位于单个数据中心或云区域的单个数据库实例运行。靠近数据库运行位置的用户将看到快速响应时间，但位于对面海岸或大洋彼岸的用户将看到更慢的响应时间。对于电子商务应用程序，页面加载缓慢会导致销售损失，因为买家会失去耐心并转到竞争对手的网站或重新考虑购买。对于 SaaS 应用程序，用户体验受损可能会导致客户流失。

分布式“多主”数据库可以配置为在地理上分布的节点集群中运行，每个节点都可以接受读写流量。这使得可以策略性地将数据库副本放置在更靠近用户连接网络的位置。这显着减少了数据延迟，始终实现更快的页面加载，并防止销售损失和客户流失。

现在让我们看看超高可用性。我们这么说是什么意思？显然，应该避免停机，因为这意味着客户的沮丧和业务的损失，具体取决于停机的时间和范围。如果应用程序能够在硬件和数据中心中断后继续运行，则该应用程序具有高可用性。许多应用程序和数据库架构师将在一个或多个地理上分离的数据中心中配置和读取其数据库的副本，以便在主系统停机时进行故障转移。

这种方法存在几个问题。首先，在云中，只读副本可能位于同一区域的附近可用区中。云提供商确实有时会出现整个区域发生数小时故障的情况。事实上，最近几周，AWS 的 us-east-1 区域（最大的）和 Google 的 europe-west-9 区域都发生了这种情况，导致完全依赖它们的应用程序出现数小时的停机时间。架构和实施多区域故障转移解决方案可能很困难，这是许多组织尚未这样做的主要原因。此外，对于许多流行的开源数据库（例如Postgres）来说，在不关闭整个系统的情况下不可能进行