内存中是一组概念，用于将数据存储在应用程序的 RAM 中，并使用磁盘进行备份。 在经典方法中，数据存储在磁盘上，内存存储在缓存中。 例如，具有用于处理数据的后端的 Web 应用程序将数据请求存储：它接收数据、转换数据，然后通过网络传输大量数据。 在内存中，计算被发送到数据 - 到存储，在那里它们被处理并且网络负载较少。
内存中还有哪些其他可能性以及这是什么样的方法？ 弗拉基米尔·普利金 - GridGain 工程师。 本评论材料对于尚未使用过 In-Memory 但想要尝试或对软件开发和架构设计的现代趋势感兴趣的 Web 应用程序后端开发人员非常有用。
注意。 本文基于弗拉基米尔在#GetIT Conf 上的报告笔录。 在引入自我隔离之前，我们定期在莫斯科和圣彼得堡为开发者举办聚会和会议：我们讨论趋势、当前的开发问题、问题及其解决方案。 现在不可能召开会议，但是时候分享过去的有用材料了。
谁使用内存以及如何使用
内存中最常用于需要快速用户交互或处理大量数据的情况。
- 银行 例如，使用内存来减少客户使用应用程序时的延迟或在发放贷款之前分析客户。
- 饰面 使用内存来提高外包数据处理和分析的银行的服务和应用程序的性能。
- 保险公司：例如，通过分析几年来的客户数据来计算风险。
- 物流公司。 例如，他们处理大量数据，通过数千个参数计算货运和客运的最佳路线，并跟踪货运状态。
- 零售。 内存解决方案有助于更快地为客户提供服务并处理大量信息：发货、发票、交易、仓库中数千种货物的存在以及准备分析报告。
- В IoT 内存中取代了传统数据库。
- 制药 例如，公司使用 In-Memory 对药物成分的组合进行分类。
我将告诉您一些我们的客户如何使用内存解决方案以及您如何自己实施它们的示例。
内存中作为主存储
我们的客户之一是美国一家大型医疗科学设备供应商。 他们使用内存解决方案作为主要数据存储。 所有数据都存储在磁盘上，而主动使用的数据子集则保存在 RAM 中。 存储访问方法是标准的 - GDBC（通用数据库连接器）和 SQL 查询语言。
这统称为内存数据库 (IMDB) 或以内存为中心的存储。 此类解决方案有很多名称，但这些名称并不是唯一的。
互联网电影数据库特点：
- 存储在内存中并通过 SQL 访问的数据与其他方法相同。 它们是同步的，只是呈现方式、寻址方式不同。 事务性在数据之间起作用。
- IMDB 比关系数据库更快，因为从 RAM 检索信息比从磁盘检索信息更快。
- 内部优化算法的指令较少。
- IMDB 适用于管理应用程序中的数据、事件和事务。
IMDB 部分支持 ACID：原子性、一致性和隔离性。 但它们不支持“持久性”——当电源关闭时，所有数据都会丢失。 为了解决这个问题，您可以使用快照——数据库的“快照”，类似于硬盘上的数据库备份，或者记录事务（日志）以在重新启动后恢复数据。
创建容错应用程序
让我们想象一下容错 Web 应用程序的经典架构。 它的工作原理如下：所有请求都由服务器之间的网络平衡器分发。 该系统很稳定，因为服务器相互复制并在发生事件时进行备份。
平衡器将来自一个会话的所有请求严格定向到一台服务器。 这是一种会话棒机制：每个会话都与本地存储和处理的服务器相关联。
当其中一台服务器发生故障时会发生什么？
不会因为架构重复而影响服务。 但是我们将丢失失效服务器会话的子集。 同时，与这些会话相关的用户。 例如，一位客户下了订单，然后突然把他赶出了办公室。 当他再次登录并发现一切都得重新做时，他会不高兴。
Web 应用程序需要支持大量用户并且不降低速度，以便他们可以舒适地工作。 但如果被拒绝，则每个后续请求与会话存储进行通信所需的时间都会增加。 这会增加其他用户的平均延迟。 但他们不想等待比以往更长的时间。
这个问题可以像我们的另一个客户（来自美国的大型 PASS 提供商）一样得到解决。 它使用内存中来集群 Web 会话。 为此，它不是将它们存储在本地，而是集中存储在内存集群中。 在这种情况下，会话的可用速度要快得多，因为它们已经在 RAM 中。
当服务器崩溃时，平衡器将请求从崩溃的服务器发送到其他服务器，就像在经典架构中一样。 但有一个重要的区别： 会话存储在内存集群中 并且服务器可以访问故障服务器的会话。
这种架构增加了整个系统的容错能力。 而且，完全放弃粘性会话机制是可能的。
混合事务分析处理 (HTAP)
通常，交易系统和分析系统是分开的。 当它们分离时，主底座就会承受负载。 对于分析处理，数据被复制到副本，以便分析处理不会干扰事务处理。 但复制是有滞后的——没有滞后的复制是不可能的。 如果我们同步这样做，它也会减慢主基地的速度，并且我们不会获得任何奖金。
在 HTAP 中，一切的工作方式都不同 - 相同的数据存储用于来自应用程序的事务负载，以及可能需要很长时间才能完成的分析查询。 当数据位于 RAM 中时，分析查询的执行速度会更快，并且数据库服务器的负载会减少（平均而言）。
混合方法打破了事务处理和分析之间的界限。 如果我们在同一存储上执行分析，则会对 RAM 中的数据启动分析查询。 它们更准确、更容易解释、也更充分。
内存解决方案的集成
一个（相对）简单的方法 - 从头开始开发一切。 我们将数据保存在磁盘上，并将热数据存储在内存中。 这有助于避免服务器重新启动或中断。
当数据存储在磁盘上时，有两种主要情况在起作用。 首先，我们希望能够承受集群或部件的崩溃或定期重新启动 - 我们希望将其用作简单的数据库。 在第二种情况下，当数据太多时，其中一些数据在内存中。
如果不可能从头开始构建所有内容，则可以将内存集成到已经存在的 现有架构。 但并非所有内存解决方案都适合于此。 有三个强制性条件。 内存解决方案必须支持：
- 连接到位于其下方的数据库的标准方式（例如，MySQL）；
- 标准的查询语言，以免重写和改变与存储交互的逻辑；
- 事务性的——保留交互的语义。
如果这三个条件都满足，那么整合是可能的。 我们将内存数据网格放置在应用程序和数据库之间。 现在写请求将委托给底层数据库，如果数据不在缓存中，读请求将委托给底层数据库。
如果快速访问数据及其处理对您很重要（例如，对于业务分析），您可以考虑实施内存中。 对于实现，您可以在设计新架构时使用这两种方法。
来源： habr.com