分区副本和分区拓扑
分区副本是可扩展性最强、可用性最高的缓存拓扑结构。 NCache它通过将数据分布到各个分区来线性扩展存储和事务，并为每个分区保留一个副本，从而在不丢失数据的情况下实现高可用性。
在集群中，如果所有服务器节点都拥有相同的数据副本，就能实现数据的高可用性。这意味着即使少数节点发生故障，集群也能正常运行而不会丢失任何数据。然而，这种方式并不具备可扩展性。当数据量开始呈爆炸式增长时，设计方案需要减少数据复制的程度，并开始对数据进行分区。
分区意味着您需要将数据分布在多个节点上，以便分散读取和写入数据负载。随着数据的增长，您可以在集群中添加更多服务器节点以容纳更多数据。集群中的每个服务器节点称为分区。
通过对数据进行分区，您可以实现可扩展性，但现在的问题是数据如何分区？ 一个简单的解决方案可能是以循环方式将数据分配到分区，但是一旦将其添加到存储中，我们如何找到特定的数据呢？
通过循环，我们将失去跟踪数据位置的能力。 我们需要一种更好的数据分布方式，不仅要保证数据的均匀分布，还要保证快速查找的能力。
注意：
Partitioned 和 Partition-Replica 拓扑之间的唯一区别是前者没有副本缓存，这使得它容易丢失数据。
分区缓存的基于哈希的数据分区
NCache 将数据分为多个块并将这些块放置在不同的分区中。 这些块称为桶。 总共有 1000 个桶，在集群中的节点之间平均分配。 这里的想法是对项目的键应用哈希函数，并通过总存储桶数量（本例中为 1000）对其进行建模，以获得该数据的所有者存储桶。
分布图
集群中的协调器服务器有责任生成包含桶分布的映射。 这张图称为分布图。 协调器服务器与集群中的其余分区以及连接的客户端共享此分布图。 无论集群中的服务器数量如何，此方法始终为您提供相同的项目存储桶地址。 尽管存储桶可能在任何阶段从一个分区移动到另一个分区，但项目的存储桶永远不会改变。 这意味着，当桶移动时，它会带走所有数据。
根据分布图对数据进行分布
当您启动具有单个分区的缓存集群时，所有 1000 个存储桶都分配给此节点。这意味着所有数据都转到此分区。当您启动集群中的另一个节点时，存储桶会在两个分区之间平均分配，每个分区有 500 个存储桶。同样，在集群中添加第三个节点时，存储桶会再次重新分配。在这种情况下，三个节点将分别有 333、333 和 334 个存储桶。
同样，当分区离开集群时，存储桶分布也会发生变化。例如，当分区离开三节点集群时，该分区拥有的 333 或 334 个存储桶将在剩余的两个节点之间重新分配。每当分布发生变化时，它都会触发状态转移，根据存储桶分布重新平衡节点之间的数据。
随机数据分布
这种分区方法为您提供了相当大的随机性，以确保数据在存储桶和分区之间均匀分区。 但是，使用这种分区方法，您将失去对应将哪些数据分配给哪个分区的控制。 大多数情况下，您不会关心数据的去向。 但是，在某些情况下，您可能希望相关数据位于同一位置。 为此，您可以使用位置关联性，其中哈希函数应用于密钥的某些部分而不是整个密钥。
平衡数据分布
每当在节点之间重新分配 bucket 时， NCache 确保以这样一种方式重新分配 bucket，即每个分区接收的数据大小几乎相同。每个分区以可配置的间隔与集群中的其他分区共享其拥有的 bucket 的统计信息。这有助于生成平衡的 分布图 需要时，每个分区获得的数据都是公平的。平衡基于数据的大小，而不是项目的数量。这种平衡通常在节点离开或加入时重新分配存储桶时得到保证。
自动和手动数据负载平衡
但是，您可能会发现集群中的一个或多个分区存在偏差，并且比其他分区接收更多的负载。在这种情况下，您可以选择手动平衡特定节点的数据，以确保该节点上的数据等于每个分区接收的平均数据大小。然后还有一个名为“自动数据负载平衡”的功能，它可以在后台自动完成这项工作。默认情况下禁用此功能，因为如果不谨慎使用，它可能会导致频繁的存储桶重新分配，从而导致分区之间发生不必要的状态传输。
每个分区的数据大小
每个分区可以容纳的数据大小等于配置的缓存大小。 例如，如果配置的缓存大小为2GB，集群大小为三个分区，则该集群上的缓存大小总量为6GB。
因此，通过这种拓扑，您不仅可以在服务器之间分配读写负载，还可以通过添加到集群中的每台新服务器来增加容量。
分区副本
现在我们已经介绍了分区副本拓扑如何扩展事务负载和存储容量。 让我们谈谈它如何处理高可用性。 集群中的每个节点都有另一个分区的备份，该分区充当称为副本的被动分区。 在节点故障的情况下，缓存集群知道丢失分区所拥有的数据在其副本中仍然可用。 因此，客户端应用程序继续平稳运行，因为丢失分区拥有的数据仍由集群通过此副本提供服务。
客户端应用程序仅与活动分区直接通信。 然后每个分区负责将其数据复制到其各自的副本。
即使此拓扑中的复制程度不如您在 复制拓扑，拥有一个备份至少可以确保您在节点发生故障时，您的数据仍然安全。 只要不存在同时发生的节点故障，该拓扑中的数据就是安全的，涵盖了大部分场景。
每个集群节点都有一个活动和一个副本，并且活动和副本实例都存在于每个集群节点上的同一个缓存进程中。
由于每个缓存节点上都存在副本实例，因此它需要与主缓存实例相同的内存大小。 这意味着每个分区副本缓存节点都需要针对其配置的缓存大小的双倍内存。
所有客户端添加的数据都存储在活动节点中，然后从活动节点复制到其专用副本，该副本位于集群中的某个其他节点上。 这种副本节点的安排确保了当活动节点出现故障时数据不会丢失。
副本选择策略
NCache 根据节点加入缓存集群的顺序自动选择副本节点。 第一个节点的副本出现在第一个节点之后加入集群的服务器节点上，依此类推。 并且，最后一个节点的副本被放置在缓存集群的第一个服务器节点（协调服务器）上。
这整个副本选择过程是自动的。 每当服务器节点离开缓存集群或新节点加入缓存集群时，副本也会根据更新后的成员映射重新分配。
单节点内存消耗
每个服务器节点（主节点和副本节点）都会保存配置的 缓存大小 并确保存储的数据永远不会超过指定的内存限制。有两种特殊情况下，此内存限制检查的工作方式不同。它们解释如下：
- 只有一个节点处于运行状态，并且正在向其中添加数据。 活动缓存实例可以使用指定缓存大小的两倍来保存数据，因为其副本没有用处。
- 在多节点集群中，当所有其他节点离开集群并且只有一个节点保持活动状态时，其副本缓存实例中的数据将传输到活动缓存实例。 来自副本的空闲内存然后被活动缓存消耗以容纳从副本接收的数据。
复制策略
Partition-Replica 拓扑有两种复制策略将数据从活动服务器节点复制到副本节点：
异步复制： 在此模式下，后台队列用于复制数据，而不会阻塞客户端操作。 每个写入操作都会排队，专用后台线程从该队列中分块选取数据并将其复制到副本实例。 此复制策略适合经常进行写入但不希望在下一次缓存操作之前等待复制完成的应用程序。 但是，如果节点突然离开，则可能会丢失数据。 在这种情况下，未复制的排队操作将会丢失。
同步复制： 使用同步复制模式，来自客户端的每个写入操作都会在将控制权返回给客户端应用程序之前复制到副本。 这种复制模式可确保活动缓存实例和副本缓存实例具有相同的用户数据副本。 如果副本实例上的复制失败，则会从活动缓存实例和副本缓存实例中删除该项目。
操作行为
驱逐， 過期时间, 透写/后写等等，这些操作都由活动节点控制。每当活动节点基于上述任何特性从其缓存中移除一个项目时，它都会将该项目复制到其副本，从而从副本中删除先前存储的数据。同样，直写/后写操作也只能在活动缓存中执行。
在分区副本拓扑中，客户端直接与每个服务器节点连接，但仅与其活动分区/实例连接。 尽管如此，在某些情况下，客户端会通过集群调用临时与副本实例进行交互。 它们的解释如下：
- 在状态转移期间，当节点离开集群时，将从其副本提供针对离开节点的客户端操作。
- 当集群处于维护模式时，维护期间针对受维护节点的所有操作均由其副本提供。
状态转移
状态传输是在缓存节点之间自动传输/复制数据的过程。 当新节点加入集群或任何当前节点离开集群时触发状态转移。 节点离开/加入也会导致集群中的成员资格发生变化。
当一个节点收到更新的 分布图，它验证本地环境中存储桶（分配给它的）是否存在。 节点本地环境中不存在的分配的桶会从其他节点一一拉取。 因此，根据缓存集群中服务器节点的数量，在状态传输期间会传输多个桶。
在以下三种主要场景中触发状态转移：
节点加入
当有新节点加入缓存集群时，协调服务器会生成一个新的分布图，将桶从当前节点分发到新加入的节点。 并且，新加入的节点在收到分布图后，从当前节点中拉取桶。 在此状态转移期间，新加入的节点一次拉一个桶。 在收到一个桶后，它会拉下一个桶，依此类推，直到它根据其分布图从其他节点获取所有分配的桶。
节点离开
类似地，当缓存节点离开缓存集群时，会触发状态转移。协调器服务器将其存储桶重新分配给集群中的活动节点。在这种情况下，活动节点会从离开节点的副本中提取数据。
关于自动数据负载平衡
Partition-Replica 拓扑有一个特点： 自动数据负载平衡 它会持续监控集群节点间的数据分布情况。如果数据分布不在预期的分布范围内（60% 到 40%），它会自动触发自动数据负载平衡。在这种情况下，协调器服务器会重新生成新的分布图，并重新分配存储桶，使所有集群节点的数据大小相等。
注意：
也可以进行数据负载均衡 手动 来自 NCache 管理中心。
无论状态转移的原因是什么，整个过程都是自动且无缝的。 而且，在状态转移期间，特别是当服务器节点离开缓存集群时，所有原本用于离开节点的客户端操作都通过集群操作从其副本提供服务。
副本也像其他活动节点一样从其活动节点执行状态传输。 副本从其活动节点拉出分配的存储桶，以在状态传输时获取数据副本。 然而，这种状态转移仅在存储桶重新分配时发生。 否则，数据将通过复制机制复制到副本。
监控状态传输的不同方法
NCache 提供多种方式来监控缓存集群中的状态传输。 它们解释如下：
- 缓存日志： 每当触发和停止状态转移时，都会记录在集群的缓存日志中。缓存日志位于…… %NCHOME%\日志文件 文件夹中。
- 自定义计数器： NCache 还发布了可在 Windows 和 Linux 上查看的自定义计数器。
- 基于 Perfmon 的计数器： 在Windows上， NCache 还通过 Windows Perfmon 工具发布状态转移计数器。
- Windows 事件日志： 与状态传输相关的信息/事件也发布在 Windows 事件日志上。
- 电子邮件警报： 状态转移特定的电子邮件警报可以在其启动和停止时进行配置。
一旦状态转移监控启动，协调器就会持续查询集群中所有节点的状态转移状态，只要集群保持状态转移状态，就会一直查询下去。 30第二 连续请求之间的间隔。每个节点返回自上次执行任何状态转移相关活动以来经过的时间。如果此持续时间超过 3分钟状态转移被认为卡在该节点上。当 卡住的州转移 如果检测到集群活动，协调器将取消设置状态转移标志，以允许节点加入和离开等集群活动。
集群成员变更和分布图同步
如前所述，当节点加入或离开集群时，集群成员关系会发生变更。在此过程中，集群会生成一个更新的分布图，以反映新的活动节点集合。由于节点间的同步并非同时进行，因此在短暂的过渡期内，部分节点可能已更新了分布图，而其他节点仍未更新。
一致性过渡态
为确保成员变更期间的一致性，集群会进入过渡状态，在此状态下：
- 客户端将继续获得最新的稳定（缓存）分布图。
- 更新后的分布图只有在所有节点完全同步后才会对外共享。
例如，在一个双节点集群中添加第三个节点时，集群会继续使用双节点分布图运行，直到所有三个节点完全同步。同步完成后，协调器退出过渡状态并共享更新后的三节点分布图。
协调器验证所有节点均已成功接收并应用更新后的 HashMap 后，便将集群标记为已退出状态转换。随后，每个节点将其缓存的 HashMap 引用切换为新的 HashMap。协调器接着通知客户端 HashMap 的更改，并指示所有集群节点开始状态转移。
这样可以保证在集群成员更新期间客户端和服务器之间的一致性。
套接字重连超时
在集群环境中，如果两个服务器节点之间的连接中断， NCache 会自动尝试重新建立连接。这些重新连接尝试发生在套接字级别。但是，套接字超时行为取决于操作系统，并且在不同环境中可能有所不同。要控制此行为， NCache 提供专用 套接字重连超时该参数定义了在两个节点之间建立套接字连接所需的时间。默认情况下，套接字重连超时设置为 1000。 10秒最小值为 5秒 最多的 30秒.
此超时机制确保集群级连接恢复在此受控时间窗口内完成。当两台服务器失去连接时，连接到这些服务器的客户端也可能受到影响，尤其是在服务器与集群其他部分隔离的情况下。为防止集群内部的重新连接尝试干扰客户端连接，此超时机制根据以下规则进行设置： 客户端优雅窗口并且经过精心选择，为服务器节点尝试重新连接提供足够的时间，而不会对客户端宽限期产生负面影响。
如果套接字连接尝试在配置的超时时间内失败：
- 尝试已终止。
- 已启动重试。
重要提示
默认情况下， 2 次重新连接尝试 用 2第二 睡眠间隔。
要配置此标志，请参阅 服务器连接 文档。
会员资格变更异常
MembershipChangeInException 在节点级别，当状态转移进行期间执行启动、停止、加入或离开操作时，可能会出现此异常。但是，在缓存级别，此异常只会在缓存启动时出现。如有必要，即使在状态转移期间也可以强制节点加入，从而允许操作在保持集群一致性的同时继续进行。
客户端连接
如分区中所述，数据分布在集群中的所有服务器之间。 与其他拓扑不同，分区拓扑的客户端需要连接所有分区，其中每个分区包含总数据的一个子集。
客户端在连接调用上收到一个分布图，该分布图告知客户端正在运行的服务器节点及其 基于散列的分布。 客户端连接所有服务器节点以从缓存中获取完整数据。 客户得到一个 更新地图 在每次集群成员变更时，为了在完成后保持连接性，需要进行以下操作： 过渡阶段客户端还会收到成员加入/离开的通知，并根据收到的信息重置连接。 地图.
客户端根据 基于散列的分布图 它接收。 对于密钥未知的所有操作，例如 SQL 搜索, 获取标签等等，客户端将请求广播到所有服务器节点并组合它们各自的响应。
在任何情况下，如果客户端无法连接到集群的任何服务器节点，并不意味着它无法从该服务器节点写入和检索信息。 为此，它使用它所连接的其他服务器节点，这些节点代表它请求无法访问的服务器节点执行操作。 例如，如果客户端无法与 node1 连接并想要获取驻留在 node1 中的密钥，它会将请求发送到 node2，它重新路由到 node1 并返回响应。
客户宽限期
如果客户端在任何情况下都无法连接到集群中的任何服务器节点，它不会立即终止操作。相反，客户端会保持一个重新连接窗口（客户宽限期）的 配置的请求超时时间的 60%（即默认值为 54 秒）在此期间，客户端会持续尝试重新建立连接，并将所有传入请求暂时放入队列。如果在此期间连接恢复，则队列中的操作将被转发到相应的节点并正常处理。如果在宽限期内连接无法恢复，则队列中的操作将失败，客户端将抛出与连接相关的异常，并且必须等待更新后的映射。
维护模式
当需要修补或升级硬件/软件时 NCache 服务器，您可能不会遇到应用程序停机。 但是，停止缓存节点会触发 状态转移 整个缓存集群内部都会发生这种情况，导致网络、CPU 和内存等资源过度消耗。这种状态转移过程的成本可能很高，具体取决于缓存数据和集群的大小。典型的升级工作流程是每次重启一个缓存节点，这需要两次状态转移：一次在节点离开时，另一次在节点加入时。
维护模式 引入此机制是为了避免缓存服务器维护期间进行代价高昂的状态传输。当缓存服务器因维护而停止运行一段时间后，被维护节点的副本会暂时激活并开始处理客户端请求。当被维护节点在指定时间内维护结束后重新加入集群时，系统会启动该节点的状态传输，使其与缓存集群同步。
集群退出维护模式有三种不同的状态。如果维护节点在指定时间内重新加入缓存集群，则启动状态转移以同步集群状态，集群退出维护模式。如果维护节点在指定时间内未能重新加入缓存集群，则集群认为该节点已宕机，退出维护模式，并生成一个新的缓存集群。 地图并启动状态转移。除了成功和失败之外，还有一种异常情况会导致集群退出维护模式，即节点离开。如果集群处于维护模式，而除维护节点之外的任何节点离开，则集群将退出维护模式，这可能会导致数据丢失。
脑裂恢复
期限 裂脑 指的是一个缓存集群分裂成多个子集群的状态。集群中的缓存服务器通过 TCP 协议进行通信。因此，任何网络故障或问题都可能导致集群中服务器之间的通信中断。如果服务器之间的通信中断持续超过一定时间，成员关系图将根据服务器之间的连接情况而发生变化。这会导致多个子集群的形成。这些子集群被称为分裂。我们称之为“脑裂”，因为这些子集群之间无法相互通信，类似于脑裂综合征中大脑的左右半球无法相互通信的情况。
所有子集群都是健康的并处理它们包含的数据。 此外，客户端可以连接到这些子集群以进行进一步的读/写操作。 客户端从集群服务器接收成员映射以更新连接。 在这里，客户端可以根据收到的第一个地图连接到任何子集群。
只有当服务器间通信恢复，且发现所有服务器均已启动并运行，但并非属于同一集群时，才会检测到脑裂现象。根据服务器间通信中断的程度，可能出现两个或多个脑裂。一旦检测到脑裂，恢复过程便会启动。所有脑裂会逐一恢复，直至所有子集群合并。
脑裂恢复过程在检测到脑裂后立即启动。它首先识别两个健康的脑裂分支，确定它们的协调器服务器，然后根据集群大小决定哪个分支获胜，哪个分支失败，并对失败的分支加锁以限制客户端在该分支上的活动，同时更改集群成员。之后，所有客户端都被重定向到获胜的分支，失败分支的所有节点逐个重启并加入获胜的分支。所有失败的分支以相同的方式与获胜的分支合并，集群恢复正常。
预计数据丢失 裂脑 当集群分裂成多个子集群时，由于集群中的多个节点同时离开，会发生数据丢失。 子集群可以在以下状态下处理客户端请求 裂脑，如果客户端连接的split是loser split，重新启动加入主集群，这些操作可能会丢失。
