富国银行旧金山湾区技术

缩放 .NET Core 应用程序和微服务的极致性能

适用于 .NET、Java 和 Node.js

伊克巴尔汗
总裁兼技术传播者

今天的服务器应用程序需要非常快速地处理大量事务。其中许多是每天为数百万用户服务的 Web 应用程序。其他的是为数百万移动应用程序或物联网 (IoT) 智能设备提供服务的微服务。

这些应用程序中的大多数现在都部署在 Kubernetes 等容器中，以简化和自动化部署、扩展和管理。而且，选择部署环境已从本地转移到领先的云，如 AWS、Azure、谷歌云等。

了解如何通过消除与数据存储和数据库相关的性能瓶颈以及微服务应用程序不同部分之间的通信来开发满足当今极端性能要求的此类应用程序。

概述

非常感谢 Mike 和 Jason，让我有机会与富国银行旧金山湾区技术集团这样一个重要的团队交谈。正如迈克所说，我在 Alachisoft 我向迈克和杰森解释的阿拉奇这个词有点像印地语单词 Ellachi 或 Elaichi，它是一种香料名称小豆蔻。所以，很多年前我们只是给公司命名，我们想想出一些独特的东西，所以我们想出了 Alachisoft.

我们的产品实际上是 NCache. 所以，我不打算谈论 NCache. 今天的演讲是关于“如何将 Web 应用程序和微服务扩展到极致性能？” 如果您使用 Java、.NET 开发这些应用程序， .NET Core 或 Node.js，那么你来对了。

什么是可扩展性？

所以，在我进入实际谈话之前，让我们先了解一些定义。首先是：什么是可扩展性？可扩展性实际上是高应用程序性能，但在峰值负载下。因此，如果您的应用程序在只有 5 个用户的情况下执行超快，那么除非您在 5000、50,000 或 500,000 个用户的速度下具有相同的超强性能，否则它并不是真正可扩展的。如果您的应用程序可以做到这一点，那么它是可扩展的，显然我们希望我们的许多应用程序都是可扩展的，我将继续讨论。

什么是线性可扩展性？

下一个定义是“什么是线性可扩展性？” 这更像是一个应用程序架构和部署术语。如果您的应用程序架构正确，它将是线性可扩展的，这意味着如果您需要增加每秒事务容量，这意味着您可以处理多少用户？您可以处理多少个应用程序请求？如果您想增加，您只需添加更多服务器，并且您添加的每台服务器都会以线性方式增加每秒事务容量。

所以，没有阻塞，没有瓶颈。显然，读取与写入曲线是不同的，但它们都是线性的。如果你能做到这一点，你的应用程序是线性可扩展的，这是我们绝对想要的。

什么是非线性可扩展性？

这是我们不想要的，如果您以存在一些瓶颈的方式构建应用程序，那么，当您增加应用程序的负载并添加更多盒子时，某些东西开始屈服并且您的应用程序启动放慢速度，事实上，它甚至有时甚至崩溃。

所以，我们绝对不希望我们的应用程序被设计成非线性可扩展的。

谁需要可扩展性？

好的，既然我们已经了解了可扩展性的含义，接下来要了解的是，谁需要它？哪些应用程序需要可扩展性？

Web应用程序
最常见的应用程序是 Web 应用程序。这些适用于像富国银行这样的银行或与我们合作的其他银行，如花旗集团、美国银行、巴克莱银行和东京银行。这些是面向客户的应用程序，您有 wellsfargo.com，这是针对消费者银行业务和小型企业的，这些 Web 应用程序需要能够处理大量用户而不会放慢速度。因此，这些应用程序在极端负载下以超快的速度执行是非常重要的。
网络服务/网络 API
第二是 Web 服务，Web API 应用程序。这些通常用于为许多移动应用程序或任何其他调用它们来执行某些任务的应用程序提供服务。所以，如果你有，假设富国银行有一个用于消费者银行业务的移动应用程序，该移动应用程序必须与某个后端通信，而今天的后端很可能是 Web 服务。显然，我不知道，但我假设是这样，因为与我们合作的许多其他银行都有这种情况，其中 Web 服务是处理此移动应用程序请求的那些。而且，它们具有完全相同的灵敏度。他们需要能够在不减速的情况下处理大量负载。
微服务
微服务是近来非常热门的流行词，我稍后将多谈一点，但本质上，你正在以一种新的更好的方式重新构建 Web 服务，让我这个时候就这么说吧。
服务器应用程序
第四种类型的应用程序是您可能拥有的任何其他服务器应用程序。这些可能是，服务器应用程序正在执行批处理。这些可能也在处理实时交易，但它们属于其他类别。但是，它们也具有相同类型的每秒事务吞吐量要求。

因此，如果您正在开发这四种类型的应用程序中的任何一种。还有一些其他的，比方说，你可能正在做实时机器学习和人工智能，但我不打算在这次谈话中讨论这个，我们没有足够的时间。但是，假设你有这四个应用程序，你肯定需要它们是可扩展的。而且，这就是他们要讨论的话题。就技术而言，Web 应用程序一般都是用 Java 或 ASP.NET 开发的，ASP.NET Core, 作为 ASP.NET 和 Node.js 的新版本，其他三种类型都是 Java 或 .NET/.NET Core, 微服务要么是 Java 要么 .NET Core 因为它是新技术。

微服务简介

对于那些不知道微服务是什么样子的人，我只是想给你一个简要的架构视图。而且，对于那些这样做的人，请耐心等待。因此，微服务之所以如此受欢迎，是因为它们允许您将单体应用程序分解为字节大小的微服务，并且每个微服务都与其他微服务分离。而且，这种脱钩意味着他们不会互相打电话。他们有自己的通常逻辑数据库。他们不必将物理数据库分开，但至少在逻辑上，他们通常有自己的。一些微服务可能使用 NoSQL database, MongoDB 或其他东西。其中一些将使用关系数据库、SQL Server、Oracle、DB2。其中一些可能会使用遗留的大型机数据。

因此，解耦要求它们通过某种事件总线相互通信，这就是右侧的管道。并且，它们被移动应用程序、单页 Web 应用程序或 Java、.NET 或 Node.js 中的标准 MVC Web 应用程序通过 API 网关调用。所以，这只是对微服务是什么的一个很好的看法。而且，我将探讨它们如何与传统上的其他应用程序具有相同的可伸缩性问题。

应用部署环境

我想快速接触的另一件事是因为我想围绕我将要讨论的内容放置上下文，那就是多年来我们必须解决的不同类型的部署环境。我已经这样做了 15 年多了，而且最长的时间都是在本地，完全控制的数据中心。即使是现在，与我们合作的许多银行仍然拥有自己的数据中心。但是，几乎每个人都在迁移或至少计划迁移到云端。一些中小型企业迁移到公共云。许多大型企业，尤其是金融服务和银行通常更喜欢私有云部署。事实上，我们合作的一些银行，他们更喜欢 Pivotal Cloud Foundry 或 Red Hat Open Stack 类型的框架上的私有云，这让他们可以完全控制私有云环境，无论在哪里私有云存在。无论它作为租用空间存在于公共云中，还是位于他们现在拥有的数据中心之上，或者是其他东西，它都给了他们自由。但是，无论哪种方式，他们都将走向云端。

而且，Kubernetes 是我稍后也会接触到的东西，但是它正在成为另一个流行词，就像微服务一样。因为，它是一种非常强大的技术，可以简化您的 Dev Ops。它还为您提供环境可移植性。因此，无论您做什么一次，都适用于各种环境。无论您是在本地，还是在任何云中，您都拥有相同的部署环境。而且，在 Kubernetes 中，与我们合作的许多银行都更喜欢更中立的云平台产品，例如 Tanzu Kubernetes 或 Red Hat OpenShift。因此，我稍后将讨论这些概念，作为我们正在讨论的可扩展性主题的一部分。

可扩展性问题

好的，那么，让我们回到我们谈到的实际问题，即是否存在我们需要解决的可扩展性问题？就在这里。但是，它不在应用层。它不在应用程序架构中。它在数据存储中，成为瓶颈。而且，当我说数据存储这个词时，我指的是关系数据库或大型机遗留数据库或数据。 NoSQL databases，它们没有相同类型的瓶颈，并且被越来越多地使用。但是，不幸的是，它们不能解决整个可扩展性问题。

可扩展性瓶颈

如果您看到这张图片，您会发现关系数据库和遗留大型机成为瓶颈的原因是，与应用层不同，您可以在其中添加更多服务器。假设您将此处的 Web 应用程序部署在多服务器负载平衡环境中，您也以相同的方式拥有 Web 服务和微服务。

同样，我现在不是在谈论他们的环境，只是给你一个多服务器的逻辑分解。因此，能够添加更多服务器意味着应用层永远不会成为瓶颈。但是，随着您增加该层的大小，数据存储变得越来越成为瓶颈。而且，即使 NoSQL 不会成为瓶颈，之所以不能解决所有问题，是因为， NoSQL 要求您将数据从关系型机中移出大型机。在理想的世界中，这应该不是什么大问题，但它是一个大问题。大多数企业不能完全摆脱关系。他们不能完全离开大型机。他们可以使用 NoSQL 作为一些数据的组合可以放入 NoSQL database 但是很多数据必须继续存在于关系数据库和大型机中。而且，只要这是真的，那么这意味着我们必须提出的任何可扩展性解决方案都不能成为 NoSQL database. 它必须是其他东西而不是 NoSQL database. 它必须与关系数据库和遗留大型机数据库一起使用。

微服务瓶颈

微服务，正如我向您展示的架构，即使它们没有为您提供内置的可扩展性。即使它们具有与 Web 服务或 Web 应用程序相同的性能瓶颈。除非他们使用 NoSQL database，当然他们不会有，但是，即使他们必须与大型机对话以获取遗留数据，而且其中许多人将继续与关系数据库对话。而且，它们还有一个额外的潜在瓶颈，即用于相互通信的事件总线。

如果你有一个非常高的事务环境，那么事件总线也可能是一个瓶颈。如果您没有为事件总线制定正确的解决方案。

可扩展性解决方案

所以，幸运的是，有一个解决方案，那就是内存分布式缓存。而且，我会详细说明为什么会这样？但是，让我，只是提出一些主张。它是一个解决方案的原因是因为它非常快。它提供线性可扩展性，并为您提供高可用性。因此，这就是它成为可扩展性问题解决方案的三个原因。而且，在像 Wells Fargo 这样的大型企业中，使用内存分布式缓存还有一个额外的好处，您实际上可以将它用作跨多个应用程序的数据共享平台。我会再讨论一下，但这是一种附带好处，或者是使用它的附带好处。主要原因是可扩展性。

内存中分布式缓存

那么，内存中的分布式缓存如何提供这个答案呢？解决这个问题的方法是什么？它是一个解决方案的原因是因为内存中的分布式缓存首先在内存中，所以它非常快。内存比甚至更快 NoSQL databases。其次，它是分布式的。内存中的分布式缓存实际上是多个低成本缓存服务器的集合。而且，每个缓存服务器都不是服务器的数据库类型。这些更像是网络服务器，4 到 8 个核心，有时甚至更多。 16 到 32 GB 的 RAM。为每个应用程序获取尽可能多的它们，并将其创建为应用程序的超快速和高度可扩展的基础架构。一旦你有了应用程序层，你可以在这里看到 Web 应用程序、Web 服务、微服务和数据库，无论这些是关系的，这些是旧的还是 NoSQL。甚至 NoSQL，正如我所说，它不如内存中的分布式缓存快。

那么，内存中的分布式缓存有什么作用呢？它创建了一个由这些缓存服务器组成的集群，并且该集群将所有这些缓存服务器的内存、CPU 甚至网卡容量汇集在一起。就像应用层一样，就像 NoSQL database, 虽然比 NoSQL database，随着事务容量的增长，您只需不断添加更多缓存服务器。所以，现在你突然有了一个冗余，而且，最重要的是，因为它是在内存中的，它必须以一种智能的方式提供数据复制，我会稍微回顾一下，以确保如果有任何一个缓存服务器下降，您不会丢失任何数据。因为否则，任何内存存储都没有价值。因为，如果您仅仅因为一台服务器宕机而丢失数千兆字节的数据，这并不是一个非常有吸引力的解决方案。因此，内存中的分布式缓存不仅可以分发数据，还可以在不影响性能的情况下以智能的方式复制数据和可扩展性。

因此，通过将内存中的分布式缓存作为基础架构的一部分，现在您突然有能力消除该瓶颈，80% 的数据读取将进入分布式缓存。 20% 用于实际数据库，因为数据库仍然是主数据源。因此，您对该数据所做的任何更新都必须针对旧式大型机的关系数据库或 NoSQL. 但是，有时甚至超过 80%、90% 的读取或写入流量只能被限制在分布式缓存中。而且，突然之间，您的应用程序不再感到任何瓶颈。

所以，这有点像现在的基本应用程序架构模式，如果你希望你的应用程序能够扩展，你必须有一个内存中的分布式缓存。

分布式缓存可扩展性

这些是一些可扩展性基准数 NCache，在这里您可以看到仅使用 4 到 5 个节点，您每秒可以执行 2 万次操作。而且，因为它是一个线性比例，所以，如果你想达到 4 万，只需再添加 5 个节点。而且，如您所知，每秒 2 万次操作是一个相当高的事务负载，如果您的大多数应用程序能够保持这种负载，那么您 90% 的应用程序都会在这种类型的负载中感到满意。也许有些人不会，他们需要更多。而且，当他们需要更多时，只需添加更多服务器。

分布式缓存的常见用途

所以，我希望到现在为止，我已经让你相信内存中的分布式缓存就应用程序架构而言是一个好主意。那么，接下来想到的或第一个问题是，好吧，作为应用程序开发人员，我该如何利用它？因为，这些都是关于应用程序的。如何使用分布式缓存来利用？

应用数据缓存
因此，您可以通过三种常用方式使用分布式缓存。第一个是应用数据缓存. 这是我刚才所说的最常见的方式。也就是说，无论您从数据库中读取什么数据，都将其保存在缓存中，因此下一次，您只需从缓存中读取它，非常简单。而且，无论您更新什么，都会同时更新缓存和数据库。

现在，您需要立即了解一件事，对于应用程序数据缓存存在一个独特的问题，即现在数据存在于两个地方，一个是主数据库，它可能是您的关系数据库， NoSQL 或旧式大型机，一个是缓存。因此，可能出错的第一件事是缓存可能会变得陈旧。所以，你已经更新了数据，你有一个没有和缓存对话的应用程序，它去更新数据库中的数据，突然缓存得到了陈旧的数据，陈旧的数据真的很糟糕。我敢肯定，你们都知道，银行比其他任何人都更清楚陈旧数据是非常糟糕的。一些陈旧的数据是可以的，但很多陈旧的数据是非常糟糕的。所以，这就是为什么大多数人在考虑缓存时，下意识的反应是好的，我将只缓存只读数据，永远不会改变，或者至少在我的应用程序的生命周期内或其他任何情况下，在很长一段时间内不会改变。好吧，如果这只是您总数据的 10% 到 15%。如果您只缓存 10%、15%，那么您并没有真正利用分布式缓存。您必须能够缓存可能每 5 秒更改一次的数据。或者，甚至比这更早。因为，即使是 5-10 秒，你也可以读 10 遍。而且，当您将其乘以您的应用程序每天处理的数百万个事务时，您将节省大量的数据库访问以及您将如何获得可伸缩性。

所以，任何不解决这个问题的分布式缓存都会跳过这个挑战，即缓存不应该过时，它应该总是新鲜的，这将迫使你不要完全使用它。所以，这是首先要记住的。
Web 应用程序特定缓存
第二个用例是 Web 应用程序。而且，Web 应用程序最常见的用途是招生面试. 无论你有 Java、ASP.NET、ASP.NET Core 或 Node.js，他们都希望将会话保存在快速且可扩展的存储中。而且，分布式缓存比其他任何东西都要好得多。无论是 Java 或 .NET 还是没有 Node.js。而且，还有其他的东西，比如页面输出缓存. 还有实时网络应用程序。在 .NET 的情况下，这称为信号R，您可以使用分布式缓存作为平台来共享事件。

但是，当 Web 应用程序不是应用程序数据缓存时，当 Web 应用程序将其数据存储在分布式缓存中时，它需要解决不同类型的问题。也就是说，现在没有数据库拥有该数据的副本。缓存是主存储。缓存作为主存储意味着如果缓存服务器出现故障，您将丢失该数据。这是不可接受的，您不希望仅仅因为缓存服务器或 Web 服务器出现故障而丢失用户会话。如果您想获得高可用性，您需要让缓存具有将数据智能地复制到多个服务器的功能。因此，如果任何缓存服务器出现故障，您不会丢失该数据。所以，这是重要的部分。应用数据缓存面临不同的挑战。 Web 应用程序特定的缓存有不同的挑战。
发布/订阅消息、CQ 和事件
而且，第三个用例是你可以使用，这是很多人根本不知道的，你可以使用分布式缓存作为发布/订阅消息平台和活动。我们讨论过，我将向您展示即使是微服务，他们也需要进行 Pub/Sub。因此，如果他们将分布式缓存用作 Pub/Sub 消息传递平台，并将其用于应用程序数据缓存，那么 Pub/Sub 消息传递将不会成为他们的瓶颈。

还有很多其他消息传递产品具有很多消息传递功能。而且，分布式缓存并不匹配所有这些功能，但分布式缓存的作用在于，它为那些只需要在此微服务或 Web 应用程序环境中共享的消息创建了一个非常快速的内存消息传递平台。因此，这是一个更简单的环境，您无需将这些消息保留数小时。它们可能只需要在接下来的几毫秒内共享。但是，事务活动如此之多，以至于如果没有真正的内存分布式架构，消息传递平台本身就会成为瓶颈。因此，现在除了数据存储成为瓶颈之外，您的消息传递平台也是一个瓶颈。所以记住这一点。而且，消息传递平台也有与 Web 应用程序特定缓存相同的问题，通常，无论作为消息保存什么，它在数据库中都没有备份副本。好吧，它可能是数据库中已经存在的某些数据的转换版本，您可能能够重新创建它，但是您不想这样做。因此，您不想丢失这些数据，也不想丢失这些消息。因此，这就是为什么一个好的分布式缓存不仅要快速且可扩展，而且还必须为 Web 特定缓存以及 Pub/Sub 消息传递提供智能复制。

Kubernetes 和分布式缓存

以下是我们如何拥有一个运行 Web 应用程序和微服务并使用分布式缓存的 Kubernetes 环境。所以，这个绿色区域是一个 Kubernetes 集群。而且，Kubernetes 有集群的概念。在每个集群中，您有多个部署。因此，这三个矩形矩形中的每一个都是一个部署。因此，有一个 Web 应用程序部署，有两个微服务部署，一个分布式缓存部署，还有一个用于微服务的 API 网关。

我不打算详细介绍 Kubernetes 的工作原理，但基本上，在这样的环境中，微服务正在使用分布式缓存来进行应用程序数据缓存和 Pub/Sub 消息传递。然而，Web 应用程序将分布式缓存用于应用程序数据缓存和 Web 会话。

大多数 Web 应用程序没有发布/订阅消息因为，Pub/Sub 消息传递通常需要某种稳定的服务器进程才能相互交谈。但无论如何，他们中的一些人可能会，但大多数人不会。但是，用于应用程序数据缓存的相同缓存基础设施可用于 Web 会话，也可用于 Pub/Sub 消息传递，在这种情况下，如您所见，这些是作为 Pod 的 Docker 实例. 您知道，这些可能是 Windows 或 Linux 机器，这取决于您对哪种方式的偏好。如今，大多数银行都将一切都转移到 Linux 上，甚至 .NET Core 因为，它支持Linux。现在您可以同时拥有 .NET 和 Java 应用程序，当然还有 Linux 上的 Node.js。

因此，对于服务和 Web 应用程序以及托管分布式缓存，这就是 Kubernetes 环境的样子。我想在这里指出的一件事是，存在于 Kubernetes 中的分布式缓存必须与 Kubernetes 兼容。它必须实现他们所谓的 Kubernetes Operator。 NCache 有它。因此，无论您查看哪种分布式缓存，都要确保它与 Kubernetes 兼容。

应用数据缓存概述 (API)

所以，这是我唯一的编码幻灯片。我不会比这更深入地编写代码。整个想法是，好吧，应用程序数据缓存是分布式缓存的主要用例，您正在开发的每个应用程序都应该使用它。无论是 Web 应用程序、Web 服务还是微服务。而且，您可以看到这是分布式缓存具有的一个非常简单的 API。

缓存连接

ICache cache = CacheManager.GetCache(“myDistributedCache”);
cache.Dispose();

获取数据

Employee employee = cache.Get<Employee>("Employee:1000"); 
bool isPresent = cache.Contains("Employee:1000");

写入数据

cache.Add("Employee:1000", employee);
cache.AddAsync("Employee:1000", employee);

cache.Insert("Employee:1000", employee);
cache.InsertAsync("Employee:1000", employee);

Employee employee = (Employee) cache.Remove("Employee:1000");
cache.RemoveAsync("Employee:1000");

你有一个缓存句柄，你做cache.Get，cache.Contains。有一个键，它通常是一个字符串，你得到一个值，一个值可以是一个对象，它可能是一个 .NET 对象，它可能是一个 Java 对象，它可能是一个 JSON 文档。 Node.js 显然在 JSON 中工作。但是，您甚至可以让 .NET 和 Java 应用程序将其对象或数据存储为 JSON。而且，这实际上允许您甚至将其用作数据共享平台，因为您有一个 Java 应用程序来存储，比如说，一个客户对象，它是一个 Java 客户对象。当它存储在分布式缓存中时，比如说 NCache 它被转换成一个 JSON 文档，然后当一个 Node.js 或一个 .NET 应用程序或 .NET Core 应用程序想要获取它他们得到它......比方说， .NET Core 应用程序会将其作为 .NET 客户对象或 JSON 文档获取，而 Node.js 可能只会获取 JSON 文档。所以，简单就在那里，获取、添加、插入、删除尽可能简单。因此，使用分布式缓存的学习曲线非常快。

应用数据缓存的特点

我将快速介绍应用数据缓存中的一些关键领域，因为如果您要使用分布式缓存，最大的用例是应用数据缓存。而且，您需要注意什么？第一个，正如我所提到的，有两个数据副本，一个在数据库中，一个在缓存中，那么如何保持缓存的新鲜度呢？

到期（绝对和滑动）
第一个是称为過期几乎每个分布式缓存都有一个特性，通常是绝对到期. 有人称其为 TTL 或生存期到期时间。另一个到期时间称为滑动到期这不适用于应用程序数据缓存，更多的是用于会话类型的情况，如果在一定时间内没有人使用它，您想要使对象过期。但是，绝对过期，你对缓存说我知道我正在缓存的这些数据在接下来的五分钟或接下来的五个小时或 24 小时内不会改变。无论数据的性质是什么，您都可以指定它。并且，在该时间结束时，缓存将自动过期。因此，应用程序可以添加它并继续前进。应用程序不必担心跟踪所有数据。所以，这是每个缓存都应该拥有的最小值，而且大多数缓存都拥有它。但问题或过期的限制是你只是在做出有根据的猜测。在某些情况下，这没关系，因为数据不会经常更改，但正如我之前提到的，真正的好处在于缓存事务数据。因此，在交易数据中，您希望能够更加准确。
将缓存与数据库同步
分布式缓存应该有的另一个特点是它应该在一定程度上了解你的数据库，以便它可以与它缓存的任何数据同步，如果该数据，数据库中的相应数据发生变化，那么缓存应该自动从缓存中删除该项目，以便下次您的应用程序需要它时，它不会在缓存中找到它，它将被迫从数据库中获取它，或者缓存应该重新加载它。而且，只有通过我要讨论的另一个功能才能重新加载，它被称为通读和通写. 但是，如果您可以将缓存与数据库同步。

因此，您可以通过两种方式进行同步。一种是基于事件的。因此，如今大多数数据库现在都有数据更改事件。 SQL Server 有，Oracle 有，MongoDB 和 Cosmos DB 都有。 Cosmos DB 将其称为更改提要，MongoDB 将其称为更改流，SQL Server 将其称为 SQL Dependency 和 Oracle，我认为将其称为数据库通知之类的。

因此，如果您的分布式缓存正在利用数据库中的这些功能，那么它可以在其缓存项目和数据库记录集之间创建某种关系。因此，当该数据更改时，数据库会通知分布式缓存该数据已更改，请注意您自己的副本。因此，您的缓存可以将其删除或从数据库重新加载，如果数据库没有事件作为功能，那么您可以使用轮询作为另一种机制。
处理关系数据
您要做的第三件事是，如果您正在缓存关系数据，则存在一些与关系相关的数据完整性问题，一对多，一对一。所以，如果你可以告诉缓存这个项目，我有这个客户对象，我有这个订单对象，它们是相关的。因此，如果应用程序删除了客户对象，缓存会自动删除所有订单。所以，这样一来，缓存中就没有所谓的悬空引用了。就是这样，如果你能做到这一点，那么你的缓存将再次永远是新鲜的。
SQL 查询
因此，有了这些功能，如果您的缓存至少具有前两个功能，那么您将有信心将所有类型的数据放入缓存中。而且，一旦您有信心，您就会开始将大量数据放入缓存中。而且，一旦您将大量数据放入缓存中，就会出现另一个问题，即现在仅根据键查找数据是不够的。因此，您希望能够像在数据库中一样查找数据，即 SQL 查询。对于 .NET， .NET Core 还有一个LINQ。因此，如果您可以根据对象属性搜索数据。你可以说给我所有的客户对象，城市是旧金山。然后它更像是一个数据库。您还可以搜索参考数据。您可以搜索很多查找数据。因此，如果您可以搜索数据，现在缓存变得更加友好。您对缓存越来越多的数据感到更有信心，因为您可以找到它。因为，如果您不能执行 SQL 查询，那么您的应用程序会突然变得非常复杂。您必须跟踪您存储的每个密钥。
组、标签、命名标签
另一个方面也是同样的关系，您希望能够对相关数据进行分组，以便您可以一次获取所有数据。因此，不同的分布式缓存提供了组、标签和名称标签的概念，然后您可以获得与该标签匹配的所有内容。或者从缓存中全部删除或从缓存中获取。因此，通过快速查找数据的能力，除了键之外，一旦您开始缓存越来越多的数据，它就变得非常重要。
通读和通写
这就是我所说的功能，通读、通写功能。这个特性的重要性在于，比方说……让我先解释一下这是什么。因此，当您拥有分布式缓存时，如果您没有此功能，那么您的应用程序会读取所有数据并将其放入缓存中，并使用它更新数据库。但是，随着您使缓存与多个应用程序越来越相关，现在缓存应该......如果缓存可以变得更加自给自足，它可以自行处理，那么这将简化应用程序。然后，您有多个应用程序，它们只是将缓存视为主数据源的内存表示。你知道，正如我所说的大型机、关系或 NoSQL. 所以，他们把这个内存中的分布式缓存作为键值存储，这非常简单非常简单，它都在内存中，所以它非常快并且分布式缓存能够读取数据，如果它不可用-through 是在分布式缓存中注册的代码。因此，分布式缓存调用您的代码，它会进入数据库并读取相应的项目。所以，假设你做了一个缓存。获取某个键并且该项目不在缓存中，缓存将调用 read-through 从数据库中获取它。
后写
同样，您也可以使用缓存来更新缓存中的数据，还可以更新数据库中的缓存。而且，后写是它的更高级版本，其中缓存更新同步发生，但数据库更新异步发生。
缓存加载器/刷新器
缓存加载器和刷新器也是另一种预热缓存的方式。当您启动缓存时，您将使用所有数据填充它，因为您知道您将始终拥有。因此，这样您就不必每次都调用 read-through。因此，一旦您加载了数百万个对象的缓存，那么缓存刷新器是另一个功能，它可以根据您指定的任何业务规则定期更新该数据的某些子集。这些可能是基于事件的，也可能是基于时间的，无论您的业务逻辑是什么。您可以说，好吧，去从主数据源获取数据的最新副本。

现在，在许多这些情况下，您会遇到这样的情况：如果数据不是对业务非常敏感，那么可以有一些陈旧的副本，如果它不是太晚或太多延迟的话。但是拥有这三个特性，通读、通写和缓存加载器/刷新器，突然之间你有了一个非常智能的缓存。正如我已经提到的，它可以进入并从多个数据源加载自身，并且不仅可以在应用程序中使用，而且可以跨多个应用程序使用。

所以，正如我之前提到的，有多个应用程序是附带的好处。使用内存中分布式缓存的附带好处。那么，这意味着什么？这意味着现在分布式缓存成为跨多个应用程序的通用基础架构。所以，当应用程序需要相互共享数据时，与其让对方互相调用或访问各自的数据库，只需把它放在一个非常简单易懂的键值存储中，它在内存中，速度超快，可扩展性强。而且，因为我提到的所有功能，通读、通写、缓存加载器、刷新，以及所有其他 SQL 搜索，所有这些都使它成为类似数据库的东西，但它不是主数据源。

所以，在数据共享平台中，缓存不是主缓存。它只是其他大师的副本，但仅用于共享目的。而且，我知道现在很多企业都非常关注整合多个应用程序以拥有一个共同的视图和一个共同的功能。

我知道与我们交谈过的许多银行都希望了解跨多个应用程序的客户旅程。那么，这些应用程序如何相互通信呢？他们可以相互共享数据的中心点是什么？它必须是内存中的东西。如果它不在内存中，它将成为另一个瓶颈。而且，内存中的美妙之处在于您可以随时重新启动它，并且不会丢失数据。因为，它只是从主数据源重新加载数据。但是，它将使自己可用。而且，因为它是冗余的，所以它会复制到多个服务器上。要知道，完全丢失分布式缓存的概率非常非常低。而且，我将介绍一些其他功能，您实际上可以在多个区域、多个数据中心、一个在旧金山、一个在纽约等等中拥有相同的缓存。而且，这样，如果您有任何灾难恢复情况，我知道我在新闻中看到几年前你们面临着相当大的停工。嗯，这样的情况需要您进行真正的灾难恢复。因此，所有内容都必须跨多个区域复制。而且，当您将分布式缓存用于数据共享目的时，该分布式缓存也应该出于多种原因进行复制，我会谈到这一点。但是，对于大公司，尤其是像富国银行这样的大公司来说，这是一个非常重要的附带好处，可以将多个应用程序整合在一起。而且，您也可以拥有多个这样的，因为您是一家如此大的公司，您可能没有整个公司的大师，或者您可能。或者，您可能在公司的某些部分拥有多个这样的数据来共享数据。

分布式缓存架构

既然我已经讨论了可以使用分布式缓存的所有方式，那么就其架构而言，您应该期望一个好的分布式缓存是什么？

高可用性

第一是高可用性。因为，分布式缓存正在实时生产环境中使用，如果它不能为您提供真正的高可用性，您需要对它非常怀疑，高可用性意味着分布式缓存正在创建的集群必须有一个 peer-对等架构。如果它没有点对点架构，如果它有一个主从的东西，那么一旦主死了，你知道，从变成只读或不可操作。因此，添加或删除服务器的能力，任何服务器在运行时都是非常关键的。

线性可伸缩性

第二是线性可扩展性，它来自于对数据进行分区。我将转到下一张幻灯片并讨论它。所以分区有两种方式，一种是不复制的分区，另一种是有复制的分区。因此，正如我所提到的，分布式缓存为您提供冗余和智能复制。

什么是智能复制？智能复制意味着每个数据都是……数据被分区，每个分区都备份到不同的服务器上，所有这些都是动态的。所以，它是自愈的。因此，当您添加新服务器时，会创建一个新分区并创建新副本，并且会自动平衡数据。

所以，这里有一个例子。假设您从一个两台服务器缓存集群开始，并且想要添加第三个，因为您的事务负载正在增长。添加第三台服务器后，它会自动创建第三个分区。现在你有了三个分区。所以，复制品也必须重新调整它。所有这些都是动态或自动发生的。

而且，同样地，假设您想要它或一台服务器由于某种原因停机。假设服务器 3 宕机，分区 3 宕机。一旦分区 3 关闭，副本 3 就会变为活动状态。而且，现在您有两个服务器和三个分区的异常情况。所以，现在它必须自动将自己合并回两个分区和两个副本。所有这些都应该在没有任何人为干预的情况下自动完成。如果它需要人工干预，那么它并不是真正的高可用性。 NoSQL databases，因为它们是必须处理持久存储大量数据的数据库，所以它们不提供这种动态重新分区。而且，没关系 NoSQL database. 但是，它不适用于内存存储。就服务器数量而言，内存存储必须更快、更敏捷地上下移动。

广域网复制

这是您拥有多个站点的高可用性。因此，如果您在站点 1 中有一个分布式缓存，例如在旧金山，并且您希望有站点 2，那么您可以有一个主动-被动或主动-主动。我们以前看到的主动-被动更多，现在几乎每个人都因为云而转向主动-主动。让基础设施运转起来要容易得多。所以，人们只有活跃的网站。

在主动-主动挑战中更多的是因为双方可能正在更新相同的数据，因此必须在分布式缓存中内置一些冲突解决能力 NCache 但是，您需要意识到这一点，要获得真正的高可用性，您必须超越一个数据中心，并且必须进入多个数据中心。

在许多情况下，您可能没有两个数据中心可能不够用，因此，如果您有三个或更多数据中心，您仍然需要具有相同的主动-主动复制能力。因此，如果任何一个数据中心出现故障，其他两个数据中心应该能够接管负载，然后您应该能够恢复该数据中心并让它重新加入，您的用户应该不会看到任何中断。

如果您可以通过分布式缓存实现该目标，所有这些都是动态的，无需任何人工……当然，恢复数据中心需要人工干预。但是，当数据中心出现故障时，不应该有人为干预，才能真正实现高可用性。如果它甚至下降了五分钟，那是不可接受的。

我的演讲到此结束。我已经尽可能快地保持它，这样我们就剩下一些时间了。我只是给你一些总结性的想法。我认为我想强调的主要内容是，对于我所讨论的这三个用例，我强烈建议您开发的每个应用程序都必须具有内存中的分布式缓存。而且，理想情况下，您还应该将其用于跨多个应用程序的数据共享。而且，无论哪种方式，即使在同一个应用程序中，您也应该尝试拥有多个站点，以确保您在其中进行灾难恢复。

而且，我是根据 15 年的经验来谈论这个的。我们一直在这样做。 NCache 已经进入市场超过 15 年，我们一直在与许多银行合作。我们传统上是一家 .NET 商店，但 NCache 现在完全支持 .NET 和 Java 和 Node.js。 .NET 和 Java 的客户端和服务器端代码以及 Node.js 都只是客户端 API。我的演讲到此结束。

谢谢你，伊克巴尔。我怎么强调都不过分，因为当我们在富国银行走现代化道路时，这个演示文稿是多么及时和相关。非常感谢你的帮忙。团队，如果您有任何问题，我会提醒您，请继续在聊天中提出。我们有一系列问题伊克巴尔。团队有很多问题，这个演示文稿和视频会提供吗？答案是，是的。演示结束后，我们将按需提供给您。我们会将链接发送给您。所以，伊克巴尔，这里有一些问题。

分布式缓存如何处理敏感数据？就像，透明加密是一个问题。

是的，我想我没有时间去讨论，但这也是一个非常重要的方面。像这样的产品 NCache例如，提供保安在多个层面。有身份验证，授权，安全性。有加密。所以，多种加密算法。一些 128 位，一些 256 位加密。有TLS，传输安全。因此，像 Wells Fargo 这样的银行的缓存必须提供安全性，这就是我们与银行合作的原因。这是我们长期以来一直拥有的功能。因此，数据可以被加密。同样，所有这些都是自动的。无需编程即可执行此操作。这些只是配置。但是，分布式缓存必须通过这些不同的特性来解决安全问题。

接下来的问题是，让Oracle等数据库缓存对象和内存，与在Oracle前面有另一个内存缓存有什么区别？基本上，我可以通过为 oracle 分配更多内存来达到相同的结果吗？

我认为关键字是“分布式”。任何非分布式的东西，你都可以快速但不可扩展。这就是为什么我的第一张幻灯片是可扩展性这个词的定义。您可以从 1 个盒子到 10 个盒子再到 50 个盒子作为部署吗？我们的一些客户拥有一个包含 150 台或更多应用程序服务器的应用程序服务器场。而且，您知道，我们还与……顺便说一句，道富银行也是我们的另一个客户，因此，单个数据库服务器的任何内存缓存绝对无法处理。是的，这是使 Oracle 和 SQL Server 以及其他软件快速运行的一个非常重要的特性，但是它们无法扩展。可扩展性只能通过分发来实现。

如何 NCache 性能相比 Redis, Coherence 等市场产品。然后，问题的另一部分是，您的路线图中是否有任何计划来支持其他编程语言，如 Scala 或 Python？其实，让我先回答第二个问题。是的，我们将非常支持 Scala 和 Python。事实上，我们将在今年这样做。在过去的近 10 年里，我们一直在支持 Java。大多数使用的客户 NCache，如果他们是大公司，他们将它用于 Java 和 .NET。尽管如此，他们可能会从 .NET 的角度购买它。所以，这是第一个。

第二个问题是，如何 NCache 性能比较 Redis 和别的？我的意思是，他们都很快。我不会让任何人看起来很糟糕，我认为你们应该进行自己的比较，但是，他们都很快。我想，我要警告你的唯一一件事是，有些玩家，你知道，给你做基准测试的错误印象。例如，我们给出的基准，它们包括完整的往返。因此，如果您正在执行 cache.Get 或 cache.Insert ，除非该插入操作返回到该操作未完成的应用程序。但是，其他一些供应商他们实际上会向您展示比我们更大的基准，但他们会做他们所谓的“一劳永逸”。所以，如果我只是发送它而不担心它，显然我可以做更多的事情。而且，实际上在 Java 方面 Hazelcast 和 Redis 实验室一直在同一点上互相追逐。所以，我将把它留给它。

您曾与其他银行和其他公司合作过，其他合规性问题围绕使用 PCI 数据返回缓存空间中的敏感数据。您在那里遇到过任何法规遵从性问题吗？

其实没有。我的意思是，首先，我们提供所有这些不同的安全功能加密，无论是在数据级别。因为，您可以在缓存数据之前加密数据，也可以在传输级别加密。我们在服务器端也有认证和授权，这就是缓存服务器端。而且，我认为这已经足够了……而且在它之上，一个缓存在一个安全的数据中心内运行。缓存不是任何外部实体都可以访问的。因此，当您将所有这些与缓存在内部运行的事实结合起来时，我们没有任何缓存，而且，您知道，我们有……我的意思是，例如，花旗集团、美国银行和巴克莱银行一直在使用 NCache 现在十多年了，没有任何问题。

它将如何与大型机数据库一起工作？

我认为大型机是你的东西……比方说，你们很可能会……你今天可能有 Web 服务，你可能会开发一些微服务来让应用程序访问大型机。大型机是另一种从大型机获取数据成本非常高的情况。就速度而言，有时如果您的大型机托管在外部，您甚至可能必须按每笔交易或每趟旅行付费。所以，如果你能在你的 Kubernetes 或微服务层中缓存更多的数据，就像我说的那样，减少访问大型机的次数，你不仅会提高性能，而且还可能会节省很多钱。

当添加和删除节点时，如何确保跨内存分布式缓存的数据的一致性和可用性？

所以，至少我可以谈谈 NCache 这 NCache 确保当您添加或删除节点时，正在完成的任何更新，正在完成的任何更改都在我们正在进行状态转移这一事实的情况下完成，例如，我们正在移动分区和东西， NCache 意识到它需要确保所有这些更新都被正确应用，同时确保正在添加节点和状态转移，我们称之为状态转移，它是将数据从一个分区移动到另一个分区的数据平衡也不断发生。所以， NCache 确保它。

当微服务与他们自己的数据库一起分发时，如图所示，这些如何为客户提供全渠道体验？

所以，分布式数据库部分，我认为这些数据库的分布式程度尚无定论。这些数据库将如何分区。因为，正如我在演讲中所说，至少在理论上，每个微服务都可以拥有自己的逻辑数据库，即使它们在物理上可能驻留在相同的数据库服务器上，因为当你部署东西时，你不会拥有100 台不同的数据库服务器，每台用于每个微服务。您将拥有一些统一的数据库服务器。你有分离的事实可能会给你更多的灵活性，就像 NoSQL 但是，对于你能真正摆脱关系数据库的这种限制，你还没有定论。我的预测是您最终将使用相同的关系数据库服务器。您可能有也可能没有逻辑分离。你可能有不同的模式或者你可能有相同的模式，你只是在与不同的表对话，但是数据库服务器仍然是相同的。因此，即使在 Web 服务中，您也正在解决同样的问题，它们将在微服务中解决。我想时间不多了。我不能感谢你。这非常有趣。问题继续涌入，但很明显，我们无法解决所有问题。所以，有了这个，我会把它还给你。