CN114756519A - 与无状态同步节点的托管文件同步 - Google Patents

Abstract

在此公开了一种用于与无状态同步节点的托管文件同步的系统和方法，其中客户端端点设备具有对托管文件存储上存储的文件的直接访问。当客户希望与在托管文件存储上存储的文件同步时，该处理识别可处理该请求的同步角色。特定的同步角色不需要维护与客户端设备或文件存储的状态。对于同步过程的处理必要的状态与同步角色保持分离，使得系统中的任意同步角色都可以挑选请求并处理请求。一旦角色被选择，同步过程将照常进行。由于状态不是由同步角色维护的，因此多个角色可以处理该请求，或者两个角色可以处置该过程的不同部分。

Description

与无状态同步节点的托管文件同步

本申请是国际申请号为PCT/US2016/049441、国际申请日为2016年08 月30日、进入中国国家阶段日期为2018年03月08日、国家申请号为 201680052057.3的发明专利申请的分案申请。

技术领域

本公开整体涉及电子安全，并且更具体地，涉及与无状态同步节点 的托管文件同步。

背景技术

多年来已经产生了各种文件同步解决方案。在这些解决方案中， 同步端点对于用户和应用程序是可访问的。在文件被创建、修改或删 除时，主动-主动同步引擎负责同步这些改变并使所有端点达到一致 状态。一些同步解决方案支持具有托管文件端点。然而，这些解决方 案受到以下限制中的一者或两者的影响。首先，托管端点对终端用户 或应用程序是不可访问的。相反，托管端点只能作为在其他(非云) 端点之间的同步文件的“中枢”。其次，托管端点可能是可访问的， 但只能经由同步解决方案特定的访问协议访问。基本上，没有对托管 端点处的文件的“直接访问”。相反，应用程序或服务必须实现同步 解决方案特定的协议，并通过同步解决方案作为中间层来访问该文 件。此外，同步会话要求某个状态在整个会话中保持不变。这要求状 态在服务节点和两个端点之间被维护，使得在可扩展的系统中，该过 程与特定节点绑定。

发明内容

为了向读者提供基本的理解，下面给出了本公开的简要概述。本 发明内容不是本公开的扩展概述，并且它不标识本发明的关键/重要要 素或描绘本发明的范围。其唯一目的是以简化的形式呈现本文公开的 一些概念，作为稍后呈现的更详细描述的前序。

本公开提出了一种可以用来同步来自托管文件系统的文件的系 统和方法，其中客户端端点设备具有对存储在托管文件存储/系统上的 文件的直接访问。当客户端希望与存储在托管文件存储上的文件同步 时，该过程在可处理该请求的托管平台上识别同步角色。特定的同步 角色不需要维护状态或文件存储。对于同步过程的处理所必须的状态 与同步角色分离地被维护，使得系统中的任意同步角色都可以挑选请 求并处理请求。一旦角色被选择，同步过程将照常进行。由于状态不 是由同步角色维护的，因此多个角色可以处理该请求，或者两个角色 可以处置同步过程的不同部分。这允许核心服务基于需要来放大或缩 小同步角色的大小，并且高效地管理资源的使用。

许多伴随的特征可以被更好地理解，因为通过参考结合附图考虑 的以下详细描述，许多伴随的特征将变得更好理解。

附图说明

根据附图阅读以下详细描述，将更好地理解本说明书，在附图中：

图1是示出了根据一个示意实施例的文件同步系统的组件的高层 框图。

图2是根据示意实施例的文件同步系统的框图，其中客户端设备 具有对托管文件存储的直接访问。

图3是示出了根据一个示意实施例的用于使客户端和托管端点的 文件与无状态同步角色同步的过程的流程图。

图4示出了根据一个实施例的计算设备的组件图。

在附图中，类似的附图标记被用于表示类似的部分。

具体实施方式

下面结合附图提供的详细描述旨在作为当前示例的描述，而不旨 在表示当前示例可以被构建或利用的唯一形式。该描述阐述了该示例 的功能以及用于构建和操作该示例的步骤顺序。然而，相同或等同的 功能和顺序可以通过不同的示例来完成。

当元件被称为“连接”或“耦合”时，元件可以直接连接或耦合 在一起，或者也可以存在一个或多个中间元件。相反，当元件被称为 “直接连接”或“直接耦合”时，不存在中间元件。

主题可以体现为设备、系统、方法和/或计算机程序产品。因此， 可以用硬件和/或软件(包括固件、驻留软件、微代码、状态机、门阵 列等)来实现主题中的一些或全部。此外，主题可以采取计算机可用 或计算机可读存储介质上的计算机程序产品的形式，该计算机可用或 计算机可读存储介质具有体现在介质中的计算机可用或计算机可读 程序代码，以供指令执行系统使用或与指令执行系统结合使用。在本 文档的上下文中，计算机可用或计算机可读介质可以是能够包含、存 储、传送、传播或传输该程序，以供指令执行系统、装置或设备使用 或与指令执行系统、装置或设备结合使用的的任意介质。

计算机可用或计算机可读介质可以是例如但不限于电子、磁性、 光学、电磁、红外或半导体系统、装置、设备或传播介质。作为示例 而非限制，计算机可读介质可以包括计算机存储介质和通信介质。

计算机存储介质包括用于存储诸如计算机可读指令、数据结构、 程序模块或其他数据的信息的、以任意方法或技术实现的易失性和非 易失性、可移动和不可移动介质。计算机存储介质包括但不限于 RAM、ROM、EEPROM、闪存或其它存储技术、CD-ROM、数字多 功能盘(DVD)或其他光存储、磁带盒、磁带、磁盘存储或其它磁存 储设备、或可用于存储所需信息并可由指令执行系统访问的任意其他 介质。注意，计算机可用或计算机可读介质可以是纸张或程序可以在 其上印刻的其他合适的介质，因为程序可以经由例如纸或其他合适介质的光学扫描被电子捕获、然后被编译、解释，否则如果有必要以适 当的方式进行处理、然后存储在计算机存储器中。

通信介质通常在诸如载波或其他传输机制的已调制数据信号中 体现计算机可读指令、数据结构、程序模块或其他数据，并且包括任 意信息传递介质。这与计算机存储介质不同。术语“已调制数据信号” 可以被定义为以下信号，该信号使其一个或多个特性以一种方式被设 置或改变，从而在该信号中对信息进行编码。作为示例而非限制，通 信介质包括诸如有线网络或直接有线连接的有线介质，以及诸如声 学、RF、红外线和其他无线介质的无线介质。上述中的任意项的组合 也应被包括在计算机可读介质的范围内，但不包括在计算机存储介质 内。

当主题在计算机可执行指令的一般上下文中体现时，该实施例可 以包括由一个或多个系统、计算机或其他设备执行的程序模块。通常， 程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、 对象、组件、数据结构等。典型地，在各种实施例中，程序模块的功 能可以根据需要组合或分布。

图1是示出文件同步系统100的组件的高层框图。文件同步系统 100包括同步端点110和同步端点150。同步端点110与同步数据库 120连接并且与同步系统130关联。类似的，同步端点150与同步数 据库160连接并且与文件系统170相关联。同步端点110包括文件同步提供器111、同步元数据组件112、数据接收机113、改变更新器 114和协调器115。同步端点150包括文件同步提供器151、施加器组 件152、冲突解决器/检测器153、同步施加器目标154和同步元数据 组件155。为了讨论的目的，组件被布置在从端点110到端点150的 上传场景中。

在讨论文件同步提供器111或151的特定组件之前，将讨论可以 提供数据的不同类型的参与者。参与者是取回来自数据源的信息的位 置。参与者可以是从网络服务到笔记本计算机到USB拇指驱动器的 任意东西。

基于特定设备的能力，提供器整合同步的方式将有所不同。至少， 该设备能够在需要时以编程方式返回信息。最终，需要确定的是，设 备是否可以使信息能够在现有设备上或当前数据存储器中存储和操 纵，并允许应用程序直接从设备执行。

区分参与者的类型以了解参与者是否能够存储提供器所需的任 意状态信息以及是否能够直接从设备执行该提供器是很重要的。理想 情况下，参与者模型是通用的。因此，可以将完整参与者配置为部分 参与者或简单参与者。

完全参与者是允许开发人员直接在设备上创建应用程序和新数 据存储的设备。笔记本计算机或智能手机是完全参与者的示例，因为 可以直接从设备执行新应用程序，并且可以创建新的数据存储以在需 要时保留信息。部分参与者是能够将数据存储在设备上的现有数据存 储或其他数据存储中的设备。然而，这些设备不具有直接从设备启动 可执行文件的能力。这些参与者的一些示例是拇指驱动器或SD卡。 这些设备的作用类似于其中可以创建、更新或删除信息的硬盘驱动 器。然而，它们通常不会提供允许应用程序直接在其上执行的接口。 简单的参与者是仅能够在请求时提供信息的设备。这些设备无法存储或操纵新数据，也无法支持新应用程序的创建。由诸如亚马逊或EBay 的外部组织提供的RSS馈送和网络服务都是简单参与者的示例。这些 组织可以提供执行或调用网络服务并拿回结果的能力，但是它们不能 提供为特定用户创建数据存储的能力，也不能提供创建在其网络服务 器内部执行的应用程序的能力。

文件同步提供器111和提供器151是在同步端点110和同步端点 150两者上发现的类似组件。文件同步提供器可以用于同步诸如 NTFS、FAT、或SMB文件系统的许多不同的文件系统中的文件和文 件夹。此外，要同步的目录可以是本地的或远程的。它们不必具有相同的文件系统。应用程序可以使用静态过滤器通过显式列出或通过使 用通配符(如*.txt)来排除或包含文件。或者应用程序可以设置排除 整个子文件夹的过滤器。应用程序还可以注册以接收文件同步进度的 通知。

协调器115是被配置为发起和控制两个端点或参与者之间的同步 会话的系统100的组件。协调器与提供器111和151两者通信以开始 同步过程并且报告回同步的进度。协调器使用的实际处理在同步过程 中是众所周知的，并且协调器115可以使用任意处理。

改变更新器114是系统100的组件，其识别自从上次改变更新器 114运行以来不通过同步而发生的对文件系统的本地改变。改变的检 测/识别可以通过简单地比较与相应的上一个同步时间相关联的时间 戳来进行。其他方案和方法可用于确定在命名空间中所做的改变。

同步数据库120和160是系统100的组件，该组件存储关于文件 系统中的文件的元数据。同步数据库120和160提供关于要在客户端 和服务器之间同步的特定文件的元数据。这些数据库也可以被称为元 数据存储。

同步数据库120、160提供了存储关于文件系统和该文件系统内 的对象的关于状态和改变信息的的信息的能力。文件系统的元数据可 以被分解为五个组件(并发跟踪属性)：版本、知识、滴答计数、副 本ID和墓碑。

对于正被同步的每个项目，存储描述项目何地以及何时被改变的 少量信息。此元数据由两个版本组成：创建版本和更新版本。版本由 两部分组成：数据存储分配的滴答计数和数据存储的副本ID。随着 项目的更新，滴答计数会由数据存储增加，并且新的当前滴答计数被 应用于该项目。副本ID是标识特定数据存储的唯一值。在项目被创 建时，创建版本与更新版本相同。对该项目的后续更新修改更新版本。 即创建版本保持不变而更新版本改变。

有版本控制可以实现的两种主要方式。第一种被称为在线追踪。 在此方法中，在做出改变时，针对项目的改变跟踪信息被更新。例如， 在数据库的情况下，在行更新后可以使用触发器来立即更新改变跟踪 表。第二种方法被称为异步跟踪。在这种方法中，有一个运行并扫描 改变的外部过程。发现的任意更新都会添加到版本信息中。该过程可 以是被调度的过程的一部分，或者可以在同步之前执行。当项目被更 新时没有内部机制来自动更新版本信息时(例如，当无法在更新管道 中注入逻辑时)，通常会使用此过程。检查改变的常用方法是存储项 目状态并将其与当前状态进行比较。例如，它可能检查自上次更新以来最后写入时间或文件大小是否已改变。当然，也可以使用其他版本 控制方法。

所有改变追踪必须至少在项目的级别发生。换句话说，每个项目 都必须具有独立的版本。在文件同步的情况下，项目可以是文件，但 它可以是其他可以同步的项目，例如文件夹。在某些场景下，可能需 要更细化的跟踪，因为它降低数据冲突的可能性(两名用户更新不同 副本上的相同项目)。缺点是它会增加存储的改变跟踪信息的数量。

另一个概念是知识的概念。知识是复制品意识到的改变的简洁表 示。随着版本信息被更新，针对数据存储的知识也被更新。诸如提供 器111和151的提供器使用副本知识来枚举改变(确定另一副本不知 道哪些改变)并检测冲突(确定哪些操作是在不具有彼此的知识的情 况下进行的)。

每个副本还应当维护被删除的每个项目的墓碑信息。这很重要， 因为在同步被执行时，如果项目不再存在，提供器将无法辨别该项目 已被删除，并且因此无法将该改变传播给其他提供器。墓碑可以包含 以下信息：全局ID、更新版本和创建版本。因为墓碑的数量会随着 时间的推移而增长，所以为了节省空间，一些实现可以创建一个过程 以在一段时间后清理该存储。也就是说，这些删除的文件将从使用元 数据信息维护的文件列表中被移除。为了防止这种情况发生，系统可 以实现用于捕获这些文件的方法。该方法通过在可能存在丢失的墓碑 时首先确定条件是否被满足而开始。副本保留知识的另一副本，该另 一副本可以被认为或被称为“被遗忘的知识”。当墓碑被从数据库中 移除/清理时，被遗忘的知识被设置/更新。这些被遗忘的知识可以跟 踪已经清理了哪些滴答计数。这可以提供关于什么时候墓碑可能已经 丢失的提示。然后，如果在一段时间同步未发生(副本变得陈旧)， 则被遗忘的知识帮助检测副本可能是陈旧的。陈旧的副本可以启动 “完全枚举同步会话”。该完整枚举是时间密集且昂贵的同步会话， 借此所有文件元数据均在同步会话的参与者之间传送。

施加器152是系统的组件，其应用被指示为完成同步过程所需的 特定改变。这些改变是基于与每个文件相关联的元数据在同步过程中 由改变更新器114记录的改变。根据同步过程的方向(上传或下载)， 施加器152将在相应的同步端点上操作。在图1中，图示了其中客户 端110将其改变上传到客户端150的上传过程。

冲突解决器153解决在已经存储的数据文件与作为同步过程的一 部分接收的数据文件的声称的更新版本之间检测到的冲突。基本上， 如果对同步会话之间的两个副本上的相同项目进行改变，则会发生冲 突。在源知识不包含针对项目的目标版本(理解的是目标知识不包含 任何被发送的源版本)时，则特别地发生冲突。如果该版本被包含在 目标的知识中，则该改变被认为已过时。副本可以自由地实现各种政 策用于解决跨同步社区存在冲突的项目。在某些方案中，无论冲突发 生在何处或在何处检测到冲突，副本中的每一个都做出相同的解决方 案。

以下是常用解决策略的一些示例：源胜利：在发生冲突的情况下， 本地副本所做的改变总是胜利。目的地获胜，远程副本总是胜利。指 定的副本ID始终获胜，即无论谁改变项目，具有指定ID的副本始终 获胜。最后写入者获胜，这是基于所有副本被信任进行改变并且挂钟 被同步的假设。因此，文件的最后写入者被允许获胜。合并时，在有 两个重复项目冲突的情况下，系统会将信息从一个文件合并到另一个 文件中。日志冲突，在这种方案中，系统选择简单地记录或推迟该冲 突。

同步目标应用程序154是系统的组件，其在解决由冲突解决器所 确定的任意冲突之后应用所指示的改变。具体改变分为两组。第一组 是改变为文件的实际数据。该信息通过施加器154处理并提供给文件 系统170，该文件系统170使得对基础文件进行适当的改变。第二改 变集合是对同步元数据所做的改变。这些通过元数据组件155被应用 于同步数据库160，其中关于特定文件的元数据被存储。

托管平台通常实现特定服务或缩放单位的许多实例。服务的每个 实例可以与特定的客户端或特定的服务订阅相关联。传统托管平台可 以响应增加的负载向该实例添加附加资源。然而，附加的资源导致构 成服务的所有资源的增加，而不是构成服务的单个组件的增加。即， 与仅需要更多资源的单个组件相反，服务的所有组件都增加了。服务 代表平台中的生命周期和管理的独立的单元，并且可以与其他服务完 全隔离地被被部署和服务。服务之间的通信只能经由公共端点进行， 而服务角色之间的通信可以通过公共和内部/受保护的端点进行。从网 络角度来看，每个服务都具有单一的负载平衡的虚拟IP(VIP)。每 个VIP是用于检测和防止分布式拒绝服务(DDoS)攻击的一个独立 的实体。为了避免要求客户端重新映射非默认HTTP端口(80、443) 用于在单个服务内与不同角色端点进行通信，一种方案利用分离的服 务在默认端口上公开端点。第二种方案利用前端(frontdoor)服务， 基于接收到的统一资源定位符(URL)将默认端口上的请求路由到单 个服务内的角色。当前平台中的服务和角色都包含逻辑上相关的组件 组。当服务的功能或部署彼此显著分离时，或者相关服务的功能被利 用时，会创建单独的服务。

图2是根据一种方案实现服务和角色的平台200的框图。服务包 括订阅服务220、核心服务210、监控服务230、分析服务240、元数 据存储250、管理数据存储260、文件存储280和运行时状态存储270。 然而，在其他方案中，根据特定最终用户的需求和期望，附加服务可 以被添加到平台上。客户端设备290连接到平台以访问这些服务。

核心服务210在服务内实现多个不同的角色。这些角色包括前端 角色211、管理角色212、同步/召回角色213、后台处理角色214、数 据访问发现角色215、以及备份/恢复角色216。应当注意的是，图2 示出了核心服务210的单个实例和核心服务210内的每个角色。然而， 在本平台中，核心服务210可以存在于任意数目的节点上，并且这些 节点可以分布在全球的不同位置处或者在数据中心内。对任意特定角 色的请求都可以由节点的这些特定实例中的任意一个提供服务。此 外，本文呈现的角色中没有一个角色依赖于文件存储280或元数据表 的特定实例。更进一步，应当注意的是，根据平台的需求，某些角色 可以被扩展到更多节点上，而无需同样扩展剩余角色。

前端角色211在一种方案中被配置为基于关守模式来实现薄前 端。关守模式被设计为通过使用专用主机实例来保护应用程序和服 务，该专用主机实例充当客户端与应用程序或服务之间的代理。它验 证并清理请求，并在它们之间传递请求和数据。这提供了附加的安全 层，并且可以限制系统的攻击面。前端角色211执行传入请求的验证 并基于请求的内容来将这些请求路由到管理角色212、同步角色213、 数据访问角色215或备份/恢复角色216。前端角色211或同步角色213 还将对长时间运行任务的请求排队到后台任务队列中的后台处理角 色214。

在一些方案中，前端角色211还实现附加的安全措施或方案以增 强对客户端数据的保护和系统的总体安全性。前端角色211将与安全 库218交互以实现附加的安全性。安全库218可以实现安全机制，诸 如相互认证、SSL/TLS加密、RMS数据加密、共享秘密、分布式拒绝服务(DDoS)保护和共享访问签名。其他安全机制可以被采用。

管理角色212在一种方案中被配置为向该平台中的其他服务和角 色提供供应、管理和配置能力。管理角色212提供用于对核心服务的 管理访问的服务端点以及通过命令输入来修改服务的能力。用于管理 角色212的关联数据被存储在管理数据存储260中。

本文中被称为同步角色213的同步/撤回角色是平台的组件，该组 件被配置为服务同步以及被从前端角色211以无状态方式提供给它的 来自同步和撤回客户端(例如，客户端设备290)文件撤回前台请求。 客户端设备290向前端角色211发出同步请求，前端角色211然后向 同步角色213提供该请求。同步角色213与负载平衡器接口，该负载 平衡器针对效率平衡该请求，并确保在预定的超时时间之前响应被返 回。同步期间的同步角色213访问来自元数据存储250、文件存储280 和位于平台背景上的运行时状态存储270的数据。在给定时间在平台 上可以存在任意数目的同步角色213操作。这允许同步请求的高效处 理。这些同步角色213中的任意一个均能够处理该请求。由于来自客 户端设备290的这样的请求可以在不同的时间去往同步角色213的不 同实例。如前所述，同步角色213相对于文件服务和文件存储280是 无状态角色。

核心服务还包括负载平衡器，其基于无状态同步/恢复处理以及高 效缓存系统来实现前端请求的负载平衡。如果不随时间进行护理，则 同步角色213的每个实例将最终为来自与它连接或通信的客户端设备 290的每个请求缓存数据。这就是说，每个合作伙伴都会导致附加的 缓存。因此，负载平衡器实现缓存策略，该缓存策略使同步角色213 免于使其CPU和内存利用率超过门限限制并且还确保内部数据结构 保持低于门限水平。在一种方案中，负载平衡器使用循环策略来路由 请求。也就是说，针对没有请求的服务的下一同步角色213被指派来 处理该请求。负载平衡器也可以采用启发式方法来优化本地使用的高速缓存的位置和资源使用情况。例如，可以基于向请求提供紧密度 (affinity)的租户或同步文件夹的散列来路由对同步角色213的请求， 而不向该请求引入状态全满。

后台处理角色214是处理长时间运行任务以及同步角色213卸载 以尝试平衡其工作量的从同步角色213卸载的任务的系统的组件。存 在花费很长时间段，并且如果在前台完成其操作，则可能会影响系统 的整体性能的任务。长时间运行任务可以包括诸如使用枚举的改变检 测、系统的备份和恢复等的任务。后台处理角色214从前端角色211 接收要通过后台任务队列执行的各种任务。后台任务队列实现分片和 优先级队列，用于管理给予后台处理角色214的任务。它使用与任务 的吞吐量有关的性能度量。优先级队列主要用于需要低延迟的请求/ 任务，诸如文件召回。由后台处理角色214创建的结果通过向设备的 通知被异步地报告给呼叫客户端设备290。

数据访问发现角色是向平台提供位置和数据访问能力的系统组 件。这可以包括提供对数据的安全访问。这种安全访问可以使用REST 接口和共享的访问签名密钥来实现。

备份/恢复角色216是系统的组件，其允许维护恢复数据，该恢复 数据可以在发生灾难、客户端设备替换、数据丢失或其他故障的情况 下恢复客户端设备290。备份数据可以使用该角色从设备提供给系统。 客户端设备290的恢复将导致存储在其中的数据被推送到客户端设备 290以恢复客户端设备290。

监视服务230是系统的组件，其提供服务状态、诊断和故障排除 能力，作为在系统组件的最后一英里、外内(主动)和内外(被动) 监视的组合视图。底层托管平台提供对平台基础架构(诸如数据中心 和网络)和平台服务的监控。附加的诊断和故障排除可由监视服务230 处理并在后台执行。

分析服务240是允许对系统的遥测分析的系统的组件。具体而言， 分析服务240可以提供门户，管理员可以通过该门户查看业务和操作 分析能力。这可以使管理员能够制定有关服务的现场或业务方面的数 据驱动决策。分析服务240从多个数据源接收数据以进行后处理、报 告和机器学习。这些数据源辅助生成该分析。

元数据存储250是处理用于同步过程和文件本身的元数据的系统 的组件。元数据存储250实现副本和项目元数据存储、二级索引、锁 定、快照隔离和垃圾收集。二级索引支持各种同步场景的查询模式， 诸如范围查询。提供锁定以确保一次一个写入者可以访问特定文件或 该文件所在的特定副本。在处理改变批次或在特定命名空间281的枚 举期间，这些访问发生。快照隔离消耗已提交的数据，并会阻止垃圾 收集，直到各个端点已经消耗已提交的数据。元数据存储250还提供 交叉表一致性。知识和项目数据必须一起提交。这确保了特定副本的 完整图像是已知的。即，副本是否已经改变，以及副本的状态。

管理数据存储260是管理文件存储280和对应命名空间281内的 数据以及为了管理的目的而由客户端设备290提供的任意其他数据的 放置的系统的组件。当文件存储280在各种不同的用户和客户端之间 共享时，每个命名空间281必须与其他命名空间281保持分离。管理 数据存储260维护针对由托管系统管理的每个命名空间281-1、281-2、 281-N(统称为281)的表。每个表表示特定租户的副本的配置以及 存储在文件存储280中的每个副本的命名空间281。此配置确保同步 表示文件存储280的正确配置，并且元数据也反映该配置。

文件存储280是用于命名空间281的实际数据所在的系统的组 件。文件存储280可以将数据存储在容器中。每个用户在文件存储280 中具有对应容器，该对应容器对应于管理数据存储260中维护的同步 文件夹。

这些用户容器也可以与多个不同的用户和设备共享。可能在相同 时间或几乎同时从多个端点发生对容器的访问。针对通用共享维护单 个容器。此外，通用共享对应于管理数据存储260上的同步文件夹。 与托管环境中的传统文件存储280不同，用户和设备可以直接写入相 应的容器，而不必通过同步角色213来执行这些读取并且写入。向各 种端点(用户和设备)提供允许他们获知数据所在的文件存储280上 的实际位置的信息，诸如统一资源标识符(URI)或统一命名规则 (UNC)。之前的方案已经要求使用中介来访问文件存储280，因为 文件存储280的位置对设备是不准确知道的。然而，对于特定容器或 命名空间281，对文件存储280的访问仍然可以通过同步角色213或 其他核心服务210角色来完成，如传统上完成的。因此，取决于应用 程序或设备的能力，文件可以通过任一种方法被访问。如此，传统应 用程序能够在不修改的情况下使用文件存储280。存储在文件存储280 和特定容器中的数据以无状态方式存储。也就是说，客户端管理对与 文件存储280的任意客户端交互所必须的任意瞬态。文件存储280不 维护关于其自身系统中的数据的这种瞬态的这种信息中的任意信息。

在文件命名空间281可以与云端点同步之前，必须为文件、目录 和元数据分配或供应存储。本方案为每个同步命名空间281提供单个 文件共享或容器。以这种方式，多个命名空间281可以被托管在云上， 但是每个命名空间281能够保持彼此分开。在一种方案中，文件共享 是Azure文件共享。然而，可以使用其他版本和类型的文件共享。

文件共享是表示文件夹和文件的分层命名空间281的根的文件存 储单元。共享可以通过诸如Azure File REST API的应用程序编程接 口(API)访问，也可以通过诸如ClFS/SMB协议的协议来访问。

通过将同步命名空间281映射到文件共享，可以认识到许多优点。 首先，文件共享允许直接同步到共享命名空间281根映射。诸如用户 到共享映射或租户到共享映射的其他配置选项要求将各个同步命名 空间281创建在文件共享根下。其次是快照隔离。本方案利用托管服 务的文件共享级别快照特征。这支持在单个时间点创建和维护共享的 状态的高效副本的能力。这对于支持备份还原、迁移、高可用性和需 要命名空间281的一致视图的其他功能很重要。第三是安全隔离。本 方案利用主机服务的共享访问签名(SAS)授权特征。这支持在每个 命名空间281的基础上在根级别上控制对共享的访问的选项。共享级 别访问控制可以代替或添加到文件或文件夹级别的更细粒度的访问 控制。

主机系统可以实现两种不同的方案用于确定何时针对特定命名 空间281提供文件共享。一种方案是通过管理控制台使用显式供应， 以利用特定用户的命名空间281创建命名空间281同步伙伴关系281。 第二种方案是在第一次尝试与命名空间281同步时隐式地提供命名空 间281。

一旦同步命名空间281已经被供应文件共享，命名空间281就可 以在参与者和云端点之间同步。同步解决方案使用同步伙伴关系的两 方(端点)之间的文件同步协议。同步过程可以遵循上面关于图1讨 论的过程。然而，应当注意的是，该协议涉及关于每个端点上的命名 空间281内的文件/文件夹的状态的元数据的交换，随后是一个或者更 多上传和下载会话，其中在每个端点上传输和创建文件和文件夹元数 据和数据，直到每个端点上的命名空间281的状态匹配。在自上次同 步会话以来文件在同步伙伴关系两侧均发生改变的情况下，冲突被检 测到，这可以导致改变的一个或两个集合被保留。

运行时状态存储270是维护文件的状态和文件的同步状态的系统 的组件。运行时状态存储270使特定同步角色213能够与文件系统和 文件存储280保持无状态。当特定同步角色213需要状态来执行特定 任务时，运行时状态存储270提供所需的状态关系，以使同步过程继 续。由于状态远离同步角色213被维持，所以任意同步角色213都可 以执行任意同步过程。

客户端设备290是可以连接到同步角色213的任意设备，用于使 其数据与托管并存储在文件存储280上的数据同步。客户端设备290 可以包括位于场所内的服务器、移动电话、笔记本计算机、平板计算 机、或与文件存储280或核心服务210的另一实例接口的任意其他设 备。此外，在设备被托管在另一平台上的情况下，设备也可以是设备 的虚拟版本。客户端设备290可以直接与文件存储280交互并向文件 存储280写入，或者可以通过同步角色213访问文件存储280以及其 中包含的特定容器。每个客户端设备290也具有同步引擎292的其自 己的版本。该同步引擎是用于客户端设备290的网关，用以启动与同 步角色213的同步上传或下载。从客户端的角度来看，同步过程与其 中访问数据的唯一途径是通过中介的系统并无不同。

本系统中的文件同步活动可以是周期性的并且可以通过调度来 驱动，或者可以是来自同步伙伴关系的客户端端点的按需指令。文件 访问活动可以在任意时间发生，因为客户端设备290可以直接访问文 件存储而无需使用中间同步角色来访问基于云的文件。

图3是示出了根据一个示意实施例的用于在客户端设备290和远 程文件服务之间同步文件的过程的流程图。在客户端设备290请求与 核心服务210的同步会话时，同步过程开始。这在步骤310中示出。 在一些方案中，请求由客户端设备290生成。在其他方案中，请求由 核心服务210生成。在该方案中，核心服务210向客户端设备290发 送消息，指示客户端设备290作出同步请求。同步请求可以是按需同 步请求，或者它们可以是周期性同步请求。周期性同步请求的定时可 以由管理员设置，以确保所有同步客户端间数据的一致性。例如，取 决于相应文件中的活动级别，周期性同步请求可以每天或每小时被执 行一次。

同步请求由核心服务210接收并被提供给核心服务210的前端角 色211，以确定是否可以处理该请求。这在步骤320中示出。再次如 前所述，前端角色211不具有对文件存储中的相应文件的直接访问， 对主机系统的任意持续性存储器的有限访问并且可以对所接收的请 求进行负载均衡。在过程的该步骤中，前端角色211实现其在保护客 户端数据的公开中的关守模式。前端角色211验证来自客户端的请求 是正确的请求并且包含正确的凭证。如果请求不符合访问底层数据存 储或服务的要求，则前端角色211不再处理这些请求。如果请求确实 满足对访问的要求，则前端角色211将请求路由到正确的服务角色和 分片，以支持维持无状态同步所必需的资源紧密度。

前端角色211分析该请求并确定该特定请求是否用于长时间运行 任务。这在步骤330中示出。长时间运行任务是诸如枚举、系统的备 份和恢复等的任务，该任务使用大量或资源或者其执行超过预定门限 时间量来完成。这些长时间运行任务将被发送到后台任务队列以便从 那里进行处理。前端角色211此时可以尝试通过向同步角色213发送 用于确定特定请求的大小的请求来确定请求的大小。同步角色213可 以从元数据存储250读取以确定哪些文件已经改变。基于已经改变的 文件的数目，前端角色211可以确定该特定同步请求是长时间运行请 求或正常请求。在某些情况下，前端可以自行确定该请求是针对长时间运行还是短时间运行任务。例如，如果同步请求是针对特定文件或 特定文件夹的，则前端角色211可以确定该任务是短时间运行任务。 而如果请求是针对一系列文件夹或目录的，则前端角色211可以确定 该请求是长时间运行任务。在其他情况下，前端角色211简单地将同 步请求传递给同步角色213并且允许同步角色确定请求是短时间运行 还是长时间运行的，以及应当由同步角色213处理还是传递给后台任 务处理角色214。

后台任务处理角色从由前端角色211填充的后台任务队列接收长 时间运行任务。这在步骤335中示出。后台任务处理角色获取队列中 的下一任务，并确定请求或任务是否需要被分片。分片是数据库分区 的一种类型，它将超大型数据库分成更小、更快、更易于管理的称为 数据分片的部分。在这种情况下，文件存储280已被分成水平分区或 分片。每个分片具有相同的模式，但保留自己独特的数据子集。分片 本身就是数据存储，运行在文件存储280的存储节点的不同实例上。 在这种情况下，请求将被分成不同的部分以到达底层数据所在的文件 存储280的适当部分。后台任务处理角色然后将该请求处理到相应的 文件存储280以取回或更新所包含的数据。客户端设备290将由后台 任务处理角色异步地更新这些后台任务的状态。在一种方案中，后台 处理角色214处理请求，并将结果存储在运行时状态存储270中。前 台211可以从运行时状态存储270取回操作的结果，以便可以将响应提供给客户端设备290。在某些情况下，前端211检查运行时间状态 达一小段时间，以查看该任务是否以中等时间量(在30秒的级别) 完成，因此它可以立即将结果返回给客户端。这在识别某个任务为长 时间运行的启发式方法错误，并且该任务实际执行很快的情况下非常 有用。在其他情况下，当前端211已经等待足够长时间时，它返回一 个“未决”结果返回给客户端，利用URL代表未决结果。客户端290 可以通过轮询未决的结果URL来继续等待结果。在接收到该未决结 果URL时，前端211可以检查运行时状态存储270，以查看任务是否已经报告了结果。如果找到一个，则将长时间运行的任务的结果返回 给客户端290。长时间运行的任务的进一步处理类似于短时间运行任 务的处理，并且其后是下面的步骤350-370。

如果该请求被确定为短时间运行任务，则同步请求被传递给同步 角色213用于处理。这在步骤340中示出。前端角色211可以基于多 个因素来选择特定同步角色213用以接收请求。当同步角色213的多 个节点存在时，前端角色211可以简单地基于循环方案来选择同步节 点。也就是说，例如，如果先前选择了第一同步角色213节点，则将 选择该组节点中的第二同步节点用于下一同步请求。在其他方案中， 前端角色211结合负载平衡器可以查看当前在节点上经历的负载和同 步请求的大小，并选择低使用率同步角色213节点用于处理该请求。 前端角色211对请求进行负载均衡，然后将该请求发送到选择的同步 角色213。在某些方案中，由于同步请求的大小或请求在该同步中被 服务所需的速度，请求可以被前端角色211分解或者被分片几个批次。 这些批次中的每一个可以被发送到不同的同步角色213用于处理。在 一些方案中，请求可以代之以被发送到后台处理角色214。

同步角色213从前端角色211接收同步请求并开始处理同步请 求。这在步骤350中示出。此时，同步角色213需要确定哪些文件已 经改变，并且因此需要与哪些文件同步。同步角色213基于这些改变 来建立或识别要从文件存储280上传或下载的文件的批次。关于哪些 文件将被同步过程修改的信息被提供回前端角色211，该前端角色211 将该信息提供给客户端设备290。在一些方案中，同步角色213可以 将该信息直接提供回客户端设备290。包括在要通过上传或下载来修 改的文件中，同步角色213可以提供统一资源标识符，使得客户端设 备290可以作为同步过程的一部分直接读取文件存储280或向文件存 储280写入。以这种方式，任意同步角色213可以处理对同步过程的 请求，因为它不需要在过程期间用文件保持状态。对于上传同步，同 步角色213促使在文件存储280中创建暂存文件夹或区域。暂存文件 夹是保留区域，在该区域中要同步的文件的较新版本被临时保持直到 同步角色213可以通过同步过程将文件提交到文件存储280。在一些 方案中，同步角色213可以确定发送给它的特定请求将超过资源使用 的预定门限。在这种方案中，同步角色213可以将该请求重定向到后 台处理角色214进行处理。在其他方案中，同步角色213可以自己将该请求分片并发送到其他同步角色。

客户端设备290从文件存储280接收要上传或下载什么文件的批 次信息，并传输批次中指示的文件。这在步骤360中示出。在该步骤 处，并且取决于上传或下载同步，客户端设备290的文件系统或者将 文件上传到文件存储280中的暂存文件夹，或者从文件存储280下载 相应的文件。这些文件的上传/下载直接用文件存储280执行或通过不 同文件传输协议的用户执行，不且不通过核心服务210或同步角色 213来执行。以这种方式，核心服务210中的特定角色在这个处理中 不需要用文件本身维护状态。只用文件存储280维持状态。当文件被 上传到文件存储280时，它们被上传到文件存储280中的暂存文件夹 中。由同步角色213创建的每个批次可以具有其自己的暂存区域。一 旦文件被上传到暂存区域，或者下载完成，客户端设备290向同步角 色213发送指示客户端设备290已经完成上传/下载的消息。在一些方 案中，暂存文件夹中的文件和文件存储280中的文件的相应版本在上 传过程中不被锁定读写。如果文件存储280中的文件在同步可以被完 成之前发生改变，诸如从另一设备访问该文件存储280，尽管直接访 问功能该文件此时不会被同步或提交，但可以被阻止直到稍后同步。

同步角色213通过提交改变来响应上传/下载已经完成的指示。这 在步骤370中示出。对于下载，同步角色213向客户端提供改变批次， 允许客户端下载文件内容并将改变应用于其本地文件存储和本地元 数据存储。在一些方案中，同步角色213通过将同步请求更新为完成 来提交改变，并且在一些方案中更新元数据存储250以指示特定客户 端已经用该信息更新。通过上传，同步角色213使暂存区域中的文件 覆写或替换文件存储280中的相应文件以及更新元数据存储250。同 步角色213使文件存储280中的文件被重命名为临时文件，然后暂存 区域中的文件被重命名到文件存储280作为文件的新版本。这允许文 件被更新并且该批次被处理，即使特定服务同步节点在同步过程期间 将遇到故障，因为任意同步节点都可以从暂存文件夹中拾取文件并继 续同步过程。

图4示出根据一个实施例的计算设备的组件图。计算设备400可 以被用于实现本文描述的一个或多个计算设备、计算机处理或软件模 块。在一个示例中，计算设备400可以用于处理计算、执行指令、接 收和发送数字信号。在另一个示例中，如本实施例的系统所要求的， 计算设备400可以用于处理计算、执行指令、接收和发送数字信号、 接收和发送搜索查询以及超文本、编译计算机代码。此外，计算设备 400可以是分布式计算设备，其中计算设备400的组件位于通过网络 或其他形式的连接被彼此连接的不同计算设备上。另外，计算设备400

计算设备400可以是现在已知的或者变得已知的、能够以软件、 硬件、固件或其组合来执行本文描述的步骤和/或执行本文描述的功能 的任意通用或专用计算机。

在其最基本的配置中，计算设备400通常包括至少一个中央处理 单元(CPU)402和存储器404。取决于计算设备的确切配置和类型， 存储器404可以是易失性的(诸如RAM)、非易失性(如ROM、闪 存等)或两者的某种组合。另外，计算设备400还可以具有附加的特 征/功能。例如，计算设备400可以包括多个CPU。所描述的方法可 以由计算设备400中的任意处理单元以任意方式执行。例如，所描述 的处理可以由多个CPU并行执行。

计算设备400还可以包括附加存储设备(可移动和/或不可移动)， 包括但不限于磁盘或光盘或磁带。这种附加存储设备在图4中由存储406 示出。计算机存储介质包括以任意方法或技术实现的易失性和非易失性、 可移动和不可移动介质，用于诸如计算机可读指令、数据结构、程序模 块或其他数据的信息的存储。存储器404和存储406都是计算机存储介 质的示例。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪 存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光存储 器、盒式磁带、磁带、磁盘存储器或其他磁存储设备、或可以用于存储 期望的信息并且可以由计算设备400访问的任意其他介质。任意这样的 计算机存储介质可以是计算设备400的一部分。

计算设备400还可以包含允许设备与其他设备通信的通信设备 412。通信设备412是通信介质的示例。通信介质通常体现计算机可 读指令、数据结构、程序模块或诸如载波的经调制的数据信号中的其 它数据，或其他传输机制并且包括任意信息传递介质。术语“经调制 的数据信号”是指以下信号，该信号使其一个或多个特性以一种方式 被设置或改变使得在该信号中编码信息。作为示例而非限制，通信介 质包括诸如有线网络或直接有线连接的有线介质，以及诸如声学、RF、 红外线的无线介质和其他无线介质。本文使用的术语计算机可读介质 包括计算机存储介质和通信介质两者。所描述的方法可以以诸如数 据、计算机可执行指令等的任意形式被编码在任意计算机可读介质 中。

计算设备400还可以具有输入设备410，诸如键盘、鼠标、笔、 语音输入设备、触摸输入设备等的。诸如显示器、扬声器、打印机等 的输出设备408也可以被包括在内。所有这些设备在本领域中都是众 所周知的，并且不需要详细讨论。

本领域技术人员将认识到，用于存储程序指令的存储设备可以跨 网络分布。例如，远程计算机可以存储被描述为软件的过程的示例。 本地或终端计算机可以访问远程计算机并下载部分或全部软件以运 行程序。替代地，本地计算机可以下载所需要的软件的片段，或者通 过在本地终端执行一些软件指令以及在远程计算机(或计算机网络) 处执行一些软件指令来进行分布式处理。本领域技术人员还将认识 到，通过利用本领域技术人员已知的常规技术，软件指令的全部或一 部分可以由诸如DSP、可编程逻辑阵列等的专用电路执行。

Claims (20)

1.一种方法，包括：

从客户端设备接收用于在所述客户端设备与远程托管平台上的文件存储之间同步数据的同步请求；

将所述同步请求划分为两个或更多个同步任务，并将所述两个或更多个同步任务分别指派给两个或更多个无状态同步节点；

将所述客户端设备和所述远程文件存储之间的所述数据的同步状态从状态存储传输到所述两个或更多个无状态同步节点；以及

经由所述两个或更多个无状态同步节点的传输，基于所述同步状态和所述两个或更多个同步任务同步所述数据，其导致所述客户端设备和所述文件存储中的至少一个所存储的数据发生变化。

2.根据权利要求1所述的方法，其中所述同步状态包括由至少一个不同的无状态同步节点执行的在所述客户端与所述文件存储之间的所述数据的同步历史。

3.根据权利要求1所述的方法，还包括：

基于在多个无状态同步节点中的当前同步负载，从所述多个无状态同步节点中选择所述两个或更多个无状态同步节点。

4.根据权利要求1所述的方法，还包括：

基于由所述同步请求标识的同步任务的预期持续时间，从多个无状态同步节点中选择所述两个或更多个无状态同步节点。

5.根据权利要求1所述的方法，还包括：

基于循环方案，从多个无状态同步节点中选择所述两个或更多个无状态同步节点。

6.根据权利要求5所述的方法，其中所述选择包括从所述多个无状态同步节点中选择与最近选择的无状态同步节点不同的无状态同步节点。

7.根据权利要求1所述的方法，其中所述同步包括基于不同的无状态同步节点完成在所述客户端设备和所述文件存储之间的所述数据同步的点来恢复所述客户端设备与所述文件存储之间的所述数据同步。

8.根据权利要求1所述的方法，其中所述划分包括基于所述数据的大小和所述同步请求所需的速度中的一项或多项将所述同步请求划分为所述两个或更多个同步任务。

9.根据权利要求1所述的方法，其中所述划分包括基于所述文件存储中的两个或更多个分片分别执行所述同步任务，将所述同步请求划分为两个或更多个同步任务。

10.一种计算系统，包括：

网络接口，所述网络接口被配置为从客户端设备用于在所述客户端设备和远程托管平台上的文件存储之间同步数据的同步请求；以及

处理器，所述处理器配置为：

将所述同步请求划分为两个或更多个同步任务，并将所述两个或更多个同步任务分别指派给两个或更多个无状态同步节点，

将所述客户端设备和所述文件存储之间的所述数据的同步状态从运行时状态存储传输到所述两个或更多个无状态同步节点，以及

控制所述两个或更多个无状态同步节点以基于所述同步状态和所述两个或更多个同步任务同所述步数据，其导致所述客户端设备和所述文件存储中的至少一个所存储的数据发生变化。

11.根据权利要求10所述的计算系统，其中所述同步状态包括由至少一个不同的无状态同步节点执行的在所述客户端与所述文件存储之间的所述数据的同步历史。

12.根据权利要求10所述的计算系统，其中所述处理器还被配置为基于在多个无状态同步节点中的当前同步负载从所述多个无状态同步节点中选择所述两个或更多个无状态同步节点。

13.根据权利要求10所述的计算系统，其中所述处理器还被配置为基于由所述同步请求标识的同步任务的预期持续时间从多个无状态同步节点中选择所述两个或更多个无状态同步节点。

14.根据权利要求10所述的计算系统，其中所述处理器还被配置为基于循环方案从多个无状态同步节点中选择所述两个或更多个无状态同步节点。

15.根据权利要求14所述的计算系统，其中所述处理器从所述多个无状态同步节点中选择与最近选择的无状态同步节点不同的无状态同步节点。

16.根据权利要求10所述的计算系统，其中所述处理器被配置为控制所述两个或更多个无状态同步节点以基于不同的无状态同步节点完成在所述客户端设备和所述文件存储之间的所述数据同步的点来恢复所述客户端设备与所述文件存储之间的所述数据同步。

17.一种非瞬态计算机可读介质，包括：

指令，当所述指令由处理器执行时使计算机执行方法，所述方法包括：

从客户端设备接收用于在所述客户端设备与远程托管平台上的文件存储之间同步数据的同步请求；

将所述同步请求划分为两个或更多个同步任务，并将所述两个或更多个同步任务分别指派给两个或更多个无状态同步节点；

将所述客户端设备和所述远程文件存储之间的所述数据的同步状态从状态存储传输到所述两个或更多个无状态同步节点；以及

经由所述两个或更多个无状态同步节点的传输，基于所述同步状态和所述两个或更多个同步任务同步所述数据，其导致所述客户端设备和所述文件存储中的至少一个所存储的数据发生变化。

18.根据权利要求17所述的非瞬态计算机可读媒体，其中所述方法还包括基于多个无状态同步节点中的当前同步负载从所述多个无状态同步节点中选择所述两个或更多个无状态同步节点。

19.根据权利要求17所述的非瞬态计算机可读介质，其中所述方法还包括基于由所述同步请求识别的同步任务的预期持续时间从多个无状态同步节点中选择所述两个或更多个无状态同步节点。

20.根据权利要求17所述的非瞬态计算机可读介质，其中所述方法还包括基于循环方案从多个无状态同步节点中选择所述两个或更多个无状态同步节点，其中与最近选择的无状态同步节点不同的无状态同步节点从所述多个无状态同步节点中被选择。

Images