我们继续尝试使用mitaps的格式。 最近，在拳击场上，我们
与集中式数据总线和Service Mesh
相撞 。 这次，我们决定尝试一些更安静的方法-StandUp，即打开麦克风。 该主题被选择为内存数据库。
在什么情况下应该切换到内存中？ 如何以及为什么缩放？ 哪些是值得关注的？ 答案在演讲者的讲话中，我们将在本文中介绍。
但是首先，想象一下演讲者：
- Promsvyazbank创新与先进技术中心负责人Andrey Trushkin
- Vladislav Shpileva，Tarantool开发人员
- GridGain解决方案架构师Artyom Shitov
切换到内存
金融市场的当前趋势对流程自动化的响应时间和操作提出了更为严格的要求。 此外，当今几乎所有大型金融机构都在寻求建立自己的生态系统。
在这方面，我们亲眼看到了内存解决方案的两个主要应用。 首先是缓存集成数据。 根据经典情况，在大型公司中，有几个自动化系统可根据用户的要求提供数据。 或外部系统-但在这种情况下，大多数情况下的发起者是用户。 传统上，这些系统将以某种方式结构化的数据存储在数据库中，并按需访问。
如今，此类系统已不再满足负载方面的要求。 在这里，我们不应忘记消费者系统对这些系统的远程调用。 这意味着需要修改存储和向用户，自动化系统或单个服务提供数据的方法。 逻辑输出-在内存层级别存储服务使用的相关数据； 市场上有许多类似的成功案例。
这是第一种情况。 从技术角度来看，第二个是有效的业务流程管理。 传统的BPM系统根据预定义的算法自动执行某些操作。 并且在许多情况下会出现问题：为什么这些系统效率不够高，速度不够快？
通常，此类系统将每个步骤（或一小部分步骤，设计为业务交易）写入数据库。 因此，它们与响应时间以及与这些系统的交互联系在一起。 现在，实时同时运行的业务流程实例的数量已超过10年前。 因此，现代业务流程管理系统应具有显着更高的性能，并确保分散式应用程序的执行。 而且，今天所有公司都在朝着大型微服务环境的形成迈进。 挑战在于业务流程的不同实例可以共享并有效地使用运营数据。 在业务流程框架内，将它们存储在内存中的解决方案中是有意义的。
和解问题
假设我们有大量的节点和服务，并且执行了许多业务流程，并且其操作以微服务的形式实现。 为了提高性能，它们每个都开始将其状态写入本地内存实例。 我们得到了大量的本地实例。 如何确保所有人的相关性和一致性？
我们使用分区内存区域。 例如，取决于业务领域。 剪切业务域时，我们确定某些微服务/业务流程仅在负责相应域的区域框架内工作。 这样，我们可以加快缓存更新和整个内存解决方案的速度。
同时，负责该域的缓存以完全复制模式运行-由于跨域分布而导致的节点数量有限，可以确保该模式下解决方案的速度和正确性。 分区和最大碎片有助于解决同步，集群操作等问题。 在大量的节点上
自然，通常会出现有关内存解决方案可靠性的问题。 是的，不是所有的东西都可以放在那里。 为了确保可靠性，我们始终在内存中保留数据库。 例如，对于需要汇总的重要报告问题，这在许多节点上可能很困难。 那么，我们今天的愿景是：
这两种方法的
协同作用 。
还值得注意的是，这两种方法也仅出于对比而并非完全正确。 同时，专注于它们。 先进的容器化虚拟化系统（例如Kubernetes）的制造商和贡献者已经为我们提供了长期可靠存储的选择。 已经出现了用于实施解决方案的良好工业案例，其中以这种虚拟化格式进行存储。
美国最大的报纸之一为读者提供了一个机会，以获取自19世纪该报纸创立以来在网上发布的任何期刊。 我们可以想象负载水平。 他们通过部署到Kubernetes的Apache Kafka平台实现存储。 这是用于存储信息并在大量负载下为大量客户提供对信息的访问的另一种选择。 在设计新解决方案时，该选项也值得关注。
使用Tarantool扩展内存数据库
假设我们有一台服务器。 它接受请求，存储数据。 突然有更多的请求和数据，服务器停止应对负载。 您可以将更多硬件上载到服务器，它将接受更多请求。 但这是一个死胡同，原因有三点：高成本，有限的技术能力和容错问题。 取而代之的是横向扩展：“朋友”来到服务器来帮助它完成任务。 水平缩放的两种主要类型是复制和分片。
复制是指当有许多服务器时，它们都存储相同的数据，并且客户端请求分散在所有这些服务器上。 这是计算而不是数据扩展的方式。 当数据放在一个节点上时，此方法有效，但是客户端请求太多，一台服务器无法处理它。 同样，这里的容错能力也大大提高了。
分片用于扩展数据：制造了许多服务器，它们存储不同的数据。 因此，您可以同时扩展计算和数据。 但是这种情况下的容错能力很低。 如果一台服务器发生故障，部分数据将丢失。
还有第三种方法-组合它们。 我们将集群分为多个子集群，称其为副本集。 它们每个都存储相同的数据，并且数据在副本集之间不相交。 结果是扩展数据，计算和容错能力。
复写
复制可以有两种类型：异步和同步。 异步是指客户端请求不等到数据散布在所有副本上时：写入一个副本就足够了。 一旦数据到达磁盘，再到日志，事务就会成功，并且有一天在后台复制该数据。 同步-将事务分为两个阶段：准备和提交。 在将数据复制到一定数量的副本之前，提交不会返回成功。
异步复制显然更快，因为网络上没有任何内容。 数据将在后台发送到网络，并且日志中记录的事务本身已经完成。 但是有一个问题：副本之间可能会相互滞后，出现不同步的情况。
同步复制更可靠，但更慢且更难以实现。 有复杂的协议。 在Tarantool中，您可以根据任务选择这些复制类型中的任何一种。
复制品的滞后不仅会导致不同步，还会导致母版的无知问题：他不知道如何将自己的更改传递给复制品。 通常以增量方式进行更改-应用更改，并以相同的形式将它们飞到副本中。 但是如果副本不可用该怎么办？ 例如，可以在Tarantool中配置所有内容，该向导将变得非常灵活。
另一个挑战：如何使拓扑复杂？ 例如，Mail.ru具有包含数百个Tarantool的拓扑。 它具有tarantool内核，用于备份的副本狼蛛与之捆绑在一起。 在Tarantool中，您可以创建完全任意的拓扑，使用此拓扑可以完美地进行复制。
分片
现在让我们继续进行数据扩展：分片。 它可以有两种类型：范围和哈希。 范围分片是指使用某个分片键对所有数据进行排序，然后将较大的序列划分为多个范围，以使每个范围具有大致相同的数据量。 每个范围完全存储在任何一个物理节点上。 但是通常不需要这种分片。 而且，它总是非常复杂的。
哈希也有分片。 它仅在Tarantool中提供。 它比分片范围更容易实现，使用和几乎总是合适的。 它的工作方式是这样的：我们考虑记录中的哈希函数，它返回要存储到的物理节点的编号。 存在问题：首先，难以快速完成复杂的查询。
其次，存在重新分片的问题。 有某种分片函数可以返回必须将密钥保存到其中的物理分片的编号。 并且当节点数更改时，分片功能也会更改。 这意味着对于群集中的所有数据，都必须重新计算并再次验证。 此外，在经典分片中，某些数据将不会传输到新节点，而只会在旧节点之间进行混洗。 在传统分片中，无用的传输无法减少为零。
Tarantool使用虚拟分片：数据不是分布在物理节点上，而是分布在虚拟节点上。 虚拟集群中的虚拟存储桶。 虚拟故事被布置在物理故事上。 并且已经可以保证每个虚拟层都完全位于一个物理层上。
这如何解决转售问题？ 事实是，存储桶的数量是固定的，并且严重超过了物理节点的数量。 因此，无论您在物理上扩展集群的多少，存储桶始终足以存储数据并平均分配它们。 并且由于分片功能不变，因此当集群的组成发生变化时，您将不必重新计算它。
结果，我们得到了
三种类型的分片：范围，哈希和虚拟存储桶 。 对于范围和存储桶，存在物理搜索问题。
怎么解决呢？ 第一种方法：仅禁止重新分片。 然后，为了重新分片，您将必须创建一个新集群并将所有内容转移到那里。 第二种方式：总是去所有节点。 但这是没有意义的，因为您需要扩展，并且计算也不会那样扩展。 第三种选择：代理模块，充当存储桶的一种路由器。 您启动它，然后在其中发送一个请求，指示存储桶的编号，它将把您的请求作为代理发送到所需的物理节点。
带有GridGain平台示例的高级内存
该企业还有其他数据库要求。 他希望所有这些都是容错和灾难性的。 他想要高可用性：这样就不会丢失任何东西，以便您可以快速恢复。 还需要容易和廉价的可伸缩性，简单的支持，对平台的信任以及有效的访问机制。
所有这些想法都不是新鲜事物。 这些事情中的许多事情在某种程度上在经典DBMS中实现，尤其是在数据中心之间的复制中。
In-Memory不再是一种启动技术，它是成熟的产品，已被世界上最大的公司（巴克莱，花旗集团，微软等）使用。 假定满足所有这些要求。
因此，如果突然发生灾难，应该有机会从备份中恢复。 而且，如果我们谈论的是金融机构，则必须确保备份的一致性，而不仅仅是所有驱动器的副本。 这样就不会出现在X时刻在某些节点上恢复数据，而在Y瞬间在另一些节点上恢复数据的情况。拥有时间点恢复非常重要，这样即使在数据损坏或特别严重的事故情况下，也要使丢失量最小化。
能够将数据推送到磁盘很重要。 这样群集就不会出现过载，并且继续运行得更慢。 并迅速从磁盘上升，然后已经将数据泵入内存。
有和没有GridGain容错组件时对崩溃的内存中响应故障转移群集应易于水平和垂直扩展。 我不想花钱购买服务器并看着一半的资源处于空闲状态。 我不想让需要管理的数百个进程陷入困境。 从支持的角度来看，我希望有一个简单的系统，并且群集中节点的输入和输出都很容易，并且要开发一个成熟的监视系统。
从这个角度考虑MongoDB。 与MongoDB合作的每个人都知道大量的过程。 如果我们有一个由5个分片组成的带阴影的MongoDB，则每个分片将具有三个进程的副本集（冗余比为3）。 这仅是数据本身的15个进程。 群集配置存储是另外3个进程，总共18个，这不包括路由器。 如果要使用20个分片，欢迎使用63个以上的进程（例如，另外8个，共71个）。
与卡桑德拉比较。 我们采用所有相同的5个分片-这是5个进程和5个节点，其冗余比为3，这在控制方面要简单得多。 我想要20个碎片-这是20个进程。 我可以将群集扩展到任意数量的节点，而不必扩展到3的倍数（或扩展到冗余系数的另一个值）。 与副本集相比，实现和维护起来更容易，更便宜。
此外，您需要信任该系统，以了解每个产品背后的人是什么。 理想情况下，许可证应为开源或开放核。 这样，在供应商死亡的情况下，可以采取一些措施。 如果源代码由一个独立的社区进行管理，这也很好-我们都记得MongoDB和Redis应管理公司的要求如何更改许可证。 Aerospike如何在年初开始对“开源”社区版引入限制。
需要有效访问数据。 几乎所有的人都以一种或另一种形式使用结构化查询语言。 他们最常使用SQL，因此必须尽可能容易地使用这种语言进行修改。 当您不需要分别向每个节点发送请求，但是可以像“单个窗口”一样与群集进行通信时，这将有助于分布式查询的执行。 不用从API的角度考虑，这是一组节点（记住即使在最简单的put / get级别，也没有潜在的复杂SQL查询的情况下，在大容量上使用Memcache多么困难），分布式DDL和ACID保证。
最后，支持。 如果某件事突然不起作用，则该公司只会亏损。 在某些领域，这并不重要，但通常重要的是，要有人对产品及其工作承担责任。 在任何时候都可以提出索赔，并且很快得到了解决。
通过这篇文章，我们将结束哈布雷的Promsvyazbank的一年。 我们通过短视频收集了哈勃罗夫斯克居民的新年祝福：