行情数据下发方法、装置、系统、设备及介质与流程

1.本发明涉及互联网技术领域，尤其涉及一种行情数据下发方法、装置、系统、设备及介质。


背景技术：

2.在金融行情数据的传输过程中，由于行情数据量较大，对整个传输系统的可靠性、时延、正确性、带宽占用等都要求较高。
3.在网卡带宽一定的情况下，同一个服务端实时下发的带宽占用高，则意味着可以接入的客户端数量就少，服务端向单个客户端下发行情时的带宽占用越低，服务端可接入的客户端数目就越多。
4.针对上述情况，目前采用的降低带宽的方式是通用的压缩算法，并不能有效解决传输数据的大量重复问题。另外，行业内常用的压缩算法，即便能够解决重复问题，但算法本身较为复杂，难以理解，对一些数据类型的处理有一定限制，需要额外转换，并没有形成完整的解决方案。


技术实现要素：

5.鉴于以上内容，有必要提供一种行情数据下发方法、装置、系统、设备及介质，旨在解决行情数据下发过程中带宽占用的问题。
6.一种行情数据下发方法，应用于服务端，所述服务端与至少一个客户端相通信，所述行情数据下发方法包括：获取接收到的行情数据消息队列中的每条消息；确定每条消息对应的证券代码、数据类型及当前时间戳；根据所述证券代码、所述数据类型对每条消息进行格式转换，得到第一json包；从所述服务端的缓存中获取所述证券代码对应的全字段转换时间；计算所述全字段转换时间与所述当前时间戳的时间差；获取时间阈值，并对比所述时间差与所述时间阈值，得到对比结果；根据所述对比结果对每条消息进行交替的格式转换，得到第二json包；对于所述至少一个客户端中的每个客户端，检测是否向每个客户端全量发送过对应于所述证券代码及所述数据类型的消息，得到检测结果；根据所述检测结果从所述第一json包及所述第二json包中选择数据进行打包，得到打包数据，并将所述打包数据累加至对应的客户端的待下发数据中；当检测到有客户端的待下发数据的体积达到对应客户端的体积阈值时，对检测到的客户端的待下发数据进行压缩，得到压缩包；下发所述压缩包至所述检测到的客户端。
7.根据本发明优选实施例，所述根据所述对比结果对每条消息进行交替的格式转换，得到第二json包包括：
当所述对比结果为所述时间差大于所述时间阈值时，根据所述证券代码、所述数据类型将每条消息转换为json格式；或者当所述对比结果为所述时间差小于或者等于所述时间阈值时，根据所述证券代码、所述数据类型从所述服务端的缓存中获取与每条消息对应的数据字段，并识别每条消息与对应的数据字段间的差异字段，获取每条消息中与所述差异字段对应的字段作为目标字段，利用所述目标字段替换所述差异字段，得到替换后的每条消息，将所述替换后的每条消息转换为json格式。
8.根据本发明优选实施例，所述根据所述检测结果从所述第一json包及所述第二json包中选择数据进行打包包括：当所述检测结果为向每个客户端全量发送过对应于所述证券代码及所述数据类型的消息时，选择所述第二json包进行打包；或者当所述检测结果为没有向每个客户端全量发送过对应于所述证券代码及所述数据类型的消息时，选择所述第一json包进行打包。
9.一种行情数据下发方法，应用于至少一个客户端，所述至少一个客户端与服务端相通信，所述行情数据下发方法包括：当接收到所述服务端下发的压缩包时，对所述压缩包进行解压，得到每条消息；解析每条消息，得到每条消息对应的证券代码、数据类型、消息编号及增量标识；对于所述至少一个客户端中的每个客户端，从每个客户端的缓存中获取与每条消息对应的所述证券代码及所述数据类型的下发记录；当检测到有消息有所述下发记录时，将检测到的消息确定为目标消息，并确定所述目标消息的所述消息编号是否连续；当所述目标消息的所述消息编号连续时，根据所述目标消息的所述增量标识确定所述目标消息是否为增量json包，得到确定结果；根据所述确定结果对所述目标消息进行处理。
10.根据本发明优选实施例，所述方法还包括：对于没有检测到有所述下发记录的候选消息，根据所述候选消息的所述增量标识确定所述候选消息是否为所述增量json包，当确定所述候选消息为所述增量json包时，丢掉所述候选消息；或者当确定所述候选消息不为所述增量json包时，获取所述候选消息对应的客户端作为第一客户端，根据所述候选消息更新所述第一客户端的缓存，并将所述候选消息传输至所述第一客户端的应用程序；当所述目标消息的所述消息编号不连续时，根据所述目标消息的所述增量标识确定所述目标消息是否为所述增量json包，当确定所述目标消息为所述增量json包时，丢掉所述目标消息；或者当确定所述目标消息不为所述增量json包时，获取所述目标消息对应的客户端作为目标客户端，根据所述目标消息更新所述目标客户端的缓存，并将所述目标消息传输至所述目标客户端的应用程序。
11.根据本发明优选实施例，所述根据所述确定结果对所述目标消息进行处理包括：当所述确定结果为所述目标消息为所述增量json包时，解析所述目标消息，得到解析数据，根据所述解析数据更新所述目标客户端的缓存，并将所述解析数据传输至所述目标客户端的应用程序；或者
当所述确定结果为所述目标消息不为所述增量json包时，根据所述目标消息更新所述目标客户端的缓存，并将所述目标消息传输至所述目标客户端的应用程序。
12.一种行情数据下发装置，运行于服务端，所述服务端与至少一个客户端相通信，所述行情数据下发装置包括：获取单元，用于获取接收到的行情数据消息队列中的每条消息；确定单元，用于确定每条消息对应的证券代码、数据类型及当前时间戳；转换单元，用于根据所述证券代码、所述数据类型对每条消息进行格式转换，得到第一json包；所述获取单元，还用于从所述服务端的缓存中获取所述证券代码对应的全字段转换时间；计算单元，用于计算所述全字段转换时间与所述当前时间戳的时间差；对比单元，用于获取时间阈值，并对比所述时间差与所述时间阈值，得到对比结果；所述转换单元，还用于根据所述对比结果对每条消息进行交替的格式转换，得到第二json包；检测单元，用于对于所述至少一个客户端中的每个客户端，检测是否向每个客户端全量发送过对应于所述证券代码及所述数据类型的消息，得到检测结果；打包单元，用于根据所述检测结果从所述第一json包及所述第二json包中选择数据进行打包，得到打包数据，并将所述打包数据累加至对应的客户端的待下发数据中；压缩单元，用于当检测到有客户端的待下发数据的体积达到对应客户端的体积阈值时，对检测到的客户端的待下发数据进行压缩，得到压缩包；下发单元，用于下发所述压缩包至所述检测到的客户端。
13.一种行情数据下发系统，运行于至少一个客户端，所述至少一个客户端与服务端相通信，所述行情数据下发系统包括：解压模块，用于当接收到所述服务端下发的压缩包时，对所述压缩包进行解压，得到每条消息；解析模块，用于解析每条消息，得到每条消息对应的证券代码、数据类型、消息编号及增量标识；获取模块，用于对于所述至少一个客户端中的每个客户端，从每个客户端的缓存中获取与每条消息对应的所述证券代码及所述数据类型的下发记录；确定模块，用于当检测到有消息有所述下发记录时，将检测到的消息确定为目标消息，并确定所述目标消息的所述消息编号是否连续；所述确定模块，还用于当所述目标消息的所述消息编号连续时，根据所述目标消息的所述增量标识确定所述目标消息是否为增量json包，得到确定结果；处理模块，用于根据所述确定结果对所述目标消息进行处理。
14.一种计算机设备，所述计算机设备包括：存储器，存储至少一个指令；及处理器，执行所述存储器中存储的指令以实现所述行情数据下发方法。
15.一种计算机可读存储介质，所述计算机可读存储介质中存储有至少一个指令，所
述至少一个指令被计算机设备中的处理器执行以实现所述行情数据下发方法。
16.由以上技术方案可以看出，本发明利用json格式表示行情字段，简单易懂，在保证行情数据可靠传输的同时，通过时间策略与增量压缩及二次压缩算法的结合，有效降低了行情数据下发时对带宽的占用，增量压缩的方式也有效降低了行情数据下发时的时延。
附图说明
17.图1是本发明行情数据下发方法的较佳实施例的流程图。
18.图2是本发明行情数据下发方法的另一较佳实施例的流程图。
19.图3是本发明行情数据下发装置的较佳实施例的功能模块图。
20.图4是本发明行情数据下发系统的较佳实施例的功能模块图。
21.图5是本发明实现行情数据下发方法的较佳实施例的计算机设备的结构示意图。
具体实施方式
22.为了使本发明的目的、技术方案和优点更加清楚，下面结合附图和具体实施例对本发明进行详细描述。
23.如图1所示，是本发明行情数据下发方法的较佳实施例的流程图。根据不同的需求，该流程图中步骤的顺序可以改变，某些步骤可以省略。
24.所述行情数据下发方法应用于一个或者多个计算机设备中，所述计算机设备是一种能够按照事先设定或存储的指令，自动进行数值计算和/或信息处理的设备，其硬件包括但不限于微处理器、专用集成电路(application specific integrated circuit，asic)、可编程门阵列(field－programmable gate array，fpga)、数字处理器(digital signal processor，dsp)、嵌入式设备等。
25.所述计算机设备可以是任何一种可与用户进行人机交互的电子产品，例如，个人计算机、平板电脑、智能手机、个人数字助理（personal digital assistant，pda）、游戏机、交互式网络电视（internet protocol television，iptv）、智能式穿戴式设备等。
26.所述计算机设备还可以包括网络设备和/或用户设备。其中，所述网络设备包括，但不限于单个网络服务器、多个网络服务器组成的服务器组或基于云计算(cloud computing)的由大量主机或网络服务器构成的云。
27.所述服务器可以是独立的服务器，也可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(content delivery network，cdn)、以及大数据和人工智能平台等基础云计算服务的云服务器。
28.其中，人工智能（artificial intelligence，ai)是利用数字计算机或者数字计算机控制的机器模拟、延伸和扩展人的智能，感知环境、获取知识并使用知识获得最佳结果的理论、方法、技术及应用系统。人工智能基础技术一般包括如传感器、专用人工智能芯片、云计算、分布式存储、大数据处理技术、操作/交互系统、机电一体化等技术。人工智能软件技术主要包括计算机视觉技术、机器人技术、生物识别技术、语音处理技术、自然语言处理技术以及机器学习/深度学习等几大方向。
29.所述计算机设备所处的网络包括但不限于互联网、广域网、城域网、局域网、虚拟
专用网络（virtual private network，vpn）等。
30.在本实施例中，所述行情数据下发方法应用于服务端，所述服务端与至少一个客户端相通信，包括：s100，获取接收到的行情数据消息队列中的每条消息。
31.在本实施例中，所述行情数据消息队列用于存储金融行情数据对应的消息。
32.其中，所述行情数据消息队列中的消息可以为至少一条。
33.s101，确定每条消息对应的证券代码、数据类型及当前时间戳。
34.在本实施例中，所述证券代码是指每一只上市证券均拥有的代码，证券与代码一一对应，且证券的代码一旦确定，就不再改变。
35.在本实施例中，所述数据类型反映了行情数据的特点，例如，所述数据类型可以为5档位快照数据、现货快照等。
36.在本实施例中，所述当前时间戳是指当前的时间。
37.例如：当接收到所述行情数据消息队列的时间是上午9点时，所述当前时间戳为上午9点。
38.s102，根据所述证券代码、所述数据类型对每条消息进行格式转换，得到第一json（javascript object notation， js 对象简谱）包。
39.具体地，在进行格式转换时，可以获取预先配置的字段与序号间的映射关系，并根据所述映射关系将对应字段的英文字符替换为简单的序号，以实现字符的简化，进而减少下发的字节数，并降低带宽占用。
40.在本实施例中，json格式的数据简单易懂，因此，将下发的数据包统一为json格式，不仅提高了数据的规范性，同时也使行情数据的可读性更强。
41.s103，从所述服务端的缓存中获取所述证券代码对应的全字段转换时间。
42.在本发明的至少一个实施例中，所述全字段转换时间是指对应的数据被全量转换的时间。
43.s104，计算所述全字段转换时间与所述当前时间戳的时间差。
44.在本发明的至少一个实施例中，通过所述全字段转换时间与所述当前时间戳的时间差，能够反映出两次数据下发的时间差。
45.s105，获取时间阈值，并对比所述时间差与所述时间阈值，得到对比结果。
46.在本发明的至少一个实施例中，所述时间阈值可以进行自定义配置，如1分钟，本发明不限制。
47.可以理解的是，由于每次下发行情数据，都需要等待数据达到一定的体积，因此，当最后剩余的数据量较小，没有达到体积要求时，将影响这部分数据的正常下发。
48.因此，本实施例通过配置的时间阈值，检测在一定时间范围内是否还有数据下发，以便根据不同的情况及时响应。
49.s106，根据所述对比结果对每条消息进行交替的格式转换，得到第二json包。
50.在本发明的至少一个实施例中，所述根据所述对比结果对每条消息进行交替的格式转换，得到第二json包包括：当所述对比结果为所述时间差大于所述时间阈值时，根据所述证券代码、所述数据类型将每条消息转换为json格式；或者
当所述对比结果为所述时间差小于或者等于所述时间阈值时，根据所述证券代码、所述数据类型从所述服务端的缓存中获取与每条消息对应的数据字段，并识别每条消息与对应的数据字段间的差异字段，获取每条消息中与所述差异字段对应的字段作为目标字段，利用所述目标字段替换所述差异字段，得到替换后的每条消息，将所述替换后的每条消息转换为json格式。
51.例如：对于5档位快照数据的数据类型，如果第一个字段有变化，后面几个档位都不需要判断即可快速生成变化的json字符串，以新收到的消息字段替换原有的对应的差异字段，并将替换后的字段转换为json格式，得到所述第二json包。
52.在上述实施方式中，只要超过所述时间阈值，即可直接对当前收到的消息进行格式的转化，以等待下发，解决了由于体积不满足而影响数据下发的问题。
53.同时，当没有超过所述时间阈值时，则对当前收到的消息进行增量压缩及格式转换，有效降低了数据处理的时间，同时，由于增量压缩减小了数据的体积，进而降低了对带宽的占用。
54.s107，对于所述至少一个客户端中的每个客户端，检测是否向每个客户端全量发送过对应于所述证券代码及所述数据类型的消息，得到检测结果。
55.在本发明的至少一个实施例中，通过检测是否向每个客户端全量发送过对应于所述证券代码及所述数据类型的消息，便于后续根据检测结果进行针对性的响应。
56.s108，根据所述检测结果从所述第一json包及所述第二json包中选择数据进行打包，得到打包数据，并将所述打包数据累加至对应的客户端的待下发数据中。
57.需要说明的是，所述服务端需要定时下发每个证券代码每种行情类型的全量包，且需要对每个证券代码每种行情类型的消息进行顺序编号，而客户端异常后重连处理时，为了下游计算正确，客户端重连候需要发送完整json包，因此，需要根据检测结果进行进一步处理。
58.具体地，所述根据所述检测结果从所述第一json包及所述第二json包中选择数据进行打包包括：当所述检测结果为向每个客户端全量发送过对应于所述证券代码及所述数据类型的消息时，选择所述第二json包进行打包；或者当所述检测结果为没有向每个客户端全量发送过对应于所述证券代码及所述数据类型的消息时，选择所述第一json包进行打包。
59.可以理解的是，当已经全量发送过对应的消息时，则为了节约带宽，可以发送增量转换及压缩后得到的所述第二json包；而当没有全量发送过对应的消息时，则直接选择全量转换及压缩的所述第一json包，以保证数据传输的完整性。
60.在本实施例中，在将所述打包数据累加至对应的客户端的待下发数据中时，可以将所述打包数据累加到对应的客户端实例中。
61.s109，当检测到有客户端的待下发数据的体积达到对应客户端的体积阈值时，对检测到的客户端的待下发数据进行压缩，得到压缩包。
62.可以理解的是，一次压缩数据量过大，会导致内存堆积和下发频率降低，进而导致时延增加；而一次性压缩数据量过小，会导致压缩算法调用频繁，进而增加压缩处理时延，且压缩效率较低。因此需要找到恰当的阈值作为压缩条件，以达到平衡。
63.在本发明的至少一个实施例中，所述体积阈值可以结合专家经验及实际带宽进行配置。
64.例如：获取人为设定（json预留配置compresssize节点，单位为kb）的经验值，及获取每个客户端的实际带宽控制值，并取两者间较小者作为每个客户端的所述体积阈值，并进一步作为压缩条件。
65.在本发明的至少一个实施例中，可以采用任意压缩算法进行压缩，以实现对数据的二次压缩，进一步降低对带宽的占用。
66.例如：可以采用zstd压缩算法进行压缩。
67.s110，下发所述压缩包至所述检测到的客户端。
68.由以上技术方案可以看出，本发明能够利用json格式表示行情字段，简单易懂，在保证行情数据可靠传输的同时，通过时间策略与增量压缩及二次压缩算法的结合，有效降低了行情数据下发时对带宽的占用，增量压缩的方式也有效降低了行情数据下发时的时延。
69.如图2所示，是本发明行情数据下发方法的另一较佳实施例的流程图。根据不同的需求，该流程图中步骤的顺序可以改变，某些步骤可以省略。
70.在本实施例中，所述行情数据下发方法应用于至少一个客户端，所述至少一个客户端与服务端相通信，包括：s200，当接收到所述服务端下发的压缩包时，对所述压缩包进行解压，得到每条消息。
71.在本实施例中，可以采用与压缩算法对应的解压算法对所述压缩包进行解压，在此不赘述。
72.s201，解析每条消息，得到每条消息对应的证券代码、数据类型、消息编号及增量标识。
73.在本实施例中，所述消息编号为每条消息的序号，通过对每条消息进行顺序编号，能够更好的检测出是否有消息丢失。
74.在本实施例中，所述增量标识用于标记对应的消息是否是增量转换及压缩，以便根据不同的转换及压缩方式进行不同的响应。
75.s202，对于所述至少一个客户端中的每个客户端，从每个客户端的缓存中获取与每条消息对应的所述证券代码及所述数据类型的下发记录。
76.在本实施例中，通过所述下发记录，能够确定每条消息的下发时间，下发时的数据状态等信息。
77.s203，当检测到有消息有所述下发记录时，将检测到的消息确定为目标消息，并确定所述目标消息的所述消息编号是否连续。
78.在本实施例中，通过确定所述目标消息的所述消息编号是否连续，能够检测到消息在传输过程中是否有丢失。
79.s204，当所述目标消息的所述消息编号连续时，根据所述目标消息的所述增量标识确定所述目标消息是否为增量json（javascript object notation， js 对象简谱）包，得到确定结果。
80.在本实施例中，通过确定所述目标消息是否为增量json包，能够有针对性的进行
处理，保证消息的可靠传输。
81.s205，根据所述确定结果对所述目标消息进行处理。
82.在本发明的至少一个实施例中，所述方法还包括：对于没有检测到有所述下发记录的候选消息，根据所述候选消息的所述增量标识确定所述候选消息是否为所述增量json包，当确定所述候选消息为所述增量json包时，丢掉所述候选消息；或者当确定所述候选消息不为所述增量json包时，获取所述候选消息对应的客户端作为第一客户端，根据所述候选消息更新所述第一客户端的缓存，并将所述候选消息传输至所述第一客户端的应用程序；当所述目标消息的所述消息编号不连续时，根据所述目标消息的所述增量标识确定所述目标消息是否为所述增量json包，当确定所述目标消息为所述增量json包时，丢掉所述目标消息；或者当确定所述目标消息不为所述增量json包时，获取所述目标消息对应的客户端作为目标客户端，根据所述目标消息更新所述目标客户端的缓存，并将所述目标消息传输至所述目标客户端的应用程序。
83.可以理解的是，在行情数据下发的过程中，可以会发生丢包的异常情况。
84.针对上述异常，本实施例做了如下处理：（1）丢失首次接收的全量包时，后续接收到的增量json包直接丢弃，直到收到全量包；（2）检查消息编号的连续性，不连续表示有丢包情况，则丢弃接收到的对应证券代码对应行情数据类型的增量json包，直到接收到全量包为止。
85.通过上述实施方式，能够保证数据传输的完整性，避免由于丢包造成的数据错误。
86.在本发明的至少一个实施例中，所述根据所述确定结果对所述目标消息进行处理包括：当所述确定结果为所述目标消息为所述增量json包时，解析所述目标消息，得到解析数据，根据所述解析数据更新所述目标客户端的缓存，并将所述解析数据传输至所述目标客户端的应用程序；或者当所述确定结果为所述目标消息不为所述增量json包时，根据所述目标消息更新所述目标客户端的缓存，并将所述目标消息传输至所述目标客户端的应用程序。
87.通过上述实施方式，能够根据接收到的数据包的类型进行不同的处理，并在处理后更新数据在缓存中的状态，以供后续使用。
88.由以上技术方案可以看出，本发明能够利用json格式表示行情字段，简单易懂，在保证行情数据可靠传输的同时，通过时间策略与增量压缩及二次压缩算法的结合，有效降低了行情数据下发时对带宽的占用，增量压缩的方式也有效降低了行情数据下发时的时延。
89.如图3所示，是本发明行情数据下发装置的较佳实施例的功能模块图。所述行情数据下发装置11包括获取单元110、确定单元111、转换单元112、计算单元113、对比单元114、检测单元115、打包单元116、压缩单元117及下发单元118。本发明所称的模块/单元是指一种能够被处理器13所执行，并且能够完成固定功能的一系列计算机程序段，其存储在存储器12中。在本实施例中，关于各模块/单元的功能将在后续的实施例中详述。
90.在本实施例中，所述行情数据下发装置11运行于服务端，所述服务端与至少一个客户端相通信，包括：
获取单元110获取接收到的行情数据消息队列中的每条消息。
91.在本实施例中，所述行情数据消息队列用于存储金融行情数据对应的消息。
92.其中，所述行情数据消息队列中的消息可以为至少一条。
93.确定单元111确定每条消息对应的证券代码、数据类型及当前时间戳。
94.在本实施例中，所述证券代码是指每一只上市证券均拥有的代码，证券与代码一一对应，且证券的代码一旦确定，就不再改变。
95.在本实施例中，所述数据类型反映了行情数据的特点，例如，所述数据类型可以为5档位快照数据、现货快照等。
96.在本实施例中，所述当前时间戳是指当前的时间。
97.例如：当接收到所述行情数据消息队列的时间是上午9点时，所述当前时间戳为上午9点。
98.转换单元112根据所述证券代码、所述数据类型对每条消息进行格式转换，得到第一json（javascript object notation， js 对象简谱）包。
99.具体地，在进行格式转换时，可以获取预先配置的字段与序号间的映射关系，并根据所述映射关系将对应字段的英文字符替换为简单的序号，以实现字符的简化，进而减少下发的字节数，并降低带宽占用。
100.在本实施例中，json格式的数据简单易懂，因此，将下发的数据包统一为json格式，不仅提高了数据的规范性，同时也使行情数据的可读性更强。
101.所述获取单元110从所述服务端的缓存中获取所述证券代码对应的全字段转换时间。
102.在本发明的至少一个实施例中，所述全字段转换时间是指对应的数据被全量转换的时间。
103.计算单元113计算所述全字段转换时间与所述当前时间戳的时间差。
104.在本发明的至少一个实施例中，通过所述全字段转换时间与所述当前时间戳的时间差，能够反映出两次数据下发的时间差。
105.对比单元114获取时间阈值，并对比所述时间差与所述时间阈值，得到对比结果。
106.在本发明的至少一个实施例中，所述时间阈值可以进行自定义配置，如1分钟，本发明不限制。
107.可以理解的是，由于每次下发行情数据，都需要等待数据达到一定的体积，因此，当最后剩余的数据量较小，没有达到体积要求时，将影响这部分数据的正常下发。
108.因此，本实施例通过配置的时间阈值，检测在一定时间范围内是否还有数据下发，以便根据不同的情况及时响应。
109.所述转换单元112根据所述对比结果对每条消息进行交替的格式转换，得到第二json包。
110.在本发明的至少一个实施例中，所述转换单元112根据所述对比结果对每条消息进行交替的格式转换，得到第二json包包括：当所述对比结果为所述时间差大于所述时间阈值时，根据所述证券代码、所述数据类型将每条消息转换为json格式；或者当所述对比结果为所述时间差小于或者等于所述时间阈值时，根据所述证券代
码、所述数据类型从所述服务端的缓存中获取与每条消息对应的数据字段，并识别每条消息与对应的数据字段间的差异字段，获取每条消息中与所述差异字段对应的字段作为目标字段，利用所述目标字段替换所述差异字段，得到替换后的每条消息，将所述替换后的每条消息转换为json格式。
111.例如：对于5档位快照数据的数据类型，如果第一个字段有变化，后面几个档位都不需要判断即可快速生成变化的json字符串，以新收到的消息字段替换原有的对应的差异字段，并将替换后的字段转换为json格式，得到所述第二json包。
112.在上述实施方式中，只要超过所述时间阈值，即可直接对当前收到的消息进行格式的转化，以等待下发，解决了由于体积不满足而影响数据下发的问题。
113.同时，当没有超过所述时间阈值时，则对当前收到的消息进行增量压缩及格式转换，有效降低了数据处理的时间，同时，由于增量压缩减小了数据的体积，进而降低了对带宽的占用。
114.检测单元115对于所述至少一个客户端中的每个客户端，检测是否向每个客户端全量发送过对应于所述证券代码及所述数据类型的消息，得到检测结果。
115.在本发明的至少一个实施例中，通过检测是否向每个客户端全量发送过对应于所述证券代码及所述数据类型的消息，便于后续根据检测结果进行针对性的响应。
116.打包单元116根据所述检测结果从所述第一json包及所述第二json包中选择数据进行打包，得到打包数据，并将所述打包数据累加至对应的客户端的待下发数据中。
117.需要说明的是，所述服务端需要定时下发每个证券代码每种行情类型的全量包，且需要对每个证券代码每种行情类型的消息进行顺序编号，而客户端异常后重连处理时，为了下游计算正确，客户端重连候需要发送完整json包，因此，需要根据检测结果进行进一步处理。
118.具体地，所述打包单元116根据所述检测结果从所述第一json包及所述第二json包中选择数据进行打包包括：当所述检测结果为向每个客户端全量发送过对应于所述证券代码及所述数据类型的消息时，选择所述第二json包进行打包；或者当所述检测结果为没有向每个客户端全量发送过对应于所述证券代码及所述数据类型的消息时，选择所述第一json包进行打包。
119.可以理解的是，当已经全量发送过对应的消息时，则为了节约带宽，可以发送增量转换及压缩后得到的所述第二json包；而当没有全量发送过对应的消息时，则直接选择全量转换及压缩的所述第一json包，以保证数据传输的完整性。
120.在本实施例中，在将所述打包数据累加至对应的客户端的待下发数据中时，可以将所述打包数据累加到对应的客户端实例中。
121.当检测到有客户端的待下发数据的体积达到对应客户端的体积阈值时，压缩单元117对检测到的客户端的待下发数据进行压缩，得到压缩包。
122.可以理解的是，一次压缩数据量过大，会导致内存堆积和下发频率降低，进而导致时延增加；而一次性压缩数据量过小，会导致压缩算法调用频繁，进而增加压缩处理时延，且压缩效率较低。因此需要找到恰当的阈值作为压缩条件，以达到平衡。
123.在本发明的至少一个实施例中，所述体积阈值可以结合专家经验及实际带宽进行
配置。
124.例如：获取人为设定（json预留配置compresssize节点，单位为kb）的经验值，及获取每个客户端的实际带宽控制值，并取两者间较小者作为每个客户端的所述体积阈值，并进一步作为压缩条件。
125.在本发明的至少一个实施例中，可以采用任意压缩算法进行压缩，以实现对数据的二次压缩，进一步降低对带宽的占用。
126.例如：可以采用zstd压缩算法进行压缩。
127.下发单元118下发所述压缩包至所述检测到的客户端。
128.由以上技术方案可以看出，本发明能够利用json格式表示行情字段，简单易懂，在保证行情数据可靠传输的同时，通过时间策略与增量压缩及二次压缩算法的结合，有效降低了行情数据下发时对带宽的占用，增量压缩的方式也有效降低了行情数据下发时的时延。
129.如图4所示，是本发明行情数据下发系统的较佳实施例的功能模块图。所述行情数据下发系统22包括解压模块220、解析模块221、获取模块222、确定模块223、处理模块224。本发明所称的模块/单元是指一种能够被处理器13所执行，并且能够完成固定功能的一系列计算机程序段，其存储在存储器12中。在本实施例中，关于各模块/单元的功能将在后续的实施例中详述。
130.在本实施例中，所述行情数据下发系统22运行于至少一个客户端，所述至少一个客户端与服务端相通信，包括：当接收到所述服务端下发的压缩包时，解压模块220对所述压缩包进行解压，得到每条消息。
131.在本实施例中，可以采用与压缩算法对应的解压算法对所述压缩包进行解压，在此不赘述。
132.解析模块221解析每条消息，得到每条消息对应的证券代码、数据类型、消息编号及增量标识。
133.在本实施例中，所述消息编号为每条消息的序号，通过对每条消息进行顺序编号，能够更好的检测出是否有消息丢失。
134.在本实施例中，所述增量标识用于标记对应的消息是否是增量转换及压缩，以便根据不同的转换及压缩方式进行不同的响应。
135.对于所述至少一个客户端中的每个客户端，获取模块222从每个客户端的缓存中获取与每条消息对应的所述证券代码及所述数据类型的下发记录。
136.在本实施例中，通过所述下发记录，能够确定每条消息的下发时间，下发时的数据状态等信息。
137.当检测到有消息有所述下发记录时，确定模块223将检测到的消息确定为目标消息，并确定所述目标消息的所述消息编号是否连续。
138.在本实施例中，通过确定所述目标消息的所述消息编号是否连续，能够检测到消息在传输过程中是否有丢失。
139.当所述目标消息的所述消息编号连续时，所述确定模块223根据所述目标消息的所述增量标识确定所述目标消息是否为增量json（javascript object notation， js 对
象简谱）包，得到确定结果。
140.在本实施例中，通过确定所述目标消息是否为增量json包，能够有针对性的进行处理，保证消息的可靠传输。
141.处理模块224根据所述确定结果对所述目标消息进行处理。
142.在本发明的至少一个实施例中，对于没有检测到有所述下发记录的候选消息，根据所述候选消息的所述增量标识确定所述候选消息是否为所述增量json包，当确定所述候选消息为所述增量json包时，丢掉所述候选消息；或者当确定所述候选消息不为所述增量json包时，获取所述候选消息对应的客户端作为第一客户端，根据所述候选消息更新所述第一客户端的缓存，并将所述候选消息传输至所述第一客户端的应用程序；当所述目标消息的所述消息编号不连续时，根据所述目标消息的所述增量标识确定所述目标消息是否为所述增量json包，当确定所述目标消息为所述增量json包时，丢掉所述目标消息；或者当确定所述目标消息不为所述增量json包时，获取所述目标消息对应的客户端作为目标客户端，根据所述目标消息更新所述目标客户端的缓存，并将所述目标消息传输至所述目标客户端的应用程序。
143.可以理解的是，在行情数据下发的过程中，可以会发生丢包的异常情况。
144.针对上述异常，本实施例做了如下处理：（1）丢失首次接收的全量包时，后续接收到的增量json包直接丢弃，直到收到全量包；（2）检查消息编号的连续性，不连续表示有丢包情况，则丢弃接收到的对应证券代码对应行情数据类型的增量json包，直到接收到全量包为止。
145.通过上述实施方式，能够保证数据传输的完整性，避免由于丢包造成的数据错误。
146.在本发明的至少一个实施例中，所述处理模块224根据所述确定结果对所述目标消息进行处理包括：当所述确定结果为所述目标消息为所述增量json包时，解析所述目标消息，得到解析数据，根据所述解析数据更新所述目标客户端的缓存，并将所述解析数据传输至所述目标客户端的应用程序；或者当所述确定结果为所述目标消息不为所述增量json包时，根据所述目标消息更新所述目标客户端的缓存，并将所述目标消息传输至所述目标客户端的应用程序。
147.通过上述实施方式，能够根据接收到的数据包的类型进行不同的处理，并在处理后更新数据在缓存中的状态，以供后续使用。
148.由以上技术方案可以看出，本发明能够利用json格式表示行情字段，简单易懂，在保证行情数据可靠传输的同时，通过时间策略与增量压缩及二次压缩算法的结合，有效降低了行情数据下发时对带宽的占用，增量压缩的方式也有效降低了行情数据下发时的时延。
149.如图5所示，是本发明实现行情数据下发方法的较佳实施例的计算机设备的结构示意图。
150.所述计算机设备1可以包括存储器12、处理器13和总线，还可以包括存储在所述存储器12中并可在所述处理器13上运行的计算机程序，例如行情数据下发程序。
151.本领域技术人员可以理解，所述示意图仅仅是计算机设备1的示例，并不构成对计算机设备1的限定，所述计算机设备1既可以是总线型结构，也可以是星形结构，所述计算机
设备1还可以包括比图示更多或更少的其他硬件或者软件，或者不同的部件布置，例如所述计算机设备1还可以包括输入输出设备、网络接入设备等。
152.需要说明的是，所述计算机设备1仅为举例，其他现有的或今后可能出现的电子产品如可适应于本发明，也应包含在本发明的保护范围以内，并以引用方式包含于此。
153.其中，存储器12至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、移动硬盘、多媒体卡、卡型存储器（例如：sd或dx存储器等）、磁性存储器、磁盘、光盘等。存储器12在一些实施例中可以是计算机设备1的内部存储单元，例如该计算机设备1的移动硬盘。存储器12在另一些实施例中也可以是计算机设备1的外部存储设备，例如计算机设备1上配备的插接式移动硬盘、智能存储卡（smart media card，smc）、安全数字（secure digital，sd）卡、闪存卡（flash card）等。进一步地，存储器12还可以既包括计算机设备1的内部存储单元也包括外部存储设备。存储器12不仅可以用于存储安装于计算机设备1的应用软件及各类数据，例如行情数据下发程序的代码等，还可以用于暂时地存储已经输出或者将要输出的数据。
154.处理器13在一些实施例中可以由集成电路组成，例如可以由单个封装的集成电路所组成，也可以是由多个相同功能或不同功能封装的集成电路所组成，包括一个或者多个中央处理器（central processing unit，cpu）、微处理器、数字处理芯片、图形处理器及各种控制芯片的组合等。处理器13是所述计算机设备1的控制核心（control unit），利用各种接口和线路连接整个计算机设备1的各个部件，通过运行或执行存储在所述存储器12内的程序或者模块（例如执行行情数据下发程序等），以及调用存储在所述存储器12内的数据，以执行计算机设备1的各种功能和处理数据。
155.所述处理器13执行所述计算机设备1的操作系统以及安装的各类应用程序。所述处理器13执行所述应用程序以实现上述各个行情数据下发方法实施例中的步骤，例如图1所示的步骤。
156.示例性的，所述计算机程序可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器12中，并由所述处理器13执行，以完成本发明。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机可读指令段，该指令段用于描述所述计算机程序在所述计算机设备1中的执行过程。例如，所述计算机程序可以被分割成获取单元110、确定单元111、转换单元112、计算单元113、对比单元114、检测单元115、打包单元116、压缩单元117及下发单元118，及/或解压模块220、解析模块221、获取模块222、确定模块223、处理模块224。
157.上述以软件功能模块的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机、计算机设备，或者网络设备等）或处理器（processor）执行本发明各个实施例所述行情数据下发方法的部分。
158.所述计算机设备1集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指示相关的硬件设备来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。
159.其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、u盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器（rom，read-only memory）、随机存取存储器等。
160.进一步地，计算机可读存储介质可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据区块链节点的使用所创建的数据等。
161.本发明所指区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性（防伪）和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层等。
162.总线可以是外设部件互连标准（peripheral component interconnect，简称pci）总线或扩展工业标准结构（extended industry standard architecture，简称eisa）总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示，在图5中仅用一根直线表示，但并不表示仅有一根总线或一种类型的总线。所述总线被设置为实现所述存储器12以及至少一个处理器13等之间的连接通信。
163.尽管未示出，所述计算机设备1还可以包括给各个部件供电的电源（比如电池），优选地，电源可以通过电源管理装置与所述至少一个处理器13逻辑相连，从而通过电源管理装置实现充电管理、放电管理、以及功耗管理等功能。电源还可以包括一个或一个以上的直流或交流电源、再充电装置、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。所述计算机设备1还可以包括多种传感器、蓝牙模块、wi-fi模块等，在此不再赘述。
164.进一步地，所述计算机设备1还可以包括网络接口，可选地，所述网络接口可以包括有线接口和/或无线接口（如wi-fi接口、蓝牙接口等），通常用于在该计算机设备1与其他计算机设备之间建立通信连接。
165.可选地，该计算机设备1还可以包括用户接口，用户接口可以是显示器（display）、输入单元（比如键盘（keyboard）），可选地，用户接口还可以是标准的有线接口、无线接口。可选地，在一些实施例中，显示器可以是led显示器、液晶显示器、触控式液晶显示器以及oled（organic light-emitting diode，有机发光二极管）触摸器等。其中，显示器也可以适当的称为显示屏或显示单元，用于显示在计算机设备1中处理的信息以及用于显示可视化的用户界面。
166.应该了解，所述实施例仅为说明之用，在专利申请范围上并不受此结构的限制。
167.图5仅示出了具有组件12-13的计算机设备1，本领域技术人员可以理解的是，图5示出的结构并不构成对所述计算机设备1的限定，可以包括比图示更少或者更多的部件，或者组合某些部件，或者不同的部件布置。
168.结合图1，所述计算机设备1中的所述存储器12存储多个指令以实现一种行情数据下发方法，所述处理器13可执行所述多个指令从而实现：获取接收到的行情数据消息队列中的每条消息；
确定每条消息对应的证券代码、数据类型及当前时间戳；根据所述证券代码、所述数据类型对每条消息进行格式转换，得到第一json包；从所述服务端的缓存中获取所述证券代码对应的全字段转换时间；计算所述全字段转换时间与所述当前时间戳的时间差；获取时间阈值，并对比所述时间差与所述时间阈值，得到对比结果；根据所述对比结果对每条消息进行交替的格式转换，得到第二json包；对于所述至少一个客户端中的每个客户端，检测是否向每个客户端全量发送过对应于所述证券代码及所述数据类型的消息，得到检测结果；根据所述检测结果从所述第一json包及所述第二json包中选择数据进行打包，得到打包数据，并将所述打包数据累加至对应的客户端的待下发数据中；当检测到有客户端的待下发数据的体积达到对应客户端的体积阈值时，对检测到的客户端的待下发数据进行压缩，得到压缩包；下发所述压缩包至所述检测到的客户端。
169.结合图2，所述计算机设备1中的所述存储器12存储多个指令以实现一种物联网设备安全接入方法，所述处理器13可执行所述多个指令从而实现：当接收到所述服务端下发的压缩包时，对所述压缩包进行解压，得到每条消息；解析每条消息，得到每条消息对应的证券代码、数据类型、消息编号及增量标识；对于所述至少一个客户端中的每个客户端，从每个客户端的缓存中获取与每条消息对应的所述证券代码及所述数据类型的下发记录；当检测到有消息有所述下发记录时，将检测到的消息确定为目标消息，并确定所述目标消息的所述消息编号是否连续；当所述目标消息的所述消息编号连续时，根据所述目标消息的所述增量标识确定所述目标消息是否为增量json包，得到确定结果；根据所述确定结果对所述目标消息进行处理。
170.具体地，所述处理器13对上述指令的具体实现方法可参考图1-2对应实施例中相关步骤的描述，在此不赘述。
171.需要说明的是，本案中所涉及到的数据均为合法取得。
172.在本发明所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
173.本发明可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络pc、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。本发明可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本发明，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
174.所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显
示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。
175.另外，在本发明各个实施例中的各功能模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能模块的形式实现。
176.对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。
177.因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本发明内。不应将权利要求中的任何附关联图标记视为限制所涉及的权利要求。
178.此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。本发明中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一、第二等词语用来表示名称，而并不表示任何特定的顺序。
179.最后应说明的是，以上实施例仅用以说明本发明的技术方案而非限制，尽管参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明的技术方案进行修改或等同替换，而不脱离本发明技术方案的精神和范围。