一种水平扩展的客户端系统

技术领域

本发明涉及一种客户端系统架构的设计，具体涉及一种可水平扩展的用C#实现的客户端系统。

背景技术

在期货期权市场中,针对交易不活跃的品种，交易所通常实行做市商制度。做市商系统具有报单量大、快速报撤、行情展示合约数量大等特点,且重启客户端必须快速恢复。客户端需要满足水平扩展的要求，以及客户端的机器性能越好，客户端表现越优秀。

在实际的生产中，客户端需要满足以下的性能需求:

1.吞吐量

吞吐量在这里的定义是客户端接收中台推送的数据在满足最低延时要求的情况下每秒中所能处理的最大数据记录数，在设计目标中，一条消息仅包含一条数据记录，如果中台合并推送消息，那么实际的吞吐量会高于设计目标。吞吐量的设计目标为5万笔/秒。

下表列出了以下消息分类总计的最大处理能力。

2.容量

容量的度量以成交量、单边报单数、合约数、每秒行情笔数四个维度来度量。成交量的变化会直接导致持仓、组合持仓、组合风险值、组合盈亏、本方行情等一系列数据的变化。

单边报单数包含普通的单边报单(order)及报价(quote)衍生出来的两笔报单，直接影响本方行情。客户端有查询报单数据的需求，单边报单数据的增加会增加查询报单数据的性能消耗，也大概率会增加客户端内存开销。

合约数量与界面展示能力相关，如T型图、组合查询等，合约量过多在同样的刷新频率选将导致界面卡顿，同在相同的行情频率下，合约数量与行情消息数成正比。

被置为基准合约的行情变动会影响衍生行情、衍生iv等数据的量增大。

3.延时

不同的数据对延时的要求不一致，根据数据的重要程度、数据量制定不一样的延时要求。如下表，设定延时要求最高的数据如市场行情最大延时为50ms，这个最大延时是在吞吐量和容量达到最大设计值的情况下的设计目标。

目前业界急需一种为满足上述需求的客户端架构设计。

发明内容

以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。此概述不是所有构想到的方面的详尽综览，并且既非旨在指认出所有方面的关键性或决定性要素亦非试图界定任何或所有方面的范围。其唯一的目的是要以简化形式给出一个或多个方面的一些概念以为稍后给出的更加详细的描述之序。

本发明的目的在于解决上述问题，提供了一种水平扩展的客户端系统，既能满足客户端水平扩展的要求，又能提升客户端的性能。

本发明的技术方案为：本发明揭示了一种水平扩展的客户端系统，系统包括：

接入模块，用于接收服务端推送的数据并处理成客户端系统内部通信的数据格式；

缓存模块，用于对来源于接入模块的数据的存储和管理；

服务模块，用于对缓存模块上传的数据进行包装以使展示模块能够不用再处理而直接展示数据；

展示模块，用于从服务模块接收包装后的数据并展示对应的界面。

根据本发明的水平扩展的客户端系统的一实施例，缓存模块配置为变更通知模式的数据刷新方式：在数据变动后发送通知到服务模块，再由服务模块通知界面刷新。

根据本发明的水平扩展的客户端系统的一实施例，缓存模块进一步配置为在数据发生变动后，由缓存模块触发服务模块的回调函数，再通过服务模块发布订阅服务实现的发布订阅模式将数据变动的消息发送到展示模块的界面，界面接收到消息的通知后，由界面决定是否从服务模块获取数据

根据本发明的水平扩展的客户端系统的一实施例，数据从缓存模块中的存储模块传输到服务模块中的业务服务，展示模块通过订阅服务从服务模块中的业务服务中获取要展示的数据。

根据本发明的水平扩展的客户端系统的一实施例，客户端系统通过多个线程对数据进行操作，其中包括：

数据接收线程，用于接收数据并放入队列中；

数据处理线程，用于从队列中取出数据依此对数据进行包括解包、生成对应的数据模型对象在内的的处理，并存储在缓存模块中；

缓存事件驱动线程，用于执行事件检查任务，判断是否要生成变更通知，变更通知到用户接口，由用户接口判断是否要进行服务调用；

界面线程，检测到数据发生变动就刷新界面。

根据本发明的水平扩展的客户端系统的一实施例，数据模型中的表包括基础表、过渡表和条件触发表，其中：

基础表，通过基础表将数据存储在内存中，在接入层接收到数据后，基础表将字符型的数据转换为对应的实体类存储在队列中；

过渡表，本身不存储任何数据，仅仅将数据交由下游处理，包括：将数据交由缓存模块中的持久化模块存储在硬盘上，或者将数据交由服务层直接处理，用于需要特化处理的数据；。

条件触发表，是基础表和过渡表的综合，既将数据存储在内存中，又可以将数据特化处理。

根据本发明的水平扩展的客户端系统的一实施例，缓存模块通过触发器实现变更通知模式，其中触发器与表的关系由表管理器进行管理，触发器包括普通触发器和条件触发器，其中普通触发器关联在基础表和条件触发表上；条件触发器只关联在条件触发器上。

根据本发明的水平扩展的客户端系统的一实施例，服务端和客户端系统之间的通信协议是websocket协议和http协议，其中websocket协议用于服务端主动推送到客户端系统的数据，http协议用于客户端系统主动请求服务端的数据。

本发明对比现有技术有如下的有益效果：本发明的客户端系统通过数据缓冲技术、底层数据持久化的特点来实现架构可水平扩展。

具体而言，数据缓冲技术是指客户端瞬时接收到大量数据时，并不直接在界面上进行刷新显示，界面刷新会消耗操作系统大量资源，而是在有数据到来时，先将数据插入缓存，由缓存的内部事件循环机制驱动界面的刷新，从而将界面的刷新频率控制在一个范围内，系统每秒收到的行情可达到上万笔，无论如何界面的刷新频率也达不到每秒上万次。传统的解决办法是使用轮询技术，缺点是无数据到来时也会获取数据进行刷新，浪费系统资源。如在缓存中设置每50毫秒的事件检测，也就是每秒进行20次事件检查，如果数据未发生变动，则不刷新，如果数据存在变动，则通知界面刷新，1秒内最多进行20次刷新，保护了客户端的可扩展性。

底层数据持久化解决了数据量增多带来的内存增大从而无法水平扩展的问题。部分可扩展的数据(如报单、报价、成交、询价)存储在硬盘上，从而使客户端占用的内存保持在一个范围内。在访问的时候，将访问频次高的数据(如处于已确认状态的报单)存储在内存中，而将访问频次低得数据(如处于已取消状态的报单)存储在硬盘上，将访问效率降低的损失降到最低。

附图说明

在结合以下附图阅读本公开的实施例的详细描述之后，能够更好地理解本发明的上述特征和优点。在附图中，各组件不一定是按比例绘制，并且具有类似的相关特性或特征的组件可能具有相同或相近的附图标记。

图1示出了本发明的水平扩展的客户端系统的一实施例的分层设计的示意图。

图2示出了本发明的水平扩展的客户端系统的一实施例的架构示意图。

图3示出了本发明的水平扩展的客户端系统的一实施例的数据流转示意图。

图4示出了本发明的水平扩展的客户端系统的一实施例的线程模型的示意图。

具体实施方式

以下结合附图和具体实施例对本发明作详细描述。注意，以下结合附图和具体实施例描述的诸方面仅是示例性的，而不应被理解为对本发明的保护范围进行任何限制。

图1示出了本发明的水平扩展的客户端系统的一实施例的分层设计的示意图。请参见图1，本实施例的客户端系统包括四个层次：用户接口层、服务层、缓存层和数据接入层。其中用户接口层是客户端界面部分，用于数据展示和参数设置界面。服务层用于提供用户接口层所需要的数据。缓存层用于存储数据，提供触发器的机制，服务层向缓存层订阅感兴趣的数据，提供服务层所需要的数据。数据接入层订阅并收取中台提供的行情、交易及其他业务数据，处理好数据之后回调缓存层注册的处理函数，且提供持久化的存储以用于数据的留痕及反演。

图2示出了本发明的水平扩展的客户端系统的一实施例的架构。请参见图2，本实施例的客户端系统通过websocket和http协议来访问服务端，以便扩展到客户端使用网页实现，同时可拆分为多个进程协调工作。

图2所示的客户端中的展示模块、服务模块、缓存模块和接入模块分别与图1所示的用户接口层、服务层、缓存层和数据接入层一一对应，图2所示的架构模块是图1中所示的分层设计模式的具体实现，即图1所示是设计模式的抽象表达。图2中的箭头表示数据的流向，服务端到客户端的通信协议是websocket协议和http协议。其中websocket协议用于服务端主动推送到客户端，而http协议用于客户端主动请求服务端的数据。

接入模块用于接收服务端推送的数据并处理成客户端内部通信的数据格式。

缓存模块用于数据的存储和管理。数据来源于接入模块。缓存模块是本发明的重要组成，其核心是变更通知模式，即其中的触发器管理模块，只有在数据变动时才发送通知到服务模块，再由服务模块通知界面刷新。数据从存储模块传输到业务服务，展示模块从业务服务中获取具体要展示的数据。

服务模块是对缓存模块上传的数据的包装，从而展示模块可以直接展示数据而不用再处理。服务模块通过订阅服务将下层数据的变动传递到展示模块中的界面。服务模块中的HTTP转发是将界面的HTTP请求直接转发到服务端。

展示模块是用于展示具体的界面，如T型图、查询、策略等界面。

图3示出了本发明的水平扩展的客户端系统的一实施例的数据流转方式，即客户端接收到数据到数据刷新的整个过程。

客户端系统接收到数据后在接入模块中放入队列中，再依次对数据解包、生成数据模型对象，处理后的数据存储在缓存模块中，图3所示的“通知”是在数据发生变动后，由缓存模块触发服务模块的回调函数，再通过服务模块发布订阅服务实现的发布订阅模式将数据变动的消息发送到展示模块的界面，界面接收到消息，即接收到通知。在界面接收到通知之后，由界面决定是否从服务模块获取数据，本发明中的数据绑定到界面，在数据发生变动时界面就会刷新显示。

从图3中看出，本发明的客户端系统通过使用变更通知模式，即数据并没有直接推送到界面，这样可以防止瞬时数据的冲击。

图4示出了本发明的水平扩展的客户端系统的一实施例的线程模型。多个线程会对数据进行操作，各线程分别执行各自的任务，如数据接收、数据处理。数据接收线程和数据处理线程之间使用队列进行沟通，接收到数据后放入队列等待数据处理线程取出处理。缓存事件驱动线程执行事件检查任务，判断是否要生成事件通知。变更事件通知到用户接口层，用户接口进行判断是否要进行服务调用(如查询服务)。界面线程检测到数据发生变动即刷新界面。

从图4中可以看出，线程模型清晰可控，缓存事件驱动是一个不执行阻塞IO的事件驱动线程。

数据模型是软件开发的核心设计，以下描述本发明中的数据模型设计，在接入模块中将接收到的数据处理成对应的数据模型，并存储到缓存模块中，展示模块和服务模块所使用的数据均是数据模型的范畴。

本实施例的水平扩展的客户端系统通过基础表将数据存储在内存中，在接入层接收到数据后，基础表将字符型的数据转换为对应的实体类存储在队列中。数据量小的数据均存储在基础表中，如合约数据。基础表只能关联普通的触发器，只要表有变动就会启动触发器的通知机制。

过渡表本身不存储任何数据，仅仅将数据交由下游处理，如将数据交由缓存模块中的持久化模块存储在硬盘上，又如将数据交由服务层直接处理，用于一些需要特化处理的数据。数据量大的数据，如报单数据，会定义为过渡表，实际数据存储到下文的带存储的条件触发器中。另外如策略日志等，数据量大，也不存储在内存中，而是在业务服务中，存储最新的指定数量的数据，在满足业务的同时可以减少内存的消耗。

条件触发表的含义是基础表和过渡表的综合，既将数据存储在内存中，又可以将数据特化处理，这样就可以判断是否满足对应条件，只有满足条件才启动触发器的通知机制。访问频率高、数据更新频率高、数据量大、延时低的数据适合采用此方案，如行情数据，可以订阅某些合约的行情数据信息。

本发明的客户端系统采用表管理器TableManager来创建表示例、提供更新数据接口、提供附加触发器接口、获取表对象、数据访问、数据通知事件的驱动等。

此外，本发明的客户端系统通过触发器提供数据表数据变更的通知机制，通过判断表数据的更新时间来判断的，因此无论是新增、删除、更新均会通知。普通触发器只能通过访问全表数据才能获取最新的数据，粒度较粗。

触发器是关联在数据表上的，触发器与表的关系由表管理器TableManager进行管理。普通触发器可以关联在基础表和条件触发表上，因为表本身存储了数据，可以直接访问。

条件触发器是用做条件触发表的数据变更通知，只有满足定义的条件会启动通知。条件定义只要实现特定的ICondition接口，ICondition接口只有一个方法:

FitResult Fit(T t)

其中T是实体类类型，FitResult是返回值枚举，包含以下定义:

上述定义中，AddOrUpdate和TryDelete都会进行变更通知。

条件触发器只能关联在条件触发表上，因为一旦触发，条件触发表的数据已经更新好了，可以直接访问。

带存储的条件触发器用于过渡表的数据通知。数据存储在触发器中，典型实现是将数据量大的表定义为过渡表，然后将数据持久化存储在这类型的条件触发器中。在内存中构建对应的条件的索引，访问数据根据索引进行访问。这种带存储的条件触发器用于访问频率较低、延迟要求一般的数据的触发通知。存储通常是使用LevelDB进行高效读写访问。

对于数据量大的数据，有分页查询的需求，传统的分页查询都是采用用户点击发起请求或者轮询的方式进行数据的更新。但本发明的客户端不希望浪费系统资源，因此设计了分页索引，分页索引运用到带存储的条件触发器中，条件触发器中更新数据时，以及根据条件信息构建分页索引。

分页索引只能按照特定的数据排序方式进行分页，不支持数据排序方式的切换。根据数据生成序列值，根据序列值和主键key更新索引数据信息，维护好一个排序好的序列，按照分页信息获取对应主键集合。根据主键集合可以在存储的数据中访问得到数据。分页索引是客户端支持快速大数据量查询的核心技术。

尽管为使解释简单化将上述方法图示并描述为一系列动作，但是应理解并领会，这些方法不受动作的次序所限，因为根据一个或多个实施例，一些动作可按不同次序发生和/或与来自本文中图示和描述或本文中未图示和描述但本领域技术人员可以理解的其他动作并发地发生。

本领域技术人员将进一步领会，结合本文中所公开的实施例来描述的各种解说性逻辑板块、模块、电路、和算法步骤可实现为电子硬件、计算机软件、或这两者的组合。为清楚地解说硬件与软件的这一可互换性，各种解说性组件、框、模块、电路、和步骤在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。技术人员对于每种特定应用可用不同的方式来实现所描述的功能性，但这样的实现决策不应被解读成导致脱离了本发明的范围。

结合本文所公开的实施例描述的各种解说性逻辑板块、模块、和电路可用通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或其设计成执行本文所描述功能的任何组合来实现或执行。通用处理器可以是微处理器，但在替换方案中，该处理器可以是任何常规的处理器、控制器、微控制器、或状态机。处理器还可以被实现为计算设备的组合，例如DSP与微处理器的组合、多个微处理器、与DSP核心协作的一个或多个微处理器、或任何其他此类配置。

结合本文中公开的实施例描述的方法或算法的步骤可直接在硬件中、在由处理器执行的软件模块中、或在这两者的组合中体现。软件模块可驻留在RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动盘、CD-ROM、或本领域中所知的任何其他形式的存储介质中。示例性存储介质耦合到处理器以使得该处理器能从/向该存储介质读取和写入信息。在替换方案中，存储介质可以被整合到处理器。处理器和存储介质可驻留在ASIC中。ASIC可驻留在用户终端中。在替换方案中，处理器和存储介质可作为分立组件驻留在用户终端中。

在一个或多个示例性实施例中，所描述的功能可在硬件、软件、固件或其任何组合中实现。如果在软件中实现为计算机程序产品，则各功能可以作为一条或更多条指令或代码存储在计算机可读介质上或藉其进行传送。计算机可读介质包括计算机存储介质和通信介质两者，其包括促成计算机程序从一地向另一地转移的任何介质。存储介质可以是能被计算机访问的任何可用介质。作为示例而非限定，这样的计算机可读介质可包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁存储设备、或能被用来携带或存储指令或数据结构形式的合意程序代码且能被计算机访问的任何其它介质。任何连接也被正当地称为计算机可读介质。例如，如果软件是使用同轴电缆、光纤电缆、双绞线、数字订户线(DSL)、或诸如红外、无线电、以及微波之类的无线技术从web网站、服务器、或其它远程源传送而来，则该同轴电缆、光纤电缆、双绞线、DSL、或诸如红外、无线电、以及微波之类的无线技术就被包括在介质的定义之中。如本文中所使用的盘(disk)和碟(disc)包括压缩碟(CD)、激光碟、光碟、数字多用碟(DVD)、软盘和蓝光碟，其中盘(disk)往往以磁的方式再现数据，而碟(disc)用激光以光学方式再现数据。上述的组合也应被包括在计算机可读介质的范围内。

提供对本公开的先前描述是为使得本领域任何技术人员皆能够制作或使用本公开。对本公开的各种修改对本领域技术人员来说都将是显而易见的，且本文中所定义的普适原理可被应用到其他变体而不会脱离本公开的精神或范围。由此，本公开并非旨在被限定于本文中所描述的示例和设计，而是应被授予与本文中所公开的原理和新颖性特征相一致的最广范围。