CN117879687A - 数据处理方法、电子设备及可读存储介质 - Google Patents

Abstract

本申请公开了一种数据处理方法、电子设备及可读存储介质，包括：在服务实例接收对应分配的信道所传输的数据帧时，基于预设队列对接收到的数据帧的序号的连续性进行检测，获得检测结果；所述预设队列用于对接收到的数据帧按序号进行排序；根据所述检测结果执行对应的预设处理。如此，通过预设队列对接收到的数据帧的序号的连续性进行检测，并检测结果执行对应的预设处理，提高了卫星通信时数据处理效率和质量。

Description

数据处理方法、电子设备及可读存储介质

技术领域

本发明涉及卫星通信技术领域，特别是涉及一种数据处理方法、电子设备及可读存储介质。

背景技术

卫星数据传输链路会经过星上处理、地面站处理、测运控中心处理、数据中心处理，传输过程中会出现误码、帧乱序、丢帧、跳帧等异常情况，在此基础上，需要按照信道区分和帧的实际顺序对数据进行解码，以得到正确的数据包。

使用卫星网络进行通信时，其成功率很难达到100％，故而地面段在对卫星下发的数据进行处理时，不仅需要正确处理正常情况的数据，还需要对异常情况进行甄别，并对解码模块进行动态调整，避免进一步造成正常数据的解码失败。其中，一般使用消息队列中间件来处理需要排队处理的消息，但常用的Kafka或RocketMq所维护的顺序是消息生产者将消息放入队列的顺序，因此，现有方式无法解决卫星网络数据下发所产生的帧乱序、丢帧、跳帧等问题，影响卫星通信时数据处理效率和质量。

发明内容

本申请的目的在于提供一种数据处理方法、电子设备及可读存储介质，通过预设队列对接收到的数据帧的序号的连续性进行检测，并检测结果执行对应的预设处理，提高了卫星通信时数据处理效率和质量。

为达到上述目的：

第一方面，本申请实施例提供了一种数据处理方法，所述方法包括：

在服务实例接收对应分配的信道所传输的数据帧时，基于预设队列对接收到的数据帧的序号的连续性进行检测，获得检测结果；所述预设队列用于对接收到的数据帧按序号进行排序；

根据所述检测结果执行对应的预设处理。

在一实施方式中，所述基于预设队列对接收到的数据帧的序号的连续性进行检测，获得检测结果，包括：

基于预设队列，获取接收到的当前数据帧的序号与前一数据帧的序号之间的差值；

根据所述差值检测是否出现丢帧或跳帧，获得对应的检测结果。

在一实施方式中，所述根据所述检测结果执行对应的预设处理，包括以下至少一种：

根据所述检测结果确定出现丢帧时，控制所述服务实例进入预设第一等待状态，以对丢失的数据帧等待预设时长；

根据所述检测结果确定出现跳帧时，控制所述服务实例进入预设第二等待状态，直至接收到丢失的数据帧。

在一实施方式中，所述控制所述服务实例进入预设第一等待状态，以对丢失的数据帧等待预设时长，包括：

在控制所述服务实例对丢失的数据帧进行等待后，获取消费者按照预设时间间隔对所述预设队列进行丢失的数据帧轮询失败次数；所述消费者用于轮询获取数据帧并进行处理；

检测到所述消费者对丢失的数据帧轮询失败次数大于或等于预设次数时，控制所述服务实例跳过所述丢失的数据帧，并记录所述丢失的数据帧的序号；所述预设次数是基于所述预设时长和所述预设时间间隔所确定的。

在一实施方式中，所述方法还包括：

响应于服务实例状态发生变更，对存活的服务实例与所有信道之间进行重新分配，并向各所述存活的服务实例广播分配结果。

在一实施方式中，所述方法还包括：

所述分配结果包括各所述存活的服务实例对应分配的信道，以及对各所述信道已处理到的数据帧的序号。

在一实施方式中，所述响应于服务实例状态发生变更，对存活的服务实例与所有信道之间进行重新分配，并向各所述存活的服务实例广播分配结果之前，还包括：

对所述服务实例接收到的对应分配的信道所传输的数据帧进行异步存储；

周期性上报所述服务实例已处理到的数据帧的序号。

第二方面，本申请实施例提供一种电子设备，包括：处理器和存储有计算机程序的存储器，在所述处理器运行所述计算机程序时，实现上述第一方面所述的数据处理方法的步骤。

第三方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，所述计算机程序被处理器执行时实现上述第一方面所述的数据处理方法的步骤。

本申请实施例提供的数据处理方法、电子设备及可读存储介质，所述方法包括：在服务实例接收对应分配的信道所传输的数据帧时，基于预设队列对接收到的数据帧的序号的连续性进行检测，获得检测结果；所述预设队列用于对接收到的数据帧按序号进行排序；根据所述检测结果执行对应的预设处理。如此，通过预设队列对接收到的数据帧的序号的连续性进行检测，并检测结果执行对应的预设处理，提高了卫星通信时数据处理效率和质量。

附图说明

图1为本发明实施例提供的数据处理方法的流程示意图；

图2为本发明实施例中数据分流的示意图；

图3为本发明实施例中信道与服务实例分配的示意图；

图4为本发明实施例中数据处理过程示意图一；

图5为本发明实施例中数据处理过程示意图二；

图6为本发明实施例中服务状态协调及广播机制的实现过程示意图；

图7为本发明实施例提供的电子设备的结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素，此外，本申请不同实施例中具有同样命名的部件、特征、要素可能具有相同含义，也可能具有不同含义，其具体含义需以其在该具体实施例中的解释或者进一步结合该具体实施例中上下文进行确定。

应当理解，尽管在本文可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本文范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语"如果"可以被解释成为"在……时"或"当……时"或"响应于确定"。再者，如同在本文中所使用的，单数形式“一”、“一个”和“该”旨在也包括复数形式，除非上下文中有相反的指示。应当进一步理解，术语“包含”、“包括”表明存在所述的特征、步骤、操作、元件、组件、项目、种类、和/或组，但不排除一个或多个其他特征、步骤、操作、元件、组件、项目、种类、和/或组的存在、出现或添加。此处使用的术语“或”和“和/或”被解释为包括性的，或意味着任一个或任何组合。因此，“A、B或C”或者“A、B和/或C”意味着“以下任一个：A；B；C；A和B；A和C；B和C；A、B和C”。仅当元件、功能、步骤或操作的组合在某些方式下内在地互相排斥时，才会出现该定义的例外。

应该理解的是，虽然本申请实施例中的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

需要说明的是，在本文中，采用了诸如S101、S102等步骤代号，其目的是为了更清楚简要地表述相应内容，不构成顺序上的实质性限制，本领域技术人员在具体实施时，可能会先执行S102后执行S101等，但这些均应在本申请的保护范围之内。

应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或者“单元”的后缀仅为了有利于本申请的说明，其本身没有特定的意义。因此，“模块”、“部件”或者“单元”可以混合地使用。

参阅图1，为本申请实施例提供的一种数据处理方法，该数据处理方法可以由本申请实施例提供的一种数据处理装置来执行，该数据处理装置可以采用软件和/或硬件的方式来实现，具体可以为位于数据中心的电子设备等。本实施例提供的数据处理方法包括：

步骤S101、在服务实例接收对应分配的信道所传输的数据帧时，基于预设队列对接收到的数据帧的序号的连续性进行检测，获得检测结果；预设队列用于对接收到的数据帧按序号进行排序。

可以理解，一个卫星可能通过多个信道向数据中心下发数据帧，而数据中心可配置有多个服务实例(即后台服务)，数据中心通过对服务实例与信道之间进行分配，使同一个信道的数据帧分流至同一个服务实例。需要说明的是，多个信道可分配至同一个服务实例。这里，服务实例接收对应分配的信道所传输的数据帧，可以是服务实例接收地面测控系统发送的信道所传输的数据帧。可以理解，数据中心与地面测控系统可采用TCP方式进行连接，地面测控系统负责收集卫星下发的所有数据帧并发给数据中心，数据中心接收到数据帧后，基于服务实例与信道之间的分配关系对数据帧进行分流，即将不同信道的数据帧分流至对应的服务实例。

其中，对于每个运行中的服务实例，其接收到的数据帧可能存在乱序、丢帧或跳帧等问题，因此，本申请实施例中通过预设队列对接收到的数据帧进行预处理，具体地，可通过预设队列对接收到的数据帧按照序号进行排序，以供消费者从预设队列中可依次读取数据帧进行处理，即消费者可从预设队列获得有序的数据帧。这里，每个服务实例可对应一个预设队列，预设队列可以是预设优先级连续队列或Kafka消息队列等，预设优先级连续队列是在优先级队列的基础上进行扩展获得的。此外，消费者可以理解为服务实例下的线程，用于对数据帧进行解码，同时数据帧的序号可包含在数据帧的帧头信息中。

在一实施方式中，基于预设队列对接收到的数据帧的序号的连续性进行检测，获得检测结果，包括：

基于预设队列，获取接收到的当前数据帧的序号与前一数据帧的序号之间的差值；

根据差值检测是否出现丢帧或跳帧，获得对应的检测结果。

具体地，基于预设队列中存储的接收到的当前数据帧和前一数据帧的序号，获取接收到的当前数据帧的序号与前一数据帧的序号之间的差值，并根据差值检测是否出现丢帧或跳帧，获得对应的检测结果。

其中，丢帧是指接收到的当前数据帧与前一数据帧之间还存在未接收到的数据帧，且未接收到的数据帧的数量通常较少，比如一帧、三帧等。跳帧是指接收到的当前数据帧与前一数据帧之间还存在未接收到的数据帧，且未接收到的数据帧的数量通常较多。以序号以自然数进行表示为例，在差值为1时，此时说明不存在丢帧和跳帧；在差值大于1且小于预设阈值时，此时说明存在丢帧；在差值大于预设阈值时，说明存在跳帧。其中，预设阈值可以根据实际情况需要进行设置，比如可以设置为3帧、5帧、10帧等，在此不作具体限定。需要说明的是，跳帧可能是由于数据帧传输过程中存在误码等原因引起的，比如，原本序号为100的数据帧，误码后的序号可能变为199等。如此，可实现快速且准确检测接收到的数据帧是否出现丢帧或跳帧问题，进一步提高了数据处理效率。

步骤S102、根据检测结果执行对应的预设处理。

其中，根据检测结果执行对应的预设处理，包括以下至少一种：

根据检测结果确定出现丢帧时，控制服务实例进入预设第一等待状态，以对丢失的数据帧等待预设时长；

根据检测结果确定出现跳帧时，控制服务实例进入预设第二等待状态，直至接收到丢失的数据帧。

这里，根据检测结果确定出现丢帧时，说明此时丢失的数据帧可能只是暂未收到，因此，可控制服务实例进入预设第一等待状态，以对丢失的数据帧等待预设时长，若超过预设时长仍未接收到丢失的数据帧，则说明可能不会接收到丢失的数据帧。而根据检测结果确定出现跳帧时，说明此时序号位于接收到的当前数据帧与前一数据帧号之间的数据帧(即丢失的数据帧)应该只是还未发送下来，因此，可控制服务实例进入预设第二等待状态，直至接收到丢失的数据帧。需要说明的是，在预设第二等待状态下，不限制对应的等待时长。如此，根据检测结果的不同执行不同的预设处理，以尽量确保数据帧的有序，进一步提高了卫星通信时数据处理效率和质量。

在一实施方式中，控制服务实例进入预设第一等待状态，以对丢失的数据帧等待预设时长，包括：

在控制所述服务实例对丢失的数据帧进行等待后，获取消费者按照预设时间间隔对预设队列进行丢失的数据帧轮询失败次数；消费者用于轮询获取数据帧并进行处理；

检测到消费者对丢失的数据帧轮询失败次数大于或等于预设次数时，控制服务实例跳过丢失的数据帧，并记录丢失的数据帧的序号；预设次数是基于预设时长和预设时间间隔所确定的。

具体地，在控制所述服务实例对丢失的数据帧进行等待后，可通过服务实例获取消费者按照预设时间间隔对预设队列进行丢失的数据帧轮询失败次数，当检测到消费者对丢失的数据帧轮询失败次数大于或等于预设次数时，控制服务实例跳过丢失的数据帧，并记录丢失的数据帧的序号；当检测到消费者对丢失的数据帧轮询失败次数小于预设次数时，继续通过服务实例获取消费者按照预设时间间隔对预设队列进行丢失的数据帧轮询的结果。

这里，由于无论预设队列是否有数据，消费者总是会按预设时间间隔对预设队列进行轮询，并且会记录当前处理到的数据帧的序号。同时，如果消费者轮询失败返回数据为空集合，表示当前序号的数据帧尚未到达或丢帧，则消费者会记录该序号的等待次数，即对该序号的数据帧轮询失败次数。此外，基于预设时长和预设时间间隔可确定预设次数，即基于预设时间间隔，可确定在预设时长内对丢失的数据帧轮询失败的最大次数，即预设次数。例如，若预设时间间隔为1秒，而预设时长为10秒，则预设次数可以设为10次。因此，可通过检测消费者对丢失的数据帧轮询失败次数，实现检测对丢失的数据帧的等待时长。例如，若预设时间间隔为1秒，则检测到消费者当前对丢失的数据帧轮询失败次数为5次时，说明服务实例已对丢失的数据帧等待了5秒。

需要说明的是，在检测到消费者对丢失的数据帧轮询失败次数大于或等于预设次数，即检测到服务实例对丢失的数据帧的等待时长达到预设时长时，说明可能不会再接收到丢失的数据帧，则控制服务实例跳过丢失的数据帧，并记录丢失的数据帧的序号，以继续接收对应分配的信道所传输的数据帧。如此，直接通过检测消费者对丢失的数据帧轮询失败次数，来确定对丢失的数据帧的等待时长是否达到预设时长，而不需要通过另起线程来处理等待时间的定时机制，降低了计算资源消耗，提高了数据处理灵活性。

综上，上述实施例提供的数据处理方法中，通过预设队列对接收到的数据帧的序号的连续性进行检测，并检测结果执行对应的预设处理，提高了卫星通信时数据处理效率和质量。

在一实施方式中，所述方法还包括：

响应于服务实例状态发生变更，对存活的服务实例与所有信道之间进行重新分配，并向各存活的服务实例广播分配结果。

其中，服务实例状态发生变更可包括服务实例由存活状态变为失活状态、服务实例数量增加或减少等。例如，若服务实例在运行过程出现宕机等现象，可能导致状态由存活状态变为失活状态，或者，若新增了服务实例，则服务实例数量相应增加等。在服务实例状态发生变更时，为了将信道均匀的分配到各个服务实例上，可对存活的服务实例与所有信道之间进行重新分配，并向各存活的服务实例广播分配结果，以使存活的服务实例根据分配结果重新加载分配的信道对应的数据帧，并重建预设队列。这里，可以设置一个作为主协调者的服务实例，其它服务实例作为从协调者，以由作为主协调者的服务实例对存活的服务实例与所有信道之间进行重新分配，并向作为从协调者的各存活的服务实例广播分配结果。其中，分配结果可包括各存活的服务实例对应分配的信道，以及对各信道已处理到的数据帧的序号。这里，各服务实例可对应设置有身份标识，而各信道也可对应设置有身份标识，通过建立的服务实例的身份标识与信道的身份标识之间的绑定关系，可以获知服务实例对应分配的信道。同时，对各信道已处理到的数据帧的序号，可以基于各服务实例周期性上报的已处理到的数据帧的序号进行获知。此外，在服务实例的状态是基于Redis桶进行分配时，Redis桶的数量即为服务实例的数量，每个Redis桶都会记录对应的服务实例的身份标识和对应分配的信道，此时分配结果可包括各存活的服务实例注册到的Redis桶。如此，在服务实例状态发生变更时，对存活的服务实例与所有信道之间进行重新分配，以将信道均匀的分配到各个服务实例上，进一步提高了数据处理效率。

在一实施方式中，响应于服务实例状态发生变更，对存活的服务实例与所有信道之间进行重新分配，并向各存活的服务实例广播分配结果，包括：

按照预设周期从服务注册与发现中间件中获取已注册的至少一服务实例；

对已注册的至少一服务实例进行状态检查，确定存活的服务实例；

将所有信道分配给存活的服务实例，并向存活的服务实例广播分配结果。

可以理解，服务注册与发现中间件可存储有服务实例列表，且该服务实例列表包括已注册的至少一服务实例，虽然服务注册与发现中间件能够排除部分宕机的已注册的服务实例，但是，服务注册与发现中间件无法检测出服务实例列表中已注册的服务实例是否真正存活，因此，在按照预设周期从服务注册与发现中间件中获取已注册的至少一服务实例后，需要对已注册的至少一服务实例进行状态检查，以从已注册的至少一服务实例中确定存活的服务实例，并将所有信道分配给存活的服务实例，以及向存活的服务实例广播分配结果，实现服务实例与信道的重新分配。

在一实施方式中，响应于服务实例状态发生变更，对存活的服务实例与所有信道之间进行重新分配，并向各所述存活的服务实例广播分配结果之前，还包括：

对服务实例接收到的对应分配的信道所传输的数据帧进行异步存储；和/或，周期性上报服务实例已处理到的数据帧的序号。

可以理解，为了避免服务实例重启后，该服务实例接收到的数据帧未完全存储，导致该服务实例或其它服务实例重新加载的数据不完整，需要对服务实例接收到的对应分配的信道所传输的数据帧进行异步存储，比如将数据帧异步存入MySQL、Elasticsearch等数据库等。此外，还可周期性上报服务实例已处理到的数据帧的序号，从而便于在服务实例与信道之间进行重新分配后，可继续对未处理的数据帧进行处理。这里，服务实例在获得分配结果后，可根据分配结果加载重新分配的信道对应的未处理数据帧，并重新构建预设队列。如此，通过异步存储服务实例接收到的数据帧和/或周期性上报服务实例已处理到的数据帧的序号，保证在对服务实例与信道之间进行重新分配后，能够继续对未处理的数据帧进行处理，同时不影响服务实例的正常运行，进一步提高了数据处理效率。

基于前述实施例相同的发明构思，下面通过一具体示例对前述实施例进行详细说明，本示例中以所述预设队列为优先级连续队列为例进行说明。

上合星座是适用于中低速通信场景的全球卫星通信系统，基于卫星网络的端到端通信需要通过地面数据中心进行转发，在数据从卫星到地面数据中心的过程中，通信时机取决于卫星对地面站的覆盖情况，卫星每次见站都会将此前收到的终端上行数据进行下发，由于卫星与地面站可通信时长的限制，往往是数分钟内下发大量数据到数据中心，并且卫星下发的数据并非逐条下发，而是在星上载荷对数据包按照固定大小和时间进行切割，切割的结果即为数据帧，帧的大小不超过886字节。卫星按照数据帧进行下发，每一个数据帧可能包含多包(即多条用户消息)或半包的情况，同时数据的下发会经由多个信道进行，对数据帧的切割是在各个信道中进行，信道之间不会互相影响。

卫星数据传输链路会经过星上处理、地面站处理、测运控中心处理、数据中心处理，传输过程中可能会出现误码、帧乱序、丢帧、跳帧等异常情况，在此基础上，需要按照信道区分和帧的实际顺序对数据进行解码，以得到正确的数据包。因此，使用卫星网络进行通信，其成功率很难达到100％，故而地面段在对卫星下发的数据进行处理时，不仅需要正确处理正常情况的数据，还需要对异常情况进行甄别，并对解码模块进行动态调整，避免进一步造成正常数据的解码失败。

传统的处理方式可以选择Kafka等消息队列中间件，或内存优先级队列，但中间件一般无法处理消息的排序，无等待机制，而内存优先级队列虽然解决了排序问题，但并非连续消费，如中间有序号的丢失，普通优先级队列并无法检测出来。软件工程中一般使用消息队列中间件来处理需要排队处理的消息，但常用的Kafka或RocketMq所维护的顺序是消息生产者将消息放入队列的顺序，因此，无法解决卫星网络数据下发所产生的帧乱序、丢帧、跳帧等问题。并且，因为卫星按照信道下发数据，信道之间不会互相影响，所以一个分布式的消息中间件对于卫星网络通信来说过于重量级，而一个基于本机的轻量级本地消息队列足以按照信道处理卫星下行数据。

通常情况下，处理卫星下行数据有以下问题需要解决：1)帧乱序，数据经由卫星下发，经过地面站和测控中心处理转发后，其帧序并非原始帧序；2)丢帧，如果发生丢帧，则排序队列不能无限等待以免造成阻塞；3)跳帧，多由误码引起，即帧序号值发生变化，会导致队列跳过一大段序号，造成大量帧被忽略的后果；4)负责数据处理的服务实例无法灵活横向扩展；5)队列的重建问题，由于卫星频繁的过境离境，数据中心的每个服务实例总是会有数据帧在等待下次卫星过境下发数据以便拼成完整数据，在使用内存队列的情况下，每次重启服务实例都要重建上次未处理结束的数据，而一般情况下只有一个找不到包尾的数据帧。

针对上述问题，本示例提供了一种适用于卫星网络的数据处理方法，通过按照信道对数据进行有状态的分配，解决了卫星下发的数据在地面段处理过程中无法灵活扩展服务实例、以及误码和丢帧造成的数据错乱问题。

本示例中，卫星下发的数据通过地面段的TCP连接发给数据中心后，数据中心首先基于信道对数据进行分流，目的是将同一个信道的数据分流到同一个服务实例上，同时异步存储数据，以在待服务实例发生再分配时，可重新加载未处理完的数据。

本示例中，数据中心与地面测控系统采用TCP方式进行连接，测控系统负责收集卫星下发的所有数据并发给数据中心，数据中心收到数据后会基于本示例中提供的服务状态协调及广播机制对数据进行分流，如图2所示。

首先，对数据处理的服务实例是有状态的，状态基于Redis桶进行分配，桶的数量即服务实例的数量，每个桶都会记录对应的服务实例ID和信道。每个服务实例都扮演了状态协调者的角色，但通过一个分布式锁进行了互斥，实际同时只有一个服务实例作为主协调者存在。主协调者负责从服务注册发现中间件实时获取运行的服务实例，并检测服务实例与Redis桶的关系，新增服务实例会增加一个桶，并将当前所有信道进行重新分配，服务实例基于自己所分配的信道加载已有的数据，运行中的服务实例基于重新分配的信道剔除不属于自己的数据，如图3所示。这里，删除服务实例会造成桶的减少，并触发同样的信道再分配逻辑。极端情况下所有信道都在一个服务实例或每个服务实例负责一个信道。

特别的，服务实例的减少可能是因为宕机或其他意外导致的异常，所以本示例中支持对服务实例进行健康检测以确定服务实例是否存活。另外，信道的再分配会触发广播机制，广播默认基于Redis的PubSub机制。

参阅图4，对于每个运行中的服务实例，收到的数据可能是乱序、丢帧、跳帧的，本示例提供了一个优先级连续队列来对数据进行预处理，使得队列的消费者得到的就是有序的数据，从而可以正确的对数据流进行解码，解决数据传输过程中必然出现的拆包、粘包等问题。

首先，在优先级连续队列中会对数据按照序号进行排序，可以获得初步的有序数据。其次，对于临时丢帧，即数据暂时未收到，队列提供了等待机制，等待期间不会继续提供数据给队列的消费者，直到所等待的数据到来。对于永久丢帧，为了避免数据无限等待，以10秒为超时时间，此时间可以根据具体的业务场景进行配置，通常是一个经验值，并且因为丢帧通常是连续发生的，所以10秒的超时时间是针对连续的丢帧而言，如某一时段丢了序号为100至104共5个帧，超时时间到达之后会一次性跳过，而非等待50秒。对于跳帧问题，通常由误码引起，如原本序号为100的帧，误码后序号变为199，造成序号为100到199之间的帧都进入临时等待状态，优先级连续队列通过记录队列的当前消费序号和最大序号来解决，如果当前消费序号等于最大序号，则进入永久等待状态，即没有新数据的正常状态，但如果当前消费序号与最大序号的差值较大，也强制进入永久等待状态，而非临时等待状态。注意永久等待跟临时等待的区别在于永久等待不会超时，使得尚未到达的数据不会错过。同时，对于同一个序号的数据，后来的会覆盖先来的，所以一般情况下序号为199的误码数据会被真正的序号为199的数据覆盖，而原本序号为100的数据会在10秒后跳过。

参阅图5，首先对于优先级连续队列，队列消息的序号既是排序的依据，又是数据的唯一键值，所以可以使用哈希结构维护队列的底层数据，如Java语言中的TreeMap，键值就是序号。队列的消费者可能会被强制处于等待状态，但等待机制通过阻塞来实现不是很灵活，且逻辑上出错概率更大，所以可以将消费与等待功能进行合并，即由消费者驱动队列的等待，具体的实现方式是：无论是否有数据，消费者总是会按固定间隔(如1秒)对队列进行轮询，并且消费者会记录当前处理到的序号，每次轮询返回的数据量可以进行配置，如1秒能够处理500条，则每次轮询最大返回500条，以避免因为轮询间隔设置不合理造成的吞吐量下降。

如果消费者轮询失败返回数据为空集合，则表示当前序号对应的数据尚未到达(或者丢帧)，消费者会记录该序号的等待次数，若等待次数超过10次，即超时时间超过了10秒，则消费者自动将序号加1，并记录这个被跳过的序号。该消费方式参照了Kafka消费者的poll机制，不需要依赖比较底层wait和notify同步机制，也不需要通过另起线程来处理超时时间的定时机制，其灵活性和程序健壮性都能得到极大的保障。

其次，参阅图6，对于服务状态协调及广播机制，服务状态协调功能由数据处理的服务实例、服务注册与发现中间件、Redis共同完成，服务实例作为服务协调者，同时只有一个服务实例作为主协调者，可通过基于Redis的分布式锁达到互斥的目的。主协调者协调的结果是修改了各个服务实例的状态，状态包括服务实例注册到某个Redis桶、服务实例所处理的信道、每个信道已处理到的数据帧的序号。此外，服务状态的变更通过分布式消息通知实现，因为本实施例已经依赖了Redis，所以可通过Redis的发布订阅机制实现。

最后，对于异步分布式缓存机制，首先要保障性能，以避免数据处理的服务实例重启之后，数据还没有完全存储，导致服务实例重建的队列数据不全，所以可以使用Redis做临时存储以辅助队列的重建，同时异步存入Mysql、Elasticsearch等服务数据库进行永久存储以满足审计备份等需求。

综上，上述实施例提供的数据处理方法的创新点在于：1)采用优先级连续队列：针对帧乱序、丢帧、跳帧问题，首先使用优先级连续队列对帧按序号进行整合，并对延迟到达的帧提供灵活的等待机制，按照信道将帧进行分组，一个信道的数据由一个服务器实例进行处理。2)服务状态协调及广播机制：针对数据处理服务实例的横向扩展问题，在一个信道的数据由一个服务实例处理的原则上，需要为服务实例分配一个状态，且服务实例重启之后依旧能加载到之前的状态，服务实例新增和删除都需要触发所有服务状态的重新分配，目的是将信道均匀的分配到各个服务实例上。3)异步分布式缓存机制：针对队列重启需要重建的问题，所有数据帧都应该进行存储，但如果同步存储会严重降低数据处理的性能，所以采用异步且独立的缓存服务，即不阻塞主服务运行，又不受主服务重启的影响，避免数据丢失。因此，上述实施例提供的数据处理方法具有以下优点：1)相比较于传统的Kafka等消息队列中间件，本示例所提供的技术方案是轻量级的，在单机上就可运行，同时可以基于信道数进行横向扩展，也能够按照指定的关键词(如信道)将数据路由到一个固定的消费者。2)相比较与传统的优先级队列，本示例支持基于数据帧序号的有序且连续消费，能够检测序号的丢失并提供一定的等待机制，同时为了避免消息的无限等待，提供了超时跳过机制。3)支持灵活的配置消息的存储方案，可以选择纯内存方式和数据库、redis等方式进行存储。

基于前述实施例相同的发明构思，本发明实施例提供了一种电子设备，如图7所示，该电子设备包括：处理器310和存储有计算机程序的存储器311；其中，图7中示意的处理器310并非用于指代处理器310的个数为一个，而是仅用于指代处理器310相对其他器件的位置关系，在实际应用中，处理器310的个数可以为一个或多个；同样，图7中示意的存储器311也是同样的含义，即仅用于指代存储器311相对其他器件的位置关系，在实际应用中，存储器311的个数可以为一个或多个。在所述处理器310运行所述计算机程序时，实现上述数据处理方法。

该电子设备还可包括：至少一个网络接口312。该电子设备中的各个组件通过总线系统313耦合在一起。可理解，总线系统313用于实现这些组件之间的连接通信。总线系统313除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图7中将各种总线都标为总线系统313。

其中，存储器311可以是易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(ROM，Read Only Memory)、可编程只读存储器(PROM，Programmable Read-Only Memory)、可擦除可编程只读存储器(EPROM，Erasable Programmable Read-Only Memory)、电可擦除可编程只读存储器(EEPROM，Electrically Erasable Programmable Read-Only Memory)、磁性随机存取存储器(FRAM，ferromagnetic random access memory)、快闪存储器(Flash Memory)、磁表面存储器、光盘、或只读光盘(CD-ROM，Compact Disc Read-Only Memory)；磁表面存储器可以是磁盘存储器或磁带存储器。易失性存储器可以是随机存取存储器(RAM，Random AccessMemory)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(SRAM，Static Random Access Memory)、同步静态随机存取存储器(SSRAM，Synchronous Static Random Access Memory)、动态随机存取存储器(DRAM，Dynamic Random Access Memory)、同步动态随机存取存储器(SDRAM，SynchronousDynamic Random Access Memory)、双倍数据速率同步动态随机存取存储器(DDRSDRAM，Double Data Rate Synchronous Dynamic Random Access Memory)、增强型同步动态随机存取存储器(ESDRAM，Enhanced Synchronous Dynamic Random Access Memory)、同步连接动态随机存取存储器(SLDRAM，SyncLink Dynamic Random Access Memory)、直接内存总线随机存取存储器(DRRAM，Direct Rambus Random Access Memory)。本发明实施例描述的存储器311旨在包括但不限于这些和任意其它适合类型的存储器。

本发明实施例中的存储器311用于存储各种类型的数据以支持该电子设备的操作。这些数据的示例包括：用于在该电子设备上操作的任何计算机程序，如操作系统和应用程序。

基于前述实施例相同的发明构思，本实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，计算机可读存储介质可以是磁性随机存取存储器(FRAM，ferromagnetic random access memory)、只读存储器(ROM，Read OnlyMemory)、可编程只读存储器(PROM，Programmable Read-Only Memory)、可擦除可编程只读存储器(EPROM，Erasable Programmable Read-Only Memory)、电可擦除可编程只读存储器(EEPROM，Electrically Erasable Programmable Read-Only Memory)、快闪存储器(FlashMemory)、磁表面存储器、光盘、或只读光盘(CD-ROM，Compact Disc Read-Only Memory)等存储器；也可以是包括上述存储器之一或任意组合的各种设备，如移动电话、计算机、平板设备、个人数字助理等。所述计算机可读存储介质中存储的计算机程序被处理器运行时，实现上述数据处理方法。所述计算机程序被处理器执行时实现的具体步骤流程请参考图1所示实施例的描述，在此不再赘述。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，除了包含所列的那些要素，而且还可包含没有明确列出的其他要素。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种数据处理方法，其特征在于，所述方法包括：

在服务实例接收对应分配的信道所传输的数据帧时，基于预设队列对接收到的数据帧的序号的连续性进行检测，获得检测结果；所述预设队列用于对接收到的数据帧按序号进行排序；

根据所述检测结果执行对应的预设处理。

2.根据权利要求1所述的方法，其特征在于，所述基于预设队列对接收到的数据帧的序号的连续性进行检测，获得检测结果，包括：

基于预设队列，获取接收到的当前数据帧的序号与前一数据帧的序号之间的差值；

根据所述差值检测是否出现丢帧或跳帧，获得对应的检测结果。

3.根据权利要求2所述的方法，其特征在于，所述根据所述检测结果执行对应的预设处理，包括以下至少一种：

根据所述检测结果确定出现丢帧时，控制所述服务实例进入预设第一等待状态，以对丢失的数据帧等待预设时长；

根据所述检测结果确定出现跳帧时，控制所述服务实例进入预设第二等待状态，直至接收到丢失的数据帧。

4.根据权利要求3所述的方法，其特征在于，所述控制所述服务实例进入预设第一等待状态，以对丢失的数据帧等待预设时长，包括：

在控制所述服务实例对丢失的数据帧进行等待后，获取消费者按照预设时间间隔对所述预设队列进行丢失的数据帧轮询失败次数；所述消费者用于轮询获取数据帧并进行处理；

检测到所述消费者对丢失的数据帧轮询失败次数大于或等于预设次数时，控制所述服务实例跳过所述丢失的数据帧，并记录所述丢失的数据帧的序号；所述预设次数是基于所述预设时长和所述预设时间间隔所确定的。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

响应于服务实例状态发生变更，对存活的服务实例与所有信道之间进行重新分配，并向各所述存活的服务实例广播分配结果。

6.根据权利要求5所述的方法，其特征在于，所述响应于服务实例状态发生变更，对存活的服务实例与所有信道之间进行重新分配，并向各所述存活的服务实例广播分配结果，包括：

按照预设周期从服务注册与发现中间件中获取已注册的至少一服务实例；

对所述已注册的至少一服务实例进行状态检查，确定存活的服务实例；

将所有信道重新分配给所述存活的服务实例，并向所述存活的服务实例广播分配结果。

7.根据权利要求5或6所述的方法，其特征在于，所述分配结果包括各所述存活的服务实例对应分配的信道，以及对各所述信道已处理到的数据帧的序号。

8.根据权利要求7所述的方法，其特征在于，所述响应于服务实例状态发生变更，对存活的服务实例与所有信道之间进行重新分配，并向各所述存活的服务实例广播分配结果之前，还包括：

对所述服务实例接收到的对应分配的信道所传输的数据帧进行异步存储；和/或，

周期性上报所述服务实例已处理到的数据帧的序号。

9.一种电子设备，其特征在于，包括：处理器和存储有计算机程序的存储器，在所述处理器运行所述计算机程序时，实现权利要求1至8中任一项所述的数据处理方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1至8中所述的数据处理方法的步骤。