一种基于电商平台的交易订单数据优化处理方法

技术领域

本发明涉及一种基于电商平台的交易订单数据优化处理方法。

背景技术

随着信息网络技术的发展和人们生活方式的改变，在线购物群体越来越庞大，电商消费在总消费中的占比也越来越高，从事电商交易平台服务的互联网公司也越来越多。在电商交易平台搭建中，最重要的环节是打通交易链路，将用户需要购买的商品通过交易订单的形式进行全流程串联，引导用户完成下单、支付，督促供货商完成商品发货履约。在整个交易链路中，从用户选定商品提交订单到交易订单的创建生成和完成支付，需要处理库存、促销、价格、会员等很多资源，如何高效处理订单资源调度，提高平台接单效率是所有电商平台不断优化提升的方向。

通常，在一个电商平台中，由于商品参与的促销活动方式不同、商品类型不同、购物资格限制不同、支付方式不同、公司业务需求不同等都有可能导致商品下单时需要调度处理的资源不同。假设普通商品A下单时需要进行可售库存的锁定，完成支付后需要进行可售库存的扣减，而秒杀商品B下单时需要进行用户秒杀资格的查询、秒杀活动库存和商品可售库存的锁定，支付完成后需要进行秒杀资格、秒杀活动库存、商品可售库存的扣减。对于这样两种商品下单处理方式，常规的电商平台一般会分别对两种业务进行产品功能设计和代码开发，针对商品A、商品B的某个标签进行逻辑分支处理和代码实现，当有一种新业务模式出现时，需要重新针对新模式进行交易全流程的代码开发，开发完成测试通过上线后，新业务模式才能正式运行，这种传统的处理方式不仅实现周期长效率低，需要耗费大量的开发人力，而且在进行新模式新代码开发时，对老业务也容易产生影响。

发明内容

发明目的：本发明所要解决的技术问题是针对传统电商平台方案设计的局限性，提供一种交易订单的数据优化处理方法，可以适用于多种交易类型的订单数据处理以及不同订单数据处理模式的快速拓展。本发明具体提供一种基于电商平台的交易订单数据优化处理方法，包括如下步骤：

步骤1，对电商平台业务进行建模处理；

步骤2，建设基于流程引擎的交易订单数据处理模块，完成交易订单数据优化处理。

步骤1包括：

步骤1-1，将电商平台的交易订单接单流程拆分成三个数据处理步骤：提交订单后处理、支付前检查、支付成功后执行，遍历统计所有交易订单在每个步骤的数据处理中所需要调用的接口和数据处理形式；

步骤1-2，按照接口所处理的数据对应的资源类型不同，将每类被调用的接口定义成资源类型，每个资源类型的数据处理形式定义成资源事件，基于资源事件设计4种事件执行器用于处理资源数据；

步骤1-3，设计一种自定义注解，包含所有的资源类型、资源事件及对应的事件执行器，并在此基础上追加定义开始资源事件和结束资源事件，用于控制资源数据处理的开始和结束；

步骤1-4，基于电商平台的订单类型，得到订单类型对应的流程引擎，完成流程引擎表的建立。

本发明中，步骤1-2中，所述4种事件执行器分别是：

创建执行器，用于创建订单的主数据和订单行的数据；

检查执行器，用于检查当前订单需要处理的资源数据是否满使用条件；

锁定执行器，用于锁定当前订单需要处理的资源数据，防止被其他订单占用和消耗，针对锁定执行器需要配备锁定时长机制，用于标志该资源锁定时长；

核减执行器，用于将当前订单需要处理的资源数据基于该订单在数据库中进行扣减。

本发明中，步骤1-4包括：基于电商平台的订单类型，在提交订单后处理、支付前检查、支付成功后执行三个数据处理步骤拆分的基础上，分别将资源事件进行处理顺序串联，如提交订单后处理可以先检查库存资源、锁定积分资源、再锁定优惠券资源等，明确资源事件处理的起始点、中间点和结束点，并对资源事件进行标注(这个是一个现有的编程语言技术处理方法，对资源事件进行标注)，完成电商平台业务建模，得到订单类型对应的流程引擎；相同的资源事件和事件执行器能够在不同的流程引擎中重复使用处理相同类型的资源数据，如库存检查执行器可以在普通订单的“提交订单后处理”、秒杀订单的“支付成功后执行”等流程引擎中多次引用进行库存数据的检查，将两个以上订单类型的流程引擎存储到数据库中，从而完成流程引擎表的建立。

步骤2包括：

步骤2-1，建立资源池，用于存放所有的流程引擎；

步骤2-2，为流程引擎增加版本号管理；

步骤2-3，完成交易订单数据处理；

步骤2-4，设计回滚机制。

本发明中，步骤2-1包括：建立资源池，用于存放所有的流程引擎：在JVM中建立一个共享集合对象存放到堆中，在电商平台系统启动过程中把流程引擎表中所有标注过的资源事件根据订单类型进行递归，获取到所有资源事件的事件执行器，按照流程引擎中定义的资源事件处理顺序，将资源事件的事件执行器按顺序存放到当前的对象当中，以便在交易订单处理过程中无需懒加载，而采用饿汉式加载，增加交易并发量；

本发明中，步骤2-2包括：为流程引擎增加版本号管理，解决流程引擎更新问题：当资源池中的流程引擎进行编辑后，将编辑后的流程引擎存储到Redis(远程字典服务)中，并更新版本号，将新版本的流程引擎与老版本一起持久化到流程引擎表中进行存档；

本发明中，步骤2-3包括：交易订单处理时，根据下单入参传入的订单类型数据，到JVM中的资源池查找当前最新版本的流程引擎，将订单信息数据和流程引擎版本号进行绑定，获取流程引擎中所有的资源事件的事件执行器，并根据流程引擎中资源事件的排列顺序依次循环调用正向(doing)流程接口处理事件执行器，定义一张记录每笔订单流程引擎中各个事件执行器执行情况的执行快照表，每处理完成一个事件执行器均需要更新执行快照表状态，流程引擎中所有事件执行器均处理成功则视为所述交易订单对应步骤1-1中拆分的单个步骤处理成功，完成该步骤的交易订单数据处理；

本发明中，步骤2-4包括：设计回滚机制，用于绑定当前的事件执行器，判断执行过程中是否需要回滚，当一个事件执行器处理失败时，触发启动回滚机制的标志位，如果标志位为需要回滚，则把当前执行的事件重新逆向处理一遍；同时，在事件执行器外围增加异常捕获机制，当事件执行器内部发生异常后，就会向外抛出异常，被外围捕获住，一旦触发捕获，也会立刻调用当前事件执行器的回滚接口，并从执行快照表中获取到已经走过的流程集合，循环此流程，并依次调用callBack接口做回滚操作，全部回滚成功后依次更新执行快照表的回滚状态为成功，完成交易订单的数据回滚。

本发明中，步骤2-4还包括：当订单发生退货时，需要到流程引擎表中获取到该订单对应版本号的流程引擎，根据该流程引擎对应的资源事件进行事件执行器的逆向执行，完成交易订单的退货数据处理。

本发明具有以下优点：

1、资源数据的处理灵活：各项交易订单的资源事件独立拆分，每种资源的事件执行器原子化处理，再通过统一的流程引擎串联调度，既可以保证订单中各资源数据处理互不干扰各司其职，也可以使不同订单的同类资源数据处理独立运行。

2、支持已有业务快速调整：在一个电商平台中，做到每种订单类型的资源数据处理方式可组装，所有的资源类型、调度顺序、事件执行器都可以随时进行配置生效，记录版本号，无需代码修改和更新。

3、业务扩展便捷：当有新业务拓展，新的订单数据类型需要处理时，只需要对新业务的特性化资源进行原子化开发，单独封装针对特性化资源的数据处理方式，生成新的事件执行器，再进行配置成流程引擎即可上线使用，完成新订单的数据处理。

4、研发效率提升：研发效率提升主要体现在已有资源类型及资源事件的维护和新资源类型、资源事件、事件执行器的增加上，新增和维护只需要进行小范围资源的研发和测试即可，无需大范围的代码改动，无需全流程的代码测试。

5、界面化资源配置：不同类型的交易订单和不同的流程引擎可在同一个界面上配置，可以让平台运营人员随时灵活配置，减少操作和学习成本

附图说明

下面结合附图和具体实施方式对本发明做更进一步的具体说明，本发明的上述和/或其他方面的优点将会变得更加清楚。

图1是电商平台不同类型的订单资源数据处理拆解图。

图2是流程引擎表。

图3是版本管理流程。

图4是交易订单资源数据处理流程图。

图5是流程引擎详细处理步骤。

具体实施方式

以O2O电商平台为例，进行不同订单的资源数据处理拆解，枚举网店普通订单、门店订单、网店秒杀订单的资源数据处理和步骤如图1所示。根据电商平台自身的交易订单类型的枚举和分析，可以将需要处理的资源数据以及资源对应的处理事件进行归类。

结合订单处理的资源类型和资源事件，以及订单处理的三大节点(提交订单后处理、支付前检查、支付成功后处理)，将需要处理的资源数据整理成流程引擎表，如图2所示，可以调度每种订单类型需要处理的资源事件和事件执行器明细。

如图4所示，在基于流程引擎的交易订单数据处理模块中，用户下单时根据“订单类型”这个关键字获取到流程引擎，获取所有的资源事件执行器，在处理过程中如果有事件执行器处理失败则需要对当前订单流程做全局回滚，回滚需要获取执行快照表中的所有已执行过的事件执行器，依次回滚所有执行过的资源事件。

由于每家公司的业务特性、交易需求、用户体验度、促销活动玩法不一样，所以每家电商平台的交易订单类型和数据处理细节都有所不同。本发明提供一种通用的交易订单资源数据处理方法，主要分为两个部分，第一部分是对电商平台业务进行建模处理，第二部分是建设交易订单流程引擎模块，完成交易订单资源数据处理。

一、对电商平台业务进行建模处理：

1、订单类型和接单流程拆分

根据资源数据处理不同进行订单类型拆分，明确每种订单类型需要处理的资源数据和步骤。如图1所示，将交易订单的接单过程从用户角度进行三个大步骤的拆分：提交订单、去支付、完成支付(支付成功)。“提交订单”成功后需要处理相应的资源数据，所有资源数据处理成功则订单创建成功并处在待支付的订单状态；“去支付”为用户通过某个行为触发进入收银台的动作，为了确保用户付款成功后订单资源数据可以全部处理成功，在进入收银台前需要对资源数据进行预处理，去支付动作触发包含提交订单后马上进入收银台支付以及用户提交订单时终止支付后从订单列表发起的支付；“完成支付”即用户支付成功，此时系统接收到支付成功结果后需要对订单进行资源数据的处理。

对三个步骤中，需要调用的资源数据处理接口和数据处理形式进行遍历统计分析，归类后可以得到图1所示订单资源数据处理拆解图，可以看到，在提交订单时“1000-网店普通订单、1010-门店订单、1020-网店秒杀订单”均需要进行库存、抵扣积分、优惠券、订单生成等数据的处理，不同的是对于“1010-门店订单”来说，由于门店交易允许负卖(即库存小于0也可以继续交易)，无需做可售库存的检查，而对于“1020-网店秒杀订单”来说，由于秒杀活动是限量进行的，则增加了活动库存的检查和锁定。

2、资源事件和事件执行器的建立

按照接口所处理数据对应的资源类型不同，将每类被调用的接口定义成资源类型，每个资源类型的数据处理形式定义成资源事件，本发明基于资源事件设计了4种事件执行器用以处理资源数据，分别是：

创建执行器，用于创建订单的主数据和订单行的数据。此执行器的目的是生成订单主表(存储订单主要信息的数据库表)和订单行表(存储订单行项目信息的表)的映射数据库的XML(可扩展标记语言)文件、生成映射XML(可扩展标记语言)文件的DAO(数据访问对象)文件、以及创建接口和业务的实现类。当流程需要调用此执行器时，会根据业务的具体逻辑组织数据并包装成订单主表数据和订单行表数据，然后触发DAO(数据访问对象)操作并把所需要的数据新增到响应的订单主表和订单行表中；

检查执行器，用于检查当前订单需要处理的资源数据是否满使用条件；当此执行器被调用时，根据接口入参数据进行对应资源数据的条件达标性进行检查，如根据商品数据检查商品是否有库存，根据用券数据检查券是否可用等；

锁定执行器，用于锁定当前订单需要处理的资源数据，防止被其他订单占用和消耗，针对锁定执行器需要配备锁定时长机制，用于标志该资源锁定时长。一旦调用锁定执行器成功，则对应的资源数据需要与调用执行器的订单数据进行临时性绑定占用，实现方式为用资源事件入参主键作为Redis(远程字典服务)命名空间，将ttl(失效时间)设置为当前资源的预设时长，到达失效时间自动失效。如用户提交订单成功，则可以设置库存预锁，锁定时长60分钟，则代表库存为该用户的该订单保留时长60分钟，保留期间不被其他用户和其他订单占用，锁定失效后，此库存可以释放给其他用户和其他订单。

核减执行器，用于将当前订单需要处理的资源数据基于该订单在数据库中进行扣减，当调用此执行器时，所处理的资源数据将与订单做永久性绑定占用，如下单支付成功后的库存扣减等。

3、建立流程引擎表，完成业务建模

本发明设计了一种自定义注解，包含所有的资源类型、资源事件及对应的事件执行器，并在此基础上追加定义“开始”资源事件和“结束”资源事件，用于控制资源数据处理的开始和结束；

基于电商平台的订单类型，将资源事件进行处理顺序串联，如可以先处理库存资源、积分资源、再处理优惠券资源等，明确资源事件处理的起始点、中间点和结束点，并对这些资源事件进行标注，完成电商平台业务建模，得到了订单类型对应的流程引擎，如图2所示，“1000网店普通订单”在“提交订单后处理”时，定义的从“可售库存的库存检查”到“订单的生成/更新订单主数据”的全部资源事件处理就是一条完成的流程。流程引擎的作用是当交易订单在进行“提交订单后处理、支付前检查、支付成功后执行”任意步骤处理时，引导交易订单按照流程引擎中定义的资源事件处理顺序依次处理。相同的资源事件和事件执行器可以在不同的流程引擎中重复使用处理相同类型的资源数据，如库存检查执行器可以在普通订单的“提交订单后处理”、秒杀订单的“支付成功后执行”等流程引擎中多次引用进行库存数据的检查，将多个订单类型的流程引擎存储到数据库中即完成了流程引擎表的建立。

二、建设基于流程引擎的交易订单数据处理模块，完成交易订单数据优化处理，建设的详细步骤和过程说明如下：

本发明旨在建设一个可配置化、全链路解耦化、模块化的交易订单数据处理模块，基于流程引擎实现不同订单类型数据处理的灵活调度，通过流程引擎获取不同资源数据的事件执行器，进行交易订单的数据处理，整体实现流程如图4所示。

交易订单数据处理模块的内容包含初始化流程引擎、流程引擎的版本管理、基于流程引擎的交易订单数据处理。首先初始化所有流程引擎，获取所有资源事件执行器，建立资源池，然后建立流程引擎版本管理流程，最后用户下单触发基于流程引擎的交易订单数据处理，根据用户下单时传入的订单类型数据依次循环处理订单类型对应的资源事件的事件执行器，直到所有数据处理完成，执行完“结束”资源事件，过程中如果出现某个执行器处理失败，则需要进行数据回滚处理。

以下是详细处理步骤和要点：

1、资源池建立

建立资源池可以保证在交易订单数据处理过程中无需懒加载，而采用饿汉式加载，增加交易订单数据处理的并发量。资源池建立的方法是在JVM中开辟一个共享集合对象存放到堆中，在电商平台系统启动过程中把流程引擎表中所有标注过的资源事件根据订单类型进行递归，获取到所有资源事件的事件执行器，按照流程引擎中定义的资源事件处理顺序，将资源事件的事件执行器按顺序存放到当前的对象当中，

2、流程引擎版本号管理

由于交易订单数据处理流程引擎随时可编辑、可维护，为流程引擎增加版本号管理，可以解决流程引擎更新问题。如图3所示，当资源池中的流程引擎进行编辑后，将编辑后的流程引擎存储到Redis(远程字典服务)中，并更新版本号，将新版本的流程引擎与老版本一起持久化到流程引擎表中进行存档。

在一个电商平台系统中，即使是同一个类型的交易订单，在不同的阶段，需要处理的资源数据也是会变化的。所以需要对每一个流程引擎的版本号进行统一管理，保证对于某一个交易订单来说，从“提交订单后处理”开始，创建订单成功后，后续“支付前检查”、“支付成功后执行”以及退货都使用同一个版本的流程引擎，处理同一套资源数据。

如，订单号202010110001，订单类型为“1000普通订单”，在提交订单处理数据时使用的是普通订单版本号为V1.0的流程引擎，需要将该流程引擎版本号记录到订单中。若“1000普通订单”的流程引擎被修改了，则记录为新的版本号V1.1，修改保存后，后续提交创建的“1000普通订单”类型的订单都按照版本号V1.1定义的流程进行处理，而对于订单号202010110001，后续“支付前检查”、“支付成功后执行”以及退货时的资源数据处理均需要按照版本号V1.0处理。

3、基于流程引擎的交易订单数据处理

用户下单时，自动触发基于流程引擎的交易订单数据处理模块运作，将用户提交的用户信息数据、商品信息数据、订单类型数据等传入交易订单数据处理模块进行资源数据处理，全部资源数据处理成功则创建订单成功。同时，交易订单基于流程引擎创建订单时，需要将当时调用的流程引擎版本号绑定到订单上，后续该订单的所有处理过程均按照绑定的版本号进行。

如，对于订单号202010110001，由于订单“提交订单处理”时使用的是版本号V1.0的流程引擎，则该订单后续触发“支付前检查”、“支付成功后执行”，也应该继续按照版本号V1.0进行处理。若订单在资源数据处理过程中发生回滚也需要按照对应的版本号进行资源回滚，若订单发生退货，退货需要回退的资源也同样需要按照原订单流程引擎版本号进行处理，回滚资源数据。

流程引擎模块运作时，如图5所示，需要根据下单入参传入的订单类型数据，到JVM中的资源池查找当前最新版本的流程引擎，保存在Redis(远程字典服务)中，获取该流程引擎中所有的资源事件的事件执行器，并根据流程引擎中资源事件的排列顺序依次循环调用正向(doing)流程接口处理进行事件执行器的处理。定义一张记录每笔订单流程引擎中各个事件执行器执行情况的执行快照表，若某个事件执行器的数据处理结果为成功，则更新执行快照表中该执行器的成功状态，以此类推依次处理完所有的资源事件直到“结束”资源事件也处理成功则跳出该流程引擎的处理，视为流程引擎处理成功，完成交易订单数据处理。

若某个事件执行器的数据处理结果为失败，则更新执行器处理状态为失败，并获取所有之前执行成功过的事件执行器，根据回滚标志位，依次做数据回滚处理，直到所有成功的资源数据均回滚完成，此时代表此交易订单流程数据处理失败。

4、基于流程引擎的交易订单回滚及退货数据处理

流程引擎模块中的每个资源事件都需要增加是否需要回滚的标志位，用于绑定当前的事件执行器，判断执行过程中是否需要回滚，当某个事件执行器数据处理失败时，触发启动回滚机制的标志位，如果标志位为需要回滚，则会把当前执行的事件执行器数据重新逆向处理一遍。同时，在事件执行器外围增加异常捕获机制，当事件执行器内部发生异常后，就会向外抛出异常，被外围捕获住，一旦触发捕获，也会立刻调用当前事件执行器的数据回滚接口，并从执行快照表中获取到已经走过的流程集合，循环此流程，并依次调用callBack回滚接口做回滚操作，全部回滚成功后依次更新执行快照表的回滚状态为成功，完成交易订单的数据回滚。

与正向流程处理过程中的事件执行器数据处理异常后回滚的处理方式相同，当订单发生退货时，需要到流程引擎表中获取到该订单对应版本号的流程引擎，根据该流程引擎对应的资源事件进行事件执行器的逆向数据处理，所有事件执行器数据处理完成，即完成交易订单的退货数据处理。

本发明提供了一种基于电商平台的交易订单数据优化处理方法，具体实现该技术方案的方法和途径很多，以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。本实施例中未明确的各组成部分均可用现有技术加以实现。