尽管当前经济环境艰难，但大公司仍在继续将其业务数字化。移动应用程序和个人仪表板已成为不可或缺的服务和通信渠道，大大增加了IT基础设施的负载。有许多方法可以通过提高系统性能来处理此事。其中一个选项是使用内存技术。但它能保证足够的可靠性吗？

大约十年前，每秒1000次查询的容量足以处理银行卡中所有与卡相关的操作。如今，仅在排名前 10 位的银行中进行投资交易，每秒就会生成 5，000 个查询。许多公司和银行用作主要数据存储的传统数据库无法应对来自移动应用程序用户的请求流量增加。为了避免财务和声誉损失，IT部门正在寻找加速现有系统的方法。

对于许多公司来说，解决方案是内存技术。内存方法意味着数据存储和处理在RAM中进行。数据也会写入硬盘驱动器以提高可靠性。这允许实现更好的容量和每秒处理数十万个查询，而传统数据库每秒最多可以处理10-15，000个查询。因此，您可能会问，如果效率更高，为什么不是每个人都使用内存中的解决方案呢？答案很简单：资源。重建传统的数据库基础架构以支持内存中技术需要花费大量的金钱和时间。

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

在这两种情况下，解决方案必须工作得足够快，并且具有足够的容错能力、可伸缩性和灵活性。容错问题的答案是复制的，我们将进一步更详细地讨论。可以在应用或服务级别上实现所需的可伸缩性和灵活性。但复制内置于数据库体系结构中，它会影响整个系统的可靠性和容量。在选择系统供应商时，请注意他们如何实现复制。

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

简单来说，复制是将数据从一个实例复制到其他几个实例---复制。这提高了解决方案的可靠性并减少了数据库的负载。由于相同的数据存储在多个实例上，因此应用或服务可以快速切换到副本，并在主服务器出现故障时继续工作。

您可以使用一个或多个不同供应商的技术设置副本。例如，Oracle 的复制解决方案 GoldenGate 通常与其他供应商的数据库一起使用。但是，您可以使用内存中的技术构建类似的解决方案，并且会更便宜。不同供应商之间的复制提高了解决方案的可靠性。此方法允许您在不重写其主逻辑的情况下加快应用程序的速度。

同步和异步复制

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

使用异步复制时，事务将发送到副本，而不管对用户的响应如何。如果服务器出现故障，则当用户收到有关成功写入的响应时，数据可能会丢失。这就是为什么异步复制对于处理关键信息（如财务操作或客户订单）的系统来说不是一个好的解决方案。

使用同步复制时，主数据库会将有关事务的信息发送到所有副本。仅当所有副本都确认它们已成功执行事务时，复制才被视为已完成。这样，恢复点目标 （RPO） 就是最小的。这可确保所有副本都包含相同的数据，并且在发生故障时不会丢失单个事务。

同步方法也有缺点。等待来自副本的答复会产生滞后，该滞后是确认数的倍数。如果数据库正在等待单个副本，则该操作需要两倍的时间才能完成。如果有三个副本，则需要三倍，依此类推。

内存中同步复制

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

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

使用异步复制时，查询会立即完成，因此它们不需要很多资源。但是，当我们在同步复制中将查询彼此隔离时，每个查询都需要计算资源和内存空间。对于每秒一千个查询来说，这不是问题。但是，当查询数量达到每秒数万个时，这些小费用会显着加载内存并需要大量资源。这就是为什么开发内存中同步复制是我们在Tarantool中完成的一项独特任务。