备份技术论文精品(七篇)

序论：写作是一种深度的自我表达。它要求我们深入探索自己的思想和情感，挖掘那些隐藏在内心深处的真相，好投稿为您带来了七篇备份技术论文范文，愿它们成为您写作过程中的灵感催化剂，助力您的创作。

篇(1)

关键词：热备，集群，容错，数据同步，心跳机制，高可用性

 

0.概述

容错热备份系统就是指由至少一台主机，一台备机组成的一个集群，当在主机上运行的应用程序或者控制系统由于外界各种未知的干扰，而出现了停止，数据损坏或者丢失的情况下，集群会自动将主机上运行的应用程序或者控制系统切换到备机上继续运行，并且保证网络ip地址也随之进行切换，保证数据同步，使数据不丢失，不损坏。论文参考网。

本文主要研究了容错热备份系统的切换可靠性，方案的可用性以及监控过程中的心跳机制和切换当中的数据同步。分别验证了“N对1”和“N加1”的热备份方案。

1.容错热备份系统的原理介绍

Veritas ClusterServer(VCS)，是一种高可用性集群软件，主要用在双机热备，容错系统中，保护数据，保持不间断服务。本文即采用Symantec公司的VCS软件达到对应用程序中进程的监控和切换。VCS使用的心跳协议是低延迟传输协议(LLT, Low LatencyTransport)，LLT协议比IP协议更快并且可靠， LLT协议上方为组成员和广播协议(GAB, Group MembershipService Broadcast)，由其发送广播。GAB为多点对多点的传输协议，有信息传输的安全保障功能， GAB驱动LLT，为整个集群提供了可靠的数据传输。高可用进程(High availability Daemon, HAD)是VCS的主要进程，在GAB上层注册，用以监控管理集群中物理机器的状态。在以上这些协议以及进程之上，VCS中，是最上层提供管理资源的逻辑的多县城进程。针对每个资源类型，都有相应的，监视对应类型的资源。原理构架如图一所示：

图一 VCS原理构架

2.容错热备份系统的方案对比

本文采取的容错热备份方案有以下两种：N对1热备份方案和N加1热备份方案。论文参考网。论文参考网。

2.1 N对1热备份方案

N对1的热备份方案主要采用的是非对称的故障切换模式，提供了一个专用的备份服务器，整个集群中的N台主机对应一个备机，当任何一台主机发生故障时，集群会将该主机的应用程序切换到这一台备机上，由于提供了专用备机，没有在同一台计算机上运行多个应用程序而互不兼容的风险。

2.2 N加1热备份方案

N加1热备份方案主要采用的是对称故障切换模式，该方案下，不需要专门的冗余服务器，集群中的一台额外服务器只是用作备份容量，集群中的某台主服务器出现故障时，可以通过之前的配置，切换到集群中任意一台机器上，任何服务器可以为其它服务器提供冗余。

3.容错热备份系统的实现及验证结论

本文的实验环境采用3台Linux操作系统的计算机作为容错热备份系统的物理节点，挂接磁盘，分别用来验证N对1和N加1方案的可行性。

本文论证了三种情况：1.杀死主机上正在运行的应用程序的进程（即可认为是应用程序出现问题的情况）；2.主机与公网断网的情况；3.主机意外宕机的情况。以上三种情况下，该容错热备份系统均能成功检测并且平滑切换，保证了数据同步，数据信息无损失。

通过对容错热备份系统的深入研究，以及多种不同热备份方案的比较，得出以下结论：本文采用的容错热备份系统，适用性广泛，对于各种不同的领域，均可达到网络信息与服务高可靠性的持续运行，并且保证数据的同步。

【参考资料】

[1]张艳,李舟军,何德全.灾难备份和恢复技术的现状与发展[J].计算机工程与科学,2005,(02).

[2]刘迎风,祁明.容灾技术及其应用[J].计算机应用研究,2002,(06).

[3]刘卫平.网络存储中的数据容错与容灾技术研究[D].西北工业大学, 2006.

[4]于雪松,王孝良,张雪源.具有双机热备功能智能电网数据采集系统[J].东北电力技术2010,(01).

[5]王丽华.计算机容错系统的体系结构与安全性研究[D].西南交通大学,2002.

[6]李海山.面向恢复的容错计算机技术研究[D].哈尔滨工程大学,2007.

[7]何晓琴,胡勇,常有渠.一种低成本的数据库热备份方法[J].重庆电力高等专科学校学报,2008,(04).

[8]陈筠,桑楠,熊光泽. 一种容错实时计算机体系结构的研究与实现[J].电子科技大学学报,2007,(05).

[9]毛睿.“双机容错”在我院信息系统中的应用[J].电脑知识与技术,2008,(35).

篇(2)

论文摘要：急救指挥中心所有的软件和用户数据都存储在服务器硬盘这个核心的数据仓库中，如何保证服务器数据的安全，并且保证服务器最大程度上的不间断运作对每个指挥中心来说都是一个关键问题。针对急救通讯指挥系统的安全保障问题，从数据物理安全、网络安全、应用系统安全、告警控制系统等方面论述了应采取的安全防范措施。对保障网络指挥中心数据安全具有重要意义。

1数据的物理安全方法

1.1RAID技术

对每台服务器的两块硬盘做RAID技术处理，把多块独立的硬盘(物理硬盘)按不同的方式组合起来形成一个硬盘组(逻辑硬盘)，从而提供比单个硬盘更高的存储性能和提供数据备份技术。数据备份的功能是在用户数据一旦发生损坏后，利用备份信息可以使损坏数据得以恢复，从而保障了用户数据的安全性，而且数据备份是自动的。在用户看起来，组成的磁盘组就像是一个硬盘，用户可以对它进行分区，格式化等等。总体来说，RAID技术的两大特点是速度和安全。

1.2双机热备系统

从狭义上讲，双机热备特指基于active/standby模式的服务器热备。服务器数据包括数据库数据同时往两台或多台服务器写，或者使用一个共享的存储设备。在同一时间内只有一台服务器运行。当其中运行着的一台服务器出现故障无法启动时，另一台备份服务器会通过软件诊测(一般是通过心跳诊断)将standby机器激活，保证应用在短时间内完全恢复正常使用。双机热备的工作机制实际上是为整个网络系统的中心服务器提供了一种故障自动恢复能力。

2、网络安全保障体系

中心网络由局域网、外部网两大部分组成。因此，我们为了建立起强大、稳定、安全的网络，可从两大安全层次着手设计与管理：局域网安全和外部网安全，这两大层次结合起来才能构成完善的网络安全保障体系。

2.1应用系统安全

应用系统的安全主要是保护敏感数据数据不被未授权的用户访问。并制订出安全策略。包括身份认证服务;权限控制服务;信息保密服务;数据完整;完善的操作日志。这些服务互相关联、互相支持，共同为本系统提供整体安全保障体系。

2.2数据安全

数据的安全主要体现在两个方面，首先，是数据不会被非授权用户访问或更该，其次，数据在遭到破坏时的恢复。

3应用安全系统

资料永久保存，磁带回复时间无严格限制。数据存储：磁盘阵列+磁带库;Tier1=4TB HDD存放线上经常使用的数据;备份带库：3TB定时定期备份所有数据。

3.1采用磁带库

磁带库具有如下优点：更高的价值;简化IT;集成的解决方案;灵活的数据存储和转移;多种接口选择;AES256位嵌入式硬件加密和压缩功能;用户可自行维护和更换的组件;广泛的兼容性测试;久经考验的可靠性。

3.2数据备份软件

3.2.1基于LAN备份方案

LAN是一种结构简单，易于实现的备份方案，广泛的存在于各中小企业中LAN方案在企业发展壮大过程中所发挥的作用一直被客户所认同。由于急救系统用户数据量的巨大，基于LAN备份的弊端较突出：此方案对LAN的依赖非常强;因为内部LAN为企业内部办公用网络，而LAN方案依赖现有网络进行备份恢复数据流的传输，所以必然会影响现有办公网络环境;基于LAN备份难于扩展，因为需要而添加存储设备将导致繁忙的办公网络更加繁忙;管理困难是LAN备份的又一难题，因为设备分散于网络各个环节，使管理员进行数据备份恢复及平时维护工作有一定难度。

3.2.2基于IPSAN的备份方案

基于IPSAN的备份方案，通过结合CBS备份管理软件，将使备份恢复工作简单而有效。

备份网络与办公网络有效隔离开，备份数据不通过办公网络传输，而是直接通过IPSAN交换机与存储设备进行连接。

系统具备良好的扩展性能，在现有基础上，客户能够添加各种存储设备(需支持ISCSI)。

根据客户需要，可以实现D2D2T功能。将数据首先备份于速度较快的磁盘阵列上，加快备份的速度。再将数据从磁盘阵列备份到磁带库。

通过CBS备份管理软件能够集中管理其中各种设备，制定备份策略，安排备份时间，实现无人值守作业，减轻管理员的工作量。下图为CBS备份框架。

备份服务器作为整个CBS备份架构的中心，实现管理功能。

4告警控制系统

通讯指挥系统出现故障时自动告警提示，确保系统安全运行。2M口通讯故障告警、网络通讯故障告警、终端网络断开告警、电话到达告警、定时放音、扩音、报时控制，也可自动循环播放、电源出现故障可自动向受理台告警。

警告系统整体性能：输入：8-32通道，8通道递增;电源输入：AC 180V-250V 50Hz;控制通道输入及输出：AC<240V/3ADC<30V/3A;告警控制盒与计算机的通讯连接告警控制盒端用：232口;计算机端用：COMl口或COM2口;使用电缆：232串口电缆;各告警通道开启时间超过10分钟将自动关闭;各开/关控制通道接通时间超过10分钟将自动断开。

5总结

随着数据管理与控制信息化综合系统的不断完善，对服务器数据的安全要求也越来越高，论文就如何保障急救指挥中心证服务器数据的安全，论文从数据物理安全、网络安全、应用系统安全、告警控制系统等方面论述了应采取的安全防范措施。对保障网络指挥中心数据安全具有指导性的作用。

参考文献：

[1]何全胜，姚国祥.网络安全需求分析及安全策略研究.计算机工程，2000，(06).

篇(3)

关键词： IPTV; 负载平衡; 影音串流; 影音备份; 随选视讯

中图分类号： TN964?34 文献标识码： A 文章编号： 1004?373X（2014）24?0022?06

IPTV system with load balance among replica servers

GUO Shu?yao， LI Meng?huang

（Department of Information Technology and management， Shih Chien University， Taipei 104， Taiwan， China）

Abstract： Since the video media has wide band width， the improvement of QoS （quality of service） of IPTV system depends on effective management of video servers. A video replication and access request distribution algorithm to implement a load balanced IPTV system with replica servers is proposed in this paper. The proposed algorithm is based on the more replicas for hot program and load distribution among replica servers. By comparing with two other algorithms， the proposed algorithm features better load balance effects. System practices demonstrate that the access requests can be evenly distributed among replica servers such that a better streaming service can be provided. The proposed algorithm has been implemented on an IPTV system platform. The relative technical issues for the implementation are discussed.

Keyword： IPTV; load balance; video streaming; video replica; video on demand

0 引 言

在VOD（Video on Demand）的系统规划上或是Video Replication and Placement的研究上，或是CDN（Content Delivery Network）系统建置的成本问题探讨上，storage capacity的需求是很明确的，就是各Video program的档案总和（也就是各Video program的program duration总和）。然而network bandwidth的需求的估算就比较困难[1?3]。论文以“worst?case demand”作为network bandwidth配置的参考参数，从而决定系统建置所需的storage capacity、网络光纤及交换设备的容量。Worst?case demand即是peak usage demand，在peak usage period的时候，使用者的数目达到最高峰，这些使用者所使用的network bandwidth总和即是worst?case demand，系统网络的配置必须依据此最高峰的network bandwidth需求来设定，以确保其服务质量。而在文献[1?3]的论文中，则以replication的方式来分散单一Origin server的负荷，在此架构中，Replica servers用来储存许多热门的影音内容，各影音内容依其viewing request probability来决定影音replication的份数，从而分散这些热门影音内容被点选时的网络流量带宽，以得到最佳成本的系统建置。 虽然上述论文有数学模式来描述worst?case demand的估量方法，然而还是无法精确地估量系统的worst?case demand，尤其Replica servers对worst?case demand估量的影响，文献[1?3]的分析模式有其适用性的问题与困难。除了文献[1?3]的研究外，文献[4?8]等研究的replication策略， 都是依各影音的热门程度，给予不同备份数的影音档，藉此来分散掉该影音在Origin Server的负荷。比如若A影片的热门程度是B影片的3倍的话，若B影片在replica servers有2个replicas的话，那么A影片就会有6个replicas安置在replica servers。而上述影音的热门程度的决定，在文献[4?8]等的研究会以影片的access rate或access probability或popularity来界定该影音的热门程度。

本文以图1的架构探讨具有replica servers的IPTV系统架构的video replication及access request distribution。如何将Origin Server里的影音replicated至replica server，此即video replication的问题;当一个access request要求服务时，如何将此access request distribute各replica servers，此即access request distribution的问题。此IPTV系统是架构在Smart?iTV的系统平台，提供以遥控器为输入设备的IPTV服务[9]，亦能提供汇流IPTV、PC及mobile device的数字汇流影音服务[10]。

图1 具有replica servers的VOD系统架构

1 Video replication algorithm和Access

request distribution algorithm

为了方便探讨，本文假设此IPTV系统的每个影音档案都具有同样的大小以及播放的带宽。因此对于Replica Server j的空间容量Cj系以可以储存多少个影片来表示;而Replica Server j的带宽容量Bj 则以可以同时播放多少个影片来表示。本文以αj来代表Replica Server j的replication风险值，此值是探讨Video replication algorithm的重要参考值。

表1 理论模式中所提及的符号

以下列的Test Case来比较不同算法的优劣，此Test Case为：v1，v2，v3，v4，v5，v6，v8，v10，v12。假设有9部影音分别为v1每1 s被点播1次;v2每2 s被点播1次;v3每3 s被点播1次;v4每4 s被点播1次;v5每5 s被点播1次;v6每6 s被点播1次;v8每8 s被点播1次;v10每10 s被点播1次;v12每12 s被点播1次，共9部影音。此时有一部Origin Server以及三部replica servers为Replica Server I，Replica Server Ⅱ，Replica Server Ⅲ来建构此9部影音的播放服务;每当有一影音被点播，则该影音第一次被播放时是Origin Server来提供，此时该影音将被备份至3部replica servers中的某一台，之后该影音要再度被点播时则由存放该影音的replica server来提供;此处亦假设每部replica server的Bj为3，Cj为4。以下分别以算法一、算法二、算法三来探讨不同算法的优劣。

算法1：Video replication algorithm：选择最不常使用的replica server作为video replication的replica server。Access request distribution algorithm： 端视access request的影音座落在哪个replica server，即由该replica server执行该影音的播放。

根据上述algorithms，Test case在各时间的video replication及access request distribution如图2所示。第1 s时v1由Origin Server播放，此时三部replica servers总共播放次数皆为0，则依顺序从Origin Server中将v1影音复制至Replica Server I，此时Replica Server I的存放影音个数为1。第2 s时v1由Replica Server I执行v1的播放，此时v2由Origin Server被播放，同时v2将从Origin Server被复制，此时Replica Server Ⅱ，Replica Server Ⅲ尚无提供影音的播放，则依顺序从Origin Server中将v2影音复制至Replica Server Ⅱ ，此时Replica Server Ⅱ的存放影音个数为1。于第8 s时，Replica Server Ⅲ的存放影音个数为4，已达到replica server最大储存空间Cj上限4。而在第10 s时，由于Replica Server Ⅲ影音总共播放次数最少，因而从Origin Server将v10复制至Replica Server Ⅲ，但Replica Server Ⅲ储存影音空间Cj已达上限4，因此将发生v10无法被复制及播放问题。

图2 算法1的仿真结果

算法2：Video replication algorithm：选择较低的αj的Replica Server j执行video replication;Access request distribution algorithm：端视access request的影音座落在哪个replica server，即由该replica server执行该影音的播放。

根据上述algorithms，Test case在各时间的video replication及access request distribution如图3所示。第1 s时v1由Origin Server播放，此时v1将被复制，同时三部replica server之αj值皆为[03]，则依顺序从Origin Server中将v1备份至Replica Server I，此时Replica Server I的存放影音个数为1。第2 s时v1由Replica Server I执行v1的播放，同时v2从 Origin Server中被播放，此时Replica Server Ⅱ，Replica Server Ⅲ之αj值皆为[03]，则依顺序从Origin Server中将v2备份至Replica Server Ⅱ，此时Replica Server Ⅱ的存放影音个数为1。第3 s时v1由Replica Server I执行v1的播放，同时v3从Origin Server中被播放，此时Replica Server Ⅲ之αj值为[03]，则从Origin Server中将v3备份至Replica Server Ⅲ，此时Replica Server Ⅲ的存放影音个数为1。依此程序持续将v1，v2，v3，v4，v5，v6，v8，v10，v12备份在Replica Server I、Replica Server Ⅱ、Replica Server Ⅲ上，虽然与演算一比较后每个影音都能均匀分布在各个replica server上，但未考虑各个影音热门程度问题，因此各个replica server处理影音播放工作量不平衡，可得知Replica Server I播放影音总共次数比Replica Server Ⅱ及Replica Server Ⅲ多，但未达到负载平衡成效。

图3 算法2的仿真结果

算法3：Video replication algorithm：选择较低的αj的Replica Server j执行video replication;并将热门的影音备份到更多的replica servers。Access request distribution algorithm：当有多个replica servers具有access request所需的影音时，选择负荷最小的replica server，执行该影音的播放。

根据上述algorithms，Test case在各时间的video replication及access request distribution如图4所示。

事先设定每5 s会去查询单位时间内影音被播放的状况以得知5 s内被点播次数最多的影音，设定为热门影音，即备份至其他的replica servers，以平均分担各个replica server的负载。本算法在将影音备份到各个replica servers的过程，具皆与算法二一致，亦即以αj值作重要的参考参数。当在第5 s时v1被播放，系统每5 s查询各影音被播放之状况，发现v1于5 s内被播放次数达到4次。相较于目前所被播放的影音v2，v3，v4都来得热门许多，因此启动v1备份。由于Replica Server Ⅱ、Replica Server Ⅲ之αj值皆为[13]，则依顺序将v1备份至Replica Server Ⅱ。至于access request distribution的运作，以图4的第120 s为例，在此时间，Test Case的9个影音都需播放，由于v3，v4，v5，v6，v8，v10，v12均只有一份影音在特定的replica server，所以这些影音只能在此些replica server上播放。亦即Replica Server I播放v4，v6，v10;Replica Server Ⅱ播放v5，v8，v12;Replica Server Ⅲ播放v1，v3，v5;如是Replica Server I为满载负荷，Replica Server Ⅱ、Ⅲ相对负荷较小。由于v2在Replica Server Ⅱ、Ⅲ均有备份，v1则在Replica Server I、Ⅱ、Ⅲ均有备份，所以择定v2在Replica Server Ⅱ播放，v1在Replica Server Ⅲ播放，如此可以得到3部replica servers的负载平衡。

图4 算法3的仿真结果

图4与图3相较，皆能符合系统影音服务需求，图4经由将热门影音备份在更多的replica servers，而有较佳的负载平衡，其负载比例为1∶1∶0.9，而图3的负载比例为1∶0.5∶0.3。因此，本文即以算法3作为实践此一具有负载平衡的IPTV串流系统。

2 系统架构

2.1 前台系统架构

由于本文是修改Smart?iTV系统平台，以成为一个具负载平衡的影音串流系统，所以本论文势必须对Smart ?iTV系统做详尽的剖析，才能在此系统内嵌此负载平衡的模块。攸关本论文的Smart?iTV系统为其前台系统，此前台系统概分为影音选单页面、影音介绍页面、以及影音播放页面，如图5所示。

影音选单页面的选项可能为影音内容的选项或是另一个影音选单页面，若是该选项属于影音内容的选项，当该选项被点选时，系统即呈现该影音内容的影音介绍页面，该页面会有一触发影音播放的关键点，当使用者启动触发影音播放关键点时，该影音内容即内嵌在影音播放页面做串流播放，并且将该影音的播放次数记录在Smart?iTV的数据库里。

图5 Smart?iTV影音选单页面到影音播放页面的流程关系

2.2 具平衡负载的串流系统架构分析

为达串流负载平衡的串流系统，本论文提出Original video replication、Hot video replication 及Access request distribution这三个模块的实作，如图6所示。当使用者点播某部影音时，Original video replication module将查询使用者所点选的影音过去曾被播放过，若不曾被播放过，则由Origin Server提供影音播放服务，并依照算法3，将所被点播的影音备份至αj值较低的Replica Server j;若曾被播放过，则Access requests distribution process将至Smart?iTV数据库查询哪些replica servers有该影音的备份，并依算法3选择负载较低的replica server，来执行此影音播放的服务。Hot video replication process是一个back?ground process，每单位时间内去查询Smart?iTV数据库中被点播次数最多的影音，判定为热门影音，并选择αj值较低的replica server，将此热门的影音备份到该replica server。图6的Replica Server I、Ⅱ两个replica servers，在Smart?iTV的Original video replication module及Hot video replication process会各自与replica server的Peer video replication共同完成video replication的任务。

图6 具平衡负载的串流系统架构图

3 系统实作

由于本系统是架构Smart?iTV上，所以会引用部分Smart?iTV数据表及相关字段，并增加部分的数据表及数据表字段，为使这些信息能够被清楚检视，兹整理如表2所示。

表2 影音播放相关数据表

参照图7，当使用者进入影音选单页中所呈现的影音选项来自步骤0.1的CategoryTemplate数据表中Cate_Name值，而使用者点选某一影音选项时则可能导向步骤0.2或步骤0.3，步骤0.2根据使用者所点选之Cate_Name值找出其对应的Cate_ShowMode值，当Cate_ShowMode为‘3’时则又是另一组影音选单页，当Cate_ShowMode值为‘1’时直接进入步骤0.3同时将Cate_UID值传至影音介绍页，依照Cate_UID值根据步骤0.4找到相符合的ML_PID值所对应的ML_UID域值及ML_Content及影音文件名。当使用者于影音介绍页中启动触发影音播放的关键点时，及执行步骤0.5将ML_Content值传至影音播放页，影音播放页串流服务是透过mms的协议来达成的，此即mms：//IP address of a replica server/Media Service的发行端点/被点播的影音档名，被点播的影音档名即步骤0.5的ML_Content值。同时执行步骤0.6将View_ContentID值记录至View_Content_Log数据表，以记录像音的播放次数。基于上述所讨论的Smart?iTV的架构，本论文在影音播放页内嵌了Original video replication module及Access request distribution process的模块、在Smart?iTV的系统安置了Hot video replication process的background job、以及记录各replica servers规格的Replica_Server_Profile数据表、记录各replica servers存放影音文件的Replication_Log数据表、记录各影音在各replica servers播放次数的View_Count，如图7所示。图7的0.1～0.6步骤，为上述Smart?iTV既有影音播放的流程;步骤1.1～1.4是Original video replication module的步骤流程;步骤2.1～2.5是Access request distribution process的步骤流程;步骤3.1～3.7是Hot video replication process的步骤流程。当有一影音被点播，Original video replication module将查询View_Content_Log及MediaListTemplate检视该影音过去是否有被播放过，如步骤1.1;若不曾被播放过，此时依照图6情境由Original Server提供影音播放，随即启动video replication将影音备份至最小αj（从Replica_Server_Profile得到）的Replica Server j，并更新Replica_Server_Profile的Replica Server j存放的影音数及记录备份影音数据至Replication_Log，如步骤1.2、1.3、1.4;若不曾被播放过即启动Access request distribution process，选择Origin Server播放，同时标记该影音已表示该影音被播放过，若曾被播放过至Replication_Log查询该影音备存放在哪一Replica Server j，挑选该Replica Server j播放，并记录其播放该影音次数，如步骤2.1、2.2;若于Replication_Log中查询到有两个Replica Server j皆拥有该影音档案，则依步骤2.3查询View_Count_Stat_On_Replica数据表根据播放影音量最少的Replica Server j来播放，并记录Replica Server j播放次数，如步骤2.4、2.5。

图7 具负载平衡之IPTV系统实作架构

步骤3.1、3.2单位时间内Hot video replication process将去查询View_Count_Log数据表被播放次数最高的影音，设定为热门影音，如步骤3.3;即启动video replication将影音备份至最小αj（同步骤1.2）的Replica Server j，如步骤3.4;并更新Replica_Server_Profile的Replica Server j存放的影音数及记录Replication_Log备份影音数据，如步骤3.5、3.6;每当Hot video replication process完成video replication动作时，即更新View_Count_Log重置影音播放次数，如步骤3.7。

图8 具负载平衡之IPTV影音串流系统实作

图8为图7的细部流程及对应的数据表的关系图。使用者要点播影音vi，可从View_Content_Log及MediaListTemplate中计算ML_UID次数，即可判断vi是否曾经被点播过，若不曾点播过vi，则Origin Server播放vi，并将vi备份至最小αj（从Replica_Server_Profile计算CurrVideoNum/Bandhwidth得αj）的Replica Server j并更新Replica_Server_Profile的CurrVideoNum值及记录Replication_Log的Video_Name值为vi，同时于记录MediaListTemplate的ML_PlayBack值，表示已被Origin Server播放过。若vi曾被点播过（从MediaListTemplate的ML_PlayBack知道），则从Replication_Log数据表可知，是否有两部以上replica servers存放vi。若为false，即从Replication_Log挑选存放vi的Replica Server j播放，并于View_Count_Stat_On_Replica中记录Replica Server j播放vi次数;若为true，即从View_Count_Stat_On_Replica数据表中，搜寻存放vi的replica servers播放影音量最少的Replica Server j来播放vi，同时于View_Count_Stat_

On_Replica中记录Replica Server j播放vi次数。而Hot video replication process则是每单位时间内计算View_Count_Log中影音放次数最高的影音，并设定为热门影音，并查询最小αj的Replica Server j，将此热门影音备份至更多的replica servers，同时更新Replica_Server_Profile的CurrVideoNum值及记录Replication_Log的Video_Name值为vi。

4 结 论

本文提出在Smart?iTV平台上建构一个具负载平衡的IPTV影音串流系统的video replication及access request distribution algorithms，并以Original video replication，Access request distribution及Hot video replication等3个模块来实作此algorithms。除了比较与验证相关算法之外，本文已分析系统实作的方式及可行性。经实例验证，此系统确能达到replica servers负载平衡的效果，以能承载更多的系统服务要求。

参考文献

[1] THOUIN Frederic， COATES Mark. Equipment allocation in video?on?demand network deployments [J]. ACM Transactions on Multimedia Computing， Communication， and Applications， 2008， 5（1）： 1?22.

[2] THOUIN Frederic， COATES Mark. Video?on?demand server selection and placement [C]// Proceedings of the 20th International Tele?traffic Conference on Managing Traffic Performance in Converged Networks. [S.l.]： [s.n.]， 2007： 18?29.

[3] ZHOU Xiao?bo， XU Cheng?zhong. Efficient algorithm of video replication and placement on a cluster of streaming servers [J]. Journal of Network and Computer Applications， 2007， 30（2）： 515?540.

[4] TAN Bo， MASSOULIE Laurent. Optimal content placement for peer?to?peer video?on?demand systems [C]// Proceedings of IEEE INFOCOM. [S.l.： IEEE， 2011： 694?702.

[5] NEVES Tiago Araujo， DRUMMOND Lucia Maria de A， OCHI Luiz Satoru， et al. Solving replica placement and request distribution in content distribution networks [J]. Electronic Notes in Discrete Mathematics， 2010， 36： 89?96.

[6] CHELLOUCHE Soraya Ait， AUBRY Will， NEGRU Daniel， et al. Home boxes support for an efficient video on demand distribution [C]// Proceedings of 2011 IEEE International Conference on Multimedia and Expo（ICME）. [S.l.]： IEEE， 2011： 1?6.

[7] MU?OZ?GEA Juan Pedro， TRAVERSO Stefano， LEONARDI Emilio， et al. Modeling and evaluation of multisource streaming strategies in P2P VoD systems [J]. IEEE Transaction on Consumer Electronics， 2012， 58（4）： 1202?1210.

[8] WU Wei?jie， LUI J C S. Exploring the optimal replication strategy in P2P?VoD systems： Characterization and evaluation [C]// Proceedings of 30th International Conference on Computer Communications. [S.l.]： IEEE， 2011： 1206?1214.

篇(4)

关键词：内部控制，管理制度

 

我国的会计电算化工作从20世纪70年代开始，经过20多年的不断发展、完善，目前已经广泛的应用到各个行业。会计电算化替代传统的手工记账，大大提高了工作效率，推动了会计的现代化发展。论文参考，管理制度。会计电算化是会计工作的发展方向，是促进会计基础工作规范化和提高经济效益的重要手段和有效措施。在全球经济贸易一体化的今天，会计电算化地位日趋重要，但它在给我们带来巨大效益的同时，也存在巨大的风险，建立约束机制，完善电算化内部管理制度是十分必要的，我认为主要应从以下几个方面加强管理：

一、 建立健全会计电算化岗位、职责范围，建立相应制度，实行内部牵制

会计电算化后的工作岗位可以分为基本工作岗位和电算化会计岗位。电算化会计岗位包括直接管理、操作、维护计算机及会计软件的工作岗位，一般可以划分为：电算主管、软件操作、审核记账、电算维护、电算审查、数据分析等岗位。

会计电算化给会计工作增添了新的摘要保持相对稳定。各个工作岗位应建立自己的职责范围，切实做到事事有人管，人人有专责。

与传统的会计工作一样，内部会计控制的关键是不相容职务的相互分离，各单位要根据本单位的实际情况和工作需要建立内部牵制制度。论文参考，管理制度。在电算化会计系统中，不相容职务主要包括系统开发、发展与系统操作；数据维护管理与电算审核；数据录入与审核记账；系统操作与系统档案管理等，应建立一套符合职责划分原则的内部控制制度。其次，单位应对计算机的使用建立一套具体使用制度，尽量做到专机专用；实行用户权限分级授权管理，增加软件的限制功能。论文参考，管理制度。

二、 加强计算机硬件、软件管理

计算机的设备安全和正常运行是会计电算化的前提条件。论文参考，管理制度。对计算机硬件设备的管理包括：（一）、对计算机所处的环境、温度进行控制；保持设备整洁、定期进行保养、维护等以防止意外事故发生；（二）、建立完善的安全制度，防止设备被盗，防止无关人员进入计算机进行操作等。（三）、对计算机上机管理应有明确的制度规定：包括轮流值班制度、上机记录制度、上机时间安排等。

互联网实现了会计资源的信息共享，但同时也处于极大的风险之中。为了提高网络会计信息的安全应采取严密的防范措施。论文参考，管理制度。对计算机软件的管理包括：（一）、加强会计数据和会计软件的安全保密，防止非法删除和修改，定期进行备份。（二）、提高网络的安全防范能力，可采用防火墙技术、网络防毒、信息加密、存储认证、授权进入等措施。此外，会计软件还应有完备的操作日志文件。

三、 建立健全电算化档案的管理制度

会计电算化档案包括存储在计算机硬盘中的会计数据及其他磁性介质或光盘存储的会计数据和计算机打印出来的书面等形式的会计数据；会计数据是指记账凭证、会计帐薄、会计报表等数据。

电算化会计档案管理是重要的会计基础工作，应严格按照有关规定执行，由专人负责。论文参考，管理制度。（一）、计算机会计系统有关的资料应及时存档，建立完善的档案管理制度。档案管理制度应包括合格的档案管理人员、完善的资料使用和归还手续，还应有对所有档案进行定期备份的措施，制定应急措施和恢复手段，会计软件一旦受到破坏能够恢复。（二）、采用光盘等介质存储会计帐薄、报表，其保存期限同打印输出的书面形式的会计帐薄、报表。记账凭证、总分类账、现金日记账、银行日记账仍需要打印输出。对磁性介质存放的数据要保持双备份。（三）、手工录入并由计算机打印出的记账凭证上应有录入人员、稽核人员、会计主管人员的签名或盖章，收付款记账凭证还应由出纳人员签名或盖章。

四、 加强学习，提高业务素质

目前我国还有相当一部分会计人员素质较低，计算机知识掌握不够，对计算机的基本操作、维护根本不懂，对使用系统的会计人员应加强培训，减少系统运行后出错的可能性。对有关人员的培训不仅仅是对系统的使用的培训，还包括系统运行后的内部控制制度，凭证流转程序等的培训。掌握会计软件的各种功能，充分发挥其作用，也是实现电算化安全运行和保障的需要。

篇(5)

 

主要栏目

环境科学理论基础研究

环境科学应用基础研究

环境科学应用技术研究

生态环境研究

环境工程研究

环境管理研究

环境经济研究

环境法律研究

 

投稿要求

1、来稿要求论点明确、数据可靠、逻辑严密、文字精炼，每篇论文必须包括题目、作者姓名、作者单位、单位所在地及邮政编码、摘要和关键词、正文、参考文献和第一作者及通讯作者（一般为导师）简介（包括姓名、性别、职称、出生年月、所获学位、目前主要从事的工作和研究方向），在文稿的首页地脚处注明论文属何项目、何基金（编号）资助，没有的不注明。

2、论文摘要尽量写成报道性文摘，包括目的、方法、结果、结论4方面内容（100字左右），应具有独立性与自含性，关键词选择贴近文义的规范性单词或组合词（3～5个）。

3、文稿篇幅（含图表）一般不超过5000字，一个版面2500字内。文中量和单位的使用请参照中华人民共和国法定计量单位最新标准。外文字符必须分清大、小写，正、斜体，黑、白体，上下角标应区别明显。

4、文中的图、表应有自明性。图片不超过2幅，图像要清晰，层次要分明。

5、参考文献的著录格式采用顺序编码制，请按文中出现的先后顺序编号。所引文献必须是作者直接阅读参考过的、最主要的、公开出版文献。未公开发表的、且很有必要引用的，请采用脚注方式标明，参考文献不少于3条。

6、来稿勿一稿多投。收到稿件之后，5个工作日内审稿，电子邮件回复作者。重点稿件将送同行专家审阅。如果10日内没有收到拟用稿通知（特别需要者可寄送纸质录用通知），则请与本部联系确认。

7、来稿文责自负。所有作者应对稿件内容和署名无异议，稿件内容不得抄袭或重复发表。对来稿有权作技术性和文字性修改，杂志一个版面2500字，二个版面5000字左右。作者需要安排版面数，出刊日期，是否加急等情况，请在邮件投稿时作特别说明。

8、请作者自留备份稿，本部不退稿。

9、论文一经发表，赠送当期样刊1-2册，需快递的联系本部。

篇(6)

[论文摘要]为了保障数据资料的安全，必须进行数据备份。而一旦发生灾难，造成大量数据丢失，容灾系统将能保证业务尽快恢复，甚至可以保证业务不间断执行。数据备份也正是容灾系统得以运行的前提。

数据资料已经成为企事业单位的无形资产和重要财富，其安全也倍受关注。当遭受地震、洪水、台风、恐怖袭击等重大灾害，以及发生大范围停电、网络中断、硬件故障等事故时就会由于数据丢失破坏而造成重大损失。考虑到大范围内灾难或故障发生的可能性，为了保障数据安全，利用现有存储设备资源为大量的主流平台用户制定完备的备份和容灾方案，构建简单、经济、可靠的备份及容灾系统，增强系统的抗灾能力，最大限度地减少损失有着十分重要意义。

一、数据备份策略

从备份策略来讲，现在的备份可分为三种：完全备份、增量备份、差异备份、累加备份策略。下面来讨论以下这几种备份方式：

完全备份就是拷贝给定计算机或文件系统上的所有文件，而不管它是否被改变。

增量备份就是只备份在上一次备份后增加、改动的部分数据。增量备份可分为多级，每一次增量都源自上一次备份后的改动部分。

差异备份就是只备份在上一次完全备份后有变化的部分数据。如果只存在两次备份，则增量备份和差异备份内容一样。

累加备份采用数据库的管理方式，记录累积每个时间点的变化，并把变化后的值备份到相应的数组中，这种备份方式可恢复到指点的时间点。

一般在使用过程中，这三种策略常结合使用，常用的方法有：完全备份、完全备份加增量备份、完全备份加差异备份、完全备份加累加备份。

完全备份会产生大量数据移动，选择每天完全备份的客户经常直接把磁带介质连接到每台计算机上（避免通过网络传输数据）。这样，由于人的干预（放置磁带或填充自动装载设备），磁带驱动器很少成为自动系统的一部分。其结果是较差的经济效益和较高的人力花费。

完全备份加增量备份源自完全备份，不过减少了数据移动，其思想是较少使用完全备份。比如说在周六晚上进行完全备份（此时对网络和系统的使用最小）。在其它6天（周日到周五）则进行增量备份。增量备份会问这样的问题：自昨天以来，哪些文件发生了变化？这些发生变化的文件将存储在当天的增量备份磁带上。

完全备份加差异备份的思想也是较少使用完全备份。比如说在周六晚上进行完全备份，在其它6天（周日到周五）则进行差异备份。做差异备份时，将会把自上星期六以来发生了变化的文件存储在当天的增量备份磁带上。

二、容灾系统的等级及实现技术

容灾是一个范畴比较广泛的概念，广义上，我们可以把所有与业务连续性相关的内容都纳入容灾。容灾是一个系统工程，它包括支持用户业务的方方面面。而容灾对于IT而言，就是提供一个能防止用户业务系统遭受各种灾难影响破坏的计算机系统。容灾还表现为一种未雨绸缪的主动性，而不是在灾难发生后的“亡羊补牢”。从狭义的角度，我们平常所谈论的容灾是指，除了生产站点以外，用户另外建立的冗余站点，当灾难发生生产站点受到破坏时，冗余站点可以接管用户正常的业务，达到业务不间断的目的。为了达到更高可用性，许多用户甚至建立多个冗余站点。

容灾系统是通过在异地建立和维护一个备份存储系统，利用地理上的分离来保证系统和数据对灾难性事件的抵御能力。

根据容灾系统对灾难的抵抗程度，可分为数据容灾和应用容灾。数据容灾是指建立一个异地的数据系统，该系统是对本地系统关键应用数据实时复制。当出现灾难时，可由异地系统迅速接替本地系统而保证业务的连续性。应用容灾比数据容灾层次更高，即在异地建立一套完整的、与本地数据系统相当的备份应用系统（可以同本地应用系统互为备份，也可与本地应用系统共同工作）。在灾难出现后，远程应用系统迅速接管或承担本地应用系统的业务运行。

设计一个容灾系统，需要考虑多方面的因素，如备份/恢复数据量大小、应用数据中心和备援数据中心之间的距离和数据传输方式、灾难发生时所要求的恢复速度、备援中心的管理及投入资金等。根据这些因素和不同的应用场合，通常可将容灾系统分为四个等级。

第0级：没有备援中心这一级容灾系统，实际上没有灾难恢复能力，它只在本地进行数据备份，并且被备份的数据只在本地保存，没有送往异地。

第1级：本地磁带备份，异地保存在本地将关键数据备份，然后送到异地保存。灾难发生后，按预定数据恢复程序恢复系统和数据。这种方案成本低、易于配置。但当数据量增大时，存在存储介质难管理的问题，并且当灾难发生时存在大量数据难以及时恢复的问题。为了解决此问题，灾难发生时，先恢复关键数据，后恢复非关键数据。

第2级：热备份站点备份在异地建立一个热备份点，通过网络进行数据备份。也就是通过网络以同步或异步方式，把主站点的数据备份到备份站点，备份站点一般只备份数据，不承担业务。当出现灾难时，备份站点接替主站点的业务，从而维护业务运行的连续性。

转贴于

第3级：活动备援中心在相隔较远的地方分别建立两个数据中心，它们都处于工作状态，并进行相互数据备份。当某个数据中心发生灾难时，另一个数据中心接替其工作任务。这种级别的备份根据实际要求和投入资金的多少，又可分为两种：①两个数据中心之间只限于关键数据的相互备份；②两个数据中心之间互为镜像，即零数据丢失等。零数据丢失是目前要求最高的一种容灾系统方式，它要求不管什么灾难发生，系统都能保证数据的安全。所以，它需要配置复杂的管理软件和专用的硬件设备，需要投资相对而言是最大的，但恢复速度也是最快的。

在建立容灾系统时会涉及到多种技术，如：SAN或NAS技术、远程镜像技术、基于IP的SAN的互连技术、快照技术等。

衡量容灾系统的两个技术指标：RPO（Recovery Point Objective）：即数据恢复点目标，主要指的是业务系统所能容忍的数据丢失量。

RTO（Recovery Time Objective）：即恢复时间目标，主要指的是所能容忍的业务停止服务的最长时间，也就是从灾难发生到业务系统恢复服务功能所需要的最短时间周期。

RPO针对的是数据丢失，而RTO针对的是服务丢失，二者没有必然的关联性。RTO和RPO的确定必须在进行风险分析和业务影响分析后根据不同的业务需求确定。对于不同企业的同一种业务，RTO和RPO的需求也会有所不同。

三、数据容灾与数据备份的联系

从定义上看，备份是指用户为应用系统产生的重要数据（或者原有的重要数据信息）制作一份或者多份拷贝，以增强数据的安全性。因此，备份与容灾所关注的对象有所不同，备份关系数据的安全，容灾关心业务应用的安全，我们可以把备份称作是“数据保护”，而容灾称作“业务应用保护”。备份最多表现为通过备份软件使用磁带机或者磁带库将数据进行拷贝，也有用户使用磁盘、光盘作为存储介质；容灾则表现为通过高可用方案将两个站点连接起来。

备份与容灾是存储领域两个极其重要的部分，二者有着紧密的联系。首先，在备份与容灾中都有数据保护工作，备份大多采用磁带方式，性能低，成本低；容灾采用磁盘方式进行数据保护，数据随时在线，性能高，成本高。其次，备份是存储领域的一个基础，在一个完整的容灾方案中必然包括备份的部分；同时备份还是容灾方案的有效补充，因为容灾方案中的数据始终在线，因此存储有完全被破坏的可能，而备份提供了额外的一条防线，即使在线数据丢失也可以从备份数据中恢复。

要保护数据，企业需要数据备份和容灾系统。但是很多企业在搭建了备份系统之后就认为高枕无忧了，其实还需要搭建容灾系统。数据容灾与数据备份的联系主要体现在以下几个方面：

（一）数据备份是数据容灾的基础

数据备份是数据高可用的最后一道防线，其目的是为了系统数据崩溃时能够快速的恢复数据。虽然它也算一种容灾方案，但这种容灾能力非常有限，因为传统的备份主要是采用数据内置或外置的磁带机进行冷备份，备份磁带同时也在机房中统一管理，一旦整个机房出现了灾难，如火灾、盗窃和地震等灾难时，这些备份磁带也随之销毁，所存储的磁带备份也起不到任何容灾功能。

（二）容灾不是简单备份

真正的数据容灾就是要避免传统冷备份所具有先天不足，它能在灾难发生时，全面、及时地恢复整个系统。容灾按其容灾能力的高低可分为多个层次，例如国际标准SHARE 78 定义的容灾系统有七个层次：从最简单的仅在本地进行磁带备份，到将备份的磁带存储在异地，再到建立应用系统实时切换的异地备份系统，恢复时间也可以从几天到小时级到分钟级、秒级或0数据丢失等。

无论是采用哪种容灾方案，数据备份还是最基础的，没有备份的数据，任何容灾方案都没有现实意义。但光有备份是不够的，容灾也必不可少。容灾对于IT而言，就是提供一个能防止各种灾难的计算机信息系统。从技术上看，衡量容灾系统有两个主要指标：RPO（Recovery Point Object）和RTO（Recovery Time Object），其中RPO代表了当灾难发生时允许丢失的数据量；而RTO则代表了系统恢复的时间。

（三）容灾不仅是技术

容灾是一个工程，而不仅仅是技术。目前很多客户还停留在对容灾技术的关注上，而对容灾的流程、规范及其具体措施还不太清楚。也从不对容灾方案的可行性进行评估，认为只要建立了容灾方案即可高枕无忧，其实这具有很大风险的。特别是在一些中小企业中，认为自己的企业为了数据备份和容灾，整年花费了大量的人力和财力，而结果几年下来根本就没有发生任何大的灾难，于是放松了警惕。可一旦发生了灾难时，后悔晚矣！这一点国外的跨国公司就做得非常好，尽管几年下来的确未出现大的灾难，备份了那么磁带，几乎没有派上任何用场，但仍一如既往、非常认真地做好每一步，并且基本上每月都有对现行容灾方案的可行性进行评估，进行实地演练。

参考文献

篇(7)

关键词：计算机；云时代；网络；简史

中图分类号：TP3-05 文献标识码：A DoI: 10.3969/j.issn.1003-6970.2012.05.028

A Discussion on "Cloud Computing"

Jao Duo-qin

(Lanzhou Resources and Environment Voc-Tech College, Lanzou 730020, China)

【Abstract】Today is the era of new things are emerging. Did not know what the network, with great difficulty, it is also known as cloud. I start from the development of computers, covering the development of networks and cloud technology, and strive to Deep elaborate computer into the cloud era process.

【Key words】Computer; The cloud era; Network; A Brief History

0 引 言

1946年，第一台计算机发明，将人们从繁琐的数据计算中解脱出来，1969年，互联网问世，使得计算机的功能进一步强大。而到了如今一个属于网络的新名词“云”已经走进了我们的生活，什么云计算、云存储、云备份之类。那么云究竟是什么，它是怎么发展起来的呢？

1 计算机发展简史

网络是建立在多台计算机互联的基础之上的，那么在谈及网络之前，让我们先来简单了解一下计算机的发展简史。世界上第一台计算机ENIAC始于1946年，其雏形是电动计算器。计算机的发明最初用于军事，主要是用来计算弹道。这是最初的计算机，它需要占三间房的面积。到了1956年，随着晶体管的问世，第二代计算机诞生了，计算速度也大大提高，占地面积也缩小了。3年后，集成电路得以使用，随即出现了第三代计算机。随后大规模、超大规模集成电路广泛应用，计算机也逐步向前发展，速度越来越快，体积越来越小，直到今天我们看到各种形式的计算机，比如台式机、平板、笔记本电脑等。在计算机的发展历史上有一个人是不能忽视的，他就是冯·诺依曼，是他设计了计算机并提出了计算机的计算架构：输入、处理、输出，直到今天再复杂的计算机也是秉承这一工作流程，冯·诺依曼也因此被称为计算机之父。计算机主要由硬件和软件两大部分构成。硬件即计算机当中实际存在的部件，软件是众多程序的集合，是让计算机能够发挥实际效用的指令与代码的表现形式，正是因为有了软件的配合，计算机的强大功能才得以充分的发挥。计算机上可以运行众多的软件，它具有运算速度快、计算精确度高、有逻辑判断能力、有自动控制能力的特点。计算机在规模上主要经历了大型、小型机、微型机这样三个发展阶段。

2 联网发展简史

在计算机发明后的23年，也就是1969年，原来每台计算机只能单独处理数据而不能协作处理数据的不足已经不能满足人们的需要了，特别是为了军事用途而发明计算机的美国军方。于是美国军方就将加利福尼亚大学及其洛杉矶分校、斯坦福大学研究学院、犹他州大学的四台主要计算机连接起来，这次连接是在当年的12月进行的。到了1970年的6月，麻省理工学院、哈佛大学、加州对达莫尼卡系统发展公司相继加入。又到了1972年的1月，斯坦福大学、麻省理工学院的林肯实验室、卡内基梅隆大学以及CaseWesternResverve加入，紧接着国家航空和宇宙航行局、Mitre、Burroughs、兰德公司和伊利诺利州大学也加入了进来。再到了1983年时，美国国防部将这些由计算机连接起来组成的网络分为军网和民网，尔后逐渐扩大成为今天的互联网，并且吸引了越来越多的公司加入。

互联网包括因特网、万维网。互联网、因特网、万维网三者的关系是万维网是因特网的分支，因特网是互联网的分支，凡是能彼此通信的设备组成的网络就是互联网。

有了互联网，我们可以聊天、玩游戏、查阅东西等。 还可以用来进行广告宣传、购物，总之互联网给我们的生活带来了很大的方便，互联网亦可以帮助我们的工作和学习。

3 从网到云的蜕变

互联网的功能是强大的，其涵义也不断在扩大。网络本身是虚拟的，但是网络上发生的一切却是事实的。随着互联网越来越完善，越来越庞大，人们再不能满足互联网只实现一些简单的应用，他们要让互联网爆发，从而完成更多先前所不能完成的事情。而随着网络不断的强大，它也被赋予了一个生动的名字：云，天空中飘浮着不止一块云，而网络当然也不止一个，所有的网络连接起来，就如同云一样，云也因此成为了网络的代名词，是对网络的美称，是种比喻。

3.1 网络云的应用

网络云的主要应用领域就是云计算，云计算是网格计算、分布式计算、并行计算、效用计算等技术与网络技术的融合。它是基于互联网的相关服务的增加、使用和交付模式，通常涉及通过互联网来提供动态易扩展且经常是虚拟化的资源[1-3]。云计算有广义与狭义之分。广义的云计算是指服务的交付和使用模式，指通过网络以按需、易扩展的方式获得所需服务；狭义的云计算[1-10]是指通过网络获得所需资源，它是以IT为基础的，有按需、易扩展的特点。云计算通过使计算分布在大量的分布式计算机上，而非本地计算机或远程服务器中[4，10]，其可以提供基础设施即服务、平台即服务、软件即服务。

3.2 云计算的应用领域

云计算的应用领域主要有云存储、云备份、云安全。

首先来看一下云存储。云存储是云计算的分支，其通过集群应用、网络技术或分布式文件系统等形式，将网络中不同类型的存储设备集合起来协同工作，以对外提供数据存储和业务访问功能。云存储的实质是一个以数据存储[4-5，7-9，11-13]和管理为核心的云计算系统，只要云计算系统运算及处理的是大量的数据存储和管理时，云计算系统中就少不了要配置大量的存储设备，这时云存储也可被称作云存储系统。一个完整的云存储[11-12]系统由存储层、基础管理层、应用接口层、访问层这样四部分构成，用户通过访问层实现对云存储相应功能的使用。云存储要得以实现，要依赖于宽带网络的发展，WEB2.0技术，应用存储的发展，集群技术、网络技术和分布式文件系统[9]，CDN内容分发、P2P技术、数据压缩技术，存储虚拟化技术、存储网络化管理技术等等这些配套领域的发展。网络硬盘，就是云存储的一个小范围应用。

其次来看一下云备份。云备份是云计算的分支，是指通过集群应用、网格技术或分布式文件系统等功能，将网络中大量各种不同类型的存储设备通过应用软件集合起来协同工作，共同对外提供数据存储备份和业务访问的功能服务。要想实现云备份[4-5，7-9，11-13]，先要整合硬件，即对服务器进行统一管理，然后要有一个坚实的底层支持。云备份侧重于备份的过程，也是数据防灾的一个重要组成部分，被广泛应用于企业及有需要的个人用户之中。

最后来看一下云安全。对于计算机及网络来讲，说到安全大家所能想到的就是密码、病毒、木马、恶意软件等等这些东西，不错，这些都是电脑安全领域的范畴[14]。但是这里将要谈到的云安全不仅包括对这些常规安全的处理，更包括更广泛、更深层的电脑及网络安全领域。先来看一下云安全究竟是什么。云安全亦是云计算技术的一项重要运用，其同云存储、云备份一样，是云计算的分支[15]，它已经在反病毒软件中取得了广泛的应用，并且卓有成效，反病毒软件在与病毒的技术竞争中因为云安全的介入而赢得了先机。云安全通过网状客户端对运行于网络之上的软件进行行为监测，发现有病毒、木马、恶意程序后，传送到服务端进行分析和处理，尔后把解决方案回传到每一个客户端[7]。云安全就是借全网之力来抵御病毒、木马、恶意软件，是一个大网络版的杀毒软件。云安全融合了并行处理、网格计算、未知病毒行为判断等兴技术和概念。云安全让用户感受最深的[7]就是在线杀毒、未知病毒分析及对将病毒库由本地放到服务器，这样大大降低了本地机器的负担，提高了运行效率。云安全目前已被各大安全公司广泛使用，从而使得杀毒软件的功能进一步强大，反病毒的能力越来越强。

4 结 语

从计算机到网络再到云，几十年弹指一挥间。谁也不会想到当初只是美国军方用于计算弹道的计算机以及后来同样为了军事用途而建立起来的互联网会在几十年后的今天如同当看电的发现及灯泡的发明一样对世界、对人们起着举足轻重的作用。历史见证了计算机及互联网的发展，人们也赋予了互联网以云的生动称呼。科学无止境，计算机进入了云时代，但这并不是终点，计算机技术、网络技术，云技术还将不断向前发展。

参考文献

[1] 于巧稚.CEO需要了解的云计算[J].中国建设信息，2012，（06）.

[2] 董日波.基于云计算的高校信息化建设[J].电脑编程技巧与维护，2012，（8）.

[3] 邦慧.云计算在新一代信息技术产业中不是浮云[J].卫星电视与宽带多媒体，2012，（9）.

[4] 初颖.基于云计算架构的移动ADC业务应用研究[D].东北财经大学硕士论文，2010.12.01.

[5] 朱勇.浅谈云计算与图书馆数据中心[J].科技情报开发与经济，2010，（24）.

[6] 任宇宁.云计算时代的存储技术——云存储[J].科技传播，2012，（3）.

[7] 葛晓滨.全球信息化背景下的电子商务发展动态研究[J].计算机与信息技术，2012，（01）.

[8] 张志成.中小学数字化校园应用集成平台研究及其应用[D].重庆大学硕士论文，2011.05.01.

[9] 张迪，霍妍.云计算技术在医院信息化中的应用[J].信息技术，2011，（05）.

[10] 曹沁宇. 浅谈云计算技术在客服系统中的应用[C].2011全国无线及移动通信学术大会论文集，2011.

[11] 苟彦.存储区域网络在联机事务处理下的性能优化及应用[D].重庆大学硕士论文，2011.05.01.

[12] saas_saas模式_金蝶友商网[DB/0L].youshang

[13] 乐静雯.计算机简史[J].科学技术周刊，2009.10.