CN111831458A - 一种高并发高解耦数据处理方法及数据中台系统 - Google Patents

Abstract

本发明公开了一种高并发高解耦数据处理方法及数据中台系统，涉及数据中台领域，包括：Ngnix服务器接收打包数据并分发给Publisher实例，Publisher实例根据业务类型将打包数据分发给消息队列，Consumer实例从消息队列获取打包数据并根据业务类型进行处理得到处理结果，Consumer实例将处理结果保存至本地数据库，本地数据库按照业务维度提供本地端口，并在公网提供相应的映射端口。本发明的有益效果：实现数据中台系统的高并发高解耦和低费用，架构清晰，易于扩展。

Description

一种高并发高解耦数据处理方法及数据中台系统

技术领域

本发明数据中台技术领域，具体涉及一种高并发高解耦数据处理方法及数据中台系统。

背景技术

中台是最早由阿里在2015年提出的“大中台，小前台”战略中延伸出来的概念，关于数据中台的整体定义，也随着头部企业落地数据种而组件清晰，数据中台是指通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。知名数据分析机构Canalys2019年2月的相关数据报告，2018年全球云计算市场规模突破800亿美元，达到804亿美元；未来10-15年，“数据中台”也许会超越今天的云计算市场，形成一个万亿级市场。

数据中台的“中”本身就是相对的，没有绝对的标准，需求的粒度也是不尽相同。它不是一个平台，也不是一个系统，更像是一种数据流处理的架构，灵活性非常大，所以即使拿到其他企业的中台源代码也不能立即上手复用到自己的企业应用当中。目前虽然有少数大厂已经提供了数据中台服务，可以解决大部分数据中台的架构设计问题，但是并不一定可以满足企业的需求，企业构建属于自己的一套具有高度灵活性的定制化数据中台解决方案是有必要性的，当然也是可行的，同时可以避免被大厂的服务所捆绑。

目前大部分的企业存在“业务生成数据，数据驱动业务”的这种需求，所以在数据中台的解决方案上存在较多问题，概括起来有下面几点：

(1)数据处理缺乏统一标准，与具体业务耦合，灵活性差，如何统一口径、标准和高时效性。

(2)架构边界定义不明确，对数据上报和数据处理不分离，存在歧义，扩展比较难。

(3)云服务器租赁费用较高，数据存储成本大，后期的迁移受限，被数据中台解决方案提供商强行绑定。

发明内容

针对现有技术中存在的缺陷，本发明提供一种低费用的高并发高解耦数据处理方法及数据中台系统。

为达到以上目的，采取的技术方案是：

一种高并发高解耦数据处理方法，包括：

数据入栈过程，通过Ngnix服务器接收打包数据并分发给多个Publisher实例，Publisher实例根据打包数据的业务类型将其分发给多个消息队列；

数据出栈过程，通过Consumer实例从多个消息队列获取打包数据，并对其进行处理得到处理结果，将处理结果存入本地数据库，本地数据库对处理结果进行分类得到对应不同业务维度的最终数据，每个业务维度的最终数据均通过唯一的本地端口和映射端口输出。

优选的，数据处理方法还包括配置过程：

配置本地数据库的预设分类策略，预设分类策略为根据多个业务维度对数据进行分类；

配置本地数据库，本地数据库包括多个本地端口，在公网上配置有与每个本地端口对应的映射端口。

优选的，配置过程还包括配置预设数量的数据来源端及对应的上报权限，配置上报权限包括：

数据来源端向数据中台系统申请appId、appKey、以及向数据中台系统上报打包数据时的原始URL；

数据中台系统保存所有数据来源端的appId、appKey、以及原始URL，以在数据来源端向数据中台系统上报打包数据时对其进行验证，在验证通过时接收打包数据，在验证失败时反馈错误代码。

优选的，所述数据处理方法还包括：

数据打包过程，通过数据来源端获取原始数据，根据原始数据的数据属性生成业务类型，根据原始数据的业务类型和数据内容生成打包数据，根据appId、appKey、原始URL、以及时间戳生成最终URL后，通过HTTP POST请求方式将打包数据上传至关联于最终URL的Publisher实例；

数据使用过程，从映射端口获取最终数据进行数据应用。

优选的，打包数据包括第一类型数据和第二类型数据，第一类型数据的数据量小于第二类型数据；

第一类型数据包括JSON类型数据；

第二类型数据包括文件类型数据。

优选的，打包数据为第一类型数据时，Publisher实例接收打包数据后，将打包数据解析后得到的数据属性和数据内容作为相关信息存储至相应的消息队列；

打包数据为第二类型数据时，Publisher实例接收打包数据后，将打包数据解析后得到的数据内容存储至本地数据库并得到本地存储地址，将打包数据解析后得到的数据属性和本地存储地址作为相关信息存储至相应的消息队列。

优选的，Publisher实例接收到打包数据后，判断是否存在队列标识与打包数据的业务类型匹配的消息队列，如果存在，则将打包数据分发给相应的消息队列，如果不存在，则判断是否创建队列标识与打包数据的业务类型匹配的消息队列，并将打包数据分发给新建的消息队列。

优选的，Consumer实例从消息队列取出打包数据后，消息队列将该打包数据添加待处理标识后移至队列末尾；

Consumer实例对打包数据处理成功后向消息队列反馈处理成功通知，消息队列删除该打包数据；

Consumer实例对打包数据处理失败后向消息队列反馈处理失败通知，消息队列删除该打包数据的待处理标识，并将该打包数据重新放入消息队列。

一种高并发高解耦数据中台系统，包括：

Ngnix服务器，用于接收打包数据；

Publisher实例，其连接Ngnix服务器，用于接收Ngnix服务器分发的符合预设接收范围的打包数据，并根据打包数据的业务类型对其进行分发；

消息队列，其连接Publisher实例，用于接收Publisher实例分发的打包数据；

Consumer实例，其连接消息队列，用于从符合预设处理范围的消息队列获取打包数据，并根据打包数据的业务类型选择相应的处理策略进行处理得到处理结果，并输出处理结果；

本地数据库，其连接Ngnix服务器、Publisher实例、消息队列、以及Consumer实例，用于存储Ngnix服务器、Publisher实例消息队列、以及Consumer实例的相关信息，还用于存储Consumer实例发送的处理结果，根据预设分类策略对处理结果进行分类得到对应不同业务维度的最终数据，通过多个本地端口分别输出不同业务维度的最终数据。

优选的，数据中台系统还包括：

配置模块，用于配置预设数量的数据来源端和数据使用端，并配置每个数据来源端的上报权限和每个数据使用端的使用权限；

配置上报权限时，数据来源端向配置模块申请appId、appKey、以及向数据中台系统上报打包数据时的原始URL；

数据中台系统从配置模块获取所有数据来源端的appId、appKey、以及原始URL并进行保存，以在数据来源端向数据中台系统上报打包数据时对其进行验证，在验证通过时接收打包数据，在验证失败时反馈错误代码。

本发明的有益效果：

1.根据数据中台系统的服务器压力通过Nginx服务器灵活配置消息队列并发数，支持多Publisher实例+Nginx服务器负载均衡提高并发量，实现高并发，保证数据上报时效性，避免数据丢失。

2.通过配置Publisher实例和Consumer实例分别实现数据入栈和数据出栈，数据入栈时存入消息队列的上报过程与数据出栈时从消息队列获取数据的处理过程完全分开，上报数据不关心具体业务需要如何解析，解析数据不需要关心数据从哪里通过什么途径来的，实现高解耦。

3.由于数据入栈上报和数据出栈处理是分来两个进行处理，也使系统处理架构明确，需要进行扩展时只需配置Publisher实例和Consumer实例的数量，并配置相应的预设接收范围和预设处理范围，就能实现灵活扩展Publisher实例能够接收的相应业务类型和Consumer实例能够处理的相应业务类型，不与具体业务耦合，配置和扩展更灵活。

4.通过配置本地数据库，将数据中台系统在数据处理过程中产生的打包数据的相关信息和最终数据均存入本地数据库，仅需要在公网配置用于获取不同业务维度的最终数据的映射端口，数据使用者通过映射端口就能获得所需数据，打通了本地数据库和公网，由本地数据库承载数据存储任务，减轻了公网存储压力，节约了公网服务器磁盘压力，减少运营费用。

5.通过在公网提供对应不同业务维度的映射端口，实现同一业务维度的数据通过统一口径输出。

附图说明

图1为本发明实施例中，高并发高解耦数据中台系统的数据上传侧的功能模块示意图。

图2为本发明实施例中，高并发高解耦数据中台系统的功能模块示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实例仅仅用以解释本发明，并不限定本发明。此外，基于本发明的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明的保护范围。

以下结合附图及实施例对本发明作进一步详细说明。

如图1-2所示，本发明提供一种高并发高解耦数据处理方法，包括：

数据入栈过程，主要涉及Ngnix服务器(一个高性能Http和反向代理Web服务程序)、Publisher(消息接收程序)实例、以及消息队列。包括通过所述Ngnix服务器接收所述打包数据并分发给多个所述Publisher实例，每个所述Publisher实例接收所述Ngnix服务器分发的符合预设接收范围的所述打包数据后，根据所述打包数据的业务类型分发给多个消息队列，每个消息队列接收具有其队列标识匹配的业务类型的所述打包数据。

数据出栈过程，主要涉及消息队列、Consumer(消息处理程序)实例、本地数据库、本地端口、以及公网的映射端口。包括通过所述Consumer实例从符合预设处理范围的所述消息队列获取所述打包数据，并根据所述打包数据的业务类型选择相应的所述处理策略进行处理得到所述处理结果，所述Consumer实例将处理结果存入所述本地数据库，所述本地数据库根据预设分类策略对所述处理结果进行分类得到对应不同业务维度的最终数据，所述本地数据库配置有对应每个业务维度的所述本地端口并在公网配置有对应每个所述本地端口的所述映射端口。通过在公网提供对应不同业务维度的映射端口，实现同一业务维度的数据通过统一口径输出。

在上述过程中，Ngnix服务器、Publisher实例、消息队列、Consumer实例的相关数据以及处理过程中产生的数据均可存入本地数据库。

本发明中，根据数据中台系统的服务器压力通过Nginx服务器灵活配置消息队列并发数，支持多Publisher实例+Nginx服务器负载均衡提高并发量，实现高并发，保证数据上报时效性，避免数据丢失。

通过配置Publisher实例和Consumer实例分别实现数据入栈和数据出栈，数据入栈时存入消息队列的上报过程与数据出栈时从消息队列获取数据的处理过程完全分开，上报数据不关心具体业务需要如何解析，解析数据不需要关心数据从哪里通过什么途径来的，实现高解耦。

由于数据入栈上报和数据出栈处理是分来两个进行处理，也使系统处理架构明确，需要进行扩展时只需配置Publisher实例和Consumer实例的数量，并配置相应的预设接收范围和预设处理范围，就能实现灵活扩展Publisher实例能够接收的相应业务类型和Consumer实例能够处理的相应业务类型，不与具体业务耦合，配置和扩展更灵活。并且因为不同的业务类型会使用不同的消息队列，所以各个业务之间的消息不会互相影响甚至丢失。可以启动多个消息处理Consumer实例从而实现消息的快速处理，同时也可以通过业务类型生成不同的消息队列唯一标识给不同的Consumer实例配置不同的处理对象，从而达到各个Consumer实例不会互相影响。

通过配置本地数据库，将数据中台系统在数据处理过程中产生的打包数据的相关信息和最终数据均存入本地数据库，仅需要在公网配置用于获取不同业务维度的最终数据的映射端口，数据使用者通过映射端口就能获得所需数据，打通了本地数据库和公网，由本地数据库承载数据存储任务，减轻了公网存储压力，节约了公网服务器磁盘压力，减少运营费用。具体的，通过FRP(一种端口NAT穿透的程序)端口代理或者VPN(虚拟专用网络)挂载另外一个配置了大数据存储服务(比如本地数据库是MongoDB集群时)的端口号，甚至是本地没有公网IP的服务器，极大减少了公网存储服务器的年费，而最终用户使用的最终结果一般都会比原始提交消息要小很多，并且可以数据应用接口服务器上配置譬如redis的缓存策略来实现减少对大数据存储服务的访问量。同样可以使用VPN方式挂载另外一个配置了大容量磁盘的服务器磁盘，减少对数据中台缓存文件的磁盘压力和云服务器年费。配置高性能高容量的大数据存储服务即本地数据库，优选使用NoSql数据库中的MongoDB(一个基于分布式文件存储的数据库)搭建集群。

较佳的实施例中，数据处理方法还包括：

配置过程，在数据中台系统中配置预设数量的Ngnix服务器、Publilsher实例、消息队列、以及Consumer实例，并配置每个Publilsher实例的预设接收范围和每个Consumer实例的预设处理范围，并配置本地数据库、多个本地数据库的本地端口、多个本地端口在公网的映射端口，并配置本地数据库的预设分类策略。

数据打包过程，主要涉及数据来源端和配置模块。包括通过所述数据来源端获取所述原始数据并根据所述原始数据的数据属性生成所述业务类型，根据所述原始数据的业务类型和数据内容生成所述打包数据，所述数据来源端向所述配置模块申请appId(客户端应用唯一标识)、appKey(客户端授权秘钥)、以及原始URL(Uniform Resource Locator，统一资源定位符)，根据appId、appKey、原始URL、以及Timestamp(时间戳)生成最终URL后，通过HTTP POST请求方式将所述打包数据上传至关联于所述最终URL的所述Publisher实例，所述Publisher实例从所述配置模块获取每个所述数据来源端的appId、appKey、以及原始UR，并在接收到所述Ngnix服务器分发的所述打包数据后，对该打包数据的appId、appKey、以及原始URL进行验证，在验证通过时接收所述打包数据，在验证不通过时反馈错误代码。

数据使用过程，主要涉及公网的映射端口和数据使用端。包括向所述配置模块申请验证信息，并在所述验证信息通过所述映射端口的权限验证时，从所述映射端口获取所述最终数据以进行数据应用。

在本实施例中，数据打包过程包括从数据源采集原始数据。根据原始数据的数据属性生成业务类型，对原始数据的数据内容进行序列化并压缩成待处理文件，在待处理文件中添加业务类型后进行打包生成打包数据。将数据来源端从配置模块申请的appId、appKey、以及原始URL结合时间戳生成最终URL，将打包数据上传至关联于最终URL的Publisher实例。

出于安全考虑，数据中台系统还必须拥有一套客户端权限配置平台，防止无权限的客户端提交无效数据。这里的客户端即为数据来源端，权限配置平台即为配置模块。

数据打包过程完成后，数据来源端将数据最终提交给Publisher实例时，Publisher实例会对打包数据进行权限验证，该权限验证过程包括数据来源端去配置模块申请appId和appKey。配置模块提供数据上报链接路由即原始URL，例如：JSON类型数据上报链接路由：https://xxxx/datacenter/publish/json。文件类型数据上报链接路由：https://xxxx/datacenter/publish/file。

原始URL带上appId以及时间戳，appId表明客户端身份，时间戳表示0001年1月1日午夜12:00以来所经过的秒数，所以现在的上传链接为：

https://xxxx/datacenter/publish/json？appId＝{AppID}&timestamp＝63689820900。

截取appId＝{AppID}&timestamp＝63689820900部分，对参数key进行字符串排序，删除“＝”号，进行拼接，假如value为空，也需要保留key的内容，大致格式为：

键key1值value1键key2值value2。

当appId为App1时，拼接结果为：

appIdApp1timestamp63689820900。

数据来源端必须保存之前在配置模块申请的appKey，拼接到上面字符串的末尾，然后进行MD5(一种广泛使用的信息摘要算法)压缩成32位长度的sign，合并到链接末尾，然后即可作为最终请求的地址即最终URL，基于最终URL上报打包数据至相应的Publisher实例，最终URL如下：

http://xxxx/datacenter/publish/json？appId＝App1&timestamp＝63689820900&sign＝D45BA030AA23CEEA41DEC14A85B74F8D。

Publisher实例通过验证sign的内容验证数据来源端的权限，通过timestamp校验权限打包数据的上报有效期和提交次数。

数据入栈过程中，Publisher服务器接收到客户来源端的请求，存在两种情况：A.打包数据为Json类型数据，B.打包数据为文件类型数据。

打包数据为JSON类型数据的数据入栈过程包括Nginx服务器将数据来源端通过HTTP POST方式提交的打包数据分发到某一个Publisher实例。Publisher实例通过最终URL对数据来源端进行权限验证，若验证通过则接收到该打包数据，若验证不通过则不接收该打包数据并反馈错误代码。根据打包数据的业务类型从消息队列(可以是RabbitMQ，Kafka，RocketMQ，MSMQ等现在市面主流的消息队列)获取是否已经存在与此业务类型匹配的消息队列，若果存在则将Publisher实例将接收到的Post请求的5个属性全部推入消息队列，等待Consumer实例取出消息进行处理。如果不存在则通过消息队列服务接口创建符合预设接收范围的新队列，然后将接收到的Post请求的5个属性全部推入消息队列，等待Consumer实例取出消息进行处理。

打包数据为文件类型数据的数据入栈过程包括Nginx服务器将数据来源端通过HTTP POST方式提交的打包数据分发到某一个Publisher实例。Publisher实例通过最终URL对数据来源端进行权限验证，若验证通过则接收到该打包数据，若验证不通过则不接收该打包数据并反馈错误代码。Publisher实例将接收到的文件内容的二进制数据写入磁盘(磁盘属于本地数据库)某一特定目录并统一修改后缀为.tmp，然后将Post请求的4个其他属性全部推入消息队列，并且额外加入一个文件原始名称和服务器磁盘路径的属性即本地存储地址，等待消费者取出消息进行处理。

数据出栈过程包括本地搭建本地数据库提供结构化存储的空间。配置VPN或者FRP端口映射，将大容量存储服务器的本地端口映射到公网上。Consumer实例配置自己能够处理哪些类型的消息(与Publisher的生成的消息队列唯一标识一一对应)，启动Consumer实例后，Consumer实例会自动从自己能够处理的消息队列注册消息接收处理事件。Publisher实例推送新的消息到A队列中，能够处理A队列消息的Consumer实例通过注册的事件可以接受到此消息通知，并取出该消息。Consumer实例处理完毕后，通知消息队列服务，此条消息已经被消费，不用返回消息队列，避免被其他消费者重复处理。Consumer实例处理后的最终数据按照业务维度保存到本地数据库中。

数据应用过程包括数据中台系统提供本地端口根据业务维度对数据进行维度上的划分，并且提供统一的映射端口。数据使用端拿到数据后结合当前业务使用，比如推送告警消息，推荐系统，或者直接生成报表给最终用户查看。

本发明还提供一种低费用的高并发高解耦数据中台系统，包括Ngnix服务器、连接Ngnix服务器的多个Publisher实例、连接多个Publisher实例的多个消息队列、连接多个消息队列的多个Consumer实例、本地数据库、以及配置模块(图中未示出)，本地数据库连接上述Ngnix服务器、Publisher实例、消息队列、Consumer实例。通过配置模块预先为每个Publisher实例均配置有预设接收范围，Publisher实例只能接收预设接收范围的数据，且预先为每个Consumer实例均配置有预设处理范围，Consumer实例只能处理预设处理范围的数据。Publisher实例的预设接收范围、Consumer实例的预设处理范围可灵活配置，同时，Ngnix服务器、Publisher实例、消息队列、Consumer实例的数量也可灵活配置。

在数据入栈时，Ngnix服务器接收外部发送的符合预设接收范围的打包数据，该打包数据由业务类型和数据内容构成。Ngnix服务器将打包数据分发给多个消息队列，每个消息队列均具有一唯一的队列标识，Ngnix服务器分发打包数据时，根据打包数据的业务类型，将打包数据发送至队列标识与其业务类型匹配的消息队列中。

在数据出栈时，Consumer实例从多个消息队列获取符合预设处理范围的打包数据，根据打包数据的业务类型选择相应的处理策略进行处理得到处理结果。所有Consumer实例产生的处理结果均存入本地数据库保存，无需上传至公网(例如云服务器)。本地数据库根据预设分类策略对处理结果进行分类得到对应不同业务维度的最终数据，本地数据库提供对应每个业务维度的本地端口，同时通过端口映射在公网提供每个本地端口的映射端口，数据使用者只需通过映射端口即可获取所需的最终数据。

较佳的实施例中，继续参照图1-2，数据中台系统还包括：

配置模块，其连接所述Publisher实例。

多个数据来源端，数据来源端可以是所有可以向Nginx服务器上报打包数据的接口或应用程序，其分别连接所述Ngnix服务器和所述配置模块，每个所述数据来源端分别用于获取原始数据并根据原始数据的数据属性生成业务类型，根据所述原始数据的业务类型和数据内容生成所述打包数据，还用于向所述配置模块申请appId、appKey、以及原始URL，根据appId、appKey、原始URL、以及时间戳生成最终URL，还用于通过HTTP POST请求方式将所述打包数据上传至关联于所述最终URL的所述Publisher实例。

所述Publisher实例还用于从所述配置模块获取每个所述数据来源端的appId、appKey、以及原始URL，所述Publisher实例接收到所述Ngnix服务器分发的所述打包数据后，对该打包数据的appId、appKey、以及原始URL进行验证，在验证通过时接收所述打包数据，在验证不通过时反馈错误代码。

多个数据使用端，数据使用端可以是所有可以从映射端口下载最终数据的接口或应用程序，其分别连接所述映射端口和所述配置模块，用于向所述配置模块申请验证信息，并在所述验证信息通过所述映射端口的权限验证时，从所述映射端口获取所述最终数据以进行数据应用。

在本实施例中，数据打包上报时，数据来源端从数据源采集原始数据，原始数据具有多个数据属性，根据原始数据的数据属性生成业务类型，将原始数据的数据内容序列化并压缩成文件然后加入业务类型打包生成打包数据。数据来源端将打包数据上报给Nginx服务器时需要通过验证，因此，数据来源端向配置模块申请数据上报的原始URL、appId、以及appKey，appId、appKey、以及上报时的时间戳构成该打包数据的sign(验证标识)，根据appId、appKey、原始URL、以及时间戳生成最终URL，通过HTTP POST请求方式将所述打包数据上传至关联于该最终URL的所述Publisher实例。Publisher实例预先从配置模块获取每个数据来源端的appId、appKey、以及原始URL，Publisher实例接收到数据来源端上报的打包数据后，对打包数据的最终URL或者说sign进行验证，验证通过则接收打包数据，验证不通过则向发送打包数据的数据来源端反馈ErrorCode(错误代码)提示数据来源端没有上传权限。

数据应用时，数据使用端从映射端口获取最终数据时，也需要进行权限验证，数据使用端的验证方法可与数据来源端一样通过申请原始URL、appId、以及appKey完成，也可采用其他验证方式。

进一步的，如果数据来源端和数据使用端均设置在本地，即数据来源端、Nginx服务器、Publisher实例、消息队列、Consumer实例、数据使用端均设置在本地时，数据来源端上报数据时和数据使用端下载数据时可以不需要上述验证过程。另外，如果只有Nginx服务器、Publisher实例、消息队列设置在本地，而Consumer实例没有设置在本地时，也可以为Consumer实例配置验证过程，只有Consumer实例通过本地验证后才能从消息队列获取打包数据。

较佳的实施例中，原始数据包括第一类型数据和第二类型数据，由第一类型数据的原始数据生成的打包数据也属于第一类型数据，由第二类型数据的原始数据生成的打包数据也属于第二类型数据。第一类型数据的数据量小于第二类型数据的数据量。

第一类型数据包括JSON(JavaScript Object Notation，JS对象简谱)类型数据，JSON类型数据包含如下5个属性，可根据前4个属性生成业务类型也可以根据前3个属性生成业务类型。JSON类型数据直接使用raw方式提交：

Source：字符串类型，消息客户端标识，针对多客户端同业务类型的情况，用来区分客户端。

Namespace：字符串类型，消息的命名空间，用来做业务类型的一级区分。

Type：字符串类型，消息的具体类型，用来做业务类型的二级划分。

Version：字符串类型，消息的版本，用来做业务类型的三级划分。

JsonString：字符串类型，消息具体的内容。

所述第二类型数据包括文件类型数据，文件类型数据包含如下4个属性，可根据前4个属性生成业务类型也可以根据前3个属性生成业务类型。文件类型数据使用form-data方式提交：

Source：字符串类型，消息客户端标识，针对多客户端同业务类型的情况，用来区分客户端。

Namespace：字符串类型，消息的命名空间，用来做业务类型的一级区分。

Type：字符串类型，消息的具体类型，用来做业务类型的二级划分。

Version：字符串类型，消息的版本，用来做业务类型的三级划分。

这4个属性与JSON类型数据的前4个属性作用一致。文件类型数据不需要JsonString属性，但是需要包含一个文件上传流。

在本实施例中，数据来源端获取原始数据进行数据打包时支持多种格式的原始数据，以Json和文件两种数据格式为例，这两种数据格式的原始数据已经足以应付大部分的业务数据提交需求，如果客户端不仅仅支持Http(HyperText Transfer Protocol，超文本传输协议)协议的通信方式，可以考虑其他TCP(Transmission Control Protocol/Internet Protocol)方式，比如Protobuf(Google Protocol Buffer，Google开源的跨语言进程间通信框架)或FastSocket(快速嵌套字连接)等技术框架实现数据上报。

较佳的实施例中，所述打包数据为JSON类型数据时，所述Publisher实例接收所述打包数据后，将所述打包数据解析后得到的数据属性和数据内容作为相关信息存储至相应的所述消息队列。

当所述原始数据为文件类型数据时，所述Publisher实例接收所述打包数据后，将所述打包数据解析后得到的数据内容存储至所述本地数据库，将所述打包数据解析后得到的数据属性和在所述本地数据库中的本地存储地址作为相关信息存储至相应的所述消息队列。

较佳的实施例中，所述Publisher实例接收到所述打包数据后，判断是否存在队列标识与所述打包数据的业务类型匹配的所述消息队列，如果存在，则将所述打包数据的所述相关信息放入相应的所述消息队列；如果不存在，则基于所述预设接收范围判断是否创建队列标识与所述打包数据的业务类型匹配的所述消息队列，并将所述打包数据的所述相关信息放入新建的所述消息队列。

所述Consumer实例从所述消息队列取出所述打包数据的所述相关信息后，所述Consumer实例将该相关信息添加待处理标识后移至队列末尾。

较佳的实施例中，所述Consumer实例对所述相关信息包含的数据内容处理成功后向所述消息队列发送处理成功通知，所述消息队列根据所述处理成功通知删除所述相关信息。

所述Consumer实例对所述相关信息包含的数据内容处理失败后向所述消息队列发送处理失败通知，所述消息队列根据所述处理失败通知删除该相关信息的待处理标识，并将该相关信息重新放入所述消息队列。

较佳的实施例中，所述本地数据库通过配置VPN端口映射或FRP端口映射将所述本地端口映射到公网。FRP安全性和性能更优。

采用上述数据中台系统，能够根据企业具体业务来定制化开发一台高并发高解耦的数据中台系统，避免被目前数据中台的云服务提供的解决方案所捆绑，根据服务器压力通过Nginx服务器灵活配置服务器并发数，通过打通公有云和本地服务器，节约了公网服务器磁盘压力，减少运营费用。业务横向扩展灵活，只需要配置数据提交Http接口侧的Publisher实例的消息类型范围和数据处理侧的Consumer实例的消息处理逻辑，业务生成数据，数据生成报表或结合APP业务使用。以开源消息队列、数据缓存区和算法为核心，对开发语言没有强制约束，进一步提高了此方法在企业应用中的灵活性。

本地数据库可以使用除了MongoDB以外的任何支持大数据存储的数据库。

VPN服务也可以使用除了N2N(一种虚拟专用网络程序)的以外的任何VPN服务器，包括OpenVPN(一种虚拟专用网络程序)等等来替代。

FRP端口映射也可以使用任何其他端口映射的解决方案，包括Sock5等等来替代。

客户端权限验证加密算法可以使用除了MD5以外的其他安全性较高单向加密方式，包括SHA1(Secure Hash Algorithm 1，安全散列算法1)、SHA2(Secure Hash Algorithm2，安全散列算法2)算法等。

在客户端访问中台数据访问接口，可以使用其他通用权限验证方式，比如OAuth2.0(Open Authorization，开发授权2.0版本)。

本发明不局限于实施方式，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也视为本发明的保护范围之内。本说明书中未作详细描述的内容属于本领域专业技术人员公知的现有技术。

Claims (10)

1.一种高并发高解耦数据处理方法，其特征在于，包括：

数据入栈过程，通过Ngnix服务器接收打包数据并分发给多个Publisher实例，Publisher实例根据打包数据的业务类型将其分发给多个消息队列；

数据出栈过程，通过Consumer实例从多个消息队列获取打包数据，并对其进行处理得到处理结果，将处理结果存入本地数据库，本地数据库对处理结果进行分类得到对应不同业务维度的最终数据，每个业务维度的最终数据均通过唯一的本地端口和映射端口输出。

2.如权利要求1所述的数据处理方法，其特征在于，数据处理方法还包括配置过程：

配置本地数据库的预设分类策略，预设分类策略为根据多个业务维度对数据进行分类；

配置本地数据库，本地数据库包括多个本地端口，在公网上配置有与每个本地端口对应的映射端口。

3.如权利要求2所述的数据处理方法，其特征在于，配置过程还包括配置预设数量的数据来源端及对应的上报权限，配置上报权限包括：

数据来源端向数据中台系统申请appId、appKey、以及向数据中台系统上报打包数据时的原始URL；

数据中台系统保存所有数据来源端的appId、appKey、以及原始URL，以在数据来源端向数据中台系统上报打包数据时对其进行验证，在验证通过时接收打包数据，在验证失败时反馈错误代码。

4.如权利要求3所述的数据处理方法，其特征在于，所述数据处理方法还包括：

数据打包过程，通过数据来源端获取原始数据，根据原始数据的数据属性生成业务类型，根据原始数据的业务类型和数据内容生成打包数据，根据appId、appKey、原始URL、以及时间戳生成最终URL后，通过HTTP POST请求方式将打包数据上传至关联于最终URL的Publisher实例；

数据使用过程，从映射端口获取最终数据进行数据应用。

5.如权利要求1所述的数据处理方法，其特征在于，打包数据包括第一类型数据和第二类型数据，第一类型数据的数据量小于第二类型数据；

第一类型数据包括JSON类型数据；

第二类型数据包括文件类型数据。

6.如权利要求5所述的数据处理方法，其特征在于，打包数据为第一类型数据时，Publisher实例接收打包数据后，将打包数据解析后得到的数据属性和数据内容作为相关信息存储至相应的消息队列；

打包数据为第二类型数据时，Publisher实例接收打包数据后，将打包数据解析后得到的数据内容存储至本地数据库并得到本地存储地址，将打包数据解析后得到的数据属性和本地存储地址作为相关信息存储至相应的消息队列。

7.如权利要求1所述的数据处理方法，其特征在于，Publisher实例接收到打包数据后，判断是否存在队列标识与打包数据的业务类型匹配的消息队列，如果存在，则将打包数据分发给相应的消息队列，如果不存在，则判断是否创建队列标识与打包数据的业务类型匹配的消息队列，并将打包数据分发给新建的消息队列。

8.如权利要求1所述的数据处理方法，其特征在于，Consumer实例从消息队列取出打包数据后，消息队列将该打包数据添加待处理标识后移至队列末尾；

Consumer实例对打包数据处理成功后向消息队列反馈处理成功通知，消息队列删除该打包数据；

Consumer实例对打包数据处理失败后向消息队列反馈处理失败通知，消息队列删除该打包数据的待处理标识，并将该打包数据重新放入消息队列。

9.一种高并发高解耦数据中台系统，其特征在于，包括：

Ngnix服务器，用于接收打包数据；

Publisher实例，其连接Ngnix服务器，用于接收Ngnix服务器分发的符合预设接收范围的打包数据，并根据打包数据的业务类型对其进行分发；

消息队列，其连接Publisher实例，用于接收Publisher实例分发的打包数据；

Consumer实例，其连接消息队列，用于从符合预设处理范围的消息队列获取打包数据，并根据打包数据的业务类型选择相应的处理策略进行处理得到处理结果，并输出处理结果；

本地数据库，其连接Ngnix服务器、Publisher实例、消息队列、以及Consumer实例，用于存储Ngnix服务器、Publisher实例消息队列、以及Consumer实例的相关信息，还用于存储Consumer实例发送的处理结果，根据预设分类策略对处理结果进行分类得到对应不同业务维度的最终数据，通过多个本地端口分别输出不同业务维度的最终数据。

10.如权利要求9所述的数据中台系统，其特征在于，数据中台系统还包括：

配置模块，用于配置预设数量的数据来源端和数据使用端，并配置每个数据来源端的上报权限和每个数据使用端的使用权限；

配置上报权限时，数据来源端向配置模块申请appId、appKey、以及向数据中台系统上报打包数据时的原始URL；

数据中台系统从配置模块获取所有数据来源端的appId、appKey、以及原始URL并进行保存，以在数据来源端向数据中台系统上报打包数据时对其进行验证，在验证通过时接收打包数据，在验证失败时反馈错误代码。

Images