事务处理系统的事务处理方法及其处理装置的制作方法

专利名称：事务处理系统的事务处理方法及其处理装置的制作方法
技术领域：
本发明涉及一种事务处理系统的事务处理方法及其处理装置，尤 其是涉及由终端，交易系统和数据库构成的事务处理系统的事务处 理方法和处理装置。
背景技术：
在目前普遍采用的由交易系统1 、数据库2和终端3构成的事务 处理系统中，对于由终端3发出的事务请求，交易系统l需要根据
该事务请求判断所包含的请求量所对应的请求额度是否超出规定的 许可额度，超出时需要对其进行限制。例如医院的挂号系统，每天 专家坐诊的时间或次数是有限的，所以需要在专家门诊的挂号总时 间或总次数超过规定额度时拒绝挂号，即交易系统1需要根据终端3 发送的挂号请求判断所包含的挂号的次数或时间是否超出了剩余的 次数或时间。又例如在用于彩票交易的彩票全热线系统中，按照奖 金的分配方式，将彩票的玩法分为奖池玩法及固定奖金玩法。对于 奖池玩法，中奖者按照一定的比率均分奖池中的金额；而对于固定 奖金玩法，中奖者所得的奖金是固定的。所以对于固定奖金玩法来 说，如果投注非常集中并且正好中奖的话，可能出现奖池被掏空或 需要补贴大量奖金的情况，对于小奖组或高频率的玩法来说尤其如 此。为了体现彩票作为公益活动的本质，需要对投注进行一定的限 制，例如当某 一 注投注的注数超过 一 定比例将导致可能掏空或需要 补贴大量奖金时，进行限号，即拒绝再对该注投注，从而达到控制 返奖率的目的。即，请求额度超出规定的许可额度时，该事务请求 将被拒绝，以保证对事务请求的处理只在许可额度不超出规定的额 度时进行。在进行这种处理的时候，因受到较多因素的影响，如何避免对 事务处理性能产生不利影响和对规避风险等显得尤为重要。
仍以彩票全热线系统为例。目前，彩票全热线系统的架构如图1
所示，终端3将投注请求发送到交易系统1,交易系统l对投注请求
中的投注内容进行合法性检查，进行一系列操作后将本次投注的内
容更新到数据库2。由数据库2将投注内容持久化。对于投注限号的 实现，由于终端3是分散的，不具备全局的信息，显然不适合作为 限号方案的实施者；数据库2具备精确的全局信息，即具备来自各 终端3的投注量和对于投注限号的规定额度，且这些数据是经过持 久化处理的，可以保证限号方案的精确控制，然而由于这些数据在 数据库中，所以每次进行投注请求的处理时，都需要调用耗时较多 的数据库，导致单次投注响应时间过慢，影响投注性能；如果在交 易系统1实施限号，即这些数据保存在交易系统中，由于都是内存 操作，可以在基本上不增加单次投注应答时间的情况下完成限号检 查，但由于交易系统1中的限号数据是没有持久化的，所以一旦由 于各种原因导致交易系统1重启或崩溃，将导致限号信息的全部丢 失，可能无法恢复正常运行，风险太大。

发明内容
有鉴于此，本发明的主要目的在于提供 一 种新的事务处理系统的 事务处理方法，以实现既能更少调用数据库，又能将可能丟失的许 可额度控制在一定范围内。
为解决上述技术问题，本发明提供了一种事务处理系统的事务处 理方法，所述事务处理系统由至少一台终端，交易系统和数据库构 成，由所述终端向所述交易系统发送事务请求，所述交易系统按规 定的程序对所述事务请求中包含的请求量计算出请求额度，在交易 系统中设定第一许可额度，在数据库中设定第二许可额度，所述第 一许可额度不足时，可从第二许可额度调用，以补充所述第一许可 额度，所述交易系统按以下步骤处理事务请求
B, 按照事务请求计算与请求量对应的请求额度；
C, 判断请求额度是否小于等于第一许可额度；
D, 请求额度小于等于第一许可额度时，从第一许可额度中减去 所述请求额度，并接受该事务请求；
E, 请求额度不小于等于第一许可额度时，从所述第二许可额度 调用规定的转移额度，以补充第一许可额度，在第一许可额度得到 补充后，从第一许可额度中减去所述请求额度，并接受该事务请求。
由上可知，交易系统在对事务请求进行处理时，首先判断根据请 求量计算得到的请求额度是否小于等于第一许可额度，在小于等于 第一许可额度时，接受该事务请求。
在请求额度不小于等于第一许可额度时，即，请求额度超出第一 许可额度时，才从数据库的第二许可额度中调用转移额度，以补充 第一许可额度，在第一许可额度得到补充后，接受该事务请求。
因此，只要将第一许可额度设定得大于可预计的请求额度，交易 系统就可独立的完成对事务请求的处理。这样对于大部分不会超出 第 一 许可额度的事务请求来说，并不需要调用耗时较多的数据库， 基本避免了事务请求处理过程中因调用数据库所造成的处理能力下 降。同时，又因为第二许可额度被设定在数据库中，是经过持久化 处理的，所以，在交易系统因重新启动等可能丢失的许可额度就被 控制在第一许可额度的范围内。
优选的是，所述事务处理系统是彩票系统，所述彩票系统的可投 注单元包括至少两个限号单元，对于每个限号单元，在所述交易系 统和所述数据库中分别设定相应的第 一许可额度和第二许可额度，
所述事务请求是包含对各限号单元进行投注的信息的投注请求， 所述步骤B之前还包括
A ，所述交易系统根据所述投注请求中所包含的投注的信息确定 投注的限号单元；
对相应的限号单元执行所述步骤B E。彩票系统中可投注单元通常包括至少两个限号单元。由此，对于 彩票系统来说，通过分别为不同的限号单元相应的设定第 一许可额 度和第二许可额度，可以在交易系统接到投注请求时，利用经过步
骤A确定的限号单元的第一许可额度和第二许可额度分别用于满足 投注请求和补充第 一许可额度。 优选的是，所述步骤E包括
El,在所述从所述第二许可额度调用规定的转移额度后，判断 请求额度是否小于等于补充后的第 一许可额度；
E2，请求额度不小于等于补充后的第一许可额度时，拒绝该投 注请求。
由此可知，在补充第一许可额度后，通过补充判断步骤El，可 以在补充后的第一许可额度补充后仍然不满足投注请求时通过拒绝 该投注请求，来保证每次投注请求的处理过程中调用数据库的操作 最多只有 一 次，从而从整体上确保了单次投注事务请求所需的时间。
优选的是，所述投注请求包含至少两个限号单元以及用于计算所 包含的限号单元的权重的投注方式，所述步骤B后还包括
B1 ，将请求额度根据由投注请求中包含的投注方式计算得到的 各限号单元的权重分配给各限号单元。
依次对相应的限号单元根据各自分配到的请求额度执行步骤 C E。
由此可知，通过步骤Bl,可以根据投注方式计算得到各限号单 元被分配到的请求额度。从而一次冲殳注请求可以包含两个或两个以 上的请求额度可能不同的限号单元，进而支持更复杂的彩票玩法。
优选的是，所述规定的转移额度为
设定的至少能满足 一 次投注请求所需的许可额度，或
第二许可额度的设定百分比数量。
由此可知，通过将规定的转移额度设定为至少能满足 一 次投注请 求所需的许可额度既可以使得第一许可额度不够用时，单次投注请 求的处理过程中只需要进行一 次调用数据库的操作，又可以使得第
9一许可额度的补充量不至于太大导致风险过大。或，通过将规定的 转移额度设定为第二许可额度的设定百分比数量，使得第一许可额 度的补充量只有第二许可额度的一部分，同样可以避免风险过大。
与此同时，在一个彩票系统存在多个交易系统时，通过设定合适 的所述规定的转移额度，还可以避免 一部分交易系统的第 一许可额 度补充过大导致第二许可额度过小，使得另一部分交易系统在需要 时却无法取得所需许可额度的情况，减少许可额度的浪费。
优选的是，定时的和/或在投注请求处理完成后将第一许可额度 设为所述规定的转移额度，调整第二许可额度使第一许可额度和第 二许可额度之和保持与所述投注请求处理完成后时的和一致。
由此可知，定时的和/或在^:注请求处理完成后，将第一许可额 度设为规定的转移额度，既可以因为此时交易系统处于空闲状态而 不补充单次投注请求的处理时间，又可以使得第 一 许可额度能够满 足下次投注请求的请求额度，还可以控制风险在所述规定的转移额 度范围内。
优选的是，所述交易系统在投注请求处理完成后将累积的请求量 记录在数据库中，
在投注请求处理完成后和/或第二许可额度小于等于所述规定的 转移额度时根据所记录的累积的请求量计算对应的动态许可额度； 并将所述动态许可额度补充到所述第二预设值中。
由此可知，通过在投注请求处理完成后将累积的请求量记录在数 据库中，交易系统可以根据请求量的记录而准确的生成动态许可额 度，从而实现了许可额度可以随着事务处理的增加等变化而动态变 化。并且通过投注请求和动态许可额度的功能分离，即在投注请求 处理完成后进行动态许可额度的计算，既可以因为此时交易系统处 于空闲状态而不影响到事务处理的性能，又可以避免因为数据库记 录失败等原因而导致生成错误的动态许可额度。保证了数据库和交 易系统各自的功能明确性。而数据库限号池不满足交易系统所请求 的许可额度时生成动态许可额度，则可以避免因未能及时生成动态
10许可额度而许可额度不够用的情况出现。
本发明还相应的提供了 一种事务处理系统的处理装置，所述事务 处理系统由至少一台终端，交易系统和数据库构成，由所述终端向 所述交易系统发送事务请求，所述交易系统按规定的程序对所述事 务请求中包含的请求量计算出请求额度，在所述交易系统中设定第 一许可额度，在所述数据库中设定第二许可额度，所述第一许可额 度不足时，可从第二许可额度调用，以补充所述第一许可额度，
所述处理装置包括
请求额度计算模块103,用于按照事务请求计算与请求量对应的 请求额度；
许可额度判断模块105,用于判断请求额度是否小于等于第一许 可额度；
第一许可额度扣除模块107，用于请求额度小于等于第一许可额 度时，将第一许可额度减去请求额度，接受该事务请求；
许可额度调整模块109，用于请求额度不小于等于第一许可额度 时，将第二许可额度减去规定的转移额度，将第一许可额度补充规 定的转移额度。
因此，只要将第一许可额度设定得大于可预计的请求额度，交易 系统就可独立的完成对事务请求的处理。这样对于大部分不会超出 第一许可额度的事务请求来说，并不需要调用耗时较多的数据库。 也就基本避免了事务处理过程中，因调用数据库所造成的处理能力 下降。同时，又因为第二许可额度被设定在数据库中，是经过持久 化处理的，所以，在交易系统因重新启动等可能丟失的许可额度就 被控制在第 一 许可额度的范围内。
优选的是，所述事务处理系统是彩票系统，所述事务处理系统是 彩票系统，所述彩票系统的可投注单元包括至少两个限号单元，对 于每个限号单元，在所述交易系统和所述数据库中分别设定相应的 第一许可额度和第二许可额度，所述事务请求是包含对各限号单元 进行投注的信息的投注请求，所述处理装置还包括限号单元确定模块111,用于根据所述投注的信息所确定投注请 求中的限号单元，并选择相应的第一许可额度，第二许可额度。
彩票系统中可投注单元通常包括至少两个限号单元。由此，对于 彩票系统来说，通过分别为不同的限号单元相应的设置第 一许可额 度和第二许可额度，可以在交易系统接到投注请求时，利用限号单
元确定模块111确定限号单元，并选择对应的第一许可额度和第二 许可额度。
优选的是，所述许可额度调整模块109还包括 补充后判断模块1093,用于在所述许可额度调整模块109从所 述第二许可额度调用规定的转移额度后，判断请求额度是否小于等
于补充后的第一许可额度；
补充后拒绝模块1095，用于请求额度不小于等于补充后的第一 许可额度时，拒绝该事务请求。
由此可知，许可额度调整模块109可以在请求额度不小于等于第 一许可额度时，调用数据库中的第二许可额度，补充第一许可额度， 在补充后判断模块1093判断出在所述许可额度调整模块109从所述 第二许可额度调用规定的转移额度后，请求额度依然不小于等于补 充后的第一许可额度时，由补充后拒绝模块1095拒绝该投注请求。 这样就保证了每次投注请求的处理过程中，调用数据库的操作最多 只有 一 次，从而从整体上确保了单次投注事务请求所需的时间。
优选的是，所述投注请求包含用至少两个限号单元以及用于计算 所包含的限号单元的权重的投注方式，
所述请求额度计算模块103还包括
请求额度分配模块1031，用于将请求额度根据由投注请求中包 含的投注方式计算得到的各限号单元的权重分配给限号单元确定模 块111所选择的各限号单元。
由此可知，通过请求额度分配模块1031，可以根据投注方式计 算得到各限号单元的权重，并依据所述权重将请求额度分配到各限 号单元。这样一次投注请求可以包含两个或两个以上的请求额度可能不同的限号单元，进而支持更复杂的彩票玩法。
优选的是，所述处理装置还包括
调整模块113，用于定时的和/或在投注请求处理完成后将第一许 可额度设为至少能满足一次投注请求所需的许可额度，调整第二许 可额度使第一许可额度和第二许可额度之和保持与投注请求处理完 成后一致。
由此，调整模块113保证了第一许可额度在每次投注请求处理完 成后被设为所述规定的转移额度。这样就保证了下次投注第一许可 额度中的第一许可额度大于请求额度。进而进一步减少了投注处理 过程中调用数据库的可能性。
优选的是，所述处理装置还包括
请求量累积记录模块115,用于在投注请求处理完成后将累积的 请求量记录在数据库2中。
动态许可额度模块117，在投注请求处理完成后和/或第二许可额 度小于等于所述请求额度时根据所记录的累积的请求量计算对应的 动态许可额度，并将所述第二许可额度补充所述动态许可额度。
由此可知，请求量累积记录模块115在投注请求处理完成后将累 积的请求量记录在数据库中，在投注请求处理完成后和/或第二许可 额度小于等于所述规定的转移额度时，动态许可额度模块117根据 所记录的累积的请求量计算对应的动态许可额度，并将所述第二预 设值补充所述动态许可额度。这样交易系统1可以根据请求量的记 录而准确的生成动态许可额度，从而实现了许可额度可以随着事务 处理的增加等变化而动态变化。并且通过投注请求和动态许可额度 的功能分离，即在投注请求处理完成后进行动态许可额度的计算， 既可以因为此时交易系统并没有处理投注请求而不影响到事务处理 的性能，又可以避免因为数据库记录失败等原因而导致生成错误的 动态许可额度。保证了数据库和交易系统各自的功能明确性。而动 态许可额度模块117在第二许可额度不满足请求额度时生成动态许 可额度，则可以避免因未能及时生成动态许可额度而许可额度不够
13用的情况出现。


图1为彩票全热线系统的架构图2为某个奖期中的一次投注过程的流程图3为交易系统1拆分投注请求的流程图4为检查交易系统限号池中各限号单元的许可额度的流程图5为记录投注的流程图6为两级限号池初始化的流程图7为彩票系统的结构示意图8为请求额度计算模块109的结构示意图9为许可额度调整模块103的结构示意图。
具体实施例方式
本发明实施方式的核心技术之一在于，釆用了两级限号池。 一级 限号池存在于交易系统1中，即交易系统限号池，用于在交易系统 中进行限号检查。交易系统限号池中的许可额度即为第一许可额度。 许可额度是所允许的额度。以彩票系统为例，许可额度可以是所允 许的限陪金额，也可以是由限陪金额转换得到的投注数，还可以是 由限陪金额转换得到的可销售金额。对于大多数不会超过第 一许可 额度的事务请求来说，限号检查的操作只需要在交易系统内部完成， 与不限号时相比基本避免了性能损失。另 一 级限号池存在于数据库 中，即数据库限号池。用于在交易系统限号池不足以满足某次事务 请求的要求时，向交易系统限号池注入许可额度。数据库限号池中 的许可额度即为第二许可额度。
因为绝大多数对投注请求的操作是在交易系统内部完成，只有交
号池中申请新的许可额度，所以既避免了频繁的读取数据库造成性 能损失，又由于数据库中的数据经过持久化避免了因交易系统崩溃而导致限号信息全部丟失的风险，实现风险可控。此外，两级限号 池的结构也提高了整个系统的可扩展性。可以满足为了更快的响应 交易请求或降低单个交易系统过大的压力，而需要多个交易系统同 时进行交易请求时对系统进行扩展的要求。以彩票为例，随着彩票 业务的发展，多交易系统1将是以后发展的主要趋势，对于彩票系
统，尤其是一些大型的，例如终端3遍布全国31个省并且有多种玩 法的彩票系统，对系统的性能、风险控制以及可扩展性有着越来越 高的要求。两级甚至多级限号池也将是本技术领域未来发展的主要 趋势。
本发明实施方式的另 一个核心技术在于，在两级限号池的基础 上，采取粒度作为数据库限号池向交易系统限号池注入许可额度的 策略。所述粒度即为规定的转移额度，是数据库限号池向交易系统 限号池单次注入的许可额度的值。该粒度通常是根据经验预先设定 的常量或者是根据彩票投注过程中的情况可进行调整的变量。利用 粒度控制了向交易系统限号池单次注入的许可额度的量，使得数据 库限号池是有控制的向交易系统限号池注入许可额度，而不会将剩 余的所有许可额度一次性注入单个交易系统限号池，进一步实现了 风险可控。此外，在多交易系统的情况下，采用粒度也可避免出现 单个交易系统限号池掏空上级限号池(即数据库限号池)的情况， 并且，通过设置合适的粒度大小，还可以避免一部分交易系统的许 可额度有剩余时，另一部分交易系统却无法取得所需许可额度的情 况，减少许可额度的浪费。
下面以将本发明的实施方式应用到彩票全热线系统为例，进行进 一步详细"i兌明。
彩票全热线系统的结构如图1所示，包括交易系统l、数据库2 和终端3。终端3可以是一个也可以是多个，在附图中以2个终端3 为例。交易系统1按规定的程序对终端3向交易系统1发出的投注 请求进行处理，在交易系统1中设了交易系统限号池(第一许可额 度)，在数据库2中设了数据库限号池(第二许可额度)。如图2所示，为终端3向交易系统1发出事务请求时，交易系统 l的流程图。其中包括以下步骤
步骤202,交易系统1收到终端3的投注请求(事务请求)。
步骤204，交易系统l拆分投注请求。限号单元是需要进行限号 控制的事务处理单元。在本实施例中限号单元是需要进行限制的可 投注单元。以通过对限号单元销量的控制，达到控制在最坏情况下 彩票销售方需要补贴的奖金金额的目的。在本实施例中， 一次投注 请求中通常会包括对多个限号单元的投注。因此对于包括多个限号 单元投注的投注请求，交易系统1首先需要对其进行拆分。
在另一个挂号系统的实施例中，限号单元是需要限制挂号数量的 专家号。
如图3所示为步骤204,交易系统1拆分投注请求的流程图。
步骤2042,交易系统1根据投注请求中所包含的投注的信息确 定投注的限号单元。
步骤2044,交易系统1根据投注方式计算投注请求中各限号单 元的请求额度。包括
步骤20442，按照事务请求计算与请求量对应的请求额度。在本 实施例中，许可额度为由限陪金额转换成的投注数。请求量即为本 次投注彩票的销售额。在本步骤中，将彩票的销售额转换为请求额 度，即所请求的投注数。当然，许可额度为限陪金额时，本步骤中 是将彩票的销售额转换为限陪金额。
步骤20444,将请求额度根据由投注请求中包含的投注方式计算 得到的各限号单元的权重分配给各限号单元。
对于一些复杂的彩票玩法，可能具有不同的投注方式，每种投注 方式的中奖金额不同，这样在拆分时就要引入"权重"的概念，对 不同的投注方式对许可额度的消耗量进行等价换算，即，将投注的 额度分配到各限号单元。以"排列三，，的中奖规则为例，"排列三" 具有"直选，，、"组选3"、"组选6"三种^:注方式，对号码123 采用"直选，，投注时，只有开奖号码为123时才能中奖，而如果是采用"组选6"投注时，则开奖号码为123/132/213/231/312/321时都 算中奖，所以拆分时将拆分到上述6个限号单元。显然"组选6"的 中奖概率是"直选"的6倍，所以奖金也应该为"直选"的1/6,即 "组选6"投注方式于每个限号单元的权重是"直选"投注方式的 1/6。也就是说，"组选6"投注方式同时覆盖了 6个限号单元，每 个限号单元的消耗量是"直选"投注方式的1/6,即"组选6"投注 方式的每个限号单元的"权重，，是"直选，，投注方式的1/6。以单次 开奖结果只会覆盖一个限号单元为例，如果以"直选"投注方式最 多可以投l，OOl注为例，那么"组选6"投注方式的话则最多可以投 6,006注。"组选3"投注方式也类似，在此不再赘述。当然，如果 单次开奖覆盖多个限号单元的话，则只需相应的将许可额度根据每 个限号单元的"权重"进行调整即可。当然，对于更复杂的彩票玩 法，同 一投注请求中不同限号单元的请求额度也可以是不一样的， 也可以根据每个限号单元的"权重"进行调整即可。在此就不再赘 述。
步骤206，检查交易系统限号池中各限号单元的许可额度。即， 判断请求额度是否小于等于交易系统限号池中的第一许可额度。将 一次投注请求拆分成限号单元后，需要对交易系统限号池中对应的 各个限号单元进行限号检查。在通过检查之后才可以进行下一步处 理。下文将对检查步骤进行详细介绍。
步骤208,通过检查之后，需要将交易系统限号池的许可额度相 应的减去将销售的投注数，以实时反应销售状况对限号池的影响。 在另一个实施例中，如果一次投注中包含多个限号单元时，各限号 单元需要减去的许可额度是根据权重计算得到的。
步骤210,通过上面步骤已经完成了限号的控制过程，这时需要 将投注内容持久化到数据库2中，即记录投注信息。
自此就完成了奖期中的一次投注过程。对于绝大多数不会超过限 号的投注请求来说，限号检查的操作只在交易系统1内部进行。与 不限号时相比基本上不会有性能损失。
17如图4所示，为步骤206，检查交易系统限号池中各限号单元的 许可额度的流程图。
步骤20602,读入投注请求中的第一个限号单元。
步骤20604,检查交易系统限号池中的读入的限号单元的许可额 度是否足够。即，对交易系统限号池中的读入的限号单元的许可额 度和所拆分出的限号单元的投注数进行比较。许可额度不足时，进 入步骤20606，许可额度足够时，进入步骤20610。
步骤20606,对于检查出的许可额度不足的限号单元，交易系统 限号池向数据库限号池申请新的许可额度。在本实施例中，交易系 统限号池向数据库限号池申请新的许可额度的额度为一个粒度。所 述粒度是根据经验预设的一个常量，通常是小于数据库限号池中的 许可额度剩余值但足够支持一定数量销售的许可额度额度。
在另一个实施例中，粒度是一个变量，会根据两级限号池的情况 而进行调整。例如， 一个粒度代表着数据库2中许可额度剩余值的 一定百分比。或者是所述常量和所述变量的组合。
在另 一个实施例中，数据库限号池收到新的许可额度的申请时， 会检查数据库限号池中的许可额度是否满足该申请。如果满足则向 交易系统限号池注入一个粒度的许可额度，如果数据库限号池中的 许可额度不足一个粒度的许可额度时，则返回数据库限号池中的剩 余许可额度。
在另 一 个实施例中，彩票全热线系统中有多个交易系统限号池， 还有一个在多个交易系统限号池和数据库限号池之间平衡的策略。 例如在数据库限号池收到 一个交易系统限号池新的许可额度的申 请，同时检查发现数据库限号池中限号单元的许可额度小于该新的 许可额度时，数据库限号池向其它的交易系统限号池申请一个或多 个粒度的许可额度。当然，也可以是数据库限号池的剩余许可额度 小于一个预设值(可以是一个或多个粒度)时，数据库限号池向其 它的交易系统限号池申请许可额度。
步骤20608，判断获得的新的许可额度是否足够。即，交易系统限号池中原许可额度剩余值加上获得的新的许可额度之和是否满足 所述许可额度不足的限号单元的投注需要，满足需要时，进入步骤
20610，不满足需要时，返回步骤20606再次申请许可额度，或者返 回"超出限号"的提示信息。本实施例中，为了不影响系统系能， 保证单次投注的应答时间在可接受的范围内，在申请一次新的许可
额度后，如果交易系统限号池仍然不满足该次投注需要则直接返回 "超出限号"。在返回"超出限号"后，终端3可以采用取消本次 投注的方法来解决问题。但是当然，随着硬件设备性能的提升或者 针对不同的应用环境，也可以在返回"超出限号"之前进行多次申 请。
步骤20610 20612,判断是否最后一个限号单元。"是"则进入 步骤208,"否"则交易系统1读入下一个限号单元后返回步骤 20604。
由此可知，对于绝大多数不会超过限号的投注请求来说，只需要 经过步骤20602、步骤20604和步骤20610，而不需要经过需要调用 数据库2的步骤20606。所以系统的性能上，尤其是单次投注的应答 时间基本不会有影响。而即使需要向数据库限号池申请新的许可额 度，也因为单次申请后还不满足投注需要就直接返回"超出限号"， 所以单次投注的应答时间也基本不受影响。而又因为除了步骤20606 以外，其它步骤都是读取数据、比较判断的简单操作，所以即使在 多个终端3同时向交易系统1发出投注请求时，进行限号检查也不 会给交易系统1带来很大的运行压力。而随着粒度策略的使用，又 很好的保证了限号池风险的可控性，并且为彩票系统提供了实现多 交易系统l的基础。
因为多个终端3可能同时发送投注请求，所以上述处理过程是并 发执行的。在另一个实施例中，上述处理过程开始之前先对即将影 响的限号单元进行独占锁定，这样能保证在步骤206与步骤208之 间锁定的限号单元的许可额度不会改变。
如图5所示，为步骤210记录投注的流程图。步骤2102，将此次投注持久化到数据库2中。
步骤2104-2106,判断操作是否成功，若"是"，则表示投注成 功结束本次投注流程，否则，将此次失败的投注所减去的许可额度 回补到交易系统限号池，回补后向终端3返回"投注失败"提示信 息。当然也可以回补到数据库限号池中。
在另一个实施例中，当投注被取消时，需要将所取消的投注所减 少的许可额度回补到数据库限号池或交易系统限号池中。
对于很多彩票系统来说，在开奖之后，将会开始新的一个奖期， 此时，需要进行奖期初始化。而同样的，在此过程中也需要对限号 池进行初始化。如图6所示，为两级限号池初始化的流程图。
步骤602,数据库限号池和交易系统限号池全部进行清空或者新 建限号池。在奖期开始前，需要将数据库限号池和交易系统限号池 全部进行清空，即设置所有限号池的所有限号单元的许可额度为零。 或者新建限号池，并在奖期结束时删除该限号池。
步骤604,数据库限号池获得初始许可额度。初始许可额度是通 过初始限赔额度计算出来的许可额度。初始限赔额度可以理解为"最 坏"情况下允许的赔付额度，可以是一个经验值，也可以是一个政 策性的固定值，也可以是对前几期销量和彩池大小计算出的 一 个值， 还可以根据对当期销量的预测设置放大系数。在本实施例中，彩票 系统根据经验预设一个初始许可额度给数据库限号池。以"排列三" 玩法为例，单注，，直选"投注方式的中奖金额为l，OOO元，假设初始 限赔额度为l,OOO，OOO元，那么"最坏"的情况即所有投注都投了同 一个号码并且中奖，所以对任一个号码(限号单元)允许的最大投注数 (许可额度)为l，OOO注(暂不考虑动态限号)。即初始限赔额度 1，000，000元转换成了 l，OOO个限号单元每个限号单元l，OOO注的许可额度。
步骤606，交易系统限号池从数据库限号池中获得初始许可额 度。在本实施例中，交易系统限号池从数据库限号池中获得的初始 许可额度可以是零或者一个粒度。当然，交易系统限号池获得的初
20始许可额度可以是不大于数据库限号池中投注许的任意值。也可以 是根据历史数据或者经验预设的。
自此完成了在奖期初始化时进行两级限号池初始化的步骤。
在另一个实施例中，在投注请求处理完成后，交易系统l将第一 许可额度设为所述规定的转移额度，即一个粒度，调整第二许可额 度使第一许可额度和第二许可额度之和保持与所述投注请求处理完 成后时的和一致。在投注请求处理完成后，将第一许可额度设为规 定的转移额度，既可以因为此时交易系统处于空闲状态而不补充单 次投注请求的处理时间，又可以使得第 一 许可额度能够满足下次投 注请求的请求额度，还可以控制风险在所述规定的转移额度范围内。
由于奖金来自投注所得，所以当销量上升时，所允许的最大许可 额度也应该相应增加。由销量产生的对限号池的贡献称为动态贡献。 动态许可即通过"由销量产生的可赔付金额"计算出来的许可额度。
仍以上面的排列三举例说明，假设排列三玩法的返奖率为50%,那 么上述1,000注投注将产生2,000元销量(每注2元)，其中1,000 元将按计划进行赔付，即该销量可以产生一个新的许可额度，此时 总许可=初始许可+动态许可=1，001。只要返奖率和中奖金额等设置
合理且投注内容分布均匀，那么动态许可将不断增加，可以保证投
注能继续进行下去。在另一个实施例中，数据库2定时重新计算许 可额度，使得动态贡献得以体现。其中，动态贡献的计算是由数据 库2完成的，而生成的新的许可额度也是注入数据库限号池中的。 通过这种功能的分离使得交易系统1的功能与数据分离开，保持了 数据库2与交易系统1各自的功能明确性。
本发明还相应的提供了 一种事务处理系统的处理装置，所述事务 处理系统由至少一台终端，交易系统和数据库构成，由所述终端向 所述交易系统发送事务请求，所述交易系统按规定的程序对所述事 务请求中包含的请求量计算出请求额度，在所述交易系统中设定第 一许可额度，在所述数据库中设定第二许可额度，所述第一许可额 度不足时，可从第二许可额度调用，以补充所述第一许可额度，
21所述处理装置包括
请求额度计算模块103,用于按照事务请求计算与请求量对应的 请求额度；
许可额度判断模块105,用于判断请求额度是否小于等于第一许 可额度；
第一许可额度扣除模块107,用于请求额度小于等于第一许可额 度时，将第一许可额度减去请求额度，接受该事务请求；
许可额度调整模块109,用于请求额度不小于等于第一许可额度 时，将第二许可额度减去规定的转移额度，将第一许可额度补充规 定的转移额度。
因此，只要将第一许可额度设定得大于可预计的请求额度，交易 系统就可独立的完成对事务请求的处理。这样对于大部分不会超出 第 一 许可额度的事务请求来说，并不需要调用耗时较多的数据库。 也就基本避免了事务处理过程中，因调用数据库所造成的处理能力 下降。同时，又因为第二许可额度被设定在数据库中，是经过持久 化处理的，所以，在交易系统因重新启动等可能丟失的许可额度就 被控制在第一许可额度的范围内。
在另一个实施例中，所述事务处理系统是彩票系统，所述事务处 理系统是彩票系统，所述彩票系统的可投注单元包括至少两个限号 单元，对于每个限号单元，在所述交易系统和所述数据库中分别设 定相应的第一许可额度和第二许可额度，所述事务请求是包含对各 限号单元进行投注的信,包、的投注请求。
如图7所示为彩票系统的结构图。
其中处理装置包括
请求额度计算模块103,用于按照事务请求计算与请求量对应的 请求额度；
许可额度判断模块105,用于判断请求额度是否小于等于第一许 可额度；
第一许可额度扣除模块107，用于请求额度小于等于第一许可额度时，将第一许可额度减去请求额度，接受该事务请求；
许可额度调整模块109,用于请求额度不小于等于第一许可额度 时，将第二许可额度减去规定的转移额度，将第一许可额度补充规 定的转移额度。
限号单元确定模块111，用于根据所述投注的信息所确定投注请 求中的限号单元，并选择相应的第一许可额度，第二许可额度。
彩票系统中可投注单元通常包括至少两个限号单元。由此，对于 彩票系统来说，通过分别为不同的限号单元相应的设置第 一许可额 度和第二许可额度，可以在交易系统接到投注请求时，利用限号单
元确定模块111确定限号单元，并选择对应的第一许可额度和第二 许可额度。
调整模块113,用于定时的和/或在每次投注请求处理完成后，将 第一许可额度设为至少能满足一次投注请求所需的许可额度，调整 第二许可额度使第一许可额度和第二许可额度之和保持与投注请求
处理完成后一致。
由此，调整模块113保证了定时的和/或在每次投注请求处理完 成后第 一 许可额度被设为所述规定的转移额度。这样就保证了下次 投注第一许可额度大于请求额度。进而进一步减少了投注处理过程 中调用数据库的可能性。
请求量累积记录模块115，用于在投注请求处理完成后将累积的 请求量记录在数据库2中。
动态许可额度模块117,在投注请求处理完成后和/或第二许可额
度小于等于所述请求额度时根据所记录的累积的请求量计算对应的 动态许可额度，并将所述第二许可额度补充所述动态许可额度。
由此可知，请求量累积记录模块115在投注请求处理完成后将累 积的请求量记录在数据库中，在投注请求处理完成后和/或第二许可 额度小于等于所述规定的转移额度时，动态许可额度模块117根据 所记录的累积的请求量计算对应的动态许可额度，并将所述第二预 设值补充所述动态许可额度。这样交易系统1可以根据请求量的记录而准确的生成动态许可额度，从而实现了许可额度可以随着事务 处理的增加等变化而动态变化。并且通过投注请求和动态许可额度 的功能分离，即在投注请求处理完成后进行动态许可额度的计算， 既可以因为此时交易系统并没有处理投注请求而不影响到事务处理 的性能，又可以避免因为数据库记录失败等原因而导致生成错误的 动态许可额度。保证了数据库和交易系统各自的功能明确性。而动
态许可额度模块117在第二许可额度不满足请求额度时生成动态许 可额度，则可以避免因未能及时生成动态许可额度而许可额度不够 用的情况出现。当然，请求量累积记录模块115和动态许可额度模 块117也可以是数据库2的子模块。 此外，交易系统l中还包括
投注请求接收模块119，用于接收终端3发送的投注请求。 第一许可额度模块101,用于保存第一许可额度。 业务逻辑模块121,用于按照规定的程序执行业务逻辑，完成投 注事务请求的处理，例如对投注请求中的投注内容进行合法性检查 等，进行一系列操作后将本次投注的内容更新到数据库2。
在另一个实施例中，如图8所示，所述许可额度调整模块109 还包括
补充后判断模块1093，用于在所述许可额度调整模块109从所 述第二许可额度调用规定的转移额度后，判断请求额度是否小于等
于补充后的第一许可额度；
补充后拒绝模块1095，用于请求额度不小于等于补充后的第一 许可额度时，拒绝该事务请求。
由此可知，许可额度调整模块109可以在请求额度不小于等于第 一许可额度时，调用数据库中的第二许可额度，补充第一许可额度， 在补充后判断模块1093判断出在所述许可额度调整模块109从所述 第二许可额度调用规定的转移额度后，请求额度依然不小于等于补 充后的第一许可额度时，由补充后拒绝才莫块1095拒绝该投注请求。 这样就保证了每次投注请求的处理过程中，调用数据库的操作最多
24只有 一 次，从而从整体上确保了单次投注事务请求所需的时间。
在另一个实施例中，所述投注请求包含用至少两个限号单元以及 用于计算所包含的限号单元的权重的投注方式，
如图9所示，所述请求额度计算模块103还包括
请求额度分配模块1031,用于将请求额度根据由投注请求中包 含的投注方式计算得到的各限号单元的权重分配给限号单元确定模 块111所选择的各限号单元。
由此可知，通过请求额度分配模块1031，可以根据投注方式计 算得到各限号单元的权重，并依据所述权重将请求额度分配到各限 号单元。这样一次投注请求可以包含两个或两个以上的请求额度可 能不同的限号单元，进而支持更复杂的彩票玩法。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明， 凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进 等，均应包含在本发明的保护范围之内。
2权利要求
1. 一种事务处理系统的事务处理方法，所述事务处理系统由至少一台终端，交易系统和数据库构成，由所述终端向所述交易系统发送事务请求，所述交易系统按规定的程序对所述事务请求中包含的请求量计算出请求额度，所述事务处理方法的特征在于，在所述交易系统中设定第一许可额度，在所述数据库中设定第二许可额度，所述第一许可额度不足时，可从第二许可额度调用，以补充所述第一许可额度，所述交易系统按以下步骤处理事务请求B，按照事务请求计算与请求量对应的请求额度；C，判断请求额度是否小于等于第一许可额度；D，请求额度小于等于第一许可额度时，从第一许可额度中减去所述请求额度，并接受该事务请求；E，请求额度不小于等于第一许可额度时，从所述第二许可额度调用规定的转移额度，以补充第一许可额度，在第一许可额度得到补充后，从第一许可额度中减去所述请求额度，并接受该事务请求。
2. 如权利要求l所述方法，其特征在于，所述事务处理系统是 彩票系统，所述彩票系统的可投注单元包括至少两个限号单元，对 于每个限号单元，在所述交易系统和所述数据库中分别设定相应的 第一许可额度和第二许可额度，所述事务请求是包含对各限号单元 进行投注的信息的投注请求，所述步骤B之前还包括A,所述交易系统根据所述投注请求中所包含的投注的信息确定 投注的限号单元；对相应的限号单元执行所述步骤B E。
3. 如权利要求2所述方法，其特征在于，所述步骤E还包括 El，在所述从所述第二许可额度调用规定的转移额度后，判断请求额度是否小于等于补充后的第 一许可额度；E2，请求额度不小于等于补充后的第一许可额度时，拒绝该投 注请求。
4. 如权利要求2所述方法，其特征在于，所述投注请求包含至 少两个限号单元以及用于计算所包含的限号单元的权重的投注方 式，所述步骤B后还包括B1 ，将请求额度根据由投注请求中包含的投注方式计算得到的 各限号单元的权重分配给各限号单元。依次对相应的限号单元根据各自分配到的请求额度执行步骤 C E。
5. 如权利要求2所述方法，其特征在于，所述规定的转移额度为设定的至少能满足 一 次投注请求所需的许可额度，或 第二许可额度的设定百分比数量。
6. 如权利要求2或5所述方法，其特征在于，定时的和/或在投 注请求处理完成后将第一许可额度设为所述规定的转移额度，调整 第二许可额度使第一许可额度和第二许可额度之和保持与所述投注请求处理完成后时的和一致。
7. 如权利要求2所述方法，其特征在于，所述交易系统在投注 请求处理完成后将累积的请求量记录在数据库中，在投注请求处理完成后和/或第二许可额度小于等于所述请求额 度时根据所记录的累积的请求量计算对应的动态许可额度；并将所 述动态许可额度补充到所述第二预设值中。
8. —种事务处理系统的处理装置，所述事务处理系统由至少一 台终端，交易系统和数据库构成，由所述终端向所述交易系统发送 事务请求，所述交易系统按规定的程序对所述事务请求中包含的请 求量计算出请求额度，所述处理装置的特征在于，在所述交易系统 中设定第一许可额度，在所述数据库中设定第二许可额度，所述第 一许可额度不足时，可从第二许可额度调用，以补充所述第一许可 额度，所述处理装置包括请求额度计算模块(103)，用于按照事务请求计算与请求量对 应的请求额度；许可额度判断模块(105),用于判断请求额度是否小于等于第 一i午可额度；第一许可额度扣除模块(107)，用于请求额度小于等于第一许 可额度时，将第一许可额度减去请求额度，接受该事务请求；许可额度调整模块(109)，用于请求额度不小于等于第一许可 额度时，将第二许可额度减去规定的转移额度，将第一许可额度补 充规定的转移额度。
9. 如权利要求8所述系统，其特征在于，所述事务处理系统是 彩票系统，所述彩票系统的可投注单元包括至少两个限号单元，对 于每个限号单元，在所述交易系统和所述数据库中分别设定相应的 第一许可额度和第二许可额度，所述事务请求是包含对各限号单元 进行投注的信息的投注请求，所述处理装置还包括限号单元确定模块(111)，用于根据所述投注的信息所确定投 注请求中的限号单元，并选择相应的第一许可额度，第二许可额度。
10. 如权利要求9所述系统，其特征在于，所述许可额度调整模 块(109)还包括补充后判断模块(1093 ),用于在所述许可额度调整模块(109) 从所述第二许可额度调用规定的转移额度后，判断请求额度是否小 于等于补充后的第一许可额度；补充后拒绝模块(1095 )，用于请求额度不小于等于补充后的第 一许可额度时，拒绝该事务请求。
11. 如权利要求9所述系统，其特征在于，所述投注请求包含用 至少两个限号单元以及用于计算所包含的限号单元的权重的投注方 式，所述请求额度计算模块(103)还包括请求额度分配模块(1031 ),用于将请求额度根据由投注请求中包含的投注方式计算得到的各限号单元的权重分配给限号单元确定 模块(111 )所选择的各限号单元。
12. 如权利要求9所述系统，其特征在于，所述处理装置还包括 调整模块(113),用于定时的和/或在投注请求处理完成后将第一许可额度设为至少能满足一次投注请求所需的许可额度，调整第 二许可额度使第一许可额度和第二许可额度之和保持与投注请求处 理完成后一致。
13. 如权利要求9所述系统，其特征在于，所述处理装置还包括 请求量累积记录模块(115),用于在投注请求处理完成后将累积的请求量记录在数据库(2)中。动态许可额度模块(117)，在投注请求处理完成后和/或第二许 可额度小于等于所述请求额度时根据所记录的累积的请求量计算对 应的动态许可额度，并将所述第二许可额度补充所述动态许可额度。
全文摘要
本发明公开了一种事务处理系统的事务处理方法，所述事务处理系统由至少一台终端，交易系统和数据库构成，所述交易系统按以下步骤处理事务请求A.按照事务请求计算与请求量对应的请求额度；B.判断请求额度是否小于等于第一许可额度；C.请求额度小于等于第一许可额度时，从第一许可额度中减去所述请求额度，并接受该事务请求；D.请求额度不小于等于第一许可额度时，从所述第二许可额度调用规定的转移额度，以补充第一许可额度，在第一许可额度得到补充后，从第一许可额度中减去所述请求额度，并接受该事务请求。还相应的提供了事务处理系统的事务处理装置。本发明既能更少调用数据库，又能将由交易系统异常导致的损失控制在一定范围内。
文档编号G06F9/46GK101482830SQ20091007957
公开日2009年7月15日 申请日期2009年3月10日 优先权日2009年3月10日
发明者刘百川, 吴壮伟, 滨 沈, 罗春水, 河 黄 申请人:中体彩科技发展有限公司