CN115269709B - 基于行情数据的查询及回放方法、装置、设备及介质 - Google Patents
基于行情数据的查询及回放方法、装置、设备及介质 Download PDFInfo
- Publication number
- CN115269709B CN115269709B CN202211208194.5A CN202211208194A CN115269709B CN 115269709 B CN115269709 B CN 115269709B CN 202211208194 A CN202211208194 A CN 202211208194A CN 115269709 B CN115269709 B CN 115269709B
- Authority
- CN
- China
- Prior art keywords
- request
- sub
- sending
- server
- playback
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/25—Integrating or interfacing systems involving database management systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2457—Query processing with adaptation to user needs
- G06F16/24578—Query processing with adaptation to user needs using ranking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/953—Querying, e.g. by the use of web search engines
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computational Linguistics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明涉及大数据技术领域,提供一种基于行情数据的查询及回放方法、装置、设备及介质,其方法包括:确定向服务端发起的针对行情数据的每个请求的类型;将每个请求中的查询请求写入发送队列;获取每个请求中的回放请求的请求代码数目;根据所述请求代码数目对所述回放请求进行拆分,得到多个子请求并写入发送队列;将发送队列中的每个子请求异步发送至服务端;当接收到服务端根据每个请求返回的请求结果时,从中提取回放请求对应的目标结果;根据行情时间对目标结果进行触发式反馈。本发明能够通过对查询与回放请求的拆分,使得服务端无差别化处理查询和回放请求,实现资源的有效利用,同时实现高效且高并发的行情数据查询及回放。
Description
技术领域
本发明涉及大数据技术领域,尤其涉及一种基于行情数据的查询及回放方法、装置、设备及介质。
背景技术
现有的证券行业中,在查询和回放历史数据场景下,采用的方案主要是将一部分历史行情数据存文件,一部分历史行情数据存数据库,但是,由于文件和数据库的各类资源有限,难以实现高效、高并发的查询及回放。
另外,查询任务粒度通常比较小,且查询是请求应答式,一个请求获取一个响应结果,而回放任务粒度通常比较大,一次可能回放上十G的数据量,并且,当客户端发送一个异步回放的请求后,服务端会将请求的历史行情源源不断地推送给客户端。因此,为了不影响查询请求的时效性,现有技术中通常会限制一个回放任务的最大查询数据量以及每个客户端最多能回放的任务数量,给查询请求留有相应的资源,同时避免对资源的过渡使用。但是,当所有客户端都只有回放请求没有查询请求,或者在只有一个客户端有请求而其他客户端没有并发请求的情况下,由于仍然为每个客户端保留了查询请求的资源,因此会造成这部分保留资源的浪费,无法充分利用服务端资源。
发明内容
鉴于以上内容,有必要提供一种基于行情数据的查询及回放方法、装置、设备及介质,能够充分利用资源,并实现高效且高并发的行情数据查询及回放。
一种基于行情数据的查询及回放方法,所述基于行情数据的查询及回放方法包括:
对于向服务端发起的针对行情数据的每个请求,确定每个请求的类型;
对于每个请求中的查询请求,将所述查询请求写入所述客户端的发送队列;
对于每个请求中的回放请求,获取所述回放请求的请求代码数目;
根据所述请求代码数目对所述回放请求进行拆分,得到多个子请求,并将所述多个子请求写入所述发送队列;
将所述发送队列中的每个子请求异步发送至所述服务端;
当接收到所述服务端根据每个请求返回的请求结果时,从所述请求结果中提取所述回放请求对应的请求结果作为目标结果;
根据行情时间,对所述目标结果进行触发式反馈。
根据本发明优选实施例,所述确定每个请求的类型包括:
确定发起每个请求的接口;
通过发起每个请求的接口获取每个请求的协议包;
从每个请求的协议包中提取每个请求的类型字段标识;
根据每个请求的类型字段标识确定每个请求的类型。
根据本发明优选实施例,在将所述发送队列中的每个子请求异步发送至所述服务端前,所述方法还包括:
创建相互独立执行的请求发送线程及结果处理线程;
其中,所述请求发送线程用于不断发送向所述服务端发起的每个请求,所述结果处理线程用于不断处理所述服务端返回的请求结果。
根据本发明优选实施例,所述根据所述请求代码数目对所述回放请求进行拆分,得到多个子请求,并将所述多个子请求写入所述发送队列包括:
对于每个回放请求,当所述请求代码数目大于或者等于1且小于或者等于5时,根据时间区间范围240分钟拆分所述回放请求为第一子请求,并将所述第一子请求的权重配置为1;
当所述请求代码数目大于或者等于6且小于或者等于10时,根据时间区间范围96分钟拆分所述回放请求为第二子请求,并将所述第二子请求的权重配置为2;
当所述请求代码数目大于或者等于11且小于或者等于50时,根据时间区间范围48分钟拆分所述回放请求为第三子请求,并将所述第三子请求的权重配置为3;
当所述请求代码数目大于或者等于51时,根据时间区间范围16分钟拆分所述回放请求为第四子请求,并将所述第四子请求的权重配置为5;
将每个回放请求对应的拆分后的每个子请求存入一个map表,其中,在每个map表中,将每个子请求的ID确定为key,将每个子请求的序号确定为value;
将所述map表对应的每个子请求写入队列,得到所述发送队列。
根据本发明优选实施例,所述将所述发送队列中的每个子请求异步发送至所述服务端包括:
获取所述客户端的最大发送请求数,所述服务端的最大查询请求数,及所述客户端对所述服务端返回的请求结果的最大接收数;
获取所述客户端已发送且未被所述服务端接收结果的请求数作为当前发送请求数,所述服务端的当前查询请求数,及所述客户端对所述服务端返回的处于已接收且未被所述客户端处理的状态的请求结果数作为当前接收数;
当所述当前发送请求数小于或者等于所述最大发送请求数,所述当前查询请求数小于或者等于所述最大查询请求数,所述当前接收数小于或者等于所述最大接收数时,将所述发送队列中的每个子请求异步发送至所述服务端;
当所述当前发送请求数大于所述最大发送请求数时,阻塞从所述发送队列中获取请求,直至接收到所述服务端返回的请求结果且所述当前发送请求数递减至小于所述最大发送请求数时,将所述发送队列中的每个子请求异步发送至所述服务端;
当所述当前查询请求数大于所述最大查询请求数时,限制所述客户端的发送速度,直至达到预设时长,再次尝试将所述发送队列中的每个子请求异步发送至所述服务端;
当所述当前接收数大于所述最大接收数时,限制所述客户端的发送速度,直至所述客户端对所述服务端返回的处于已接收且未被所述客户端处理的状态的请求结果数小于或者等于所述最大接收数,继续将所述发送队列中的每个子请求异步发送至所述服务端。
根据本发明优选实施例,所述方法还包括:
从所述请求结果中提取所述查询请求对应的请求结果;
直接反馈所述查询请求对应的请求结果。
根据本发明优选实施例,所述根据行情时间,对所述目标结果进行触发式反馈包括:
按照所述行情时间由早到晚的顺序处理所述目标结果中的每个子结果;
其中,对于任务指针指向的当前子结果,获取按照所述行情时间确定的实际待处理子结果;
当所述当前子结果为所述实际待处理子结果时,将所述子结果的状态标记为已就绪状态,并按照所述行情时间依次获取所述当前子结果后连续的处于所述已就绪状态的其他子结果,直至检测到有子结果处于未就绪状态,停止获取所述其他子结果,并反馈所述当前子结果及所述其他子结果,将所述任务指针指向处于所述未就绪状态的子结果;
当所述当前子结果不为所述实际待处理子结果时,将所述子结果的状态标记为已就绪状态。
一种基于行情数据的查询及回放装置,运行于客户端,所述基于行情数据的查询及回放装置包括:
确定单元,用于对于向服务端发起的针对行情数据的每个请求,确定每个请求的类型;
发送单元,用于对于每个请求中的查询请求,将所述查询请求写入所述客户端的发送队列;
获取单元,用于对于每个请求中的回放请求,获取所述回放请求的请求代码数目;
拆分单元,用于根据所述请求代码数目对所述回放请求进行拆分,得到多个子请求,并将所述多个子请求写入所述发送队列;
所述发送单元,还用于将所述发送队列中的每个子请求异步发送至所述服务端;
提取单元,用于当接收到所述服务端根据每个请求返回的请求结果时,从所述请求结果中提取所述回放请求对应的请求结果作为目标结果;
反馈单元,用于根据行情时间,对所述目标结果进行触发式反馈。
一种计算机设备,所述计算机设备包括:
存储器,存储至少一个指令;及
处理器,执行所述存储器中存储的指令以实现所述基于行情数据的查询及回放方法。
一种计算机可读存储介质,所述计算机可读存储介质中存储有至少一个指令,所述至少一个指令被计算机设备中的处理器执行以实现所述基于行情数据的查询及回放方法。
由以上技术方案可以看出,本发明能够通过对查询与回放请求的拆分,实现资源的有效利用,同时实现高效且高并发的行情数据查询及回放。
附图说明
图1是本发明基于行情数据的查询及回放方法的较佳实施例的流程图。
图2是本发明基于行情数据的查询及回放装置的较佳实施例的功能模块图。
图3是本发明实现基于行情数据的查询及回放方法的较佳实施例的计算机设备的结构示意图。
具体实施方式
为了使本发明的目的、技术方案和优点更加清楚,下面结合附图和具体实施例对本发明进行详细描述。
如图1所示,是本发明基于行情数据的查询及回放方法的较佳实施例的流程图。根据不同的需求,该流程图中步骤的顺序可以改变,某些步骤可以省略。
所述基于行情数据的查询及回放方法应用于一个或者多个计算机设备中,所述计算机设备是一种能够按照事先设定或存储的指令,自动进行数值计算和/或信息处理的设备,其硬件包括但不限于微处理器、专用集成电路(Application Specific IntegratedCircuit,ASIC)、可编程门阵列(Field-Programmable Gate Array,FPGA)、数字处理器(Digital Signal Processor,DSP)、嵌入式设备等。
所述计算机设备可以是任何一种可与用户进行人机交互的电子产品,例如,个人计算机、平板电脑、智能手机、个人数字助理(Personal Digital Assistant,PDA)、游戏机、交互式网络电视(Internet Protocol Television,IPTV)、智能式穿戴式设备等。
所述计算机设备还可以包括网络设备和/或用户设备。其中,所述网络设备包括,但不限于单个网络服务器、多个网络服务器组成的服务器组或基于云计算(CloudComputing)的由大量主机或网络服务器构成的云。
所述服务器可以是独立的服务器,也可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(ContentDelivery Network,CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器。
其中,人工智能(Artificial Intelligence,AI)是利用数字计算机或者数字计算机控制的机器模拟、延伸和扩展人的智能,感知环境、获取知识并使用知识获得最佳结果的理论、方法、技术及应用系统。
人工智能基础技术一般包括如传感器、专用人工智能芯片、云计算、分布式存储、大数据处理技术、操作/交互系统、机电一体化等技术。人工智能软件技术主要包括计算机视觉技术、机器人技术、生物识别技术、语音处理技术、自然语言处理技术以及机器学习/深度学习等几大方向。
所述计算机设备所处的网络包括但不限于互联网、广域网、城域网、局域网、虚拟专用网络(Virtual Private Network,VPN)等。
在本实施例中,所述基于行情数据的查询及回放方法应用于客户端,包括:
S10,对于向服务端发起的针对行情数据的每个请求,确定每个请求的类型。
在本实施例中,所述服务端与所述客户端相通信,所述服务端用于根据所述客户端的请求向所述客户端提供服务。
例如:当所述客户端向所述服务端发送查询请求时,所述服务端根据所述客户端发起的查询请求进行数据查询,并向所述客户端返回查询结果;当所述客户端向所述服务端发送回放请求时,所述服务端根据所述客户端发起的回放请求获取指定时间段内的回放数据,并向所述服务端返回获取到的回放数据。
在本实施例中,所述行情数据可以包括证券交易系统下发的交易数据等。
在本实施例中,每个请求的类型可以包括,但不限于查询请求、回放请求等。
其中,发起所述查询请求是为了实时查询行情,以了解行情。
其中,发起所述回放请求可以进行交易策略回测,验证策略的有效性。
具体地,所述确定每个请求的类型包括:
确定发起每个请求的接口;
通过发起每个请求的接口获取每个请求的协议包;
从每个请求的协议包中提取每个请求的类型字段标识;
根据每个请求的类型字段标识确定每个请求的类型。
通过上述实施例,能够通过接口自动实现请求类型的识别。
S11,对于每个请求中的查询请求,将所述查询请求写入所述客户端的发送队列。
在本实施例中,将所述查询请求写入所述客户端的发送队列后,即可等待向服务端发送。
S12,对于每个请求中的回放请求,获取所述回放请求的请求代码数目。
在本实施例中,不同的回放请求所对应的请求代码数目可能是不同的,例如:所述请求代码数据可以只有一个,也可以为几十个,甚至更多。
S13,根据所述请求代码数目对所述回放请求进行拆分,得到多个子请求,并将所述多个子请求写入所述发送队列。
在本实施例中,为了避免数据量过大,需要对所述回放请求进行拆分。
具体地,所述根据所述请求代码数目对所述回放请求进行拆分,得到多个子请求,并将所述多个子请求写入所述发送队列包括:
对于每个回放请求,当所述请求代码数目大于或者等于1且小于或者等于5时,根据时间区间范围240分钟拆分所述回放请求为第一子请求,并将所述第一子请求的权重配置为1;
当所述请求代码数目大于或者等于6且小于或者等于10时,根据时间区间范围96分钟拆分所述回放请求为第二子请求,并将所述第二子请求的权重配置为2;
当所述请求代码数目大于或者等于11且小于或者等于50时,根据时间区间范围48分钟拆分所述回放请求为第三子请求,并将所述第三子请求的权重配置为3;
当所述请求代码数目大于或者等于51时,根据时间区间范围16分钟拆分所述回放请求为第四子请求,并将所述第四子请求的权重配置为5;
将每个回放请求对应的拆分后的每个子请求存入一个map表,其中,在每个map表中,将每个子请求的ID确定为key,将每个子请求的序号确定为value;
将所述map表对应的每个子请求写入队列,得到所述发送队列。
其中,请求代码数目、时间区间范围及权重等参数都是根据测试得到的性能最佳时的参数取值(如可以采用性能压测工具测试得到)。例如:分别利用8、16、32、48、96、192、240等多个分钟点作为时间区间范围进行测试,并从中选择能够提供最大并发能力的分钟点。权重可以根据耗时比例及并发体验等性能指标进行选择。
具体地,可以参见下表进行拆分:
请求代码数目 | 时间区间范围 | 权重 |
1-5 | 240分钟 | 1 |
6-10 | 96分钟 | 2 |
11-50 | 48分钟 | 3 |
51以上 | 16分钟 | 5 |
举例而言,每天的交易时间段一般是固定的,为9:30-11:30及13:00-15:00,共4小时。根据上表中的拆分策略,当要回放2只代码1天内的行情时,由于2只代码满足上表中的第一个区间,并且每天交易的开始时间9:30与结束时间15:00间正好共有240分钟,因此该回放任务不需要拆分,直接按照一个完整的查询请求发送到服务端即可。
再举例而言,当要回放12只代码5天内的行情时,即要回放时间为202206010900-202206051600的行情,根据上表得知,需要拆分成每48分钟一个子请求(非交易时间自动去除),则子请求大概参数变成:
12只代码 | 202206010930-202206011018 |
12只代码 | 202206011019-202206011107 |
12只代码 | ...... |
12只代码 | 202206051412-202206051500 |
因此,每天拆成5个小任务,共5天,12只代码5天内的行情对应的回放大任务拆分成了25个子请求。
可以理解的是,查询的条件一般是1只代码1天的行情数据,一般为1-2MB左右的数据量。回放请求转换到服务端,则相当于按照一定的条件查询,本质上也是查询请求,但回放请求可能请求的数据量非常大。即回放任务拆分后的子请求,就是一个个的数据库查询任务。应用传递给系统的回放任务和查询任务的区别是:
回放任务可以传以下参数:多个证券代码+开始日期+结束日期(可以是多天的,即回放可以是多个代码多天的行情量);
查询任务可以传以下参数:一个证券代码+开始日期+结束日期(结束日期必须等于开始日期,即只能查一个代码一天的行情量)。
并且,若要回放200只代码一个月的行情数据,由于数据量非常大,服务端不能一个查询结果就直接封装成一个应答包返回给客户端。一方面,服务端获取这个回放请求的数据量大,耗时太长,独占一个线程来处理它的时间太久,不利于多客户端大量并发的查询体验;另一方面,一个大包传回客户端的时间过久,又占用整个带宽使用,单个客户端并发体验差的同时,客户端网络抖动还可能导致大包传输失败。所以,在客户端将回放请求拆分成更小粒度的回放子请求,例如可以将回放请求拆分成和查询请求一样的1-2MB的粒度的子请求,那么服务端就无需区分是查询请求还是回放的子请求,解决了直接返回大包的问题。
同时,上述实施例通过将回放任务进行拆分,将回放任务统一转换成一个个的数据库查询操作,不再需要区分回放请求还是查询请求,充分考虑数据库查询并发吞吐能力,并充分协调资源使用。
S14,将所述发送队列中的每个子请求异步发送至所述服务端。
在本实施例中,在将所述发送队列中的每个子请求异步发送至所述服务端前,所述方法还包括:
创建相互独立执行的请求发送线程及结果处理线程;
其中,所述请求发送线程用于不断发送向所述服务端发起的每个请求,所述结果处理线程用于不断处理所述服务端返回的请求结果。
具体地,在异步处理过程中,用一个请求发送线程专门处理发送,用另一个结果处理线程专门处理服务端的返回结果。请求发送线程将一个请求发往服务端后,不需要等待该请求返回数据,立刻可以发送下一个请求到服务端。而另一个结果处理线程不断的接收服务端的应答,并将应答写入接收队列等待下一步的处理。
上述实施例通过配置异步线程,使发送任务与接收任务能够相互独立的执行,进而提高了请求的高并发性,避免造成任务堵塞。
可以理解的是,发送主要受三个因素影响:发送端(即客户端)最大发送请求数,服务端队列是否已满(即服务端的最大查询请求数),客户端接收服务端的应答数据的接收队列是否满(即客户端对服务端返回的请求结果的最大接收数)。
具体地,所述将所述发送队列中的每个子请求异步发送至所述服务端包括:
获取所述客户端的最大发送请求数,所述服务端的最大查询请求数,及所述客户端对所述服务端返回的请求结果的最大接收数;
获取所述客户端已发送且未被所述服务端接收结果的请求数作为当前发送请求数,所述服务端的当前查询请求数,及所述客户端对所述服务端返回的处于已接收且未被所述客户端处理的状态的请求结果数作为当前接收数;
当所述当前发送请求数小于或者等于所述最大发送请求数,所述当前查询请求数小于或者等于所述最大查询请求数,所述当前接收数小于或者等于所述最大接收数时,将所述发送队列中的每个子请求异步发送至所述服务端;
当所述当前发送请求数大于所述最大发送请求数时,阻塞从所述发送队列中获取请求,直至接收到所述服务端返回的请求结果且所述当前发送请求数递减至小于所述最大发送请求数时,将所述发送队列中的每个子请求异步发送至所述服务端;
当所述当前查询请求数大于所述最大查询请求数时,限制所述客户端的发送速度,直至达到预设时长,再次尝试将所述发送队列中的每个子请求异步发送至所述服务端;
当所述当前接收数大于所述最大接收数时,限制所述客户端的发送速度,直至所述客户端对所述服务端返回的处于已接收且未被所述客户端处理的状态的请求结果数小于或者等于所述最大接收数,继续将所述发送队列中的每个子请求异步发送至所述服务端。
在上述实施例中,三个因素中任意因素达到最大限制都会阻塞发送端向服务端发送请求。第一个因素限制目的是限制每个客户端的最大并发请求数,提高服务端并发响应其他客户端的体验。第二个因素限制目的是在服务端队列满后限制客户端发送速度,例如可以间隔500ms后再重试发送。第三个因素限制目的是在客户端接收队列满后,将应答消息缓存到服务端,避免服务端对该客户端应答消息缓存越来越大,并控制客户端发送的速度,直到接收缓存队列有一定的空余再继续发送请求。
上述实施例中发送策略的配置能够有效避免数据堵塞。
S15,当接收到所述服务端根据每个请求返回的请求结果时,从所述请求结果中提取所述回放请求对应的请求结果作为目标结果。
在本实施例中,所述方法还包括:
从所述请求结果中提取所述查询请求对应的请求结果;
直接反馈所述查询请求对应的请求结果。
在上述实施例中,保证了查询请求的实时反馈,避免对查询请求的及时响应造成影响。
在本实施例中,可以根据字段标识从所述请求结果中提取所述回放请求对应的请求结果作为所述目标结果,本发明不限制。
S16,根据行情时间,对所述目标结果进行触发式反馈。
在本实施例中,所述根据行情时间,对所述目标结果进行触发式反馈包括:
按照所述行情时间由早到晚的顺序处理所述目标结果中的每个子结果;
其中,对于任务指针指向的当前子结果,获取按照所述行情时间确定的实际待处理子结果;
当所述当前子结果为所述实际待处理子结果时,将所述子结果的状态标记为已就绪状态,并按照所述行情时间依次获取所述当前子结果后连续的处于所述已就绪状态的其他子结果,直至检测到有子结果处于未就绪状态,停止获取所述其他子结果,并反馈所述当前子结果及所述其他子结果,将所述任务指针指向处于所述未就绪状态的子结果;
当所述当前子结果不为所述实际待处理子结果时,将所述子结果的状态标记为已就绪状态。
例如:一个目标结果task中包含4个子请求,子请求编号依次为1、2、3、4,先收到子请求3的返回结果,而1、2的结果还没有收到,此时,只要更新子请求3的状态为1,表示已收到(即已就绪状态),由于子请求1、2的编号结果未收到,不能直接返回子请求3的结果给应用,否则接收到的结果时间将是乱序的。等待收到子请求1和子请求2的结果后,就可以把子请求3的结果一起发送给应用,这时就可以做到按1、2、3的顺序提交结果给应用。
上述实施例采用了触发式的方式查询各个任务的状态,相较于传统的轮询式查询方式更加实时而高效,且满足了回放任务的业务要求,并能够按照时间顺序回放任务。
由以上技术方案可以看出,本发明能够通过对查询与回放请求的拆分,实现资源的有效利用,同时实现高效且高并发的行情数据查询及回放。
如图2所示,是本发明基于行情数据的查询及回放装置的较佳实施例的功能模块图。所述基于行情数据的查询及回放装置11包括确定单元110、发送单元111、获取单元112、拆分单元113、提取单元114、反馈单元115。本发明所称的模块/单元是指一种能够被处理器所执行,并且能够完成固定功能的一系列计算机程序段,其存储在存储器中。在本实施例中,关于各模块/单元的功能将在后续的实施例中详述。
在本实施例中,所述基于行情数据的查询及回放装置11运行于客户端,包括:
对于向服务端发起的针对行情数据的每个请求,所述确定单元110确定每个请求的类型。
在本实施例中,所述服务端与所述客户端相通信,所述服务端用于根据所述客户端的请求向所述客户端提供服务。
例如:当所述客户端向所述服务端发送查询请求时,所述服务端根据所述客户端发起的查询请求进行数据查询,并向所述客户端返回查询结果;当所述客户端向所述服务端发送回放请求时,所述服务端根据所述客户端发起的回放请求获取指定时间段内的回放数据,并向所述服务端返回获取到的回放数据。
在本实施例中,所述行情数据可以包括证券交易系统下发的交易数据等。
在本实施例中,每个请求的类型可以包括,但不限于查询请求、回放请求等。
其中,发起所述查询请求是为了实时查询行情,以了解行情。
其中,发起所述回放请求可以进行交易策略回测,验证策略的有效性。
具体地,所述确定单元110确定每个请求的类型包括:
确定发起每个请求的接口;
通过发起每个请求的接口获取每个请求的协议包;
从每个请求的协议包中提取每个请求的类型字段标识;
根据每个请求的类型字段标识确定每个请求的类型。
通过上述实施例,能够通过接口自动实现请求类型的识别。
对于每个请求中的查询请求,所述发送单元111将所述查询请求写入所述客户端的发送队列。
在本实施例中,将所述查询请求写入所述客户端的发送队列后,即可等待向服务端发送。
对于每个请求中的回放请求,所述获取单元112获取所述回放请求的请求代码数目。
在本实施例中,不同的回放请求所对应的请求代码数目可能是不同的,例如:所述请求代码数据可以只有一个,也可以为几十个,甚至更多。
所述拆分单元113根据所述请求代码数目对所述回放请求进行拆分,得到多个子请求,并将所述多个子请求写入所述发送队列。
在本实施例中,为了避免数据量过大,需要对所述回放请求进行拆分。
具体地,所述拆分单元113根据所述请求代码数目对所述回放请求进行拆分,得到多个子请求,并将所述多个子请求写入所述发送队列包括:
对于每个回放请求,当所述请求代码数目大于或者等于1且小于或者等于5时,根据时间区间范围240分钟拆分所述回放请求为第一子请求,并将所述第一子请求的权重配置为1;
当所述请求代码数目大于或者等于6且小于或者等于10时,根据时间区间范围96分钟拆分所述回放请求为第二子请求,并将所述第二子请求的权重配置为2;
当所述请求代码数目大于或者等于11且小于或者等于50时,根据时间区间范围48分钟拆分所述回放请求为第三子请求,并将所述第三子请求的权重配置为3;
当所述请求代码数目大于或者等于51时,根据时间区间范围16分钟拆分所述回放请求为第四子请求,并将所述第四子请求的权重配置为5;
将每个回放请求对应的拆分后的每个子请求存入一个map表,其中,在每个map表中,将每个子请求的ID确定为key,将每个子请求的序号确定为value;
将所述map表对应的每个子请求写入队列,得到所述发送队列。
其中,请求代码数目、时间区间范围及权重等参数都是根据测试得到的性能最佳时的参数取值(如可以采用性能压测工具测试得到)。例如:分别利用8、16、32、48、96、192、240等多个分钟点作为时间区间范围进行测试,并从中选择能够提供最大并发能力的分钟点。权重可以根据耗时比例及并发体验等性能指标进行选择。
具体地,可以参见下表进行拆分:
请求代码数目 | 时间区间范围 | 权重 |
1-5 | 240分钟 | 1 |
6-10 | 96分钟 | 2 |
11-50 | 48分钟 | 3 |
51以上 | 16分钟 | 5 |
举例而言,每天的交易时间段一般是固定的,为9:30-11:30及13:00-15:00,共4小时。根据上表中的拆分策略,当要回放2只代码1天内的行情时,由于2只代码满足上表中的第一个区间,并且每天交易的开始时间9:30与结束时间15:00间正好共有240分钟,因此该回放任务不需要拆分,直接按照一个完整的查询请求发送到服务端即可。
再举例而言,当要回放12只代码5天内的行情时,即要回放时间为202206010900-202206051600的行情,根据上表得知,需要拆分成每48分钟一个子请求(非交易时间自动去除),则子请求大概参数变成:
12只代码 | 202206010930-202206011018 |
12只代码 | 202206011019-202206011107 |
12只代码 | ...... |
12只代码 | 202206051412-202206051500 |
因此,每天拆成5个小任务,共5天,12只代码5天内的行情对应的回放大任务拆分成了25个子请求。
可以理解的是,查询的条件一般是1只代码1天的行情数据,一般为1-2MB左右的数据量。回放请求转换到服务端,则相当于按照一定的条件查询,本质上也是查询请求,但回放请求可能请求的数据量非常大。即回放任务拆分后的子请求,就是一个个的数据库查询任务。应用传递给系统的回放任务和查询任务的区别是:
回放任务可以传以下参数:多个证券代码+开始日期+结束日期(可以是多天的,即回放可以是多个代码多天的行情量);
查询任务可以传以下参数:一个证券代码+开始日期+结束日期(结束日期必须等于开始日期,即只能查一个代码一天的行情量)。
并且,若要回放200只代码一个月的行情数据,由于数据量非常大,服务端不能一个查询结果就直接封装成一个应答包返回给客户端。一方面,服务端获取这个回放请求的数据量大,耗时太长,独占一个线程来处理它的时间太久,不利于多客户端大量并发的查询体验;另一方面,一个大包传回客户端的时间过久,又占用整个带宽使用,单个客户端并发体验差的同时,客户端网络抖动还可能导致大包传输失败。所以,在客户端将回放请求拆分成更小粒度的回放子请求,例如可以将回放请求拆分成和查询请求一样的1-2MB的粒度的子请求,那么服务端就无需区分是查询请求还是回放的子请求,解决了直接返回大包的问题。
同时,上述实施例通过将回放任务进行拆分,将回放任务统一转换成一个个的数据库查询操作,不再需要区分回放请求还是查询请求,充分考虑数据库查询并发吞吐能力,并充分协调资源使用。
所述发送单元111将所述发送队列中的每个子请求异步发送至所述服务端。
在本实施例中,在将所述发送队列中的每个子请求异步发送至所述服务端前,创建相互独立执行的请求发送线程及结果处理线程;
其中,所述请求发送线程用于不断发送向所述服务端发起的每个请求,所述结果处理线程用于不断处理所述服务端返回的请求结果。
具体地,在异步处理过程中,用一个请求发送线程专门处理发送,用另一个结果处理线程专门处理服务端的返回结果。请求发送线程将一个请求发往服务端后,不需要等待该请求返回数据,立刻可以发送下一个请求到服务端。而另一个结果处理线程不断的接收服务端的应答,并将应答写入接收队列等待下一步的处理。
上述实施例通过配置异步线程,使发送任务与接收任务能够相互独立的执行,进而提高了请求的高并发性,避免造成任务堵塞。
可以理解的是,发送主要受三个因素影响:发送端(即客户端)最大发送请求数,服务端队列是否已满(即服务端的最大查询请求数),客户端接收服务端的应答数据的接收队列是否满(即客户端对服务端返回的请求结果的最大接收数)。
具体地,所述发送单元111将所述发送队列中的每个子请求异步发送至所述服务端包括:
获取所述客户端的最大发送请求数,所述服务端的最大查询请求数,及所述客户端对所述服务端返回的请求结果的最大接收数;
获取所述客户端已发送且未被所述服务端接收结果的请求数作为当前发送请求数,所述服务端的当前查询请求数,及所述客户端对所述服务端返回的处于已接收且未被所述客户端处理的状态的请求结果数作为当前接收数;
当所述当前发送请求数小于或者等于所述最大发送请求数,所述当前查询请求数小于或者等于所述最大查询请求数,所述当前接收数小于或者等于所述最大接收数时,将所述发送队列中的每个子请求异步发送至所述服务端;
当所述当前发送请求数大于所述最大发送请求数时,阻塞从所述发送队列中获取请求,直至接收到所述服务端返回的请求结果且所述当前发送请求数递减至小于所述最大发送请求数时,将所述发送队列中的每个子请求异步发送至所述服务端;
当所述当前查询请求数大于所述最大查询请求数时,限制所述客户端的发送速度,直至达到预设时长,再次尝试将所述发送队列中的每个子请求异步发送至所述服务端;
当所述当前接收数大于所述最大接收数时,限制所述客户端的发送速度,直至所述客户端对所述服务端返回的处于已接收且未被所述客户端处理的状态的请求结果数小于或者等于所述最大接收数,继续将所述发送队列中的每个子请求异步发送至所述服务端。
在上述实施例中,三个因素中任意因素达到最大限制都会阻塞发送端向服务端发送请求。第一个因素限制目的是限制每个客户端的最大并发请求数,提高服务端并发响应其他客户端的体验。第二个因素限制目的是在服务端队列满后限制客户端发送速度,例如可以间隔500ms后再重试发送。第三个因素限制目的是在客户端接收队列满后,将应答消息缓存到服务端,避免服务端对该客户端应答消息缓存越来越大,并控制客户端发送的速度,直到接收缓存队列有一定的空余再继续发送请求。
上述实施例中发送策略的配置能够有效避免数据堵塞。
当接收到所述服务端根据每个请求返回的请求结果时,所述提取单元114从所述请求结果中提取所述回放请求对应的请求结果作为目标结果。
在本实施例中,从所述请求结果中提取所述查询请求对应的请求结果;
直接反馈所述查询请求对应的请求结果。
在上述实施例中,保证了查询请求的实时反馈,避免对查询请求的及时响应造成影响。
在本实施例中,可以根据字段标识从所述请求结果中提取所述回放请求对应的请求结果作为所述目标结果,本发明不限制。
所述反馈单元115根据行情时间,对所述目标结果进行触发式反馈。
在本实施例中,所述反馈单元115根据行情时间,对所述目标结果进行触发式反馈包括:
按照所述行情时间由早到晚的顺序处理所述目标结果中的每个子结果;
其中,对于任务指针指向的当前子结果,获取按照所述行情时间确定的实际待处理子结果;
当所述当前子结果为所述实际待处理子结果时,将所述子结果的状态标记为已就绪状态,并按照所述行情时间依次获取所述当前子结果后连续的处于所述已就绪状态的其他子结果,直至检测到有子结果处于未就绪状态,停止获取所述其他子结果,并反馈所述当前子结果及所述其他子结果,将所述任务指针指向处于所述未就绪状态的子结果;
当所述当前子结果不为所述实际待处理子结果时,将所述子结果的状态标记为已就绪状态。
例如:一个目标结果task中包含4个子请求,子请求编号依次为1、2、3、4,先收到子请求3的返回结果,而1、2的结果还没有收到,此时,只要更新子请求3的状态为1,表示已收到(即已就绪状态),由于子请求1、2的编号结果未收到,不能直接返回子请求3的结果给应用,否则接收到的结果时间将是乱序的。等待收到子请求1和子请求2的结果后,就可以把子请求3的结果一起发送给应用,这时就可以做到按1、2、3的顺序提交结果给应用。
上述实施例采用了触发式的方式查询各个任务的状态,相较于传统的轮询式查询方式更加实时而高效,且满足了回放任务的业务要求,并能够按照时间顺序回放任务。
由以上技术方案可以看出,本发明能够通过对查询与回放请求的拆分,实现资源的有效利用,同时实现高效且高并发的行情数据查询及回放。
如图3所示,是本发明实现基于行情数据的查询及回放方法的较佳实施例的计算机设备的结构示意图。
所述计算机设备1可以包括存储器12、处理器13和总线,还可以包括存储在所述存储器12中并可在所述处理器13上运行的计算机程序,例如基于行情数据的查询及回放程序。
本领域技术人员可以理解,所述示意图仅仅是计算机设备1的示例,并不构成对计算机设备1的限定,所述计算机设备1既可以是总线型结构,也可以是星形结构,所述计算机设备1还可以包括比图示更多或更少的其他硬件或者软件,或者不同的部件布置,例如所述计算机设备1还可以包括输入输出设备、网络接入设备等。
需要说明的是,所述计算机设备1仅为举例,其他现有的或今后可能出现的电子产品如可适应于本发明,也应包含在本发明的保护范围以内,并以引用方式包含于此。
其中,存储器12至少包括一种类型的可读存储介质,所述可读存储介质包括闪存、移动硬盘、多媒体卡、卡型存储器(例如:SD或DX存储器等)、磁性存储器、磁盘、光盘等。存储器12在一些实施例中可以是计算机设备1的内部存储单元,例如该计算机设备1的移动硬盘。存储器12在另一些实施例中也可以是计算机设备1的外部存储设备,例如计算机设备1上配备的插接式移动硬盘、智能存储卡(Smart Media Card,SMC)、安全数字(SecureDigital,SD)卡、闪存卡(Flash Card)等。进一步地,存储器12还可以既包括计算机设备1的内部存储单元也包括外部存储设备。存储器12不仅可以用于存储安装于计算机设备1的应用软件及各类数据,例如基于行情数据的查询及回放程序的代码等,还可以用于暂时地存储已经输出或者将要输出的数据。
处理器13在一些实施例中可以由集成电路组成,例如可以由单个封装的集成电路所组成,也可以是由多个相同功能或不同功能封装的集成电路所组成,包括一个或者多个中央处理器(Central Processing unit,CPU)、微处理器、数字处理芯片、图形处理器及各种控制芯片的组合等。处理器13是所述计算机设备1的控制核心(Control Unit),利用各种接口和线路连接整个计算机设备1的各个部件,通过运行或执行存储在所述存储器12内的程序或者模块(例如执行基于行情数据的查询及回放程序等),以及调用存储在所述存储器12内的数据,以执行计算机设备1的各种功能和处理数据。
所述处理器13执行所述计算机设备1的操作系统以及安装的各类应用程序。所述处理器13执行所述应用程序以实现上述各个基于行情数据的查询及回放方法实施例中的步骤,例如图1所示的步骤。
示例性的,所述计算机程序可以被分割成一个或多个模块/单元,所述一个或者多个模块/单元被存储在所述存储器12中,并由所述处理器13执行,以完成本发明。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机可读指令段,该指令段用于描述所述计算机程序在所述计算机设备1中的执行过程。例如,所述计算机程序可以被分割成确定单元110、发送单元111、获取单元112、拆分单元113、提取单元114、反馈单元115。
上述以软件功能模块的形式实现的集成的单元,可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机、计算机设备,或者网络设备等)或处理器(processor)执行本发明各个实施例所述基于行情数据的查询及回放方法的部分。
所述计算机设备1集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明实现上述实施例方法中的全部或部分流程,也可以通过计算机程序来指示相关的硬件设备来完成,所述的计算机程序可存储于一计算机可读存储介质中,该计算机程序在被处理器执行时,可实现上述各个方法实施例的步骤。
其中,所述计算机程序包括计算机程序代码,所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括:能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM,Read-Only Memory)、随机存取存储器等。
进一步地,计算机可读存储介质可主要包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需的应用程序等;存储数据区可存储根据区块链节点的使用所创建的数据等。
本发明所指区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(Blockchain),本质上是一个去中心化的数据库,是一串使用密码学方法相关联产生的数据块,每一个数据块中包含了一批次网络交易的信息,用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层等。
总线可以是外设部件互连标准(peripheral component interconnect,简称PCI)总线或扩展工业标准结构(extended industry standard architecture,简称EISA)总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示,在图3中仅用一根直线表示,但并不表示仅有一根总线或一种类型的总线。所述总线被设置为实现所述存储器12以及至少一个处理器13等之间的连接通信。
尽管未示出,所述计算机设备1还可以包括给各个部件供电的电源(比如电池),优选地,电源可以通过电源管理装置与所述至少一个处理器13逻辑相连,从而通过电源管理装置实现充电管理、放电管理、以及功耗管理等功能。电源还可以包括一个或一个以上的直流或交流电源、再充电装置、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。所述计算机设备1还可以包括多种传感器、蓝牙模块、Wi-Fi模块等,在此不再赘述。
进一步地,所述计算机设备1还可以包括网络接口,可选地,所述网络接口可以包括有线接口和/或无线接口(如WI-FI接口、蓝牙接口等),通常用于在该计算机设备1与其他计算机设备之间建立通信连接。
可选地,该计算机设备1还可以包括用户接口,用户接口可以是显示器(Display)、输入单元(比如键盘(Keyboard)),可选地,用户接口还可以是标准的有线接口、无线接口。可选地,在一些实施例中,显示器可以是LED显示器、液晶显示器、触控式液晶显示器以及OLED(Organic Light-Emitting Diode,有机发光二极管)触摸器等。其中,显示器也可以适当的称为显示屏或显示单元,用于显示在计算机设备1中处理的信息以及用于显示可视化的用户界面。
应该了解,所述实施例仅为说明之用,在专利申请范围上并不受此结构的限制。
图3仅示出了具有组件12-13的计算机设备1,本领域技术人员可以理解的是,图3示出的结构并不构成对所述计算机设备1的限定,可以包括比图示更少或者更多的部件,或者组合某些部件,或者不同的部件布置。
结合图1,所述计算机设备1中的所述存储器12存储多个指令以实现一种基于行情数据的查询及回放方法,所述处理器13可执行所述多个指令从而实现:
对于向服务端发起的针对行情数据的每个请求,确定每个请求的类型;
对于每个请求中的查询请求,将所述查询请求写入所述客户端的发送队列;
对于每个请求中的回放请求,获取所述回放请求的请求代码数目;
根据所述请求代码数目对所述回放请求进行拆分,得到多个子请求,并将所述多个子请求写入所述发送队列;
将所述发送队列中的每个子请求异步发送至所述服务端;
当接收到所述服务端根据每个请求返回的请求结果时,从所述请求结果中提取所述回放请求对应的请求结果作为目标结果;
根据行情时间,对所述目标结果进行触发式反馈。
具体地,所述处理器13对上述指令的具体实现方法可参考图1对应实施例中相关步骤的描述,在此不赘述。
需要说明的是,本案中所涉及到的数据均为合法取得。
在本发明所提供的几个实施例中,应该理解到,所揭露的系统,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述模块的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式。
本发明可用于众多通用或专用的计算机系统环境或配置中。例如:个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。本发明可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本发明,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
所述作为分离部件说明的模块可以是或者也可以不是物理上分开的,作为模块显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。
另外,在本发明各个实施例中的各功能模块可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用硬件加软件功能模块的形式实现。
对于本领域技术人员而言,显然本发明不限于上述示范性实施例的细节,而且在不背离本发明的精神或基本特征的情况下,能够以其他的具体形式实现本发明。
因此,无论从哪一点来看,均应将实施例看作是示范性的,而且是非限制性的,本发明的范围由所附权利要求而不是上述说明限定,因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本发明内。不应将权利要求中的任何附关联图标记视为限制所涉及的权利要求。
此外,显然“包括”一词不排除其他单元或步骤,单数不排除复数。本发明中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一、第二等词语用来表示名称,而并不表示任何特定的顺序。
最后应说明的是,以上实施例仅用以说明本发明的技术方案而非限制,尽管参照较佳实施例对本发明进行了详细说明,本领域的普通技术人员应当理解,可以对本发明的技术方案进行修改或等同替换,而不脱离本发明技术方案的精神和范围。
Claims (9)
1.一种基于行情数据的查询及回放方法,应用于客户端,其特征在于,所述基于行情数据的查询及回放方法包括:
对于向服务端发起的针对行情数据的每个请求,确定每个请求的类型;
对于每个请求中的查询请求,将所述查询请求写入所述客户端的发送队列;
对于每个请求中的回放请求,获取所述回放请求的请求代码数目;其中,所述回放请求是指按照条件进行查询的请求,所述回放请求查询的数据量大于所述查询请求;
根据所述请求代码数目对所述回放请求进行拆分,得到多个子请求,并将所述多个子请求写入所述发送队列;
将所述发送队列中的每个子请求异步发送至所述服务端,包括:获取所述客户端的最大发送请求数,所述服务端的最大查询请求数,及所述客户端对所述服务端返回的请求结果的最大接收数;获取所述客户端已发送且未被所述服务端接收结果的请求数作为当前发送请求数,所述服务端的当前查询请求数,及所述客户端对所述服务端返回的处于已接收且未被所述客户端处理的状态的请求结果数作为当前接收数;当所述当前发送请求数小于或者等于所述最大发送请求数,所述当前查询请求数小于或者等于所述最大查询请求数,所述当前接收数小于或者等于所述最大接收数时,将所述发送队列中的每个子请求异步发送至所述服务端;当所述当前发送请求数大于所述最大发送请求数时,阻塞从所述发送队列中获取请求,直至接收到所述服务端返回的请求结果且所述当前发送请求数递减至小于所述最大发送请求数时,将所述发送队列中的每个子请求异步发送至所述服务端;当所述当前查询请求数大于所述最大查询请求数时,限制所述客户端的发送速度,直至达到预设时长,再次尝试将所述发送队列中的每个子请求异步发送至所述服务端;当所述当前接收数大于所述最大接收数时,限制所述客户端的发送速度,直至所述客户端对所述服务端返回的处于已接收且未被所述客户端处理的状态的请求结果数小于或者等于所述最大接收数,继续将所述发送队列中的每个子请求异步发送至所述服务端;
当接收到所述服务端根据每个请求返回的请求结果时,从所述请求结果中提取所述回放请求对应的请求结果作为目标结果;
根据行情时间,对所述目标结果进行触发式反馈。
2.如权利要求1所述的基于行情数据的查询及回放方法,其特征在于,所述确定每个请求的类型包括:
确定发起每个请求的接口;
通过发起每个请求的接口获取每个请求的协议包;
从每个请求的协议包中提取每个请求的类型字段标识;
根据每个请求的类型字段标识确定每个请求的类型。
3.如权利要求1所述的基于行情数据的查询及回放方法,其特征在于,在将所述发送队列中的每个子请求异步发送至所述服务端前,所述方法还包括:
创建相互独立执行的请求发送线程及结果处理线程;
其中,所述请求发送线程用于不断发送向所述服务端发起的每个请求,所述结果处理线程用于不断处理所述服务端返回的请求结果。
4.如权利要求1所述的基于行情数据的查询及回放方法,其特征在于,所述根据所述请求代码数目对所述回放请求进行拆分,得到多个子请求,并将所述多个子请求写入所述发送队列包括:
对于每个回放请求,当所述请求代码数目大于或者等于1且小于或者等于5时,根据时间区间范围240分钟拆分所述回放请求为第一子请求,并将所述第一子请求的权重配置为1;
当所述请求代码数目大于或者等于6且小于或者等于10时,根据时间区间范围96分钟拆分所述回放请求为第二子请求,并将所述第二子请求的权重配置为2;
当所述请求代码数目大于或者等于11且小于或者等于50时,根据时间区间范围48分钟拆分所述回放请求为第三子请求,并将所述第三子请求的权重配置为3;
当所述请求代码数目大于或者等于51时,根据时间区间范围16分钟拆分所述回放请求为第四子请求,并将所述第四子请求的权重配置为5;
将每个回放请求对应的拆分后的每个子请求存入一个map表,其中,在每个map表中,将每个子请求的ID确定为key,将每个子请求的序号确定为value;
将所述map表对应的每个子请求写入队列,得到所述发送队列。
5.如权利要求1所述的基于行情数据的查询及回放方法,其特征在于,所述方法还包括:
从所述请求结果中提取所述查询请求对应的请求结果;
直接反馈所述查询请求对应的请求结果。
6.如权利要求1所述的基于行情数据的查询及回放方法,其特征在于,所述根据行情时间,对所述目标结果进行触发式反馈包括:
按照所述行情时间由早到晚的顺序处理所述目标结果中的每个子结果;
其中,对于任务指针指向的当前子结果,获取按照所述行情时间确定的实际待处理子结果;
当所述当前子结果为所述实际待处理子结果时,将所述子结果的状态标记为已就绪状态,并按照所述行情时间依次获取所述当前子结果后连续的处于所述已就绪状态的其他子结果,直至检测到有子结果处于未就绪状态,停止获取所述其他子结果,并反馈所述当前子结果及所述其他子结果,将所述任务指针指向处于所述未就绪状态的子结果;
当所述当前子结果不为所述实际待处理子结果时,将所述子结果的状态标记为已就绪状态。
7.一种基于行情数据的查询及回放装置,运行于客户端,其特征在于,所述基于行情数据的查询及回放装置包括:
确定单元,用于对于向服务端发起的针对行情数据的每个请求,确定每个请求的类型;
发送单元,用于对于每个请求中的查询请求,将所述查询请求写入所述客户端的发送队列;
获取单元,用于对于每个请求中的回放请求,获取所述回放请求的请求代码数目;其中,所述回放请求是指按照条件进行查询的请求,所述回放请求查询的数据量大于所述查询请求;
拆分单元,用于根据所述请求代码数目对所述回放请求进行拆分,得到多个子请求,并将所述多个子请求写入所述发送队列;
所述发送单元,还用于将所述发送队列中的每个子请求异步发送至所述服务端,包括:获取所述客户端的最大发送请求数,所述服务端的最大查询请求数,及所述客户端对所述服务端返回的请求结果的最大接收数;获取所述客户端已发送且未被所述服务端接收结果的请求数作为当前发送请求数,所述服务端的当前查询请求数,及所述客户端对所述服务端返回的处于已接收且未被所述客户端处理的状态的请求结果数作为当前接收数;当所述当前发送请求数小于或者等于所述最大发送请求数,所述当前查询请求数小于或者等于所述最大查询请求数,所述当前接收数小于或者等于所述最大接收数时,将所述发送队列中的每个子请求异步发送至所述服务端;当所述当前发送请求数大于所述最大发送请求数时,阻塞从所述发送队列中获取请求,直至接收到所述服务端返回的请求结果且所述当前发送请求数递减至小于所述最大发送请求数时,将所述发送队列中的每个子请求异步发送至所述服务端;当所述当前查询请求数大于所述最大查询请求数时,限制所述客户端的发送速度,直至达到预设时长,再次尝试将所述发送队列中的每个子请求异步发送至所述服务端;当所述当前接收数大于所述最大接收数时,限制所述客户端的发送速度,直至所述客户端对所述服务端返回的处于已接收且未被所述客户端处理的状态的请求结果数小于或者等于所述最大接收数,继续将所述发送队列中的每个子请求异步发送至所述服务端;
提取单元,用于当接收到所述服务端根据每个请求返回的请求结果时,从所述请求结果中提取所述回放请求对应的请求结果作为目标结果;
反馈单元,用于根据行情时间,对所述目标结果进行触发式反馈。
8.一种计算机设备,其特征在于,所述计算机设备包括:
存储器,存储至少一个指令;及
处理器,执行所述存储器中存储的指令以实现如权利要求1至6中任意一项所述的基于行情数据的查询及回放方法。
9.一种计算机可读存储介质,其特征在于:所述计算机可读存储介质中存储有至少一个指令,所述至少一个指令被计算机设备中的处理器执行以实现如权利要求1至6中任意一项所述的基于行情数据的查询及回放方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211208194.5A CN115269709B (zh) | 2022-09-30 | 2022-09-30 | 基于行情数据的查询及回放方法、装置、设备及介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202211208194.5A CN115269709B (zh) | 2022-09-30 | 2022-09-30 | 基于行情数据的查询及回放方法、装置、设备及介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN115269709A CN115269709A (zh) | 2022-11-01 |
CN115269709B true CN115269709B (zh) | 2022-12-30 |
Family
ID=83758079
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202211208194.5A Active CN115269709B (zh) | 2022-09-30 | 2022-09-30 | 基于行情数据的查询及回放方法、装置、设备及介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115269709B (zh) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117827740B (zh) * | 2024-03-05 | 2024-05-14 | 上海特高信息技术有限公司 | 一种基于fpga的模块化行情数据回放方法及回放系统 |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8148622B2 (en) * | 2009-07-01 | 2012-04-03 | Apple Inc. | Media playback queuing for playback management |
CN105989179A (zh) * | 2015-03-06 | 2016-10-05 | 北京邮电大学 | 金融数据处理方法及系统 |
CN105808661B (zh) * | 2016-02-29 | 2019-03-08 | 浪潮天元通信信息系统有限公司 | 一种数据查询的方法及装置 |
CN111552622B (zh) * | 2020-04-30 | 2023-11-07 | 上海英方软件股份有限公司 | 一种行情数据的回放装置及方法 |
CN113297222A (zh) * | 2021-05-25 | 2021-08-24 | 北京京东振世信息技术有限公司 | 报表数据的获取方法、装置、电子设备和存储介质 |
CN114817387A (zh) * | 2022-04-01 | 2022-07-29 | 盈立数智科技(深圳)有限公司 | 一种基于日志文件的行情重放方法及系统 |
-
2022
- 2022-09-30 CN CN202211208194.5A patent/CN115269709B/zh active Active
Also Published As
Publication number | Publication date |
---|---|
CN115269709A (zh) | 2022-11-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN114124968B (zh) | 基于行情数据的负载均衡方法、装置、设备及介质 | |
CN111770002B (zh) | 测试数据转发控制方法、装置、可读存储介质和电子设备 | |
CN112653760B (zh) | 跨服务器的文件传输方法、装置、电子设备及存储介质 | |
CN115269709B (zh) | 基于行情数据的查询及回放方法、装置、设备及介质 | |
CN113163009A (zh) | 数据传送方法、装置、电子设备及存储介质 | |
CN111814033A (zh) | 用于投放的媒介信息确定方法、装置、设备和存储介质 | |
CN112084486A (zh) | 用户信息验证方法、装置、电子设备及存储介质 | |
CN112702228A (zh) | 服务限流响应方法、装置、电子设备及可读存储介质 | |
CN115617403A (zh) | 基于任务切分的清算任务执行方法、装置、设备及介质 | |
CN116755637B (zh) | 交易数据存储方法、装置、设备及介质 | |
CN111814045A (zh) | 数据查询方法、装置、电子设备及存储介质 | |
CN114169303A (zh) | 基于vue.js的表格编辑方法、装置、设备及介质 | |
CN114185776A (zh) | 应用程序的大数据埋点方法、装置、设备及介质 | |
CN115314570B (zh) | 基于协议开发框架的数据下发方法、装置、设备及介质 | |
CN114675976B (zh) | 基于kubernetes的GPU共享方法、装置、设备及介质 | |
CN115101152A (zh) | 样本优先级切换方法、装置、设备及介质 | |
CN114201466A (zh) | 防缓存击穿方法、装置、设备及可读存储介质 | |
CN115277859B (zh) | 请求调度方法、装置、设备及介质 | |
CN115065642B (zh) | 带宽限制下的代码表请求方法、装置、设备及介质 | |
CN115174698B (zh) | 基于表项索引的行情数据解码方法、装置、设备及介质 | |
CN116630048B (zh) | 基于期货行情k线的交易方法、装置、设备及介质 | |
CN114860349B (zh) | 数据加载方法、装置、设备及介质 | |
CN116225789B (zh) | 交易系统备份能力检测方法、装置、设备及介质 | |
CN116483747A (zh) | 行情快照下发方法、装置、设备及介质 | |
CN114666165B (zh) | 查询请求响应方法、装置、设备及介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |