当今的应用程序是高度事务性的,并且可以通过在负载平衡的多服务器部署中运行来针对高事务进行扩展。 同时,其中许多应用程序需要在多个数据中心运行。 这可以用于灾难恢复,其中一个主动数据中心将灾难恢复作为通常位于不同地理位置的被动数据中心。 另一个原因是,如果此应用程序的用户分布在不同的地理位置,他们将获得更快的响应时间,因为他们同时访问他们所在地区的自己的数据中心。
NCache 更多信息 用于 WAN 复制的桥接器 NCache 配套文档
缓存需要 WAN 复制,就像数据库一样
当您的应用程序在多个数据中心运行时,需要复制缓存。 这是因为缓存保留了临时数据,如果缓存出现故障,数据就会丢失。 瞬态数据可以是 ASP.NET 会话、应用程序生成的任意数据或聚合数据。 但是,临时数据不是永久性的,因此它永远不会存储在数据库中——它只是被缓存。
其他数据 NCache 出于性能原因保留的是应用程序数据。 如果丢失此数据,它会从数据库重新加载,这会损害性能。 由于应用程序流量高,许多企业不想处理这个问题. 这就是为什么如果您有一个多数据中心部署,甚至应用程序数据也必须通过 WAN 进行复制。
解决方案: NCache 通过 Bridge 进行 WAN 复制
针对以上情况, NCache 通过网桥提供 WAN 复制功能。 这允许您部署 NCache 跨主动-被动、主动-主动、3+ 数据中心主动-主动配置的多个数据中心。
2站点主动-被动
在主动-被动配置中, NCache 部署在主动站点和被动站点上,在主动站点上创建桥接拓扑。 图 1 显示了它在主动-被动配置中的布局方式。 所有应用程序更新都从活动站点的缓存发送到网桥,网桥在几毫秒内将它们异步发送到被动站点。 这里唯一的延迟是数据中心之间的延迟,如果它们相距很远。 因此,具有异步排队机制的桥接拓扑允许所有这些更新发生而不会溢出任何东西。
NCache 更多信息 缓存同步模式 NCache 配套文档
2站点主动-主动
另一种配置 NCache supports 是主动-主动的,两个站点都处于活动状态。 一个拥有缓存和网桥拓扑,另一个只拥有缓存。 图 2 显示了这是如何完成的。 与主动-被动模式类似,在主动-主动模式中,缓存将其更新发送到网桥,而网桥又将更新发送到其他缓存。 但是,现在有区别了。 当双方同时更新同一项目时,可能会发生冲突。 这意味着网桥必须协调来自两个站点的更新并异步解决冲突,以避免对每个活动站点的缓存性能产生不利影响。
NCache 更多信息 多数据中心 WAN 复制 NCache 配套文档
3+ 站点主动-主动
第三种情况,有3个或更多的活跃数据中心。 这里的一个活动站点有缓存和网桥,所有其他站点只有缓存。 也就是说,该网桥位于其中一个站点的本地,但其他两个站点远程访问该网桥。 与主动-主动场景类似,在这个 3+ 主动-主动场景中,所有缓存都将更新发送到网桥,而网桥将更新传播到所有连接的缓存。 同时,它执行冲突解决以确保从缓存中更新的相同数据不会导致数据完整性违规。
图 3 显示了三个双活数据中心。 NCache 允许非常无缝和异步的缓存复制。 没有应用程序代码更改。 应用程序甚至不知道缓存正在被复制,但它是通过数据中心的 WAN 异步复制的。
并行和批量异步 WAN 复制
对缓存的所有更新都是异步的。 它们异步的原因是多个数据中心之间的距离。 由于延迟,此距离可能会导致性能不佳。 当应用程序缓存在同一数据中心时,服务器之间的访问时间非常快。 但在 WAN 上,它通常非常慢。 因此,如果您不进行异步更新,无论是谁发出更新请求,都必须等待更新完成——同步更新,这会减慢您的应用程序。
然而,异步复制意味着每个站点的应用程序和缓存都不会等待它们的数据被复制到其他数据中心。 数据在排队 桥. 网桥本身是一个双节点集群,将来自所有缓存的所有更新请求排队。 对于主动-被动,请求是 排队 仅来自主动缓存并异步应用于被动缓存。 如果您拥有三个或更多数据中心,则该网桥会将更新并行应用到多个活动站点。
此外,网桥执行批量更新。 这意味着您可以将多个数据项组合成一个请求,并将它们作为一个批量请求发送到其他站点,从而大大减少网络传输。 因此,这种并行、批量和异步复制的强大组合提高了跨多个数据中心复制缓存的性能。
NCache 更多信息 WAN 复制拓扑 NCache 配套文档
解决冲突
如果您有多个活动站点,那么每个站点都可以同时更新相同的数据。 确保您的本地计算机与当地时区同步。 当然,不同时更新也没有问题。 假设您在时间 T1 更新项目 1,并在时间 T2 更新项目 2。 时间 T2 的更新是应用的最后更新。 但是,如果两个更新同时发生,则 桥 必须以两种方式之一解决冲突。
-
默认“最后更新获胜”逻辑: 网桥自动从每个缓存中检索时间戳,并且所有缓存的时钟都是同步的,因此它们具有相同的时间。 网桥从每个缓存接收更新时间,并将最新更新应用于所有缓存。 同样,冲突解决的目的是对所有缓存应用相同的版本更新以避免数据完整性问题。
-
冲突解决处理程序: 桥解决冲突的另一种方式是它可以根据其分析更新的逻辑提供冲突解决处理程序。 由于此解析器配置有 NCache,桥将提供对象的两个副本,解析器将根据提供的逻辑分析哪个版本更好。 这会将最终版本返回给桥并将此更新应用于所有缓存。
以下代码片段为您提供了部署在缓存上的冲突解决程序实现示例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
public class Resolver : IBridgeConflictResolver { public void Init(System.Collections.IDictionary parameters) {. . .} public ConflictResolution Resolve(ProviderBridgeItem oldEntry, ProviderBridgeItem newEntry) { var conflictResolution = new ConflictResolution(); switch (oldEntry.BridgeItemVersion) { case BridgeItemVersion.OLD: { /* Replace item with new entry */ } break; case BridgeItemVersion.LATEST: { /* Keep old entry */ } break; case BridgeItemVersion.SAME: { /* Your logic to replace entry if needed */ } break; } return conflictResolution; // Configure this implementation on cache } public void Dispose() {. . .} } |
因此,通过建立冲突解决机制 NCache,您放心,您的缓存永远不会不同步。 它永远不会有两个不同版本的数据更新,并且在多个数据中心之间始终保持一致。
在运行时处理灾难
现在让我们谈谈在一个站点出现故障的灾难情况下会发生什么。
主动-被动
案例 1:被动站点宕机
主动-被动配置充当灾难恢复站点。 因此,如果被动端出现故障,主动端仍将工作,您的应用程序将继续运行。 在您干预恢复被动站点之前,网桥无法将数据复制到被动站点。 当您还原被动站点时,它会重新连接到网桥并重新同步,从而丢弃现有缓存并有效地跨网桥获取活动站点缓存的完整副本。 同步完成后,切换到普通的 WAN 复制模式。
案例二:活跃站点宕机
如果活动站点出现故障,则意味着您遇到了某种灾难,因为网桥出现故障,应用程序可能会出现故障。 您现在必须将所有流量发送到 被动站点 现在变得活跃。 所有数据都从原始活动站点复制到原始被动站点,不会对用户造成中断。 原来的被动站点现在处于活动状态,因此所有更新都在这里进行,但用户不会看到任何中断。
但是,一旦原来的活动站点再次启动,它就会连接到新的活动站点(原来的被动站点)并且 同步 自己完全。 同步完成后,即使所有流量都流向原始被动站点,两者都是主动-主动的。 您可以灵活地将所有流量卸载到原始活动站点,并将双活站点的状态更改回桥上的被动。 NCache 允许您在运行时执行所有这些操作,而不会在发生主动-被动灾难时发生任何中断。
主动-主动
当带有网桥的活动站点出现故障时,WAN 复制会因为网桥出现故障而停止。 但是,其他活动站点将继续运行,所有流量都将路由到它们。 一旦启动了故障站点,就可以启动网桥并将活动站点连接到网桥,这样两个站点就会同步。 这一切都在运行时完成,因此不需要停机。 一旦网桥同步,两个站点将能够相互推送更新。 NCache 从而提供容错能力。
NCache 更多信息 缓存同步模式 NCache 配套文档
3+ 活跃网站
第三种情况是当您有 3 个或更多活动站点时,其中一个站点有网桥,而其他站点没有。 如前所述,在这种情况下会发生两种情况。
案例一:非网桥活动站点宕机
在这种情况下,其他站点将继续相互复制,并且该站点的流量将重新路由到其他连接的站点,而不会中断用户。 站点启动后,它会重新连接到网桥并重新同步以获取缓存的最新副本。 这是让交通回到正轨的信号。
案例 2:带网桥的活动站点宕机
在网桥出现故障的情况下,其他两个活动站点继续工作,但它们无法相互复制更新,因为没有网桥。 所以,此时你能做的就是在另外两个活动站点中的一个启动一个桥接。
要启动网桥,您需要两个节点作为 簇. 理想情况下,您应该为 网桥拓扑 在该站点上,但您也可以将两个缓存服务器用作一个集群,因为它很可能是临时的。 但是,它可能会对这些缓存服务器产生一些性能影响,因为现在网桥也会消耗 CPU 和内存等资源。
您需要 启动桥梁 在两个活动站点都已在运行的活动站点之一上。 正在运行的缓存现在可以连接到网桥。 因此,它们都连接到网桥并通过相互复制所有更新来同步。 用户不会遇到任何中断,因为这两个站点同步并相互传播更新。 因此,如果任何站点出现故障,您不会丢失任何数据。
现在,一旦带有网桥的原始站点恢复正常,您就可以简单地:
- 在临时站点上拆除桥梁。
- 拆桥 来自现有的缓存。
- 在原址上架桥。
- 将所有缓存连接到这个新桥。
由于您可以在运行时将缓存连接到网桥, NCache 允许您通过脚本自动化所有这些工作,因此您可以无缝处理桥接站点出现故障并且您必须将其恢复的情况。
结论
NCache 为您提供强大的 WAN 复制机制,使您能够处理许多不同的高级场景。 此外,它以快速高效的方式执行 WAN 复制,并处理主动-被动、主动-主动或三个或更多主动-主动数据中心。