张以利,杨万扣
移动和频繁断连是移动设备特点之一,利用移动设备自身计算和存储能力,可缓存服务器中部分“热点”数据,当客户端因断连或网络拥塞而与服务器“失联”时,在本地即可找到所需数据。但当服务端数据更新时,客户端缓存会出现由于未及时更新而与服务器不一致等问题[1]。
移动缓存一致性维护问题是当前研究热点之一。目前最有代表性算法,是带有时间戳的广播算法(Broadcasting Timestamps Strategy,BTS),服务器每隔一个时间段,向客户端发送一个包含更新数据的失效报告(Invalidation Report,IR),用以更新缓存。但是,BTS算法基于C/S模式,当服务器数据更新时,需通知每一客户端并等待确认,服务端会因为客户端无法及时确认而产生“写延迟”,客户端的频繁断接还会加剧“写延迟”;客户端不允许断接,一旦断接就会始终处于重连等待状态;客户端每次断接重连后需重新验证缓存;这些都会影响客户请求响应速度及网络通信开销。
移动云计算是移动互联网和云计算相结合的新技术;Agent具有主动性和智能性,适合在异构开放环境中提供中间件服务,在减少网络“延迟”、支持轻载移动设备方面具有不可比拟的优越性[2],而移动设备具有移动性、计算能力弱、存储空间小、电池容量小特点。因此,移动缓存技术同移动云技术和Agent技术具有天然的匹配性。
移动云环境中基于 Agent的缓存一致性维护策略(Cache Consistent Maintenance Scheme Based on Agent in Mobile Cloud Environment,CSC),针对传统算法中存在的服务端“写延迟”及终端断接操作,结合移动云技术、Agent技术及缓存技术,搭建三层结构移动云平台,并在中间层建立数据缓存,利用中间层协调客户端与服务端关系,通过移动代理来维护“双缓存”一致性。实验结果表明,该策略能够有效解决“写延迟”和终端断接操作及断接重连后的一致性验证问题,并能提高客户请求响应速度、减少网络通信开销。
移动云环境中基于 Agent的缓存一致性维护平台(Cache Consistent Maintenance platform Based on Agent in Mobile Cloud Environment,CPCE),是借助移动云技术、Agent技术及缓存技术搭建起来的三层结构移动云平台,在云平台的中间层开辟大缓存空间并建立缓存状态信息列表,利用中间层对缓存数据进行备份和一致性维护,有效解决服务端“写延迟”问题,同时支持终端频繁断接,提高终端访问请求的响应速度,减少数据通信开销。CPCE平台结构图,如图1所示:
图1 移动云环境中基于Agent的语义缓存维护三层结构模型
Agent具有主动性与智能性特点,能减少网络“延迟”、支持轻载设备。CPCE平台中的Agent有静态Agent和移动Agent两种类型,实行统一标识、统一命名管理,采用“黑板报”通信机制,平台中的Agent之间互相“协商”,共同完成缓存一致性维护的任务[3]。
定义1 CPCE平台的Agent模型
CPCE平台的Agent模型定义为5元组如公式(1):
ID属性用以标识CPCE平台的Agent唯一性,一个节点可以存在一个或多个 Agent,故ID由所在中心服务器号(Central Server)、小区服务器号(Cell Server)及本地序号共同组成;Type属性标识Agent类型;state标识Agent当前工作状态是否忙;currPara描述Agent当前资源共享情况及历史信息;policy是Mobile Agent的任务策略属性,Agent根据自身情况及相关环境参数,确定是否进行迁移以及往何处迁移。
静态Agent有Process Agent、Service Agent和Monitor Agent 3种类型,分布在客户端、服务端及中间层,负责处理所在层的相关事务。
移动agent为Mobile Agent,在中间层移动并执行任务,也可以移动到其所对应的客户端执行某种任务,同时与其所对应的静态Agent进行协商,以协调客户端与服务端关系,共同完成管理并维护缓存的任务。Mobile Agent在CPCE平台中的运行机制,见图1。
Agent采取“黑板报”的通信机制。“黑板报”为在云服务器内开辟的一块为全局共享内存区域,是标识平台内Agent及节点信息的“目录表”,每个Agent主动向“黑板”上“张贴”或“读取”相关信息。“黑板报”上的信息,是Mobile Agent行动决策的依据之一。
CPCE平台是由服务端、客户端、中间层以及Agent系统构建而成的三层结构移动云平台系统[4]。服务端由中心服务器(Central Server)、Monitor Agent和 Process Agent组成,可以存放客户端所需数据,并有中心控制作用,有线连接多个本地服务器(Cell Server),属于云中心服务器。Monitor Agent对“热点”数据进行周期性广播,并由中间层进行数据的接收;Process Agent接收来自中间层的Monitor Agent的查询请求。
客户端由移动终端(Mobile Terminal,MT)、Monitor Agent和 Service Agent组成,MT无线接入到本地服务器(Cell Server)中,中间层为每个移动终端创建一个Mobile Agen(移动代理),用来代替移动终端处理相关事务。Monitor Agent负责接收来自中间层的广播数据并更新缓存,Service Agent负责提交客户端的查询请求并接收来自中间层或服务端的查询结果。
中间层由本地服务器(Cell Server)、Monitor Agent、Process Agent及若干Mobile Agent组成。Cell Server有固定移动通信网关接口功能,发送的信号覆盖的范围称为一个“小区”(Cell),一个 Cell Server无线连接若干 MT。Monitor Agent接收服务端的广播数据并更新缓存,向客户端广播更新数据,Process Agent处理来自客户端的查询请求。
Cell Server为其“辖区”范围内的每个移动终端创建一个移动代理Mobile Agent,该Mobile Agent可以移动到其对应的客户端并执行某些事务;同时,当移动终端从一个“小区”移动到另一个“小区”时,与其对应的 Mobile Agent也要相应移动到其对应的移动终端所在 “小区”的 Cell Server中,Mobile Agent紧紧“跟随”移动终端,随着移动终端来回“穿梭”于各个“小区”。Mobile Agent实行“属地管理”机制,接受所在“小区”的管理[5]。
基于移动终端及移动云端在计算和存储能力方面各自特点,CSC策略采取“双缓存”机制,考虑在移动终端和CPCE三层结构云平台的中间层开辟缓存[6]。移动终端缓存,是利用移动终端自身的处理和存储能力而开辟的一块存储空间以缓存部分“热点”数据,可提高数据访问速度、减少网络拥塞。
考虑到移动终端计算能力弱、存储空间小、电池容量小等特点,CSC策略利用移动云存储,在CPCE平台中间层开辟大缓存空间,用以缓存终端热点数据。在CPCE平台中间层Cell Server中建立的缓存里,每个客户端都有对应的备份,并建立一个云端缓存区号,且由“Cell缓存状态信息列表”记录相应信息。移动终端与其相应的“Mobile Agent号”、“云端缓存区号”以及“Cell缓存状态信息列表号”一一对应。
定义2 Cell缓存状态信息列表
Cell缓存状态信息列表,记录中间层缓存状态信息,存放于 CPCE三层结构云平台中间层的缓存中,每一个 Cell缓存状态信息列表对应中间层一块缓存区,由 Cell Server中的 Monitor Agent维护并管理,可以被其对应的 Mobile Agent携带,“游离”于其所在的Cell Server及其相应的移动终端,还可随着移动终端的移动而“穿梭”于各个“小区”。Cell缓存状态信息列表cachTabl定义为五元组[7]:invaFlag属性为数据项失效标志,starLog属性为记录脱机事务日志启动与否的量。offTimeMobi为记录客户端与 Cell Server断接时间长度。counter记录客户端在某段时间内的访问次数平均值,是数据访问热度标志,是Cell缓存数据换出换入的依据。
中间层 Cell Server与其中的 Monitor Agent、Process Agent及Mobile Agent,起到协调移动客户端与服务端的作用,负责监控、管理、维护缓存以及接受移动客户端数据请求,维护移动终端缓存数据的一致性。
考虑到空间资源利用率,CSC策略根据Cell缓存状态信息列表的相关记录参数,实现缓存数据“换入换出”的动态机制,“换人”移动客户端近期常访问的“热点”数据,“换出”那些长期未访问过的较“旧”的数据。
CSC策略,搭建三层结构移动云平台并构建“双缓存”,利用中间层对缓存数据进行备份和一致性维护,既减轻移动终端负担,又达到了数据强一致性,并支持移动终端频繁断接。
客户端事务驱动缓存一致性维护,是由客户端查询请求事件驱动发起,是客户端的MT及其Agent与中间层交互并维护客户端缓存与中间层缓存一致性的过程[8]。
移动客户端的Monitor Agent可对网络连接进行实时监听。当客户端有数据查询请求时,如果客户端处于联机状态,则客户端的Service Agent启动联机事务,如果客户端处于断接状态,并且断接时间offTimeMobi大于服务器广播时间间隔cellServBroaInte,则Service Agent启动断接事务,若这时Monitor Agen监测到客户端由原来的断接又重新联机,这种由断接到联机的状态,称为物理重联机状态,则 Service Agent立即启动集成事务,而后客户端就进入正常联机状态运行。下面分别介绍这3种事务。
客户端联机事务。当客户端有数据查询请求并检测到处于网络联机状态时,其中的Service Agent将发送信息到该客户端所在“小区”的本地服务器Cell Server,Cell Server接受该信息并验证时间戳,如果仍是时间戳TS0,则表明数据很“新”,则直接在MT端执行操作,如果时间戳过期,此时要执行一致性维护,返回中间层缓存“最新”数据,同时保存时间戳并更新Cell缓存状态信息表。如果中间层缓存数据不是“最新”,则直接到Central Server中查找并返回数据。
客户端断接事务。当客户端有数据查询请求而这时却处于断接状态,移动终端会因无法连接服务器而得不到最新数据,此时移动终端缓存便充当“临时服务器”角色。实际上,多数情况下客户端并不一定必须要最新数据,只要偏差在一定范围内也是可以忍受的。CSC策略采取,当断接时间offTimeMobi小于cellServBroaInte时,视作客户端缓存有效;当断接时间offTimeMobi大于cellServBroaInte时,则启动断接事务执行程序。
执行断接事务程序时,客户端的Service Agent在移动终端缓存执行暂态事务,并记录暂态事务日志,等待重新联机时与移动到终端的Mobile Agent携带过来的Cell缓存状态信息列表融合,再根据融合结果更新客户端缓存。CSC策略允许客户端在断接状态工作,无论断接时间长短都有相应方案,而 BTS等传统策略只允许连机状态下工作,一旦断接就一直处于重连等待状态中。
客户端集成事务。当客户端有数据查询请求,且此时处于断接状态的客户端又再次联机时,监控网络连接状态的客户端Monitor Agent会通知中间层,这时,与该移动终端对应的中间层Mobile Agent,会携带Cell缓存状态信息列表移动到客户端,同客户端Service Agent进行协商,将Cell缓存状态信息列表与断接状态时记录的暂态事务日志进行融合,如果发生冲突,则对相应的暂态事务回滚并提交,同时更新客户端缓存[8]。
服务端事务驱动缓存一致性维护,是由服务端数据更新事件驱动发起,是服务端的云中心服务器及其Agent与中间层交互并维护中间层缓存与服务端一致性的过程[9]。
服务器端驱动语义缓存一致性维护算法,如算法1:
算法1 服务器端驱动语义缓存一致性维护算法
当中心服务器 central server有数据更新时,其中的Monitor Agent将更新通知发送给缓存了该数据项的中间层Monitor Agent,当中心服务器接收到中间层确认信息后,即可更新中间层缓存数据并将相关信息连同时间戳一同保存在Cell缓存状态信息列表中。
在传统的两层结构中,中心服务器将更新数据消息直接发送给移动客户端并等待确认,这时,服务端可能会由于断接而无法及时得到客户端确认,进而出现服务器“写延迟”问题。而在CSC策略中,中心服务器更新的数据不是缓存在移动客户端,而是在本地服务器,由于中心服务器与本地服务器有线连接,因此,不会出现“写延迟”问题,并且终端断接重连后不需要进行一致性验证。
传统算法中,服务端采取每隔一个时间段发送包括所有被修改标识的失效报告给客户端,当终端断接时间超过失效报告时长时,必须将缓存全部失效。终端重连后,服务端收到客户端发送过来的所有数据请求,都以广播方式将数据发送到客户端。显然,这会大大增加网络通信开销。
CSC策略,搭建CPCE三层移动云平台,建立“双缓存”,利用中间层为终端提供缓存备份并协助终端进行缓存一致性维护。中间层对缓存数据更新操作,是更新数据序列操作,而不是发送失效报告来笼统更新全部数据。当终端要恢复缓存有效性时,或者有数据查询请求时,只需要访问中间层缓存中的更新序列并执行,即可达到客户端缓存与服务端数据一致性的目的。这就是CSC策略缓存数据“粒度”更新方法。
因此,这种CSC策略缓存数据“粒度”更新方法,较BTS等传统失效报告方法,会大减少网络通信开销和缓存一致性维护的时间开销。
仿真实验任务:验证CSC策略能够有效解决服务端“写延迟”和终端断接操作及断接重连后的一致性验证问题,并能提高客户请求响应速度、减少网络通信开销。
对比试验为:带有时间戳的广播算法(BTS)。
仿真实验构建三层结构移动云平台:云中心服务器Central Server一台为服务端,有线连接3台本地服务器Cell Server为中间层,这些机器均采用Pentium P6100 2.00GHz处理器,内存2GB,操作系统WindowsXP Professional,每台本地服务器无线连接4台移动终端为一个“小区”,采用java语言编程,云平台Hadoop,IBM Aglet SDK实现CPCE平台的Agent系统[10]。仿真实验各项参数,如表1所示:
表1 仿真实验各项参数
CSC和BTS两种策略在“写延迟”方面的性能对比,如表2所示:
表2 两种策略在“写延迟”方面的性能对比
由表2可以看出,在CSC策略中,服务端不会出现“写延迟”问题,并且客户端移动、断接时对“‘写延迟’增加与否情况”均无影响。而 BTS策略的情况则完全不同。这是因为,CSC策略采用三层结构移动云平台,服务端修改数据的通知不再发给客户端,而是发给缓存了该数据项的中间层服务器 Cell Server,由中间层服务器给服务端发回确认。而BTS算法采用两层结构,增加了这种“写延迟”。由表2可以看出,CSC策略允许终端断接操作,而BTS策略则不允许。这是因为CSC策略允许客户端在断接状态下工作,根据断接时间长短启动相应运行程序。而 BTS等传统策略只允许连机状态下工作,一旦断接就一直处于连接等待状态。由表2还可以看出,CSC策略在终端断接重连后不需要一致性验证,而 BTS策略必须要一致性验证。这是因为,CSC策略采用三层结构移动云平台,服务端的写操作由 Central Server与中间层的Cell Server交互完成,不需要客户端参与。
仿真实验三层结构移动云平台,有3个“小区”,无线连接终端12台。实验时,对12台移动终端做记录并取平均值。横轴为“移动终端断接的平均时间”,纵轴为“访问缓存数据的平均响应时间”。两种策略在客户端断接重连后访问请求的响应时间对比,如图2所示:
由图2可看出,CSC策略的平均响应时间远低于BTS算法的平均响应时间,即提高了客户请求响应速度。这是因为,服务器广播失效报告时间间隔为50s,对于CSC策略来说,只要是移动终端断接时间小于cellServBroaInte,终端缓存就被认为有效,因此直接访问终端缓存。如果大于cellServBroaInte,启动客户端断接事务执行程序,在客户端执行暂态事务,当重新连接后,启动客户端执行集成事务,要将暂态事务同 Cell 缓存状态信息列表融合并回滚事务,实际上大部分数据无需更新。而 BTS算法,只要离线且无论离线时间长短,重新连接后都要进行一致性验证,因此响应时间较大。
由图2还可看出,随着离线时间的增大,响应时间不断增大,因为,离线时间越长,需要更新数据就会越多,缓存更新时长都会增大,因此响应时间就会增大。
选取在客户端缓存中从50到500个待更新的元祖数据进行一致性维护。两种策略产生的数据通信开销对比,如图3所示:
由图 3可以看出,CSC策略的数据通信开销明显低于BTS策略。这是因为,BTS策略在断接重连后必须进行一致性验证,尤其是网络拥塞情况下,频繁断接时常发生,这无疑增加通信开销。当断接时间长于服务器广播时间时,再次联机就无法根据发送的失效报告来处理缓存有效性问题。而CSC策略,在断接重连后不需要一致性验证。因此,产生较少的网络通信开销。同时,BTS策略的更新操作是,先在缓存中执行DELETE操作,再将执行SELECTE操作得到的更新元组放入缓存,把修改个别属性值就达到目的的操作变成了整个元祖操作。而CSC策略,采取的是“粒度”更新方法,是“个别”操作。因此,产生较少网络通信开销。
移动云环境中基于Agent的缓存一致性维护策略,在构建基于Agent的三层结构移动云平台基础上,根据移动终端及移动云存储特点建立“双缓存”,同时,利用中间层维护管理缓存并协调客户端与服务端关系,通过移动代理来维护“双缓存”一致性。该策略解决了传统算法中存在服务端“写延迟”和断接操作问题,提高客户请求响应速度、减少网络通信开销。因此,CSC策略非常适用于终端频繁移动、断接的无线网络计算环境。下一步,将进一步研究移动云环境中基于多Agent的移动终端在“小区”间频繁切换时的代价最优问题。
[1] 田雪颖,刘衍珩,孙鑫.一种动态的移动社交网络拓扑模型[J].计算机工程,2014,40(9):124-129,142.
[2] 张以利,杨万扣,李峻.基于移动Agent的代价驱动的云端存储模型[J].计算机工程与设计,2012,33(11):4240-4244.
[3] 刘晓茜.云计算数据中心结构及其调度机制研究[D].合肥:中国科学技术大学,2011.
[4] 王素贞,杜治娟.基于移动Agent的移动云计算系统构建方法[J].计算机应用,2013,33 (05):1276-1280.
[5] Iosup A, Ostermann S, Yigitbasi M N. Performance Analysis of Cloud Computing Services for Many-tasks Scientific Computing[J].IEEE Trans. on Parallel and Distributed System.2011,22(6):931-945.
[6] 孙一杰,张国良,张胜修.一类异构多智能体系非线性协议下的一致性分析[J].计算机应用,2015,35(1):136-139.
[7] 茹蓓,肖云鹏,张俊鹏.基于Agent的移动Web服务集成方案[J].计算机工程,2012, 38(9):49-50,54.
[8] 梁茹冰,刘琼.移动计算环境中基于agent计算的语义缓存一致性验证方法[J].计算机科学, 2014,41(3):132-136.
[9] 李娟妮,华庆一,姬翔.移动环境中任务分析及任务建模方法[J].计算机科学, 2014,41(10):210-215.
[10] Mell J, Grance T. The NIST Definition of Cloud Computing[EB/OL].http://csrc.nist.gov/publications/drafts/800-145/Draft-SP-800-145_cloud-definition.pdf,2011.