NCache 建筑
今天我要讲的是 NCache 架构。 NCache 是用于 .NET 和 Java 应用程序的内存中分布式存储。 它速度极快且可扩展。 而且，您可以在高事务服务器应用程序中使用它来提高应用程序性能和可扩展性。
的常见用途 NCache
分布式缓存
两种常见的方式 NCache 用来。 第一个是作为 分布式缓存 您可以在其中缓存应用程序数据以减少昂贵的数据库访问，第二个是 消息传递和流 平台。 在进入架构之前，我将简要回顾一下这两个问题。
-
应用数据缓存
因此，在分布式缓存中，应用程序数据缓存意味着您使用 NCache API 通常只是缓存您的应用程序数据，因此您不必频繁访问数据库，因为缓存比数据库快得多。 它也更具可扩展性，因为它位于内存中，所以速度很快。 它靠近您的应用程序，因此速度很快，并且是分布式的，因此具有可扩展性。 而且，如果您有 .NET 应用程序并且正在使用 EF Core，那么您可以使用 NCache 还通过 EF Core、NHibernate 和 EF 6。 如果您有 Java 应用程序，您可以使用 NCache 作为 Hibernate 二级缓存。 您还可以将 with 用作 Spring Cache，或者可以针对 JCache 对其进行编程。 -
Web 应用缓存
分布式缓存使用的第二部分是，如果您有 Web 应用程序，则可以存储您的 会议在 NCache 接着 NCache 将这些会话复制到多台服务器，以便如果有任何一台服务器 NCache 服务器宕机后，您不会丢失任何数据，但这些会话再次具有可扩展性，因为它是分布式存储，而且显然速度超快。 .NET、Java、Nodejs 等所有语言都提供多站点会话功能。除了会话之外，例如 .NET 6、ASP.NET Core 应用程序可以存储它们的 响应缓存在 NCache 并且，他们还可以使用 NCache 作为 SignalR 背板。 SignalR 适用于实时 Web 应用程序，其中 Web 应用程序必须向客户端发送事件。 然后，如果您使用 .NET 4.8，您还可以存储会话状态， 查看状态, 输出缓存，还有 SignalR。
NCache 适用于关键任务应用程序
让我快速告诉你什么 NCache 好像。 这就是它作为关键任务应用程序的分布式缓存的含义。 我使用关键任务这个词是因为在大多数情况下我们看到客户使用 NCache 在面向客户的非常敏感的应用程序中，它们对其业务非常重要。 所以， NCache 您知道，在这种情况下，这是您非常关键的基础设施的一部分。
而且，正如我所说，这些是高事务性的服务器应用程序。 这些是网络应用程序。 这些是微服务、Web API 或其他服务器应用程序。 显然，您可以使用 .NET、Java、Node.js 或 Python。 而且，这些应用程序正在尝试以 SQL Server、Oracle、Db2、MySQL 或任何其他关系数据库的形式访问您的数据库，或者它们可能正在访问您的遗留大型机数据，或者它们可能正在使用 NoSQL database 例如 Mongo DB、Cosmos DB、Cassandra 或其他。 在这个情况下， NCache 成为分布式缓存......您使用 NCache 作为两个或更多服务器作为单独的缓存层，尽管您不必有单独的缓存层，但您的应用程序可以在同一个框中运行 NCache 并且工作得很好，但更流行的部署架构是有一个单独的缓存层，这只是一种更干净的使用方式 NCache.
因此，假设您从 2 个服务器的缓存集群开始， NCache 簇， NCache 将所有这些服务器的内存、CPU、网卡资源集中到一个逻辑容量中，比方说，您通过应用程序将更多事务负载置于 NCache 这两台服务器都已满，您可以轻松添加第三台服务器，或第四台服务器，或第五台服务器，依此类推， NCache 永远不会成为瓶颈。 这是你无法用数据库做的事情。 数据库无法扩展。 NoSQL 确实可以扩展，但在大多数情况下，我们发现人们出于各种业务原因必须使用关系数据库，而且他们还拥有遗留的大型机。 所以，因为数据存储层不可扩展 NCache 通过让您缓存尽可能多的数据来帮助您的应用程序扩展。 总体目标是有大约 80% 的时间您应该从以下位置找到数据 NCache 而不是去你的数据库。 如果您能够达到该比率，那么您就知道，您已经减轻了数据库的压力，并且您的应用程序将会扩展。
消息传递和流
第二个常见用例，或使用 NCache 是将其用作消息传递和流平台，您可以在其中拥有多个可以通过以下方式相互通信的应用程序 发布/订阅消息通过 连续查询或 NCache 基于事件。 让我告诉你那是什么样子的。 因此，例如，如果您有一个需要执行大量实时消息传递或流处理的高事务服务器应用程序，您可以使用 NCache。 现在也一样 NCache 那是一个分布式缓存，现在变成了一个消息传递和流平台。 同样，它是一个内存中分布式存储。 它线性缩放。 它跨多个服务器复制消息。 实际上， NCache 也有坚持在里面。
因此，这样，您就可以拥有不同的应用程序，例如，Pub/Sub 消息传递是一种非常流行的方式，它是一种方法，它是一种范式，其中您拥有多个发布者和多个订阅者，可以以解耦的方式相互通信。 解耦意味着发布者不知道订阅者是谁，他们只是将消息发布到某些主题，并且这些订阅者可以获得它们。 连续查询也是如此。 那么，这就是两种常见的方式 NCache 用来。
.NET 与 Java 应用程序
现在我们来谈谈如何 NCache 处理 .NET 与 Java 应用程序。 NCache 具有非常独特的本机多平台功能，您会发现它非常有趣，让我详细介绍一下。
.NET版本
NCache 尝试为您提供 .NET 和 Java 的本机解决方案。 我的意思是，当您拥有 .NET 应用程序时，您的整个应用程序堆栈都体验 .NET，那么您除了使用 .NET 之外什么都没有使用。 所以，举例来说， NCache 有一个本机 .NET 客户端，您的应用程序将在您的应用程序上使用它。 这在您的应用程序服务器上运行并且 NCache 已在“C Sharp”(C#) 中开发了此功能，100%。
同样，如果您有使用 .NET 编写的服务器端代码，例如 Read-through、Write-through、Right-behind、Loader/Refresher， NCache 将在其自己的 .NET CLR 进程中运行该代码。 让我告诉你怎么做。 而且，我会反复讨论这个图表。 因此，例如，这是一个 NCache 架构 您这里有一个可能在 Windows 或 Linux 上运行的 .NET 应用程序。 它有一个本土 NCache .NET 客户端。 而且，这是在和一个 NCache cluster 是.NET 版本 NCache 簇。 因此，这意味着服务器端代码也是 .NET。
现在的方式 NCache 是经过架构设计的，这就是为什么它对于多平台本机支持真正强大的原因是有一个缓存进程，有一个管理进程，这些进程与服务器端代码进程是分开的。 而且，还有一个非常高性能的 RPC。 这是一个内存中的 RPC NCache 使用，即 NCache 开发了自己专有的超快 RPC。 这就是缓存与服务器端代码对话的方式。 因此，例如，如果它必须调用 Read-through Handler，则 Read-through Handler 将在此 .NET CLR 进程内运行，以访问数据库获取数据，然后将其传递到缓存。 而且，Write-through、Loader 和 Refresher 也是如此。 因此，您的应用程序拥有的全部体验都是 .NET。
Java版
好吧，让我们切换到Java 端。 同样，您也有了 Java 服务器端代码。 NCache 有一个 100% Java 客户端，可以在您的应用程序服务器上运行，然后以与 .NET 相同的方式运行。 这是Java版。 假设您有一个 Java 应用程序，很可能在 Linux 上运行，甚至可能在 Windows、Docker、Kubernetes 上运行。 因此，该应用程序将嵌入 NCache Java 客户端，正如我在这里所说的，100% 原生 Java，而且这个 Java 客户端与 .NET 客户端基本相同。 它还与 NCache 集群方式与 .NET 客户端使用的集群方式相同 NCache自己专有的套接字协议和 NCache 服务器的架构使得您的服务器端 Java 代码将在其自己的 JVM 上运行。
因此，您将进行的所有开发、测试和调试都将在本机 JVM 进程中进行。 并且，该缓存进程将调用 Read-through 处理程序，该处理程序将进入 Oracle 或 Db2，甚至 SQL Server 数据库并获取数据并将其提供给缓存进程。 再次使用相同的高性能内存中 RPC。 因此，通过拥有一种将 .NET 和 Java 代码封装在它们自己的本机进程中的体系结构， NCache 能够为您提供 Java 和 .NET 的本机堆栈。
而且，对于 Java 应用程序，您可能希望在 Windows 或 Mac OS 上进行开发，并且 NCache 完全支持它，甚至是 Linux，那么你比 .NET 人员更有可能使用 Docker 和 Kubernetes NCache 为您提供 Docker 映像，以及对 Kubernetes、Azure AKS、AWS EKS、Google GKE 或 Red Hat OpenShift 的全面支持。 您可以以非常无缝的方式使用它。
所以， NCache 非常独特。 它为您提供本机 .NET 体验，同时提供本机 Java 体验。 因此，如果您是一家 Java 商店，您不会感觉自己在使用非 Java 产品；如果您是一家 .NET 商店，您不会感觉自己在使用非 .NET 产品。网产品。 这就是它的美丽之处 NCache 它的架构方式。
动态集群
好的，现在让我们进入 动态聚类 部分 NCache 面向高可用性的架构。 然后，等一下，好吧。 所以，第一部分是动态集群。 当我使用集群这个词时，我并不是指 Kubernetes 集群，而是任何其他操作系统级集群。 这是 NCache自己的基于 TCP 的集群。 而且，该集群具有点对点架构。 点对点意味着没有主人，没有奴隶。 主/从的问题是，如果主节点宕机，从节点就会变得无法运行或受到限制，而在对等架构中，每个节点的能力都相同。 显然有一个集群协调器节点，它是最旧的节点，如果该节点出现故障，下一个最旧的节点将被自动选择为集群协调器。 集群协调器负责集群成员资格。 它管理分布图、集群运行状况以及其他一些事情，我将介绍其中的一些内容。
动态集群意味着您可以在运行时向集群添加或删除服务器，而无需停止缓存或应用程序。 没有中断。 而且，当您向集群添加新服务器时，集群成员资格显然会在运行时更新，然后该运行时信息会传播到客户端。 而且，我将在下一张幻灯片中详细讨论这一点。
还有集群连接故障转移功能。 因此，由于这些是套接字，尽管集群服务器通常位于同一子网中且彼此相当接近，但情况可能并非总是如此。 我们确实有客户甚至在不同地区部署了服务器，并且它工作得很好，尽管我们建议在大多数情况下， NCache 服务器之间应该相当接近。 但是，仍然可能出现连接失败的情况。 如果是这样的话 NCache 有重试逻辑，并且有超时。 有心跳逻辑，所有这些都是为了确保它都是动态的。
动态客户端和动态配置
动态客户端连接
动态架构的另一部分是动态客户端。 因此，就像这样，集群能够在运行时添加或删除服务器，您也能够在运行时添加或删除客户端。 客户是什么意思？ 客户是 NCache 在应用程序服务器、Web 服务器上运行的客户端，这是应用程序与之通信的部分。 因此，您可以在运行时添加客户端，也可以在运行时删除客户端而无需停止 NCache、缓存或您的应用程序而不会出现任何中断。 这是第一部分。
动态配置
第二部分是动态配置。 因此，正如我在上一张幻灯片中提到的，当您将服务器添加到集群时，集群成员资格会发生变化。 好吧，这会传播到所有已连接的现有客户端，因此，他们现在知道他们需要连接到一个新服务器。 因此，如果他们选择基于缓存拓扑，他们也可以连接到该服务器。 此外，根据拓扑结构，可能会有分布图。 分布图更多地用于分区缓存和分区副本缓存。 但是，当您添加服务器时，它会更新，并在运行时传播。 并且，还有许多其他配置更改。 您可以执行一个热应用功能，该功能会在运行时传播。 那么，这是第二部分。
客户端连接故障转移
第三部分是，同样存在客户端连接故障转移，其方式与集群连接故障转移相同。 但是，实际上更需要这样做，因为客户端可能不会总是距离集群服务器非常近。 并且，中间可能有一些路由器或防火墙。 因此，客户端和集群之间的连接更有可能中断。 所以， NCache 具有相当智能的重试能力、超时能力。 还有保持活动功能，因此，即使连接中断，客户端也能保持连接，客户端会重新连接到 NCache 簇。
裂脑检测和恢复
动态方面的另一个重要话题 NCache 建筑是裂脑。 裂脑是集群中可能发生的一种现象。
连接断开时发生脑裂
而且，如果您有一个由六台服务器组成的健康集群，那么当其中一些服务器之间的连接由于某种原因中断时，并且只要您有网络连接，它们就可能会中断，就会发生裂脑。 而且，我们一直都看到这一点。 因此，当这种情况发生时，就会形成子簇。 比方说，在这种情况下，有一个 split 1、split 2、split 3。每个子簇都认为自己是幸存者。 因此，它创建了自己的集群协调器并成为一个独立的集群。
裂脑检测
然而，所有这些分裂都记得它们曾经是健康集群的一部分，并且这些服务器并没有自愿离开，它们并没有以平稳的方式离开。 您没有从 NCache 相反，管理工具连接中断。 所以，他们会不断寻找这些服务器，看看网络连接是否恢复。 而且，大多数情况下，五分钟、十分钟、半小时、一小时后，连接很可能会恢复。
裂脑恢复
当这种情况发生时，裂脑恢复就完成了。 并且，这些分裂被合并。 这些子簇以从最大到最小的迭代方式合并，并且，显然存在一些数据丢失，因为这些子簇成为独立的簇，并且现在必须丢失一些数据。 但这一切都是根据您指定的规则自动完成的。
有关裂脑的更多详细信息，请参阅单独的文章 电影 但这可以让你有一个概览。 这是一个非常重要的功能，可以确保您的 NCache 集群保持健康并且可以在发生裂脑时恢复。
缓存拓扑
好的，现在让我们进入 缓存拓扑。 缓存拓扑本质上是数据存储、复制策略以及客户端连接策略。 有四种拓扑，一种是分区缓存、分区副本、复制缓存和镜像缓存。 让我们来看看分区缓存。
分区缓存
分区缓存 基本上整个缓存被分成多个分区，每台服务器都有一个分区。 并且，还有这个桶的概念。 所以，每个分区都有桶。 整个缓存总共100个桶。 因此，根据您拥有的分区数量，这些存储桶将在它们之间平均分配。
而且，这些分区是在运行时创建的，这是其中的重要部分。 因此，当您添加服务器时，就会创建一个分区。 比方说，您从一台服务器开始，只有一个分区，所有 100 个存储桶都在该分区中。 如果您在运行时添加第二台服务器，不仅会更新我在前面的幻灯片中提到的集群成员资格信息，而且现在分布图也会更新。 分布图本质上是哪个分区包含哪些存储桶的映射。 因此，假设您添加了第二个分区，那么分布图现在将发生更改。 分布图实际上是映射到存储桶的哈希图。 哈希映射值范围为桶。 而且，这不会根据您添加的数据量而改变，只有当您更改服务器数量、分区数量或进行数据重新平衡时，它才会发生变化。 因此，分区是动态的。
动态数据平衡
第二部分是动态数据平衡。 因此，因为这都是基于哈希图的，所以根据您使用的键的类型，某些存储桶很可能会比其他存储桶获得更多的数据。 而且，您最终会发现一些分区几乎已满，而其他分区几乎是空的。 并且，当这种情况发生时 NCache 具有可以设置阈值的功能。 比方说，如果某个分区的填充率超过 80%，则删除其中的 20%、10% 或 5%。 不是删除，我的意思是动态平衡它。 因此，数据平衡意味着从分区 1 中取出这些存储桶并将它们复制到其他分区，或将它们移动到其他分区。 因此，数据平衡可确保数据和所有分区相当均匀。
客户端连接到所有分区
在分区缓存中，每个客户端都连接到所有分区或所有服务器。 它这样做的原因是因为它想在一次调用中直接访问它想要的任何项目。 假设它只连接到一台服务器，并且它想要第 3 号物品，它将与服务器 1 通信，服务器 1 将前往服务器 2 并获取它。 而且，这是一个两跳操作，没有像客户端可以直接访问数据所在的位置那样优化。 并且，客户通过分布图知道这一点。 这就是为什么创建分布图是为了帮助客户了解数据在哪里，这样他们就可以直接从那里获取数据。
因此，分区缓存没有复制。 因此，如果任何服务器出现故障，您就会丢失该数据。 没有办法，除非你使用“持久性”，我稍后会讨论这一点。 那么即使是分区缓存也不会丢失任何数据。
分区副本缓存
分区副本（动态）
下一个拓扑是分区副本缓存。 顺便说一句，这是我们最受欢迎的拓扑，因为它为您提供了两全其美的优点。 它为您提供分区，即可扩展性。 而且，它还为您提供复制，即高可用性。 所以，不会有数据丢失。 例如，它与分区缓存相同，一切都是相同的，但每个分区现在在不同的服务器上都有一个副本。 因此，分区 1 位于服务器 1 上，那么其副本称为副本 2，在本例中，即位于服务器 XNUMX 上。因此，就像分区是在运行时动态创建的一样，副本也是在运行时创建的，当分区被添加或删除。 而且，它们显然总是位于不同的服务器上。
另一部分是所有副本都是被动的。 被动意味着没有客户直接与他们交谈。 客户端意味着它们仅与分区通信，然后分区更新其副本。 因此，每当您更新分区中的某些内容时，分区都会在副本中更新它。 并且，默认情况下该更新是异步的。 是异步的，这样可以更快。 首先，客户端不必等待复制发生，其次您可以进行批量复制。 因此，您可以将数百或数千个更新组合在一起，并将它们立即移动或推送到副本。 因为，这次网络旅行的成本比合并数据要快得多或成本要高得多。
异步/同步复制
然而，异步复制显然并不总是一致的。 它最终是一致的，这对于 95% 到 99% 的情况来说已经足够了，并且在 1% 到 5% 的情况下您正在处理非常敏感的数据。 因此，您不需要异步复制，而是需要同步复制。 因此，有一个称为“同步复制”的功能，您可以将其打开，当您这样做时，每当客户端更新分区中的项目时，该操作都不会完成，直到分区首先更新副本。 因此，如果复制失败，操作就会失败。 因此，您知道，如果操作成功，复制也会成功。 所以，这是一个非常重要的特征。
最后，就像分区拓扑、分区缓存拓扑一样，副本上也有动态数据平衡。 因此，当分区动态数据平衡时，副本必须匹配，因为副本始终是分区的相同副本。 因此，他们也会进行数据平衡。
动态分区
现在让我们快速了解一下动态分区是如何真正发生的。 因此，假设您有一个包含两个服务器的集群，其中有 6 个项目，并且您想添加第三台服务器，那么我不会添加更多数据，因为这是另一个用例，这就是数据的样子当您添加另一个节点时转移到其他分区。
假设您添加了一个节点。 所以，现在有第三台服务器了。 因此，创建了分区 3，分区 3 现在从分区 1 和分区 2 获取数据。因此，它从分区 1 获取一些数据，从分区 2 获取一些数据。所以，假设它从分区 3 获取项目 1，从分区 4 获取项目 2并成为分区 3。
现在，它成为分区 3，其副本必须位于不同的服务器上，因此，假设它被放在服务器 1 上。因此，服务器 1 曾经拥有副本 2，它被转换为副本 3，然后副本 2 被移动到服务器 3 中。例如，现在副本 3 将包含 3、4，而不是 4、5、6，而副本 2 将包含 5、6。所有这些都将在运行时动态完成，而应用程序不会看到任何中断。
同样的事情向后发生，如果服务器出现故障，比方说，您有一个三个分区 NCache 集群和服务器 3 宕机了，要么你把它宕机了，要么它宕机了，一旦发生这种情况，因为分区 3 不再可用，副本 3，正如你所看到的，我改变了它的颜色，它变得活跃。 通常，正如我所说，副本不处于活动状态，对吗？ 只有分区是活动的，但现在它变成了分区。 但是，这只是暂时的，因为您不希望在同一个盒子上有两个分区，然后没有副本。
因此，现在它与分区 1 合并，因此，假设项目 3 转到分区 1，项目 4 转到分区 2，您的情况如下所示，此副本 3 现在变为副本 2。因此，同样的事情向后发生，都是在运行时，动态分区，非常非常灵活，非常动态。 这种动态性增加了高可用性 NCache.
维护模式
好吧，虽然动态分区非常有用且非常强大，但是，在某些情况下您不想重新分区，其中之一就是计划维护。 假设您正在打操作系统补丁，该补丁将使服务器停机五分钟或十分钟。 嗯，您知道，您的整个缓存集群可能有数十 GB 的数据。 因此，您不希望仅在那五分钟内重新分区，然后在恢复该节点时再次重新分区。 因此，您可以打开计划维护功能 NCache 在这种情况下，当您关闭此节点时，您必须再次通过管理工具将其关闭，它会触发该副本变为活动状态，但不会重新分区。
因此，它保留为两个服务器配置，其中分区 1 副本 3、分区 2 副本 1，并且该副本 3 实际上是分区 3，这意味着它处于活动状态并且正在运行。 显然，这不是高可用性，因为虽然这里备份了分区1。 分区 2 没有备份，副本 3 也没有备份。 但是，这只是暂时的，因为您只需要 5、10 分钟。 因此，一旦该服务器恢复，它就会回到旧状态，并在再次成为分区时再次成为副本。 这就是定期维护功能的原理 NCache 作品。
复制缓存
下一个拓扑称为 复制缓存。 在此拓扑中，您可以拥有两个或更多服务器，其中每个服务器都有缓存的完整副本，并且每个服务器都处于活动状态，这意味着每个服务器都有与其连接的客户端。 但是，这里每个客户端仅连接到一台服务器。 因为，该服务器拥有整个缓存。 因此，它不需要像分区或分区副本那样连接到两个服务器。
在这种拓扑中，所有读取都非常快，因为整个缓存都在那里，但是更新必须同步完成。 因为，这两个服务器都是活动服务器，所以相同的项目可以同时在此处和此处更新，并且您显然不想陷入数据完整性问题。 因此，它是以同步方式完成的，其中有一个索引方案，有一个索引，实际上就像一个发出的序列号，并且每个项目都以相同的顺序更新。 因此，这使得更新始终能够以正确的方式完成。 但代价是，同步更新意味着如果你有一个客户端更新了 Item 1，那么这个 Server 就会通知 Item 2 更新 Item 1。当两个服务器都成功更新了 Item 1 后，更新才成功，控制权就被控制了。回去。 因此，这意味着它不如分区或分区副本拓扑那么快，但操作可以保证，如果更新成功，则意味着它始终对所有服务器完成。
这种拓扑结构非常适合读取密集型操作。 对于两台服务器集群，即使写入速度也相当快，虽然不如分区副本快，但在大多数情况下相当快。 但是，随着添加更多服务器，更新性能会下降。 实际上，它变得更慢，因为更多的服务器必须同步更新。 所以，这个拓扑有它自己的用途，这就是我们保留它的原因。 我们的许多客户确实在特殊情况下使用它。
镜像缓存
第四种拓扑称为 镜像缓存。 这又是一个非常具体的拓扑。 它只是 2 节点拓扑。 有一个主动节点和一个被动节点。 同样，主动节点拥有整个缓存，并且缓存的副本位于被动节点上。 所有客户端都连接到主动节点，它们更新主动节点的所有内容，并且更新会异步镜像或复制到被动节点。 而且，异步意味着它也像分区副本一样非常快。
在此拓扑中，如果主动节点出现故障，被动节点将自动变为主动节点，并且所有客户端都会自动移动到被动节点或新的主动节点。 而且，这样就没有停机时间，没有中断，这就是所谓的自动故障转移支持，这就是我的意思。 并且，显然，当活动节点恢复时，它再次变为活动状态，同样的事情也会发生相反的情况。
因此，镜像拓扑对于特殊情况也非常有用。 它无法扩展到这两台服务器之外，但它有自己的用途，因为所有客户端都连接到这里，然后您可以在不同的机器上进行复制。 我的意思是这可以用于例如灾难恢复情况。
现场持久性
另一个非常强大的功能 NCache 叫做 现场持久性。 实时持久性仅适用于分区和分区副本拓扑，并且它是实时的，这意味着当您在运行时更新缓存时，持久性存储也会立即更新。 持久存储的更新是异步的。 因此，它不会干扰您的应用程序性能或 NCache 表现。 所以，这就是您的应用程序可以保持非常快的方式。 持久化是在存储桶级别完成的。 因此，有 100 个存储桶代表整个缓存，它们保存在一个 NoSQL 文档存储。 它是基于文件的存储，因此它不是基于服务器的存储。 这不是一个 NoSQL database 服务器，它是一个 NoSQL 文档存储 NCache 用途。 您可以在网络中所有服务器共用的公共位置使用它。 NCache 集群，这样它们就可以依赖同一个持久存储。
这样做的一些好处是，也是提供此功能的原因，第一，无论您要保留什么，您都可以保留整个缓存，并且整个缓存始终会被保留。 您可以说，无论您在缓存中更新什么，您知道，只要有几毫秒的差异，它也会保存在持久存储中。 因此，您可以将其重新加载到不同的缓存中，或者如果所有服务器都出现故障，您可以随时从持久存储中重新启动它们。 除了非常少量的数据外，您不会丢失任何数据。 或者也许您想将缓存从一个环境转移到另一个环境，您可以轻松做到这一点。
另一个好处是它实际上为分区和分区副本拓扑增加了更多的高可用性。 好吧，分区拓扑，我将在这里进行讨论。 因此，正如我之前提到的，分区缓存没有任何复制，因此，如果任何分区、任何服务器出现故障，您就会丢失该分区，对吧？ 好吧，如果你有毅力，那么你就不会。 因为，这些数据的副本也保存在这些存储桶中。 因此，如果该服务器要关闭内存中的存储桶，则会重新分配内存中的存储桶，但显然没有数据发送给其他服务器，现在这些服务器知道这些是空存储桶，其数据存在于持久性存储中，因此，它们将从持久性存储中重新加载该数据店铺。
因此，即使您使用分区缓存，即使服务器出现故障，您也不会丢失任何数据。 而且，您可以享受与分区副本和分区缓存相同的好处。
在这里您将获得的好处是您可以使用更多内存。 您可以在缓存中存储更多数据，因为在这里您必须为副本分配更多内存，而不必在此处分配，但是您必须分配持久性存储。 这就是分区缓存的好处。 分区副本也有好处。 而且，有趣的是，虽然这已经为您提供了高可用性，但如果仅当一台服务器在任何一个时间点发生故障时才会发生高能力，但是，比方说，如果两台服务器同时故障而没有持久性，即使在分区副本中你会丢失数据。 因为，您知道，每个分区只有一份副本，如果两台服务器出现故障，那么您失去的服务器数量将超出您的承受能力。 有了持久性，您就没有任何问题，您只需从持久性存储中重新加载所有数据即可。
显然，在这两种情况下，您都必须记住，每当您从持久性存储加载数据时，您以前有三台服务器，现在有两台。 好吧，数据可能太大，无法容纳两台服务器，这可能是您必须处理的另一个问题，即确保这两台剩余服务器上有足够的内存，以便它可以容纳所有三台服务器的同等内存服务器。 所以，这是唯一的限制。 否则，持久性确实会为分区缓存和分区副本缓存增加价值。
客户端缓存
好的，另一个非常重要的功能 NCache 叫做 客户端缓存。 它为您提供分布式存储环境中的 InProc 速度。 因此，举例来说，您有一个分布式 NCache 集群，您的应用程序在这里运行，这通常是数据库顶部的缓存或您正在执行的其他操作，当您有分布式缓存场景时通常会使用客户端缓存，客户端缓存是在数据库之上的缓存这个缓存集群，它距离您的应用程序非常近。 它位于应用程序服务器或 NCache 客户端框。 而且，它甚至可以是 InProc 或 OutProc，具体取决于您的偏好。 InProc 缓存速度非常快，因为它实际上将数据以反序列化对象的形式保存在堆上。 因此，这就像在堆上放置该对象一样。 它可以变得更快。
因此，InProc 缓存非常快，但同时它的优点在于它与 NCache 簇。 而且，它的同步方式是集群知道的客户端缓存中保存的内容。 因此，如果此客户端缓存中保留的某些内容在集群中的另一个客户端中更新，则集群会通知客户端缓存自行更新。 然后，客户端缓存会异步更新自身。 显然，有几毫秒的延迟，但正如我所说，最终一致性是大多数情况下的模型，并且对于 99% 的情况通常是可以接受的。
如果那不可接受的话 NCache 为您提供……并且乐观同步是默认设置，即存在几毫秒的延迟，并且从技术上讲可能存在数据过时的情况，正如我所说的 99% 的情况下，这是可以的。 但是，比方说，如果情况不好并且您的数据非常敏感，但您仍然想使用客户端缓存，那么您可以使用悲观同步功能，它确保在您的应用程序从客户端缓存获取任何内容之前缓存仅检查是否有该数据的更新版本，这比获取数据本身更快，因为， NCache 然后保留多个版本控制信息。 并且，如果有该数据的更新版本，则客户端缓存会获取它，如果没有，那么它只会从客户端缓存返回它。
您无需更改任何代码即可使用客户端缓存。 它只需插入您的环境，并且非常适合读取密集型情况。 如果您要做更多的读取，至少 5:1、10:1 是理想的，但是当有 1:1 时，比如说，在 Web 会话的情况下，客户端缓存实际上根本没有帮助。 事实上，根本不建议这样做。
广域网复制
多区域/多区域
好吧，另一部分 NCache 是哪里 NCache 不 广域网复制 处理应用程序的多区域或多区域部署。 因此，例如，您可以将应用程序部署在两个不同的灾难恢复站点上，一个是主动站点，一个是被动站点。 而且，您已经有了这个应用程序， NCache 运行它，并且这里有一个未运行的应用程序。 但是，您希望确保如果该站点出现故障，该站点将立即能够恢复负载。 所以，你可以架一座桥。 桥接器本身就是一个 2 节点集群，可以与桥接器位于同一个盒子上 NCache main，或者它可能是一个单独的专用的，这取决于你。 然后，您在此缓存中更新的任何内容都会通过 WAN 异步复制到其他缓存。 所以，这就是主动-被动。
您可以使用主动-主动执行相同的操作。 假设您遇到这样的情况：即使该站点也处于活动状态，您也可以使用活动-活动来执行相同的操作，其中两个站点都可以相互更新。 在这种情况下，也存在冲突可能解决、可能出现的情况。 并且，冲突意味着同一项目、同一密钥同时在两个站点上更新。 如果发生这种情况，桥接器默认应用“最后更新获胜”逻辑。 因此，更新的时间戳较晚者获胜。 但是，例如，如果您愿意，您还可以提供冲突解决和冲突解决处理程序，这是桥将调用的 .NET 或 Java 代码，并且它将数据或对象的副本传递给该解决处理程序然后您可以分析内容以确定哪一个更正确，然后您说，好吧，此更新获胜，然后该更新将应用到两个站点。 只要双方都遵守这一点，就不会有冲突。
NCache 能够以主动-主动、主动-被动或这些的某种组合方式为您提供三个或更多站点。 因此，例如，您至少需要一个主动的，但这些可能都是被动的，也可能都是主动的，或者可能是主动或被动的组合。 而且，同样，当有多个活动时，这可能是冲突解决。
容器（Docker 和 Kubernetes）
最后，容器已经变得非常流行 Docker 和 Kubernetes。 所以， NCache 显然支持它们，因为它们在 Java 和 Linux 端比在 .NET 和 Windows 端更受欢迎，但是，我确信随着时间的推移，这种情况将会改变。 所以，无论哪种方式， NCache 完全有能力在两种环境下处理它。 例如，这是一个典型的 Kubernetes 部署 NCache.
这是一个 NCache 部署。 有 NCache 拥有自己的发现服务。 这些是可以扩展的 Pod，然后您可以在 Kubernetes 集群中拥有应用程序 NCache 客户端，可以是 Azure、AKS、AWS、EKS、Google GKE 或 Red Hat OpenShift。 Red Hat OpenShift 通常是另一个云，例如 AWS、Azure 或 Google，或者可能是另一个云，但是 NCache 支持他们所有人。 而且，这个 Pod 可以是 Linux，这种情况在 Kubernetes 中更常见，并且 NCache 工作得很好。 并且，该应用程序还可以是Linux或Windows。 因此，它们可以是 Linux 或 Windows，Linux 或 Windows。
Docker / Kubernetes（多区域）
与 WAN 复制的启动方式相同，如果您愿意，可以说，由于云，您可以拥有多个可用区域。 您想做一个多区域 Kubernetes。
因此，我们建议的方法是创建一个 Kubernetes 集群，并拥有两个 NCache 部署，可以是主动-主动或主动-被动。 而且，那么这座桥要么完全坐在这里，要么完全坐在这里。 或者，您甚至可以进行桥接拆分，其中一部分位于该区域，一部分位于该区域，然后复制异步发生。
我想这几乎涵盖了今天的主题。 我强烈建议您访问我们的网站并查看 NCache 游乐场 这确实是从浏览器使用实时运行副本的一种非常快速且简单的方法 NCache，你甚至可以获得 2-Node NCache 包含所有工具的集群，无需任何安装工作。 或者如果你准备好了就来这里吧 注册并下载 或 NCache Enterprise 对于 .NET 版本或 NCache Enterprise 对于Java版。 正如我所说，您可以获取适用于 Linux 的 .tar.gz、.msi，也可以获取 Docker。 你只需拉取一个 Docker 镜像即可 NCache。 我的演讲到此结束。 非常感谢。