CN107239952B - 一种数据处理的方法及装置 - Google Patents

Abstract

本申请公开了一种数据处理方法及装置，该方法首先接收用户发送的携带有待操作的多个对象的操作请求，确定每个对象对应的处理规则，根据每个对象对应的处理规则，生成包含有各对象共同的统一处理规则的配置文件，根据该配置文件中包含的统一处理规则，对每个对象进行数据处理。通过上述方法，计算设备在对每个对象进行处理的过程中，无需逐一获取每个对象的配置文件，只需要一次性生成并获取包含各对象共同的统一处理规则的配置文件即可，这样可有效的降低计算设备的运行负载，提高计算设备的运行效率。

Description

一种数据处理的方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种数据处理的方法及装置。

背景技术

随着计算机的不断发展，用户在通过计算机等设备进行操作时，执行一次操作可对多个不同的对象，如，卸载一个应用程序的过程中，需要对多个文件同时进行卸载。

在现有技术中，计算设备在接收到用户发送的携带有对多个对象的操作请求后，可能会调用多个线程，每个线程分别获取针对每个对象的配置文件，再从每个对象的配置文件中获取处理规则，并根据每个对象的处理规则，计算处理每个对象对应的业务处理数值，最后根据每个对象对应的业务处理数值，对每个对象分别进行处理。

但是，由于每个对象对应一个包含有处理规则的配置文件，因此，如果用户发送的携带有对多个对象的操作请求中所涉及到的对象较多，计算设备调用的线程则会增多，也就是说，每个线程分别获取每个对象的配置文件，并根据每个对象的配置文件中包含的处理规则，计算每个对象对应的业务处理数值，势必会造成计算设备的运行负载较大，降低计算设备的运行效率。

发明内容

本申请实施例提供一种数据处理方法及装置，用以解决现有技术中计算设备的运行负载较大，降低计算设备的运行效率的问题。

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

接收用户发送的操作请求，其中，所述操作请求中携带有待操作的多个对象；

确定每个对象对应的处理规则；

根据每个对象对应的处理规则，生成包含有各对象共同的统一处理规则的配置文件；

根据所述配置文件中包含的各对象共同的统一处理规则，对每个对象进行数据处理。

本申请实施例提供的一种优惠凭证的使用方法，所述方法包括：

接收用户发送的第一指定操作请求，其中，所述第一指定操作请求中携带有待操作的多个商品信息；

确定每个商品信息对应的优惠活动信息；

根据每个商品信息对应的优惠活动信息，生成各商品信息共同的聚合优惠凭证；

对所述用户使用所述聚合优惠凭证。

本申请实施例提供的一种数据处理的装置，所述装置包括：

接收模块，用于接收用户发送的操作请求，其中，所述操作请求中携带有待操作的多个对象；

确定模块，用于确定每个对象对应的处理规则；

生成模块，用于根据每个对象对应的处理规则，生成包含有各对象共同的统一处理规则的配置文件；

处理模块，用于根据所述配置文件中包含的各对象共同的统一处理规则，对每个对象进行数据处理。

本申请实施例提供的一种优惠凭证的使用装置，所述装置包括：

接收模块，用于接收用户发送的第一指定操作请求，其中，所述第一指定操作请求中携带有待操作的多个商品信息；

确定模块，用于确定每个商品信息对应的优惠活动信息；

生成模块，用于根据每个商品信息对应的优惠活动信息，生成各商品信息共同的聚合优惠凭证；

使用模块，用于对所述用户使用所述聚合优惠凭证。

本申请实施例提供一种数据处理的方法及装置，该方法首先接收用户发送的携带有待操作的多个对象的操作请求，确定每个对象对应的处理规则，根据每个对象对应的处理规则，生成包含有各对象共同的统一处理规则的配置文件，根据该配置文件中包含的统一处理规则，对每个对象进行数据处理。通过上述方法，计算设备在对每个对象进行处理的过程中，无需逐一获取每个对象的配置文件，只需要一次性生成并获取包含各对象共同的统一处理规则的配置文件即可，这样可有效的降低计算设备的运行负载，提高计算设备的运行效率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的数据处理的过程；

图2为本申请实施例提供的优惠凭证的使用的过程；

图3为本申请实施例提供的数据处理的装置结构示意图；

图4为本申请实施例提供的优惠凭证的使用的装置结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

图1为本申请实施例提供的数据处理的过程，具体包括以下步骤：

S101：接收用户发送的操作请求。

在实际应用中，用户在通过计算设备(如，计算机)进行操作时，执行一次操作可涉及多个不同的对象，所述对象可以是应用程序，可以是数据文件，也可以是业务。

在对多个不同的对象执行操作的过程中，首先要接收用户发送的操作请求，而接收该操作请求可以是由计算设备完成的，计算设备可以是计算机或服务器，也可以是具有数据处理功能的设备，所述操作请求中携带有待操作的多个对象。

S102：确定每个对象对应的处理规则。

S103：根据每个对象对应的处理规则，生成包含有各对象共同的统一处理规则的配置文件。

在本申请中，服务器在接收到用户发送的操作请求后，生成包含有各对象共同的统一处理规则的配置文件，所述配置文件中包含的统一处理规则适用各对象。

S104：根据所述配置文件中包含的各对象共同的统一处理规则，对每个对象进行数据处理。

在本申请中，服务器可根据该配置文件中包含的各对象共同的统一处理规则，确定处理每个对象的业务处理数值，再根据处理每个对象的业务处理数值，对每个对象进行数据处理，后续，服务器可将处理每个对象的业务处理数值、以及处理每个对象的业务处理数值之和提供给该用户，其中，所述业务处理数值可以是系统开销，如，用户在计算机上卸载一个应用程序(也就是说，执行一次卸载操作可涉及到对多个数据文件同时进行卸载)的过程中，计算机确定每个对象对应的处理规则，并生成包含有各对象共同的统一处理规则的配置文件，根据该配置文件中包含的统一处理规则，确定出每个对象的系统开销，再根据处理每个对象的系统开销，对每个对象进行数据处理。

通过上述方法，计算设备在对每个对象进行处理的过程中，无需逐一获取每个对象的配置文件，只需要一次性生成并获取包含各对象共同的统一处理规则的配置文件即可，这样可有效的降低计算设备的运行负载，提高计算设备的运行效率。

以上是本申请提供的数据处理的方法，而在实际应用中，用户有可能通过个人计算进行网上购物，而卖家为了更好的为用户提供服务，可能会为用户提供优惠凭证，而整个优惠凭证的使用过程如图2所示。

图2为本申请实施例提供的优惠凭证的使用过程，具体包括以下步骤：

S201：接收用户发送的第一指定操作请求。

在实际应用中，用户可能通过个人计算机在购物网站上购买所需的商品，而用户在购买商品的整个过程中，服务器首先接收用户发送的第一指定操作请求，并做出相应的响应，所述指定操作请求中携带有待操作的多个商品信息，所述指定操作请求可以是由用户发送的下单操作请求，所述下单操作指的是将购买的商品添加到购物车里，也可以是支付操作请求所述支付操作指的是对添加到购物车里的商品进行付款。

例如，用户A在某购物网站上购买所需的商品A、商品B以及商品C，假设服务器接收到用户A发送的携带有商品A的信息、商品B的信息以及商品C的信息的下单操作请求，并执行步骤S202。

S202：确定每个商品信息对应的优惠活动信息。

由于在实际应用中，卖家为了吸引更多的用户购买商品，以此提高商品的售卖量，因此，卖家通常为用户提供商品对应的优惠活动信息，并将优惠活动信息对应的优惠凭证提供给用户。

在本申请中，为了更好的为用户提供服务，用户自己无需预先去各卖家中领取优惠凭证，服务器在接收到用户发送的第一指定操作请求后，可自动在各卖家中查询，确定出待操作的多个商品信息中每个商品信息对应的优惠活动信息，所述优惠活动信息中包含有哪些商品优惠以及优惠的价格，还可包含卖家的信息。

延续上例，服务器在接收到用户A发送的携带有商品A的信息、商品B的信息以及商品C的信息的下单操作请求之后，自动去商品A、商品B以及商品C各自对应的卖家中查询，假设服务器确定出的各商品的优惠活动信息如表1所示：

商品信息	优惠活动信息
		商品A的信息	商品A优惠20元
商品B的信息	商品B优惠30元
		商品C的信息	商品C优惠10元

表1

S203：根据每个商品信息对应的优惠活动信息，生成各商品信息共同的聚合优惠凭证。

在本申请中，服务器在确定出每个商品信息对应的优惠活动信息后，直接根据各优惠活动信息，生成各商品信息共同的聚合优惠凭证。

在生成聚合优惠凭证的过程中，可以将各优惠活动信息中的差异信息添加到聚合优惠证上(如，各优惠活动信息对应的商品中出现了两次以上的同一个卖家的名称，则可以直接写一个卖家的名称即可)，也可以将各优惠活动信息完整的添加到聚合优惠凭证上，也就是说，所述聚合优惠凭证中包含了每个商品对应的优惠活动信息，后续每个商品都是根据该聚合优惠凭证进行优惠的。

延续上例，服务器在确定出如表1的各优惠活动信息后，根据各优惠活动信息，生成商品A的信息、商品B的信息以及商品C的信息共同的聚合优惠凭证。

S204：对所述用户使用所述聚合优惠凭证。

在本申请中，服务器在生成各商品信息共同的聚合优惠凭证后，可以直接根据聚合优惠凭证上的各优惠活动信息，确定每个商品对应的实际支付金额以及优惠金额，同时也可以确定出所有商品对应的实际支付总金额以及优惠总金额，并将确定出每个商品对应的实际支付金额以及优惠金额返回给用户，同时如果确定出所有商品对应的实际支付总金额以及优惠总金额后，也需要将所有商品对应的实际支付总金额以及优惠总金额返回给用户。

延续上例，假设服务器根据生成的聚合优惠凭证，确定出每个商品对应的实际支付金额、优惠金额以及所有商品对应的实际支付总金额和优惠总金额如表2所示：

商品名称	原始金额	优惠金额	实际支付金额
				商品A	100元	20元	80元
商品B	130元	30元	100元
				商品C	70元	10元	60元
各商品的总金额	300元	60元	240元

表2

通过上述方法，在整个优惠凭证的使用过程中，服务器无需去各卖家中领取商品对应的优惠凭证，也就是说，服务器无需多次去各卖家中领取并返回给用户商品对应的优惠凭证，只需要获取一次由各商品对应的优惠活动信息对应的聚合优惠凭证，并将该聚合优惠凭证返回给用户即可，这样在用户一次性购买大量具有优惠活动信息对应商品时，可有效的降低服务器的运行负载，并降低服务器的运行效率。

在实际应用中，用户在向服务器发送了下单操作请求后(也就是说，用户只是把需要购买的商品加入到了购物车里)，需要完成支付操作，在本申请中，整个支付过程如下所示：接收用户发送的携带有对多个商品信息的第二指定操作请求，判断聚合优惠凭证是否有效，若是，则确定每个商品对应的实际支付金额以及实际支付总金额，并将确定出的实际支付金额以及实际支付总金额返回给该用户，当接收到用户发送的确认信息时，对该实际支付总金额进行处理，若否，则确定出每个商品对应的原始支付金额以及原始支付总金额，并将确定出的原始支付金额以及原始支付总金额返回给该用户，当接收到用户发送的确认信息时，对该原始支付总金额进行处，其中，服务器在确定出每个商品对应的实际支付金额以及实际支付总金额的同时，也可以确定出每个商品对应的优惠金额以及优惠总金额，并将优惠金额以及优惠总金额返回给该用户，并且所述第二指定操作请求可以是支付操作请求，当然所述第二指定操作请求也可以是下单操作请求，即，用户在下单后，服务器可生成聚合优惠凭证，并直接判断聚合优惠凭证是否有效，根据判断结果进行相应处理。

延续上例，假设服务器接收到用户A发送的支付操作请求，判断由步骤S203生成的聚合优惠凭证是否有效，假设聚合优惠凭证是有效的，则直接确定每个商品对应的实际支付金额、实际支付总金额以及个商品对应的优惠金额以及优惠总金额如表3所示：

商品名称	原始金额	优惠金额	实际支付金额
				商品A	100元	20元	80元
商品B	130元	30元	100元
				商品C	70元	10元	60元
各商品的总金额	300元	60元	240元

表3

服务器将表3中的数据返回给用户A，当服务器接收到用户A发送的确认信息时，对表3中的实际支付总金额进行处理。

在此需要说明的是，由于下单操作与支付操作时两个完全独立的操作环节，也就是说，用户在向服务器发送下单操作请求后，只是将购买的商品加入了购物车，而用户可以在任何时间段内完成支付操作，由于聚合优惠凭证通常是有使用期限的，因此，这样有可能存在用户在超过聚会优惠凭证的使用期限以外的时间内进行支付操作的情况，因此，在支付操作的过程中，服务器需要判断聚合优惠凭证是否有效，也就是说，是否被使用过，是否过期。

进一步的，由于后续每个卖家都需要统计出哪些优惠凭证被用户使用过，哪些优惠凭证没有被用户使用过，而聚合优惠凭证上的优惠活动信息对应着不同的卖家，因此，在本申请中，服务器在执行完成支付操作后，可按照预设的时间(如，一小时)，根据聚合优惠凭证还原成每个活动信息对应的优惠凭证，并将还原后的各优惠凭证发送给相应的卖家。

在此需要说明的是，考虑到实际应用中，有可能存在有些用户在向服务器发送完下单操作请求后，一直没有再向服务器发送支付操作请求，从而导致聚合优惠凭证出现过期的情况，面对这种情况，在本申请中，服务器可按照预设的时间，同样根据聚合优惠凭证还原成每个活动信息对应的优惠凭证，并将还原后的各优惠凭证发送给相应的卖家。

另外，为了有效的区分出聚合优惠凭证的使用状态，在本申请中，可以预先在生成的聚合优惠凭证上添加状态标识，当聚合优惠凭证被用户使用过时，服务器需要将该聚合优惠凭证上表示未使用的状态标识修改成已使用的状态标识。

在实际应用中，卖家不仅仅需要统计出哪些优惠凭证被用户使用过，哪些优惠凭证没有被用户使用过，还需要统计出金额收入情况，因此，在本申请中，服务器在判断出聚合优惠凭证有效时，可针对每个商品信息，将该商品信息对应的优惠金额、实际支付金额返回给该商品信息对应的卖家。

在上述整个支付过程中，由于只存在一个聚合优惠凭证，因此，在判断优惠凭证是否有效时，只需要判断一次聚合优惠凭证是否有效即可，无需像现有技术中对每个商品信息对应的优惠凭证一个一个进行多次判断，这样可以有效降低了服务器的运行负载，提高了运行效率，与此同时，也极大的缩短了整个支付过程的处理时间，提高了支付效率。

考虑到实际应用中，有可能存在用户在购买完所需的商品后，由于某些因素造成用户对商品不满意，从而要求退款的情况，因此，本申请提供了退款的整个过程，具体的，接收用户发送的携带有待退款的多个商品信息的退款请求，根据该待退款的每个商品信息以及该待退款的每个商品信息对应的实际支付金额，确定每个待退款的商品信息对应的实际退款金额以及退款总金额，将该每个待退款的商品信息对应的实际退款金额以及退款总金额返回给用户。

延续上例，假设服务器接收到用户A发送的携带有商品A的信息、商品B的信息以及商品C的信息的退款请求，根据表3中每个商品信息对应的实际支付金额以及退款请求中携带的待退款的商品信息：商品A的信息、商品B的信息以及商品C的信息，确定每个待退款的商品信息对应的实际退款金额以及退款总金额如表4所示：

表4

服务器将如表4中的数据返回给用户A。

另外，由于后续卖家需要统计出金额收入情况，因此，在本申请中，服务器按照预设的时间，可针对每个待退款的商品信息，将该待退款的商品信息对应的实际退款金额返回给该待退款的商品信息对应的卖家。

在本申请中，服务器在接收到用户发送的退款请求后，不仅仅要将待退款的商品信息对应的实际退款金额返回给该待退款的商品信息对应的卖家，还需要将修改待退款的商品信息对应的聚合优惠凭证的状态标识，也就是将聚合优惠凭证的状态标识由使用过的状态标识修改成未使用过的状态标识。

在此需要说明的是，当用户的购买行为中存在退款的情况时，根据聚合优惠凭证还原成每个活动信息对应的优惠凭证这个过程，可以在服务器执行完成退款过程后执行，这样可以只需要修改一次优惠凭证的状态标识即可，无需像现有技术中对每个商品信息对应的优惠凭证一个一个进行多次修改，这样可以有效降低了服务器的运行负载，提高了运行效率，与此同时，也极大的缩短了整个退款过程的处理时间，提高了退款效率。

以上为本申请实施例提供的数据处理的方法以及优惠凭证的使用方法，基于同样的思路，本申请实施例提供两种装置，即，数据处理的装置，如图3所示，优惠凭证的使用的装置，如图4所示。

图3为本申请实施例提供的数据处理的装置结构示意图，所述装置包括：

接收模块301，用于接收用户发送的操作请求，其中，所述操作请求中携带有待操作的多个对象；

确定模块302，用于确定每个对象对应的处理规则；

生成模块303，用于根据每个对象对应的处理规则，生成包含有各对象共同的统一处理规则的配置文件；

处理模块304，用于根据所述配置文件中包含的各对象共同的统一处理规则，对每个对象进行数据处理。

所述处理模块304具体用于，根据所述统一处理规则，确定处理每个对象的业务处理数值，根据处理每个对象的业务处理数值，对每个对象进行数据处理。

所述装置还包括：

提供模块305，用于将处理每个对象的业务处理数值、以及处理每个对象的业务处理数值之和提供给所述用户。

图4为本申请实施例提供的优惠凭证的使用的装置结构示意图，所述装置包括：

接收模块401，用于接收用户发送的第一指定操作请求，其中，所述第一指定操作请求中携带有待操作的多个商品信息；

确定模块402，用于确定每个商品信息对应的优惠活动信息；

生成模块403，用于根据每个商品信息对应的优惠活动信息，生成各商品信息共同的聚合优惠凭证；

使用模块404，用于对所述用户使用所述聚合优惠凭证。

所述使用模块404具体用于，根据所述聚合优惠凭证上的各优惠活动信息，确定每个商品对应的实际支付金额以及优惠金额，将所述每个商品对应的实际支付金额以及优惠金额返回给所述用户。

所述装置还包括：

支付模块405，用于接收用户发送的对所述多个商品信息的第二指定操作请求，判断所述聚合优惠凭证是否有效，若是，则确定每个商品对应的实际支付金额以及实际支付总金额，并将所述实际支付金额以及实际支付总金额返回给所述用户，当接收到用户发送的确认信息时，对所述实际支付总金额进行处理，若否，则确定出每个商品对应的原始支付金额以及原始支付总金额，并将所述原始支付金额以及原始支付总金额返回给所述用户，当接收到用户发送的确认信息时，对所述原始支付总金额进行处理。

所述装置还包括：

支付还原模块406，用于当所述支付模块判断所述聚合优惠凭证有效时，针对每个商品信息，将该商品信息对应的优惠金额、实际支付金额返回给该商品信息对应的卖家。

所述装置还包括：

退款模块407，用于接收用户发送的退款请求，其中，所述退款请求中携带有待退款的多个商品信息，根据所述待退款的每个商品信息以及所述待退款的每个商品信息对应的实际支付金额，确定每个待退款的商品信息对应的实际退款金额以及退款总金额，将所述每个待退款的商品信息对应的实际退款金额以及退款总金额返回给用户。

所述装置还包括：

退款还原模块408，用于针对每个待退款的商品信息，将该待退款的商品信息对应的实际退款金额返回给该待退款的商品信息对应的卖家。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

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

Claims (14)

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

接收用户发送的操作请求，其中，所述操作请求中携带有待操作的多个对象；所述操作请求包括卸载应用程序的操作；所述多个对象包括所述应用程序对应的多个待卸载的数据文件；

确定每个对象对应的处理规则；

根据每个对象对应的处理规则，生成包含有各对象共同的统一处理规则的配置文件，所述配置文件中包含的统一处理规则适用于各对象；其中，无需逐一获取每个对象的配置文件；

根据所述配置文件中包含的各对象共同的统一处理规则，对每个对象进行数据处理；

其中，根据所述配置文件中包含的各对象共同的统一处理规则，对每个对象进行数据处理，具体包括：

根据所述配置文件中包含的各对象共同的统一处理规则，确定处理每个对象的业务处理数值；所述业务处理数值包括系统开销；

根据处理每个对象的业务处理数值，对每个对象进行数据处理。

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

将处理每个对象的业务处理数值、以及处理每个对象的业务处理数值之和提供给所述用户。

3.一种优惠凭证的使用方法，其特征在于，所述方法包括：

接收用户发送的第一指定操作请求，其中，所述第一指定操作请求中携带有待操作的多个商品信息；

确定每个商品信息对应的优惠活动信息；

根据每个商品信息对应的优惠活动信息，生成各商品信息共同的聚合优惠凭证，所述聚合优惠凭证中包含的共同优惠活动信息适用于各商品信息；其中，将各优惠活动信息中的差异信息添加到聚合优惠凭证；

对所述用户使用所述聚合优惠凭证；

其中，对所述用户使用所述聚合优惠凭证，具体包括：

判断所述聚合优惠凭证是否有效；

若是，根据所述聚合优惠凭证上的各优惠活动信息，确定每个商品对应的实际支付金额以及优惠金额；

将所述每个商品对应的实际支付金额以及优惠金额返回给所述用户。

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

接收用户发送的对所述多个商品信息的第二指定操作请求；

判断所述聚合优惠凭证是否有效；

若是，则确定每个商品对应的实际支付金额以及实际支付总金额，并将所述实际支付金额以及实际支付总金额返回给所述用户，当接收到用户发送的确认信息时，对所述实际支付总金额进行处理；

若否，则确定出每个商品对应的原始支付金额以及原始支付总金额，并将所述原始支付金额以及原始支付总金额返回给所述用户，当接收到用户发送的确认信息时，对所述原始支付总金额进行处理。

5.如权利要求4所述的方法，其特征在于，当判断所述聚合优惠凭证有效时，所述方法还包括：

针对每个商品信息，将该商品信息对应的优惠金额、实际支付金额返回给该商品信息对应的卖家。

6.如权利要求3所述的方法，其特征在于，所述方法还包括：

接收用户发送的退款请求，其中，所述退款请求中携带有待退款的多个商品信息；

根据所述待退款的每个商品信息以及所述待退款的每个商品信息对应的实际支付金额，确定每个待退款的商品信息对应的实际退款金额以及退款总金额；

将所述每个待退款的商品信息对应的实际退款金额以及退款总金额返回给用户。

7.如权利要求6所述的方法，其特征在于，所述方法还包括：

针对每个待退款的商品信息，将该待退款的商品信息对应的实际退款金额返回给该待退款的商品信息对应的卖家。

8.一种数据处理的装置，其特征在于，所述装置包括：

接收模块，用于接收用户发送的操作请求，其中，所述操作请求中携带有待操作的多个对象；所述操作请求包括卸载应用程序的操作；所述多个对象包括所述应用程序对应的多个待卸载的数据文件；

确定模块，用于确定每个对象对应的处理规则；

生成模块，用于根据每个对象对应的处理规则，生成包含有各对象共同的统一处理规则的配置文件，所述配置文件中包含的统一处理规则适用于各对象；其中，无需逐一获取每个对象的配置文件；

处理模块，用于根据所述配置文件中包含的各对象共同的统一处理规则，对每个对象进行数据处理；

其中，所述处理模块具体用于，根据所述统一处理规则，确定处理每个对象的业务处理数值，根据处理每个对象的业务处理数值，对每个对象进行数据处理；所述业务处理数值包括系统开销。

9.如权利要求8所述的装置，其特征在于，所述装置还包括：

提供模块，用于将处理每个对象的业务处理数值、以及处理每个对象的业务处理数值之和提供给所述用户。

10.一种优惠凭证的使用装置，其特征在于，所述装置包括：

接收模块，用于接收用户发送的第一指定操作请求，其中，所述第一指定操作请求中携带有待操作的多个商品信息；

确定模块，用于确定每个商品信息对应的优惠活动信息；

生成模块，用于根据每个商品信息对应的优惠活动信息，生成各商品信息共同的聚合优惠凭证，所述聚合优惠凭证中包含的共同优惠活动信息适用于各商品信息；其中，将各优惠活动信息中的差异信息添加到聚合优惠凭证；

使用模块，用于对所述用户使用所述聚合优惠凭证；

其中，所述使用模块具体用于，判断所述聚合优惠凭证是否有效；若是，根据所述聚合优惠凭证上的各优惠活动信息，确定每个商品对应的实际支付金额以及优惠金额，将所述每个商品对应的实际支付金额以及优惠金额返回给所述用户。

11.如权利要求10所述的装置，其特征在于，所述装置还包括：

支付模块，用于接收用户发送的对所述多个商品信息的第二指定操作请求，判断所述聚合优惠凭证是否有效，若是，则确定每个商品对应的实际支付金额以及实际支付总金额，并将所述实际支付金额以及实际支付总金额返回给所述用户，当接收到用户发送的确认信息时，对所述实际支付总金额进行处理，若否，则确定出每个商品对应的原始支付金额以及原始支付总金额，并将所述原始支付金额以及原始支付总金额返回给所述用户，当接收到用户发送的确认信息时，对所述原始支付总金额进行处理。

12.如权利要求11所述的装置，其特征在于，所述装置还包括：

支付还原模块，用于当所述支付模块判断所述聚合优惠凭证有效时，针对每个商品信息，将该商品信息对应的优惠金额、实际支付金额返回给该商品信息对应的卖家。

13.如权利要求10所述的装置，其特征在于，所述装置还包括：

退款模块，用于接收用户发送的退款请求，其中，所述退款请求中携带有待退款的多个商品信息，根据所述待退款的每个商品信息以及所述待退款的每个商品信息对应的实际支付金额，确定每个待退款的商品信息对应的实际退款金额以及退款总金额，将所述每个待退款的商品信息对应的实际退款金额以及退款总金额返回给用户。

14.如权利要求13所述的装置，其特征在于，所述装置还包括：

退款还原模块，用于针对每个待退款的商品信息，将该待退款的商品信息对应的实际退款金额返回给该待退款的商品信息对应的卖家。