数据分发框架的制作方法

本申请涉及物联网技术领域，具体而言，涉及一种数据分发框架。

背景技术：

中间件技术是当前物联网技术中的核心技术之一。目前大部分中间件的本质作用仅在于数据的透传及系统的解耦，无法进行一些数据的过滤。因而导致只能通过收到由中间件发送的数据的系统对该数据件过滤处理，由此将对业务处理效率产生影响。并且，目前利用中间件在进行业务解耦时，存在大量的相互调用，浪费了数据传输的时间，在一定程序上限制了数据传输、过滤及业务处理的效率。

技术实现要素：

为了克服现有技术中的上述不足，本申请实施例的目的在于提供一种数据分发框架，其能够在对待分发数据进行数据分发前，会进行过滤及分类，然后根据分类结果进行数据传递，由此可保证将数据传递给需要该数据的系统，实现业务的解耦，并避免仅通过后续系统对获得的该数据进行过滤处理而影响业务处理效率。

本申请实施例提供一种数据分发框架，包括连接的数据生产者、数据通道、数据消费者及数据接收者，

所述数据生产者，用于获得待分发数据，并将所述待分发数据经所述数据通道发送给所述数据消费者；

所述数据消费者，用于对接收的所述待分发数据进行过滤及分类，并将分类后的待分发数据传递给对应的数据接收者或下一层框架。

可选地，在本申请实施例中，所述数据消费者包括过滤器，

所述过滤器，由多个过滤单元以链式结构组成，用于根据存储的过滤条件对所述待分发数据进行多层次的过滤处理。

可选地，在本申请实施例中，所述数据消费者还包括分类器，

所述分类器，用于计算过滤后的每条待分发数据的hash值，并根据过滤后的每条待分发数据的hash值及分发策略对该条待分发数据进行分类。

可选地，在本申请实施例中，所述数据通道包括缓存单元，

所述缓存单元，用于缓存由所述数据生产者发送的所述待分发数据。

可选地，在本申请实施例中，所述数据通道还包括限流单元，

所述限流单元，用于获得所述缓存单元的容量信息，并根据所述容量信息判断是否进行限流，其中，所述容量信息包括剩余的可使用容量。

可选地，在本申请实施例中，还包括本地终端，所述本地终端包括监听器及控制单元，

所述监听器，用于获得所述数据通道的容量信息，并将所述容量信息发送给所述控制单元；

所述控制单元，用于根据所述容量信息判断是否向上一层框架中的监听器发送对本框架所在层进行横向扩容的扩容请求，以使上一层框架中的控制单元对本框架所在层进行横向扩容；

所述控制单元，还用于对下一层框架进行横向扩容。

可选地，在本申请实施例中，所述本地终端还包括本地存储单元，

所述本地存储单元，用于存储hash计算规则、分发策略及过滤后的待分发数据；

所述分类器，具体用于获取所述hash计算规则及分发策略，根据所述hash计算规则计算得到过滤后的每条待分发数据的hash值，并根据所述hash值从所述分发策略中得到该待分发数据的分类结果，以便根据所述分类结果对过滤后的待分发数据进行分发。

可选地，在本申请实施例中，所述数据接收者包括单向输出端组，所述数据生产者、单向输出端组及本地终端中均包括状态机，

所述状态机中存储有一组状态信息，用于根据存储的状态信息控制所在的数据生产者或单向输出端组或本地终端实现业务逻辑。

可选地，在本申请实施例中，所述监听器，还用于获得所述状态机的当前状态信息，并将所述当前状态信息发送给所述控制单元；

所述控制单元，还用于根据所述当前状态信息控制所述状态机所在的数据生产者、单向输出端组及本地终端建立连接或断开连接，以及，控制所述数据生产者和/或单向输出端组开启或关闭。

可选地，在本申请实施例中，所述数据通道为至少一个，所述数据消费者为至少一个，所述数据通道对应至少一个数据消费者，每个数据消费者中的过滤器中的过滤条件不同，以隔离不同业务数据。

相对于现有技术而言，本申请具有以下有益效果：

本申请实施例提供一种数据分发框架，包括数据生产者、数据通道、数据消费者及数据接收者。上述数据生产者用于获得待分发数据，并将所述待分发数据经所述数据通道发送给所述数据消费者。所述数据消费者用于对接收的所述待分发数据进行过滤及分类，并将分类后的待分发数据传递给对应的数据接收者或下一层框架。该数据分发框架在对待分发数据进行数据分发前，会进行过滤及分类，然后根据分类结果进行数据传递，由此可保证将数据传递给需要该数据的系统，实现业务的解耦，并避免仅通过后续系统对获得的该数据进行过滤处理而影响业务处理效率。

为使申请的上述目的、特征和优点能更明显易懂，下文特举本申请较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1是本申请实施例提供的数据分发系统的方框示意图。

图2是本申请实施例提供的数据分发框架的方框示意图之一。

图3是本申请实施例提供的数据分发框架的方框示意图之二。

图4是图3中的过滤器的方框示意图。

图5是本申请实施例提供的数据分发框架的方框示意图之三。

图6是本申请实施例提供的数据分发框架的方框示意图之四。

图7是图6中的状态机的状态信息示意图。

图8是本申请实施例提供的数据分发框架的应用场景示意图之一。

图9是本申请实施例提供的数据分发框架的应用场景示意图之二。

图标：10-数据分发系统；100-数据分发框架；101-状态机；110-数据生产者；120-数据通道；121-缓存单元；122-限流单元；130-数据消费者；131-过滤器；132-分类器；140-数据接收者；150-本地终端；151-监听器；152-控制单元；153-本地存储单元。

具体实施方式

下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

下面结合附图，对本申请的一些实施方式作详细说明。在不冲突的情况下，下述的实施例及实施例中的特征可以相互组合。

请参照图1，图1是本申请实施例提供的数据分发系统10的方框示意图。所述数据分发系统10可包括多个数据分发框架100，该数据分发系统10为多层结构。每层中的数据分发框架100在对获得数据进行过滤、分类后，可将最后得到的数据传递给下一层的数据分发框架100，以经下一层的数据分发框架100对其进行进一步处理，进而得到最终需要的数据。该方式既可以对数据完成所有处理，同时也可以避免每个数据分发框架100的任务量过大，影响数据传输速度。

或者，上一层中的数据分发框架100主要用于分发，下一层中的数据分发框架100主要用于对数据进行处理。由此，可避免所有数据都通过一个数据分发框架100进行处理，而导致该数据分发框架100的工作量过大，严重影响数据传递速度。比如，若该数据分发系统10包括三层，第一层中的数据分发框架100做第一次分发，第二层中的数据分发框架100做第二次分发，第三层中的数据分发框架100用于进行处理，以得到相应的处理后的数据。

请参照图2，图2是本申请实施例提供的数据分发框架100的方框示意图之一。所述数据分发框架100可以包括连接的数据生产者110、数据通道120、数据消费者130及数据接收者140。所述数据生产者110用于通过采集数据或接收其他系统发送的数据等方式获得待分发数据，并将所述待分发数据经所述数据通道120发送给所述数据消费者130。所述数据消费者130用于对接收到的待分发数据进行过滤及分类，并将分类后的待分发数据传递给对应的数据接收者140或下一层框架。

其中，下一层框架是指如图1所示的当前数据分发框架100所在层的下一层中的数据分发框架100，比如，第二层中的数据分发框架100a的下一层为第三层，与数据分发框架100a对应的下一层框架具体则为数据分发框架100b及数据分发框架100c。

上述数据分发框架100在对待分发数据进行数据分发前，会进行过滤及分类，然后根据分类结果进行数据传递，由此可保证将数据传递给需要该数据的系统，实现业务的解耦，并避免仅通过后续系统对获得的该数据进行过滤处理而影响业务处理效率。

请参照图3及图4，图3是本申请实施例提供的数据分发框架100的方框示意图之二，图4是图3中的过滤器131的方框示意图。在本实施例中，所述数据消费者130可以包括过滤器131。所述过滤器131由多个过滤单元以链式结构组成，用于根据存储的过滤条件对所述待分发数据进行多层的过滤处理。其中，上述过滤单元可以是业务过滤单元，也可以是逻辑过滤单元。不同的过滤单元中存储有不同的过滤条件，由此，在实际应用时，不需要根据实际需求经过一系列处理得到需要的过滤器，仅通过组合过滤单元即可得到一符合需求的过滤器131，该过滤器131中的过滤条件符合实际需求。

如图4所示，过滤器131中的第一个过滤单元接收到未过滤处理的数据(message)后，第一个过滤单元根据自身存储的过滤条件对其进行过滤处理，然后传递给下一个过滤单元；下一个过滤单元根据自身存储的过滤对由第一个过滤单元传递的数据进行过滤处理，再传递给下一个过滤单元……直到完成所有的过滤处理后得到数据(datamessage)，再依次返回，直至返回给第一个过滤单元，从第一个过滤单元得到经过所有过滤处理的数据(datamessage)。

请再次参照图3，所述数据消费者130还可以包括分类器132。所述分类器132用于计算过滤后的每条待分发数据的hash值，并根据过滤后的每条待分发数据的hash及获得的分发测量对该条待分发数据进行分类，然后按照分类将过滤后的该条待分发数据传递给对应的数据接收者140或下一层框架。由此，可保证将过滤处理后的待分发数据被传递给需要该数据的系统。

请再次参照图3，所述数据通道120可以包括缓存单元121，所述缓存单元121用于缓存由所述数据生产者110发送的所述待分发数据。

请再次参照图3，所述数据通道120还可以包括限流单元122。所述限流单元122用于获得所述缓存单元121的容量信息，并根据所述容量信息判断是否进行限流。其中，所述容量信息包括剩余的可使用容量。其中，具体判断是否进行限流的判断条件可以根据实际需求进行设置，比如，根据剩余的可使用容量的百分比、剩余的可使用容量的具体值、业务场景等。

下面对限流单元122如何判断是否进行限流进行具体说明。

在缓存单元121中可加入读标识、写标识。数据生产者110在向所述缓存单元121中写入数据后，可根据数据写入情况对写标识进行更新。数据消费者130在从所述缓存单元121中读出数据后，可根据数据读出情况对所述读标识进行更新。所述限流单元122用于获得上述读标识及写标识，在写标识减去所述读标识得到的差值大于预设的限流阈值时，即读标识远远小于写标识时，则判定需要进行限流。比如，缓存单元121的容量是存储100条数据，写标识为130条，读标识为40条，若预设的限流阈值为80条，则可以判定限流。

本领域技术人员应当理解，上述根据读标识及写标识判断是否进行限流仅为举例说明，这并不构成对本方案的限制。

请参照图5，图5是本申请实施例提供的数据分发框架100的方框示意图之三。所述数据分发框架100还包括本地终端150，所述本地终端150包括连接的监听器151及控制单元152。所述监听器151用于获得的所述数据通道120的容量信息，并将所述容量信息发送给所述控制单元152。所述控制单元152用于根据所述容量信息判断是否向上一层框架中的监听器151发送对本框架所在层进行横向扩容的扩容请求，以使上一层框架中的控制单元152对本框架所在层进行横向扩容。

如图1所示，假如在第二层中，数据分发框架100a中的控制单元152根据由监听器151获得的数据通道120的容量信息判定需要发送扩容请求，则向与第一层中与该数据分发框架100a对应的数据分发框架100发送扩容请求。在第一层中，与数据分发框架100a对应的数据分发框架100中的监听器151监听到该扩容请求后，将该扩容请求发送给控制单元152。所述控制单元152对相关连接设置进行修改，以增加第二层中与自身连接的数据分发框架100的数量，从而实现横向扩容，减小第二层中与自身连接的数据分发框架100a的任务量。

比如，第一层中的数据分发框架100原本与第二层中的三个数据分发框架100对应连接，若第二层中的数据分发框架100a发送扩容请求，表示第二层中的数据分发框架100a的任务量大。而经过扩容后，原本第一层中的数据分发框架100分发给第二层中的数据分发框架100a的数据，被分发给第二层中的数据分发框架100a及第二层中新增的数据分发框架100。

在本实施例中，所述控制单元152还用于对下一层框架进行横向扩容。即，如图1所示，若第三层中的数据分发框架100b向第二层中的数据分发框架100b发送扩容请求，第二层中的数据分发框架100a中的监听器151监听到该请求后，将其发送给控制单元152，使得第二层中的数据分发框架100a中的控制单元152对第三层进行横向扩容，以增加与第二层中的数据分发框架100a对应的数据分发框架100的数量。

当然可以理解的是，所述控制单元152还可以根据所述数据通道120的容量信息向上一层框架中的监听器151发送关闭本框架所在层中部分数据分发框架100的请求。所述控制单元152还用于关闭下一层框架中的部分数据分发框架100。比如，如图1所示，第三层中的数据分发框架100b中的控制单元152可向第二层中与其对应的数据分发框架100a发送关闭数据分发框架100的请求。数据分发框架100a中的控制单元152在接收到该请求后，则可以关闭数据分发框架100b或数据分发框架100c。

请再次参照图5，所述本地终端150还可以包括本地存储单元153。所述本地存储单元153用于存储hash计算规则、分发策略及过滤后的待分发数据。进一步地，本地存储单元153在存储过滤后的待分发数据时，也可以同时该数据对应的hash值，以便于后续查询。所述分类器132，具体用于获取所述hash计算规则及分发策略，根据所述hash计算规则计算得到过滤后的每条待分发数据的hash值，并根据所述hash值从所述分发策略中得到该待分发数据的分类结果，以便根据所述分类结果对过滤后的待分发数据进行分发。

可选地，所述分类器132与所述本地存储单元153连接，从所述本地存储单元153中获得hash计算规则、分发策略，然后根据hash计算规则计算经过滤处理后的每条待分发数据的hash值，然后从分发策略中获得与该hash值对应的分类结果，最后即可按照分类结果传递该条待分发数据。比如，假设分发策略包括hahs值及对应的发送地址，那么在计算得到一条过滤后的待分发数据的hash值后，可获得该hash值对应的发送地址，接着即可按照该发送地址发送该数据。

请参照图6，图6是本申请实施例提供的数据分发框架100的方框示意图之四。所述数据接收者140包括单向输出端组，所述数据生产者110、单向输出端组及本地终端150中均包括状态机101。所述状态机101中存储有一组状态信息，用于根据存储的状态信息控制所在的数据生产者110或单向输出端组或本地终端150实现业务逻辑。也就是说，所述状态机101用于控制所在的数据生产者110或单向输出端组或本地终端150的工作状态。由此可知，每个数据生产者110、单向输出端组、本地终端150内都封装实现了一组状态机101，并抽象出了每一状态的实现方法，用来实现自主的调用或业务逻辑。

请参照图7，图7是图6中的状态机101的状态信息示意图。该状态机101用于实现：connect(建立连接)、idle(长连接检测、及重连)、busy(存在待收发消息)、close(连接关闭)。由此，在连接状态，会执行重连动作。在连接成功时，若存在待分发消息(即待分发数据)，则分发待分发消息；若不存在待分发消息，或完成消息的分发后，则可关闭。

可选地，单向输出端组中可包括多个单向输出端，每个单向输出端中均包括状态机101。该单向输出端可以是，但不限于，数据库、服务器等。

在本实施例中，所述监听器151还用于获得所述状态机101的当前状态信息，并将所述当前状态信息发送给所述控制单元152。所述控制单元152还用于根据所述当前状态信息控制所述状态机101所在的数据生产者110、单向输出端组及本地终端150建立连接或断开连接，以及，控制所述数据生产者110和/或单向输出端组开启或关闭。

单向输出端、数据生产者110及本地终端150均包括connect接口及close接口。在所述当前状态信息为连接时，所述控制单元152通过调用connect接口及close接口即可使单向输出端或数据生产者110或本地终端150建立连接或断开连接。

可选地，所述控制单元152还用于在某些情况下控制所述数据生产者110、单向输出端或本地终端150建立连接或断开连接，以节省资源。比如，若所述数据生产者110或单向输出端与其他系统的连接一直失败，并一直重复建立连接的动作，在这种情况下，则可控制数据生产者110或单向输出端断开连接。若所述本地终端150断开连接，则该数据分发框架100不与其他系统连接。

可选地，所述控制单元152还可以在某些情况下开启或关闭所述数据生产者110和/或单向输出端。比如，若所述数据生产者110获取数据的速度过快，而数据消费者130处理数据的速度过慢，则可以关闭所述数据生产者110。对于单向输出端而言，比如，若所述数据生产者110已停止获取数据，而所述数据通道120内也无数据，则是则可以关闭单向输出端，避免单向输出端重复从所述数据消费者130获取数据的动作。当然可以理解的是，上述仅为距离说明，具体对应的应用场景可以根据实际需求设置。

在本实施例中，所述数据通道120为至少一个，所述数据消费者130为至少一个，所述数据通道120对应至少一个数据消费者130，每个数据消费者130中的过滤器131中的过滤条件不同，以隔离不同业务数据。其中，每个数据数据通道120用于存储同源数据，同源数据是指获取位置可能不同、但数据类型相同的数据。由此，上述设置即可实现对数据的过滤处理，同时可以保证对应的系统可以收到需要的数据。若双源的数据要在数据分发框架100内传输，则可搭建两个数据通道120，分别负责数据的上行及下行操作。

比如，若有一条业务a需要的数据，该数据被数据消费者1、2处理，其中，数据消费者1中的过滤器131中的过滤条件对应业务a。那么，虽然数据消费者1、2均会对该数据进行过滤处理，但是由于分类器132的分类作用，数据消费者2不会将过滤处理后的该数据发送给业务a对应的系统，与业务a对应的系统仅会接收到由数据消费者1传递的数据。

可选地，作为一种实施方式中，本地终端150为多个，多个本地终端150可共享一个监听器151。若因业务需要，也可以部分本地终端150共享一个监听器151。进一步地，也可以多个本地终端150共享一个控制单元152。

请参照图8，图8是本申请实施例提供的数据分发框架100的应用场景示意图之一。该应用场景为进行数据分发，mqtt服务器将订阅的消息进行分发存储，通过数据的hash值将数据hash到本地设备或其他设备或其他数据分发框架100处。图8中dataadapter表示数据分发框架100。由图8可知，与mqtt服务器连接的dataadapter用于数据分发，其他dataadapter用于数据存储。

请参照图9，图9是本申请实施例提供的数据分发框架100的应用场景示意图之二。在图9中，dataadapter(即数据分发框架100)对数据实施过滤后传送到目标。其中，图9中dataadapter处理的是kafka数据。dataadapter可以通过过滤算法分别对数据进行如下处理：每秒内的不同数据存入mysql；取消mysql查询，利用filter(即过滤器131)实时处理每10分钟数据，并将其整理成邮件分发给订阅的客户。

综上所述，本申请实施例提供一种数据分发框架，包括数据生产者、数据通道、数据消费者及数据接收者。上述数据生产者用于获得待分发数据，并将所述待分发数据经所述数据通道发送给所述数据消费者。所述数据消费者用于对接收的所述待分发数据进行过滤及分类，并将分类后的待分发数据传递给对应的数据接收者或下一层框架。该数据分发框架在对待分发数据进行数据分发前，会进行过滤及分类，然后根据分类结果进行数据传递，由此可保证将数据传递给需要该数据的系统，实现业务的解耦，并避免仅通过后续系统对获得的该数据进行过滤处理而影响业务处理效率。

进一步地，所述数据通道还可以用于存储由所述数据生产者110发送的待分发数据，并根据存储情况判断是否进行限流。

进一步地，所述数据分发框还可以包括本地终端，该本地终端用于存储hash计算规则、分发策略及过滤后的待分发数据，以便于数据消费者可基于该hash计算规则、分发策略计算待分发数据的hash值，并进行分发，并便于后续从本地终端处获得过滤后的数据。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。