技术领域
[0001] 本申请实施例涉及数据处理领域，尤其涉及一种数据处理方法和数据处理装置。
相关背景技术
[0002] 目前，与用户使用电子设备通信连接的设备服务器可以通过配置一个或多个任务实例，以便于在用户使用相关操作时，提供丰富的活动体验。
[0003] 例如，该一个或多个任务实例中可以包括对应于抽奖活动的任务实例。设备服务器可以根据用户在电子设备上输入的抽奖指示，根据任务实例的已配置项，确定为用户配发的奖励信息。
[0004] 现有的已配置项大多较为单一，已经无法适配到越来越复杂的任务配置需求。
具体实施方式
[0047] 目前，电子设备可以通过安装运行一个或多个应用程序，向用户提供不同的功能。
[0048] 示例性的，参考图1，电子设备中可以安装有商城应用、社区应用等。
[0049] 需要说明的是，本申请中，电子设备中安装的应用程序可以包括系统应用、三方应用。
[0050] 其中，系统应用可以包括如图1所示的商城应用、社区应用等。
[0051] 三方应用可以是第三方开发者为电子设备运行的操作系统适配开发的应用程序。按照不同类型划分，该三方应用可以包括游戏应用、购物应用、搜索应用等。
[0052] 以下示例中，以电子设备中安装的系统应用为例。
[0053] 电子设备在运行系统应用(如商城应用)时，可以向用户提供商城应用中商品选购的相关功能。此外，商城应用还可以向用户提供抽奖功能，以便于提升用户粘性，优化用户购物体验。一般的，该抽奖功能可以是电子设备中的应用程序与相应的服务器互相配合实现的。
[0054] 示例性的，继续参考图1。以商城应用对应的服务器为商城应用对应的设备服务器为例。
[0055] 在设备服务器中可以配置有抽奖活动相关逻辑。例如，该抽奖活动相关逻辑可以配置在抽奖模块中。
[0056] 在一些实现中，抽奖模块中可以配置有一个或多个抽奖活动对应的任务实例。在如图1的实例中，该一个或多个任务实例可以包括任务实例1、任务实例2等。
[0057] 对于其中的一个任务实例(如任务实例1或任务实例2)，可以配置有对应的抽奖算法逻辑和对应的奖池信息。
[0058] 例如，任务实例1中可以包括抽奖算法逻辑1以及奖池信息1。
[0059] 在奖池信息中可以包括两个或多个不同的奖励信息，以便于根据抽奖算法逻辑，为用户配置多种奖励信息。
[0060] 作为一种示例，参考图2，为电子设备和设备服务器之间的交互示意图。通过该如图2所示的方案实现，就可以实现一次抽奖过程的逻辑。
[0061] 如图2所示，电子设备可以接收用户的操作201。
[0062] 如上述图1的示例说明，电子设备可以在界面上显示各个应用程序的图标。例如，商城应用的图标、社区应用的图标等。本示例中，该操作201可以包括用户点击商城应用的图标的操作。
[0063] 对应的，电子设备可以向设备服务器发送操作信息1。
[0064] 示例性的，操作信息1可以是电子设备根据用户输入的操作201生成的。该操作信息1可以用于请求商城应用的界面信息。例如，该界面信息可以包括如图2所示的界面202的界面信息。
[0065] 如图2所示，设备服务器可以根据操作信息1，以及当前配置，确定在商城应用中显示抽奖界面。接着，设备服务器可以向电子设备发送抽奖界面信息。
[0066] 电子设备可以根据接收到的抽奖界面信息，显示界面202。
[0067] 以设备服务器根据操作信息1，确定用户参与任务实例1对应的抽奖活动为例。
[0068] 在该示例中，界面202可以包括该任务实例1中配置的奖池信息1中的各个奖励。例如，该奖池信息1中可以包括奖励信息1、奖励信息2、奖励信息3以及奖励信息4。对应的，电子设备在界面202上就可以分别对应显示奖励1、奖励2、奖励3以及奖励4的标识。
[0069] 界面202中还可以包括按钮203。该按钮203可以用于接收用户的抽奖指示。
[0070] 以用户对按钮203输入点击操作205为例。对应的，电子设备可以生成操作信息2。
[0071] 该操作信息2可以表示用户输入了对该任务实例1的抽奖操作。
[0072] 在一些实施例中，该操作信息2可以包括任务实例1的任务编码。其中，任务编码唯一对应于用户指示参加的抽奖活动。
[0073] 在一些实施例中，该操作信息2可以包括用户标识。该用户标识可以用于唯一对应当前用户。
[0074] 示例性的，在一些实现中，用户标识可以包括电子设备的信息，如国际移动设备识别码(International Mobile Equipment Identity，IMEI)等。在另一些实现中，用户标识可以包括以下中的至少一项：国际移动用户识别号(International Mobile Subscriber Identification Number，IMSI)、用户当前登录到商城应用的账号信息、user ID等用户的信息。
[0075] 电子设备可以将该操作信息2发送给设备服务器。
[0076] 在本申请中，电子设备生成操作信息2，以及向设备服务器发送该包括用户标识的操作信息2的过程，可以是在用户授权后执行的。
[0077] 对应的，设备服务器可以根据操作信息2，触发执行任务实例1中的抽奖逻辑的判断。
[0078] 例如，设备服务器可以根据任务编码，确定用户要参加的抽奖活动的任务实例。设备服务器还可以根据该任务实例的抽奖算法逻辑，确定为用户配置的奖励信息。
[0079] 以确定为用户配置奖励信息1为例。设备服务器可以将奖励信息1发送给电子设备。这样，电子设备就可以在界面上显示“已获取奖励1”对应的界面204。
[0080] 由此，就可以实现对用户参加抽奖活动的设备交互逻辑。
[0081] 在目前的设备服务器配置中，接收到操作信息2之后，确定奖励信息的逻辑配置大多较为简单。例如，接收到操作信息2后，根据随机抽取逻辑，为用户配置奖励信息。由此只能实现较为单一的抽奖活动配置。这样可能会出现某一种或某几种奖励信息被大量配置导致的配发失败等问题。目前的逻辑实现也无法支持较为复杂的奖励配置方式。
[0082] 基于此，本申请实施例提供一种数据处理方法，通过在设备服务器中配置多维度奖励信息的判断逻辑，实现多维度抽奖活动的配置支持。从而满足目前越来越复杂的奖励抽取场景的要求。在一些实施例中，本申请提供的方案还可以支持限量配置的判断逻辑，以便于不同奖励信息的合理配发。
[0083] 以下结合附图对本申请实施例提供的方案进行详细说明。
[0084] 本申请实施例提供的方案可以应用于设备服务器中。
[0085] 参考图1的说明，设备服务器可以是与用户的电子设备通信连接的服务器。其中，用户在使用电子设备的过程中，可以通过在电子设备上的授权操作，授权设备服务器获取电子设备发送的相关信息。例如，该相关信息可以包括用户的操作信息等。
[0086] 对应的，设备服务器可以根据来自电子设备的相关信息，向电子设备以及使用电子设备的用户提供奖励抽取服务。
[0087] 在一些实现中，设备服务器中可以配置有一个或多个功能模块，以便于该对一个或多个功能模块互相配合，实现上述奖励抽取服务的逻辑实现。
[0088] 作为一种示例，参考图3，为本申请实施例提供的一种设备服务器的组成示意图。
[0089] 需要说明的是，如图3的示例仅为一种实现，并不构成对本申请实施例涉及设备服务器的任何限定。
[0090] 如图3所示，设备服务器中可以配置有一个或多个任务实例。设备服务器还可以配置有概率判断模块，限量判断模块，以及奖励配置模块。
[0091] 以下分别进行说明。
[0092] 每个任务实例可以对应于一项奖励抽取服务。或者说，一个任务实例可以对应于一个抽奖活动。例如，该一个或多个任务实例可以包括任务实例1～n。n为大于或等于1的整数。在n为1的情况下，则设备服务器中可以配置一个任务实例。
[0093] 对于每个任务实例而言，都可以配置有一个或多个对应的奖励信息。这样，在该任务实例对应场景下，就可以根据后续说明中的逻辑，向不同用户/同一用户的不同操作配置多样化的奖励信息。
[0094] 以该n个任务实例中包括任务实例A为例。
[0095] 如图3所示，任务实例A中可以配置有奖励信息1，奖励信息2，奖励信息3，以及奖励信息4。
[0096] 作为一种示例，参考图4，每个奖励信息都可以包括对应的奖励内容信息，类型标识等信息。在一些实现中，奖励信息还可以包括配置该奖励信息的概率信息。
[0097] 其中，奖励内容信息可以包括以下中的至少一项：奖励信息序号，奖励信息编码，奖励信息名称，奖励信息类型，奖励信息图片，奖励信息对应奖品的序号，奖励信息对应奖品的名称，奖励信息对应奖品的价值信息，奖励信息对应奖品的数量，奖励信息对应奖品的编码。
[0098] 作为一种示例，以下表1提供了一种奖励内容信息的配置示意。其中，奖品也即奖励信息对应的奖品。
[0099] 表1
[0100]
[0101] 这样，在确定配发某一奖励(如图3所示的奖励信息1、奖励信息2、奖励信息3等)后，设备服务器就可以将奖励内容信息发送给对应的电子设备(或电子设备对应的用户账号)。
[0102] 本示例中，奖励信息的类型标识可以用于标示对应奖励信息的类型。一个奖励信息可以对应配置有一个类型标识。或者，一个奖励信息也可以同时配置有两个或多个类型标识。
[0103] 在本申请中，奖励信息的类型可以包括：第一类型，第二类型，以及第三类型。在另一些实现中，第一类型也可称为兜底类型。第二类型也可称为必得类型。第三类型也可称为限量类型。相应的，第一类型的奖励信息也即兜底奖励，第二类型的奖励信息也即必得奖励，第三类型的奖励信息也即限量奖励。
[0104] 对应到类型标识的实现，第一类型对应的类型标识可以为第一标识，第二类型对应的类型标识可以为第二标识，第三类型对应的类型标识可以为第三标识。
[0105] 示例性的，第一类型的奖励信息可以是配置概率最高的奖励信息。在另一些实现中，第一类型的奖励信息也可以用于向异常用户的奖励配置。在另一些实现中，第一类型的奖励信息也可以用于在不符合第二类型奖励信息或第三类型奖励信息的配发条件的情况下，向用户配发。
[0106] 第二类型的奖励信息可以对应配置有次数阈值。该次数阈值可以是相同用户标识输入的操作次数的阈值。以第一类型的奖励信息的次数阈值为m为例。设备服务器可以在接收到来自同一个用户标识的操作次数达到m的情况下，为该用户配发对应的第二类型的奖励信息。
[0107] 第三类型的奖励信息可以对应配置有限量信息。本申请实施例中，限量信息也可以称为限量配置。在本申请的一些实施例中，该限量信息可以是多维度的配置阈值，如包括以下中的至少一个维度：单个用户维度、多用户(如总用户)维度、年维度、月维度、日维度、时维度、分维度、秒维度等。该限量信息可以用于控制对应奖励信息在各个维度下的配置数量，以使得在各个维度下，对应奖励信息都的配置数量都可以维持在相对均衡的状态。
[0108] 作为一种示例，以下表2提供了一种第三类型的奖励信息的多维度限量信息配置示例。
[0109] 表2
[0110] 总 每年 每月 每日 每时 每分 每秒
单用户 0 0 0 1 0 0 0
总用户 45 0 0 3 0 0 0
已发放 20 0 0 0 0 0 0
[0111] 在表2的示例中，该第三类型的奖励信息可以配置有单用户维度、总用户维度，以及日维度的限量信息。其中，配置为“0”的项目则对应于未配置，没有对应的限制。
[0112] 基于该表2的配置，该第三类型的奖励信息，每日每个用户最大可配置1次；每日为所有用户配置的最大次数为3次；当前任务实例运行的完整周期中，向所有用户配置的次数不超过45次。
[0113] 可以理解的是，表2仅为一种示例。在其他实现中，各个第三类型的奖励信息还可以基于如表2所示的配置示例，进行更多或更少维度的限量信息的配置。
[0114] 在一些实施例中，每个第三类型的奖励信息可以携带有相应的地址信息。该地址信息可以包括存储该奖励信息对应配置的限量信息的地址。设备服务器在想要向用户配置该第三类型的奖励信息的情况下，则可以通过对应的地址，获取对应配置的限量信息。进而据此确定此次配置是否在限量信息的限定范围内，进而实现该奖励信息向用户的配置。
[0115] 需要说明的是，在表2的示例中，与限量信息一同存储的，还可以包括该奖励信息的已发放记录。该已发放记录也可以是与已配置的限量信息的维度相对应的。
[0116] 例如，如表2所示，该奖励信息的已发放记录可以表示：当前奖励信息已经配发20次。而当前用户尚未配置过该奖励信息。这样，基于如表2所示的信息，设备服务器就可以在想要为当前用户配置对应奖励信息的情况下，确定此次配置行为不会超出各个维度的限量信息，相应的执行对该用户的奖励信息的配发。
[0117] 在本申请的另一些实施例中，已发放记录也可以存储在设备服务器的其他位置，与如表2中的限量信息相关信息分离。
[0118] 可以理解的是，在任务实例配置创建后，该限量信息可以为已配置的固定值。因此，该限量信息可以与任务实例的其他已配置的固定值(如奖励内容信息等)一同存储。
[0119] 对应的，已发放记录可以是与用户操作相关的动态信息，该已发放记录可以由设备服务器根据接收到的操作信息进行维护更新。
[0120] 在本申请的一些实施例中，设备服务器中可以配置有已发放记录对应表，用于存储各个用户标识(如user ID)、任务实例、已配置信息的对应关系。
[0121] 作为一种示例，以下表3提供了一种已发放记录对应表的示例。
[0122] 表3
[0123]
[0124] 如表3所示，以启用的任务实例的任务编码分别为任务编码1、任务编码2等。
[0125] 设备服务器可以在已发放记录对应表中，按照不同user ID，存储各个用户已参与任务实例，以及在各个任务实例中的已配置信息。其中，已配置信息可以包括该对应任务实例中，为当前用户已配发的奖励信息的奖励编码、已发放次数(或已领取次数)等。需要指出的是，在该奖励信息配置有多个维度的限量配置时，该已配置信息中的已发放次数可以包括各个维度下的已领取次数。
[0126] 例如，在表3的示例中，user ID为ID 1的用户，参与任务编码1的任务实例时，设备服务器已经为该用户发放了已配置信息1‑1对应的奖励信息。类似的，user ID为ID 1的用户，参与任务编码2的任务实例时，设备服务器已经为该用户发放了已配置信息1‑2对应的奖励信息。
[0127] 此外，在表3中还可以包括其他用户(如user ID为ID 2的用户)参与的任务实例，以及已配置信息的对应关系。
[0128] 设备服务器可以在每次为用户配置奖励信息后，更新已发放记录对应表，以便于根据已发放记录对应表准确判断下次奖励信息的配置。
[0129] 作为表3所示已发放记录对应表的另一种实现，已发放记录对应表中也可以按照任务编码‑user ID‑已配置信息对应的逻辑顺序，依次进行记录。
[0130] 示例性的，参考图4，为本申请实施例提供的又一种已发放记录对应表的示意。
[0131] 表4
[0132]
[0133] 基于该表4的实现，设备服务器就可以在根据操作信息确定任务编码后，获取该任务编码对应的各个用户(如不同user ID)的已配置信息。
[0134] 例如，设备服务器在确定当前操作对应于任务编码1的任务实例的情况下，可以基于表4，确定user ID为ID 1的用户对应各个奖励信息的配置情况为已配置信息1‑1。又如设备服务器还可以确定user ID为ID 1的用户对应各个奖励信息的配置情况为已配置信息2‑1。其他类似。
[0135] 本申请对已发放记录对应表的具体实现形式不做限定。
[0136] 该如表3或表4的示例中，设备服务器可以将多个用户、多个任务实例，以及对应的奖励信息的已配置信息集中管理维护。这样，每当接收到一个操作信息的情况下，设备服务器就可以调用该已发放记录对应表，准确确定此次操作信息对应配置的奖励信息。
[0137] 在另一些实施例中，设备服务器也可以为每个用户或者每个任务实例分别建立已发放记录对应表，由此实现不同用户或者不同任务实例的奖励信息的配置情况的分离。由此可以避免集中维护的已发放记录对应表出现异常，导致所有用户或任务实例的奖励配置情况均无法查询的问题。
[0138] 在具体实现过程中，可以采取上述实施例中任一种提供的实现，进行已配置信息的存储维护。
[0139] 在本申请的另一些实施例中，任务实例中的一个或多个奖励信息中的部分或全部奖励信息，还可以包括对应配置的概率信息。也就是说，可能存在奖励信息未被配置概率信息。那么该奖励信息可以根据对应的发放条件进行配发的判断。
[0140] 该概率信息可以用于表示对应奖励信息的抽取概率。本申请中，对于配置有概率信息的奖励信息而言，所有配置有概率信息之和可以不超过1。
[0141] 作为一种示例，以任务实例A为例。以下表5提供了任务实例A中，各个奖励信息的类型标识，以及概率信息的配置示意。
[0142] 表5
[0143] 第一标识 第二标识 第三标识 概率信息奖励信息1 1 0 0 0.7
奖励信息2 0 1 0 NA
奖励信息3 0 0 1 0.2
奖励信息4 0 0 1 0.1
[0144] 在如表5所示的示例中，各个奖励信息都可以配置有第一标识、第二标识、和/或第三标识。其中，该奖励信息为与对应标识相应类型时，对应标识配置为1。对应的，奖励信息与对应标识不相应时，对应标识配置为0。
[0145] 在表5所示的示例中，以任一奖励信息配置有一个类型标识为例。也即，任一奖励信息可以为第一类型的奖励信息，或者第二类型的奖励信息，或者第三类型的奖励信息。
[0146] 以表5所示的配置为例。奖励信息1可以为第一类型的奖励信息(如兜底奖励)。奖励信息2可以为第二类型的奖励信息(如必得奖励)。奖励信息3和奖励信息4可以为第三类型的奖励信息(如限量奖励)。
[0147] 需要说明的是，在本申请的另一些实施例中，同一个奖励信息可以具有两种或更多类型特征。
[0148] 例如，同一个奖励信息可以同时配置有第一标识以及第三标识。这样，该奖励信息可以对应于第一类型的奖励信息，同时也配置有第三类型对应的限量配置。
[0149] 又如，同一个奖励信息可以同时配置有第二标识以及第三标识。这样，该奖励信息可以对应于第二类型的奖励信息，同时也配置有第三类型对应的限量配置。
[0150] 示例性的，参考表6，为另一种实现中，任务实例A的各个奖励信息的类型标识，以及概率信息的配置示意。
[0151] 表6
[0152] 第一标识 第二标识 第三标识 概率信息
奖励信息1 1 0 0 0.7
奖励信息2 0 1 1 NA
奖励信息3 0 0 1 0.2
奖励信息4 0 0 1 0.1
[0153] 在该表6的示例中，奖励信息2可以配置有第二标识，该奖励信息2还可配置有第三标识。由此，该奖励信息2的类型可以为第二类型以及第三类型。
[0154] 这样，设备服务器在根据第二类型的判断机制，在同一个用户(如相同user ID)对同一个任务实例的操作次数达到m的情况下，确定满足第二类型对应的配发条件。
[0155] 此外，由于该奖励信息2还配置有第三标识，因此设备服务器在配发该奖励信息2之前，还需确认该奖励信息2的已配发信息满足限量信息。即确定满足第三类型对应的配发条件。
[0156] 例如，在该奖励信息2的已配发信息符合对应限量信息的条件的情况下，则确定奖励信息2满足第三类型对应的配发条件。
[0157] 由此，设备服务器可以在奖励信息2同时满足第二类型的配发条件，以及第三类型的配发条件的情况下，为当前用户标识对应的用户配置奖励信息2。
[0158] 需要说明的是，在本本申请实施例中，概率信息的配置与类型标识并没有固定的绑定关系。概率信息的配置可以是在不同具体任务实例中灵活配置的。
[0159] 结合前述说明，在表5或表6的示例中，奖励信息1、奖励信息3以及奖励信息4也可以配置有概率信息。比如，奖励信息1的概率信息为0.7；奖励信息3的概率信息为0.2；奖励信息4的概率信息为0.1。
[0160] 可以看到，所有奖励信息的概率信息之和可以为1。各个奖励信息的概率信息可以用于后续判断为当前用户配置其中的奖励信息之一。
[0161] 此外，该示例中，奖励信息2可以未配置概率信息。这样，设备服务器可以根据配置的逻辑，在确定需要为用户配置必得奖励的情况下，根据奖励信息2的类型标识为第二标识，向用户配置该奖励信息2。该具体配置的逻辑示例将在后续详细说明。
[0162] 如表5的示例中，是以奖励信息1(如兜底奖励)配置有概率信息为例。在另一些实施例中，奖励信息1也可以不配置概率信息。对应的，限量奖励可以配置有概率信息。
[0163] 比如，如表7所示。
[0164] 表7
[0165] 第一标识 第二标识 第三标识 概率信息
奖励信息1 1 0 0 NA
奖励信息2 0 1 0 NA
奖励信息3 0 0 1 0.7
奖励信息4 0 0 1 0.3
[0166] 在该表7的示例中，奖励信息1(如兜底奖励)和奖励信息2(如必得奖励)可以未配置概率信息。奖励信息3和奖励信息4(如限量奖励)可以配置有概率信息。比如，奖励信息3的概率信息配置为0.7，奖励信息4的概率信息配置为0.3。
[0167] 这样，设备服务器可以根据配置的逻辑，在确定需要为用户配置兜底奖励的情况下，根据奖励信息1的类型标识为第一标识，向用户配置该奖励信息1。设备服务器可以根据配置的逻辑，在确定需要为用户配置必得奖励的情况下，根据奖励信息2的类型标识为第二标识，向用户配置该奖励信息2。
[0168] 上述对设备服务器中的任务实例进行了具体说明。
[0169] 如图3所示，在设备服务器中还可以配置有概率判断模块、限量判断模块，以及奖励配置模块。
[0170] 在本申请的一些实施例中，概率判断模块以及限量判断模块可以用于根据预配置在设备服务器中的逻辑，执行本申请实施例提供的数据处理方法，基于各个奖励信息配置的概率信息，初步判断为当前用户配置的奖励信息。
[0171] 作为一种示例，参考图5，概率判断模块可以通过该如图5所示的逻辑实现，根据各个奖励信息的概率信息确定需要配发的奖励信息。
[0172] 在该示例中，以当前运行的任务实例为任务实例A，任务实例A中配置有奖励A、奖励B以及奖励C，奖励A的概率信息配置为10％，奖励B的概率信息配置为20％，奖励C的概率信息配置为70％为例。
[0173] 由于所有奖励的概率之和为1，在本示例中，概率判断模块可以生成长度为100的线段。该线段可以根据各个奖励信息的概率信息，将对应长度区间配置为各个奖励信息。
[0174] 例如，如图5所示，奖励A的概率为10％，则概率判断模块可以将该长度100的线段中，长度区间为[1,10)的长度为10的部分线段对应配置为奖励A。类似的，长度区间为[10,30)的长度为20的部分线段对应配置为奖励B，长度区间为[30,100)的长度为70的部分线段对应配置为奖励C。
[0175] 接着，概率判断模块可以生成随机数。根据随机数所在长度区间，确定此次根据概率判断的奖励信息配发结果。
[0176] 例如，以生成随机数为66为例。该随机数落在长度区间[30,100)中。对应的，概率判断模块可以确定此次配发奖励C。
[0177] 在本申请的另一些实施例中，在待配置信息配置有第三标识，也即该确定的待配置信息配置有限量配置的情况下，则限量判断模块可以根据对应的限量配置，确定该待配置是否可以配发。
[0178] 由此，设备服务器可以根据待配置信息，以及限量判断模块的判断结果，综合确定为当前用户配置的奖励信息。也即确定当前用户的抽奖结果。
[0179] 在设备服务器中还可以包括奖励配置模块。该奖励配置模块可以用于确定需要配发的奖励信息后，向操作请求中携带的用户标识配发该奖励信息，例如向该用户标识对应的电子设备发送奖励信息中的奖励内容信息。
[0180] 在本申请的一些实施例中，该如图3所示的设备服务器可以应用于如图1所示的场景下。也即，该设备服务器可以与用户的电子设备通信连接，以便于在接收到用户输入的操作(如图2所示的对按钮203的操作)后，通过上述各个模块的逻辑实现，确定为用户配置的奖励信息。进一步的，设备服务器可以将为用户的奖励信息，通过奖励配置模块发送给用户的电子设备，实现奖品信息的配发。
[0181] 需要说明的是，在具体实现中，本申请实施例涉及的电子设备可以具有多种不同的实现。
[0182] 示例性的，本申请实施例中的电子设备可以包括手机、可折叠电子设备、平板电脑、桌面型计算机、膝上型计算机、手持计算机、笔记本电脑、超级移动个人计算机(ultra‑mobile personal computer，UMPC)、上网本、蜂窝电话、个人数字助理(personal digital assistant，PDA)、增强现实(augmented reality，AR)设备、虚拟现实(virtual reality，VR)设备、人工智能(artificial intelligence,AI)设备、可穿戴式设备、车载设备、智能家居设备、或智慧城市设备中的至少一种。
[0183] 以下对本申请实施例提供的数据处理方法的进行详细说明。
[0184] 作为一种可能的实现，参考图6，为本申请实施例提供的一种奖励信息的确定方法的流程示意图。该方法可以应用于设备服务器中。该设备服务器可以具有前述如图3的组成。如图6所示，该方案可以包括：
[0185] S601、获取第一操作信息。
[0186] 示例性的，该第一操作信息可以是电子设备接收到用户输入的指示进行抽奖的第一操作后生成并发送给设备服务器的。
[0187] 结合图2的说明，作为一种可能的实现，该第一操作可以包括操作205。对应的，第一操作信息可以对应于如图2中的操作信息2。
[0188] 例如，本示例中，第一操作信息可以包括任务编码、用户标识等信息。
[0189] 其中，任务编码可以是用户指示进行抽奖的抽奖界面对应任务实例的编码。电子设备可以根据接收用户操作205时，显示的界面信息，确定任务编码。
[0190] 用户标识可以包括以下中的至少一项：IMEI，IMSI，user ID，当前登录的账号信息等。
[0191] S602、根据第一操作信息，获取第一任务实例的奖励信息。
[0192] 其中，第一任务实例可以是第一操作信息中包括的任务编码指示的任务实例。
[0193] 设备服务器可以根据接收到的第一操作信息中携带的任务编码，从已配置的一个或多个任务实例中，获取第一任务实例，并读取第一任务实例的奖励信息。在一些实施例中，该步骤可以是由设备服务器中的概率判断模块执行的。
[0194] 结合前述图4的相关说明，该获取第一任务实例的奖励信息具体可以包括：获取第一任务实例的每个奖励信息的奖励内容信息、类型标识。在奖励信息配置有概率信息时，该获取第一任务实例的奖励信息还可以包括获取已配置的每个奖励信息的概率信息。
[0195] 作为一种示例，以第一任务实例为任务实例A，对应配置有奖励信息1、奖励信息2、奖励信息3以及奖励信息4为例。
[0196] 以各个奖励信息的类型标识以及概率信息的配置如表6所示为例。则该奖励信息1可以为第一类型的奖励信息，即兜底奖励。奖励信息2可以为第二类型以及第三类型的奖励信息，即必得奖励，同时为限量奖励。奖励信息3以及奖励信息4可以为第三类型的奖励信息，即限量奖励。
[0197] 这样，在该S602中，设备服务器可以获取奖励信息1对应的奖励内容信息1，表示奖励信息1为第一类型的第一标识，以及奖励信息1的概率信息0.7。
[0198] 设备服务器可以获取奖励信息2对应的奖励内容信息2，表示奖励信息2为第二类型的第二标识、奖励信息2同为第三类型的第三标识。
[0199] 设备服务器可以获取奖励信息3对应的奖励内容信息3，表示奖励信息3为第三类型的第三标识，以及奖励信息3的概率信息0.2。
[0200] 设备服务器可以获取奖励信息4对应的奖励内容信息4，表示奖励信息4为第三类型的第三标识，以及奖励信息4的概率信息0.1。
[0201] 需要说明的是，在本申请的一些实施例中，设备服务器还可以获取各个奖励信息对应的已发放信息。
[0202] 例如，设备服务器可以获取如表3或表4所示的已发放记录对应表。
[0203] S603、判断当前用户是否为第一类用户。
[0204] 示例性的，第一类用户对应于异常用户。比如，在用户短时间内多次输入抽奖操作的情况下，该用户可以被配置为异常用户。其中，短时间可以由预配置的时长定义。例如，预配置的时长为时长T1，则在时长T1内，接收到具有相同用户标识的操作信息的次数达到对应的最大阈值时，该用户即为异常用户。
[0205] 对应的，设备服务器可以存储异常用户的用户标识。比如，设备服务器可以存储异常用户列表，该异常用户列表中可以用于存储异常用户的用户标识(如user ID等信息)。
[0206] 本申请中，设备服务器可以在按照概率配置、限量配置确定配发奖励信息之前，确定当前用户是否为异常用户。
[0207] 例如，设备服务器可以根据S601获取的第一操作信息中携带的user ID，判断该user ID是否包括在异常用户列表中。
[0208] 在第一操作信息携带的user ID包括在异常用户列表中的情况下，则该用户为第一类用户，设备服务器对应执行S604。
[0209] 在第一操作信息携带的user ID不包括在异常用户列表中的情况下，则该用户不是第一类用户，即该用户是正常用户。设备服务器对应执行S605。
[0210] S604、确定配置第一奖励信息。
[0211] 示例性的，该第一奖励信息可以为第一类型的奖励信息，即兜底奖励。如奖励信息1。
[0212] 在一些实施例中，设备服务器可以在确定用户为异常用户的情况下，向该用户直接配发兜底奖励。
[0213] 可以理解的是，在另一些实施例中，设备服务器中该S603的判断逻辑也可省略。例如，设备服务器可以在执行S602后，直接跳转执行S605。由此在安全环境(如不存在异常用户)的情况下，节省判断执行步骤，提升处理效率。
[0214] S605、判断是否配置第二类型的奖励信息。
[0215] 示例性的，第二类型的奖励信息可以为必得奖励的奖励信息。例如，该第二类型的奖励信息可以为前述示例中的奖励信息2。
[0216] 本申请中，设备服务器可以记录第一任务实例运行后，已接收到同一个用户标识对应操作信息的个数。进而据此确定是否为在当前接收到第一操作信息的情况下，为对应的第一用户配置第二类型的奖励信息。
[0217] 例如，以接收到第一操作信息之前，设备服务器记录的已接收到第一操作信息的个数为a；第二类型的奖励信息的次数阈值配置为m为例。
[0218] 在S601中，设备服务器接收到第一操作信息之后，设备服务器可以更新a为a+1。在该S605中，设备服务器可以在确定a+1达到m的情况下，确定为第一用户标识配置第二类型的奖励信息2。跳转执行S606。
[0219] 反之，设备服务器可以在确定a+1未达到m的情况下，确定为第一用户标识配置第二类型的奖励信息2。跳转执行S608。
[0220] 在本申请的一些实施例中，在确定配置第二类型的奖励信息的情况下，跳转执行S606之后，设备服务器可以将已接收到第一操作信息的次数置为0。由此避免此后一直为该第一用户标识配发第二类型的奖励信息。
[0221] S606、判断限量配置是否符合。
[0222] 需要说明的是，在本示例中，以奖励信息2的类型包括第二类型和第三类型为例。那么，在S605确定奖励信息2符合第二类型的次数阈值对应的配发条件的情况下，设备服务器还可以执行该S606，判断奖励信息2是否符合第三类型的限量配置对应的配发条件。
[0223] 而对应的，对于奖励信息类型仅为第二类型的情况下，则可以跳过该S606，执行S607。
[0224] 在本示例中，设备服务器可以针对每一个第三类型的奖励信息(如奖励信息2)，基于已发放记录对应表中记录的该奖励信息的已配置信息，以及该奖励信息对应的限量配置(如表2所示的限量配置)，确定该奖励信息2是否满足第三类型的配发条件。
[0225] 其中，已配置信息可以包括各个维度下，该奖励信息的配发数量。结合前述说明，该各个维度可以包括以下中至少一项：单个用户维度、所有用户维度、年维度、月维度、日维度、时维度、分维度、秒维度等。
[0226] 本示例中，设备服务器可以根据已配置信息，逐个维度进行确认，以便在再次配发该奖励信息2后，不会导致超出限量配置。这样也即该奖励信息2符合限量配置。由此可以跳转执行S607。反之，若再次配发奖励信息2，会导致至少一个维度超出限量配置，则不配发奖励信息2。例如，跳转执行S604。
[0227] S607、确定配置第二奖励信息。
[0228] 示例性的，该第二奖励信息可以为第二类型的奖励信息，即必得奖励。如奖励信息2。
[0229] 这样，通过上述S606‑S607，对确定配置必得奖励的情况进行了详细说明。
[0230] 对应的，在S605中，设备服务器确定不配置必得奖励的情况下，则可以从第一任务实例中，配置有概率信息的奖励信息一个或多个奖励信息中，确定为第一用户标识配置的奖励信息。
[0231] 示例性的，该过程可以包括：
[0232] S608、根据已配置的奖励信息的概率信息，确定配置第三奖励信息。
[0233] 示例性的，设备服务器可以根据如图5所示的方案实现，在已经配置有概率信息的所有奖励信息中，确定第三奖励信息。
[0234] 例如，继续结合表6的示例。当前任务实例中，配置有概率信息的奖励信息可以包括奖励信息1、奖励信息3以及奖励信息4。
[0235] 这样，设备服务器可以根据如图5所示的方案实现，从该奖励信息1、奖励信息3以及奖励信息4中，选取第三奖励信息。
[0236] 以下说明中，以第三奖励信息为奖励信息3为例。
[0237] S609、判断限量配置是否符合。
[0238] 类似于前述S606的说明，在本示例中，以第三奖励信息配置有限量配置为例。
[0239] 这样，设备服务器可以根据奖励信息3的已配置信息，确定该奖励信息3的配置是否符合限量配置。具体执行可以参考S606，此处不在赘述。
[0240] 本申请中，在第三奖励信息(如奖励信息3)的配置符合限量配置的情况下，则执行S610。反之，在第三奖励信息的配置不符合限量配置的情况下，则此次不为第一用户标识配置第三奖励信息。例如，跳转执行S604。为第一用户标识配置第一奖励信息，即配置兜底奖励。
[0241] S610、确定配置第三奖励信息。
[0242] 这样，通过上述方案实现，设备服务器即可在接收到第一操作信息后，确定为当前第一用户标识配置的奖励信息。如S604中的第一奖励信息、S607中的第二奖励信息，或者S610中的第三奖励信息。
[0243] 需要说明的是，上述各个方案步骤，都可以通过如图3所示的设备服务器中的概率判断模块和/或限量判断模块实现。
[0244] 示例性的，S606以及S609可以由限量判断模块实现。图6中的其他逻辑步骤可以由概率判断模块执行。
[0245] 本申请中，在确定为当前第一用户标识配置的奖励信息后，设备服务器可以通过奖励配置模块，实现向电子设备的奖励信息的配发。
[0246] 示例性的，以设备服务器确定配置第一奖励信息(如奖励信息1)为例。奖励配置模块可以向第一用户标识对应的电子设备发送奖励信息1包括的奖励内容信息1等信息。
[0247] 与之类似的，以设备服务器确定配置第二奖励信息(如奖励信息2)为例。奖励配置模块可以向第一用户标识对应的电子设备发送奖励信息2包括的奖励内容信息2等信息。
[0248] 以设备服务器确定配置第三奖励信息(如奖励信息3)为例。奖励配置模块可以向第一用户标识对应的电子设备发送奖励信息3包括的奖励内容信息3等信息。
[0249] 上述如图6的示例中，提供了一种限量配置判断的方案实现。本申请的一些实施中，设备服务器可以结合不同存储介质的存储空间大小以及数据读取速率，实现快速的限量配置的判断。
[0250] 本申请实施例中，设备服务器中可以配置有第一存储介质和第二存储介质。第一存储介质可以具有较大存储空间，对应数据读取速率较低。相对的，第二存储介质具有较高的数据读取速率，但存储空间有限。作为一种可能的实现，第一存储介质可以为设备服务器中配置的外存，或硬盘。第二存储介质可以为设备服务器中配置的内存。
[0251] 作为一种可能的实现，数据在第一存储介质中可以存储在对应的数据库中，如mysql数据库。相应的，数据在第二存储介质中也可以存在对应的数据库中进行维护，如redis数据库。
[0252] 本申请中，由于每个任务实例配置有多个维度的限量配置，因此，如表2所示的已发放配置(也即上述已发放记录对应表)的存储数据量非常大，无法全部存储在内存中。在已发放记录对应表存储在外存中时，进行限量配置判断过程中，设备服务器的处理器就需要频繁多次与外存进行数据读取，以获取各个维度的已配置信息。这样就会产生大量的数据读写开销，不利于奖励信息的快速确认和配发。
[0253] 本申请的一些实施例中，完整的已配置信息可以被存储在外存中。此外，在内存中还可以配置有各个已配置信息的简化字段。这样，只需要在内存中存储少量数据，就可以在进行限量配置判断时，不需要从外存中频繁大量读取数据。由此达到提升限量配置效率，降低该过程的开销的目的。以下进行具体说明。
[0254] 为了便于说明，以如图3中的任务实例A为例进行说明。
[0255] 以下示例中，该任务实例A可以配置有4个维度的限量配置。如维度1、维度2、维度3以及维度4。这样，前述实例中涉及的奖励信息1对应的已配置信息具体可以包括：
[0256] User ID：1001；#用户标识user ID为1001；
[0257] 奖励信息编码：pack01；#当前记录对应的奖励信息的编码为pack01，对应于奖励信息1；
[0258] 维度1＝a11次；#当前用户在维度1领取奖励信息1的次数为a11次；
[0259] 维度2＝a12次；#当前用户在维度2领取奖励信息1的次数为a12次；
[0260] 维度3＝a13次；#当前用户在维度3领取奖励信息1的次数为a13次；
[0261] 维度4＝a14次；#当前用户在维度4领取奖励信息1的次数为a14次。
[0262] 上述6个数据段可以分别存储在外存中。
[0263] 此外，外存中还可以存储有当前用户标识，领取其他奖励信息的已配置信息。
[0264] 例如，奖励信息2对应的：
[0265] User ID：1001，奖励信息编码：pack02，维度1＝a21次，维度2＝a22次，维度3＝a23次，维度4＝a24次。
[0266] 奖励信息3对应的：
[0267] User ID：1001，奖励信息编码：pack03，维度1＝a31次，维度2＝a32次，维度3＝a33次，维度4＝a34次。
[0268] 奖励信息4对应的：
[0269] User ID：1001，奖励信息编码：pack04，维度1＝a41次，维度2＝a42次，维度3＝a43次，维度4＝a44次。
[0270] 由此，在外存中至少需要通过24个数据段存储用户标识为1001的用户在该任务实例A中的奖励获取情况。
[0271] 本申请中，在内存中可以配置已经获取过的奖励信息对应的简化字段。
[0272] 示例性的，内存中的简化字段可以由两部分组成：键值(key)部分，以及数值(value)部分。
[0273] 在一些实施例中，key部分用于标识User ID、奖励信息编码、以及维度的标识。Value部分用于标识key对应的已获取次数。在另一些实施例中，key部分可以包括单用户或中总用户标志、奖励信息编码、维度标识(年、月等)，当前维度开始时间戳等。
[0274] 例如，以user ID为1001，奖励信息1，维度1为例。
[0275] 对应在内存中的简化字段可以包括：“key1＝1001:pack01:1,value＝a11”一个字段。对应的，以用户标识1001在所有维度均领取过奖励信息1为例。内存中可以存储如下4个字段：“key1＝1001:pack01:1,value＝a11”、“key1＝1001:pack01:2,value＝a12”、“key1＝1001:pack01:3,value＝a13”、“key1＝1001:pack01:4,value＝a14”。
[0276] 由此实现奖励信息1的已配置信息在内存中的记录。
[0277] 本申请中，设备服务器可以针对每一个已经领取过的奖励信息，在内存中生成存储对应的简化字段。如此即可如图7所示的，在设备服务器的内存中配置简化字段，在外存中存储完整的配置信息。以便于后续触发如图6所示的S606或S609，快速获取已配置信息，进行限量配置的判断。
[0278] 作为一种实现，图8提供了一种限量判断的流程示意图。该方案可以应用于如图3所示的限量判断模块中。该如图8所示的方案实现，可以用于针对一个奖励信息的多个不同维度，实现该奖励信息的配发是否会导致各个维度的限量配置不符合的判断逻辑。
[0279] 如图8所示，该流程可以包括：
[0280] S801、根据第一操作信息，以及奖励信息，生成第一键值。其中，第一键值与第一维度对应。
[0281] 示例性的，限量判断模块可以在触发限量判断的情况下执行该S801。例如，限量判断模块可以执行S606或S609时对应触发限量判断。
[0282] 本申请中，以第一操作信息是第一用户通过第一电子设备输入第一操作后，第一电子设备生成的第一操作信息，第一用户(以及第一电子设备)的用户标识为第一用户标识为例。第一操作信息的生成以及获取过程可以参考图6中的说明，此处不在赘述。
[0283] 作为一种实现，限量判断模块可以根据第一操作信息中携带的第一任务实例的任务编码，获取第一任务实例对应配置的奖励信息。
[0284] 限量判断模块可以对应生成第一维度的第一键值。
[0285] 例如，结合前述说明，以第一奖励信息包括奖励信息1，对应配置的限量配置包括维度1、维度2、维度3以及维度4为例。
[0286] 本示例中，限量判断模块可以在第一操作信息到来之后，生成奖励信息1对应的维度1的key1。
[0287] 例如，该key1＝1001:pack01:1。
[0288] S802、判断内存中是否存在第一键值。
[0289] 示例性的，限量判断模块可以在内存中，根据生成的key1进行查找，以便判断在内存中是否存储有key1以及对应的value。
[0290] 结合图7中的说明，本申请中，在key1对应user ID、奖励信息、维度1已经被领取过的情况下，在内存中可以存储该已配置信息对应的简化字段。对应的，在存在多个已经被领取的奖励时，在内存中可以存储有多个奖励信息各自对应的不同维度下的多个简化字段。
[0291] 这样，在第一键值(如key1)存在，则内存中与该key1对应value就可以为该user ID为1001、奖励信息1、维度1对应的已领取次数。
[0292] 本示例中，在内存中存在第一键值的情况下，执行S804。对应的，在内存中不存在第一键值的情况下，执行S803。
[0293] S803、第一键值的数值加1。
[0294] 以内存中存在第一键值(如key1)为例。
[0295] 限量判断模块可以根据内存中存储的key1对应的数据(value)，确定该第一操作信息是否满足第一维度的限量配置。
[0296] 示例性的，限量判断模块可以首先对内存中存储的key1的value执行加1的处理。这样，处理后的内存中的key1的value的值即为：若为当前第一操作信息对应的第一用户标识配置奖励信息1，当前维度下(即user ID为1001，奖励信息1，维度1)的已领取次数。
[0297] 进一步的，限量判断模块可以根据该处理之后的value，确定为第一用户标识的配置是否会超出第一维度的限量配置。例如跳转执行S805。
[0298] S804、从外存中获取数据，在内存中生成第一键值和对应的数值，且数值加1。
[0299] 本示例中，以内存中没有key1为例。则对应的，该user ID为1001，奖励信息1在围堵1下尚未领取过奖励信息1，或者，由于内存异常导致对应的已配置信息丢失。
[0300] 由此，限量判断模块可以从外存中，根据任务编码1、user ID为1001，以及奖励信息1的奖励信息编码和维度1的标识，读取“user ID为1001，奖励信息1，维度1”对应的已领取次数。相应的，限量判断模块可以根据读取的信息，在内存中生成key1以及对应value的简化字段。
[0301] 类似于S803中的处理，限量判断模块可以对内存中生成的，与S801生成的第一键值相应的key1，确定标识当前维度下已领取次数的value。限量判断模块可以对该value进行加1的处理，以便获取再次配置奖励信息1后已领取次数。接着执行S805。
[0302] S805、判断是否大于对应限量配置。
[0303] 示例性的，限量判断模块可以根据S803或S804中处理后获取的value，与相应维度的限量配置进行对比，判断当前维度是否大于对应限量配置。
[0304] 例如，限量判断模块可以根据“user ID为1001，奖励信息1，维度1”对应的编码，获取限量配置中的限值。作为一种实力，限量判断模块可以从如表2所示的多维度限量信息配置获取“user ID为1001，奖励信息1，维度1”对应的限值。
[0305] 对应的，在确定大于对应限量配置的情况下，表明如果再次配置奖励信息1，则会使得维度1下的限量配置不符合。也就是说，不能再为user ID为1001配置该奖励信息1。
[0306] 反之，在加1处理后的value不大于对应限量配置的情况下，表明如果再次配置奖励信息1，则维度1下的限量配置依然符合。也就是说，可以为user ID为1001配置该奖励信息1。
[0307] 在一些实施例中，若当前奖励信息1仅配置有一个维度(如维度1)，则限量配置判断通过，按照如图6所示逻辑向后执行。
[0308] 在本实施例中，以当前奖励信息1配置有多个维度为例。在一些实现中，该S801‑S805的处理也可称为第一维度限量判断。
[0309] 这样，通过S801‑S805的处理，在S805判断结果为“否”的情况下，则表明第一维度(即维度1)限量判断通过。对应的，限量判断模块可以按照S801‑S805类似的逻辑，执行其他维度的限量判断。
[0310] S806、第一键值加入预设列表。
[0311] 在本申请中，限量判断模块可以为第一奖励信息配置对应的预设列表(list)。这样，在确定第一维度的限量判断通过的情况下，限量判断模块可以将该第一维度对应键值(如key1)加入预设列表中。该预设列表中的各个key对应于限量判断通过的维度。
[0312] 需要说明的是，如图8所示，在任一个维度的限量判断不通过的情况下，则限量判断模块可以将预设列表中的所有键值对应value执行减1的处理。
[0313] 结合S803以及S804的说明，在key放入预设列表前，判断是否符合对应维度的限量配置时，该key的value会加1处理。那么，预设列表中的所有key的value均经过该加1处理，对应于此次配置第一奖励信息后的已领取次数。
[0314] 这样，如果确定限量判断不通过，限量判断模块通过对预设列表中的所有key的value执行减1处理，使得各个key的value能够准确反映当前维度的已领取次数。
[0315] 接着，限量判断模块可以执行以下S807：第二维度限量判断，并在符合第二维度的限量配置的情况下，执行S808：第二键值加入预设列表。由此完成第二维度的限量判断逻辑。该S807到S808的处理逻辑可以参考上述S801‑S806中第一维度限量判断的具体说明，具体实施过程可以互相参考。
[0316] 此后类似，进行其他维度的限量判断逻辑。
[0317] 例如，针对第三维度的限量判断逻辑可以包括：S809：第三维度限量判断，并在符合第三维度的限量配置的情况下，执行S810：第三键值加入预设列表。
[0318] 又如，针对第四维度的限量判断逻辑可以包括：S811：第四维度限量判断，并在符合第四维度的限量配置的情况下，执行S812：第四键值加入预设列表。
[0319] 需要说明的是，本示例中，以第一奖励信息配置有四个维度的限量配置为例。在另一些实施例中，具体第一奖励信息的限量配置维度不同时，设备服务器也可以针对各个维度分别执行对应的限量判断。
[0320] 以此类推，以所有维度限量判断均通过为例。这样，在完成所有维度的限量判断后，限量判断模块可以执行S813：确定所有维度的键值加入预设列表。由此表示所有维度的限量判断均成功通过。这样，限量判断模块就可以确定该第一奖励信息的限量判断通过，可以为该第一用户标识配置第一奖励信息。后续具体处理可以参考图6中的相关说明，此处不在赘述。
[0321] 这样，结合图6到图8的说明，设备服务器就可以高效准确地实现多维度的奖励信息确认。
[0322] 在本申请的另一些实施例中，设备服务器还可以提供多线程并发能力。这样，在短时间内接收到两个或多个相同用户标识或不同用户标识对应的操作信息的情况下，则设备服务器可以分别进行并行处理。例如，设备服务器可以基于如图6或图8所示的方案实现，分别对接收到的操作信息进行并行处理，由此通过一个设备服务器同时向多个电子设备提供奖励信息的抽取服务。
[0323] 作为一种示例，参考图9，以设备服务器在短时间内接收到第一操作信息和第二操作信息为例。其中，设备服务器接收到第一操作信息的时间早于接收到第二操作信息的时间。
[0324] 此外，第一操作信息和第二操作信息可以对应不同用户标识。例如，第一操作信息可以包括user ID为1001，第二操作信息包括user ID为1002。
[0325] 这样，设备服务器可以通过运行第一线程，用于响应于第一操作信息，判断为user ID为1001的用户配置对应的奖励信息。
[0326] 如图9所示，第一线程可以通过执行S801到S805，实现第一维度的限量配置判断。具体步骤执行可以参考图8中的说明。
[0327] 与之类似的，设备服务器可以通过运行第二线程，用于响应于第二操作信息，判断为user ID为1002的用户配置对应的奖励信息。
[0328] 如图9所示，第二线程可以通过执行S901到S905，实现第一维度的限量配置判断。具体步骤执行可以参考图8中的说明。
[0329] 例如，在如图9的示例中，设备服务器可以通过第二线程执行的第一维度的限量配置可以包括：
[0330] S901、根据第二操作信息，以及奖励信息，生成第一维度的第五键值。其中，第五键值可以对应于第二操作信息的user ID领取奖励信息1时，对应的第一维度下在内存中的简化字段。比如，第五键值可以包括“key5＝1002:pack01:1”。
[0331] S902、判断内存中是否存在第五键值。
[0332] S903、再次判断内存中是否存在第五键值。
[0333] 在一些实施例中，该S903的执行可以使得第二操作信息的限量判断过程更加准确。而在另一些实施例中，该S903也可以是可选步骤，即执行S902之后直接跳转执行S904。具体情况再后续详述。
[0334] S904、从外存中获取数据，在内存中生成第五键值和对应的数值，且数值加1。
[0335] S905、判断是否大于对应限量配置。
[0336] 由此即可实现基于不同线程的多线程并发处理，实现不同操作信息的并行判断。
[0337] 需要说明的是，在一些情况下，第一操作信息和第二操作信息分别针对不同任务实例，或者针对不同奖励信息的情况下。则设备服务器可以根据如图6到图8所示的方案实现，分别独立确定为user ID为1001的用户配置对应的奖励信息，以及确定为user ID为1002的用户配置对应的奖励信息。
[0338] 这样，上述如图9所示的S903即可省略。由此，第二操作信息的限量判断逻辑可以包括S901‑S902‑S904‑S905。
[0339] 在另一些情况下，第一操作信息和第二操作信息的user ID不同，但可以针对相同任务实例中的同一个奖励信息(如第一奖励信息)进行判断。
[0340] 这样，设备服务器可以通过配置内存信息的持锁逻辑，避免对两个操作信息的判断出现问题。以下具体进行说明。
[0341] 作为一种实现，如图9所示，在第一线程执行S802之后，在确定内存中没有第一操作信息对应的第一键值的情况下，第一线程执行S803。在该执行S803的过程中，设备服务器可以将第一奖励信息对应的操作锁(lock)配置给第一线程，也即第一线程持锁。这样，在该过程中，如果有其他线程需要读取或修改内存中第一奖励信息对应的内容，可以等待第一线程持锁结束，也即第一线程解锁。由此，保证在第一线程对第一奖励信息在内存中的简化字段进行修改的情况下，其他线程等待解锁后再对该简化字段进行操作。
[0342] 例如，第二线程执行S902之后，在确定内存中不包括第五键值的情况下，执行S903之前，可以判断第一奖励信息对应的操作锁正在被其他线程持锁(如被第一线程持锁)。这样，第二线程可以等待第一奖励信息对应的操作锁被释放，再执行S903。
[0343] 可以理解的是，由于在第二线程从外存中读取第一奖励信息的相关数据之前，第一线程可以通过S803从外存中读取该第一奖励信息的已配置信息，并在内存中生成对应的简化字段。因此，在第一线程释放第一奖励信息对应的操作锁后，内存中可能已经存在第五键值对应的简化字段。这样，第二线程可以在从外存中读取第一奖励信息的已配置信息(即执行S904)之前，再次执行S903，判断内存中是否存在第五键值，以便实现对内存中简化字段准确匹配的效果。
[0344] 对应的，在另一些场景下，第二线程执行S903后，若内存中存在第五键值，对应的第一奖励信息的操作锁正在被其他线程所持有。那么，第二线程也可以等待其他线程释放第一奖励实施的操作锁后，再执行第五键值的value加1以及限量判断等后续操作。这样，就可以使得第一线程对第一奖励信息的已配置信息进行更新后，第二线程可以根据最新的已配置信息，进行限量判断。由此提升多线程并发处理机制中的数据准确性。
[0345] 可以理解的是，本申请实施例提供的电子设备为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请实施例的范围。
[0346] 本申请实施例可以根据上述方法示例对上述电子设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
[0347] 示例性的，图10示出了的一种数据处理装置1000的组成示意图。在一些实现中，该数据处理装置1000可以配置在设备服务器中。
[0348] 如图10所示，该数据处理装置1000可以包括：处理器1001和存储器1002。该存储器1002用于存储计算机执行指令。示例性的，在一些实施例中，当该处理器1001执行该存储器
1002存储的指令时，可以使得该数据处理装置1000执行上述实施例中任一种所示的方法。
[0349] 需要说明的是，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。
[0350] 图11示出了的一种芯片系统1100的组成示意图。在一些实现中，该芯片系统1100可以配置在如图10所示的数据处理装置1000中，或者，该芯片系统1100可以配置在上述实施例中涉及的设备服务器中。
[0351] 如图11所示，该芯片系统1100可以包括：处理器1101和通信接口1102，用于支持相关设备实现上述实施例中所涉及的功能。在一种可能的设计中，芯片系统还包括存储器，用于保存电子设备必要的程序指令和数据。该芯片系统，可以由芯片构成，也可以包含芯片和其他分立器件。需要说明的是，在本申请的一些实现方式中，该通信接口1102也可称为接口电路。
[0352] 需要说明的是，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。
[0353] 在上述实施例中的功能或动作或操作或步骤等，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件程序实现时，可以全部或部分地以计算机程序产品的形式来实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或者数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包括一个或多个可以用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)，光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solid state disk，SSD))等。
[0354] 尽管结合具体特征及其实施例对本申请进行了描述，显而易见的，在不脱离本申请的精神和范围的情况下，可对其进行各种修改和组合。相应地，本说明书和附图仅仅是所附权利要求所界定的本申请的示例性说明，且视为已覆盖本申请范围内的任意和所有修改、变化、组合或等同物。显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包括这些改动和变型在内。
