一种基于云的应用层容错机制设计与实现

于翔，叶德建



一种基于云的应用层容错机制设计与实现

于翔，叶德建

摘 要：针对高一致性应用的场景，基于云平台中间件提供的支持，从业务特性出发，设计了一种与数据层异步复制技术相结合的应用层容错机制，该机制保存状态数据的快照，在数据层异常时对未达到最终一致的状态数据进行访问控制，并允许其他状态数据继续进行业务操作。实验证明，该机制在保证数据一致的前提下，有效缩短了系统的故障切换时间，提高了系统整体的可用性，并对系统吞吐量不造成太大影响。

关键词：云平台中间件容错机制一致性；可用性

0 引言

分布式关系型数据库是云存储的重要组成部分，目前其主流架构是基于非共享存储的主从式分库分表结构，基于业务特征进行分库分表使其具备良好的水平扩展能力，同一分库通过主从复制技术实现数据冗余，并通过主备切换保证高可用性。

CAP理论指出，对于具有分区容错性的分布式系统，可用性和一致性不可兼得[1]。其中，可用性是以系统服务的可用时间来衡量，如99.999%可用的系统在一年内服务不可用时间不超过5分钟[2]；一致性是指数据各副本之间保持一致，对于“单点写、多点读”的主从式架构而言，分为强一致性和最终一致性[3]。

文献[4]指出分布式数据库主从之间的复制技术分为同步复制和异步复制。同步复制是指一次事务操作将主备库所有的数据副本均更新成功后返回客户端操作成功，副本之间保持强一致性，当主库故障时，由于主备完全一致，可实现主备快速自动切换，但当备库不可用时，事务只能回滚，因此事务成功率较低，并且由于同步复制一般采用严格的两阶段加锁协议或PAXOS协议，因此系统的吞吐量较低，且会随着同步副本数量的增多而进一步降低；异步复制是指一次事务操作将主库数据更新成功后即返回客户端操作成功，备库从主库异步复制事务日志并执行，副本之间保持最终一致性，当备库不可用时，事务可正常提交，异步复制的吞吐量高，且与副本数量无关，当主库故障时，备库更新进度落后于主库，主备切换要考虑上层应用能否接受主备数据不一致，如果能够接受，则可实现快速自动切换，否则，必须使备库与主库的事务日志完全相同，并等待备库执行日志完毕后才可切换，但主库事务日志在主库不可用时一般无法访问，因此切换难以实现自动化，需要DBA手动重启主库获取日志并完成操作，切换时间大约在分钟级。

针对高一致性的应用场景，如金融、电信等行业，两种复制技术各有不足之处，同步复制过于注重一致性而牺牲了可用性和吞吐量，异步复制的主备切换时间长且需要人工干预。本文针对金融行业中常用的计费系统，从业务特点出发，在应用层设计了一种基于云中间件的容错机制，并与数据层异步复制技术相结合，当主库不可用需要进行主备切换时，应用层能够在业务允许的范围内对未达到最终一致的业务数据进行访问控制，并允许其他业务数据进行正常操作，直至主备切换完成，从而在保留异步复制优点的同时，极大缩短了系统整体的不可用时间。本文对其他具有相似需求的系统容错机制设计也给出了一般性的建议。

1 云平台中间件支持

传统的应用系统设计一般分为应用层和数据层，应用层负责执行业务逻辑，数据层负责业务数据模型的存储。随着云计算技术的发展，云中间件作为基础支撑技术为应用层提供了强大的功能支持和稳定性保证。下面对计费系统应用层容错机制所需的基础中间件进行介绍：

（1）可靠消息队列RocketMQ

RocketMQ是阿里巴巴开源的分布式可靠消息队列，利用磁盘顺序读写快的特性，持久化存储消息，支持集群并发消费，吞吐量高，保证每条消息至少成功消费一次，消费失败的消息存储在重试队列中，RocketMQ定时扫描该队列进行重试消费，直至消费者返回成功。

RocketMQ提供两阶段事务性消息机制，允许应用层同时操作关系型数据库和消息队列。在数据库事务中发送消息分为两个阶段：一阶段发送Prepared消息，该消息存储在队列中，但不会被投递给消费者；二阶段是在事务结束后，根据事务结果发送Commit或Rollback消息，表示确认或取消发送。如果Prepared消息在指定时间间隔内未收到确认或取消命令，RocketMQ会将该消息发送给生产者进行回查，生产者查询消息对应的数据库事务执行结果并重新发送Commit或Rollback消息。RocketMQ通过两阶段消息与回查机制有效地防止悬挂消息的产生。

（2）分布式内存集群缓存Memcache

Memcache是基于一致哈希算法的分布式缓存中间件，存储的数据结构为键值对，允许设置数据的过期时间，数据保存在内存中，读写速度快，集群中的节点构成分布式哈希表，当某个节点不可用时，相邻节点代替该节点进行读写操作，但不可用节点上的数据会丢失，即在同一个集群内没有数据的备份，冗余备份可通过将数据写入多个集群的方式来实现。

Memcache对外操作接口均为原子性方法并提供加锁机制控制同一键值对的并发操作：Add方法在主键冲突时保证只有一条数据插入成功，控制并发插入；Gets和Cas（compare and set）方法通过乐观锁机制控制并发更新，Gets方法返回数据项的当前值及其对应的唯一标识，该标识在数据项每次更新后会改变，客户端使用Cas方法更新数据时，需要将之前Gets方法获取到的标识作为参数传入，如果该参数与数据项当前唯一标识相等则进行更新，否则更新失败。

（3）应用程序管控平台JManage

JManage是基于JMX（Java Management Extensions）技术的Java应用程序管控平台，JMX技术可以在程序运行时查看并动态修改内存变量的取值，从而动态调整应用程序的运行情况，如调整线程池的最大线程数、连接池的最大连接数以及其他应用程序的自定义变量。程序中被管理的对象称为MBean（Managed Bean），所有MBean统一注册到Java虚拟机中的MBean服务器，MBean服务器对外提供接口，JMX客户端通过该接口查询和更新MBean对象的属性值。JManage管控平台是面向集群管理的JMX客户端，包括用户界面和API接口，可同时满足运维人员手动管理和程序自动化管理的需求。

（4）分布式定时任务Quartz

Quartz是开源的Java定时任务调度框架，支持集群部署，具备线性扩展性和高可用性。当集群部署时，单节点执行调度任务，其余节点检测该任务执行是否成功，如果执行失败，新的节点会重新执行任务，直至执行成功，节点之间的互斥机制可通过对临界资源加锁而实现。

2 整体流程

计费系统的核心业务数据模型包括当前计费金额和计费明细。当前计费金额会随着用户的请求而持续改变，且不会有终止状态，属于状态数据；计费明细是在每次用户请求时新插入到数据库中，且插入之后该条明细不再改变，其目的主要用于用户查询和对账，属于流水数据。从业务特点可以看出，状态数据的更新强依赖于上次更新后的数值，而流水数据的插入与已有的流水数据并无关联。当数据层主库故障时，只要能够获取当前计费金额的准确值，就可以继续进行正常的业务操作，即使用户暂时无法查询到最新的明细记录，此时可在客户端给予用户安抚提示。因此，应用层容错机制是针对状态数据而设计的，在保证状态数据一致的提前下，提高状态数据的可用性。

应用层容错机制将程序的运行过程划分为4种模式：正常模式、容错过渡模式、容错模式和恢复模式。4种模式在程序中用变量的不同取值表示，通过JManage管控平台切换应用层当前的运行模式，四种模式的切换顺序如图1所示：

图1　应用层服务器的运行模式转移顺序

在4种模式下涉及到的数据库有3种：主库、备库和容错库。主备库之间采用异步复制技术，而容错库是专用于容错处理时进行事务操作的数据库，初始化时无数据，完成容错任务后，容错库数据清空或迁移到历史数据库。

2.1 正常模式

正常模式对应主库正常工作阶段，该模式下事务操作均在主库中进行。事务中包含的数据库操作分为两部分：更新状态数据和插入流水数据。事务操作成功后，将状态数据封装为消息发送到RocketMQ，消费端接收消息并将状态数据写入多份缓存，备库从主库异步复制数据。正常模式的系统执行逻辑如图2所示：

图2　正常模式下系统执行逻辑图

主库数据异步复制到两个备库：一个备库用于在主库不可用时进行主备切换；另一个备库用于读写分离。Memcache缓存数据的过期时间要远大于主备库复制延迟，从而保证缓存过期失效的数据已经复制到备库，主备库异步复制的延迟在几秒钟到十几分钟的范围内，Memcache数据缓存过期时间设置为2小时，同时对主备库复制延迟进行监控，延迟过高时报警。数据库和分布式缓存中的状态数据均有由应用服务器统一标记的时间戳，以便查询最新的状态数据。备库和Memcache二者所有的状态数据与主库数据保持最终一致性，而RocketMQ中未被消费的消息则是未达到最终一致的状态数据。

2.2 容错过渡模式

当运维脚本通过心跳机制检测到主库不可用时，首先将自动调用JManage管控平台的API接口切换应用服务器到容错过渡模式，该模式不允许事务操作，只允许数据查询。切换完成后，运维脚本再从集群中随机选择一台应用服务器，调用其RPC接口以生成黑名单。所谓黑名单是指尚未达到最终一致的状态数据，不允许这些数据在后续的容错模式下进行事务处理。通过RocketMQ提供的查询接口从消息队列中查询消费进度和未被消费的消息，并将查询结果中包含的状态数据插入到容错库中，可生成黑名单列表。过渡模式系统执行逻辑如图3所示：

图3　容错过渡模式下系统执行逻辑图

容错过渡模式是四种模式中唯一不允许进行业务处理的模式，应用层处于该模式下的时间长短决定了整体系统的可用性高低，当检测到主库不可用时，模式切换与黑名单生成均由运维脚本调用相关接口自动完成。由于RocketMQ并发消费吞吐量高和缓存写入速度快，因此只有少数状态数据被记入黑名单。

2.3 容错模式

当黑名单生成结束后，运维脚本调用JManage管控平台的API接口切换应用服务器到容错模式。由于未达到最终一致的状态数据均已记入黑名单中，因此黑名单之外的状态数据可以通过备库和Memcache查询到准确的最新值。将该值插入到容错库中，对该状态数据的相关事务操作均在容错库中进行。容错模式的系统执行逻辑如图4所示：

图4　容错模式下系统执行逻辑图

在容错模式进行业务处理的同时，DBA等运维人员采用传统方式进行主备切换。容错模式与主备切换相结合的优势在于，在主备切换的过程中，系统服务不被中断，这也弥补了异步复制在保证一致性的提前下主备切换时间较长的缺陷。

2.4 恢复模式

当主备切换完成后，主库重新可用，运维人员通过JManage提供的操作界面手动将应用层从容错模式切换到恢复模式，此时主库和容错库均允许进行事务操作，同时异步执行分布式定时任务，将容错库的状态数据和流水数据回迁到主库。

回迁时要准确控制事务操作的数据源，防止单条状态数据同时在主库和容错库进行更新，导致数据紊乱。对容错库中不存在的状态数据或已回迁到主库的状态数据，在主库进行事务操作；对未开始回迁的状态数据，在容错库进行事务操作；对正在回迁的状态数据，不允许进行事务操作。当容错库所有数据回迁完成，运维人员切换应用服务器到正常模式，历史数据清空或迁移到历史库。恢复模式的系统执行逻辑如图5所示：

图5　恢复模式下系统执行逻辑图

对应用层四种模式的总结，任何模式下进行的事务操作，均发送包含状态数据的消息到RocketMQ，保证Memcache始终有状态数据的最新快照，如表1所示：

表1　各模式下组件执行操作概览表

系统整体的容错机制在保留了数据层异步复制优点的同时，使用容错模式在主备切换的过程中进行业务处理，系统的不可用时间也从异步复制的主备切换时长缩短为过渡模式下黑名单生成时长，前者为保证一致性需要DBA手动操作时间较长，而后者完全由运维脚本自动化快速完成，从而大大缩短了系统服务的不可用时间，提高了系统可用性。

3 模块设计与实现

应用层容错机制分为3个模块：业务处理模块、快照处理模块和数据回迁模块。各模块间的交互关系如图6所示：

图6　容错机制模块交互图

业务处理模块负责响应不同模式下的业务处理请求，在主库或容错库中进行事务操作，其运行模式通过JManage管控平台进行切换。当运维脚本通过心跳检测到主库不可用时，自动切换到容错过渡模式下，并向业务处理模块发送请求生成黑名单，生成结束后，运维脚本切换业务处理模块到容错模式，开始容错模式下的业务处理，直至主备切换完成。之后，再由运维人员切换业务处理模块到恢复模式，并开始数据回迁，回迁是在数据回迁模块中由Quartz定时任务异步执行，回迁结束后，运维人员切换回正常模式下。恢复模式和正常模式在切换前后均可以进行正常的业务处理，因此运维人员手动切换模式对系统可用性并无影响。

业务处理模块进行事务处理时，将状态数据的快照发送给快照处理模块，并由快照处理模块将状态数据写入Memcache，当在容错模式下进行事务操作时，快照处理模块从Memcache和备库中读取最新的快照返回给业务处理模块。

在设计具有高一致性需求的其他应用系统时，应考虑在应用层设计容错机制，并与数据层的复制技术结合起来，将容错作为系统的整体任务，而非数据层的单一职责。根据系统的业务特点，对数据模型进行分析，选择更新操作较为频繁的状态数据保存其快照，以用于容错阶段的查询。下面对计费系统容错机制各模块的实现方法进行详细介绍。

3.1 数据模型

计费系统及其容错机制的数据模型如表2所示：

表2　计费系统数据模型表

计费表和流水表分别对应业务操作的状态数据和流水数据，存储于主库和容错库中；状态消息是计费金额发生变动时发送到RocketMQ的账户最新计费金额，其中，“数据源”字段表示本次计费操作发生在主库还是容错库；状态快照是以键值对的形式存储在Memcache的计费账户当前金额。

黑名单是记录在容错模式下不提供服务的账户；容错控制表是记录在容错模式和恢复模式下账户是否已回迁，其中，“账户标识”字段取值有三种：INIT表示账户在容错库进行事务操作；PROCESS表示账户正在从容错库回迁主库，不允许事务操作；COMPLETE表示账户在主库进行事务操作。黑名单和容错控制表存储于容错库中。

各数据模型中的“计费账户”字段和“计费流水号”字段在业务上是唯一的，因此在数据库中要满足唯一性约束。3.2 业务处理模块

业务处理模块负责响应用户请求执行计费操作以及在过渡模式下生成黑名单，计费操作分为准备阶段和事务处理阶段。

（1）准备阶段

准备阶段是在事务处理前进行与当前运行模式相关的准备工作。正常模式和容错过渡模式的准备工作较为简单：正常模式下选择主库作为后续事务处理阶段的数据源；容错过渡阶段拒绝一切事务处理请求。

在容错模式下，首先查询请求操作的计费账户是否在容错控制表中，如果不存在，说明该账户从未在容错模式下进行事务处理，此时，再查询该账户是否在黑名单中，如果仍不存在，说明该账户可以在容错模式下进行事务处理，这种情况下，业务处理模块从快照处理模块读取该账户的最新计费金额，并插入到容错库的计费表中，并再向容错库的容错控制表插入账户标识为INIT的相应记录，两次插入在同一事务中进行，最后选择容错库作为下一阶段的数据源。在容错模式下，处理对该账户的后续请求时，由于容错控制表中已经存在标识为INIT的该账户记录，因此可直接选取容错库作为数据源，而无需再次读取快照。

在恢复模式下，先查询计费账户是否在容错控制表中：如果存在，则根据账户标识选择数据源，INIT标识选择容错库，COMPLETE标识选择主库，PROCESS标识表示数据正在回迁，不允许操作；如果计费账户不在容错控制表中，说明该账户在容错模式下没有发生计费操作，向容错库的容错控制表插入账户标识为COMPLETE的记录，并选择主库作为数据源。

当准备阶段完成后，系统已经根据应用层当前的运行模式和容错控制表中的账户标识选择了对应的数据源，对三者之间的对应关系进行了总结，如表3所示：

表3　运行模式、账户标识和数据源对应关系表

（2）事务处理阶段

事务处理阶段分为四步：账户加锁、对应关系检查、数据库操作和消息发送。

为了控制事务的并发操作，在修改任何账户相关的数据前，均要在计费表中对该账户加锁，使用select…for update语句为单行数据加更新锁，账户相关数据包括当前计费金额和账户标识。

在对账户成功加锁后，要对运行模式、账户标识和已选择数据源三者的关系进行重新检查。再次检查的原因有两方面：首先，在准备阶段和事务处理阶段应用层运行模式可能发生了切换；其次，准备阶段没有加锁操作，账户标识在查询后可能被其他事务更新。

数据库操作包括计费金额的更新和流水明细的插入，在更新账户当前计费金额时，还需要更新计费账户的修改时间，虽然各服务器的时间由NTP服务来统一，但仍会存在微小偏差，计费账户的修改时间是以毫秒为单位的时间戳，如果应用服务器当前时间戳小于计费账户上次保存的时间戳，则在计费账户上次保存的时间戳的基础上增加一毫秒，从而保证账户修改时间严格递增。由于在对计费账户更新时，已经对账户加锁控制事务并发，因此，通过时间戳的大小可以完全反映计费账户更新的先后顺序，这种做法借鉴了lamport逻辑时钟的思想[5]。

在数据库事务提交前，需要发送计费账户的快照到消息队列中，消息体中包含的内容如表2所示。事务提交前，发送一阶段消息，事务提交后，根据事务提交的结果，发送二阶段消息。当RocketMQ由于悬挂消息而主动回查业务处理模块时，业务处理模块可根据计费流水号查询事务是否已提交，如果回查消息中的计费流水号对应的明细在数据库中存在，并且消息体中的流水创建时间和发生额与数据库中的记录相同，则发送Commit消息，否则发送Rollback消息，如果此时数据库不可用则发送Unknown消息表示要求RocketMQ稍后重新回查。消息体中的“数据源”字段表示该事务在主库还是在容错库中进行，业务处理模块根据“数据源”选择不同的数据库进行回查。

（3）黑名单生成

业务处理模块对外提供黑名单生成接口，该接口的实现是从RocketMQ中查询未消费消息，并将消息中涉及到的账户插入到容错库的黑名单中。RocketMQ中未消费的消息分为三类：消费队列中还未投递到快照处理模块的消息；消费失败后在重试队列中等待定时重试的消息；事务性消息状态表中还未收到二阶段确认的消息。

3.3 快照处理模块

快照处理模块负责账户快照的读写，该模块从RocketMQ接收消息写入Memcache，并在容错模式下从Memcache和备库中读取最新的账户计费金额。

当快照处理模块读取账户最新计费金额时，首先从多个Memcache集群中读取，比较多个查询结果的修改时间，选择修改时间最新的结果，如果Memcache中没有该账户的记录，则从备库中读取，并返回结果。

当快照处理模块接收消息写入数据时，采用并发消费的方式以提高吞吐量，RocketMQ批量推送消息到消费者，消费者不必等待前一条消息处理完成，即可开始下一条消息的处理，单条消息消费失败不阻塞队列中其他消息的处理。

并发消费的方式不能保证消息严格有序，因此只有当消息体中计费账户修改时间大于Memcache中该账户修改时间才进行更新，否则不更新。这种做法可以保证同一计费账户在Memcache中是按照修改时间的先后顺序进行更新的，即保证数据库和缓存之间更新顺序的因果一致性[6]。快照写入逻辑如图7所示：

图7　快照处理模块快照写入逻辑图

为实现快照冗余备份，快照处理模块将数据写入到3个Memcache集群中，写入时构建3个任务提交到线程池中并发执行，等待并汇总3个任务的执行结果，当任务全部成功时，返回RocketMQ处理成功，否则返回处理失败，由RocketMQ定时重试。

3.4 数据回迁模块

在恢复模式下，由Quartz发起异步定时任务逐步将容错库中的数据回迁到主库中，数据回迁的过程中涉及到容错库和主库两个数据库的操作，由于回迁任务可能会出现异常，为保证回迁任务的可靠性，应当允许回迁任务能够多次重试，并且多次操作不会导致同一账户的重复回迁，即操作要保证幂等性。

Quartz定时任务从容错库的容错控制表中查询所有账户标识为INIT或PROCESS的记录，将查询到的账户进行分组，并将分组发送给其他服务器，当某台服务器接收到分组时，即开始进行该分组的回迁任务，回迁时是按照单个账户的维度进行的，如果某计费账户回迁失败，则开始下一个账户的回迁。Quartz定时任务每隔一段时间重复执行，直至容错库的容错控制表中所有账户标识均为COMPLETE。

单个计费账户及其相关流水的回迁逻辑如图8所示：

图8　回迁任务逻辑图

回迁任务分为3个独立的事务，其中事务1和事务2是容错库事务，事务3是主库事务，如果事务2或者事务3执行失败，则事务1回滚，而事务2和事务3是否成功只与其事务本身执行过程有关，与其他事务无关。与计费操作的事务处理类似，回迁任务需要对账户加更新锁，避免并发操作。加锁后检测账户标识，标识为INIT表示没有进行过回迁，标识为PROCESS表示上次的回迁任务没有完成，主库中可能已经回迁，也可能没有回迁，标识为COMPLETE则表示回迁完成，可以结束单个账户的回迁任务。

为解决标识为PROCESS时无法确定是否已经回迁成功的问题，在主库中也增加了容错控制表，与容错库的容错控制表的区别在于，主库的容错控制表只有COMPLETE账户标识，用于标识主库回迁是否完成，该表属于过程数据，回迁成功后删除或者迁移到历史数据中。容错库中账户标识为PROCESS的数据，可以依据主库中是否存在COMPLETE标识判断主库的回迁是否完成，从而继续任务的处理，即使多次重试相同的定时任务，也不会导致单个账户的重复回迁，保证了回迁操作的幂等性。

4 应用与测试

在基于OpenStack的私有云环境下，搭建了带有应用层容错机制的计费系统用于实验测试，其计费能力通过Web服务的形式对外提供，通过发送HTTP请求可模拟真实的用户计费操作，请求的主要参数包括计费账户和本次计费发生额。

私有云环境下分配的虚拟机配置相同，均为单核Intel Core i7-5500U处理器、2G内存、20G固态硬盘，操作系统均为64位CentOS6.6。应用层使用2台虚拟机，用于搭建事务处理模块和快照处理模块，软件环境为Tomcat7.0.22；数据层使用4台虚拟机，1台作为主库，2台作为备库，1台作为容错库，软件环境为MySQL Community Server 5.7.9；为进行对比实验，再使用4台虚拟机搭建MySQL Cluster （NDB引擎）的同步复制环境，1台作为管理节点，1台作为计算节点，2台作为存储节点，NDB引擎的版本为7.4.8。使用InnoDB引擎的MySQL数据库不支持同步复制，而使用NDB引擎的MySQL Cluster数据库提供了同步复制的功能。中间件在私有云中已集群部署，作为基础平台为应用层提供服务，其中，RocketMQ的版本为3.2.6，Memcache的版本为1.4.4，JManage的版本为2.0，Quartz的版本为2.1.1。

测试时，首先在数据库插入10万条计费账户信息，然后利用JMeter压测软件模拟100个客户端对账户随机发起计费请求，测试完成后JMeter自动生成测试报告，包括吞吐量、平均响应时间等关键指标。

三种容错机制的吞吐量对比测试结果如表4所示：

表4　吞吐量对比测试结果

其中异步复制和同步复制均为数据层容错方案，未使用应用层容错机制，测试结果表明：异步复制不影响数据库的吞吐量，因此吞吐量最高；应用层容错机制的额外性能开销主要在于状态消息的发送，其每秒处理请求数是异步复制的85%，而平均响应时间增加了24毫秒；同步复制的性能最低，其每秒处理请求数是异步复制的51.5%，性能降低一半，平均响应时间增加了131毫秒，是异步复制的两倍。

针对应用层容错机制在不同的吞吐量下进行故障切换的测试结果如表5所示：

表5　不同吞吐率下故障切换测试结果

结果包括故障切换时长和记入黑名单的账户数量。其中，故障切换时长是指处于容错过渡模式下的时间，从切换到容错过渡模式开始计时，当切换到容错模式后停止计时，主要是黑名单生成时长，通过运维脚本的日志可以获取该时间。

测试结果表明：随着吞吐量的增加，黑名单中的账户数量也增多，黑名单中账户数与吞吐量的比值在2.7%到6.45%的范围内，即黑名单中不可用账户数最多不超过当前吞吐量的6.45%，绝大部分账户在容错模式下都可以进行事务处理。应用层容错机制的故障切换时间在毫秒级，根据MySQL官方提供的最新白皮书，使用NDB引擎的MySQL Cluster数据库故障切换时间同样在毫秒级[7]。

从测试结果可以看出，对于具有高一致性需求的计费系统，应用层容错机制的故障切换时间与同步复制技术相当，系统吞吐量相对于同步复制技术则有较大提升。异步复制在保证数据一致的前提下的主备切换时长通常在分钟级，应用层容错机制相对于异步复制则大大缩短了故障切换时系统的不可用时间。应用层容错机制在容错模式下禁止黑名单账户的计费操作，而黑名单中账户数量所占比例完全在业务可接受的范围内。

5 总结

保证数据的高可用性，不仅是DBA和运维人员的责任，同时也是应用设计者在系统架构阶段应当考虑的问题。应用层容错机制为提高系统可用性提供了一种新的思路，应用系统感知数据层的异常，并针对业务特点，制定相应的容错阶段解决方案，可有效减少系统不可用时间。

参考文献

[1] 桑成良. 多租户数据库一致性问题研究[D].山东大学,2013.

[2] 梁勇. 数据库集群故障切换技术的研究与实现[D].国防科学技术大学,2010.

[3] 施晓烨. 数据网格中副本管理策略研究[D].南京邮电大学,2011.

[4] 江英琴. 基于日志复制的医院容灾备份系统的构建与应用[D].浙江工业大学,2014.

[5] 张红亮. 分布式系统时钟同步技术的研究与应用[D].国防科学技术大学,2002.

[6] 吕伟. 分布式系统下时钟同步及事件因果一致性问题研究[D].山东大学,2006.

[7] Oracle, Incorporated. MySQL: A Guide to High Availability[R/OL]. Oracle, Incorporated, 2015.

Design and Implementation of Fault Tolerance Mechanism in Application Layer Based on Cloud

Yu Xiang,Ye Dejian
(1.Software School, Fudan University, Shanghai 201203, China; 2.Engineering Research Center of Cyber Security Auditing and Monitoring, Ministry of Education, Shanghai 201203, China)

Abstract:According to highly consistent scenarios, this paperproposes modular design of a fault tolerance mechanism in application layer from the perspective of business characteristicscombinedwith asynchronous replication technology in data layer based on the support provided by cloud middleware. This mechanism takes a snapshot of state data. When the data layer is down, the mechanism forbids access to the inconsistent data and allows business operation on the consistent data. Testing results show that the fault tolerance mechanism shortens the failover time effectively and improve the system’s availability under the premise of guaranteeing data consistency. At the same time, it doesn’t have an obvious impact on the system’s throughput.

Key words:Cloud Middleware; Fault Tolerance Mechanism; Consistency; Availability

收稿日期：（2015.10.14）

作者简介：于 翔（1991-），男，山东，复旦大学软件学院，硕士研究生，研究方向：分布式与云计算，上海，201203叶德建（1976-），男，浙江，复旦大学软件学院，副教授，研究方向：网络多媒体，上海，201203

文章编号：1007-757X(2016)02-0063-06

中图分类号：TP3

文献标志码：A