CN101997896B - 一种文件发布的方法及系统 - Google Patents
一种文件发布的方法及系统 Download PDFInfo
- Publication number
- CN101997896B CN101997896B CN 200910164897 CN200910164897A CN101997896B CN 101997896 B CN101997896 B CN 101997896B CN 200910164897 CN200910164897 CN 200910164897 CN 200910164897 A CN200910164897 A CN 200910164897A CN 101997896 B CN101997896 B CN 101997896B
- Authority
- CN
- China
- Prior art keywords
- web server
- file
- server
- transaction file
- encryption
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种文件发布的方法,包括:管理服务器通知所选择的网页Web服务器从发布服务器获取更新文件,所选择的Web服务器从发布服务器获取更新文件,完成更新;管理服务器选择待更新的Web服务器,通知所选择的待更新的Web服务器从已更新的Web服务器获取更新文件,待更新的Web服务器从已更新的Web服务器获取更新文件,完成更新。本发明在不增加硬件、不改动现有硬件环境的前提下,提高了文件发布的效率和硬件的利用率。
Description
技术领域
本发明涉及Web(网页)服务器系统,尤其涉及一种向Web服务器发布文件的文件发布的方法及系统。
背景技术
随着因特网的高速发展,在传统的大型门户网站和新兴的IPTV(Interactive Personality Television,个性化互动电视)等业务环境中,直接为用户提供服务的Web系统越来越多地使用了多Web服务器系统。多个Web服务器能够提高整个系统的并行处理能力,在单位时间内能够响应更多的用户请求。但是,随之而来的问题是在新的文件上线时,很难保证新的文件尽快发布到所有的Web服务器上。
由于Web服务器直接连接在公共网络上,运营商从安全角度考虑,在公共网络上通常只开放Web服务器上的HTTP协议(Hypertext TransferProtocol,超文本传输协议)的端口和HTTPS协议(Hypertext Transfer Protocolover Secure Socket Layer,安全超文本传输协议)的端口。为了进行管理和文件发布,只会在内部网络上允许Web服务器以特定端口访问特定的服务器以获取管理指令和更新文件。因此,在Web服务器之间只能通过公网的HTTP或HTTPS协议互相访问,向Web服务器发布文件时,无法利用现有的CDN(Content Distribute Network,内容分发网络)和P2P(Point to Point,点对点)等文件发布技术,需要采用FTP(File Transfer Protocol,文件传输协议)端口技术或不受端口限制的传输技术。
如图1所示,现有的Web服务器文件发布技术是在Web服务器系统外配置一台管理服务器和一台保存上传文件以及提供下载文件功能的服务器(称为发布服务器),向Web服务器发布文件的过程为:
第一步:将要发布到Web服务器的文件,传输给发布服务器;
可以采用以下方式向发布服务器传输要发布的文件:
1、管理服务器将文件直接下发给发布服务器(图1中①)。
2、由其它系统将文件发送给发布服务器(图1中②),再通知管理服务器文件已下发到发布服务器(图1中③)。
第二步:管理服务器制定文件发布计划,根据计划向每台Web服务器的后台服务程序发送文件更新指令(图1中④),要求Web服务器从发布服务器获取更新的文件;
第三步:Web服务器在收到管理服务器的文件更新指令后,从发布服务器获取更新的文件(图1中⑤),并向管理服务器上报结果。
在Web服务器数量较少的情况下,上述方式尚且能够正常工作,但是,当Web服务器的数量增加到一定程度后,在发布文件时,短时间内大量并发请求会使发布服务器超负荷运行甚至阻塞,导致Web服务器获取文件失败,甚至导致发布服务器宕机。为了避免瞬时海量并发操作引起的问题,在现有技术中也提出了一些优化方案。
一种优化方案是将文件发布由并行改为串行,不是所有Web服务器同时进行更新,而是让Web服务器排队,逐个或逐批更新,第一个或第一批更新完成后,下一个或下一批Web服务器再进行更新。这种方式在发布任务比较少并且Web服务器也比较少的情况下比较可行,但由于是串行执行,存在以下弊端:
1、由于排队和超时等待等因素,串行执行的总时间比并行长了很多,如果发布任务很频繁或者Web服务器很多,容易导致一个发布任务还没执行完,后续发布任务又到来,发布服务器将始终处于忙碌状态,并且任务无法准时完成,随着任务的积累问题将更加越严重。
2、虽然发布服务器一直处于忙碌状态,但是,大部分Web服务器却因为在排队等待而闲置,白白浪费了系统资源。
另一种优化方案是增加发布服务器数量,让Web服务器随机选择发布服务器,或者采用其它方式选择发布服务器。但是,这种方式也存在较多问题,如:
1、由于文件来源很多,很难保证上传到发布服务器上的文件的一致性,进而难以保证Web服务器上文件的一致性。这个问题很难发觉并且很难修复。
2、需要保证任何发布服务器均不能宕机或者出现网络故障,否则不但会出现第一个问题,而且依靠故障发布服务器提供服务的Web服务器改为向其它发布服务器请求服务后,可能导致其它发布服务器相继超负荷引起整个系统宕机。在发布服务器很多的情况下,保证所有的机器在任何时候都正常运行是非常困难的。
3、最重要的是,并没有从根本上解决并发服务能力低的问题,有限的发布服务器很难跟上Web服务器的快速增长。如果随着Web服务器的增长不断添置造价昂贵的发布服务器(发布服务器往往需要性能很高的服务器以及网络带宽,甚至磁盘阵列),会产生高昂的成本,降低产品的市场竞争力。
发明内容
本发明要解决的技术问题是提供一种文件发布的方法及系统,解决在采用较多Web服务器时,向Web服务器发布文件效率低、扩展性差的问题,实现提高文件发布的效率。
为解决上述技术问题,本发明的一种文件发布的方法,包括:
管理服务器通知所选择的网页Web服务器从发布服务器获取更新文件,所选择的Web服务器从发布服务器获取更新文件,完成更新;
管理服务器选择待更新的Web服务器,通知所选择的待更新的Web服务器从已更新的Web服务器获取更新文件,待更新的Web服务器从已更新的Web服务器获取更新文件,完成更新。
进一步地,更新文件为:普通文件或特殊文件;
当更新文件为特殊文件时,管理服务器通知待更新的Web服务器从已更新的Web服务器获取更新文件前,还通知已更新的Web服务器对更新文件进行点对点加密;
已更新的Web服务器选择点对点加密的方式,并将所选择的点对点加密的方式及加密参数通过管理服务器通知待更新的Web服务器;
管理服务器通知待更新的Web服务器从已更新的Web服务器获取更新文件;待更新的Web服务器根据点对点加密的方式及加密参数从已更新的Web服务器获取更新文件。
进一步地,点对点加密的方式包括:采用HTPPS协议传输更新文件;
采用HTTPS协议传输更新文件时,待更新的Web服务器根据点对点加密的方式及加密参数从已更新的Web服务器获取更新文件的过程包括:
待更新的Web服务器使用加密参数解密HTPPS传输信道,从已更新的Web服务器获取更新文件。
进一步地,点对点加密的方式包括:对更新文件进行加密,使用超文本传输协议HTTP传输加密后的更新文件;
采用对更新文件进行加密,使用HTTP传输加密后的更新文件时,待更新的Web服务器根据点对点加密的方式及加密参数从已更新的Web服务器获取更新文件的过程包括:
待更新的Web服务器从已更新的Web服务器获取加密后的更新文件,使用加密参数对加密后的更新文件进行解密。
进一步地,更新文件为:普通文件或特殊文件;
当更新文件为特殊文件时,管理服务器在选择Web服务器从发布服务器获取更新文件前,选择加密算法并生成加密密钥和解密密钥,将加密算法、加密密钥以及更新文件的文件名通知发布服务器;
发布服务器根据更新文件的文件名,按照加密算法使用加密密钥分别对更新文件的文件体和文件名加密,并使用加密后的文件名命名加密后的文件体,将加密后的文件名发送给管理服务器;
管理服务器根据加密后的文件名,执行通知所选择的Web服务器从发布服务器获取更新文件的操作,完成对Web服务器的更新后,将加密算法、解密密钥和加密后的文件名通知完成更新的Web服务器;
完成更新的Web服务器根据加密算法,采用解密密钥分别对加密后的文件名和文件体进行解密。
进一步地,管理服务器根据Web服务器选择策略选择待更新的Web服务器,Web服务器选择策略包括但不限于:
根据硬件性能对Web服务器进行排序,按照硬件性能由好到差的顺序选择Web服务器;
根据负荷对Web服务器进行排序,按照负荷由低到高的顺序选择Web服务器;
每轮发布时,根据机器性能和当前负荷参数计算出当前服务能力,按当前服务能力由高到低的顺序选择Web服务器;
预先配置更新队列,按照由前到后的顺序选择Web服务器。
进一步地,一种文件发布系统,包括:管理服务器、发布服务器和Web服务器,其中:
管理服务器,用于通知所选择的Web服务器从发布服务器获取更新文件,所选择的Web服务器从发布服务器获取更新文件,完成更新后,管理服务器还选择待更新的Web服务器,通知所选择的待更新的Web服务器从已更新的Web服务器获取更新文件;
待更新的Web服务器,用于从已更新的Web服务器获取更新文件,完成更新。
进一步地,更新文件为:普通文件或特殊文件;
管理服务器,还用于当更新文件为特殊文件时,在通知待更新的Web服务器从已更新的Web服务器获取更新文件前,通知已更新的Web服务器对更新文件进行点对点加密;
已更新的Web服务器,用于选择点对点加密的方式,并将所选择的点对点加密的方式及加密参数通过管理服务器通知待更新的Web服务器;
待更新的Web服务器根据点对点加密的方式及加密参数从已更新的Web服务器获取更新文件。
进一步地,更新文件为:普通文件或特殊文件;
管理服务器,还用于当更新文件为特殊文件时,在选择Web服务器从发布服务器获取更新文件前,选择加密算法并生成加密密钥和解密密钥,将加密算法、加密密钥以及更新文件的文件名通知发布服务器;并且,根据接收到的加密后的文件名,执行通知所选择的Web服务器从发布服务器获取更新文件的操作,完成对Web服务器的更新后,将加密算法、解密密钥和加密后的文件名通知完成更新的Web服务器;
发布服务器,用于根据更新文件的文件名,按照加密算法使用加密密钥分别对更新文件的文件体和文件名加密,并使用加密后的文件名命名加密后的文件体,将加密后的文件名发送给管理服务器;
完成更新的Web服务器,用于根据加密算法,采用解密密钥分别对加密后的文件名和文件体进行解密。
进一步地,管理服务器根据Web服务器选择策略选择待更新的Web服务器,Web服务器选择策略包括但不限于:
根据硬件性能对Web服务器进行排序,按照硬件性能由好到差的顺序选择Web服务器;
根据负荷对Web服务器进行排序,按照负荷由低到高的顺序选择Web服务器;
每轮发布时,根据机器性能和当前负荷参数计算出当前服务能力,按当前服务能力由高到低的顺序选择Web服务器;
预先配置更新队列,按照由前到后的顺序选择Web服务器。
综上所述,本发明在不增加硬件、不改动现有硬件环境的前提下,提高了文件发布的效率和硬件的利用率。
附图说明
图1为现有技术中向Web服务器发布文件的架构图;
图2为本发明的向Web服务器发布文件的1轮的架构图;
图3为本发明的向Web服务器发布文件的2轮的架构图;
图4为本发明的向Web服务器发布文件的3轮的架构图;
图5为本发明采用点对点加密的方式发布特殊文件的架构图;
图6为本发明采用全局加密方式发布特殊文件的架构图。
具体实施方式
本发明中向Web服务器发布文件时,管理服务器根据策略通知一部分待更新的Web服务器从发布服务器进行更新。完成更新后,已完成更新的Web服务器可以作为其它未更新的Web服务器的发布服务器,管理服务器可选择通知待更新的Web服务器,从已更新的Web服务器获取更新文件,或从发布服务器获取更新文件,进而完成全部Web服务器的更新。
管理服务器在选择待更新的Web服务器时,可以有多种选择策略,例如:
1、根据硬件性能对Web服务器进行排序,将硬件性能好的优先更新。
2、根据负荷对Web服务器进行排序,对负荷低的优先更新。
3、每轮发布时,根据机器性能和当前负荷等参数,计算出当前服务能力,按当前服务能力由高到低的顺序选择Web服务器。
4、预先配置更新队列,按照先后顺序进行更新。
下面结合附图对本发明的具体实施方式进行说明。
在Web服务器上存在两类文件,一类允许外部直接访问,如图片和静态HTML页面等,以下称为普通文件;另一类不允许外部直接访问,如动态网页的源代码和库文件等,以下称为特殊文件。特殊文件的传输面临两个问题:一是Web服务器之间无法相互读取这些文件,例如,JSP和PHP等动态网页的源文件;二是特殊文件属于不能向外部泄露的文件,如,包含口令信息的配置文件。普通文件和特殊文件的的发布流程在整体上是相同的,但是,对特殊文件需要一些特殊处理,下面予以描述。
如图2所示,下面以在系统中存在7台Web服务器为例,为方便描述,以下将管理服务器记为M,发布服务器记为S,Web服务器分别标记为ABCDEFG。S采用FTP方式提供文件发布功能。为简化描述,采用预先配置更新队列的策略选择待更新的Web服务器,更新顺序为ABCDEFG。
普通文件的发布流程包括:
步骤1.1:M根据Web服务器选择策略选择A作为第一轮文件发布的待更新Web服务器;
步骤1.2:M向A发送文件更新指令(图2中①);
步骤1.3:A接收到M的文件更新指令后,从S获取更新文件(图2中②);
步骤1.4:A向M报告文件获取成功(图2中③);
此时,A已经完成更新,第一轮发布完成。
下面进入第二轮发布,如图3所示,在已经完成发布的Web服务器A上加圈以示区别)。
步骤2.1:M根据Web服务器选择策略选取Web服务器B和C作为第二轮文件发布的待更新Web服务器;
由于A已经完成更新,在第二轮文件发布中将A作为“发布服务器”,这样就存在S与A两个可以发布文件的服务器。
步骤2.2:M分别向B和C发送文件更新指令,通知B以HTTP方式从A获取更新文件,通知C以FTP方式从S获取更新文件(图3中①);
步骤2.3:B以HTTP方式从A获取更新文件(图3中②),C以FTP方式从S获取更新文件(图3中③);
步骤2.4:B和C分别向M报告文件获取成功(图3中④和图3中⑤);
此时,ABC三台Web服务器均已完成文件更新,下面进入第三轮文件发布,如图4所示,在已经完成发布的Web服务器ABC上加圈以示区别。
步骤3.1:M根据Web服务器选择策略选取DEFG作为第三轮文件发布的待更新Web服务器;
由于ABC都已完成更新,加上S共有四台可提供文件发布的服务器,因此,可以为DEFG四个待更新Web服务器分别匹配一个“发布服务器”,根据“发布服务器”是Web服务器还是真实的发布服务器分别指定是采用HTTP方式还是采用FTP方式获取文件。
步骤3.2:M分别向DEFG发送文件更新指令(图4中①),通知D以HTTP方式从C获取更新文件,通知E以HTTP方式从B获取更新文件,通知F以HTTP方式从A获取更新文件,通知G以FTP方式从S获取更新文件;
步骤3.3:DEFG分别从各自指定的服务器获取更新文件(图4中②);
步骤3.4:DEFG分别向M报告文件获取成功。(限于图形复杂,图4图不再绘制报告的连线)。
此时,文件发布任务完成。
下面对特殊文件的发布流程进行说明。
由于发布服务器在内网采用FTP向Web服务器发布文件,可以直接传输任何文件而不用担心外泄。而将Web服务器作为“发布服务器”时,则存在Web服务器之间无法读取特殊文件,以及Web服务器之间在公网上明文传输文件带来的泄密问题。这样就需要采取一些额外措施来发布特殊文件。
解决特殊文件的发布可以采用点对点加密的方式,即:在两台Web服务器之间进行文件发布时,两台服务器采用可以保护文件内容的加密的方式进行文件发布,而不是直接传输文件。加密的方式包括但是不限于:HTTPS传输协议、文件加密等。为简化叙述,下面仅以HTTPS传输协议、文件加密两种方式进行说明。
下面仍以上述在系统中存在7台Web服务器为例,其中,第一轮文件发布与上述步骤1.1~1.4相同,在第二轮发布中,当M需要指定待更新的Web服务器从已更新的Web服务器获取更新文件时,需要按照以下流程处理,包括:
步骤1:M将B需要从A获取更新文件的信息通知A(图5中①),并通知A对更新文件进行点对点加密;
步骤2:A根据M的通知,选定一种点对点加密方式;
例如,A可选择采用HTTPS协议传输数据,或者是对更新文件加密后,采用HTTP传输文件。如果是采用对更新文件加密,则A需要将更新文件加密。此步骤在一个发布任务中可以仅做一次,A以后为其它Web服务器提供文件加密方式的发布服务时,可以重用这个已加密的文件。
步骤3:A将点对点加密方式及加密参数(加密算法和解密密钥等)上报给M(图5中②);
步骤4:M将点对点加密方式及加密参数通知B,通知B从A上获取更新文件(图5中③);
步骤5:B根据点对点加密的方式及加密参数获取更新文件(图5中④);
采用HTTPS协议传输更新文件时,待更新的Web服务器使用加密参数解密HTPPS传输信道,从已更新的Web服务器获取更新文件。采用对更新文件进行加密,使用HTTP传输加密后的更新文件时,待更新的Web服务器从已更新的Web服务器获取加密后的更新文件,使用加密参数对加密后的更新文件进行解密。
步骤6:B向M报告文件获取成功(图5中⑤)。
此时Web服务器之间的特殊文件的发布完成一轮,以后每一轮的发布都采用相同的方式处理,在此不再赘述。当所有Web服务器都更新完成后,M通知所有发布过特殊文件的Web服务器将本地加密后的特殊文件删除。
此方案的优点在于各Web服务器可以根据自身情况决定自己在发布文件时采用何种方式,不需要所有的Web服务器都具有统一的软、硬件环境。同时,加密方式还可以组合起来使用,例如同时应用HTTPS和文件加密,以进一步提高安全性。
对特殊文件的发布也可以采用对全局文件加密,此方案需要发布服务器至少具有文件加密功能,所有的Web服务器至少具有文件解密功能,具体过程包括:
步骤a:在发布文件前,M选择加密算法并生成密钥;
密钥包含加密密钥和解密密钥,密钥的具体形式取决于所用的加密算法,如果是对称加密算法则两者相同,密钥强度要求在可接受的时间内加密后的文件不能被破解即可。
步骤b:M将加密算法、加密密钥和更新文件的文件名发送给S(图6中①);
步骤c:S按照加密算法,使用加密密钥对更新文件的文件体和文件名分别加密,并使用加密后的文件名对加密后的文件体命名,将加密后的文件名发送给M(图6中②);
步骤d:M按照上述步骤1.1~3.4的过程发布加密后的更新文件(图6中未绘制该流程);
步骤e:完成向Web服务器发布加密后的更新文件后,M将加密算法、解密密钥和加密后的文件名等解密所需的信息发送给完成更新的Web服务器(图6中③);
步骤f:完成更新的Web服务器根据加密算法,采用解密密钥分别对加密后的文件名和文件体进行解密。
此方案不需要Web服务器提供HTTPS服务,系统只需进行一次文件加密,节省了软件资源。同时,此方案与点对点加密的方案并不冲突,可以联合使用,进一步提高Web服务器之间进行文件发布时的安全性。
本发明还提供了一种文件发布的系统,包括:管理服务器、发布服务器和Web服务器,其中,
管理服务器,用于根据Web服务器选择策略选择待更新Web服务器,向待更新Web服务器发送文件更新指令,将待更新的Web服务器需要从已更新的Web服务器获取更新文件的信息通知已更新的Web服务器,并通知已更新的Web服务器对更新文件进行点对点加密;将接收到的点对点加密方式及加密参数通知待更新的Web服务器,通知待更新的Web服务器从已更新的Web服务器上获取更新文件;在发布文件前,选择加密算法并生成密钥,将加密算法、加密密钥和更新文件的文件名发送给发布服务器,将加密算法、解密密钥和加密后的文件名等解密所需的信息发送给完成更新的Web服务器,完成更新的Web服务器根据加密算法,采用解密密钥分别对加密后的文件名和文件体进行解密。
待更新的Web服务器,用于根据管理服务器的指令,从发布服务器或已更新的Web服务器获取更新文件,并向管理服务器上报获取结果,当更新文件为特殊文件时,根据接收到的点对点加密的方式及加密参数获取更新文件。
已更新的Web服务器服务器,用于根据管理服务器的通知,选定一种点对点加密方式,将点对点加密方式及加密参数(加密算法和解密密钥等)上报给管理服务器。
发布服务器,用于储存需要发布的文件并响应Web服务器的请求,为其提供文件(原始文件或加密后的文件);按照加密算法,使用加密密钥对更新文件的文件体和文件名分别加密,并使用加密后的文件名对加密后的文件体命名,将加密后的文件名发送给管理服务器。
应当理解的是,对本发明技术所在领域的普通技术人员来说,可以根据本发明的技术方案及其构思进行相应的等同改变或替换,而所有这些改变或替换,都应属于本发明所附权利要求的保护范围。
Claims (8)
1.一种文件发布的方法,包括:
管理服务器通知所选择的网页Web服务器从发布服务器获取更新文件,所选择的Web服务器从所述发布服务器获取更新文件,完成更新;
所述管理服务器根据Web服务器选择策略选择待更新的Web服务器,通知所选择的待更新的Web服务器从已更新的Web服务器获取更新文件,所述待更新的Web服务器从所述已更新的Web服务器获取更新文件,完成更新;所述Web服务器选择策略包括但不限于:
根据硬件性能对Web服务器进行排序,按照硬件性能由好到差的顺序选择Web服务器;
根据负荷对Web服务器进行排序,按照负荷由低到高的顺序选择Web服务器;
每轮发布时,根据机器性能和当前负荷参数计算出当前服务能力,按当前服务能力由高到低的顺序选择Web服务器;
预先配置更新队列,按照由前到后的顺序选择Web服务器。
2.如权利要求1所述的方法,其特征在于,
所述更新文件为:普通文件或特殊文件;
当所述更新文件为特殊文件时,所述管理服务器通知所述待更新的Web服务器从已更新的Web服务器获取更新文件前,还通知所述已更新的Web服务器对更新文件进行点对点加密;
所述已更新的Web服务器选择点对点加密的方式,并将所选择的点对点加密的方式及加密参数通过管理服务器通知所述待更新的Web服务器;
所述管理服务器通知待更新的Web服务器从已更新的Web服务器获取更新文件;所述待更新的Web服务器根据点对点加密的方式及加密参数从所述已更新的Web服务器获取更新文件。
3.如权利要求2所述的方法,其特征在于,
所述点对点加密的方式包括:采用HTPPS协议传输更新文件;
采用HTTPS协议传输更新文件时,待更新的Web服务器根据点对点加密的方式及加密参数从所述已更新的Web服务器获取更新文件的过程包括:
所述待更新的Web服务器使用加密参数解密HTPPS传输信道,从已更新的Web服务器获取更新文件。
4.如权利要求2所述的方法,其特征在于,
所述点对点加密的方式包括:对更新文件进行加密,使用超文本传输协议HTTP传输加密后的更新文件;
采用对更新文件进行加密,使用HTTP传输加密后的更新文件时,所述待更新的Web服务器根据点对点加密的方式及加密参数从所述已更新的Web服务器获取更新文件的过程包括:
所述待更新的Web服务器从所述已更新的Web服务器获取加密后的更新文件,使用加密参数对加密后的更新文件进行解密。
5.如权利要求1所述的方法,其特征在于,
所述更新文件为:普通文件或特殊文件;
当所述更新文件为特殊文件时,所述管理服务器在选择Web服务器从发布服务器获取更新文件前,选择加密算法并生成加密密钥和解密密钥,将所述加密算法、加密密钥以及更新文件的文件名通知发布服务器;
所述发布服务器根据更新文件的文件名,按照加密算法使用加密密钥分别对更新文件的文件体和文件名加密,并使用加密后的文件名命名加密后的文件体,将加密后的文件名发送给管理服务器;
所述管理服务器根据加密后的文件名,执行所述通知所选择的Web服务器从发布服务器获取更新文件的操作,完成对Web服务器的更新后,将加密算法、解密密钥和加密后的文件名通知完成更新的Web服务器;
所述完成更新的Web服务器根据加密算法,采用解密密钥分别对加密后的文件名和文件体进行解密。
6.一种文件发布系统,包括:管理服务器、发布服务器和Web服务器,其中:
所述管理服务器,用于通知所选择的Web服务器从发布服务器获取更新文件,所选择的Web服务器从所述发布服务器获取更新文件,完成更新后,所述管理服务器还根据Web服务器选择策略选择待更新的Web服务器,通知所选择的待更新的Web服务器从已更新的Web服务器获取更新文件;
所述待更新的Web服务器,用于从所述已更新的Web服务器获取更新文件,完成更新;
所述Web服务器选择策略包括但不限于:
根据硬件性能对Web服务器进行排序,按照硬件性能由好到差的顺序选择Web服务器;
根据负荷对Web服务器进行排序,按照负荷由低到高的顺序选择Web服务器;
每轮发布时,根据机器性能和当前负荷参数计算出当前服务能力,按当前服务能力由高到低的顺序选择Web服务器;
预先配置更新队列,按照由前到后的顺序选择Web服务器。
7.如权利要求6所述的系统,其特征在于,
所述更新文件为:普通文件或特殊文件;
所述管理服务器,还用于当所述更新文件为特殊文件时,在通知所述待更新的Web服务器从已更新的Web服务器获取更新文件前,通知所述已更新的Web服务器对更新文件进行点对点加密;
所述已更新的Web服务器,用于选择点对点加密的方式,并将所选择的点对点加密的方式及加密参数通过管理服务器通知所述待更新的Web服务器;
所述待更新的Web服务器根据点对点加密的方式及加密参数从所述已更新的Web服务器获取更新文件。
8.如权利要求6所述的系统,其特征在于,
所述更新文件为:普通文件或特殊文件;
所述管理服务器,还用于当所述更新文件为特殊文件时,在选择Web服务器从发布服务器获取更新文件前,选择加密算法并生成加密密钥和解密密钥,将所述加密算法、加密密钥以及更新文件的文件名通知发布服务器;并且,根据接收到的加密后的文件名,执行所述通知所选择的Web服务器从发布服务器获取更新文件的操作,完成对Web服务器的更新后,将加密算法、解密密钥和加密后的文件名通知完成更新的Web服务器;
所述发布服务器,用于根据更新文件的文件名,按照加密算法使用加密密钥分别对更新文件的文件体和文件名加密,并使用加密后的文件名命名加密后的文件体,将加密后的文件名发送给管理服务器;
所述完成更新的Web服务器,用于根据加密算法,采用解密密钥分别对加密后的文件名和文件体进行解密。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 200910164897 CN101997896B (zh) | 2009-08-19 | 2009-08-19 | 一种文件发布的方法及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 200910164897 CN101997896B (zh) | 2009-08-19 | 2009-08-19 | 一种文件发布的方法及系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101997896A CN101997896A (zh) | 2011-03-30 |
CN101997896B true CN101997896B (zh) | 2013-06-05 |
Family
ID=43787477
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN 200910164897 Expired - Fee Related CN101997896B (zh) | 2009-08-19 | 2009-08-19 | 一种文件发布的方法及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101997896B (zh) |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104580357B (zh) * | 2014-11-25 | 2018-06-05 | 南京奥拓电子科技有限公司 | 一种可扩展的综合信息发布系统 |
CN104392008B (zh) * | 2014-12-19 | 2017-12-05 | 北京奇虎科技有限公司 | 网页数据获取方法、浏览器客户端及cdn服务器 |
CN108958900A (zh) * | 2017-05-18 | 2018-12-07 | 腾讯科技(深圳)有限公司 | 一种任务发布方法和任务发布系统 |
CN109408486B (zh) * | 2018-10-29 | 2020-10-30 | 珠海格力电器股份有限公司 | 文件发布方法和系统、发布服务器和文件生成装置 |
CN110445869B (zh) * | 2019-08-13 | 2022-02-15 | 中国工商银行股份有限公司 | 一种基于分布式订阅的内容发布方法、终端及服务器 |
CN111782730B (zh) * | 2020-07-09 | 2021-07-06 | 腾讯科技(深圳)有限公司 | 一种文件上传方法、装置及存储介质 |
CN113382286A (zh) * | 2021-06-07 | 2021-09-10 | 中山亿联智能科技有限公司 | 基于iptv的自动处理文件下载通知的方法 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101079709A (zh) * | 2006-06-15 | 2007-11-28 | 腾讯科技(深圳)有限公司 | 单点对多节点并发下载系统和方法 |
CN101132272A (zh) * | 2006-08-23 | 2008-02-27 | 中国科学院计算技术研究所 | 一种同时支持分布式加密文件下载和使用的系统 |
CN101252602A (zh) * | 2008-03-31 | 2008-08-27 | 华为技术有限公司 | 文件分发及下载的方法和系统 |
-
2009
- 2009-08-19 CN CN 200910164897 patent/CN101997896B/zh not_active Expired - Fee Related
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101079709A (zh) * | 2006-06-15 | 2007-11-28 | 腾讯科技(深圳)有限公司 | 单点对多节点并发下载系统和方法 |
CN101132272A (zh) * | 2006-08-23 | 2008-02-27 | 中国科学院计算技术研究所 | 一种同时支持分布式加密文件下载和使用的系统 |
CN101252602A (zh) * | 2008-03-31 | 2008-08-27 | 华为技术有限公司 | 文件分发及下载的方法和系统 |
Also Published As
Publication number | Publication date |
---|---|
CN101997896A (zh) | 2011-03-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101997896B (zh) | 一种文件发布的方法及系统 | |
EP3293934B1 (en) | Cloud storage method and system | |
CN102710630A (zh) | 一种多线程分片的云上传下载方法及系统 | |
US20160119292A1 (en) | Re-encryption system, re-encryption apparatus, and program | |
CN103297428B (zh) | 一种云存储系统数据保护方法 | |
US20130283056A1 (en) | Providing security services on the cloud | |
EP2992639B1 (en) | Splicing into an active tls session without a certificate or private key | |
US11374908B2 (en) | Private virtual network replication of cloud databases | |
US10764261B2 (en) | System and method for enabling a scalable public-key infrastructure on a smart grid network | |
CN105208404A (zh) | 一种视频加密、解密方法及装置 | |
EP1548614B1 (en) | Storage service | |
CN103209202A (zh) | 用于传输数据的方法和设备 | |
CN102801810A (zh) | 在内容分发网络中隐藏url的方法 | |
CN102693597A (zh) | 基于远程票据信息的本地打印方法和装置 | |
CN110581829A (zh) | 通信方法及装置 | |
CN111953716B (zh) | 消息通讯方法、系统、计算机设备及存储介质 | |
CN115967175A (zh) | 一种面向储能电站边缘端数据采集控制装置及方法 | |
CN114338179A (zh) | 页面加密方法、页面解密方法、装置、终端和服务器 | |
CN114531455B (zh) | 基于边缘协助的多云安全存储方法 | |
CN115756538A (zh) | 一种软件在线升级的方法 | |
CN101052001B (zh) | 一种p2p网络信息安全共享的系统和方法 | |
CN111464311A (zh) | 一种机固多节点一体授权管理的方法 | |
CN118432846B (zh) | 一种基于文件交换柜的文件交换方法 | |
CN116389508B (zh) | 一种基于联盟链的多中心数字内容分发方法及系统 | |
CN107612942A (zh) | 一种短信平台用户数据传输安全加密方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
C41 | Transfer of patent application or patent right or utility model | ||
TR01 | Transfer of patent right |
Effective date of registration: 20160928 Address after: 100000 No. 1026, building 5, building 1, two street, five Li Jie Road, Beijing, Chaoyang District, 10 Patentee after: Shiyuki Bo (Beijing) Technology Co., Ltd. Address before: 518057 Nanshan District high tech Industrial Park, Guangdong, South Road, science and technology, ZTE building, legal department Patentee before: ZTE Corporation |
|
CF01 | Termination of patent right due to non-payment of annual fee | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20130605 Termination date: 20170819 |