CN101493924A - 事务处理系统的事务处理方法及彩票事务处理方法 - Google Patents

Abstract

本发明提供了一种事务处理系统的事务处理方法，所述事务处理系统由第一终端和至少一个第二终端构成，其中，第二终端可重复地向第一终端发送同样的事务请求，包括：第二终端向第一终端发送包含事务标识的事务请求；第一终端根据与所述事务标识对应的第一终端事务状态判断是否处理过该事务请求，若否，第一终端处理所述事务请求，记录与所述事务标识对应的第一终端事务状态，并向步骤A中所述第二终端发送包含处理结果和所述事务标识的响应信息；若是，第一终端向步骤A中所述第二终端再次发送包含处理结果和所述事务标识的响应信息。还相应提供了一种事务处理方法。本发明实现系统两端状态不同步的情况下，避免同一个事务被重复处理。

Description

事务处理系统的事务处理方法及彩票事务处理方法

技术领域

本发明涉及一种事务处理方法的技术领域，特别是指一种事务处理系统的事务处理方法及彩票事务处理方法。

背景技术

在常用的事务处理系统中需要通过网络交互信息。例如彩票全热线系统中，彩票业务由终端与交易系统通过广域网或因特网实时交互实现。就售票业务而言，其业务过程可简单描述为以下步骤：

1、终端接收彩民的投注，验证投注内容是否符合玩法规则，对于符合玩法规则的投注，终端将投注内容和彩票玩法等相关信息打包，发送给交易系统；

2、交易系统接收到终端发送的售票请求后，检查玩法、奖期等业务状态是否合法。对于合法的投注，交易系统将产生彩票序列号、存储彩票信息并做相关统计和业务处理，在完成操作以后，发送彩票序列号和投注内容给终端；

3、终端接收到交易系统发送的彩票投注内容和彩票序列号后，校验数据正确，将彩票信息发送给打印机打印输出。

由于终端与交易系统之间的数据交互是通过广域网或因特网传输的，而网络传输的不可靠性，如丢包或网络超时等原因，都会使得终端和交易系统无法准确知道对方处理的状态，从而无法保证售票过程的唯一性。例如，终端在发送完成售票请求以后，没有收到交易系统的响应，这个时候可能有两种情况会导致终端无法收到交易系统的响应：1)终端发送售票请求时，因网络故障交易系统没有接收到售票请求，从而交易系统不可能会发送任何信息，这种情况简称为“上行失败”；2)终端发送的售票请求已经被交易系统正确接收并处理，但当交易系统给终端发送数据时，因网络故障终端无法正确接收到交易系统发送的数据，这种情况简称为“下行失败”。因为彩票序列号是由交易系统生成的，终端必须得到交易系统正确响应后才能得到彩票序列号，所以对于“上行失败”和“下行失败”两种因网络故障造成的交易状态不同步的情况，没有完整的彩票信息的终端只能重发售票请求。但如果是“下行失败”，在现有技术中，交易系统是无法判断两次请求是否为同一张彩票的，这会导致出现重复记录的问题。同样的对于彩票交易系统中的关键业务，例如兑奖、取消票等都是不能允许类似的情况出现的。

所以对于可重复发送同样事务请求的事务处理系统急需一种可以实现交易两端不同步的情况下，避免同一事务被重复处理的方法。

发明内容

有鉴于此，本发明的主要目的在于提供一种事务处理系统的事务处理方法及彩票事务处理方法，以实现第一终端和第二终端状态不同步的情况下，避免同一个事务被重复处理。

为解决上述技术问题，本发明提供一种事务处理系统的事务处理方法，所述事务处理系统由第一终端1和至少一个第二终端2构成，其中，第二终端2可重复地向第一终端1发送同样的事务请求，该方法包括：

A、第二终端2向第一终端1发送包含事务标识的事务请求；

B、第一终端1根据与所述事务标识对应的第一终端事务状态判断是否处理过该事务请求，

若否，第一终端1处理所述事务请求，记录与所述事务标识对应的第一终端事务状态，并向步骤A中所述第二终端2发送包含处理结果和所述事务标识的响应信息；

若是，第一终端1向步骤A中所述第二终端2再次发送包含处理结果和所述事务标识的响应信息。

由上可以看出，通过事务标识可以区别不同的事务请求。而每次第一终端1处理事务请求，发送响应信息时都会记录与事务标识对应的第一终端事务状态，这样第一终端1在收到事务请求时，只要在处理该事务请求之前检查与该事务请求包括的事务标识对应的第一终端事务状态就可以知道是否曾经对同样的事务请求进行处理并发送响应信息了。例如第一终端1在收到因“下行失败”导致重发的事务请求时，与该事务请求包括的事务标识对应的第一终端事务状态已经被记录过了。而第一终端1在收到因“上行失败”导致重发的事务请求时，与该事务请求包括的事务标识对应的第一终端事务状态是没有被记录的。这样就可以区分出是因什么情况导致事务请求的重发。从而避免了同样的事务请求被重复处理。

优选的是，在第二终端2判断未收到所述事务请求的响应信息时第二终端2重复地向第一终端1发送同样的事务请求。

由上可以看出，第二终端2只需要在判断未收到所述事务请求的响应信息时重复地向第一终端1发送同样的事务请求，就避免了因没有收到响应信息而使得事务处理过程中断。

优选的是，所述事务处理系统中包括申请事务请求，步骤A中所述事务请求为申请事务请求时，该事务请求包含的事务标识为空；

步骤B中包括：第一终端1判断事务标识为空时，与该事务标识对应的第一终端事务状态为空；

所述处理所述事务请求包括：生成新事务标识替换原事务标识；

所述记录与所述事务标识对应的第一终端事务状态包括：记录与所述事务标识对应的第一终端事务状态为初始化状态。

由上可以看出，只有申请事务请求才能得到事务标识，从而开始一个事务。又因为第二终端2只有分散信息且稳定性低于第一终端1，所以事务标识是在第一终端1集中生成的，以利于集中控制和规避风险。

优选的是，所述事务处理系统中包括处理事务请求，步骤A中所述事务请求为处理事务请求，所述处理事务请求还包括第二终端事务处理信息；

步骤B中所述处理所述事务请求包括：根据第二终端事务处理信息生成并记录第一终端事务处理信息；

所述记录与所述事务标识对应的第一终端事务状态包括：记录与所述事务标识对应的第一终端事务状态为未决状态。

由上可以看出，在步骤B中第一终端1在处理完处理事务请求之后修改第一终端事务状态为未决状态，并在每次处理事务请求之前都根据事务标识查找对应的第一终端事务状态。这样就使得第一终端在接到处理事务请求后就可以正确判断并进行下一步处理了。

优选的是，所述事务处理系统中包括确认事务请求，步骤A中所述事务请求为确认事务请求时；

步骤B中所述记录与所述事务标识对应的第一终端事务状态包括：记录与所述事务标识对应的第一终端事务状态为确认状态。

由上可以看出，只有经过确认事务请求才可以结束一次完整的事务了。

优选的是，第二终端2判断收到步骤A中所述事务请求的响应信息时，保存该响应信息中的事务标识和更新当前第二终端事务状态；

第二终端2从故障中恢复时，读取并根据所保存的第二终端事务状态继续对所述事务标识的事务进行处理。

由上可以看出，第二终端事务状态为第二终端2从故障恢复时如何进行事务的下一步处理提供了依据。

优选的是，第二终端2判断收到步骤A中所述事务请求的响应信息包括：申请事务请求的响应信息或事务处理请求的响应信息；

对应的，更新当前第二终端事务状态包括：更新为未决状态或确认状态。

优选的是，步骤A所述事务请求为取消事务请求；

步骤B所述处理所述事务请求包括：将所述事务标识所对应的记录做取消处理；

所述记录与所述事务标识对应的第一终端事务状态包括：记录与所述事务标识对应的第一终端事务状态为取消状态。

由上可以看出，对于不成功的事务还可以通过取消事务请求结束事务。

优选的是，所述第二终端2带有外部设备3，所述事务请求为取消事务请求是第二终端2判断外部设备3出现故障时向第一终端1发送的。

由上可以看出，因外部设备3出现故障导致事务不能继续进行时，可以通过取消事务请求来结束该事务，并在第一终端1对该事务做取消处理。

优选的是，所述事务请求为取消事务请求是第二终端2故障并从故障恢复时向第一终端1发送的。

由上可以看出，第二终端2自身出现故障，从故障中恢复时，一律发送取消事务请求，避免因各种原因导致第二终端事务状态记录错误而出现事务被错误处理的情况。

本发明还提供一种彩票事务处理方法，包括：

a、第二终端2向第一终端1发送申请事务请求；

b、第一终端1处理收到所述申请事务请求后，生成事务标识，记录第一终端事务状态为初始化，向第二终端2发送包括所述事务标识的申请事务请求响应信息；

c、第二终端2处理收到申请事务请求响应信息后，记录第二终端事务状态为未决，向第一终端1发送包含第二终端事务处理信息和所述事务标识的处理事务请求；

d、第一终端1处理收到处理事务请求后，根据第二终端事务处理信息生成第一终端事务处理信息，更改第一终端事务状态为未决，向第二终端2发送包括第一终端事务处理信息和事务标识的处理事务请求响应信息；

e、第二终端2收到处理事务请求响应信息后，更改第二终端事务状态为确认，向第一终端1发送确认事务请求；

f、第一终端1收到事务确认事务请求后，更改第一终端事务状态为确认，向第二终端2发送确认事务请求响应信息。

由上可以看出，第二终端2通过申请事务请求开始一个事务，由确认事务请求结束该事务。通过事务标识与事务进行对应并在每次第一终端收到事务请求后和第二终端收到响应信息后都对应修改各自的事务状态。从而通过跟踪事务状态就可以知道事务处于什么情况。

优选的是，步骤b、d或f进一步包括：

第一终端1收到来自第二终端2的请求时，首先判断是否已处理过所述请求，并在判断为是时，第一终端1重发所述请求对应的响应信息。

由上可以看出，第一终端1收到来自第二终端2的请求时，首先判断是否已处理过所述请求，就避免了第一终端1对同样的事务请求进行重复处理。

优选的是，步骤c或e进一步包括：

第二终端2记录第二终端事务状态和事务标识；

第二终端2从故障中恢复时，读取并根据所记录的第二终端事务状态继续对所述事务标识的事务进行处理。

由上可以看出，通过记录第二终端事务状态和事务标识，有效的规避了第二终端出现故障时导致事务无法继续处理的风险。

优选的是，第二终端2从故障中恢复时，向第一终端(1)发送包含事务标识的取消事务请求；

第一终端1收到所述取消事务请求时，将所述事务标识所对应的记录做取消处理。

由上可以看出，通过取消事务请求，可以避免第二终端因故障导致第二终端事务状态记录错误而错误处理事务。

附图说明

图1为彩票全热线系统示意图；

图2为一个售票过程在终端的流程图；

图3为申请事务过程中交易系统的流程图；

图4为业务处理过程中交易系统的流程图；

图5为确认事务过程中交易系统的流程图；

图6为用于解决终端出现打印问题的一个实施例的终端流程图；

图7为用于解决终端出现打印问题的一个实施例的交易系统流程图；

图8为正常情况下终端记录事务状态的一个实施例的流程图；

图9为终端从故障恢复下终端继续完成事务的一个实施例的流程图；

图10为彩票交易流程图。

具体实施方式

下面以彩票全热线系统为例对本发明的实施方式进行详细说明。彩票全热线系统的结构如图1所示，包括作为第一终端的交易系统1、作为第二终端的终端2和作为外部设备的用于出票的打印机3。

在本发明中事务是指一个关键业务的完整过程。所有事务都是由彩票全热线系统的终端2发起并在终端2最终结束，交易系统1处理所有终端2的各种事务请求。

交易系统1是处理终端2事务请求的服务器。终端2是面对客户进行业务操作的终端设备。终端2可以是投注站的投注设备也可以是安装了投注端口的个人电脑，移动设备等。当然，基于BS(Brower/Server浏览器/服务器)结构的彩票全热线系统，终端也可以是可以提供投注等服务的浏览器或软件。

对于彩票业务处理过程中关键的业务操作来说，需要经过三个过程：申请事务，业务处理和结束事务。在本发明中，终端2和交易系统1通过事务状态的变化来跟踪和确认每一步操作。对应于上述三个过程设置了三个事务状态：初始化、未决和确认/取消。每个事务都有一个唯一的事务标识，简称TID。在本实施例中事务标识采用的是终端编号(终端信息)加历史累积数字的形式。当然，事务标识还可以采用别的形式，例如时间加随机编码等。只要能有效的体现出事务的唯一性即可。

下面以售票过程为例结合附图对彩票交易系统的事务处理方法和实现避免重复处理的彩票交易的方法进行详细说明。附图中简称交易系统事务状态为事务状态。

对于终端2来说，发出事务请求之后，必须等待交易系统1的响应信息才能进行下一步处理。但是一个事务在交易的两端，即终端2和交易系统1端，是不同步的。也就是说终端2并不能实时知道事务在交易系统1端的处于何种状态。或者说该事务请求是否在交易系统1端处理过了。为了使终端2能够继续工作，终端2只能在设定时间内没有收到交易系统1的响应信息的情况下，重发之前的事务请求，直到得到交易系统1的响应或触发预设的停止条件为止。如图2所示为一个完整的售票过程在终端2的流程图。下面结合图2对终端2在整个售票过程中的流程进行详细说明。

步骤202，终端2向交易系统1发出申请事务请求。申请事务请求属于所述三个过程中的申请事务过程。在本实施例中，事务类型是按照在事务中的先后顺序对应于各个过程的具体类型。所以本实施例中包括三个事务类型：申请、处理和结束(确认/取消)。此外业务类型是终端2发出的处理事务请求的具体业务类型，包括：售票、取消票和兑奖等。交易系统1根据事务类型判断是否需要处理事务请求，而根据业务类型选择对应的业务逻辑对处理事务请求进行处理。

步骤204，终端2判断设定时间内是否收到交易系统1的响应信息，收到了则转入步骤206，没有收到则转入步骤202，重新发出申请事务请求。

步骤206，终端2接收交易系统1根据申请事务请求做出的响应信息。在本实施例中，所述的响应信息包含了这次售票事务的事务标识，其中事务标识是在交易系统1生成的。当然，事务标识也可以是在终端2直接生成，而省略上述3个步骤。但是如果在终端2生成事务标识的话存在一定的风险，不利于集中控制。

步骤208，终端2发送包含彩票内容和事务标识的售票事务请求。售票事务是彩票交易中的关键业务。关键业务还包括兑奖、取消票等。关键业务在本实施例中均对应的是交易事务过程。彩票内容包括彩票投注内容等。

步骤210，终端2判断设定时间内是否收到交易系统1的响应信息，收到了则转入步骤212，没有收到则转入步骤208，重新发出售票事务请求。

步骤212，终端2接收包含彩票序列号、彩票内容和事务标识的响应信息。通过该响应信息，终端2获得交易系统1根据事务标识和彩票内容给出的本次售票事务的彩票序列号。彩票序列号是和投注内容一一对应的，有需要时终端2会根据彩票序列号打印彩票。

步骤214，终端2发送确认事务请求。确认事务请求属于所述三个过程中的确认事务过程。

步骤216，终端2判断设定时间内是否收到交易系统1的确认事务成功的响应信息，收到了则结束本次事务，没有收到则转入步骤214，重新发出确认事务请求。

至此完成了从终端2发起售票事务到结束售票事务的整个过程。

在本发明中，交易系统1在收到事务请求的时候需要依据事务标识查询交易系统事务状态，来判断是否曾经处理过所接收的事务请求并分别做出相应的响应。下面结合附图对交易系统1在整个售票过程中的流程进行详细说明。

如图3所示为申请事务过程中交易系统1的流程图。

步骤302，交易系统1收到包含终端信息的申请事务请求。

步骤304，交易系统1根据终端信息读取交易系统事务状态判断是否曾经处理过所接收的申请事务请求。即，是否已经为收到的申请事务请求发送过包含事务标识的响应信息。如果交易系统事务状态为初始化，则表示已发送过响应信息，进入步骤306，否则表示尚未发送过响应信息，进入步骤308。

步骤306，交易系统1读取原事务标识并发送给终端2。对于已经初始化过的事务请求来说，意味着已经为该事务请求发送过包含事务标识的响应信息了。此时，只需根据终端信息读取并发送原事务标识即可。结束对终端2申请事务请求的处理。

步骤308，交易系统1生成事务标识。

步骤310，交易系统1记录包含事务标识的响应信息并发送响应信息给终端2，修改交易系统事务状态为初始化。在本实施例中，事务标识是由交易系统1生成的，这样便于集中控制并且规避了假冒终端2出现的可能。当然，事务标识也可以由终端2生成。

至此完成了交易系统1对终端2发来的申请事务请求的处理。在本实施例中，每个终端2一次只能处理一个事务。即在终端2是不能并发处理多个事务的。但是在交易系统1中，因为交易系统1只需要对终端2的事务请求做出正确响应，所以可以多个事务并发处理，也就是说交易系统是同时为多台终端机提供服务的，不同终端的事务因事务标识具有隔离性，互不干扰。这样可以很好的实现了交易的集中控制。在另一个实施例中，交易系统1每次接到申请事务请求，不做判断而是直接生成一个新的事务标识并发送给终端2。当然，交易系统1每次处理事务请求时只需要记录交易系统事务状态而不需要删除原交易系统事务状态。

如图4所示为业务处理过程中交易系统1的流程图。

步骤402，交易系统1收到包含彩票内容和事务标识的售票事务请求。

步骤404，交易系统1根据事务标识读取交易系统事务状态判断是否曾经处理过所接收的事务请求。即是否已经为收到的售票事务请求发送过包含彩票序列号、彩票内容和事务标识的响应信息。如果事务状态为未决，则已表示发送过响应信息，进入步骤406，否则表示未发送过响应信息，进入步骤408。

步骤406，交易系统1读取记录的包含原彩票序列号、彩票内容和事务标识的响应信息并发送给终端2。结束对终端2发来的售票事务请求的处理。

步骤408，交易系统1产生彩票序列号。

步骤410，交易系统1记录包含彩票序列号、彩票内容和事务标识的响应信息并发送给终端2，修改交易系统事务状态为未决。当然，也可以通过事务标识关联包括彩票序列号和彩票内容的相关信息。

至此完成了交易系统1对终端2发来的售票事务请求的处理。

和申请事务请求类似的是，在交易系统1每次接收到事务请求时均会根据事务状态进行判断是否曾发送过该事务请求的响应信息。且在处理并发送响应信息后都修改事务状态。

如图5所示为确认事务过程中交易系统1的流程图。

步骤502，交易系统1收到包含事务标识的确认事务请求。

步骤504，交易系统1根据事务标识读取交易系统事务状态判断是否曾经处理过所接收的事务请求。即是否已经为收到的确认事务请求发送过确认事务成功的响应信息。如果事务状态为确认，则已经发送响应信息，进入步骤506，否则未发送过响应信息，则进入步骤508。

步骤506，交易系统1发送确认事务成功或发送“事务不存在”。结束对终端2发来的确认事务请求的处理。

步骤508，交易系统1修改交易系统事务状态为确认或删除该事务。

步骤510，交易系统1发送确认事务成功。

至此完成了交易系统1对终端2发来的确认事务请求的处理。当然，因为确认事务请求并不需要在交易系统1进行处理，所以交易系统1也可以在修改交易系统事务状态为确认后发送确认事务成功即可。

在另一个实施例中，在步骤212终端2接收包含彩票序列号、彩票内容和事务标识的响应信息之后，对于部分终端2来说，还需要将彩票信息送往打印机3进行打印。因交易系统1记录的每张彩票只能打印一次，一旦如果因打印过程中的异常情况，例如打印机3卡纸、缺纸等，造成彩票未成功打印，就会造成交易系统1已记录彩票而实际没有打印出来的不一致问题。为了解决这个技术问题，如图6所示，为示出的用于解决终端2出现打印问题的一个实施例的终端2流程图。出现打印故障时，终端2在步骤212后执行以下步骤：

步骤602，终端2收到打印故障信号。

步骤604，终端2向交易系统交易1发送取消事务请求。

步骤606，终端2判断设定时间内是否收到交易系统1的取消事务成功的响应信息，收到了则结束本次事务，没有收到则转入步骤604，重新发出取消事务请求。

如图7所示，为示出的用于解决终端2出现打印问题的一个实施例的交易系统1流程图。交易系统1收到终端2的取消事务请求时，交易系统1执行以下步骤：

步骤702，交易系统1收到包含事务标识的取消事务请求。

步骤704，交易系统1根据事务标识读取交易系统事务状态判断是否曾经处理过所接收的事务请求。即是否已经为收到的取消事务请求发送过取消事务成功的响应信息。如果事务状态为取消，则进入步骤706，否则进入步骤708。

步骤706，交易系统1发送取消事务成功。结束对终端2发来的取消事务请求的处理。

步骤708，交易系统1删除该事务的所有记录，修改事务状态为取消。当然，也可以采用使记录无效的方式替代删除操作。或者直接删除事务状态和该事务的所有记录。

步骤710，交易系统1发送取消事务成功。

至此就解决了即使终端2出现打印问题时可能出现的终端2和交易系统1的不一致的问题。

在另一个实施例中，为了在事务过程中，终端2因为故障或其它原因暂停工作之后能继续正确处理该事务，在终端2保存有包含事务标识和终端事务状态的事务文件。终端2每次接收到交易系统1的响应信息和终端2完成事务处理需发送事务请求时，都修改并记录终端2事务状态到事务文件中，如图8所示，为示出了正常情况下终端2记录事务状态的一个实施例的流程图。

在步骤206和步骤208之间执行如下步骤：

步骤2071，终端2修改终端事务状态为初始化，保存事务文件。

步骤2072，完成投注操作。

步骤2073，修改终端事务状态为投注完成，保存事务文件。

在步骤212和步骤214之间执行如下步骤：

步骤2131，终端2修改终端事务状态为待打印，保存事务文件。

步骤2132，打印彩票。

步骤2133，修改终端事务状态为确认，保存事务文件。

至此，终端2每次接收到响应信息之后处理完成之前，处理完成后发送请求信息之前都相应修改终端事务状态并保存事务文件。当然，终端2也可以是在每次接收到响应信息之后以及发送事务请求之后修改终端事务状态并保存事务文件。

在终端2恢复的时候只需要读取事务文件，继续事务的处理即可。如图9所示，为示出了终端2从故障恢复下继续完成事务的一个实施例的流程图。在终端2从故障中恢复后执行以下步骤：

步骤902，终端2读取事务文件。

步骤904，终端2根据事务文件继续完成事务处理。

在本实施例中，所述的事务文件是保存在磁盘中的磁盘文件。在另一个实施例中，为了提高性能，终端2配有不间断电源(UPS)，所述的事务文件保存在内存中。当然所述事务文件可以保存在其它存储器中，只要能够有效的保存即可。而对于交易系统1来说，上述情况是透明的，即无关的。交易系统1只需对终端2发出的各种事务请求做出正确的响应即可。在此不再赘述。

在另一个实施例中，终端事务状态分为未完成和已完成两种。在终端2发送最后一次事务请求之前的处理过程完成之前的终端事务状态为未完成，终端2发送最后一次事务请求时修改终端事务状态为已完成。如果终端2是从未完成的终端事务状态中恢复的，终端2发送的是取消事务请求。取消事务请求的过程可以参见上文解决出现打印故障时所采用的方法。在此不再赘述。如果终端2是从已完成的终端2事务状态中恢复为，终端2发送的是确认事务请求。确认事务请求的过程可以参见上文图2和图5的相应步骤，在此不再赘述。

当然，对于终端2从故障中恢复来说，若不采用上述的步骤继续恢复到故障前的工作，也可以向交易系统1发送取消请求，即凡发生故障均采用取消操作的方式。

为了使终端2和交易系统1的交互过程更为清晰，图10示出了彩票交易流程图，其中对于上述图2～图8的实施例，也可以参考图10流程图，更易理解本发明。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，例如打印机3更改为其他输出彩票设备，如手机、电脑等输出电子彩票的终端，均应包含在本发明的保护范围之内。

Claims (14)

1.一种事务处理系统的事务处理方法，所述事务处理系统由第一终端(1)和至少一个第二终端(2)构成，其中，第二终端(2)可重复地向第一终端(1)发送同样的事务请求，其特征在于，包括：

A、第二终端(2)向第一终端(1)发送包含事务标识的事务请求；

B、第一终端(1)根据与所述事务标识对应的第一终端事务状态判断是否处理过该事务请求，

若否，第一终端(1)处理所述事务请求，记录与所述事务标识对应的第一终端事务状态，并向步骤A中所述第二终端(2)发送包含处理结果和所述事务标识的响应信息；

若是，第一终端(1)向步骤A中所述第二终端(2)再次发送包含处理结果和所述事务标识的响应信息。

2.根据权利要求1所述方法，其特征在于，在第二终端(2)判断未收到所述事务请求的响应信息时第二终端(2)重复地向第一终端(1)发送同样的事务请求。

3.根据权利要求1所述方法，其特征在于，所述事务处理系统中包括申请事务请求，步骤A中所述事务请求为申请事务请求时，该事务请求包含的事务标识为空；

步骤B中包括：第一终端(1)判断事务标识为空时，与该事务标识对应的第一终端事务状态为空；

所述处理所述事务请求包括：生成新事务标识替换原事务标识；

所述记录与所述事务标识对应的第一终端事务状态包括：记录与所述事务标识对应的第一终端事务状态为初始化状态。

4.根据权利要求1所述方法，其特征在于，所述事务处理系统中包括处理事务请求，步骤A中所述事务请求为处理事务请求，所述处理事务请求还包括第二终端事务处理信息；

步骤B中所述处理所述事务请求包括：根据第二终端事务处理信息生成并记录第一终端事务处理信息；

所述记录与所述事务标识对应的第一终端事务状态包括：记录与所述事务标识对应的第一终端事务状态为未决状态。

5.根据权利要求1所述方法，其特征在于，所述事务处理系统中包括确认事务请求，步骤A中所述事务请求为确认事务请求时；

步骤B中所述记录与所述事务标识对应的第一终端事务状态包括：记录与所述事务标识对应的第一终端事务状态为确认状态。

6.根据权利要求3，4或5所述方法，其特征在于，进一步包括：

第二终端(2)判断收到步骤A中所述事务请求的响应信息时，记录该响应信息中的事务标识和更新当前第二终端事务状态；

第二终端(2)从故障中恢复时，根据所记录的第二终端事务状态继续对所述事务标识的事务进行处理。

7.根据权利要求6所述方法，其特征在于，

第二终端(2)判断收到步骤A中所述事务请求的响应信息包括：申请事务请求的响应信息或事务处理请求的响应信息；

对应的，更新当前第二终端事务状态包括：更新为未决状态或确认状态。

8.根据权利要求1所述方法，其特征在于，步骤A所述事务请求为取消事务请求；

步骤B所述处理所述事务请求包括：将所述事务标识所对应的记录做取消处理；

所述记录与所述事务标识对应的第一终端事务状态包括：记录与所述事务标识对应的第一终端事务状态为取消状态。

9.根据权利要求8所述的方法，其特征在于：所述第二终端(2)带有外部设备(3)，所述事务请求为取消事务请求是第二终端(2)判断外部设备(3)出现故障时向第一终端(1)发送的。

10.根据权利要求8所述的方法，其特征在于：所述事务请求为取消事务请求是第二终端(2)故障并从故障恢复时向第一终端(1)发送的。

11.一种彩票事务处理方法，包括：

a、第二终端(2)向第一终端(1)发送申请事务请求；

b、第一终端(1)处理收到所述申请事务请求后，生成事务标识，记录第一终端事务状态为初始化，向第二终端(2)发送包括所述事务标识的申请事务请求响应信息；

c、第二终端(2)处理收到申请事务请求响应信息后，记录第二终端事务状态为未决，向第一终端(1)发送包含第二终端事务处理信息和所述事务标识的处理事务请求；

d、第一终端(1)处理收到处理事务请求后，根据第二终端事务处理信息生成第一终端事务处理信息，更改第一终端事务状态为未决，向第二终端(2)发送包括第一终端事务处理信息和事务标识的处理事务请求响应信息；

e、第二终端(2)收到处理事务请求响应信息后，更改第二终端事务状态为确认，向第一终端(1)发送确认事务请求；

f、第一终端(1)收到事务确认事务请求后，更改第一终端事务状态为确认，向第二终端(2)发送确认事务请求响应信息。

12.根据权利要求11所述的方法，其特征在于，步骤b、d或f进一步包括：

第一终端(1)收到来自第二终端(2)的请求时，首先判断是否已处理过所述请求，并在判断为是时，第一终端(1)重发所述请求对应的响应信息。

13.根据权利要求11所述的方法，其特征在于，步骤c或e进一步包括：

第二终端(2)记录第二终端事务状态和事务标识；

第二终端(2)从故障中恢复时，读取并根据所记录的第二终端事务状态继续对所述事务标识的事务进行处理。

14.根据权利要求11所述的方法，其特征在于，进一步包括：

第二终端(2)从故障中恢复时，向第一终端(1)发送包含事务标识的取消事务请求；

第一终端(1)收到所述取消事务请求时，将所述事务标识所对应的记录做取消处理。

Images