论文投稿_医学论文投稿_核心期刊,职称论文投稿发表_论文部落

　　事务组件负责支持分布式事务内存编程范式，并保证其正确性。为使所有读事务不被撤销，需要解决两个问题：①建立系统全局快照，使所有内存事务的读操作可以从数据项的多个版本中选择合适的一个；②为写事务在提交阶段建立全局串行化以保证事务性。

　　TMC基于两阶段提交算法[6]（2PC）和文献[7]中的方法解决上述两个问题。为了正确地实现事务串行化，事务组件会在每个Txi的读操作后更新其nextID属性。如果Txi的节点接收到了来自另一个事务Txj的读请求并且Txj.ts>Txi.nextID，则推进Txi.nextID至Txj.ts。

　　3.1内存事务的读写操作

　　TMC采用延时读写策略，事务Txi执行写操作时先将要写入的数据项do保存在Txi的写集合ws中，Txi.ws只有在提交阶段时才对外可见。Txi对数据项do的读操作则分为本地读（来自Txi）和远程读（来自Txj）两种类型。本地读如算法1。

　　4存储组件

　　存储组件以云的形式向事务组件（也可以直接面向最终用户）提供数据存储服务。从用户角度来看，所有的读写操作只针对一个数据副本，数据一致性和可用性、系统可扩展性由存储组件透明地实现。TMC中的存储组件是一群相互依存的服务集合，共同实现系统设计目标，如图3所示。

　　Locator服务将数据项id映射到数据中心，Router服务将消息转发到节点，Allocator服务决定存放数据项及元数据的节点，Selector服务选择存放数据副本的数据中心，MetaData与RawData服务用于存储元数据和数据值，Logger服务记录针对每个数据项的操作。

　　4.1存储组件的扩展性

　　TMC存储组件的设计目标之一是系统吞吐量与容量同系统节点数之间成正比，即具有良好的可扩展性。为实现这个目标，课题组首先在前期工作基础上[8]，采用机架选举和多路线性散列算法，将工作负载均匀地分布到不同的数据中心以及每个数据中心的内部节点，该过程不需要“中心节点”来管理，全体数据中心和节点各司其职，防止了系统瓶颈的产生。

　　为进一步增强扩展性，存储组件的另一个设计目标是将元数据（包括位置、大小、副本信息等）与数据项本身解耦，具体实现上采用了层次化的设计方法。最上层是定位层，在访问每个数据项时，均需通过Locator服务计算出存储其元数据的数据中心，为提高可用性，元数据也被多处存储（见图1），并使用强一致性协议同步，Locator从多个副本中根据预设策略（例如距离）选择合适的元数据。

　　存储组件第二层是操作层，由MetaData服务负责处理数据项的创建与删除，并确保数据项与其id属性间的一一对应。

　　存储组件的最下层是数据层，其中的Allocator服务根据数据项id计算其元数据和数据值的存储节点；Router服务负责接收来自用户或其他数据中心的请求，并将其转发至相应节点。本文假设所有数据中心均具有一定的稳定性，每个数据中心均有一张全局成员信息表。每当增加或移除一个数据中心时，需要更新所有信息表。

　　4.2数据一致性

　　因为从用户角度来看，所有读写操作只针对一个数据副本，所以需要使用数据一致性协议来更新其他副本。存储组件共实现了三种数据一致性协议[6]供用户在创建数据项时自由动态地选择，见表1。

　　5实验

　　实验的主要目的是为了验证TMC能适用于读密集型的云计算应用，同时也应具备良好性能和高可用性。本文利用澳大利亚墨尔本大学的开源系统CloudSim[9]作为测试平台来模拟云计算环境，课题组实现了TMC原型及相关算法，并集成到CloudSim中。实验机器的软硬件配置为Windows764bit+四核IntelCorei52.53GHz+内存4GB。

　　本实验选用了TPC-C作为测试基准和数据集，TPC-C是专门针对联机交易处理系统（OLTP）的面向事务处理与数据库性能的测试标准，可在其中模拟比较复杂并具有代表意义的OLTP应用环境。实验的比较对象包括另一种典型分布式事务内存系统GenRSTM[10]和MySQL集群。实验结果如下。

　　图4所示吞吐量实验中，首先通过CloudSim模拟出了五个数据中心，所有节点随机均匀地分布其中，再将TPC-C测试集中的只读事务比例设置为80%。对于MySQL，创建一张包含id和value字段的临时表，将记录作为数据项存取。从实验结果中可看出，三个系统的吞吐量均可随着节点数增多而线性增长，但在以读任务为主的环境下，TMC的优势更为明显。同时由于日志记录等磁盘操作的影响，MySQL在读密集环境下的吞吐量明显低于另外两种事务内存系统。

　　6结束语