RPC-DDSF_一种基于RPC的分布式数据共享框架

('RPC-DDSF：一种基于RPC的分布式数据共享框架张磊;张乾石;尚利宏【摘要】设计了一种基于RPC的分布式数据共享框架RPC-DDSF.RPC-DDSF基于SUN公司的ONCRPC框架,采用模块化的设计思想,按照功能分为网络化数据池、数据对象工厂和自动化测试三大模块.通过抽象数据共享应用的特点,在框架中引入配置文件,实现了对共享数据和数据共享规则的可配置性.分析ONCRPC框架中影响数据共享性能的因素,通过实验获得了不同参数下ONCRPC性能的不同表现,从而为框架使用者提供一定的指导意义.【期刊名称】《通信技术》【年(卷),期】2016(049)006【总页数】6页(P745-750)【关键词】分布式数据共享;ONCRPC;远程过程调用;数据池【作者】张磊;张乾石;尚利宏【作者单位】中航工业集团公司西安航空计算技术研究所,陕西西安710068;北京航空航天大学计算机学院,北京100191;北京航空航天大学计算机学院,北京100191【正文语种】中文【中图分类】TN393.0随着计算机技术的发展，计算机的价格越来越低，使用计算机解决的问题也越来越复杂。一台计算机有限的计算能力和存储能力通常无法解决复杂问题。因此，多台计算机组成的分布式系统成为解决复杂问题的常用手段。分布式系统中，各台计算机非完全独立，而是存在数据共享[1]。不同计算机间实现数据共享有多种方式，包括基于socket自定义通信方式以及各种中间件技术[2]，如面向消息中间件[3]和远程过程调用中间件等[4-5]。本文给出了一种基于RPC的提供按名称访问且具有良好可配置性的分布式数据共享框，为分布式系统的开发提供了极大方便。最后，给出了该框架的典型应用模式及该框架的性能调优。1.1RPC-DDSF的模块化结构为了使系统具有良好的可重用性和可维护性，RPC-DDSF采用模块化结构，如图1所示，主要包括数据对象工厂模块、网络化数据池模块、自动化测试模块。RPC-DDSF中三大模块的功能：（1）网络化数据池模块的主要功能。该模块的主要作用是负责数据对象的存储以及不同计算机之间数据对象的传输刷新。数据池中存放的数据对象需要符合一个基类数据对象的定义，并且提供按照数据对象的名称访问数据对象的功能，保证了数据对象访问的时间效率。数据对象的访问规则描述在一个配置文件中。RPC通信模块解析这个配置脚本，维护数据对象的访问规则。网络化数据池模块向外提供统一的按名称访问数据对象的接口函数，并且隐藏访问实现的具体细节。用户可以通过编辑修改访问规则配置脚本文件来更改数据对象的访问规则。（2）数据对象工厂模块的主要作用。该模块在系统中扮演着数据对象生产者的角色。数据对象工厂生产的数据对象具有一定的限制，需要符合数据池中规定的基类数据对象的定义。数据对象工厂模块同样接受一个脚本文件，并根据脚本文件描述的数据对象的信息来构建数据对象。（3）自动化测试模块的主要作用。该模块主要实现日志记录和自动化日志分析功能。测试开发人员通过调用日志记录模块将应用运行过程中的一些关键信息记录在日志文件。自动化日志分析模块可以根据测试目的自动分析日志文件给出分析结果。1.2数据对象远程访问的要素及描述规则的设计数据对象远程访问的要素主要有两方面：数据对象存储的位置和数据对象访问方式。在一个分布式系统中，数据对象往往存储在不同的计算机上。数据对象远程访问首先关心数据对象存储的位置信息。另外，在不同的应用系统中，数据对象的访问存在着不同的实时性要求。对于不需要实时获得数据对象变化的应用场景，适合采用轮询的模式获取数据对象。而对于需要及时反映数据对象变化的应用场景，则适合采用推送的模式，将更新的数据对象推送到关心对应数据对象的计算机上。为了获得更广的应用场景，本文设计的分布式数据共享框架同时支持基于轮询和基于推送的两种数据访问模式。RPC采用C/S编程模式，通过在服务器端和客户端生成的句柄进行交互，交互流程如图2所示[6]。客户端应用首先将调用请求发送给客户端句柄，客户端句柄通过网络将函数调用的请求发到服务器端的句柄，服务器端句柄再将请求传递给服务器端的执行程序，服务器端执行对应函数后将结果返回给服务器端句柄，服务器端句柄再将结果返回给客户端句柄，并由客户端句柄将程序调用的结果传递给客户端的执行程序，从而完成一次RPC请求的处理。对应数据对象远程访问的要素，本文设计了相应的描述规则。对于推送机制维护的数据对象，关心的主要是将哪个对象推送到什么位置。因此，推送机制的数据访问方式采用一个二元组＜name，destination＞来描述。其中，name表示被推送数据对象的名字，destination表示数据对象将被推送到的目标计算机。对于轮询机制维护的数据对象，关心的则是哪个对象按照怎样的时间周期从哪个计算机上轮询。因此，轮询机制的数据访问方式采用一个三元组＜name，timer，source＞来描述。其中，name表示该条轮询机制维护的数据对象的名字，timer表示该条轮询规则关联的定时器，source表示应该从哪台计算机上获得数据对象。为了保证数据对象访问的灵活性，将计算机中维护的数据对象的所有访问方式按照上述的描述规则统一描述在一个脚本文件中（定义这个脚本文件为访问规则配置文件）。当需要改变某个数据对象的访问方式时，只需要修改访问规则配置文件，而不用修改程序中的代码，这极大地提高了系统的灵活性和可配置性。在一个分布式系统中，通常每台计算机都存在与其他计算机的数据交互。因此，每台计算机都需要有一个访问规则配置文件。为了使访问规则配置文件描述的尽量清晰、简洁，将访问规则配置文件中描述的内容分成了四个部分。第一部分描述本机与其他计算机建立RPC通信句柄的相关信息。一台计算机通常与分布式系统中的多台计算机之间存在数据共享，因此需要建立多个RPC通信句柄。每个RPC通信句柄的建立都需要提供IP地址、传输层协议、重传时间和最大重传时间四方面信息。下面介绍这四方面信息的意义。IP地址描述RPC句柄另一端连接的计算机的IP地址；由于ONCRPC的实现支持TCP和UDP两种传输层协议，因此在配置文件中提供了对这两种传输层协议的配置选项，以供开发者灵活使用；重传时间和最大重传时间是ONCRPC协议实现中两个影响RPC传输效率的重要参数，同样提供了可配置性的支持。重传时间表示RPC请求发出后等待响应的时间。如果等待响应的时间超过了重传时间，就会重新发送RPC请求。最大重传时间限制了重传的次数。如果总的请求等待时间超过了最大重传时间，就认定此次RPC请求失败，放弃本次请求。通过增加重传时间和最大重传时间的可配置性支持，使开发者可以根据自己应用的特点灵活设置这两个参数，并且便于测试人员对系统进行性能测试。第二部分描述了通过推送方式维护的数据对象的信息。根据推送模式的二元描述规则定义，在脚本文件中需要描述要推送的数据对象以及推送的目的地。通常，需要向一个目的地推送多个数据对象。为了减少描述信息的重复，在一个推送目的地信息之后，描述向这个目的地推送的所有数据对象的信息。第三部分描述轮询机制中的定时器信息。主要描述本机维护的轮询规则中不同轮询周期的定时器，包括定时器的个数和每个定时器的轮询周期信息。第四部分描述了通过轮询方式维护的数据对象的信息。根据轮询模式的三元描述规则定义，在脚本中需要描述数据对象的名字、轮询对应的定时器和轮询数据对象的存储位置。其中，轮询对应的定时器对应第三部分中描述的定时器。1.3数据池中数据对象访问规则的实现方式脚本解析模块解析访问规则配置脚本生成相应的数据对象的过程如图3所示。由于访问规则配置文件存储在外存中，读写速度较慢。如果每次需要查询某个数据对象的访问规则时都去读取配置文件，将大大降低系统运行的效率。因此，在访问规则实现上，采用一些特定的数据结构来存储访问规则配置文件中的配置信息。这些特定的数据结构包括：（1）存放RPC句柄的顺序表。通过一个顺序表存储与本计算机存在数据交互关系的所有计算机的RPC句柄。访问规则配置脚本中，通过顺序表中的位置来确定跨计算机读写某个数据对象时，应该进行交互的RPC句柄。（2）存放定时器的顺序表。在一台计算机上，不同数据对象的刷新频率可能不同，因此通过一个顺序表来存储不同触发周期的定时器。同样，访问规则配置脚本通过顺序表中的位置来确定某个轮询访问规则应该关联的定时器。（3）存放轮询规则的哈希表。当某个定时器一个时间周期结束时，需要更新关联在这个定时器上所有的数据对象。因此，通过一个哈希表来存储本计算机上所有的轮询规则信息。该哈希表的key是本计算机上的一个定时器对象，value是与该定时器绑定的所有的数据对象，通过一个顺序表来存储。（4）存放推送规则的哈希表。通过一个哈希表存储本计算机上所有的推送规则信息。该哈希表的key是某个数据对象的名字，value是一个列表，存储关心该数据对象的所有计算机的RPC句柄。当某个基于推送机制的数据对象发生变化时，需要通过该数据结构将新的数据对象推送到所有关心该数据对象的计算机上。在分布式系统中的计算机启动时，读取访问规则配置文件，将配置文件传递给脚本解析模块进行解析，并将其中的访问规则信息存储在相应的数据结构中。数据对象的共享访问就可以通过这些特定的数据结构来进行维护，而不必每次从外存中读取配置文件。分布式系统中每台计算机都有且只有一个物理上的数据池存储数据对象。按照功能不同，数据池从逻辑上可分为存储池和缓存池。存储池负责存储数据对象的正本，缓冲池存储数据对象的副本。某一时刻，任意数据对象的正本只能存在于一台计算机上，但是该数据对象可以有多个副本。每个需要用到该数据对象的计算机的数据池中都可以存储该数据对象的一个副本。缓冲池中数据对象的副本必须按照存储池中同名数据对象的正本进行刷新。本文设计的数据池既可设计C/S架构的应用也可设计P2P架构的应用，同时还可构建两种架构混合的应用。2.1基于C/S架构的应用模式基于C/S架构的应用，存储池只存在于作为服务器端的计算机上。所有的数据对象正本都存储在作为服务器端的计算机的数据池中，其他计算机作为客户端。客户端中的数据池在逻辑上都是缓存池。客户端通过RPC协议从服务器端的数据池中获得数据对象的正本，并缓存在本地数据池中。客户端对缓冲池中某个数据对象的更改，都会更新到服务器端的存储池中，再由服务器端更新其他计算机缓冲池中数据对象的副本，或由其他计算机通过轮询机制从服务器端获得最新的数据对象。C/S架构下推送访问方式的原理见图4，其优点是客户端访问规则配置脚本编写简单，缺点是数据对象更新较慢。2.2基于P2P架构的应用模式基于P2P架构的应用，每个计算机都可存储并维护分布式系统中数据对象的正本，也可存储本节点机应用层关心的数据对象副本。因此，数据池在逻辑上既包括存储池也包括缓存池。当某个计算机更新数据对象时，可以直接根据访问规则配置脚本中描述的规则，将最新数据对象推送到对应的计算机或者等待关心改变后数据对象值的计算机来轮询。P2P架构下推送访问方式的实现原理见图5，其优点是推送模式下数据对象更新快，缺点是访问规则配置脚本编写复杂。2.3混合架构的应用模式混合应用模式是C/S架构应用模式和P2P架构应用模式的结合。在整个分布式系统中，一部分计算机维护着C/S架构，一部分计算机维护着P2P架构。混合架构下推送访问方式的实现原理见图6。系统设计中，主要根据应用特点决定分布式系统中计算机采用的架构形式。一个分布式数据共享框架，使用者关心的性能参数主要包括实时性、重传占比和有效吞吐量。本文设计的分布式数据共享框架基于ONCRPC，数据对象传输由ONCRPC完成。因此，上述三方面性能由ONCRPC决定。实时性可通过从RPC请求发出到获得RPC响应的最长时间来刻画。ONCRPC中，RPC请求一段时间内没有收到回复会重新发送请求。重传占比表示系统运行一段时间中作为重传的RPC请求占总的RPC请求的比例。重传占比反映了网络传输的效率。重传占比越大，表示越多的RPC请求是无效请求，网络资源利用率也越低；反之则越高。有效吞吐量表示单位时间内完成RPC请求的数量，表明计算机在特定测试环境下处理RPC请求的能力。在ONCRPC中，上述三方面性能的好坏主要由重传时间这个参数决定。重传时间表示一次RPC请求发出后多长时间内没有收到回复会重新发出请求。3.1测试环境设置在现有测试环境中，通过在一台计算机上生成30个线程来模拟30个RPC客户端，用另一台单独的计算机作为RPC的服务器端。两台计算机的软硬件配置如表1所示。设置RPC请求的频率为1.25ms一次来保证足够的RPC请求。3.2实时性测试不同重传时间下，系统实时性的表现见图7。可见，随着重传时间的增大，最差情况下RPC请求的处理时间逐渐增大，即系统实时性逐渐变差。因此，当系统对实时性要求较为严格时，应该设置一个较小的RPC重传时间，以获得较好的实时性。进一步分析，当重传时间设置为5ms时，客户端RPC请求处理的最差时间是48ms，说明最差情况下的RPC请求重传9次才完成了RPC请求处理；当重传时间设置为100ms时，客户端RPC请求处理的最差时间是204ms，说明最差情况下RPC请求重传2次就完成了RPC请求处理。通过对比发现：设置重传时间为5ms，虽然获得了较好的实时性，但是出现了大量重传；设置重传时间为100ms，虽然实时性较差，但是最差情况下的重传次数较少。通过计算可以求得，设置不同重传时间时，最差情况下RPC请求重传的次数如表2所示。通过表2可以看出，随着重传时间的增大，最差情况下的重传次数逐渐减小。当重传时间增大到一定值时，最大重传次数趋于稳定。因此，当应用关注于网络资源利用率时，应该选择一个较大的重传时间。3.3重传占比测试在重传占比性能测试过程中，首先对不同重传时间设置下重传次数的分布进行测量。若某次RPC处理的时间小于重传时间，说明该次请求没有进行重传；如果该次请求的时间大于重传时间但是小于两倍的重传时间，说明该次RPC请求重传了一次。依次类推，可以获得测试结果中关于重传次数的信息。不同重传时间下重传次数所占比见表3。根据重传占比的概念及上述测得的不同重传时间下重传次数的分布，可获得不同重传时间间隔下总的重传占比分布，见图8。从图8可见，随着重传时间的增大，总的重传占比逐渐减小并趋于稳定。因此，要高效利用网络资源，需选择较大的重传时间。3.4吞吐量测试吞吐量反映了单位时间内RPC请求被处理的次数。当前测试环境下，设置不同重传时间获得的吞吐量分布如图9所示。测试结果表明：当重传时间的取值在50ms到100ms之间时，影响吞吐量的主要因素是重传时间。因为重传时间越大，当某次RPC请求未得到响应时，需要等待的时间越长。但是，当重传时间取值在20ms到50ms之间时，结合重传占比的分布可以发现，吞吐量的取值则主要由系统重传占比的情况决定。因为重传占比越大，意味着越多的RPC请求是无效请求。当重传时间小于20ms时，吞吐量的取值重新变成由重传时间来决定，且吞吐量逐渐趋于稳定。分布式数据共享是当前解决复杂问题采用分布式系统的一个通用问题。本文提出的基于RPC的分布式数据共享框架具有良好的可配置性，能够很好地适应需求不确定的应用场景。最后，本文提供了RPC-DDSF性能调优的方法及一种测试环境中的结果，结果对框架的使用者具有一定的指导意义。张磊（1984—），男，学士，工程师，主要研究方向为总线技术、实时系统；张乾石（1991—），男，硕士，主要研究方向为嵌入式系统；尚利宏（1971—），男，博士，副教授，主要研究方向为嵌入式系统、容错系统。【相关文献】[1]KhanRZ,AliMF.AnEfficientDiffusionLoadBalancingAlgorithminDistributedSystem[J].InternationalJournalofInformationTechnology&ComputerScience,2014,6(08):65-71.[2]QilinL,MintianZ.TheStateoftheArtinMiddleware[J].InternationalForumonInformationTechnologyandApplications-Volume,2010(01):83-85.[3]TranP,GreenfieldP,GortonI.BehaviorandPerformanceofMessage-orientedMiddlewareSystems[C].IEEE:InternationalConferenceonDistributedComputingSystemsWorkshops,2002,7(02):645-650.[4]WangX,ZhaoH,ZhuJ.GRPC:ACommunicationCooperationMechanisminDistributedSystems[J].OperatingSystemsReview,1993,27(03):75-86.[5]ChenH,ShiL,SunJ,LiK,etal.AFastRPCSystemforVirtualMachines[J].ParallelandDistributedSystems,2013,24(07):1267-1276.[6]SrivastavaS,SrivastavaP.K.PerformanceAnalysisofSunRPC[C].Bangalore:NationalConferenceonParallelComputingTechnologies,2013:1-8.',)