CN101669346A - 交易处理系统 - Google Patents

Abstract

一种包括多个分布式节点的系统的交易处理的方法，该方法包括以下步骤：在第一节点处接收消息，所述消息定义要对与实体相关联的数据执行的操作；将用于由在节点上运行的消息处理机处理的消息编入队列；在没有其它消息处理机正对该数据进行操作的情况下，允许该消息处理机处理该消息；以及将该消息转发给第二节点以进行后续处理。

Description

交易处理系统

技术领域

本发明涉及交易处理(transaction processing)，具体地，但不是排他性地，涉及一种用于处理博彩(betting)交易的方法和装置。

背景技术

交易处理系统在许多不同的环境中得到了应用，包括证券交易(exchange)系统、旅行预定系统和诸如在线对赌(betting exchange)的博彩系统。随着对于高速交易处理系统的需求增加，传统系统将费力地提供所需要的处理速率。

发明内容

根据本发明，提供了一种包括多个分布式节点的系统中的交易处理的方法，其中在多个数据分区(partition)中保存数据，相应分区中的数据与所述节点中的相应的单个节点相关联，该系统包括：用于控制一组数据分区的多个控制器，每个控制器包括多个用于对数据分区中的数据执行操作的写入级(stage)；以及用于向写入级分配执行线程的线程管理器，其中线程管理器被安排为分配用于对给定数据分区中的数据进行操作的至多单个线程，该方法包括以下步骤：在多个控制器中的第一控制器处接收消息，所述消息定义要对与给定数据分区相关联的数据执行的操作；将用于由所述多个写入级中的一个处理的消息编入队列，以及在执行线程可用于给定数据分区的情况下允许该写入级处理所述消息。

根据本发明，还提供了一种用于包括多个分布式节点的系统中的交易处理的装置，其中在多个数据分区中保存数据，相应分区中的数据与所述节点中的相应的单个节点相关联，该系统包括：多个用于控制一组数据分区的控制器，每个控制器包括多个用于对数据分区中的数据执行操作的写入级；以及用于向写入级分配执行线程的线程管理器，其中线程管理器被安排为分配用于对给定数据分区中的数据进行操作的至多单个线程，该装置包括：接收器，用于在多个控制器中的第一控制器处接收消息，所述消息定义要对与给定数据分区相关联的数据执行的操作；以及多个写入级，用于处理所述消息，其中，写入级被安排为在执行线程可用于给定数据分区的情况下处理多个消息中的一个，并且，在执行线程不可用的情况下，该装置被安排为将所述消息放置到队列中。

根据本发明的另一方面，提供了一种用于包括多个分布式节点的系统中的交易处理的方法，该方法包括以下步骤：在第一节点处接收消息，所述消息定义要对与实体相关联的数据执行的操作；将用于由在该节点上运行的消息处理机(handler)处理的消息编入队列；在没有其它消息处理机正对该数据进行操作的情况下允许所述消息处理机处理该消息；以及将该消息转发给第二节点以进行后续处理。

消息处理机包括多个处理只读取请求的第一消息处理机和多个处理读取-写入请求的第二消息处理机，其中多个只读取请求可并行地运行。

只有当读取-写入请求没有对与实体相关联的数据进行操作时，所述多个只读请求才可能运行以便对所述数据进行操作。在给定的时间，仅仅单个读取-写入请求可以对与实体相关联的数据运行。

该方法可以包括在接收时对所接收的消息进行日志记录(journaling)。

该方法可以包括将该消息与多个其它接收的消息进行批处理。该批处理可以取决于其被执行所在的处理级。可以依据网络等待时间(latency)、盘等待时间和要处理的实体中的至少一个来执行批处理。

消息处理机可以与多个实体相关联，并且该方法还包括依据消息去往的消息处理机来对消息进行分组。

可以在所述节点中的单个节点处存储关于与消息处理机相关联的多个实体的数据。可以在所述节点中的单个节点处存储关于单个实体的数据。

该实体可以包括与用户相关联的账户或者可以包括多个用户能够在其上放置彩注(place bets)的市场(market)。

可以异步地传送所述消息。

所述节点可以包括服务器。

根据本发明，还提供了一种用于包括多个分布式节点的系统中的交易处理的装置，该装置包括用于在第一节点处接收消息的部件，所述消息定义要对与实体相关联的数据执行的操作；用于将用于由在该节点上运行的消息处理机处理的消息编入队列的部件；用于在没有其它消息处理机正对该数据进行操作的情况下允许所述消息处理机处理该消息的部件；以及用于将该消息转发给第二节点以进行后续处理的部件。

该装置还可以包括线程管理器，用于向对单个账户或者单个市场进行操作的消息处理机分配单个线程，并且还可以包括预处理器，用于处理影响多个消息处理机的消息。预处理器可被安排为从多个日志消息流生成单个消息流。

该装置还可以包括用于响应于未接收到消息的通知而从第一节点向第二节点重新发送消息的部件。

该装置还可以包括用于对大量(heavily)请求的数据进行服务的数据分布器的群。

附图说明

现在将参照附图而作为示例来描述本发明的实施例，在附图中：

图1是通常的交易处理环境的示意图；

图2是图示在对赌系统的情境下交易处理系统的示意图；

图3是图示图2中所示的服务器的组件的示意图；

图4图示根据本发明的交易处理系统中的与账户和市场(market)有关的数据的分区；

图5是图示提供交易处理功能的软件模块的结构的示意图；

图6a图示形成根据本发明的交易处理系统的一部分的两个服务器之间的消息的正常交换；

图6b图示形成根据本发明的交易处理系统的一部分的两个服务器之间的消息的交换期间的消息丢失；

图6c图示形成根据本发明的交易处理系统的一部分的两个服务器之间的消息的交换期间的消息的重复消除(de-duplication)；

图7图示通过根据本发明的交易处理系统进行的交易的第一流程；

图8是图示在图2所示的服务器上运行以允许图7中图示的交易流程的交易处理模块的实例(instance)的示意图；

图9和10图示通过根据本发明的交易处理系统进行的交易的第二流程、以及在将第一和第二彩注(bet)匹配在一起时涉及的匹配处理；以及

图11是图示在图2所示的服务器上运行以允许图9和10中图示的交易流程的交易处理模块的实例的示意图。

具体实施方式

图1图示了通常的交易处理环境1。交易处理系统2是经由客户端(client)接口4与其它系统、应用或者用户进行通信的更大的功能系统3的一部分。客户端接口模块4可以具有多个子系统4a、4b、4c，用于从不同的源接收交易信息并且用于向交易处理系统2以及从交易处理系统2传递相关交易信息。交易处理系统2依据特定功能系统3的需求处理交易。例如，该功能系统可以是在其中交易处理系统对买入价(bid)和卖出价(offer)进行匹配的证券交易(exchange)系统，或者可以是在其中交易处理系统处理贷方金额(credit)和借方金额(debit)的银行系统。

图2图示了在对赌系统3的情境下的交易处理系统2。例如按照英国专利申请GB 2356071A中描述的来配置对赌系统以匹配相对立的彩注(opposingbets)。

对赌系统3包括通过例如防火墙5链接的客户端接口模块4和交易处理系统2。客户端接口模块4包括多个服务器400，其在此被称为客户端接口服务器，其利用客户端处理流入(incoming)和流出(outgoing)的通信。客户端可以是服务器应用，该服务器应用连接到构成对赌并且向交易处理系统提供彩注交易请求的各种系统。将客户端接口服务器400配置为接收由用户放置的彩注和/或相关联的下注(betting)信息请求消息，以及向交易处理系统2注入(inject)对应的请求消息。客户端接口服务器400还可以接收例如来自用户的、用于查看其可用于下注的(available-to-bet)账户余额(account balance)的请求消息或者来自用户的、用于查看其所有的当前活动的(active)彩注(bet)。还可以将客户端接口服务器400配置为从交易处理系统2接收消息并且向用户返回对应的消息。在此还将所述客户端接口服务器单独地称为服务器400a...n。

交易处理系统2高度分布在多个联网的服务器200(在此被称为交易处理服务器)上，并且被适配为从客户端接口服务器400接收消息。将交易处理系统2分布在多个服务器200上意味着在需要时能够通过进一步增加服务器来容易地和节省成本地扩展(scale)该系统。

参照图3，每个交易处理服务器200和每个客户端接口服务器至少包括一个处理器201/401、诸如RAM之类的存储器202/402、诸如硬盘之类的非易失性存储器203/403以及包括网络接口的I/O系统204/404。技术人员将理解每个服务器具有执行其功能必需的所有组件。在此还将处理交易服务器单独地称为服务器200a...n。交易服务器200a-c、200d-f的组可以与相应的共享盘6相关联。

交易处理系统2中的消息可以包括例如用于执行特定操作的命令、或者详述(detail)交易处理系统2中的特定的发生事件(occurrence)的事件。例如，命令消息可以是用于查看用户的可用于下注的账户余额的请求，而事件消息可以是向用户报告他们的彩注已被成功放置(place)的消息。

为了实现高交易速率，该分布式系统中的每个服务器200具有一定程度的数据本地化(locality)，以避免与对远程系统或者盘的网络调用相关联的开销(overhead)。这是通过利用用户账户以及利用博彩市场对交易处理系统2进行分区(partition)来实现的。将与单个用户账户有关的所有信息存储在单个服务器上并且将与单个博彩市场(market)有关的所有信息存储在单个服务器上。这减少了各个服务器对网络中的远程服务器或者非易失性存储器(例如，硬盘)进行网络调用的需要。以这样的方式，减少了交易处理系统中的等待时间(latency)并且增加了交易吞吐量(throughput)。尽可能地将数据存储在本地存储器中，或者至少存储在低等待时间的存储器中，从而减少对访问诸如联网的硬盘之类的高等待时间的资源的需要。

图4图示了在用于处理博彩交易的交易处理系统2中使用的账户10的集合(set)和市场11的集合。通过向用户显示的定价(pricing)屏幕而允许进行下注。给希望放置彩注的用户指配用户账户10，用户可以经由例如基于因特网的安全现金支付系统向该用户账户存钱。交易处理系统2给每个用户账户10指配其自己的唯一ID。

用户访问多个博彩市场11，在博彩市场11上用户可以针对所显示的赔率(odds)放置彩注。博彩市场11可以包括例如，诸如足球比赛或者赛马之类的运动事件的结果。如同上面讨论的用户账户10，交易处理系统2给每个博彩市场11指配其自己的唯一ID。

用户账户10的组12由各个账户控制器应用13控制。用于特定用户账户组12的账户控制器13在服务器200上操作，在存储器202中存储与该组中的用户账户有关的信息。与单个账户以及与关联于账户控制器的账户组有关的所有信息被存储在单个服务器上，或者由单个服务器所拥有。每个账户控制器13负责为其所指配的用户账户10上的请求服务并且负责提供所有账户中心(centric)功能。

例如，如果用户希望在其账户10上执行诸如放置彩注、加载其可用于下注的余额、查看其当前彩注的概况、或者计算其当前风险(exposure)(即在最坏情况的场景中，用户从其当前的彩注将会输(stand to lose)多少)的操作，则这些操作将通过所指配的账户控制器13来提供。可以通过访问用户账户10所位于的单个服务器200来对这些操作进行服务。例如，参照图2，账户控制器的单独的实例在服务器200a-c中的每一个上运行，处理在各个服务器上存储的账户。

类似地，博彩市场11由很多市场控制器应用14来控制，每个市场控制器14负责博彩市场11的组15。如上所讨论的，用于特定博彩市场11的市场控制器14在服务器200操作，在存储器202中存储与该博彩市场11有关的信息。与单个市场以及与关联于市场控制器的市场组有关的所有信息被存储在单个服务器上，或者由单个服务器所拥有。市场控制器14负责提供所有市场中心功能。这些功能可以包括以下将讨论的彩注匹配(bet-matching)。例如，再次参照图2，市场控制器的单独的实例在服务器200d-f中的每一个上运行，处理在各个服务器上存储的市场信息。

将在每个服务器400、200上同时运行的线程(thread)的数量保持为最小；这帮助维持高交易速率，因为不需要每个服务器400、200的处理器401、201在大量线程之间共享其处理时间。通过采用主要为异步的消息发送类型(predominately asynchronous messaging style)来将交易处理系统2所使用的线程计数(count)保持为低。因此，取代每次将消息注入到交易处理系统2中都分配用于处理的线程，所接收的消息被保存在入站队列(inbound queue)上，并且在被处理之前必须等待线程从另一操作变得可用。以下更详细地描述本发明的线程管理方面。

根据本发明的交易处理系统2采用以下架构，在该架构中，其被划分为由消息队列连接的处理级(stage)的流水线(pipeline)。总地来说，一级包括：用于入站事件的源队列、用于处理事件的事件处理机(handler)、用于监视该级的组件并且向容留(host)该级的线程管理器提供处理探索(heuristics)的资源控制器的集合、以及出站(outbound)队列或转发器(sink)的组。以下关于图5至图10进一步描述该基于级的架构。

资源控制器包括批处理(batching)资源控制器模块，其功能是通过相对于彼此而折衷来满足等待时间和吞吐量目标。通过降低在每级迭代(iteration)期间处理的消息批次(batch)大小可以改善等待时间而损害吞吐量。通过增加消息批次大小能够改善吞吐量。批处理资源控制器监视每级迭代所花费的时间(等待时间)以及每秒处理的消息的数量(吞吐量)并且相应地调整入站消息队列上的批次大小。

能够对系统中的每一级应用批处理资源控制器来控制入站的批次大小。

除了通过批处理资源控制器提供的批处理之外，还能够根据正在操作的数据来对消息进行批处理。通过将相似的消息分组在一起，每一级可以在内部批处理。例如，在以下详细描述的登记器(booker)级可以根据消息涉及的账户来对消息进行批处理。处理对相同账户或者相同市场操作的多个消息能够比分开处理每个消息更快。

如在GB2356071A中描述的，希望放置彩注的用户可以选择“支持(back)”特定结果或者“放弃(lay)”特定结果，即打赌该结果将不会发生。然后，可以针对彼此而匹配“支持”特定结果的彩注和“放弃”特定结果的彩注。通过以这种方式匹配相对立的彩注，交易处理系统2允许用户针对彼此而不是针对传统的彩注登记人(bookmarker)下注。这向博彩者(punter)提供了更灵活的方法，因为他或者她可以设置其愿意在其上下注的精确的项目(term)(例如，赔率、钱的最大量)。一旦放置了用户的彩注，就在未匹配的彩注池(pool)中放置用户的彩注，所述未匹配的彩注池可以被存储在相关市场控制器14所位于的服务器200上的存储器201中。交易处理系统2搜索该池以找到相对立的匹配。如果不存在可用的匹配，即，没有其它用户放置了可针对该用户报出的项目而匹配的彩注，则该彩注保留在未匹配的池中。以下将更详细地解释交易处理系统2中的彩注匹配的处理。

当用户在博彩市场11上决定“支持”或者“放弃”特定的结果时，在客户端接口服务器400处接收到详述该用户的彩注的消息。然后客户端接口服务器400生成被称为PlaceBetRequest(放置彩注请求)消息的消息并且将该消息注入到交易处理系统2，该消息给出了用户愿意向另一个博彩者报出(offer)的项目的细节。PlaceBetRequest消息将指明在其上报出彩注的市场、该彩注是“支持”还是“放弃”特定的结果，用户愿意下注的钱的量以及用户愿意下注的赔率。将交易处理系统2配置为处理PlaceBetRequest消息并且优选地将其针对已由另一用户放置的相对立的PlaceBetRequest消息进行匹配。比如，可以将期望支持特定结果的第一用户的PlaceBetRequest消息针对来自期望放弃相同结果的第二用户的PlaceBetRequest消息进行匹配。

以下将与图5至图10相关地借助于图示由第一用户和第二用户通过交易处理系统2放置的两个相对立的PlaceBetRequest消息的流动路径来更详细地描述该处理。

将与多个软件模块相关地描述该处理，这些软件模块在此被称为指引器(director)31、账户控制器41、61和市场控制器51。账户控制器41、61和市场控制器51是图4中所示的账户控制器模块13和市场控制器模块14的具体实例。

图5图示了适配用于作为核心交易处理应用的账户控制器和市场控制器两者的总体结构。虽然这些应用包括不同的逻辑和具有不同的职责，但它们共享用于处理交易的共同方法。

该结构包括：在接收器线程管理器模块(接收器线程管理器)112的控制下操作的接收器模块(接收器)110；在经调度(scheduled)线程管理器117的控制下操作的确认器(acknowledger)模块(确认器)115；在单线程管理器模块(单线程管理器)122的控制下操作的日志器(journaler)模块(日志器)120以及预处理器模块(预处理器)125；数据分区130；在分区线程管理器模块(分区线程管理器)145下操作、包括经分区的读取级140和经分区的写入级150的经分区消息处理机140、150；在经调度线程管理器模块(经调度线程管理器)162下操作的重发器(resender)模块(重发器)160；以及也在单线程管理器122下操作的调遣器模块(调遣器)170。

接收器110被安排为从网络读取消息并且将它们去串行化(deserialize)。接收器线程管理器112等待入站网络事件，继而在足够的网络数据到达以形成预定的批次时调用接收器110。接收器110负责对消息进行重复消除(de-duplicate)，换言之，丢弃之前见过的任何消息。重复消除的必要性产生于重发器160的功能，这将在以下进行详细描述。作为结果的去串行化后的消息被发送给日志器120。消息的串行化的形式也被保持并且被发送给日志器120。

日志器120负责将消息写入服务器硬盘403或者共享盘6上存储的日记(log)中。消息的日记记载(logging)意味着在故障期间，能够重放日记并且恢复(restore)故障时的存储器的状态。需要以与处理所述消息的顺序相同的顺序来重放所述消息以确保确定性的复原(recovery)。为了实现这个，由日志器120对每个消息指配序列号，使得到达调遣器的消息能够根据它们到达日志器的顺序而被重新排序。

预处理器125通过在经分区的操作之前在单个线程上处理全局消息来帮助复原处理，以下对经分区的操作详细描述。如果使用多于一个的日志器120，则预处理器125提供单个点，在该点上多个日志消息流被接合(coalesce)回单个串行流。预处理器还处理将影响所有经分区的级的诸如“系统在线”或者“系统离线”之类的串行消息。

日志器120在单线程管理器122之下操作，就像预处理器125和调遣器170那样。该线程管理器等待形成一批次的预定数量的消息到达其入站队列，继而调用(invoke)合适的级。仅仅串行地调用级，并且无论何时在任何一个时刻只能有一级的单个实例运行，都应用该线程管理器。

日志器120经由预处理器125将消息继续发送到经分区的写入级150。

经分区的写入级处理交易阶段(stage)并且对数据分区130中的数据进行操作。在账户控制器的情况下，数据分区表示账户10。在市场控制器的情况下，数据分区表示市场11。经分区的写入级包括读取/写入应用业务逻辑。例如，图6中所示的风险器(exposer)44和登记器45是用于账户控制器模块的经分区的写入级，而图6中所示的匹配器54是用于市场控制器模块的经分区的写入级。

用于账户控制器模块的其它经分区的写入级包括账户创建器、账户编辑器和账户删除器，以及彩注删除器。例如，账户创建器接受“创建账户”消息并且以账户数据结构存储该新的账户。与市场控制器相关地，其它经分区的写入级包括市场创建器、市场编辑器和市场删除器。例如，市场创建器接受“创建市场”消息并且以市场数据结构存储该新的市场。

分区线程管理器145管理线程向经分区的写入级的分配以确保每个账户或者每个市场分配最多一个线程。其允许具有确定性(determinism)的并行性(parallelism)，这意味着能够跨越线程和处理器对系统进行扩展，但是在发生故障的情况下，确定性的重放意味着系统将总是返回到其在故障之前所处的状态。

例如，在消息到达要对数据A执行读取/写入操作的级150a、b、c之一时，该级从线程池获取用于执行的线程并在该线程中处理数据A。当该写入级正对数据A进行操作时，没有其它的级能够对相同的数据A进行操作，因而确保改变被彼此隔离开并且不存在分布的锁定(lock)。将到达以便对数据A执行操作的消息编入队列，直到对数据A进行操作的线程被释放为止。然而，经分区的写入级150a、b、c能够使用并行的执行线程来对其它数据操作，使得相同或不同的写入级能够与数据A并行地处理数据B和C。

经分区的读取级140也从接收器110接收消息并且包含只读应用业务逻辑。在这种情况下，能够在任意时刻利用多个经分区的读取级来对数据分区进行操作，只要经分区的写入级没有正在对它们进行操作即可。例如，如果写入级正在对数据A进行操作，则分区线程管理器将对于数据A的读取或写入请求编入队列。然而，如果读取级正对数据A进行操作，则对其它读取请求分配线程以对数据A进行操作。类似地，将所接收的写入请求编入队列直到完成当前读取请求为止。

经分区的读取级的示例包括账户加载器(loader)和市场加载器，账户加载器接受“加载账户”消息并且返回具有从账户数据结构加载的账户的“账户已加载”消息，市场加载器执行用于市场的对应功能。

重发器160从经分区的写入级150接收消息。如以下更详细地描述的，重发器的目的是重复地将消息调遣到网络上直到其被告知停止为止，从而确保消息的有保障的传递。这在出现故障的情况下有优势，因为消息不会被丢失，而是将在队列中建立(build up)，直到例如通过更换服务器而修复故障为止。然后，继续处理所述消息。重发器在经调度线程管理器162的控制下操作。该线程管理器在从其入站队列中将消息移出队列(dequeue)之前等待某个量的时间过去。

调遣器170接收来自重发器160和经分区的读取级140的消息以及来自确认器115的消息，确认器115的功能将在以下描述。调遣器170对消息进行串行化并且将它们写入到网络。

当日志器保存用于在出现故障的情况下重放的事件的重做(redo)日记时，通过将状态刷(flush)到非易失性存储器而附加地执行检查点标记(check-pointing)。需要检查点标记以允许周期性地清除(clear down)日志并且确保复原次数不会过多。在出现故障的情况下，能够从上一个检查点开始重放(replay)该状态。

上述的每个模块执行的操作能够并行地进行，使得在日志器处理从接收器接收的消息的同时以及在调遣器对先前接收的消息进行串行化的同时，接收器读取消息并对消息去串行化。

图6a到6c图示了用于提供服务器之间的有保障的消息传递的处理。例如，在图6a中所示的正常操作中，服务器A处的调遣器170依据发送计数器设置消息序列(sequence)值，例如，设置序列值“1”，并且向服务器B处的接收器110发送消息(步骤s100)并在缓冲器中存储该消息以防需要重新传送该消息(步骤s101)。在接收时，服务器B处的接收器110递增接收计数器(步骤s102)。服务器A向服务器B发送第二消息2(步骤s103)并且存储该消息(步骤s104)。在接收端，服务器B递增其接收计数器(步骤s105)。服务器B处的确认器115周期性地运行从而收集还未被确认的消息，并且生成对于这些消息的确认消息ACK。因而，在这个示例中，确认器115(经由调遣器170)向服务器A发送对于第一消息的ACK消息(步骤s106)。服务器A从其缓冲器中清除消息1和2并且递增发送计数器到值2。在下次发送时，调遣器为该消息指配下一序列号，在此情况中是“3”。

图6b图示了丢失消息的情况。服务器A处的调遣器170再次向服务器B处的接收器110发送具有序列号1的消息(步骤s110)并且在缓冲器中存储该消息以防需要重新传送该消息(步骤s111)。然而，在传送中该消息丢失。随后，服务器A向服务器B发送消息2(步骤s112)并且存储该消息(步骤s113)。在接收到该消息之后，服务器B注意到其接收计数器被设置为零，而消息编号是2。因此，接收器生成包含计数器(counter)‘0’的‘未确认’NACK消息，该‘未确认’NACK消息由调遣器传送回服务器A(步骤s114)。服务器A处的重发器160通过以图6a中描述的方式重新传送所有具有大于0的计数器的消息来响应NACK消息(步骤s115)。

图6c图示了重复消除的处理。如图6a中的步骤s100到s105中图示的，成功地发送了第一和第二消息(步骤s120至步骤s125)，导致服务器B处的接收计数器被设置为‘2’。然后，服务器B处的确认器115生成确认消息ACK并且将其(经由调遣器170)发送到服务器A(步骤s126)。然而，在传送中该消息丢失。服务器A在超时(timeout)时段内未接收到ACK消息，服务器A重新传送消息1(步骤s127)。服务器B接收该消息。然而，由于其接收计数器处于2，因此其意识到其已经接收过该消息并且丢弃该消息(步骤s128)。对于消息2出现相同的处理(步骤s129，s130)。然后服务器B发送包含计数器2的ACK消息(s131)，并且服务器A清除其缓冲器并且将其发送计数器设置为2(步骤s132)。然后，该处理可以如图6a所示的那样继续进行。

图7图示了在交互以处理彩注请求消息的各种模块之间的相互关系。如以下将更详细地描述的，这些模块在不同的服务器上运行。从以下的描述中很清楚的是不使用客户端-服务器模型处理交易，其中在客户端-服务器模型中，在客户端和服务器之间建立连接并且通信在它们之间向前和向后传送。作为替代，客户端向第一节点或者服务器传送消息。如果需要进一步处理，则在关于所请求的交易的消息被返回到客户端之前，第一服务器将该消息中继到第二服务器，然后到第三服务器，等等。

在出现例如运行账户控制器实例的服务器的模块的故障的情况下，消息将不会丢失，而是将在队列中建立，直到例如通过更换该服务器而修复故障为止。然后将继续处理该消息。

参照图7和图8，当第一用户希望放置彩注时，在此被称为发起器(Initiator)的软件模块21生成第一PlaceBetRequest消息。PlaceBetRequest消息包括以下数据，该数据例如为用户的用户账户ID 2、他们希望在其上投放彩注的市场的ID 3、用户正在其上下注的结果的ID以及他们希望“支持”还是“放弃”、他们希望下注的钱的量、以及他们愿意下注的赔率。

参照图8，发起器21在例如J2EE应用服务器的应用服务器400a上运行，该服务器是作为客户端接口服务器的服务器400的集群(cluster)中的一个。该集群的客户端接口服务器400负责将所有的彩注请求注入交易处理系统2。该客户端接口服务器400的集群还负责注入与博彩系统相关联的其它请求和消息，例如，用于加载用户的可用于下注的余额的请求或者用于查看用户的当前活动的所有彩注的请求。

所生成的PlaceBetRequest消息与发起器21创建的其它请求和消息一起被放置在入站队列上，并且去往在此被称为执行者(Executive)22的软件模块，该执行者22在与发起器21相同的客户端接口服务器400a上运行。执行者22包括若干处理级。这些级的第一级是被称为执行器(Executor)23的处理级，其被PlaceBetRequest所调用。执行者22还包括在此被称为接收器24的处理级和在此被称为调遣器25的处理级。将执行器23配置为将消息分批地从入站消息队列中移出队列，以及在由线程管理器应用(未示出)分配的线程上处理消息。线程管理器可以位于交易处理服务器200中的一个上。以上已经参照图5解释了分配线程的方式。

以下将提供对于在处理交易系统2中处理异步请求的详细描述。

PlaceBetRequest消息是异步请求。异步请求的使用意味着发起器21在重新开始(resume)其经调度的操作之前不必等待来自执行者22的执行器23的确认消息。异步消息可以被用于以下描述的并且在图7至图11中所示的交易处理系统2的所有级中。

包含PlaceBetRequest消息的消息批次中的消息的数量由以上提到的在此被称为批处理资源控制器(BRC)23a的软件模块来控制。

参照图7，随后通过执行器23将所接收的PlaceBetRequest消息转发给调遣器25(步骤s2)。执行器23通过将该PlaceBetRequest消息与去往调遣器25的任何其它请求或消息一起编队(enqueue)到调遣器25的入站队列中来执行这一操作。这些其它请求或消息也可能来源于发起器21。由于PlaceBetRequest消息是异步请求，因此，随后执行器23可以继续其操作。它不必等待来自调遣器25的确认消息。

调遣器25从其入站队列中将该消息批次中的PlaceBetRequest消息移出队列。由与调遣器25相关联的、在此被称为批处理资源控制器25a的控制器模块25a来确定和指示批次大小。如上面关于批处理资源控制其23a所述的，该控制器模块被配置为监视调遣器25的操作并且调整在每个消息批次中处理的请求和消息的数量。分批地将消息和请求移出队列允许调遣器25(以及交易处理系统2中的所有其它级)最大化消息吞吐量，这是由于处理一批中的多个请求和消息允许执行高速缓存(cache)本地化和任务聚合(aggregation)。然而，如上所讨论的，如果分批因子(batching factor)变得过大，将显著地延长对(等待对他们的彩注请求的响应的)用户的响应时间。

交易处理系统2中的所有批处理资源控制器以相同的方式操作。然而，取决于所抵达的级，能够基于不同的标准来执行批处理。例如，在接收器级，批处理能够基于网络等待时间，在日志器处其能够基于盘等待时间，而在风险器处，其能够基于每个账户的请求数量。尽管在该示例中，单独的批处理资源控制器与每一级相关联，但是在可替换的实施例中，可以在每个服务器上存在单个批处理资源控制器，其负责控制该服务器上所有的批处理操作。为了清楚起见，在该实施例中没有将批处理资源控制器示出为与每一级相关联。在以下的描述中，下面还将使用术语“转发”和“接收”来描述操作，然而将理解的是这些操作涉及队列编排(queuing)和批次控制。

由调遣器25移出队列的消息被划分为组以允许分批地处理它们。将PlaceBetRequest消息与去往被指配给促使发起器21生成该PlaceBetRequest消息的用户的用户账户的账户控制器41的所有其它消息一起批处理。如之前所述的，被指配到该批次的其它消息可以包括其它PlaceBetRequest消息、用以查看用户的可用于下注的余额的请求等等。

在此级，执行者22不知道图4中所示的账户控制器13中的哪一个被指配给用户的用户账户10，因此不知道将PlaceBetRequest消息调遣到哪里。因此调遣器25生成LocateInstanceRequest(定位实例请求)消息(步骤s3)以便查明正确的账户控制器41。同时，PlaceBetRequest消息被存储在执行者22处以用于随后的传送。例如，可以在位于客户端接口服务器400a上的存储器402中存储PlaceBetRequest消息。如上所讨论的，包含PlaceBetRequest消息的批次中的所有的消息都去往相同的账户控制器41，因此只需要为该批次生成单个LocateInstanceRequest消息。该LocateInstanceRequest与去往指引器31的任何其它消息(例如，与其它用户账户相关联的LocateInstanceRequest消息)一起被编队到队列中。

指引器31包括接收器级32、定位器级33和调遣器级34。它还以与其它模块对应的方式包括日志器(未示出)，但是这为了清楚起见而被省略。参照图8，指引器31可以在作为所述集群的交易处理服务器200中的一个的服务器200g上运行。接收器32将消息批次中的LocateInstanceRequest消息移出队列。

接收器32将LocateInstanceRequest消息与去往定位器33的所有其它消息一起编队到队列中(步骤s4)。然后，在批处理资源控制器33a的控制下，定位器33将消息批次中的所述LocateInstanceRequest消息与例如其它LocateInstanceRequest消息一起从所述队列中移出队列。定位器33被配置为从指引器31所位于的服务器220g的存储器202中存储的列表中查找被指配给在LocateInstanceRequest消息中指明的用户账户的账户控制器41的地址。然后定位器33创建包含所指配的账户控制器41的地址信息的LocateInstanceReply(定位实例答复)消息(步骤s5)，并且将该消息与去往指引器31的调遣器级34的任何其它消息一起编队。

LocateInstanceReply消息由调遣器34移出队列，并且与去往执行者22的接收器24的任何其它消息一起被编队到队列中(步骤s6)。一旦被接收器24移出队列，LocateInstanceReply消息就被转发给调遣器25的入站队列(步骤s7)。

在这一级，从客户端接口服务器400a的存储器401中检索(retrieve)触发了LocateInstanceReply消息的悬而未决的(pending)PlaceBetRequest消息并且将其转发给在LocateInstanceReply消息中指明的账户控制器41。账户控制器41的地址由执行者22高速缓存(cache)以避免任何进一步的查找(lookup)。账户控制器可以在作为交易处理服务器200中的一个的服务器200a上运行。服务器200a是在其上存储与用户的用户账户相关的所有数据的服务器。

类似于执行者22和指引器31，账户控制器41包括接收器级42和调遣器级46。账户控制器41还包括日志器级43、风险器级4和登记器级45。PlaceBetRequest消息由接收器42接收(步骤s8)并且被转发给日志器43的入站队列(步骤s9)。

账户控制器41的处理级以与上面关于执行者22和指引器31的级描述的方式类似的方式操作。从消息的入站队列中将消息移出队列。前一处理级已将入站队列上的消息放置在那里。然后处理该消息，并且将其放置在下一级的入站队列上或将其用于创建新的消息，该新的消息被放置在下一级的入站队列上。这些处理在此被总称为编队和移出队列。

在日志器43处，PlaceBetRequest消息被附加到例如可存储在共享硬盘6上的非易失性日记中。可替换地，它可以被存储在每个服务器200内的硬盘203处，由此提高每个服务器200上的日记中存储的信息可以被复原的速度。在用于在需要时重放的日记中，PlaceBetRequest消息被赋予了唯一的序列号。

以此方式对接收的消息进行日志记录意味着在系统故障的情况下，交易处理系统2可以返回到明确的点，即所接收的消息最后由账户控制器41的日志器43记录所在的级。从日志器43向风险器44转发PlaceBetRequest消息(步骤s10)。

在风险器级44处，处理PlaceBetRequest以计算该彩注的最大可能风险，这是作为确定当用户支持或者放弃特定结果时用户的最大债务(liability)的计算。例如，如果彩注是以2/1的赔率(数字赔率3)“支持”特定结果，并且奖金(stake)为5英镑，则如果用户打赌输了则他们将会失去5英镑。然而，如果彩注是以2/1的赔率“放弃”特定结果，并且最大彩注为5英镑，则当用户打赌输了则他们将会失去10英镑。

风险计算由风险器44执行并且被分批地处理。因此，如果存在对于特定用户账户的多个PlaceBetRequest消息，则将在单个操作中计算所有彩注的风险。

风险器级44针对用户的用户账户的可用于下注的余额来检查所计算的风险。如果用户账户包含足够的钱以偿付(cover)用户的一个或多个活动彩注的风险，则风险器44创建MatchBetRequest(匹配彩注请求)消息并且将MatchBetRequest消息转发给调遣器46(步骤s11)。如果用户账户未包括足够的钱以偿付彩注的风险，则可以经由执行者22和发起器21将消息返回给用户以通知该用户在其账户中可用的资金不够了。

调遣器46处的处理与上面参照执行者22的调遣器24所述的处理类似。账户控制器41不知道哪一个市场控制器14被指配给由MatchBetRequest指明的博彩市场11。因此调遣器46创建LocateInstanceRequest消息并且将其发送给指引器31(步骤s12)，指引器31将消息转发给定位器33(步骤s13)。定位器33以与上面关于账户控制器41的查找所述的方式类似的方式从列表中查找指配的市场控制器51。同时，MatchBetRequest消息被存储在账户控制器41处用于随后的传送。例如，可以在位于账户控制器41所位于的服务器200上的RAM 202中存储MatchBetRequest消息。定位器33定位所指配的市场控制器51，定位器33将LocateInstanceReply消息转发给调遣器34(步骤s14)。在由指引器31的调遣器34创建的LocateInstanceReply消息中将市场控制器51的地址转发给账户控制器41的接收器42(步骤s15)。

然后LocateInstanceReply消息由账户控制器41的接收器42转发给调遣器46(步骤s16)。在这一点处，从服务器200上的存储器201中检索触发了LocateInstanceRequest消息的悬而未决的MatchBetRequest消息，并且由调遣器46将其转发给正确的市场控制器51(s17)。如同账户控制器41，市场控制器51的地址被执行者22高速缓存以避免再次查找其地址的需要。

如在图8中所示，市场控制器51位于作为交易处理服务器200之一的服务器200d上，并且其包括接收器级52、日志器级53、匹配器级54以及调遣器级55。如同关于执行者22、指引器31和账户控制器41所描述的，市场控制器51的级对消息进行编队和移出队列。该MatchBetRequest消息被接收器52接收并且被转发给日志器53(步骤s18)。在日志器53处，以与关于账户控制器41的日志器43处的PlaceBetRequest消息的日记记录描述的方式类似的方式，将MatchBetRequest消息附加到例如在硬盘上存储的非易失性日记中。如之前所讨论的，例如，非易失性日记可以存储在市场控制器51所位于的服务器200d上，或者可以存储在共享盘6或经由网络连接而连接到市场控制器51的另一盘中。然后将MatchBetRequest消息转发给匹配器54(步骤s19)。

在匹配器54处，MatchBetRequest消息使匹配器54触发对已经放置在该博彩市场3上的任何未匹配的彩注池的仔细搜索。可以在例如作为服务器200d的一部分的存储器202中存储未匹配的彩注池。该搜索的目的是找到报出与由MatchBetRequest消息所报出的项目(term)的彩注相对立的项目的彩注。在这个示例中，彩注池是空的，因此不存在可用的可匹配彩注。因此将用户的彩注添加到未修改的未匹配的彩注池中。然后匹配器54创建详述有关该彩注的匹配处理的消息的MatchBetReply(匹配彩注答复)消息。在该情况下，由于池是空的，因此MatchBetReply消息详述不存在该彩注的可用匹配。

分批地执行彩注的匹配；如果在特定的博彩市场11上存在多个MatchBetRequest，则将在单个操作中进行对于所有MatchBetRequest的匹配处理。

通过匹配器54将MatchBetReply消息转发给调遣器55(步骤s20)，调遣器55继而将该消息转发给账户控制器41的接收器42(步骤s21)。接收器42将MatchBetReply消息转发给日志器43(步骤s22)，在日志器43处，MatchBetReply消息在被转发给登记器45(步骤s23)之前被附加到非易失性日记中。

在登记器45处，例如，使用MatchBetReply消息中包含的信息来将用户的彩注状态从“未处理”更新为“已处理”。登记器45还被配置为存储任何匹配信息。然而，在该MatchBetReply消息的情况中，由于在彩注池中不存在合适的MatchBetRequest，因此不存在匹配信息。例如，可以在诸如运行账户控制器41的服务器200a上的RAM之类的存储器202中存储用户彩注的状态。登记器45创建PlaceBetReply(放置彩注答复)消息并且将其转发给调遣器46(步骤s24)。PlaceBetReply从调遣器46经由接收器24被转发给执行者22的执行器23(步骤s25、s26)。

在这一点处，将PlaceBetReply消息放置在发起器21的入站队列中，准备被移出队列(步骤s27)。然后可以将彩注放置的结果经由发起器21返回给用户。

参照图9和图10，第二用户经由用户网站放置与第一用户放置的彩注相对立的彩注。这使得将第二PlaceBetRequest消息注入执行者22的执行器23(步骤s1)。第二PlaceBetRequest消息遵循贯穿交易处理系统2的路径，如上面关于与第一用户的彩注相关联的PlaceBetRequest消息的通路(passage)描述的那样。步骤s1至s19与上述的那些步骤相同。

如之前关于与第一用户的彩注相关联的MatchBetRequest消息所讨论的，当抵达市场控制器51中的匹配器54时，与第二用户的彩注相关联的MatchBetRequest消息使匹配器54触发在RAM 202中存储的未匹配的彩注池中对于与该MatchBetRequest消息的潜在匹配的搜索。这一次，搜索成功了并且与第二用户的彩注相关联的MatchBetRequest和与第一用户的彩注相关联的第一MatchBetRequest匹配。

然后匹配器54生成详述关于该匹配的信息的MatchBetReply消息，并且将MatchBetReply消息转发给调遣器55(步骤s20a)，然后转发给被指配给第二用户的用户账户的账户控制器61的接收器62(步骤s21a)。参照图11，账户控制器61位于作为形成交易处理系统的服务器200的网络之一的服务器200b上。服务器200b是在其上例如在RAM 202中存储与第二用户的用户账户相关联的所有信息的服务器。

然后，MatchBetReply消息以图9中所示的方式流过交易处理系统2。这类似于关于与第一用户的彩注相关联的MatchBetReply消息的流动描述的方式。具体地，通过日志器63将MatchBetReply消息存储在非易失性存储器203中并且将其转发给登记器65，登记器65将账户控制器61中的第二彩注的状态从“未处理”更新为“已处理”。登记器65还存储在MatchBetReply消息中包含的匹配信息并且构建PlaceBetReply消息，该PlaceBetReply消息经由调遣器66以及执行者21的接收器23和执行器22被转发给发起器21(步骤s24至s27)。

然后，可以经由客户端接口服务器400a上的发起器21将PlaceBetReply消息中继回用户网页。这向第一和第二用户两者提供了其彩注已经针对相对立的彩注而被成功匹配的确认。

除了如上述创建MatchBetReply消息之外，匹配器54另外生成被转发给市场控制器51的匹配器55的MatchBetEvent(已匹配彩注事件)消息(步骤s20b)。该MatchBetEvent消息将被转发给被指配给第一用户的用户账户的账户控制器41，以向它通知现在已经成功地匹配了与第一用户的彩注相关联的PlaceBetRequest消息。然而，在这一级，市场控制器51不知道与第一用户的用户账户相关联的账户控制器41的地址。因此MatchBetEvent消息被存储在市场控制器51处，例如被存储在服务器200b上的存储器202中，并且调遣器55生成LocateInstanceRequest消息(s21b)以从指引器31所访问的列表中查找账户控制器41的地址。可以将该列表存储在作为指引器31所位于的服务器200g的一部分而被包括的RAM 202中。

LocateInstanceRequest消息被接收器32接收并被转发给定位器33以查找账户控制器41的地址(s22b)。定位器33生成包含账户控制器41的地址的LocateInstanceReply消息并且经由调遣器34将其转发给市场控制器51的接收器52(步骤s23b、s24b)。然后，市场控制器51的接收器52将LocateInstanceReply消息转发给调遣器55(步骤s25b)。在这一级，从存储器201中检索悬而未决的MatchBetEvent消息并且将其转发给账户控制器41的接收器42(步骤s26b)。账户控制器41的地址被市场控制器51高速缓存以避免将来再次查找它的需要。

所接收的MatchedBetEvent消息被转发给日志器43(步骤s27b)，并且以之前描述的方式利用唯一的参考号码而被附加到非易失性存储器。然后，MatchedBetEvent消息被转发给登记器45(步骤s28b)并且被用于更新账户控制器41上的彩注的状态。可以在运行账户控制器41的服务器200a上的RAM202中存储该数据。

以此方式，将由第一和第二用户放置的彩注成功地匹配在一起。

当处理交易时，在交易处理系统内保存的数据快速地改变。需要向客户端通知新的数据，例如，需要为用户更新市场梗概(view)。通过将被称为增量(delta)的对于现有数据的改变推向客户端，而不是响应客户端请求，来向需要信息的客户端传达这些改变。

可以单个地或者组合地使用上述实施例和替换方式以实现由交易处理系统提供的效果。

根据本发明的上述系统总体符合交易处理系统的ACID原理。它们是：交易需要具有以下性质：

原子性(atomicity)。原子交易是要么所有操作都成功要么没有一个操作成功的一系列操作。如果该系列操作在完成之前在某个点失败，则在失败之前完成的任何操作都需要重新执行(roll back)。在根据本发明的交易处理系统中，交易是预先(up front)已知的，并且在易失性存储器存储了一切。不像传统系统，在交易的层级上而不是在操作的层级上进行日记记录，因此不需要其中以日记记录所有已完成操作的撤销(UNDO)日记记录，并且检查UNDO日记以便从非易失性存储器中移除在完成交易之前写入的改变。

例如，以日记记录“彩注放置”交易，而不是作为其基础(underlie)的一系列操作，诸如“写入旧的风险”、“写入新的风险”，“写入新的彩注”等等。

在捕捉到交易、执行开始、并且在该交易中的所有操作完成之前存在故障的情况下，抛弃(throw away)该状态，并且重放也被称为重做(REDO)日记的日志以恢复该状态。

为了确保能够通过日记重放而成功地恢复状态，所述级是确定性的。例如，彩注以特定的顺序到达并且被以日记记录。假定：

1.彩注1(10英镑)

2.彩注2(15英镑)

3.彩注3(20英镑)

在以确定性的方式处理之后，单个可能状态如下：

1.彩注1(10英镑与彩注2匹配)

2.彩注2(10英镑与彩注1匹配，5英镑与彩注3匹配)

3.彩注3(5英镑与彩注2匹配，15英镑未匹配)

很清楚，如果彩注匹配级是非确定性的，则任何数量的状态都将是可能的。例如，如果在彩注1和2之前处理彩注3，则一个可能的状态将是：

1.彩注1(10英镑与彩注3匹配)

2.彩注2(10英镑与彩注3匹配，5英镑未匹配)

3.彩注3(10英镑与彩注1匹配，10英镑与彩注2匹配)

由于日记重放可能是耗时的过程，因此本发明的一些实施例包括高可用性的机制，例如日记跟踪(tailing)。

一致性。这意味着必须没有对于任何应用限定的完整性限制的违背。假定系统在交易执行之前处于一致状态，则之后它也必须处于一致状态。

例如，如果用户有10英镑的彩注，则未匹配部分和匹配的部分必须加起来等于10英镑。

在根据本发明的系统的实施例中，应用了弱一致性。系统最终将变为一致的，但在任意时刻它可以是不一致的。例如，账户控制器可能具有10英镑未匹配彩注的记录，而市场控制器可能具有匹配的该彩注的5英镑的记录。虽然账户控制器没有匹配的或未匹配的5英镑的记录，但从市场控制器传送、详述该匹配的消息意味着账户控制器最终将记录匹配的5英镑和未匹配的值。如前所述，这是由状态和消息发送保障所保障的。

隔离性(isolation)。该属性是指多个执行操作不重叠，使得虽然它们可能同时执行，但它们看起来是串行执行的。交易处理系统中的主要功能需要独占地访问账户和事件。为了实现隔离性，将执行单元指配给单独的实体，因此访问被内在地串行化并且交易被彼此隔离。例如，如与获取和释放在特定数据块上的锁定的客户端会话相反，单个执行单元可以拥有特定的账户或者特定的市场。

耐久性。一旦交易成功完成，它就一定不能丢失，甚至在系统关闭的情况下也是如此。因此，将改变写入或者写日志到盘上。如上所描述的，以此方式仅仅以日记记录了完整的交易，而不是组成交易的单独操作。

还可以以日记记录消息计数器，以防备消息丢失、次序颠倒或者重复。

对上述的实施例的修改和变化对于普通技术人员来说是显而易见的，同时仍然落在权利要求的范围内。

Claims (34)

1.一种包括多个分布式节点的系统中的交易处理的方法，其中在多个数据分区中保存数据，相应分区中的数据与所述节点中的相应的单个节点相关联，该系统包括：

多个控制器，用于控制一组数据分区，每个控制器包括用于对数据分区中的数据执行操作的多个写入级；以及

线程管理器，用于向写入级分配执行线程，其中线程管理器被安排为分配用于对给定数据分区中的数据进行操作的至多单个线程，该方法包括以下步骤：

在所述多个控制器中的第一控制器处接收消息，所述消息定义要对与给定数据分区相关联的数据执行的操作；

将用于由所述多个写入级中的一个处理的消息编入队列；以及

在执行线程可用于给定数据分区的情况下允许该写入级处理所述消息。

2.根据权利要求1所述的方法，还包括：

将消息转发给所述多个控制器中的第二控制器以进行后续处理。

3.根据权利要求1或2所述的方法，包括：在将所述消息发送给第一或第二控制器之前，确定被指配给所述消息去往的给定数据分区的控制器的地址。

4.根据前述权利要求中的任一项所述的方法，还包括：允许多个读取级并行地对给定分区中的数据进行操作。

5.根据权利要求4所述的方法，其中如果写入级没有对给定分区中的数据进行操作，则允许所述多个读取级对给定分区中的数据进行操作。

6.根据前述权利要求中的任一项所述的方法，包括：在接收时对接收的消息进行日志记录。

7.根据权利要求6的方法，包括向接收的消息指配序列号。

8.根据前述的权利要求中的任一项所述的方法，包括：将接收的消息与多个其它接收的消息进行批处理。

9.根据权利要求8所述的方法，其中基于取决于执行批处理所在的处理级的标准来执行该批处理。

10.根据权利要求8或9所述的方法，其中依据网络等待时间、盘等待时间和要处理的数据中的至少一个来执行批处理。

11.根据权利要求8至10中的任一项所述的方法，还包括：依据与消息去往的数据分区相关联的控制器来对消息进行分组。

12.根据前述的权利要求中的任一项所述的方法，其中在所述节点中的单个节点处存储与单个控制器相关联的多个数据分区中的数据。

13.根据前述的权利要求中的任一项所述的方法，其中第一数据分区中的数据定义与用户相关联的账户。

14.根据权利要求13所述的方法，其中第一控制器包括用于控制关于多个账户的操作的账户控制器。

15.根据权利要求13或14所述的方法，其中第二数据分区中的数据包括多个用户能够在其上放置彩注的市场。

16.根据权利要求15所述的方法，其中第二控制器包括用于控制关于多个市场的操作的市场控制器。

17.根据前述的权利要求中的任一项所述的方法，其中异步地传送所述消息。

18.根据前述的权利要求中的任一项所述的方法，其中所述节点包括服务器。

19.一种包括计算机可读指令的计算机可读介质，所述计算机可读指令用于执行包括多个分布式节点的系统中的交易处理的方法，其中在多个数据分区中保存数据，相应分区中的数据与所述节点中的相应的单个节点相关联，该系统包括：

多个控制器，用于控制一组数据分区，每个控制器包括用于对数据分区中的数据执行操作的多个写入级；以及

线程管理器，用于向写入级分配执行线程，其中线程管理器被安排为分配用于对给定数据分区中的数据进行操作的至多单个线程，该计算机可读指令包括：

第一指令，用于在所述多个控制器中的第一控制器处接收消息，所述消息定义要对与给定数据分区相关联的数据执行的操作；

第二指令，用来将用于由所述多个写入级中的一个处理的消息编入队列；以及

第三指令，用于在执行线程可用于给定数据分区的情况下，允许所述写入级处理该消息。

20.根据权利要求19所述的计算机可读介质，还包括：

第四指令，用于将所述消息转发给所述多个控制器中的第二控制器以进行后续处理。

21.一种用于包括多个分布式节点的系统中的交易处理的装置，其中在多个数据分区中保存数据，相应分区中的数据与所述节点中的相应的单个节点相关联，该系统包括

多个控制器，用于控制一组数据分区，每个控制器包括用于对数据分区中的数据执行操作的多个写入级；以及

线程管理器，用于向写入级分配执行线程，其中线程管理器被安排为分配用于对给定数据分区中的数据进行操作的至多单个线程，该装置包括：

接收器，用于在所述多个控制器中的第一控制器处接收消息，所述消息定义要对与给定数据分区相关联的数据执行的操作；以及

多个写入级，用于处理所述消息，其中，写入级被安排为在执行线程可用于给定数据分区的情况下处理多个消息中的一个，并且，在执行线程不可用的情况下，该装置被安排为将所述消息放置到队列中。

22.根据权利要求21所述的装置，包括：

调遣器，用于将消息转发给所述多个控制器中的第二控制器以进行后续处理。

23.根据权利要求21或22所述的装置，其中在单个服务器上存储关于账户的数据。

24.根据权利要求23所述的装置，还包括用于控制一组账户的账户控制器。

25.根据权利要求12至24中的任一项所述的装置，其中在单个服务器上存储关于市场的数据。

26.根据权利要求25所述的装置，还包括用于控制一组市场的市场控制器。

27.根据权利要求23至26中的任一项所述的装置，还包括线程管理器，用于向对单个账户或单个市场进行操作的第一写入级分配单个线程。

28.根据权利要求27所述的装置，其中请求访问所述单个账户或者所述单个市场的第二写入级被拒绝访问，直到该单个线程被释放为止。

29.根据权利要求27或28所述的装置，其中第一和/或第二写入级被配置为在单个操作中处理关于单个账户或市场的一批消息。

30.根据权利要求21至29中的任一项所述的装置，还包括用于处理影响多个写入级的消息的预处理器。

31.根据权利要求30所述的装置，其中预处理器被安排为从多个进行了日志记录的消息流生成单个消息流。

32.根据权利要求21至31中的任一项所述的装置，还包括：响应于未接收到消息的通知而从第一节点向第二节点重新发送消息的部件。

33.根据权利要求21至32中的任一项所述的装置，还包括用于对大量请求的数据进行服务的数据指引器的集群。

34.根据权利要求21至33中的任一项所述的装置，被配置为在非易失性存储器中对交易进行日志记录，以及在易失性存储器中对组成交易的操作进行日志记录。

Images