一种行情数据处理方法、系统、设备与流程

1.本技术涉及网络数据处理技术领域，尤其涉及一种行情数据处理的技术。


背景技术：

2.随着金融证券市场的不断开发和发展，投资金融证券行业的人越来越多，作为金融证券市场交易的各类交易所，在交易时段会产生大量的实时交易的行情源数据。为了满足不同需求，交易所或中间数据服务商会在服务端采用各种证券分析技术和软件技术对行情源数据进行处理，向众多的业务提供商提供其需求的标的行情数据，以使业务提供商向其用户提供业务。而标的行情数据的低时延对投资者用户的交易决策至关重要。
3.而随着上市企业越来越多，并且可交易的金融证券产品越来越多，以及基于行情源数据可提供的功能越来越多，标的的数量也越来越多，要处理和传输的行情数据越来越大，通常采用的消息中间件或http(hyper text transfer protocol，超文本传输协议)轮询等方式的时延较高，如何保证对行情数据处理和传输的低时延成为一个需要面对和解决的问题。


技术实现要素：

4.本技术的目的是提供一种行情数据处理的技术方案，用以至少部分解决现有行情数据处理和传输的时延较大的技术问题。
5.根据本技术的一个方面，提供了一种行情数据处理方法，其特征在于，应用于接入服务端，所述方法包括：
6.接收分发服务端发送的订阅请求，其中，所述订阅请求至少包括订阅的行情数据的类型；
7.基于所述订阅请求，向行情数据源发起订阅，以获取行情源数据；
8.将所述行情源数据转换成对应所述类型的行情数据，并根据所述行情数据中的标的代码，将所述行情数据进行hash分组，以获取标的行情数据；
9.将所述标的行情数据发送至所述分发服务端。
10.可选地，其中，所述接收分发服务端发送的订阅请求包括：
11.基于与分发服务端之间的quic(quickudpinternetconnection，快速udp互联网连接)连接，接收所述分发服务端发送的订阅请求；
12.其中，所述将所述标的行情数据发送至所述分发服务端包括：
13.基于与所述分发服务端之间的quic连接，将所述标的行情数据发送至所述分发服务端。
14.可选地，其中，所述基于所述订阅请求，向行情数据源发起订阅包括：
15.将所述订阅请求转换成符合所述行情数据源要求的格式后发送至所述行情数据源，以向所述行情数据源发起订阅。
16.根据本技术的又一方面，提供了一种行情数据处理方法，其特征在于，应用于分发
服务端，所述方法包括：
17.接收业务端发送的订阅请求，其中，所述订阅请求至少包括订阅的行情数据的类型；
18.对所述订阅请求进行处理后发送至接入服务端；
19.接收所述接入服务端返回的对应的标的行情数据并发送至所述业务端，其中，所述标的行情数据是在所述接入服务端将接收到的行情源数据转换成对应所述类型的行情数据，并根据标的代码进行hash分组后获得的。
20.可选地，其中，所述接收业务端发送的订阅请求包括：
21.基于与业务端之间的quic连接，接收所述业务端发送的订阅请求；
22.其中，所述将订阅请求发送至接入服务端包括：
23.基于与接入服务端之间的quic连接，将所述订阅请求发送至所述接入服务端；
24.其中，所述接收所述接入服务端返回的对应的标的行情数据并发送至所述业务端包括：
25.基于与所述接入服务端之间的quic连接，以及与所述业务端之间的quic连接，接收所述接入服务端返回的对应的标的行情数据并发送至所述业务端。
26.可选地，其中，所述订阅请求还包括：
27.订阅的标的代码；
28.其中，所述接收所述接入服务端返回的对应的标的行情数据并发送至所述业务端包括：
29.接收所述接入服务端返回的对应的标的行情数据并根据所述订阅的标的代码进行筛选后发送至所述业务端。
30.可选地，其中，若所述业务端有多个，所述接收业务端发送的订阅请求，其中，所述订阅请求至少包括订阅的行情数据的类型包括：
31.接收不同业务端发送的订阅请求，其中，所述订阅请求至少包括发起订阅的业务端标识和订阅的行情数据的类型；
32.其中，所述对所述订阅请求进行处理后发送至接入服务端之前，所述方法还包括：
33.维护订阅关系，其中，所述订阅关系包括订阅的行情数据的类型及订阅所述类型的业务端标识；
34.其中，所述对所述订阅请求进行处理后发送至接入服务端包括：
35.对不同业务端发送的订阅请求基于订阅的行情数据的类型进行聚合，得到聚合后的订阅请求；
36.将聚合后的包含订阅的行情数据的类型的订阅请求发送至接入服务端；
37.其中，所述接收所述接入服务端返回的对应的标的行情数据并发送至所述业务端包括：
38.接收所述接入服务端返回的对应的标的行情数据并根据所述订阅关系发送至对应的业务端。
39.可选地，其中，所述订阅请求还包括订阅许可信息，在所述维护订阅关系之前，所述方法还包括：基于所述许可信息对订阅请求进行认证；
40.其中，所述维护订阅关系包括：基于通过认证的订阅请求，维护订阅关系。
41.根据本技术的另一方面，提供了一种行情数据处理系统，其特征在于，所述系统包括：
42.业务端，用于向分发服务端发送订阅请求，以订阅标的行情数据，以及接收所述分发服务端发送的对应的标的行情数据；
43.分发服务端，用于接收所述业务端发送的订阅请求并进行处理，将处理后的订阅请求发送至接入服务端，以及接收所述接入服务端返回的对应的标的行情数据并发送至所述业务端；
44.接入服务端，用于接收所述分发服务端发送的订阅请求，并基于所述订阅请求，向行情数据源发起订阅，以获取行情源数据，再将所述行情源数据转换成对应的行情数据，以及根据所述行情数据中的标的代码，将所述行情数据进行hash分组，以获取标的行情数据，并将所述标的行情数据发送至所述分发服务端。
45.与现有技术相比，本技术提供了一种行情数据处理的技术方案，行情数据处理系统包括业务端、分发服务端和接入服务端，其中，业务端基于业务需求确定要订阅的行情数据类型，向分发服务端发送订阅请求，以订阅标的行情数据；分发服务端接收业务端发送的订阅请求并进行处理，将处理后的订阅请求发送至接入服务端；接入服务端接收分发服务端发送的订阅请求，并基于订阅请求向行情数据源发起订阅，以获取行情源数据，再将获取的行情源数据转换成对应的行情数据，以及根据行情数据中的标的代码，将行情数据进行hash分组，以获取标的行情数据，并将所述标的行情数据发送至分发服务端；分发服务器再向对应的业务端发送其订阅的标的行情数据，以实现行情数据处理。可选地，业务端和分发服务端之间、分发服务端和接入服务端之间都采用quic连接。
46.本技术提供的一种行情数据处理的技术方案可带来的技术效果：
47.可针对全量或者按需提交的订阅请求，将获取的行情源数据转换后按照标的代码进行hash分组，相同标的代码的行情数据由同一线程处理，不同标的代码的行情数据由不同线程处理，既能够保证同一标的代码的行情数据在时间上是顺序处理的，又能根据标的代码数量动态设置线程数，对不同标的代码的行情数据进行并行处理，可提升处理行情数据的能力，减少行情数据处理的时延。进一步地，建立quic连接进行行情数据网络传输，还可进一步减少网络传输的时延。从而能够快速将行情数据传输到业务端，以使用户投资者能获取到实时行情数据。
附图说明
48.通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：
49.图1示出根据本技术一个方面的应用在接入服务端的一种行情数据处理的方法流程图；
50.图2示出根据本技术另一个方面的应用在分发服务端的一种行情数据处理的方法流程图；
51.图3示出根据本技术又一个方面的一种行情数据处理的系统示意图；
52.图4示出根据本技术又一个方面的一个可选实施例的一种行情数据处理系统的结构示意图；
53.附图中相同或相似的附图标记代表相同或相似的部件。
具体实施方式
54.下面结合附图对本发明作进一步详细描述。
55.在本技术的各实施例的一个典型的配置中，方法的执行主体、系统各可信方和/或装置各模块均包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
56.内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的示例。
57.计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
58.为更进一步阐述本技术所采取的技术手段及取得的效果，下面结合附图及各实施例，对本技术的技术方案，进行清楚和完整的描述。
59.金融证券行业中，不同的第三方行情数据源提供商对向其订阅行情数据的订阅请求要求可能不同。通常是行情数据服务商的行情数据处理系统接收到业务端的订阅请求，按照第三方行情数据源提供商的要求处理后向第三方行情数据源发出订阅请求，在获得对应的行情源数据后进行处理，再向业务端推送与其订阅请求相对应的行情数据。
60.基于安全考虑，第三方行情数据源都只允许白名单内的机器可以访问。在确保安全性的前提下，为了可以让更多业务端能够获得基于第三方行情数据源的行情数据，通常在业务端和行情数据源之间引入中间层，以接入行情源数据并完成数据处理、分发。
61.本技术提供的一种行情数据处理系统包括接入服务端100、分发服务端200和业务端300，其中，接入服务端100作为第三方行情数据源的代理服务端，可以是独立部署在idc(internet data center，互联网数据中心)，通过专线与第三方行情数据源通信交互，并通过专线与分发服务器200通信交互，而分发服务器200作为业务端300的代理服务端，还通过网络与业务端300通信交互。
62.其中，接入服务端100、分发服务端200和业务端300为安装有相应软硬件的计算机设备和/或云。其中，所述计算机设备包括但不限于个人计算机、笔记本电脑、工业计算机、服务器、网络主机、单个网络服务器、多个网络服务器集；所述云由基于云计算(cloud computing)的大量计算机或网络服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个虚拟超级计算机。
63.在此，所述计算机设备和/或云仅为举例，其他现有的或者今后可能出现的设备和/或资源共享平台如适用于本技术也应包含在本技术的保护范围内，在此，以引用的方式包含于此。
64.图1示出根据本技术一个方面的应用在接入服务端的一种行情数据处理的方法流程图，其中，一个实施例的方法包括：
65.s101接收分发服务端发送的订阅请求，其中，所述订阅请求至少包括订阅的行情数据的类型；
66.s102基于所述订阅请求，向行情数据源发起订阅，以获取行情源数据；
67.s103将所述行情源数据转换成对应所述类型的行情数据，并根据所述行情数据中的标的代码，将所述行情数据进行hash分组，以获取标的行情数据；
68.s104将所述标的行情数据发送至所述分发服务端。
69.在该实施例中，所述方法的执行主体是接入服务端100。
70.在步骤s101中，接入服务端100接收分发服务端200发送的订阅请求，其中，该订阅请求至少包括订阅的行情数据的类型。
71.其中，不同业务端300可以根据其业务需要或用户需求向分发服务端200发送针对全部类型或不同类型的行情数据的订阅请求，以订阅所述类型的标的行情数据。其中，行情数据可以包括不同证券交易所或第三方数据提供商提供的各种行情数据，例如：股票行情、股票期权行情、基金行情、债券行情等各种行情数据，行情数据的类型可以是快照、成交明细、报价信息、经济队列、实时分时走势图等。分发服务端200接收到业务端300发送的订阅请求，进行处理后发送至接入服务端100。
72.继续在该实施例中，在步骤s102中，接入服务端100根据接收到的该订阅请求，向相应的证券交易所或第三方数据提供商等的行情数据源发起订阅，以获取行情源数据。
73.不同的证券交易所或第三方数据提供商提供不同的订阅内容，对接收到的订阅请求有不同的格式要求。
74.一个可选实施例中，所述基于所述订阅请求，向行情数据源发起订阅包括：
75.将所述订阅请求转换成符合所述行情数据源要求的格式后发送至所述行情数据源，以向所述行情数据源发起订阅。
76.另外，并不是所有的订阅请求都需要向行情数据源发起订阅，只有接入服务端100接收到的订阅请求是针对之前未订阅过的行情数据时才需要向行情数据源发起订阅，若接收到的订阅请求针对的是之前其它业务端300发起订阅过的行情数据，接入服务端100无需重复向行情数据源发起订阅。因此，接入服务端100需要先对接收到的订阅请求进行判断处理后再向行情数据源发起订阅。
77.继续在该实施例中，在步骤s103中，接入服务端100将获取的行情源数据转换成对应上述类型的行情数据，并根据该行情数据中的标的代码，将该行情数据按照标的代码进行hash分组，以获取标的行情数据。
78.其中，行情源数据通常是二进制的数据，而且其中可能包含与订阅无关的数据，因此，接入服务端100先对获取的行情数据源进行解码转换处理，然后整理成与订阅请求中的类型相对应的行情数据。另外，考虑到行情数据中相同标的代码(比如同一个股票、期权、债券或基金)的行情数据有时间属性，需要顺序处理和传输，而不同标的代码的行情数据之间没有时间属性，不需要考虑顺序处理和传输，可考虑采用多线程并行处理的方式来处理行情数据，根据标的代码对行情数据进行hash分组处理，将相同标的代码的行情数据顺序送入同一线程池，而不同标的代码的行情数据分别送入不同线程池。比如，以数组的形式存储
线程池中的行情数据，根据hash分组的组号对动态分配的线程数取模，获取到下标后将行情数据送入对应的线程池，队列的worker(工作者)从相关线程池中依次取出线程任务执行，从而保证了相同标的代码的行情数据是顺序执行的。并且，还可设置单个线程任务的超时时间，以防止因异常导致堵塞后续数据的处理。
79.不但增加了接入服务端100对行情数据处理的能力，还降低了行情数据处理的时延。而且还可减少占用的线程数量，以及降低线程切换的成本。
80.继续在该实施例中，在步骤s104中，接入服务端100将该标的行情数据发送至分发服务端200。
81.网络传输实时数据通常采用的消息中间件或http轮询等方式的传输时延较高。
82.本技术中的行情数据包括实时数据，考虑传输的低延时要求，接入服务端与分发服务端之间基于quic协议进行通信，通过quic连接传输数据。其中，quic协议是谷歌制定的一种基于udp(user datagram protocol，用户数据报协议)的低时延的互联网传输层协议。
83.一个可选实施例中，所述接收分发服务端发送的订阅请求包括：
84.基于与分发服务端之间的quic连接，接收所述分发服务端发送的订阅请求；
85.其中，所述将所述标的行情数据发送至所述分发服务端包括：
86.基于与所述分发服务端之间的quic连接，将所述标的行情数据发送至所述分发服务端。
87.对于某些对quic有限制的应用场景，可以考虑tcp(transmission control protocol，传输控制协议)连接，虽然在建立连接过程中需要多次握手，效率较低，但一旦连接建立，其数据传输的时延较低。
88.一个可选实施例中，所述接收分发服务端发送的订阅请求包括：
89.基于与分发服务端之间的tcp连接，接收所述分发服务端发送的订阅请求；
90.其中，所述将所述标的行情数据发送至所述分发服务端包括：
91.基于与所述分发服务端之间的tcp连接，将所述标的行情数据发送至所述分发服务端。
92.图2示出根据本技术另一个方面的应用在分发服务端的一种行情数据处理的方法流程图，其中，一个实施例的方法包括：
93.s201接收业务端发送的订阅请求，其中，所述订阅请求至少包括订阅的行情数据的类型；
94.s202对所述订阅请求进行处理后发送至接入服务端；
95.s203接收所述接入服务端返回的对应的标的行情数据并发送至所述业务端，其中，所述标的行情数据是在所述接入服务端将接收到的行情源数据转换成对应所述类型的行情数据，并根据标的代码进行hash分组后获得的。
96.在该实施例中，所述方法的执行主体是分发服务端200。
97.在步骤s201中，分发服务端200接收业务端300发送的订阅请求，其中，该订阅请求至少包括订阅的行情数据的类型。
98.其中，不同业务端300根据其业务需要或用户需求向分发服务端200发送针对不同类型的行情数据的订阅请求，其中，行情数据可以包括不同证券交易所或第三方数据提供商提供的各种行情数据，例如：股票行情、股票期权行情、基金行情、债券行情等各种行情数
据，行情数据的类型可以是快照、成交明细、报价信息、经济队列、实时分时走势图等。
99.继续在该实施例中，在步骤s202中，分发服务端200对该订阅请求进行处理后发送至接入服务端100。
100.继续在该实施例中，在步骤s203中，分发服务器200接收接入服务端100返回的对应的标的行情数据并发送至业务端300，其中，该标的行情数据是在接入服务端100将接收到的行情源数据转换成对应上述类型的行情数据，并根据标的代码进行hash分组后获得的。
101.在该实施例中，业务端300根据业务需要或用户需求，不但可以根据行情数据的类型进行订阅，还可以根据标的代码进行订阅，以向用户提供颗粒度更小的订阅服务。
102.一个可选实施例中，所述订阅请求还包括：
103.订阅的标的代码；
104.其中，所述接收所述接入服务端返回的对应的标的行情数据并发送至所述业务端包括：
105.接收所述接入服务端返回的对应的标的行情数据并根据所述订阅的标的代码进行筛选后发送至所述业务端。
106.其中，若订阅请求中还包括订阅的行情数据的标的代码，分发服务端200在收到接入服务端100响应订阅请求而发送的对应类型的行情数据后，再从总筛选出与该标的代码相符的行情数据后发送至业务端300。
107.通常分发服务端200会向多个业务端300提供数据服务。
108.一个可选实施例中，若业务端有多个，所述接收业务端发送的订阅请求，其中，所述订阅请求至少包括订阅的行情数据的类型包括：
109.接收不同业务端发送的订阅请求，其中，所述订阅请求至少包括发起订阅的业务端标识和订阅的行情数据的类型；
110.其中，所述对所述订阅请求进行处理后发送至接入服务端之前，所述方法还包括：
111.维护订阅关系，其中，所述订阅关系包括订阅的行情数据的类型及订阅所述类型的业务端标识；
112.其中，所述对所述订阅请求进行处理后发送至接入服务端包括：
113.对不同业务端发送的订阅请求基于订阅的行情数据的类型进行聚合，得到聚合后的订阅请求；
114.将聚合后的包含订阅的行情数据的类型的订阅请求发送至接入服务端；
115.其中，所述接收所述接入服务端返回的对应的标的行情数据并发送至所述业务端包括：
116.接收所述接入服务端返回的对应的标的行情数据并根据所述订阅关系发送至对应的业务端。
117.在该可选实施例中，业务端300发送的订阅请求中至少包括发起订阅的业务端标识和订阅的行情数据的类型，其中，业务端标识与业务端一一对应。
118.其中，由于不同业务端300订阅的行情数据的类型可能相同，为了减轻接入服务端100以及行情数据源不必要的负担，不应该接入服务端100发送类型相同的行情数据的订阅请求，因此，分发服务端200有必要对来自不同业务端300的订阅请求进行记录，以维护不同
业务端300的订阅关系，在维护的订阅关系中，包括发起订阅的业务端标识以及订阅的行情数据的类型。当不同业务端300订阅不同类型的行情数据时才将每个业务端300发送的订阅请求都发送至接入服务端100，若不同业务端300订阅的是相同类型的行情数据，则会记录并维护订阅关系后，对相同类型的订阅请求进行聚合，只向接入服务端100发送一个该类型的行情数据的订阅请求。比如：有两个业务端m和n都订阅了同一标的的行情数据，则分发服务端200在收到两个订阅请求后，记录并维护业务端m和n的订阅信息，将这两个订阅请求聚合成一个订阅请求，然后向接入服务端100发送该订阅请求。相应地，分发服务端200在收到接入服务端100发回的对应的标的行情数据后，会根据记录并维护的订阅关系，向业务端m和n发送。
119.其中，若业务端m解除该订阅请求，业务端n继续订阅，则分发服务端200会修改相关记录，但不会触发向接入服务端100发送解除订阅请求。只有当业务单m和n都解除该订阅请求，分发服务端200才会删除相关记录，并触发向接入服务端100发送解除订阅请求。
120.出于安全性考虑，同时由于分发服务端200以及接入服务端100的资源及处理能力有限，为了更好管理及服务于业务端300，杜绝非许可的业务端300占用资源，有必要对接入分发服务端200的业务端300进行许可认证，比如针对业务端颁发接入许可证书，证书中包含了与业务端一一对应的标识，只有获得接入许可的业务端300发送的订阅请求才会被分发服务端200接受。
121.一个可选实施例中，业务端300发送的订阅请求还包括订阅许可信息，在所述维护订阅关系之前，所述方法还包括：基于所述许可信息对订阅请求进行认证；
122.其中，所述维护订阅关系包括：基于通过认证的订阅请求，维护订阅关系。
123.其中，业务端300发送的订阅请求至少包括与业务端对应的许可信息、业务端标识和行情数据的类型。分发服务端200在接收到不同业务端300发送的订阅请求时，首先判断订阅请求中的许可信息是否包含通过认证的接入许可，若是，则将业务端标识及订阅的行情数据的类型记录并维护在订阅关系中。全部订阅请求经记录并维护订阅关系后，再经聚合处理，然后将聚合处理后的订阅请求发送至接入服务端100。
124.考虑传输的低延时要求，分发服务端200与接入服务端100、业务端300之间采用基于quic协议进行通信，通过quic连接传输数据。
125.一个可选实施例中，所述接收业务端发送的订阅请求包括：
126.基于与业务端之间的quic连接，接收所述业务端发送的订阅请求；
127.其中，所述将订阅请求发送至接入服务端包括：
128.基于与接入服务端之间的quic连接，将所述订阅请求发送至所述接入服务端；
129.其中，所述接收所述接入服务端返回的对应的标的行情数据并发送至所述业务端包括：
130.基于与所述接入服务端之间的quic连接，以及与所述业务端之间的quic连接，接收所述接入服务端返回的对应的标的行情数据并发送至所述业务端。
131.图3示出根据本技术又一个方面的一种行情数据处理的系统示意图，其中，一个实施例的系统包括：
132.业务端300，用于向分发服务端200发送订阅请求，以订阅标的行情数据，以及接收分发服务端200发送的对应的标的行情数据；
133.分发服务端200，用于接收业务端300发送的订阅请求并进行处理，将处理后的订阅请求发送至接入服务端100，以及接收接入服务端100返回的对应的标的行情数据并发送至业务端300；
134.接入服务端100，用于接收分发服务端200发送的订阅请求，并基于所述订阅请求，向行情数据源发起订阅，以获取行情源数据，再将所述行情源数据转换成对应的行情数据，以及根据所述行情数据中的标的代码，将所述行情数据进行hash分组，以获取标的行情数据，并将所述标的行情数据发送至分发服务端200。
135.在该实施例中，不同业务端300可以根据其业务需要或用户需求向分发服务端200发送针对全部类型或不同类型的行情数据的订阅请求，以订阅所述类型的标的行情数据。其中，行情数据可以包括不同证券交易所或第三方数据提供商提供的各种行情数据，例如：股票行情、股票期权行情、基金行情、债券行情等各种行情数据，行情数据的类型可以是快照、成交明细、报价信息、经济队列、实时分时走势图等。相应地，业务服务端300还接收分发服务端200发送的与上述订阅请求对应的标的行情数据。
136.继续在该实施例中，分发服务端200接收业务端300发送的订阅请求并进行处理，将处理后的订阅请求发送至接入服务端100，以及接收接入服务端100返回的对应的标的行情数据并发送至业务端300；其中，若订阅请求包含与业务端对应的业务端标识和/或许可信息，分发服务端200在接收到业务端300发送的订阅请求后，记录并维护订阅关系，其中，订阅关系包括业务端标识和订阅的行情数据的类型，并对订阅相同类型的不同业务端300发送的订阅请求进行聚合处理，接着将聚合处理后的订阅请求发送至接入服务端100；相应地，分发服务端200还接收接入服务端发送的与上述聚合处理后的订阅请求对应的标的行情数据，再根据记录并维护的订阅关系发送至相应的业务端300。
137.继续在该实施例中，接入服务端100接收分发服务端200发送的订阅请求，其中，若有多个获得接入许可的业务端发送订阅请求，多个订阅请求会在分发服务端200被记录及聚合处理后在发送给接入服务端100；接入服务端100根据收到的订阅请求，向相关行情数据源发起订阅，以获取行情源数据，其中，接入服务端100可以将订阅请求转换成符合相关行情数据源要求的格式后向相关行情数据源发起订阅；接入服务端100在收到行情数据源响应的行情源数据后，会将该行情源数据转换成对应的行情数据，以及根据该行情数据中的标的代码，将所述行情数据进行hash分组，其中，每个标的代码对应一组hash分组，采用多线程并行处理方式，每个标的代码的行情数据顺序送入同一线程处理，以获取标的行情数据，可增强处理效率，减小处理时延；并将所述标的行情数据发送至分发服务端200。
138.为了降低网络传输时延，一个如图4所示的可选实施例的系统示意图中，分发服务端200与接入服务端100、业务端300之间采用基于quic协议进行通信，通过quic连接传输数据。
139.一个可选实施例中，系统各相关部分功能可以采用谷歌golang语言开发，其中，golang语言是一种静态强类型、编译型、并发型，并具有垃圾回收功能的编程语言，可友好支持多线程多任务并发处理，降低行情数据hash分组及转发的时延。
140.在上述各可选实施例中，系统各相关部分采用的方法步骤与前述图1、图2和/或图3所示相关实施例中相同，在此不再赘述。
141.根据本技术的又一方面，还提供了一种计算机可读介质，所述计算机可读介质存
储有计算机可读指令，所述计算机可读指令可被处理器执行以实现前述方法。
142.需要注意的是，本技术中各方法实施例可在软件和/或软件与硬件的组合体中被实施。本技术中涉及的软件程序可以通过处理器执行以实现上述各实施例的步骤或功能。同样地，本技术的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中。
143.另外，本技术的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本技术的方法和/或技术方案。而调用本技术的方法的程序指令，可能被存储在固定的或可移动的记录介质中，和/或通过广播或其他信号承载媒体中的数据流而被传输，和/或被存储在根据所述程序指令运行的计算机设备的工作存储器中。
144.根据本技术的再一方面，还提供了一种行情数据处理的设备，该设备包括：存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发该设备运行基于前述根据本技术的多个实施例的方法和/或技术方案。
145.对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件和/或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。