CN105740418B

CN105740418B - 一种基于文件监控和消息推送的实时同步系统

Info

Publication number: CN105740418B
Application number: CN201610065684.2A
Authority: CN
Inventors: 林人俊; 程远; 赖兴荣; 肖佳涛; 杨倩娴
Original assignee: Hangzhou Yifangyun Network Science & Technology Co Ltd
Current assignee: Hangzhou Yifangyun Network Science & Technology Co Ltd
Priority date: 2016-01-29
Filing date: 2016-01-29
Publication date: 2019-09-24
Anticipated expiration: 2036-01-29
Also published as: CN105740418A

Abstract

本发明公开了一种基于文件监控和消息推送的实时同步系统，包括本地文件监控组件：适配Windows、MAC、Linux操作系统，实时捕获用户对本地文件系统的操作；推送服务组件：维护云端与本地客户端之间的长连接，将云端的数据变动实时推送到本地；内核数据库组件：记录云端文件和本地文件的基本元数据，用于文件当前状态和历史版本的比较，从而计算出文件差异；同步组件：根据本地与云端的文件系统的差异，自动将本地修改上传到云端，并且将云端的变动同步到本地。本发明可以全自动运行，并且能实时同步百万级别文件数量，免去了人工下载和上传文件的麻烦，从而极大地方便用户使用云服务来管理文件数据。

Description

一种基于文件监控和消息推送的实时同步系统

技术领域

本发明涉及文件同步技术领域，尤其涉及一种基于文件监控和消息推送的实时同步系统。

背景技术

随着计算机技术和互联网技术的不断发展，个人用户或者企业用户需要管理的文件数据越来越多，种类越来越丰富；同时用户对数据安全性越来越敏感。传统的U盘、硬盘等方式保存数据逐渐不能满足需求。云存储在近几年迅猛发展，逐渐成为互联网用户主流的数据存储方式，并且实现了随时随地数据访问。

然而，目前的云存储技术还存在以下几个问题。第一、无论是通过浏览器、桌面应用程序还是手机APP来上传下载文件都需要复杂的拖拽、点击操作。用户需要消耗大量的时间和精力在文件操作上；第二、在多人协作场景之下，用户本地保存的并不一定是文件的最新版本，导致每次使用文件之前都需要到云端下载最新版本；第三、当文件数目急剧增加的时候，用户无法通过手工操作，保证成千上万文件的实时同步。

因此，同步网盘应运而生。所谓同步网盘，只是保持本地文件系统中某个或者某几个文件夹与云端的文件系统保持实时同步。本地的文件修改能及时上传到云端；云端的变动也能实时反映到本地文件上，无需认为干涉，自动完成。目前已有的一些同步算法存在同步错误、实时性不强等缺点。

发明内容

针对现有技术中的不足，本发明提供了方便用户使用、准确度高、实时性强的一种基于文件监控和消息推送的实时同步系统。

本发明的目的是提供一种基于文件监控和消息推送的实时同步系统。在无人工干预的情况下，自动检测本地文件系统中的内容变化并同步到云端；将云端的内容变动以消息推送的方式发送到本地，并将实际内容同步到本地。

为了实现上述目的，本发明所采取的技术方案是包括：

一种基于文件监控和消息推送的实时同步系统，其特征在于，包括，

本地文件监控组件，所述本地文件监控组件适配不同的操作系统，用于实时捕获用户在本地操作系统中的用户操作；

推送服务组件，所述推送服务组件用以维护云端与本地客户端之间的长连接，以及将云端的数据变动实时推送到本地；

内核数据库组件，所述内核数据库组件用以记录云端文件和本地文件的基本元数据，以及对文件进行当前状态和历史版本的比较，计算出本地与云端文件的差异；

同步组件，所述同步组件用以根据本地与云端的文件的差异，自动将本地修改上传到云端，并且将云端的变动同步到本地。

更进一步，所述推送服务组件包括：

Rabbit MQ消息队列，所述Rabbit MQ消息队列中创建两个先进先出FIFO队列：Action Queue操作队列和Failed Action Queue操作失败队列，所述Action Queue用于保存用户需要推送的操作消息；所述Failed Action Queue用于保存在异步处理过程中推送失败的消息；

异步消息处理器，所述异步消息处理器用以从Action Queue中提取用户的操作消息，并且获取推送对象和消息主体；

HBase集群，所述HBase集群用以根据用户ID为索引值，存储需要推送给每个用户的消息，以及持久化推送消息；

Web集群，所述Web集群用以提供Web服务器接口；

RealTime集群，用以从所述HBase集群中取得需要推送的所有未推送的消息，并将其推送给用户。

更进一步，所述RealTime集群包括HAProxy和实时推送节点，

所述HAProxy用于均衡每个实时推送节点上的压力，进行负载均衡；

以及通过访问HAProxy，获取实时推送节点的URL；

再通过WebSocket协议创建与所述实时推送节点之间的长连接；

所述实时推送节点采用Netty作为通讯引擎。

更进一步，所述内核数据库组件包括：任务管理器，操作线程池，操作队列，

在所述操作队列中根据当操作队列非空时，所述任务管理器进行轮询操作队列，并按照FIFO的方式取出在所述操作队列中需要同步的任务，并调用所述操作线程池中的至少一个执行单元来执行任务；

当调取出来的任务是本地至云端的同步，则调用WEB API接口进行上传；

当调取出来的任务是云端至本地的同步，则调用本地操作系统接口进行数据下载。

上述任务分为两种：本地数据同步到云端，云端数据同步到本地。

更进一步，所述内核数据库组件还用以，

记录文件的基本元数据，包括：文件名、文件大小、文件在操作系统中的索引值、文件的父文件夹在操作系统中的索引值、文件本地状态、文件全路径、文件在本地内容的SHA1值、文件在云端的ID值、文件的父文件夹在云端的ID值、文件在云端内容的SHA1值、文件云端状态。

更进一步，所述内核数据库组件采用SQL Alchemy作为数据库管理ORM对象关系映射。

更进一步，所述同步组件还用以，

通过操作系统接口将云端文件的用户操作在本地重现，实现同步；

通过WEB API接口将用户对本地文件的操作在云端重现，实现同步。

更进一步，所述同步组件中，

采用线程池技术，用以将同一时间多个文件处于传输状态，其余文件均处于排队等待状态，其中保证同一时间有5个文件处于传输状态。

更进一步，所述同步组件中，

采用优先级队列处理技术，将所有操作分为文件夹队列和文件队列，其中所述文件夹队列优先于所述文件队列进行执行。

更进一步，所述本地文件监控组件用以适配，Windows、MAC、Linux不同操作系统。

本发明的有益效果：

1)本发明采用不同的适配器来处理不同的操作系统上的文件监控，使得整个系统可以运行在跨平台的环境中，提高了系统的可用性，方便了用户的使用；

2)本发明采用内核数据库来保存文件的状态，使文件的处理过程得以持久化，避免文件状态的丢失。因此，在同步过程中发生任何非可控异常(例如：断电)导致系统被迫中止，在系统重启系统之后都能重新进入正常的运行状态；再次，本发明创新性地采用RabbitMQ和异步处理器来实现消息推送和主逻辑处理的分离，即保证逻辑处理的及时性，防止主逻辑由于负责的推送计算而阻塞，又能保证消息推送的正确性和及时性；

3)本发明采用HBase来管理推送的具体信息和推送对象，解决了传统关系型数据库处理效率上的瓶颈，同时使得消息能够在云端持久化保存。用户离线不会影响推送结果，当用户再次登录的时候，云端未被推送的消息会即使推送给用户，从而避免推送消息的丢失所造成的错误。

4)本发明采用多线程技术实现同步，即保证同步效率又保证系统的稳定性。

综上，本发明能够实现，从本地到云端和从云端到本地的整个同步过程全自动执行，无需人工干预即可完成同步。

附图说明

图1为本发明的系统结构示意图；

图2为本发明的推送服务结构示意图；

图3为本发明的本地监控流程示意图；

图4为本发明的同步流程示意图。

具体实施方式

为了使本发明的目的、技术特征和实施效果更佳清楚，下面将结合参照图1、图2、图3和图4及具体实施例对本发明的技术方案进行详细的描述。

请参考图1为本发明的系统结构示意图。

在本实施例中基于文件监控和消息推送的实时同步系统，包括：本地监控组件101、推送服务组件102、内核数据库组件103以及同步组件104。

本地监控组件101：用于实时捕获用户在本地操作系统上所做的创建、移动、删除、重命名、修改等操作。目前主流的操作系统有Windows、MAC、Linux三种。为了在所有操作系统上得到一致性的监控效果，需要引入Windows适配器、MAC适配器、Linux适配器。适配器的作用在于兼容所有操作系统中不同的回调，并且对同步系统提供统一的接口。其中Windows适配器采用微软自带的文件夹监控函数ReadDirectoryChangesW来实现，当捕获用户操作之后，ReadDirectoryChangesW将返回操作数组，数组中每个元素都是由文件路径和操作类型组成的元组。MAC适配器和Linux适配器，由于是基于相同的内核，因此采用相同的第三方库fsevents来实现，当捕获用户操作之后，fsevents会扫描整个监控目录，查看文件结构的变化，最终返回用户的实际操作。

用户操作解析器搜集不同的操作系统适配器提供上来的监控结果，结合被操作的文件在本地系统中的当前状态以及内核数据库中存储的文件在被操作之前所处的状态。计算得到需要上传到云端的数据。例如：收到适配器提供的本地文件修改的消息，用户操作解析器需要计算本地文件当前的实际SHA1值，并且与数据库中存储的文件原本的SHA1值进行对比。如果SHA1值发生了变化，则需要上传文件的新版本；如果SHA1值没有变化，则表示不需要上传。需要上传的操作会被插入到本地操作队列。

推送服务组件102：维护云端与本地客户端之间的长连接，将云端的数据变动实时推送到本地。推送服务是由用户的云端操作所触发的，该操作可以是Android客户端、IOS客户端、Web页面以及同步系统本身所触发。客户端通过调用WEB服务器提供的接口，操作云端数据，实现云端文件的创建、修改、删除、移动、重命名等操作。这里的WEB服务器可以是一台单独的机器，也可以是一个服务集群，部署了处理云端数据的所有逻辑部件。

内核数据库组件103：用于记录文件的基本元数据，包括文件名、文件大小、文件在操作系统中的索引值、文件的父文件夹在操作系统中的索引值、文件本地状态、文件全路径、文件在本地内容的SHA1值、文件在云端的ID值、文件的父文件夹在云端的ID值、文件在云端内容的SHA1值、文件云端状态。其中文件本地状态和文件云端状态，分别有创建、删除、修改、移动、重命名等枚举值。所有元数据组成了两棵树形结构，一棵代表本地文件系统，另一棵代表云端文件系统。当本地或者云端数据发生变化的时候，内核数据库中存储的两棵树则是判断变化的重要依据。通过对比文件在当前操作系统中的状态和数据库中记录的本地元数据，可以计算本地文件的状态值；而通过对比文件在云端的状态和数据库中存储的云端元数据，则可以计算出云端文件的状态值。

同步组件104：用于同步本地和云端的数据。其中操作队列保存用户需要从云端同步到本地的数据以及需要从本地同步到云端的数据。任务管理器负责调度操作队列中的文件，通过执行单元来进行同步。操作线程池中维护了5个执行单元，每个执行单元为一个独立的线程，并且独立执行同步任务。当操作队列非空时，任务管理器会不停轮询操作队列，以FIFO的方式取出队列中需要同步的元素，并且在线程池中找到一个处于空闲状态的执行单元，让执行单元处理取出来的元素。如果操作队列为空，那么任务管理器将阻塞挂起，直到有新的操作进入。如果线程池中的所有线程都处于工作状态，那么任务管理器也会阻塞挂起，直到有线程处于空闲状态。采用操作队列和线程池的优点在于即能最大化利用系统资源，又能防止大量操作并发执行导致云端服务阻塞，影响系统的稳定性。

同步组件通过操作系统接口将云端文件的创建、删除、移动、重命名、修改等操作在本地重现；通过Web API将本地文件的创建、删除、移动、重名民、修改等操作在云端重现，从而达到同步的效果。

请参考图3为本发明的系统结构示意图。

在本实施例中，本地监控组件用于实时捕获用户在本地操作系统上所做的创建、移动、删除、重命名、修改等操作。如图3所示，为了适配不同的操作系统，监控组件中需要包含有针对目前主流操作系统的适配器，例如：Windows适配器301、MAC适配器302以及Linux适配器303。适配器向下可以控制不同操作系统的回调，而对外则提供统一的接口，方便系统处理。

以Windows系统为例，文件监控采用微软自带的ReadDirectoryChangesW函数栈来实现，用户的操作将会在适配器中得到回调。由于Windows系统监控本身回调是有缓存的，而这部分缓存由系统分配，当监控到大量的操作而且操作不能得到及时处理时，会造成监控遗漏。因此在监控得到由于用户操作所造成的本地文件系统发生变化之后，需要立刻将结果用同步器缓存304保存起来，防止丢失。

监控得到的数据中存在一些需要被忽略掉的文件可以归结为以下四类：

1.系统文件的创建、删除、修改。例如：desktop.ini；

2.隐藏文件。例如：.DS_Store；

3.临时文件。例如office文件操作产生的.tmp文件。

4.无法执行的操作。例如：创建一个文件，但当监控到此操作的时候，文件已经被删除；用户操作过滤器305负责将不需要处理的操作从监控结果中删除。

用户操作解析器306从队列中获取经过过滤，需要被同步到服务器端的操作。通过和数据库中的数据进行对比，确定该操作是否需要被同步到服务器。需要说明的是，并不是所有的用户操作都需要被同步到服务器，例如，用户修改了本地某个文件，又把文件改了回来，文件的最终状态sha1并没有发生变化，那么此文件是没有必要上传到服务器的。一旦解析器确定该操作需要被上传到服务器，首先会修改数据库，记录需要上传的状态，再将此操作插入本地操作队列中307。本地操作队列用于保存需要上传到云端的操作，定时器每隔2秒遍历一次数组，取出其中所有等待触发的操作，放入同步组件。使用定时器，能有效地避免同一个资源反复同步。例如，用户在很短的时间之内修改了文件多次，会触发多个需要上传文件的操作。如果对每个操作都进行同步，其实是冗余的。特别是Office文件的保存，会触发大量监控行为。最好的做法应该是等待2秒，如果2秒之内没有新的操作，则触发定时器；否则，如果两秒内有针对同一个文件或者文件夹的新的操作到达，则重置此文件或者文件夹的时间，再等2秒。采用定时器的另一个重要原因是Office文件的修改操作，当Office文件被修改的时候，并不是简单地收到一系列修改，还会监控到文件的创建，删除，重命名。这是因为Office的修改首先是创建了一个临时文件，然后将所有修改都记录在临时文件之中。当用户点击保存的时候，系统会删除原来的Office文件，将临时文件重命名为源文件。因此，只有完全受到整个处理流程之后才能出发操作。否则，会出现服务器上的文件被删除，又被重新创建，导致系统版本全部消失。

请参考图2为本发明的推送服务结构示意图。

如图2所示，推送服务组件：用以维护云端与本地客户端之间的长连接，将云端的数据变动实时推送到本地。由于Sync客户端需要同步本地与服务器之间的数据，则必须实时知道服务器上的变化，实时推送服务应运而生。其中包括：WEB集群201、Rabbit MQ消息队列202、异步处理器203、HBASE集群204、用户207、以及WebSocket集群208。

所述推送服务组件包括：

Rabbit MQ消息队列202，所述Rabbit MQ消息队列中创建两个先进先出FIFO队列：Action Queue操作队列和Failed Action Queue操作失败队列，所述Action Queue用于保存用户需要推送的操作消息；所述Failed Action Queue用于保存在异步处理过程中推送失败的消息；

异步消息处理器203，所述异步消息处理器用以从Action Queue中提取用户的操作消息，并且获取推送对象和消息主体；

HBase集群204，所述HBase集群用以根据用户ID为索引值，存储需要推送给每个用户的消息，以及持久化推送消息；

Web集群201，所述Web集群用以提供Web服务器接口；

RealTime集群208，用以从所述HBase集群中取得需要推送用户的所有未推送的消息，并将其推送给用户。

推送服务是由用户的云端操作所触发的，该操作可以是Android客户端、IOS客户端、Web页面以及同步系统本身所触发。客户端通过调用WEB服务器提供的接口，操作云端数据，实现云端文件的创建、修改、删除、移动、重命名等操作。当服务器端发生数据变化时，由WEB集群决定这部分数据是否需要推送，以及需要推送给哪些用户。对于云存储服务，任何云端文件的变动都需要推送给大量关联用户，推送内容和推送对象的计算具有三个特点：第一，耗时长。特别是协作了大量用户或者文件夹层次结构复杂的时候，大量的计算需要消耗服务器系统资源，严重影响原有服务请求的响应时间。第二，时效性短。对于WEB服务器来说，是一个无状态的服务结构，一旦消息被推送之后，将不再由web负责后续操作。第三，严格的时序性。用户的操作序列是有一定的时序性，任何两个操作的执行顺序的变动都可能影响最后的同步结果。采用Rabbit MQ作为消息缓存队列，可以有效地缓减服务器压力，提高推送效率。处理请求的可以是独立的Web服务器，使用独立的硬件和内网通讯，效率提升更加明显。因此，需要Rabbit MQ中创建两个FIFO(先进先出)队列，Action Queue和FailedAction Queue，分别用于保存用户需要推送的操作消息以及在异步处理过程中推送失败的消息。当WEB集群需要推送消息时，首先将操作消息发送到Rabbit MQ的Action Queue队列。操作消息仅包含用户所做的操作的基本数据，并不涉及复杂的推送逻辑。

推送服务组件一方面需要将云端的数据变动推送给对应的用户，另一方不能阻塞当前用户的操作，因此，需要做异步处理。Rabbit MQ具有稳定性强、扩展性高、便于管理等优点，因此，异步处理采用Rabbit MQ来管理用户操作。创建两个FIFO(先进先出)队列，Action Queue和Failed Action Queue，分别用于保存用户需要推送的操作消息以及在异步处理过程中推送失败的消息。当WEB集群需要推送消息时，首先将操作消息发送到RabbitMQ的Action Queue队列。操作消息仅包含用户所做的操作的基本数据，并不涉及复杂的推送逻辑。

消息异步处理器监听Rabbit MQ队列，如果发现有新消息需要推送，则从消息队列中取出消息的元数据，访问WEB集群来获取需要发送的实际消息主体，即需要推送的消息的具体信息，包含文件在云端的ID、父文件夹的ID、操作类型、操作序列号、文件大小、文件名、文件路径等等。如果WEB集群针对异步消息处理器没有给出正确的回复，则重新将操作放到Rabbit MQ的Failed Action Queue队里中。

异步消息处理器负责从Rabbit MQ的Action Queue队列中取出用户的操作消息。并且调用WEB的接口来获取推送对象和消息主体。其中推送对象是指用户的操作需要通知的其他用户的集合；消息主体表示需要推送的消息的具体信息，包含文件在云端的ID、父文件夹的ID、操作类型、操作序列号、文件大小、文件名、文件路径等等。操作计算推送对象和消息主体是耗时操作，异步消息处理器将这部分耗时操作独立出来进行异步计算，保证用户的当前操作能够迅速执行，而不会被复杂的计算所阻塞。最终将获得的推送消息主体和推送对象将保存在HBase数据库中。

由于推送消息随着时间的推移会变得越来越大，百万级别的消息将超出MySQL、SQLite等关系型数据库的承载能力。因此，在推送过程中，不能采用传统的关系型数据库作为推送消息的存储介质。取而代之的是HBase。异步消息处理器将获得的推送内容以用户ID为索引，插入到HBASE集群中。经过HBase数据持久化，用户的推送消息将不会丢失。处于离线状态的用户，在重新登录系统之后，推送服务可以根据用户离线时所处的状态，自动推送后续的所有消息。

在本实施例中，HBase数据库的作用在于持久化推送消息，使得处于离线状态的被推送的用户，当重新上线的时候，依然能收到推送消息。由于推送消息随着时间的推移会变得越来越大，百万级别的消息将超出MySQL、SQLite等关系型数据库的承载能力。因此，在推送过程中，不能采用，传统的关系型数据库作为推送消息的存储介质。取而代之的是HBase，考虑到HBase高效的性能以及主键的检索能力，采用HBase作为消息推送的持久化数据库，推送消息以用户ID为索引值，存储需要推送给用户的所有消息。对于单个用户来说，其在HBase中存储的是一个消息队列，队列中包含了从这个用户产生以来所有需要推送给他的消息。每个消息有一个严格递增的Action ID，可以用户检索从某个Action ID开始的所有消息。

RealTime服务器集群是由两部分组成，HAProxy205和实时推送节点206。HAProxy的作用是负载均衡，客户端启动之后首先访问HAProxy请求实时推送节点的URL，然后通过WebSocket协议创建一个与实时推送节点之间的长连接。实时推送节点节点每隔一段时间会从HBase中批量查询当前登录在该server上的用户是否有新消息，如果有则将其推送到客户端进行处理。

在本实施例中，RealTime集群由HAProxy和实时推送节点两部分组成。负责从HBase中取得特定用户ID的所有未推送的消息，并将其推送给用户。其中HAProxy作为负载均衡，用于均衡每个实时推送节点上的压力。当用户发起连接请求之前，首先访问HAProxy节点，请求一个实时推送节点作为通讯节点。HAProxy会根据当前每个实时推送节点上的压力，返回一个当前压力最小的实时推送节点的URL。用户根据返回的URL，连接到对应的实时推送节点上。客户端与实时推送节点之间采用WebSocket协议进行通讯，维持长连接。实时推送节点会定期向所有连接的客户端发送心跳包，客户端收到心跳包之后返回相应的ACK。如果连续两次没有收到来自服务器端的心跳包，客户端将认为连接已经失效，将主动断开当前连接，并且重新尝试创建新连接；如果连续两次没有收到来自客户端的ACK返回，服务器端将认为连接已经失效，主动断开连接，并且释放连接占用的资源。

用户连接到实时推送节点之后，将向节点声明自己的用户ID，token以及当前客户端已经处理的最大推送的Action ID。实时推送节点根据收到的消息，首先校验token是否合法，如果不合法，则主动断开连接。如果token合法，则查询数据库中对应的用户ID以及Action ID之后的所有需要推送的消息，推送给用户。推送之后，连接将长期保持，一旦有新的消息需要推送，实时推送节点都会将消息从HBase中取出，发送给用户。

在本实施例中，系统为了同步本地文件结构和服务器端的文件结构，不可能实时对本地文件夹和服务器进行扫描来获取文件状态，因此，引入内核数据库组件，用于记录文件的基本元数据，数据库中的每一条记录都唯一标识一个文件夹或者文件。由三部分构成：基本属性、本地属性和服务器属性。其中基本属性包含有资源的基本状态，包括sync标记、资源类型(文件还是文件夹)、冲突标记、冲突原因、同步时间等。本地属性包括资源路径、资源移动目标路径、上传和下载的临时路径、本地ID、本地父亲节点ID、本地状态(创建、删除、移动、修改等)、本地sha1。服务器属性包括资源名、资源移动目标名、修改者用户名、修改者ID、服务器ID、服务器父亲节点ID、移动目标父亲节点ID、服务器sequence ID、服务器状态(创建、删除、移动、修改等)、服务器sha1。可以看到，本地属性和服务器属性都包含了本节点的ID以及其父节点的ID，实际上维护了两个文件系统的树形结构，分别表示本地文件系统的树形结构和服务器端文件系统的树形结构。当本地的操作被监控到之后，可以将资源当前状态和本地的树形结构进行对比，获取文件实际需要上传的数据。例如，文件被修改之后，可以通过对比文件当前的sha1和数据库中原有的sha1来得知文件内容是否有变化，如果有变化，则上传，否则并不需要上传。这里需要说明的是，用户每次点击保存按钮的时候，文件监控都会监控到保存操作的发生，但是有保存操作并不代表文件内容发生了变化，也不一定需要出发同步操作。与本地文件系统相对应，当接收到来自服务器的实时推送请求的时候，可以将服务器资源的当前状态和服务器的树形结构进行对比，获取资源实际同步内容。同步系统的核心功能，实际上就是要合并服务器端和客户端的两棵树，当其中任何一棵树的结构发生变化，Sync需要将变化的节点在另一棵树上做比对。如果有所不同，则让另一个树也发生相同的变化。同步完成的状态，就是两棵树完全一致的时候。

请参考图4为本发明的同步流程示意图。

如图4所示，同步组件由任务管理器401、操作线程池402以及操作队列403三部分组成。操作队列403中的任务分为两种：本地数据同步到云端，云端数据同步到本地。当操作队列非空时，任务管理器会不停轮询操作队列，以FIFO的方式取出队列中需要同步的任务，并调用操作线程池中的执行单元来执行任务。执行单元的数量是可以调整的，每一个执行单元代表执行线程池中的一个线程，线程数量不宜太大，否则会对服务器造成一定压力；也不宜太小，使得同步效率太低，默认为5。当取出来的任务是本地至云端的同步，则调用WEBAPI接口实现上传。而当取出来的任务是云端至本地的同步，则调用操作系统接口实现数据下载。

执行单元如何执行任务，是由操作对象的本地状态和云端状态共同决定的，这些状态保存在内核数据库中，在需要执行的时候取出。举个例子，当本地状态为修改，而云端为同步完成，则表示用户只对本地文件做了修改，需要上传到服务器。而当本地状态为修改，而云端状态也为修改，则表示本地文件和服务器文件都做了修改，这是一种冲突，无论是把本地文件上传到服务器来覆盖服务器端文件，或者是下载服务器端文件到本地来覆盖本地文件，都不是合理的解决方案，都会造成用户数据的丢失。那么需要将本地的文件以用户名来重命名，以新文件的方式上传到服务器，同时将服务器的文件下载到本地，让两个修改同时并存。

以上对本发明所提供的一种基于文件监控和消息推送的实时同步系统，进行了详细的介绍，并且应用了具体实施案例对本发明的原理和实施方式进行了阐述，以上实施案例的说明只是用于帮助理解本发明的方法与核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims

1.一种基于文件监控和消息推送的实时同步系统，其特征在于，包括，本地文件监控组件，所述本地文件监控组件适配不同的操作系统，用于实时捕获用户在本地操作系统中的用户操作；推送服务组件，所述推送服务组件用以维护云端与本地客户端之间的长连接，以及将云端的数据变动实时推送到本地；内核数据库组件，所述内核数据库组件用以记录云端文件和本地文件的基本元数据，以及对文件进行当前状态和历史版本的比较，计算出本地与云端文件的差异；同步组件，所述同步组件用以根据本地与云端的文件的差异，自动将本地修改上传到云端，并且将云端的变动同步到本地；

所述推送服务组件包括：RabbitMQ消息队列，用于创建两个先进先出FIFO队列；

ActionQueue操作队列和FailedActionQueue操作失败队列，所述ActionQueue用于保存用户需要推送的操作消息；所述FailedActionQueue用于保存在异步处理过程中推送失败的消息；

异步消息处理器，用于从ActionQueue中提取用户的操作消息，并且获取推送对象和消息主体；

HBase集群，用于根据用户ID为索引值，存储需要推送给每个用户的消息，以及持久化推送消息；

Web集群，所述Web集群用以提供Web服务器接口；

RealTime集群，用以从所述HBase集群中取得需要推送的所有未推送的消息，并将其推送给用户，

所述 RealTime集群包括HAProxy和实时推送节点，所述HAProxy用于均衡每个实时推送节点上的压力，进行负载均衡；以及通过访问HAProxy，获取实时推送节点的URL；再通过WebSocket协议创建与所述实时推送节点之间的长连接；所述实时推送节点采用Netty作为通讯引擎；

本地文件监控组件还用于监控得到的数据中存在需要被忽略掉的以下四类文件：

系统文件的创建、删除、修改；

隐藏文件；

临时文件；

无法执行的操作。

2.根据权利要求1所述的基于文件监控和消息推送的实时同步系统，其特征在于，所述内核数据库组件还用以，记录文件的基本元数据，包括：文件名、文件大小、文件在操作系统中的索引值、文件的父文件夹在操作系统中的索引值、文件本地状态、文件全路径、文件在本地内容的SHA1值、文件在云端的ID 值、文件的父文件夹在云端的ID值、文件在云端内容的SHA1值、文件云端状态。

3.根据权利要求1所述的基于文件监控和消息推送的实时同步系统，其特征在于，所述内核数据库组件采用SQLAlchemy作为数据库管理ORM对象关系映射。

4.根据权利要求1所述的基于文件监控和消息推送的实时同步系统，其特征在于，所述同步组件还用以，通过操作系统接口将云端文件的用户操作在本地重现，实现同步；通过WEBAPI接口将用户对本地文件的操作在云端重现，实现同步。

5.根据权利要求4所述的基于文件监控和消息推送的实时同步系统，其特征在于，所述同步组件中，采用线程池技术，用以将同一时间多个文件处于传输状态，其余文件均处于排队等待状态，其中保证同一时间有5个文件处于传输状态。

6.根据权利要求4所述的基于文件监控和消息推送的实时同步系统，其特征在于，所述同步组件中，采用优先级队列处理技术，将所有操作分为文件夹队列和文件队列，其中所述文件夹队列优先于所述文件队列进行执行。

7.根据权利要求1所述的基于文件监控和消息推送的实时同步系统，其特征在于，所述本地文件监控组件用以适配，Windows、MAC、Linux不同操作系统。