CN114707926A - 基于kafka技术的订单数据处理方法、系统、设备和存储介质 - Google Patents

Abstract

本发明公开基于kafka技术的订单数据处理方法、系统、设备和存储介质，包括：预先通过Kafka集群创建订单服务器作为消息生产方，并创造一用于存储直接交互订单记录的第一topi c标题，直接处理数据交互的处理服务器为第一topic标题的消息订阅方；订单服务器通过kafka消息队列从当前物流订单数据中抓取设置有直接交互标识的物流订单信息，将信息发布至第一topic标题中；处理服务器消费发布到第一topi c标题的物流订单信息，将物流订单信息进行第二业务处理后，找到物流订单匹配的终端，完成数据传输。本发明通过kafka队列抓取出有标记的物流订单，处理服务器独立处理第二业务，信息推送省去中间环节，节省处理时间，提高处理效率，安全性高。

Description

基于kafka技术的订单数据处理方法、系统、设备和存储介质

技术领域

本发明属于物流订单处理的技术领域，尤其涉及基于kafka技术的订单数据处理方法、系统、设备和存储介质。

背景技术

OMS系统中文全称“订单管理系统”，英文全称“Order Management System”，简称“OMS”。OMS订单管理系统是物流管理系统的一部分，通过对客户下达的订单进行管理及跟踪，动态掌握订单的进展和完成情况，提升物流过程中的作业效率，从而节省运作时间和作业成本，提高物流企业的市场竞争力。OMS系统定位于为贸易双方提供更完整的物流外包服务，通过统一订单提供用户整合的一站式供应链服务，订单管理以及订单跟踪管理能够使用户的物流服务得到全程的满足。

OMS订单管理系统定位于为处于供应链上游的供应商和下游的买方，以及提供各种物流服务的各类物流服务供应商提供基于订单进行业务沟通、实现物流服务和控制管理的系统。通过对订单的管理和控制，合理安排运送计划、有效降低库存。物流行业也随之迅猛发展，物流网点与物流总部之间或各物流网点之间会产生很多的业务数据流通。

以图1为例，物流总部平台1至少设置OMS订单管理系统所在的订单服务器11，订单服务器11通过网络4与各个物流网点2进行通信，再通过对应物流网点2与对应的终端3(如快递员所在的通信终端)进行数据交互。这种数据传输的链路较长，数据传送的安全性不高。特别是当物流网点2没有与终端3进行数据交互时，订单服务器11需要不断跟踪该订单数据的交互记录，直至该物流网点2与终端3完成交互，才能将交互完成的消息反馈至订单服务器11，响应慢且占用大量的网络交互资源。

以冷链属性的闪送订单为例，订单服务器11先定期将冷链属性的闪送订单数据进行批处理，获知物流网点2中相应的终端3是否将订单送至对应的客户端，后根据结算模型计算出该物流网点2这些批处理闪送订单数据需要的物流业务费用，物流业务费用结算是通过物流总部进行物流业务费用的结算，并由物流总部根据结算所得的结算清单进行转账至物流网点2，由物流网点2再转账到对应的终端3。整个数据处理链路太长、安全性不高且准确性不高。

发明内容

本发明的目的是提供一种基于kafka技术的订单数据处理方法、系统和存储介质，基于kafka技术来进行数据处理后可以直接完成处理器与终端的数据传输。

一种基于kafka技术的订单数据处理方法，包括：

预先通过Kafka集群创建订单服务器作为消息生产方，并创造一用于存储直接交互订单记录的第一topic标题，直接处理数据交互的处理服务器为所述第一topic标题的消息订阅方；

所述订单服务器通过kafka消息队列从当前物流订单数据中抓取设置有所述直接交互标识的物流订单信息，将所述信息发布至所述第一topic标题中；

所述处理服务器消费所述发布到所述第一topic标题的物流订单信息，将所述物流订单信息进行第二业务处理后，找到所述物流订单匹配的终端，完成数据传输。

进一步，所述处理服务器消费所述发布到所述第一topic标题的物流订单信息进一步包括：

所述处理服务器预先设置并维护偏移量信息，所述偏移量信息表明所述第一topic标题消费到的当前物流订单信息所在的partition分区的位置信息；

所述处理服务器在空闲状态下，通过所述偏移量信息去访问适配的所述partition分区对应的所述物流订单信息，并将所述物流订单信息依次放入预置数据库，后更新所述偏移量信息。

进一步，将所述物流订单信息进行第二业务处理之前还包括：

读取所述物流订单信息，从所述物流订单信息中解析出订单标识信息；

通过所述订单标识获得匹配的订单物流轨迹信息，其至少包括所述物流订单的签收信息。

进一步，通过所述订单标识获得匹配的订单物流轨迹信息进一步包括：

预先通过Kafka集群创建物流轨迹服务器作为消息生产方，并创造一用于存储物流轨迹记录的第二topic标题，所述处理服务器为所述第二topic的消息订阅方；

所述物流轨迹服务器通过kafka消息队列从当前物流轨迹数据中抓取符合预设要求的物流轨迹信息，将所述物流轨迹信息发布至所述第二topic标题中；

所述处理服务器消费所述发布到所述第二topic标题的物流轨迹信息，将所述物流轨迹信息保存至所述预置数据库所述订单标识对应的记录中。

进一步，将所述物流订单信息进行第二业务处理具体为包括：

所述处理服务器按照预先设置的订单派送计费模型，计算所述预置数据库中派单计费数据生成付款信息；

根据所述付款信息生成付款账单，以使将费用支付至所述物流订单匹配的终端。

进一步，计算所述预置数据库中派单计费数据进一步包括：

设置所述预置数据库进一步设置第一数据库、第二数据库和派单计费数据库；

所述处理服务器通过所述偏移量信息去访问适配的所述partition分区对应的所述物流订单信息，将所述物流订单信息放入在所述第一数据库；并且，所述处理服务器消费所述发布到所述第二topic标题的物流轨迹信息，将所述物流轨迹信息保存至所述第二数据库中；

定期或触发式将所述第一数据库和和所述第二数据库的同一订单标识数据更新至所述派单计费数据库；

从所述派单计费数据库中获得所述订单标识下的快递单接收时间，计算出所述快递单的送单时间，以计算出所述订单的送单费用信息。

进一步，找到所述物流订单匹配的终端完成数据传输进一步包括：

找到所述物流订单匹配的终端；

利用所述处理服务器启动在主线程回调,开启

swoole_websocket_server服务，将所述第二业务处理后的数据采用swoole+Redis实现实时数据推送，其具体为：

预先创建了manager进程和创建了worker进程；

监听定时器；

当监听到所述第二业务处理后的数据被计算后，所述worker进程使用swoole_server_task函数投递发送至对应的终端的Task；

当前的Task进程在调用onTask回调函数时会将进程状态切换为忙碌，这时将不再接收新的Task，当onTask函数返回时会将进程状态切换为空闲然后继续接收新的Task；

当所述worker进程投递的任务完成时，所述task进程会通过

$ws->finish()方法将任务处理的结果发送给所述worker进程，以此基于异步事件驱动和协程的并行网络通信来完成所述第二业务处理后的数据及时传送至对应的终端。

本发明还提供一种基于kafka技术的订单数据处理系统，包括：

Kafka集群：用于创建订单服务器作为消息生产方，并创造一用于存储直接交互订单记录的第一topic标题，直接处理数据交互的处理服务器为所述第一topic标题的消息订阅方；

订单服务器：用于通过kafka消息队列从当前物流订单数据中抓取设置有所述直接交互标识的物流订单信息，将所述信息发布至所述第一topic标题中；

处理服务器：用于消费所述发布到所述第一topic标题的物流订单信息，将所述物流订单信息进行第二业务处理后，找到所述物流订单匹配的终端完成数据传输。

本发明还提供一种基于kafka技术的订单数据处理设备，其特征在于，

Kafka集群交互单元：用于预先通过Kafka集群创建订单服务器作为消息生产方，并创造一用于存储直接交互订单记录的第一topic标题，直接处理数据交互的处理服务器为所述第一topic标题的消息订阅方；

发布单元：用于通过kafka消息队列从当前物流订单数据中抓取设置有所述直接交互标识的物流订单信息，将所述信息发布至所述第一topic标题中；

第二业务处理单元：用于消费所述发布到所述第一topic标题的物流订单信息，将所述物流订单信息进行第二业务处理后，找到所述物流订单匹配的终端完成数据传输。

一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意一项所述的基于kafka技术的订单数据处理方法。

本发明由于采用以上技术方案，使其与现有技术相比具有以下的优点和积极效果：通过kafka队列抓取出有标记的物流订单，订单服务器作为消息生产方，处理服务器独立处理第二业务，将第二业务处理后的信息推送省去中间环节，从而节省处理时间，以提高处理效率，更重要的是增加安全性。

附图说明

图1为现有的OMS订单管理系统的原理图；

图2为一种基于kafka技术的订单数据处理系统的第一个实施图；

图3为第一实例基于kafka技术的订单数据处理流程图；

图4为一种基于kafka技术的订单数据处理系统的第二个实施图

图5为一种基于kafka技术的订单数据处理设备原理图。

具体实施方式

以下结合附图和具体实施例对本发明提出的一种基于kafka技术的订单数据处理方法、系统和存储介质作进一步详细说明。根据下面说明和权利要求书，本发明的优点和特征将更清楚。

本申请人发现：以冷链属性的闪送订单为例，订单服务器先定期将冷链属性的闪送订单数据进行批处理，获知物流网点中相应的终端是否将订单送至对应的客户端，后根据结算模型计算出该物流网点这些批处理闪送订单数据需要的物流业务费用，物流业务费用结算是通过物流总部进行物流业务费用的结算，并由物流总部根据结算所得的结算清单再转账至物流网点。以冷链属性的闪送订单每天以千万订单为级别数进行处理的，订单服务器只有在一天的晚上或定期时间点，更新物流网点的终端是否将订单送至对应的客户端后，后才能计算出该物流网点的相关终端3的物流业务费用，处理效率慢，不具有及时性。且整个数据传输链路长。申请人经过分析可知，处理的数据量大，且单进程跟踪终端送订单的反馈(订单是否签收，签收的时间等)。

为此，本申请人引入了Kafka(卡夫卡)技术，Kafka是最初由Linkedin(领英)公司开发，是一个分布式、分区的、多副本的、多订阅者，基于zookeeper(分布式应用程序协调服务软件)协调的分布式日志系统(也可以当做MQ系统)，常见可以用于访问日志，消息服务等等，Linkedin于2010年贡献给了Apachea基金(Apache Software Foundation，简称为ASF，阿帕切人软件基金)基会并成为顶级开源项目。主要应用场景是：日志收集系统和消息系统。一个消息系统负责将数据从一个应用传递到另外一个应用，应用只需关注于数据，无需关注数据在两个或多个应用间是如何传递的。分布式消息传递基于可靠的消息队列，在客户端应用和消息系统之间异步传递消息。有两种主要的消息传递模式：点对点传递模式、发布-订阅模式。大部分的消息系统选用发布-订阅模式。Kafka就是一种发布-订阅模式。

请参阅图2，其为一种基于kafka技术的订单数据处理系统的一个实施图。它包括：订单服务器21、Kafka集群22、第一topic标题24、处理服务器23、网络25、物流网站26和各个快递员终端27(后续简称终端27)。

订单服务器21：其内设置OMS订单管理系统，完成订单数据处理。

处理服务器23，用于完成物流平台与终端的直接交互的处理服务。

处理服务器23可以是单纯的物理服务器，也可以是逻辑上的服务器。在本实例中，处理服务器23和订单服务器21可以在一个服务器集群中，或者仅设置在同一个服务器中。订单服务器21除了处理常规的OMS订单管理之外，还需要将订单服务器21将处理后的数据尽量实时且快速处理后直接发给对应的终端27。本发明的第一创新在于，将订单服务器21的常规的OMS订单管理业务和计算费用发至终端27等及时处理业务分为两个单独的处理进程。

Kafka集群22：Kafka集群22包含一个或多个服务器，服务器节点称为broker。broker存储topic(标题)的数据。如果某topic有N个partition(分区)，集群有N个broker(服务器节点)，那么每个broker存储该topic的一个partition。如果某topic有N个partition，集群有(N+M)个broker，那么其中有N个broker存储该topic的一个partition。如果某topic有N个partition，集群中broker数目少于N个，那么一个broker存储该topic的一个或多个partition。每条发布到Kafka集群的消息都有一个标题，这个标题被称为Topic。(物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处)。topic中的数据分割为一个或多个partition。每个topic至少有一个partition。每个partition中的数据使用多个segment(片)文件存储。partition中的数据是有序的，不同partition间的数据丢失了数据的顺序。

订单服务器21作为消息生产方，Kafka集群22并创造一用于存储直接交互订单记录的第一topic标题25，直接处理数据交互的处理服务器23为第一topic标题的消息订阅方。直接交互订单记录是一种比较笼统说明，表明完成第二业务有的标记。当第二业务为闪送的快递费结算时，则第一topic标题25用于保存有闪送标识的物流订单信息。存储直接交互订单记录的第一topic标题25为存储有第二业务特有标识的物流订单信息。

包含订单服务器21和处理服务器23的物流平台可以通过网络25与各个物流网站26和终端27进行通信。

第一实施例

请参阅图3，其为基于kafka技术的订单数据处理的一种流程图。它包括：

S11O:预先通过Kafka集群创建订单服务器作为消息生产方，并创造一用于存储直接交互订单记录的第一topic标题，直接处理数据交互的处理服务器为第一topic标题的消息订阅方。

S120:订单服务器通过kafka消息队列从当前物流订单数据中抓取设置有直接交互标识的物流订单信息，将信息发布至所述第一topic标题中；

S130:处理服务器消费所述发布到第一topic标题的物流订单信息，将物流订单信息处理后，找到物流订单匹配的终端完成，数据传输。

本发明的核心在于，将常规的订单业务和第二业务(将处理后的数据尽量实时且快速处理后直接发给对应的终端27)划分为两个独立进程，可以并行处理，订单业务独立进行，在订单业务中实时或定期从实时处理的当前订单中抓取满足条件的物流订单信息，利用kafka技术将其存储在第一topic标题中，而第二业务处理的处理服务器在其空闲时消费第一topic标题中的物流订单信息，完成第二业务处理。就上述提及的两个独立进程可以并行处理，而且可以是同一个物理服务器或服务集群来实现。

考虑到一个物流平台上同一段时间处理的订单数据是海量的，可能一个物流平台的OMS订单管理系统要在一天周期内处理达到几千万条的订单记录。以“闪送”业务为例，先将标明“闪送”标识的客户信息传送至OMS订单管理系统，这样，在订单实时处理过程中，可以将有该客户信息的订单标注““闪送”标识通过kafka消息队列从当前物流订单数据中抓取出有“闪送”标识的物流订单信息，发布至第一topic标题中。这里的“实时”也是相对的，一般也是批量化将满足条件“闪送”的标识进行抓取。

处理服务器消费发布到第一topic标题的物流订单信息，本实例考虑到海量的数据量，我们对其进行了处理。第一topic标题可以存在多个partition中，每个partition中的数据使用多个segment(片)文件存储。每个segment又包含.log、.index、.timeindex文件，存放的每条订单信息包含offset(偏移量)、消息大小、消息体……。利用偏移量信息去访问适配的partition分区对应的物流订单信息。订单服务器是将当前物流订单数据中找到满足条件的(如有第二业务特有标识)物流订单连续不断地放置第一topic标题。第一topic标题有很多partition、多个segment。按照第一topic标题存储的逻辑或存储方式，将该些有第二业务特有标识的物流订单进行存储，这个存入第一topic标题的存储进程是一个单独的进程。而取出物流信息又是一个额外的单独进程。在本发明中，通过偏移量信息，用于保存从第一topic标题中上一次取物流订单信息的位置信息。则当处理服务器消费发布到第一topic标题的物流订单信息，通过偏移量信息找到上一次消费物流订单信息所在的位置，即可进行本次消息。消息消费后需要更新偏移量信息，完成偏移量信息的维护。

还有，本发明通常会先预设一偏移量幅度(如N，相对偏移量)进行预处理后，通过偏移量值按一定相对偏移量调整再进行预处理，直到处理效果达到一预设范围(第二业务发送的时间)，后保存该偏移量值。

比如，查找订单数据时的时候是利用segment+offset配合的。假如现在需要查找一个offset为378801的message是什么样的过程呢？

先找到offset的378801message所在的segment文件(利用二分法查找)，这里找到的就是在第二个segment文件。

打开找到的segment中的.index文件(也就是378796.index文件，该文件起始偏移量为378796+1，我们要查找的offset为378801的message在该index内的偏移量为368796+5＝378801，所以这里要查找的相对offset为5)。由于该文件采用的是稀疏索引的方式存储着相对offset及对应message物理偏移量的关系，所以直接找相对offset为5的索引找不到，这里同样利用二分法查找相对offset小于或者等于指定的相对offset的索引条目中最大的那个相对offset，所以找到的是相对offset为4的这个索引。

根据找到的相对offset为4的索引确定message存储的物理偏移位置为256。打开数据文件，从位置为256的那个地方开始顺序扫描直到找到offset为378801的那条Message。

利用segment+有序offset+稀疏索引+二分查找+顺序查找等多种手段来高效的查找数据！至此，处理服务器就能拿到需要处理的数据进行处理了。那处理服务器又是怎么记录自己消费的位置呢？在处理服务器消费到的offset已经直接维护在kafk集群的__consumer_offsets这个topic中！

即：“处理服务器消费发布到第一topic标题的物流订单信息”进一步包括：

处理服务器预先设置并维护偏移量信息，偏移量信息表明第一topic标题消费到的当前partition分区中当前处理到的订单的位置信息；

处理服务器在空闲状态下，通过偏移量信息访问适配的partition分区对应的订单信息，并将物流订单信息依次放入预置数据库，后更新偏移量信息。

通过上述方式，即可以将满足条件的物流订单信息放置在一预置数据库中。预置数据库可以单独设置在处理服务器上，也可以是物流平台上一存储数据的空间，甚至是缓存空间等，即该预置数据库可以是物理上的数据库，也可以是逻辑上的存储空间。处理服务器可以直接对预置数据库中数据进行第二业务的处理。若订单中有客户的确认接收订单与否、收到的时间、终端信息，可以直接计算出第二业务中闪送的计费信息，并将计费信息传送至对应的终端。这种处理的效率高，不占用现有的订单处理进程，而且不存在第二业务的传输链路长、没有及时响应反馈无法实现的问题。

第二实施例

当物流平台的OMS订单管理系统处理的订单信息中未包含有客户接收订单是否签收、签收后的接收时间等，需要及时获知该些信息才能处理。物流平台的物流轨迹服务器实时保存该些信息。当然，原理上物流轨迹服务器和订单服务器同样可以是一个服务器或服务器集群，考虑到处理效率，将物流实时轨迹进程逻辑上虚拟到一物流轨迹服务器来实现。物流实时轨迹进程单独将其包含有客户接收订单是否签收、签收后的接收时间等信息独立获取，而不影响常规的物流轨迹服务器处理业务。

请参阅图4，其为其为一种基于kafka技术的订单数据处理系统的第二个实施图。它除了包括：订单服务器21、Kafka集群22、第一topic标题24、处理服务器23、网络25、物流网站26和各个快递员终端27(后续简称终端27)之外，还包括物流轨迹服务器28和第二topic标题29。

与第一实例相比，本方法增加了以下流程：

预先通过Kafka集群创建物流轨迹服务器作为消息生产方，并创造一用于存储物流轨迹记录的第二topic标题，物流轨迹实时处理的物流轨迹服务器为第二topic的消息订阅方；

物流轨迹服务器通过kafka消息队列从当前物流轨迹数据中抓取符合预设要求的物流轨迹信息，将信息发布至其匹配的所述第二topic标题中；

所理服务器消费发布到第二topic标题的物流轨迹信息，将物流轨迹信息分别保存至预置数据库订单标识对应的记录中。

比如，物流轨迹服务器将符合条件的记录存在第二topic标题中。符合条件可以是闪送且客户签收的，则直接将符合条件的记录放在第二topic标题中。处理服务器消费发布到第二topic标题的物流轨迹信息，将物流轨迹信息分别保存至预置数据库订单标识对应的记录中。每一订单有唯一的标识，可以将其保存在同一标识的记录中。

本实例中，(1)订单服务器通过kafka消息队列从当前物流订单数据中抓取设置有直接交互标识的物流订单信息，将信息发布至第一topic标题中；

(2)处理服务器消费发布到第一topic标题的物流订单信息，将其放置在预置数据库；

(3)物流轨迹服务器通过kafka消息队列从当前物流轨迹数据中抓取符合预设要求的物流轨迹信息，将信息发布至其匹配的第二topic标题中；

(4)处理服务器消费所述发布到第二topic标题的物流轨迹信息，将物流轨迹信息分别保存至所述预置数据库订单标识对应的记录中；

上述的四个进程是独立的进程，可以并行处理，提升处理的效率。

另外，预置数据库设置一总表，进程(2)中会修改该总表信息，进程(4)同样也会修改总表信息。这种方案是一种可以实现的方案。考虑到数据处理和存储的安全性，预置数据库进一步包括第一数据库、第二数据库和第二业务数据库，进程(2)的物流订单信息直接存储在第一数据库中，进程(4)的物流轨迹信息直接存储在第二数据库中，上述两个数据库仅是存储不做更改，这种保证获得的数据的不被修改性，同时也保证数据的安全性。定期利用第一数据库、第二数据库的数据更新至第二业务数据库，按订单标识进行保存。当第二业务为派单计费业务时，将第二业务数据库称为派单计费数据库。在本实例中，物流平台将物流网站、终端等信息是存在一个基本库中的，因此，在本实例的实操中，要将物流网站、终端等信息一并导入至派单计费数据库中，才能完成进行派单计费的第二业务处理。

因此，“将物流订单信息处理”之前还包括：读取当前的物流订单信息，从当前物流订单信息中解析出订单标识信息；通过订单标识获得匹配的所述订单物流轨迹信息，其至少包括该订单的签收信息。

“计算预置数据库中派单计费数据”进一步包括：

设置预置数据库进一步设置第一数据库、第二数据库和派单计费数据库；

处理服务器通过所述偏移量信息线程去访问适配的所述partition分区对应的订单信息，将物流订单信息放入在所述预置数据库的所述第一数据库；并且，处理服务器线程消费所述发布到所述第二topic标题的物流轨迹信息，将物流轨迹信息分别保存至所述预置数据库的第二数据库中；

定期或触发式将所述第一数据库和和第二数据库的同一订单标识数据更新至所述派单计费数据库；

从所述派单计费数据库中获得所述订单标识下的快递单接收时间，计算出所述快递单的送单时间，以计算出所述订单的送单费用信息。

“将物流订单信息处理”具体为包括：

处理服务器按照预先设置的订单派送计费模型，计算预置数据库中派单计费数据，进行付款信息推送。比如，签收时间-揽件时间＞签收时效。预先配置好相关费用的费率信息，费率信息包括类型、名称、基础费率、续费费率、费率上限等，费率单位为元/票或元/天/票，例如类型为付款项或收款项，名称为散单派费、派送网点延误罚款等，订单派送计费模型按照预先费率信息即可计算出该笔订单的付款信息。

根据付款信息生成付款账单，以使将费用支付至快递员对应的终端。对付款信息进行消息推送，将付款信息推送至费用结算终端，采用swoole+Redis实现实时数据推送。

根据付款信息生成付款账单，并进行费用支付。由费用结算终端进行费用结算，并由oms订单管理系统进行退费确认，若扣款状态为失败，展示补推按钮，点击可进行扣款信息补推，若扣款状态为成功，展示退费按钮，点击弹框提醒是否进行退费操作，确认后完成退费操作。

找到物流订单匹配的终端完成数据传输进一步包括：

找到物流订单匹配的终端；

利用处理服务器启动在主线程回调,开启swoole_websocket_server服务，将所述第二业务处理后的数据采用swoole+Redis实现实时数据推送，其具体为：

预先创建了manager进程和创建了worker进程；

监听定时器；

当监听到第二业务处理后的数据被计算后，worker进程使用swoole_server_task函数投递发送至对应的终端的Task；

当前的Task进程在调用onTask回调函数时会将进程状态切换为忙碌，这时将不再接收新的Task，当onTask函数返回时会将进程状态切换为空闲然后继续接收新的Task；

当worker进程投递的任务完成时，task进程会通过$ws->finish()方法将任务处理的结果发送给worker进程，以此基于异步事件驱动和协程的并行网络通信来完成第二业务处理后的数据及时传送至对应的终端。

实施例三

本实施例提供了一种基于kafka技术的订单数据处理设备。请参看图5，该基于kafka技术的订单数据处理设备500可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(central processing units，CPU)510(例如，一个或一个以上处理器)和存储器520，一个或一个以上存储应用程序533或数据532的存储介质530(例如一个或一个以上海量存储设备)。其中，存储器520和存储介质530可以是短暂存储或持久存储。存储在存储介质530的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对基于kafka技术的订单数据处理设备500中的一系列指令操作。

进一步，处理器510可以设置为与存储介质530通信，在基于kafka技术的订单数据处理设备备500上执行存储介质530中的一系列指令操作。

基于末端码的快递投递设备500还可以包括一个或一个以上电源540，一个或一个以上有线或无线的网络接口550，一个或一个以上输入输出接口560，和/或，一个或一个以上操作系统531，例如Windows Serve、Vista等等。

基于kafka技术的订单数据处理设备，除了OMS订单管理系统处理单元，还进一步包括：

Kafka集群交互单元：用于预先通过Kafka集群创建订单服务器作为消息生产方，并创造一用于存储直接交互订单记录的第一topic标题，直接处理数据交互的处理服务器为所述第一topic标题的消息订阅方；

发布单元：用于通过kafka消息队列从当前物流订单数据中抓取设置有所述直接交互标识的物流订单信息，将所述信息发布至所述第一topic标题中；

第二业务处理单元：用于消费所述发布到所述第一topic标题的物流订单信息，将所述物流订单信息进行第二业务处理后，找到所述物流订单匹配的终端完成数据传输。

第二业务处理单元可以独立与OMS订单管理系统处理单元，进行并发处理，由此提升整个处理的效率。

本领域技术人员可以理解，图5示出的基于kafka技术的订单数据处理设备并不构成对基于kafka技术的订单数据处理设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

本发明的另一实施例还提供了一种计算机可读存储介质。

该计算机可读存储介质可以为非易失性计算机可读存储介质，该计算机可读存储介质也可以为易失性计算机可读存储介质。该计算机可读存储介质中存储有指令，当该指令在计算机上运行时，使得计算机执行实施例一中的基于kafka技术的订单数据处理方法的步骤。

基于kafka技术的订单数据处理方法如果以程序指令的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件的形式体现出来，该计算机软件存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-onlymemory，ROM)、随机存取存储器(Random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

所属领域的技术人员可以清楚地了解到，为描述得方便和简洁，上述描述的系统及设备的具体执行的识别内容，可以参考前述方法实施例中的对应过程。

上面结合附图对本发明的实施方式作了详细说明，但是本发明并不限于上述实施方式。即使对本发明作出各种变化，倘若这些变化属于本发明权利要求及其等同技术的范围之内，则仍落入在本发明的保护范围之中。

Claims (10)

1.一种基于kafka技术的订单数据处理方法，其特征在于，包括：

预先通过Kafka集群创建订单服务器作为消息生产方，并创造一用于存储直接交互订单记录的第一topic标题，直接处理数据交互的处理服务器为所述第一topic标题的消息订阅方；

所述订单服务器通过kafka消息队列从当前物流订单数据中抓取设置有所述直接交互标识的物流订单信息，将所述信息发布至所述第一topic标题中；

所述处理服务器消费所述发布到所述第一topic标题的物流订单信息，将所述物流订单信息进行第二业务处理后，找到所述物流订单匹配的终端，完成数据传输。

2.如权利要求1所述的基于kafka技术的订单数据处理方法，其特征在于，所述处理服务器消费所述发布到所述第一topic标题的物流订单信息进一步包括：

所述处理服务器预先设置并维护偏移量信息，所述偏移量信息表明所述第一topic标题消费到的当前物流订单信息所在的partition分区的位置信息；

所述处理服务器在空闲状态下，通过所述偏移量信息去访问适配的所述partition分区对应的所述物流订单信息，并将所述物流订单信息依次放入预置数据库，后更新所述偏移量信息。

3.如权利要求2所述的基于kafka技术的订单数据处理方法，其特征在于，将所述物流订单信息进行第二业务处理之前还包括：

读取所述物流订单信息，从所述物流订单信息中解析出订单标识信息；

通过所述订单标识获得匹配的订单物流轨迹信息，其至少包括所述物流订单的签收信息。

4.如权利要求3所述的基于kafka技术的订单数据处理方法，其特征在于，通过所述订单标识获得匹配的订单物流轨迹信息进一步包括：

预先通过Kafka集群创建物流轨迹服务器作为消息生产方，并创造一用于存储物流轨迹记录的第二topic标题，所述处理服务器为所述第二topic的消息订阅方；

所述物流轨迹服务器通过kafka消息队列从当前物流轨迹数据中抓取符合预设要求的物流轨迹信息，将所述物流轨迹信息发布至所述第二topic标题中；

所述处理服务器消费所述发布到所述第二topic标题的物流轨迹信息，将所述物流轨迹信息保存至所述预置数据库所述订单标识对应的记录中。

5.如权利要求3或4所述的基于kafka技术的订单数据处理方法，其特征在于，将所述物流订单信息进行第二业务处理具体为包括：

所述处理服务器按照预先设置的订单派送计费模型，计算所述预置数据库中派单计费数据生成付款信息；

根据所述付款信息生成付款账单，以使将费用支付至所述物流订单匹配的终端。

6.如权利要求5所述的基于kafka技术的订单数据处理方法，其特征在于，计算所述预置数据库中派单计费数据进一步包括：

设置所述预置数据库进一步设置第一数据库、第二数据库和派单计费数据库；

所述处理服务器通过所述偏移量信息去访问适配的所述partition分区对应的所述物流订单信息，将所述物流订单信息放入在所述第一数据库；并且，所述处理服务器消费所述发布到所述第二topic标题的物流轨迹信息，将所述物流轨迹信息保存至所述第二数据库中；

定期或触发式将所述第一数据库和和所述第二数据库的同一订单标识数据更新至所述派单计费数据库；

从所述派单计费数据库中获得所述订单标识下的快递单接收时间，计算出所述快递单的送单时间，以计算出所述订单的送单费用信息。

7.如权利要求1所述的基于kafka技术的订单数据处理方法，其特征在于，找到所述物流订单匹配的终端完成数据传输进一步包括：

找到所述物流订单匹配的终端；

利用所述处理服务器启动在主线程回调,开启swoole_websocket_server服务，将所述第二业务处理后的数据采用swoole+Redis实现实时数据推送，其具体为：

预先创建了manager进程和创建了worker进程；

监听定时器；

当监听到所述第二业务处理后的数据被计算后，所述worker进程使用swoole_server_task函数投递发送至对应的终端的Task；

当前的Task进程在调用onTask回调函数时会将进程状态切换为忙碌，这时将不再接收新的Task，当onTask函数返回时会将进程状态切换为空闲然后继续接收新的Task；

当所述worker进程投递的任务完成时，所述task进程会通过$ws->finish()方法将任务处理的结果发送给所述worker进程，以此基于异步事件驱动和协程的并行网络通信来完成所述第二业务处理后的数据及时传送至对应的终端。

8.一种基于kafka技术的订单数据处理系统，其特征在于，包括：

Kafka集群：用于创建订单服务器作为消息生产方，并创造一用于存储直接交互订单记录的第一topic标题，直接处理数据交互的处理服务器为所述第一topic标题的消息订阅方；

订单服务器：用于通过kafka消息队列从当前物流订单数据中抓取设置有所述直接交互标识的物流订单信息，将所述信息发布至所述第一topic标题中；

处理服务器：用于消费所述发布到所述第一topic标题的物流订单信息，将所述物流订单信息进行第二业务处理后，找到所述物流订单匹配的终端完成数据传输。

9.一种基于kafka技术的订单数据处理设备，其特征在于，

Kafka集群交互单元：用于预先通过Kafka集群创建订单服务器作为消息生产方，并创造一用于存储直接交互订单记录的第一topic标题，直接处理数据交互的处理服务器为所述第一topic标题的消息订阅方；

发布单元：用于通过kafka消息队列从当前物流订单数据中抓取设置有所述直接交互标识的物流订单信息，将所述信息发布至所述第一topic标题中；

第二业务处理单元：用于消费所述发布到所述第一topic标题的物流订单信息，将所述物流订单信息进行第二业务处理后，找到所述物流订单匹配的终端完成数据传输。

10.一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-7中任意一项所述的基于kafka技术的订单数据处理方法。

Images