数据处理速度和可靠性：内存中同步复制

尽管目前经济形势严峻，大公司仍在继续将其业务数字化。移动应用程序和个人仪表盘已经成为不可或缺的服务和沟通渠道，大大增加了IT基础设施的负荷。有很多方法可以通过提高系统性能来应对这种负荷。其中一个选择是使用内存技术。但它能保证足够的可靠性吗？

大约十年前，每秒1,000次查询的能力足以处理银行所有与卡有关的业务。今天，只有排名前十的银行的投资交易每秒产生5000次查询。许多公司和银行用作主要数据存储的传统数据库无法应对移动应用程序用户增加的请求流。为了避免财务和声誉上的损失，IT部门正在寻找方法来加快现有系统的速度。

对许多公司来说，解决方案是内存技术。内存方法意味着数据存储和处理是在RAM中进行的。数据也被写入硬盘以提高可靠性。这可以实现更好的容量，每秒处理数十万次查询，而传统数据库每秒最多只能处理1-1.5万次查询。所以你可能会问，既然内存解决方案的效率高得多，为什么大家不使用呢？答案很简单：资源。重建一个传统的数据库基础设施以支持内存技术需要大量的资金和时间。

大多数大公司的IT格局早在我们所知道的内存方法出现之前就已经形成。许多业务流程都是围绕着过时的系统进行的。将关键系统转移到另一个技术堆栈，不可避免地会导致大量的财政支出。有时，创建一个新公司可能比从一个过时的基础设施迁移更便宜。每个公司都会做出选择：是从头开始建立新的架构，还是更新和改进现有的架构。

在这两种情况下，解决方案必须工作得足够快，并有足够的容错性、可扩展性和灵活性。容错问题的答案是复制，我们将进一步详细讨论。所需的可扩展性和灵活性可以在应用或服务层面实现。但是复制是建立在数据库架构中的，它影响到整个系统的可靠性和容量。当选择你的系统供应商时，注意他们是如何实现复制的。

为什么我们需要数据库复制？

这提高了解决方案的可靠性，减少了主数据库的负载。由于相同的数据存储在几个实例上，如果主服务器发生故障，应用程序或服务可以快速切换到一个副本并继续其工作。

你可以使用一个或几个不同供应商的技术来设置副本。例如，甲骨文公司的复制解决方案GoldenGate经常被用于其他供应商的数据库。然而，你可以用内存技术建立一个类似的解决方案，而且成本会更低。不同供应商之间的复制增加了解决方案的可靠性。这种方法可以让你加快你的应用程序，而不需要重写其主要逻辑。

同步复制和异步复制

有两种类型的复制--同步和异步。内存解决方案通常使用异步复制，因为它不影响服务器的响应时间。从做出改变到在应用程序中看到结果的延迟不到一毫秒，这对用户体验来说是微不足道的。用异步复制实现的关键指标是恢复时间目标（RTO）。

通过异步复制，无论对用户的响应如何，事务都会被发送到副本中。如果服务器发生故障，在用户得到关于成功写入的响应时，数据就会丢失。这就是为什么异步复制对于处理金融业务或客户订单等关键信息的系统来说不是一个好的解决方案。

在同步复制中，主数据库将交易信息发送给所有的复制体。只有当所有的复制体确认它们成功地执行了交易时，复制才算完成。这样一来，恢复点目标（RPO）是最小的。这确保了所有的复制体都包含相同的数据，并且在发生故障时不会丢失任何一个事务。

同步方法也有缺点。等待复制体的回复会产生一个滞后，这个滞后是确认次数的倍数。如果数据库在等待单个副本，操作完成需要两倍的时间。如果有三个复制体，则需要三倍的时间，等等。

内存中的同步复制

任何内存技术的设计都是为了提高性能。同步方法，即数据库等待来自复制体的响应，会导致延迟的加倍增加。因此，同步复制为可靠性牺牲了速度。也许这就是为什么很少有供应商在他们的产品中实施它。

然而，设计良好的同步复制主要影响延迟，对每秒的操作数影响不大。当一个查询在等待同步的时候，其他的查询可以并行运行。如果数据库有查询隔离，它看起来是一致的，用户不会看到中间的状态。

通过异步复制，查询会立即完成，所以不需要很多资源。但是当我们在同步复制中把查询相互隔离时，每个查询都需要计算资源和内存空间。对于每秒一千次的查询来说，这并不是一个问题。然而，当查询数量达到每秒数万次时，这些小的支出就会大大地加载内存，并需要大量的资源。这就是为什么开发内存同步复制是我们在Tarantool这里完成的一项独特的任务。

寻找平衡

毕竟，公司的需求决定了对供应商的选择。异步方法可以在主数据库发生故障时更快地恢复应用程序。如果服务显示的是静态信息，不依赖于用户的操作，那么同步复制是更好的选择。

然而，如果用户可以对服务进行关键性的改变，那么系统的优先级是确保数据在各个副本中的一致性。因此，如果主服务器发生故障，应用程序将继续工作而不会丢失任何事务数据。

即使同步复制可以使内存解决方案与传统数据库一样可靠，但这种方法很少见。