Redis vs NCache
录制的网络研讨会
作者：罗恩·侯赛因和扎克·汗
NCache 是在高事务 .NET 中非常流行的原生 .NET 开源分布式缓存， .NET Core 和 Java 应用程序。 Redis 由...开发 Redis 实验室，目前由 Microsoft 在 Azure 中使用。 在此网络研讨会中，了解如何 NCache 和 Redis 相互比较。 本次网络研讨会的目标是让您更轻松、更快速地比较这两种产品，特别是在特性、性能、可扩展性、高可用性、数据可靠性和管理等定性方面。
以下是本次网络研讨会的内容：
- 性能和可扩展性
- 缓存弹性（高可用性）
- 缓存拓扑
- SQL & LINQ 搜索缓存
- 第三方集成（EF、EF Core、NHibernate 等）
今天，我们的话题是比较两种非常相似但在很多方面也不同的产品。 所以，我们有 NCache 这是我们主要的 .NET 分布式缓存产品和 .NET Core 应用程序，然后我们将从功能的角度与 Redis. 因此，我们有很多内容要介绍。 我将从平台和技术堆栈开始讨论很多技术细节。 然后我们将讨论聚类。 这两种产品在缓存集群方面的比较以及使用这些产品有哪些不同的好处，比较起来，如何 NCache 更好，然后我将讨论不同的功能。 我们会去 逐个特征比较 关于您可以使用这些产品的不同用例，然后从功能比较的角度比较这两种产品。
对于本次网络研讨会，我选择了 NCache Enterprise 5.0.2，至于 Redis 关注，我们将主要关注 Azure Redis. 那是开源的 Redis 4.0.1.4。 但是，我也会向您详细介绍 Redis 开源项目，以及， Redis 实验室是商业变体 Redis. 所以，我们来比较 NCache 拥有所有这些风格，但我们的主要关注点是 Microsoft Azure Redis, 的托管模型 Redis 您可以在 Microsoft Azure 中获得。
可扩展性问题
因此，在我们开始之前，我将主要介绍这两种产品的介绍性细节。 那么，为什么您需要分布式缓存解决方案呢？
因此，在那之后，您将继续比较不同的产品。 因此，通常情况下，您可能会在应用程序中遇到可伸缩性和性能挑战。 可能是您的应用程序正在承受大量数据负载，尽管您的应用程序层非常可扩展，但您始终可以创建一个网络农场，您可以在应用程序层上添加更多资源，但所有这些应用程序实例都必须返回并与之对话- 结束数据源。 而且，当您需要返回并与那些您看到性能问题的数据源交谈时，因为数据库，通常关系数据库在处理事务负载方面很慢。
存在与它们相关的性能问题，然后在横向扩展方面，例如，如果您需要有很多请求处理能力或围绕我们需要处理大量请求的要求，并且您的应用程序正在生成大量用户负载，数据库并非旨在处理这种极端的事务负载。 这对于可以存储大量数据的存储非常有用，但是在该数据上进行事务负载是数据库不是一个很好的候选者。 它可能会窒息。 它会给你带来缓慢和最终用户体验可能会下降。
因此，您可能会对性能产生影响，而您无法增加应用程序架构中的容量。
解决方案：内存中分布式缓存（NCache)
解决方案非常简单，您可以使用内存中的分布式缓存系统，例如 NCache 这是超快的，因为它在内存中。 因此，与关系数据库或文件系统或任何其他非基于内存的数据源相比，如果它来自磁盘，与将数据存储在内存、内存中相比，它会变得超级 -快速地。 因此，您从中获得的第一个好处是您可以获得超快的性能 NCache.
第二个好处是它是一个缓存集群。 它不仅仅是一个单一的来源。 您可以从一台服务器开始，但通常我们建议您至少有两台服务器并创建一个缓存集群，一旦您创建了该缓存集群，它会有所改善，如果我们只是在所有服务器上分配负载并且您继续在运行时添加更多服务器。
因此，您可以扩展您的容量，您可以，您知道，通过添加更多服务器来增加运行时的容量，您也可以将它与您的后端关系数据库结合使用。 它不能替代您的传统关系数据库，我们将讨论一些用例。
分布式缓存部署 (NCache)
这是一个典型的部署。
我正在使用 NCache 现在作为一个例子，但在本演示文稿中，我们将比较如何 Redis 被部署以及如何部署 NCache 被部署以及这些产品中可用的灵活性是什么。
因此对于 NCache，非常灵活。 您可以选择将其部署在 Windows 以及 Linux 环境中。 它可以在本地使用，也可以在云环境中使用。 它在 Azure 以及 AWS marketplaces。 所以，你可以得到一个预配置的图像 NCache 并开始使用它。 适用于 Windows 和 Linux 的 Docker 容器可用，您可以在需要使用它的任何平台上使用它们。
通常，您的应用程序无论是托管在本地还是云中，都可能是应用服务，也可能是 Cloud service，它可以是微服务，也可以是 Azure 网站，任何类型的应用程序都可以在客户端-服务器模型中连接到它，它位于您的应用程序和后端数据库之间，这是典型的使用模型。 这里的想法是您将数据存储在里面 NCache 因此，您将节省昂贵的后端数据库之旅。 您将尽可能地节省对数据库的访问，并且每当您需要访问数据库时，您总是会访问数据库，获取数据并将其放入缓存中，以便下次数据存在并且您没有去数据库。 并且，因此您的应用程序性能和整体可扩展性得到改善，因为现在您可以访问内存，从而提高性能。 你有多个服务器托管和服务你的请求，你的数据请求。 因此，相比之下，它更具可扩展性。 然后，还内置了高可用性和数据可靠性功能 NCache 协议。
NCache 可以托管在运行应用程序的同一个盒子上。 或者它可能只是一个单独的层。 在云中，首选方法是您使用单独的专用缓存层，然后您的应用程序是，应用程序实例在它们各自的层上运行。 但是，这两种型号都受支持 NCache 被关注到。
一些可扩展性数字。 我们最近在我们的 AWS 实验室中进行了这些测试，在那里我们模拟了读取和写入请求负载，并且我们不断增加负载，当我们看到服务器被最大化时，我们增加了缓存集群中的服务器数量。 因此，从 2 到 3 台服务器，然后从 3 到 4 台，我们能够实现每秒 2 万个请求的吞吐量，而只需 5 NCache 服务器，这不是，这不是一触即发的数据。 这是真实的应用程序数据，但在我们的 AWS 实验室中的应用程序中进行了模拟。 而且，延迟因素也非常优化。 我们能够在微秒级延迟内实现所有这些。 因此，当我们能够实现所有这些负载时，单个请求的性能并没有降低。
常见用例：分布式缓存
一些用例，这是常见的 Redis 以及，但我会谈谈如何 NCache 会比较。
应用数据缓存
您缓存通常从后端数据库中获取的几乎所有内容，并且数据库中存在数据，现在您想要缓存它。 因此，您可以节省昂贵的数据库访问，并且我们已经确定数据库速度很慢，并且在事务负载处理方面不是非常理想的。 我们在这条线上有很多数据库同步功能，但在这里您只需连接到 NCache 并且基本上使用我们的 API 来建立连接，你知道，进行任何数据调用 NCache. 因此，您几乎可以缓存任何内容。 它可以是您的域对象、集合、数据集、图像，任何类型的应用程序相关数据都可以使用我们的数据缓存模型进行缓存。
ASP.NET/ASP.NET Core 高速缓存
然后我们有我们的 ASP.NET 和 ASP.NET Core 特定的缓存。 这又是一个技术用例，您可以将它用于 ASP.NET 或 ASP.NET Core 会话状态缓存。 ASP.NET 或 ASP.NET Core SignalR Backplane. NCache 可以作为背板插入。 ASP.NET Core 您还可以将其用于响应缓存。 IDistributedCache 接口和会话通过 ID分布式缓存 接口，这两个功能也支持 NCache 对于遗留应用程序，您还可以将其用于查看状态和输出缓存。 想向你提出一个快速的问题，罗恩。
我们进来了，问题是 NCache 和 Azure 支持无服务器编程模型？
绝对地。 这是在 Azure 部署方面，您可以将应用程序部署在服务器或应用程序上，就您的应用程序部分而言，这些也可以是无服务器应用程序。 您可以在应用程序中包含我们的 NuGet 包，这些应用程序可以 NCache 在他们需要的时候打电话。 他们甚至不需要安装任何 NCache 或者就应用程序资源而言，有一个服务器设置。 但是，就目前而言， NCache 服务器端部署本身受到关注，因为 NCache 是数据源，因此，它必须有一个 VM 或一组 VM，您的应用程序可以在其中连接、检索和添加数据。
所以，从服务器， NCache 缓存服务器的立场，作为你需要的来源 NCache 服务器，但就您的应用程序而言，那些可能严格是无服务器的，并且没有问题。 甚至是微服务架构。 这是一个非常常见的例子，在微服务中，有很多微服务。 可能有一个 Azure 函数，它只是在执行，它处理大量数据，这些数据可以来自 NCache. 所以，你对待 NCache 作为数据源。 鉴于您的应用程序可以是无服务器的，并且 NCache 与该模型完全兼容。
发布/订阅消息和事件
然后是另一个用例 Pub/Sub 消息传递 这围绕着微服务，因为这是令人印象深刻的用例之一，您可以将消息传递用于无服务器应用程序。 微服务是松散耦合的无服务器应用程序，在它们之间建立通信是一个很大的挑战。 因此，您可以使用我们的 Pub/Sub 消息传递平台，在那里您可以利用我们的事件驱动异步事件传播机制。 多个应用程序可以将消息发布到的位置 NCache 订阅者可以收到这些消息。
因为它是基于异步事件驱动的机制，发布者应用程序不必等待确认或消息被传递，同样订阅者不必等待或获取消息。 他们在收到通知时通过回调获得通知。 所以，它非常灵活，这是您可以使用的另一个用例 NCache 作为您的应用程序的 Pub/Sub 消息传递平台。
NCache 创办缘起
更多细节，然后我们将讨论它们之间的区别 NCache 和 Redis. NCache 于 2005 年推出。它已经在市场上超过 15 年了。 当前版本 NCache 是 5.0，第 15 版。 我们有很多很多的客户。 NCache 也可以在开源版本中使用。 您可以从我们的网站以及 GitHub 存储库下载。
一些 NCache 合作伙伴
我们的一些客户。 你也可以得到一份详细的清单。
平台与技术
接下来我们将讨论如何 NCache 比较 Redis 第一部分是建立在有关该技术的一些介绍性细节的基础上的。 这将是关于分布式缓存技术的信息。 现在我们将直接关注如何 NCache 比较 Redis 我已经制定了一些细分。
所以，我们定义的第一部分是平台和技术，我最初提到我们的目标是 NCache 5.0.2。 所以， NCache 5.0 SP2 是主版本 NCache 网站和从 Redis 我们将使用 Azure 的观点 Redis 作为比较，我们还将讨论开源和 Redis 实验室作为其中的一部分。 大多数这些细节对于不同口味的 Redis.
本机 .NET 缓存
因此，来自 Azure 背景，如果您打算选择这样的产品，那么第一件事就是与平台的兼容性。
所以， NCache 本身是用 100% .NET 编写的。 它是本机 .NET 或.NET Core 产品，就您的应用而言，对。 因此，基本上，它是用 .NET 编写的，主要用于 .NET 应用程序，它部署在 Windows Server 2016、2019 甚至 2012 上。仅适用于 NCache is .NET framework or .NET Core 对于这个问题。 鉴于，对于 Redis，它是用 C++ 编写的。 NCache 是用 .NET 编写的。 它是 100% 开发的，实际上 C# 是我们使用的主要技术语言，它是 100% 原生的 .NET 和 .NET Core。 鉴于 Redis 是一个基于 C++ Linux 的解决方案。
因此，从 Windows 的角度来看，Windows 背景，如果您的应用程序是用 .NET 编写的，那么自然的选择是使用同样用 .NET 编写的产品，这样您就可以使用相同的技术堆栈。 您不必在应用程序开发堆栈中有很多变化。 因此，这是这两种产品之间的一个问题或一个区别。
第二个方面是 Windows 与 Linux，然后你就知道有什么可用的了 NCache 什么是可用的 Redis 边。 从 Windows 的角度来看 NCache 部署，这是一个首选的部署，但我们也有一个 Linux 部署可用在我们的帮助下 .NET Core 服务器发布。 因此，我们在 Windows 2012、2016、2019 上完全兼容。我们的 Docker 映像也可用于 Windows 变体。 的一个变种 NCache. 所以，你可以下载我们的 Docker 镜像，然后旋转 Windows 镜像 NCache 根据需要，我们在生产环境中完全支持它。 这是我们的官方支持。 然而，如果你比较 Redis 即使在 Microsoft Azure 中 Redis 托管在 Linux 上。 首选方法、首选部署模型是 Linux for Redis. Windows 变体是第三方项目。 Microsoft Open Tech 有一个移植版本。 没有来自官方的支持 Redis 本身。 该项目本身被搁置。 它有问题、不稳定，甚至是 Azure Redis，如前所述，使用 Linux 版本，最大的问题是您没有来自 Redis，制造商 Redis 或者从一个角度来看，如果你想使用开源项目并且你想在你自己的前提下部署它，那么你会看到很多问题。
作为其中的一部分，我还想强调另一个方面是，如果您使用 NCache 本地部署，您现在想要从本地迁移，并且您想在 Azure 中使用，相同的软件可以按原样运行。 所以，搬家不需要改变 NCache 从本地到 Azure。 同样，如果您打算在云供应商中使用 NCache 在 Azure 上，如果需要，您可以直接迁移到 AWS。 因为，完全相同的软件可在所有平台上全面使用。 鉴于， Redis 就 Azure 而言 Redis 是一种托管模型，就后端部署而言，它部署在 Linux 上，但您在本地没有可用的相同变体。 所以，你必须处理开源 Redis 或某些第三方提供商。 即使您必须使用商业变体，这是一种完全不同的产品。
所以，我想在这里强调的要点是 Redis 内部部署，开源或某些商业版本与 Redis 在 Azure 或 Redis 在 AWS 中，它是弹性缓存。 这些是完全独立的产品。 所以，有一个过渡，有很多变化。 你不能移植 Redis 从一种环境到另一种环境，无需经历一些变化。 缺少某些功能集。 有些 API 是不同的。 这些产品之间的部署模型完全不同。 因此，如果您保持不变，则不会发生任何变化 NCache 在 Windows 或 Linux 上进行本地部署，现在您想迁移到 Azure，这将是完全相同的产品，现在您想将其从 Azure 更改为 AWS，您想更改云供应商，相比之下它更灵活到 Redis。 所以， NCache 灵活得多。
Linux支持， NCache 完全兼容，官方支持。 甚至性能也经过测试，Linux 性能超快，与 NCache 在 Windows 上。 我们有可用的 Docker 镜像。 完全支持生产，我们有一个完全集成的监控和管理工具，你可以，这些是 网络管理和监控工具 您可以从任何地方访问。 因此，即使您的 Linux 部署也可以像部署、管理和监控 Windows 部署一样进行管理和监控 NCache. Linux 也支持 Redis. 因此，其生产支持可通过 Redis 实验室。 天蓝色 Redis 也托管在 Linux 版本上。 因此，它由供应商本身提供支持。
平台之后的第二个方面再次是 .NET 和 .NET Core，技术栈。 我们有一个官方客户可用。 我们已经实施了。 我们完全支持它，如果有任何功能集，这就是为什么 NCache 全面兼容。 因此，如果您选择本地或 Azure 或 AWS 环境，您将拥有相同的风格 NCache 及其客户全面可用。 而且，如果需要进行任何更改，我们将正式提供这些更改，因为我们拥有一切以及项目相关。 鉴于，对于 Redis 它是第三方。 因此，对于不同的语言，来自不同语言的支持也来自不同的供应商。 因此，可能存在功能集差异。 可能存在发布周期差异。 因此，就客户要求而言，就技术而言，您必须依赖第三方客户。
所以，我想强调一些方面 NCache 是本机 .NET 和 .NET Core 的产品。 NCache 在 Windows 和 Linux 上都完全支持。 然而， Redis 在 Windows 上不是很稳定。 它是第三方移植版本，并且提供 Linux 支持，因此，您必须尽可能依赖 Linux 支持 Redis 被关注到。 因此，来自 Microsoft 技术背景，这是您必须依赖的东西。
缓存性能和可扩展性
第二个方面是我们的缓存性能。 这也是非常重要的方面。
两种产品都非常快，这就是这里的主要好处 NCache 和 Redis，您会选择这样的产品的主要原因是性能改进方面。 我们已经确定数据库速度很慢，而且它们的可扩展性不是很好。 相比之下，这些产品速度很快，而且非常可扩展。 所以，我不会带走任何东西 Redis. 只是 Windows 版本不稳定，存在性能问题，但如果你有 Linux 版本，它也非常快速和可扩展，而且非常快和 NCache 也很快。 它非常可扩展。 我们有自己实现的基于 TCP/IP 的集群协议，该协议非常优化且性能非常强大。
但是，这里也存在一些差异。 之内 NCache 我们有很多性能改进功能。 我们最近还举办了一次网络研讨会，我们在其中讨论了六种不同的方法来改进 NCache 表现。 如果你设置 NCache 默认情况下，它会为您提供非常好的性能，但最重要的是，根据您的用例，您可以启用不同的功能，您可以进一步提高性能，其中一项功能是我们的客户端缓存。
NCache：客户端缓存（近缓存）
客户端缓存是一项独有的功能 NCache. Redis 没有这个功能。
它是客户端本地缓存，即使对于无服务器应用程序也是可能的，您可以在应用程序进程中拥有 InProc 副本和/或对于基于服务器的应用程序，您可以使用进程外客户端缓存. 这里的想法是，它可以节省通过网络到缓存集群的昂贵旅行。 此缓存已经节省了访问后端数据源的次数。 现在您可以在两者之间进行缓存，并假设您在缓存中有 100 个项目，如果您在应用程序端提供了一些项目，您知道，比如说 10 个项目，这 10 个项目将在下次自动带回客户端缓存您的应用程序会发现该数据更接近您的应用程序，因此可以节省昂贵的网络旅行。
而且，这是一个同步的客户端缓存。 同步由 NCache. 的任何变化 客户端缓存 因为那是主副本，所以在服务器缓存上传播。 这是数据的一个子集，并且该更改也会传播到其他客户端缓存。 如果您有参考数据场景。 如果您有很多读取然后写入，我们强烈建议您打开客户端缓存，与针对我们的数据库运行的缓存相比，它会为您提供非常好的性能。
我们最近与我们的一位客户（我们的大客户之一）进行了 POC。 他们有一个工作流程，使用默认配置大约需要 46 秒。 他们正在制作一堆 NCache 调用和检索数据。 因此，它主要是一个读取密集型用例。 我们打开了进程外的客户端缓存，顺便说一下，有两种风格，您可以将其保留在进程之外，这意味着在应用程序框上运行一个单独的缓存进程，或者您可以让客户端缓存在您的应用程序进程中运行的 InProc。 InProc 没有序列化或进程来处理通信开销。 所以，它非常快。 即使与 OutProc 相比也更快。 因此，对于该客户，工作流程大约需要 46 秒才能开始。 然后我们打开进程外客户端缓存，它把它降低到 3 到 4 秒，然后我们进一步打开它，打开 InProc 客户端缓存，我们能够在 400 到 500 毫秒内实现所有这些。 从 46 秒到 400 到 500 毫秒，这就是我们所说的改进，而这个功能在任何其他产品甚至任何其他风格的 Redis，包括 Redis 实验室，包括开源项目和 Azure Redis.
因此，您可以使用我们的客户端缓存来调整性能，并且无需更改代码。 这只是您打开的配置。
双方都支持批量操作，但使用 NCache 是的，我们的批量操作适用于整个缓存集群，这意味着如果您有十台服务器并且您拥有完全分布式的数据，那么批量调用将从所有这些服务器获取数据并检索合并结果。 因此，所有这些相互结合以制定结果，然后您会得到一个本质上完整的结果。 然而 Redis 批量操作在分片级别。 因此，您必须处理给定分片上的数据。 所以，这就是限制。 如果有，假设缓存集群中有多个节点，并且您有可用的主分片，因此，您将能够对给定分片执行批量操作。
所以，这就是限制。 否则，这是一个很好的性能改进功能，您无需来回处理单个请求，而是发送一个大请求并立即获取所有数据，从而证明您的性能。
序列化，这是另一个功能，还有另一个方面，因为您的大部分时间都花在序列化和反序列化数据上，这对于 NCache 以及 Redis. 默认情况下，这两种产品都会序列化和反序列化，但使用 NCache 有一种方法可以提高您的序列化和反序列化开销。 我们有一个快速复杂的序列化，可以优化您的序列化时间，这通常是您的应用程序需要的时间。 您的对象变得复杂。 因此，无需任何代码更改，您就可以将它们定义为紧凑类型，并且 NCache 将确保它在运行时对它们运行紧凑的序列化，并且会改善您的序列化和反序列化开销。
最后，我们还有压缩功能。 压缩在客户端完成。 通常，如果您正在处理更大的对象，比如 2MB、3MB 或 500 KB，那么这就是一个更大的对象。 因此，通常我们建议您处理较小的对象，但如果您有较大的对象，则会占用大量网络，然后性能也会下降。 和 NCache 你可以打开压缩。 这是一个无代码更改选项，在 Redis 边，它会在添加到缓存时自动压缩项目。 因此，较小的对象被添加并在您的应用程序和缓存之间传输，并且类似地，相同的较小对象也会在应用程序端被检索回。 处理较小的有效负载可以提高您的应用程序性能。 因此，如果打开压缩，整体应用程序性能将会提高。
因此，我们建议任何大于 100 KB 的对象，您绝对应该打开压缩，并且您可以启用一个阈值，并且只压缩较大的对象，较小的对象保持原样。
因此，所有这些性能改进功能，客户端缓存、批量操作、紧凑序列化、压缩，要么不可用，要么 Redis. 例如，客户端缓存不可用。 批量操作可用，但它们是有限的。 没有序列化优化选项，压缩是不可用的。 所以，这就是你有明显区别的地方 NCache 和 Redis，其中 NCache 是完整的软件包，我们在其中内置了许多以性能为中心的功能。
高可用性
下一部分是高可用性，这就是您将看到两者之间巨大的功能集差异的地方 NCache 和 Redis. 高可用性是可以比较这些部分的另一个方面。 对于任务关键型应用程序，这是您需要来源的一个非常重要的方面。 现在您将通常在数据库中的数据和在数据库中的数据进行了某种镜像，某种备份，对吗？
因此，在分布式缓存产品中移动数据时，虽然它提高了性能，但它具有很强的可扩展性，但高可用性是一个非常重要的方面。 对于任务关键型应用程序，任何停机时间都是不可接受的。 它会影响您的业务，并且可能会影响用户体验。 所以，买不起。 因此，您的应用程序始终能够从存在数据的缓存中获取响应非常重要。 所以，这里我们有大量的特征差异。
缓存集群
NCache 是一个 100% 对等架构的缓存集群。
它是动态的和自我修复的，我将讨论如何，你知道，但相比之下 Redis 使用主/从。 因此，作为对等架构 NCache 允许您自动添加和删除服务器，并且与您的应用程序无缝连接。 您可以继续添加所需数量的服务器。 例如，您开始使用 2 台服务器。 现在您要添加第三台服务器，您可以即时执行此操作。 您不必停止缓存或连接到该缓存的客户端应用程序。 观察到无缝体验。 因此，借助我们的高可用性和数据可靠性功能，您的应用程序可以继续工作而不会出现任何停机或数据丢失。 鉴于，在 Redis 你不能自动添加新的分片。 因为没有自动数据重新平衡。 这是我们缓存集群动态特性的核心。 之内 NCache，如果您想添加新服务器，它会自动重新平衡数据。
所以，有两种情况。 您添加新服务器以带来容量，带来更多可扩展性的一种情况是您关闭服务器。
所以，让我们首先解决添加节点的场景。 一个新节点加入。 和 NCache，您的数据将自动分发。
比如从2台服务器增加到3台服务器，如果你再增加2台，你这里有6个项目，你添加另一个服务器现有的数据将被传输到，将平衡到新添加的服务器。 因此，该服务器将从现有服务器中获取大量数据，这将自动完成。 它本质上是动态的。 因此，发生了自动数据重新平衡。 和 Redis，这是手动重新平衡数据，这适用于 Azure Redis 因为 Azure 中有不同的可用层集。 有基础的，有中级的，有高级的。 集群只在高级版中发挥作用，这也很昂贵，最重要的是，他们至少需要至少 3 台服务器，这又是一个限制。
NCache 您甚至可以仅使用 2 台服务器就可以完全启动并运行集群，在此之上，添加新服务器需要手动重新平衡数据。 这是个大问题。 因此，您将对应用程序以及何时计划增加容量有某种限制。 鉴于，与 NCache 您可以在运行时实现这一点。 您可以即时添加更多服务器。
第二个方面是服务器宕机。 所以，我们有，在 Redis 我们有主从概念。 主服务器将数据复制到从服务器。 有一个奴隶碎片。 因此，master 必须复制数据，并且可以采用 Sync 或 Async 方式。 在 Redis，如果从属分片出现故障，主分片本身停止，集群将变得不可用。 所以，这是一个大问题，并且可能一直发生。 严格在您拥有开源或 Redis 实验室部署 Redis. 在这种情况下，如果服务器出现故障并且恰好是主分片的从属服务器，则集群本身将变得不可用。 因此，您必须参与其中并进行手动干预才能从该场景中恢复。 而在 NCache 这是自动的。 因此，任何服务器都可以关闭，幸存的节点可以是活动的或备份的。
例如，这台服务器宕机了，这是一个活动分区，它也有一个备份分区。 如果整个服务器出现故障，备份会提升活动状态。 备份分区被提升为活动分区，您从幸存节点获取所有数据，并且其中内置了连接故障转移。 任何服务器宕机的客户端都会在运行时检测到这一点，他们会决定并故障转移到幸存的节点，在这里我想加强这个概念，用 Redis 您至少需要 3 台服务器。 这就是多数规则的概念。 Cluster coordinator has to win an election. 情况并非如此 NCache. 您可以仅使用 2 个节点启动完全工作的缓存集群，并为您提供完整的高可用性功能。 任何服务器出现故障，幸存的节点完全能够正常工作而不会出现任何问题，但情况并非如此 Redis.
动态配置。 您可以在运行时更改集群配置，这包括添加新服务器、删除服务器或更改缓存集群上的某些设置。 您可以在运行时将其应用于整个崩溃集群而无需停止它。 而对于 Redis, 是有限的。 您必须手动应用很多配置，然后有很多可用的集群健康事件 NCache 侧，您可以订阅。 您可以在它之上使用监控和管理工具。 然而， Redis 没有这些功能。
所以，这是一个非常重要的概念。 让我为你总结一下。 添加和删除服务器 Redis 是会给你带来很多问题的东西。 因为添加数据不会自动重新平衡。 所以，这不是百分百的点对点架构。 因此，缓存集群的容量是有限的。 同样，如果从属分片出现故障，集群本身就会变得不可用。 因为，现在您必须手动管理分发问题。 故障转移也是手动的，对吧？ 因此，如果服务器出现故障，您必须手动进行故障转移并开始使用幸存者节点。 如果添加新服务器，则必须手动切换到新添加的服务器。
所以，这些都是你会遇到的限制，你知道，我会惊讶地看到使用这种性质的生产部署，现在你需要增加容量，或者你需要关闭服务器进行维护。 所以，对于像这样的产品来说，这将是非常困难的 Redis. 然而， NCache 为您提供无缝体验。 您可以在不影响任何内容的情况下即时添加或删除服务器。
动态分区/分片
现在还有一个概念，你知道，集群是自愈机制。
NCache 有动态分区。 您添加更多服务器，数据获取 redis值得庆幸的是，新的分区是在运行时制定的。 同样，如果您将服务器关闭，集群将使备份可用，并且如果您将其从 2 降低到 3 再降低可靠性方面，它将自行修复并制定一个健康的 2 节点缓存集群。 它有正确的复制分区，也可以在 Redis 作为从属的形式，但它们的高可用性依赖于复制。 他们没有与 Redis 如果您没有配置从分片，您将不会获得高可用性。 因此，您必须有可用的从属分片。 鉴于，随着 NCache，我们有拓扑。
例如，分区缓存，我们有主分片，主分区。 如果此服务器出现故障，您仍然具有高可用性，因为客户端会检测到这一点，它们将进行故障转移并开始使用生存节点。 他们会丢失数据，这对 Redis 也是。 数据丢失，因为没有复制，但它仍然具有高可用性，然后我们对此进行了增强，我们也有复制支持。 如果此服务器出现故障，不仅服务器的备份可用，客户端会自动进行故障转移。 所以， Redis 是有限的。 它的高可用性取决于复制。 它不是高度可用的，如果没有打开复制，这也是一个限制因素。
然后是自愈机制，虽然不需要人工干预。
如果你从 3 台服务器开始，你关闭了一台服务器，你会使用活动分区，一个主服务器，然后你也会失去另一台服务器的从属服务器。 因此，在这种情况下，服务器 3 的备份在服务器 1 上，因此，它被激活。 它在运行时加入活动分区。 不需要干预。 需要手动工作，然后分区服务器 2 会在服务器 1 上制定一个健康的分区。因此，集群会自动自我修复，这就是 NCache 与...相比 Redis. 在哪里 Redis, 分片不能在运行时重新调整。 如果从属分片出现故障，集群将停止。 数据 redis归因不是动态的。 高可用性取决于复制，而复制并非如此 NCache. NCache 即使没有复制也可以为您提供高可用性。
所以，你得到的所有这些好处 NCache, 使它成为更优秀的产品，因为这些功能完全缺失或有限 Redis Azure 也是如此 Redis. 这也适用于开源，因为这些是非常可比的产品，对于开源也是如此 Redis 实验室 Redis 提供以及。
NCache 演示
我现在要花一些时间，你知道，展示实际的产品，以便你了解如何 NCache 得到配置。 所以，这是我们的演示环境。 我一直在使用它。 所以，我将创建一个新的缓存。 这是我们安装的网络管理工具 NCache. 序列化模式可以是二进制或 JSON。 这完全取决于你。 我将只命名缓存，并向您展示如何创建缓存集群、连接客户端应用程序以及监控和管理它。
所以，我会保持一切简单，因为这个网络研讨会的主要焦点是 NCache 与 Redis，所以，我将保持所有细节简单。 分区副本，这是我们最推荐的拓扑。 活动和备份之间的异步复制。 因此，您可以选择同步。 异步更快，所以我将继续使用它。 缓存集群的大小。 然后我将指定这些服务器节点在哪里 NCache 已安装。 TCP 端口。 NCache 是基于 TCP/IP 的通信协议。 所以，我将保持一切简单，在此我将启用驱逐，这样缓存就会变满。 因此，它会自动从缓存中删除一些项目，从而为较新的项目腾出空间。 启动此缓存并完成。 在服务启动时自动启动它，因此，每次我的服务器重新启动时，它都会自动加入缓存集群，仅此而已。 这就是配置缓存集群然后使用它是多么简单，接下来我将向您展示。
云支持（Azure 和 AWS）
因此，我们的托管服务模式即将出现。 我们的下一个版本的重点是我认为两到三周后的内容。 因此，我们将拥有一个完全托管的 NCache Azure 和 AWS 中的软件即服务模型。
目前，它要么是VM模型。 如果您有内部部署，则可以使用物理或虚拟机框。 如果您选择 Azure，您需要通过市场设置您的 VM，或者您可以设置一个 VM，然后安装 NCache 从我们的网站下载软件。 然后我们也有容器化的环境。 我们有 Docker 映像，并且完全支持 Azure Kubernetes 服务、EKS - 弹性 Kubernetes 服务和任何其他服务，例如 OpenShift Kubernetes 平台， NCache 已经在这些平台上完全集成并完全支持。 就托管方面而言，这是即将发生的事情。 因此，从现在起两到三周后，它将完全可用。
因此，我将向您展示统计窗口，它是一个性能计数器，顺便说一下，这些监控选项可用于 NCache， 按照 NCache 在 Windows 和 Linux 环境上，对吧？
所以，我要运行一个压力测试工具。 我认为已经有一个正在运行另一个缓存。 因此，我将继续运行一个，这将模拟我们的缓存集群上的虚拟负载。 您只需指定名称，它就会使用配置文件自动发现服务器并连接到它。
因此，我们有完全连接的集群状态、每秒请求数显示吞吐量、每个缓存操作的平均微秒延迟、添加、获取、更新、删除、缓存大小、CPU、内存。 因此，您将获得一个集中的监控视图。 您可以使用此工具。 您还可以使用 Windows perfmon。
对于基于 Linux，我们有我们定制的监控。 因此，您也可以直接将我们的监控工具用于 Linux 服务器，也可以使用任何第三方工具进行监控 NCache 也是。 因此，这是对我们的缓存创建过程的快速浏览。 一些监控和管理方面。
于是，回来了。 因为我们讨论了一些细节。 接下来我想讨论的是云产品/云支持。 现在 Redis 本身，您可以选择非托管缓存，也可以选择托管缓存，然后有一个可用的托管服务，并且管理选项来自第三方供应商。 托管选项来自 Azure Redis, 你可以有一个开源变体 Redis 由 Microsoft 定制，可作为托管模型使用。 鉴于，在 NCache 一方面，我们有缓存服务器模型，VM模型。 我已经讨论过容器方法。 它与 Windows 以及 Linux 容器完全兼容。 我们提供了适用于 Windows 容器的 Azure Service Fabric 的视频演示、微服务架构详细信息。 我们有使用 Linux 容器的 Azure Kubernetes 服务。 EKS – Elastic Kubernetes Service，然后我认为我们还通过 Kubernetes 完成了 Red Hat OpenShift Containers。
所以，这些都是可用的容器部署选项，它很灵活，它的平台，你知道，它不是特定于平台的。 因此，您可以将其部署在任何类型的容器化平台中，而不会出现任何问题。 托管服务即将推出，所以我们已经讨论过了。 所以，这就是 NCache 将有托管服务，但这是我们的下一个版本。
一个重要方面是使用 VM 模型的好处，尽管您必须连接到 VM 而不是服务，但您可以控制一切。 您可以运行我将在接下来介绍的服务器端代码，但最重要的方面是性能方面。 我们已经讨论过内部有很多性能特征 NCache, 其中缺少 Redis. 如果您选择使用 Azure Redis，您必须连接到 Azure 基础结构。 因此，这些是虚拟机，它们在单独的虚拟网络中运行。 这些都位于附近，但它们又很远。 它不同于您在 Microsoft Azure 中拥有的您自己的虚拟网络以及您拥有所有应用程序部署的地方。
NCache 您可以选择我们的 NCache 部署在与您的应用程序虚拟网络相同的虚拟网络上。 例如，您的应用服务、您的 Azure 网站、您的 Azure 微服务，它们都在 Azure 虚拟网络上运行。 您可以选择在同一虚拟网络上部署 Azure VM 并提高应用程序性能。 根据我们自己在实验室内的测试， NCache 比 SaaS 模式快四到五倍 Redis 您通常会在 Microsoft Azure 中获得。 所以，这是我想强调的一个非常重要的方面。
最重要的是，您可以对 VM 进行大量控制。 您可以完全控制启动缓存、增加大小、获得全部容量。 请求单位没有限制，大小没有限制，没有使用足迹，并且您不会因此而被计入成本。 您携带自己的许可证，也可以是永久许可证，也可以是订阅许可证，在许可方面可能非常灵活。 最重要的是，您可以在您的之上运行服务器端代码 NCache 服务器。 您可以完全管理这一点。 您可以对此进行全面优化。 你可以写很多接口。 例如，read-through、write-through、write-behind、cache loader 和一些计算网格特性，如 MapReduce、Aggregator、Entry 处理器，这只有在 NCache. 即使是我们的 SaaS 模型，也就是托管模型，可以提供所有这些产品，但情况并非如此 Redis. 所以，这就是我们的平台。
保持缓存新鲜
下一部分，接下来的 15 分钟，我将花在功能级别比较上，为此我定义了一些部分。 因此，如果您需要保持缓存新鲜，我将开始，这非常重要，应该有一个单独的网络研讨会，专门针对后端数据源，关于您的应用程序使用如何保持缓存新鲜案例。
所以，相比 Redis， 你懂， NCache 这方面也有很多功能。
我们有时间基准到期，它是绝对的和滑动的，但我们也有一个自动重新加载机制可用于此。 Redis 只有绝对和滑动到期，没有任何重新加载机制。 对于重新加载，我们允许您实现一个名为 read-through handler 的接口，它是一个服务器端代码。 同样，这是可能的，因为 NCache 允许您授予对您的虚拟机的完全访问权限 NCache 托管。 所以，你可以在上面部署服务器端代码 NCache 并使用 NCache 计算能力来支持它。
您可以将缓存与数据库同步。 NCache 在数据库同步方面非常强大。 我们有 SQL 依赖项。 我们有 DB 依赖项，它只符合 DB 标准。 我们有 .NET CLR 存储过程。 因此，所有这些功能都允许您将缓存与数据库同步。 这里的想法是，如果数据库中发生更改，数据库中的记录发生更改并且您缓存了该记录，这两个源可能不同步。 所以，随着 NCache，如果数据库发生变化，您可以自动使该数据无效或重新加载 NCache 在运行时。 这是一个独特的功能 NCache. 没有其他产品具有此功能。 因此，您可以与后端数据库完全同步缓存，这不仅适用于关系数据库，我们在非关系数据源方面也有功能。
文件依赖是另一个功能，您可以使项目依赖于文件。 文件的内容，如果内容发生变化，您会自动删除或重新加载项目。 和自定义依赖项，您可以将它与任何来源一起使用。 它可能是一个 NoSQL database，它可以是文件系统或关系、任何连接器、任何 Web 服务。 因此，您可以根据您的灵活要求对项目进行验证。 我们已经使用 Cosmos DB 提供了此依赖项的实现。 所以，我们实现了同步 NCache 使用 Cosmos DB。 如果您正在使用 NCache 除了 cosmos DB，您还可以使用自定义依赖项，我想我也为此做了一个网络研讨会。
处理关系数据。 因此，关系数据具有关系。 缓存中的项目是键值对，因此您可以在不同项目之间建立关系，这是不可用的 Redis 边。 因此，您将不得不根据各自的优点来处理项目。 鉴于，与 NCache 您可以在一对一、一对多或多对多组中组合项目。 父项通过更改，子项可以根据需要自动失效或重新加载。
数据分组、SQL 和 LINQ 搜索
另一方面是数据分组和搜索，其中 NCache 很强大& Redis 没有任何功能。 同样，Azure 也是如此 Redis 无论如何，这是非常有限的。 开源 Redis 稍微领先，但在功能方面仍然有限。 即便是 Redis 实验室，商业版 Redis，即不具备这些功能。
可以使用 SQL 搜索。 您可以在其中搜索项目 NCache 基于它们的对象属性。 对象被添加到缓存中。 您可以为其属性定义索引。 例如，产品可以在其 ID、价格、类别的索引中，现在您可以使用这些属性对这些产品进行搜索。 一个典型的例子是选择产品，其中产品点类别是某物，或者产品点价格大于 10，产品点价格小于 100，并且 NCache 将在所有服务器上对所有项目运行内存搜索，合并结果并将您带回结果集。 因此，您不必再处理密钥了。 您根据标准检索数据。
LINQ 搜索也可用。 我们有 .NET 和 .NET Core 应用。 如果您正在使用 LINQ 搜索，您可以在其上运行 LINQ 搜索 NCache 也是。 所以，这是一个独特的功能 NCache 哪里 Redis 没有任何支持。 Redis 任何，所有的味道 Redis，没有这个支持。
您可以有组、子组。 你可以在里面合乎逻辑地制作集合 NCache. 这在 Redis 您可以根据这些组检索、更新和删除数据。
标签和命名标签可以被赋予属性。 例如，您可以使用可以附加到您的项目的关键字。 一个典型的例子是您可以使用客户标签标记所有客户。 所有带有订单标签的订单和某个客户的订单也可以附加一个客户 ID 作为标签。 当您需要订单时，您只需说按标签获取并将订单作为标签提供，这样您就可以获得所有订单。 当您需要某个客户的订单时，您会说通过任何标签获取或通过标签获取并提供客户 ID，它会为您提供所有订单，但仅限于该客户 ID。 所以，这就是使用标签和命名标签的灵活性 NCache. Redis 不支持这些。
服务器端 .NET 代码
我们已经讨论过，通常我们使用缓存侧模式，首先检查缓存中的数据，如果在缓存中找到数据，则返回，如果在缓存中找不到数据，则转到应用程序中的后端数据库然后获取该数据并将其放入缓存中。 所以，有一个空，你检索空，然后你去数据库。 您可以在 Read-Thru 处理程序的帮助下自动执行此操作。 它是在您的服务器上运行的服务器端代码 NCache 服务器。 我们的托管服务也将具有此功能。 因此，您实现了这个接口，它允许您连接到任何数据源。 它可以是 Web 服务，可以是关系数据源或非关系数据源，并且一旦在缓存中找到空值，就会调用一堆方法。
因此，您调用 Cache.Get 方法，启用 Read-Thru 标志。 如果项目不在缓存中，则调用将传递给您的 Read-Thru 处理程序，因此您将通过该处理程序代码从后端数据库获取数据。 您的用户代码在哪个上运行 NCache 服务器端。 所以，你可以无缝地通过 NCache 并获取您需要的数据。
直写与之相反，它也被支持和 Redis 没有这些功能，您可以在其中更新缓存中的某些内容，现在您想要更新数据库，您可以通过调用您的直写处理程序来更新数据库。 您实现并注册此直写处理程序并 NCache 会调用它来更新后端数据库，而 write-behind 则与之相反。 缓存上的任何更新，客户端应用程序返回和 NCache 将在幕后异步更新后端数据库。 所以， NCache 甚至可以提高您对数据库的写操作的性能，这是不可能的 Redis 或任何其他产品，如果您无法运行服务器端代码。 这是一个纯粹的原生 .NET 和 .NET Core 您可以实现并注册为通过接口读取和写入的类库，这可以通过 NCache.
缓存加载器是另一个特性。 您可以通过实现接口和注册来预填充缓存 NCache. 因此，每次重新启动缓存时，都会自动在其中加载一些重要数据 NCache 这同时在所有服务器上运行。 所以，它超级快。 因此，您可以预先填充所有数据，而无需再次访问数据库。 您总是会找到该数据，因为您预先加载了它。
自定义依赖项，入口处理器，这些又是唯一的特性 NCache 以及无法使用这些功能的主要原因。 首先， Redis 没有这些功能，Azure 中不支持模块 Redis 甚至在开源 Redis. 服务器端，Azure 无法编写代码 Redis. 主要是因为您无权访问底层虚拟机，这是我之前提到的主要原因 NCache 在目前的 VM 模型上，您可以完全访问您的部署位置、控制方式和管理方式。 因此，您可以完全控制。 它不是一个黑匣子 Redis 是。
多数据中心的 WAN 复制
更多细节，然后我将结束这一点。 WAN 复制是另一个方面。
支持主动-被动 Redis，您可以在其中将整个数据中心、缓存从一个数据中心传输到另一个数据中心。 在 NCache，我们有主动-被动。 因此，数据从一个数据中心到另一个数据中心的单向转换。 我们也有 active-active，这是非常紧迫、非常重要的用例，您可能同时拥有两个站点。 您需要站点 XNUMX 上的站点更新，反之亦然。 所以，这不是一个能力 Redis 边。 你没有那个能力，所以，你不能运行主动-主动站点 Redis。 同 NCache 这适用于您的应用数据缓存用例，您在两个站点上都有数据正在更新，这也可以通过我们的多站点会话实现。 所以，那是另一个空间 NCache 是一个明显的赢家。
缓存拓扑
然后是一些其他的细节。 缓存拓扑。 与 Redis.
所以，根据不同的用例，我们有镜像、复制、分区，然后是分区副本，然后我们已经讨论过了，我们讨论了如何 NCache 总体而言，聚类更好，与 Redis 产品。
GUI 工具 - 缓存管理和监控
然后我们有 GUI 工具。 这是一个比较。 经理，监控。
然而，我们有 PowerShell 工具，我们有转储和重新加载工具，其中内置了完整的管理和监控方面。 然而， Redis 在这方面也受到限制，作为其中的一部分，我向您展示了一些细节，这对于 Windows 以及 Linux 部署都是如此 NCache.
ASP.NET 特定功能
一些 ASP.NET 特定的缓存功能。
会话，我们有多站点会话，从 ASP.NET 到 ASP.NET Core 会话共享即将到来。 多站点 ASP.NET 和 ASP.NET Core 会话可用。 查看状态，输出缓存。 Redis 只有会话，与 NCache. 会话锁定，会话共享是其中的一部分 NCache. 两端都支持输出缓存，此外我们还有 SignalR Backplane, ASP.NET Core 响应缓存。 因此，所有这些都为您的 Web 特定缓存要求提供了完整的功能集。 因此，您可以详细查看功能集。
与事件共享运行时数据
然后我们有 Pub/Sub 消息传递。
我们有项目级事件，我们也有一个基于标准的事件通知系统，与 Redis. 我有一个关于 Pub/Sub 消息传递的单独网络研讨会。 因此，如果有任何问题，我强烈建议您查看。 所以，我想我会在这一点上结束。
第三方整合
最后，第三方集成。
我们也有 NHibernate 和实体框架。 AppFabric 包装器可用。 Memcached 包装器可用。 因此，如果您要从这些产品过渡，您可以无缝过渡到 NCache 与...相比 Redis.
安全与加密
关于的一些细节 安全加密 我认为我们已经在时间标记上。
结论
所以，现在是总结它的好时机。 所以，第一件事是，你们随时随地都可以访问 www。alachisoft.com，您可以下载企业版 NCache 我们将亲自向您展示它如何在您的环境中运作。 因此，我们鼓励您直接访问该网站，获得 30 天的企业免费试用期。 安排演示将是我们的荣幸。 除此之外，我们将为您提供本次网络研讨会的录音。 因此，当我们向您发送消息时，请留意您的电子邮件和社交媒体。 如果我们今天没有回答您的问题，而且我知道我们还有很多问题要解决，而且我们正处于边缘，请发送电子邮件 support@alachisoft.com.
如果您有任何技术疑问，我们将为您解答，如果您有兴趣继续前进和申请 NCache 在您的环境中，您可以联系 sales@alachisoft.com 以及。