CN111905376B - 虚拟物品的数据处理方法、装置及系统、电子设备 - Google Patents

Abstract

本申请提供一种虚拟物品的数据处理方法、装置及系统、电子设备，该方法包括：通过数据库服务端根据虚拟物品动态变化的交易数据，定时更新数据库存储的虚拟物品的估价值；将更新后的虚拟物品的估价值同步到游戏服务端；通过游戏服务端缓存虚拟物品的估价值；当游戏服务端接收到客户端登录信号时，通过游戏服务端将缓存的虚拟物品的估价值下发到客户端登录信号的发送方。本申请实施例提供的技术方案，可以减少对游戏服务端的占用，减少响应时间，避免游戏卡顿。

Description

虚拟物品的数据处理方法、装置及系统、电子设备

技术领域

本申请涉及数据处理技术领域，特别涉及一种虚拟物品的数据处理方法、装置及系统、电子设备、计算机可读存储介质。

背景技术

在自由度很高的游戏世界中，玩家间可以交易物品的价值是应该由玩家来决定的，但是在玩家交易量超大的情况下，没有合适的办法来给出物品的动态估价。

估价需要的数据越多越接近真实价格，但大量的交易数据的估价算法在内存中做，需要消耗大量服务器CPU(Central Processing Unit，中央处理器)。

在玩家交易量为千万级左右大数据的情况下，如果要遍历所有交易数据，且对数据操作计算，需要持续长时间占满服务器CPU，而游戏主逻辑服务器长时间被占满，到导致游戏响应慢，卡顿的问题。

发明内容

本申请实施例提供了虚拟物品的数据处理方法，用以解决服务器CPU长时间被占满，游戏响应慢、卡顿的问题。

本申请实施例提供了一种虚拟物品的数据处理方法，包括：

通过数据库服务端根据虚拟物品动态变化的交易数据，定时更新数据库存储的所述虚拟物品的估价值；

将更新后的所述虚拟物品的估价值同步到游戏服务端；

通过所述游戏服务端缓存所述虚拟物品的估价值；

当所述游戏服务端接收到客户端登录信号时，通过所述游戏服务端将缓存的所述虚拟物品的估价值下发到所述客户端登录信号的发送方。

在一实施例中，所述通过数据库服务端根据虚拟物品动态变化的交易数据，定时更新数据库存储的所述虚拟物品的估价值之前，所述方法还包括：

通过数据库服务端遍历动态变化的交易记录表，筛选出交易时间处于预设时间范围内的交易数据；

在所述数据库构建临时表保存筛选出的所述交易数据。

在一实施例中，在所述数据库构建临时表保存筛选出的所述交易数据之后，所述方法还包括：

通过所述数据库服务端根据不同虚拟物品对应配置的有效价格区间，将所述临时表中交易价格不处于所述有效价格区间内的交易数据标记为无效交易；

通过双层游标嵌套遍历所述临时表，去除标记为无效交易的交易数据。

在一实施例中，所述交易数据包括交易价格和交易量；所述通过数据库服务端根据虚拟物品动态变化的交易数据，定时更新数据库存储的所述虚拟物品的估价值，包括：

通过所述数据库服务端定时根据所述虚拟物品每笔交易的交易量，计算所述虚拟物品的交易量中位数；

根据所述交易量中位数对应的交易价格，得到所述虚拟物品的估价值；

更新所述数据库的估价表，所述估价表包括每种虚拟物品的估价值。

在一实施例中，根据所述交易量中位数对应的交易价格，得到所述虚拟物品的估价值，包括：

通过所述数据库服务端根据不同时间段的交易量中位数对应的交易价格，以及不同时间段的交易总量，加权计算出所述虚拟物品的估价值。

在一实施例中，所述游戏服务端包括不同游戏场景对应的场景服务端，将更新后的所述虚拟物品的估价值同步到游戏服务端，包括：

在所述场景服务端开服时，通过所述数据库服务端将所述数据库存储的估价表同步到开服的所述场景服务端。

在一实施例中，所述数据库服务端包括主库服务端和从库服务端，通过数据库服务端根据虚拟物品动态变化的交易数据，定时更新数据库存储的所述虚拟物品的估价值，包括：

通过主库服务端定时将交易数据备份到所述从库服务端；

在所述交易数据的数据量大于阈值时，切换到由所述从库服务端定时更新所述虚拟物品的估价值。

本申请实施例还提供了一种虚拟物品的数据处理系统，包括：

数据库服务端，用于根据虚拟物品动态变化的交易数据，定时更新数据库存储的所述虚拟物品的估价值；将更新后的所述虚拟物品的估价值同步到游戏服务端；

游戏服务端，连接所述数据库服务端，用于缓存所述虚拟物品的估价值；当接收到客户端登录信号时，将缓存的所述虚拟物品的估价值下发到所述客户端登录信号的发送方。

本申请实施例提供了一种虚拟物品的数据处理装置，包括：

估价更新模块，用于通过数据库服务端根据虚拟物品动态变化的交易数据，定时更新数据库存储的所述虚拟物品的估价值；

估价同步模块，用于将更新后的所述虚拟物品的估价值同步到游戏服务端；

估价缓存模块，用于通过所述游戏服务端缓存所述虚拟物品的估价值；

估价下发模块，用于当所述游戏服务端接收到客户端登录信号时，通过所述游戏服务端将缓存的所述虚拟物品的估价值下发到所述客户端登录信号的发送方。

本申请实施例还提供了一种电子设备，所述电子设备包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为执行上述虚拟物品的数据处理方法。

本申请实施例还提供了一种计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序可由处理器执行以完成上述虚拟物品的数据处理方法。

本申请上述实施例提供的技术方案，由数据库服务端根据动态变化的交易数据，进行虚拟物品估价值的定时更新，并将更新后的结果同步到游戏服务端，从而游戏服务端无需进行估价值的计算，即使交易数据的数量级非常大，也不会占用游戏服务端的CPU，从而加快响应，使操作更流畅。客户端在登录时即可获取到虚拟物品的估价值，无需每次交易访问一次游戏服务端，从而进一步减少对游戏CPU的占用，也加快客户端的响应。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍。

图1是本申请实施例提供的虚拟物品的数据处理方法的应用场景示意图；

图2是本申请实施例提供的一种虚拟物品的数据处理系统示意图；

图3是本申请实施例提供的一种电子设备的示意图；

图4是本申请实施例提供的一种虚拟物品的数据处理方法的流程示意图；

图5是图4对应实施例基础上本申请另一实施例提供的虚拟物品的数据处理方法的流程示意图；

图6是图4对应实施例中步骤S410的细节流程图；

图7是本申请实施例提供的一种虚拟物品的数据处理装置的框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

图1是本申请实施例提供的虚拟物品的数据处理方法的应用场景示意图，如图1所示，该应用场景包括数据库服务端110、游戏服务端120以及多个客户端130。数据库服务端110可以是运行数据库软件的服务器，即数据库服务器。游戏服务端120可以是运行游戏程序的服务器。游戏服务端120可以有多个。客户端130可以手机、平板电脑、笔记本电脑或台式电脑。

数据库服务端110和游戏服务端120构成服务器集群，数据库服务端110、游戏服务端120和客户端130之间通过有线或无线网络通信。数据库服务端110和游戏服务端120可以执行本申请实施例提供的虚拟物品的数据处理方法，虚拟物品的估价计算由数据库服务端110完成，从而不占用游戏服务端120的CPU。数据库服务端110计算的每种虚拟物品的估价值可以同步到游戏服务端120，进而游戏服务端120可以在客户端130登录后(即与客户端130建立通信连接后)，将每种虚拟物品的估价值发送到客户端130。

在一实施例中，对于多CPU的服务器而言，数据库服务端110和游戏服务端120可以是同一服务器，一个CPU运行数据库软件，其他CPU运行游戏程序，估价计算由数据库CPU完成，从而不占用游戏CPU。

图2是本申请实施例提供的一种虚拟物品的数据处理系统200示意图。如图2所示，该数据处理系统200包括数据库服务端110和游戏服务端120。

数据库服务端110，用于根据虚拟物品动态变化的交易数据，定时更新数据库存储的所述虚拟物品的估价值；将更新后的所述虚拟物品的估价值同步到游戏服务端120。

游戏服务端120，连接所述数据库服务端110，用于缓存所述虚拟物品的估价值；当接收到客户端登录信号时，将缓存的所述虚拟物品的估价值下发到所述客户端登录信号的发送方。

图3是本申请实施例提供的一种电子设备300的示意图，该电子设备300包括处理器310；用于存储处理器310可执行指令的存储器320；其中，所述处理器310被配置为执行本申请实施例提供的虚拟物品的数据处理方法。

处理器310可以是一种集成电路芯片，具有信号处理能力。上述处理器310可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(NetworkProcessor，简称NP)等；还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。其可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。

存储器320可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(Static Random Access Memory，简称SRAM)，电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，简称EEPROM)，可擦除可编程只读存储器(Erasable Programmable Read Only Memory，简称EPROM)，可编程只读存储器(Programmable Red-Only Memory，简称PROM)，只读存储器(Read-Only Memory，简称ROM)，磁存储器，快闪存储器，磁盘或光盘。

本申请实施例还提供了一种计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序可由处理器310执行以完成本申请实施例提供的虚拟物品的数据处理方法。

图4是本申请实施例提供的一种虚拟物品的数据处理方法的流程示意图。如图4所示，该方法包括以下步骤S410-步骤S440。

步骤S410：通过数据库服务端110根据虚拟物品动态变化的交易数据，定时更新数据库存储的所述虚拟物品的估价值。

其中，虚拟物品是指游戏等虚拟场景中玩家之间交易的武器、药品、食品等物品。交易数据是指玩家与玩家之间对虚拟物品的交易记录，包括物品类型、交易价格、交易量等，玩家可以自由设定交易价格。随着时间推移，交易订单会越来越多，故交易数据是动态变化的。定时更新可以是每日、每周或每月更新一次。数据库用于存储虚拟物品的估价值，可以是关系型数据库，例如MYSQL数据库。在一实施例中，可以由MYSQL数据库服务端110根据虚拟物品的交易数据计算虚拟物品的估价值。虚拟物品的估价值可以根据虚拟物品历史的交易数据计算得到。举例来说，可以是历史每笔交易价格的平均值。

步骤S420：将更新后的所述虚拟物品的估价值同步到游戏服务端120。

其中，虚拟物品的种类可以是一种或多种，方便起见，可以以估价表的形式存储每种虚拟物品的估价值，可以直接将估价表发送到游戏服务端120。同步是指估价值计算完成后，在游戏服务端120开启时，将计算得到的每个虚拟物品的估价值发送到游戏服务端120，使游戏服务端120存储的估价表与数据库服务端110一致。

步骤S430：通过所述游戏服务端120缓存所述虚拟物品的估价值。

在一实施例中，游戏服务端120可以在内存中缓存估价表。缓存是相对永久性存储而言的，不限定具体缓存的时间。

步骤S440：当所述游戏服务端120接收到客户端登录信号时，通过所述游戏服务端120将缓存的所述虚拟物品的估价值下发到所述客户端登录信号的发送方。

在一实施例中，客户端130可以向游戏服务端120发送客户端登录信号，客户端登录信号可以包括用户名称和密码，游戏服务端120进行用户名称和密码的校验，在校验成功后，将缓存的虚拟物品的估价值下发到客户端130。

客户端130可以在本地缓存估价表，这样估价访问从原来的几分钟缩短到毫秒级，而且客户端130可以同时选择多个虚拟物品，不会因多选虚拟物品延长估价获取时间。

本申请上述实施例提供的技术方案，由数据库服务端110根据动态变化的交易数据，进行虚拟物品估价值的定时更新，并将更新后的结果同步到游戏服务端120，从而游戏服务端120无需进行估价值的计算，即使交易数据的数量级非常大，也不会占用游戏服务端120的CPU，从而加快响应，使操作更流畅。客户端130在登录时即可获取到虚拟物品的估价值，无需每次交易访问一次游戏服务端120，从而进一步减少对游戏CPU的占用，也加快客户端130的响应。

在一实施例中，在上述步骤S410之前，如图5所示，本申请实施例提供的方法还包括：步骤S401：通过数据库服务端110遍历动态变化的交易记录表，筛选出交易时间处于预设时间范围内的交易数据；步骤S402：在数据库构建临时表保存筛选出的所述交易数据。

交易记录表可以存储在数据库服务端110的数据库中，交易记录表包括不同玩家之间每条交易的交易数据，每条交易的交易数据可以包括：交易编号、交易时间、物品类型、交易价格以及交易量等参数。

预设时间范围可以是最近24小时，最近一周或最近一月，还可以是指定的时间段，例如5号到20号。数据库服务端110根据每条交易的交易时间，可以筛选出交易时间在预设范围内的交易数据，从而可以筛选出在这次估价计算时间范围之间的所有交易数据。数据库服务端110可以在临时表中保存筛选出的交易数据。临时表是相对交易记录表而言的，是一个暂存数据的表，方便从临时表中获取交易数据进行处理，得到估价表。

在一实施例中，如图5所示，在上述步骤S402之后，本申请实施例提供的方法还包括以下步骤S403-步骤S404。

步骤S403：通过所述数据库服务端110根据不同虚拟物品对应配置的有效价格区间，将所述临时表中交易价格不处于所述有效价格区间内的交易数据标记为无效交易。

由于玩家可以自由定价，故针对同一虚拟物品，可能存在某条交易数据的交易价格过高或过低，如果这条交易数据参与估价计算，可能影响估价准确性。

故针对不同虚拟物品，可以配置与该虚拟物品对应的有效价格区间。有效价格区间是指当交易价格在有效价格区间内时，属于正常价格，不属于过高或过低，可以参与估价计算。故可以将临时表中交易价格不处于有效价格区间内的交易数据标记为无效交易。

步骤S404：通过双层游标嵌套遍历所述临时表，去除标记为无效交易的交易数据。

故因为临时表中，涵盖了每一种虚拟物品的多次交易，比如X虚拟物品在一次交易中买卖价格是1元，数量是1个，另一次交易中X虚拟物品的交易价格为2元，数量为2个。此外，一次交易中物品价格如果过于高或者过于低，需要将这次交易标记为无效交易，不参与估价计算。因此就需要遍历临时表，拿到每一次的交易数据。为遍历所有交易数据，可以使用游标技术。

开启一个游标1，去遍历临时表，将同类物品的交易数据聚合，得到每一类物品的交易总量和有效交易总量，得到每一行的数据，存入游标1中，再开启游标1，进行LOOP循环，此时我们已经得到游标1中每一行的物品ID，交易总量，有效交易总量(比如X物品，交易了两次，交易总量为3个，有效价格内的交易总量为3个；这个游标1得到的每一行的数据即有:物品的类别ID，交易总量，有效交易总量，那么此时再定义游标2，嵌套在游标1中，再去筛选临时表A，筛选的条件是物品的类别ID和游标1中的物品类别ID相等，可以筛选出这一次交易的交易价格，交易数量，交易是否有效的交易状态，此时，就实现了遍历每一次交易的数据。可以去除临时表中标记为无效交易的交易数据，从而无效交易可以不参与估价的计算。

在一实施例中，交易数据包括交易价格和交易量；如图6所示，上述步骤S410具体包括步骤S411-步骤S413。

步骤S411：通过所述数据库服务端110定时根据所述虚拟物品每笔交易的交易量，计算所述虚拟物品的交易量中位数。

举例来说，假设存在5条交易数据，交易量依次为2、3、1、3、5、4，则交易量中位数可以是对上述交易量由小到大排序，取最中间的数值。

在一实施例中，可以在第二层游标循环里面，先定义一个变量:tt_accumulated(计算数)为0，如果这个计算数小于这一类虚拟物品的交易总量的二分之一，并且在一次计算中，计算数加上一条交易的交易量，大于这一类物品的交易总量的二分之一，那么这条交易的交易量就是交易量中位数。如果不满足，那么就继续下一次游标的循环，将上一次交易的交易量加到计算数中，以此往复，直到找出交易量中位数为止。

步骤S412：根据所述交易量中位数对应的交易价格，得到所述虚拟物品的估价值。

在一实施例中，可以将交易量中位数对应的交易价格，作为虚拟物品的估价值。

为提高估价值的准确性，可以数据库服务端110可以根据不同时间段的交易量中位数对应的交易价格，以及不同时间段的交易总量，加权计算出所述虚拟物品的估价值。

时间段可以是以天、周或月为单位，交易总量是指时间段内的每条交易量的总和。

举例来说，假设第一个月的交易量中位数对应的交易价格是10，第一个月的交易总量是1000，第二个月的交易量中位数对应的交易价格是11，第二个月的交易总量是1500，第三个月的交易量中位数对应的交易价格是13，第三个月的交易总量是1300，第四个月的交易量中位数对应的交易价格是12，第四个月的交易总量是1100，则加权计算虚拟物品的估价值可以参照以下公式：

(10×1000+11×1500+13×1300+12×1100)/(1000+1500+1300+1100)

即多个时间段交易量中位数对应的交易价格乘以交易总量的和，除以多个时间段交易总量的和，作为最终输出的估价值。

步骤S413：更新所述数据库的估价表，所述估价表包括每种虚拟物品的估价值。

由于虚拟物品的种类可能较多，可以在估价表中一一对应存储每种虚拟物品的估价值，在计算出新的估价值后，可以更新数据库存储的估价表。之后，数据库服务端110可以将估价表同步到游戏服务端120。

在一实施例中，游戏服务端120可以包括不同游戏场景对应的场景服务端，举例来说，在沙盒游戏中，整个游戏世界被划分为多个区域，每个区域可以对应一个服务端。一个区域可以认为是一种游戏场景，各个区域对应的服务端可以认为是场景服务端。步骤S420可以包括以下步骤：在场景服务端开服时，通过所述数据库服务端110将所述数据库存储的估价表同步到开服的所述场景服务端。

开服是指场景服务端开启，不同场景服务端可以同时开服，也可以根据需要开启指定的场景服务端。场景服务端开服后，可以向数据库服务端110发送开服信号，从而数据库服务端110可以将数据库存储的最新的估价表发送到开服的场景服务端。

玩家通过客户端130登录指定区域的场景服务端时，可以由各个区域的场景服务端把缓存的估价表发送至此客户端130，客户端130可以将估价表缓存在本地，由此客户端130可以快速获取多个虚拟物品的估价值，缩短客户端130响应时间。

在一实施例中，所述数据库服务端110包括主库服务端和从库服务端，上述步骤S410可以包括以下步骤：通过主库服务端定时将交易数据备份到所述从库服务端；在所述交易数据的数据量大于阈值时，切换到由所述从库服务端定时更新所述虚拟物品的估价值。

假设交易数据的数据量非常大，数据库服务端110可以包括彼此通信的主库服务端和从库服务端，始终在主库服务端计算估价，会占满主库服务端的CPU，故主库服务端可以将所有交易数据发送到从库服务端进行备份，从而从库服务端具有与主库服务端相同的交易数据。

在一实施例中，交易数据的数据量在一个月千万条左右的时候，可以由主库服务端进行估价值的更新计算。在大于这个数量级时，计算过程会长时间占满主库服务端的CPU，此时，可以切换到由从库服务端进行估价值的更新计算。

在其他实施例中，随着数据量的加大，如果主库服务端的计算时间越来越久，也可以切换到由从库服务端进行估价值的更新计算。

由于游戏服务端120连接数据库服务端110，需要进行估价值的同步，为不影响主库服务端和游戏服务端120的主进程，可以在游戏服务端120关服时，切换到由从库服务端进行估价值的计算。

本申请上述实施例提供的技术方案，估价更新计算由数据库服务端110完成，从而避免大数据计算占满游戏服务端120的CPU；数据量特别大时，转移到从库服务端执行更新计算，从而彻底释放对主库服务端和游戏服务端120的占用；客户端130登录后即可从游戏服务端120获取到所有虚拟物品的估价值，从而即使用户选择多个虚拟物品，客户端130也可以快速响应，显示多个虚拟物品的估价值。

以往，虚拟物品的价格是由游戏策划配置的，无法实现玩家自由定价，在供需随时变化的情况下，无法满足用户需求。而本申请实施例可以根据历史交易数据，可以给用户一个合适的估价值，从而提高用户体验。

下述为本申请装置实施例，可以用于执行本申请上述虚拟物品的数据处理方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请虚拟物品的数据处理方法实施例。

图7为本申请一实施例示出的虚拟物品的数据处理装置的框图。如图7所示，该装置包括：估价更新模块710、估价同步模块720、估价缓存模块730以及估价下发模块740。

估价更新模块710，用于通过数据库服务端根据虚拟物品动态变化的交易数据，定时更新数据库存储的所述虚拟物品的估价值；

估价同步模块720，用于将更新后的所述虚拟物品的估价值同步到游戏服务端；

估价缓存模块730，用于通过所述游戏服务端缓存所述虚拟物品的估价值；

估价下发模块740，用于当所述游戏服务端接收到客户端登录信号时，通过所述游戏服务端将缓存的所述虚拟物品的估价值下发到所述客户端登录信号的发送方。

上述装置中各个模块的功能和作用的实现过程具体详见上述虚拟物品的数据处理方法中对应步骤的实现过程，在此不再赘述。

在本申请所提供的几个实施例中，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

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

Claims (9)

1.一种虚拟物品的数据处理方法，其特征在于，包括：

通过数据库服务端根据虚拟物品动态变化的交易数据，定时更新数据库存储的所述虚拟物品的估价值；

将更新后的所述虚拟物品的估价值同步到游戏服务端；

通过所述游戏服务端缓存所述虚拟物品的估价值；

当所述游戏服务端接收到客户端登录信号时，通过所述游戏服务端将缓存的所述虚拟物品的估价值下发到所述客户端登录信号的发送方；

其中，所述交易数据包括交易价格和交易量，得到所述虚拟物品的估计值的方式包括：

通过所述数据库服务端定时根据所述虚拟物品每笔交易的交易量，计算所述虚拟物品的交易量中位数；将所述交易量中位数对应的交易价格，作为所述虚拟物品的估价值，并更新所述数据库的估价表，所述估价表包括每种虚拟物品的估价值；

或，

通过所述数据库服务端根据不同时间段的交易量中位数对应的交易价格，以及不同时间段的交易总量，加权计算出所述虚拟物品的估价值。

2.根据权利要求1所述的方法，其特征在于，所述通过数据库服务端根据虚拟物品动态变化的交易数据，定时更新数据库存储的所述虚拟物品的估价值之前，所述方法还包括：

通过数据库服务端遍历动态变化的交易记录表，筛选出交易时间处于预设时间范围内的交易数据；

在所述数据库构建临时表保存筛选出的所述交易数据。

3.根据权利要求2所述的方法，其特征在于，在所述数据库构建临时表保存筛选出的所述交易数据之后，所述方法还包括：

通过所述数据库服务端根据不同虚拟物品对应配置的有效价格区间，将所述临时表中交易价格不处于所述有效价格区间内的交易数据标记为无效交易；

通过双层游标嵌套遍历所述临时表，去除标记为无效交易的交易数据。

4.根据权利要求1所述的方法，其特征在于，所述游戏服务端包括不同游戏场景对应的场景服务端，将更新后的所述虚拟物品的估价值同步到游戏服务端，包括：

在所述场景服务端开服时，通过所述数据库服务端将所述数据库存储的估价表同步到开服的所述场景服务端。

5.根据权利要求1所述的方法，其特征在于，所述数据库服务端包括主库服务端和从库服务端，通过数据库服务端根据虚拟物品动态变化的交易数据，定时更新数据库存储的所述虚拟物品的估价值，包括：

通过主库服务端定时将交易数据备份到所述从库服务端；

在所述交易数据的数据量大于阈值时，切换到由所述从库服务端定时更新所述虚拟物品的估价值。

6.一种虚拟物品的数据处理系统，其特征在于，包括：

数据库服务端，用于根据虚拟物品动态变化的交易数据，定时更新数据库存储的所述虚拟物品的估价值；将更新后的所述虚拟物品的估价值同步到游戏服务端；

游戏服务端，连接所述数据库服务端，用于缓存所述虚拟物品的估价值；当接收到客户端登录信号时，将缓存的所述虚拟物品的估价值下发到所述客户端登录信号的发送方；

其中，所述交易数据包括交易价格和交易量，所述数据库服务端用于通过以下方式得到所述虚拟物品的估计值：

定时根据所述虚拟物品每笔交易的交易量，计算所述虚拟物品的交易量中位数；将所述交易量中位数对应的交易价格，作为所述虚拟物品的估价值，并更新所述数据库的估价表，所述估价表包括每种虚拟物品的估价值；

或，

根据不同时间段的交易量中位数对应的交易价格，以及不同时间段的交易总量，加权计算出所述虚拟物品的估价值。

7.一种虚拟物品的数据处理装置，其特征在于，包括：

估价更新模块，用于通过数据库服务端根据虚拟物品动态变化的交易数据，定时更新数据库存储的所述虚拟物品的估价值；

估价同步模块，用于将更新后的所述虚拟物品的估价值同步到游戏服务端；

估价缓存模块，用于通过所述游戏服务端缓存所述虚拟物品的估价值；

估价下发模块，用于当所述游戏服务端接收到客户端登录信号时，通过所述游戏服务端将缓存的所述虚拟物品的估价值下发到所述客户端登录信号的发送方；

其中，所述交易数据包括交易价格和交易量，所述估价更新模块用于通过以下方式得到所述虚拟物品的估计值：

通过所述数据库服务端定时根据所述虚拟物品每笔交易的交易量，计算所述虚拟物品的交易量中位数；将所述交易量中位数对应的交易价格，作为所述虚拟物品的估价值，并更新所述数据库的估价表，所述估价表包括每种虚拟物品的估价值；

或，

通过所述数据库服务端根据不同时间段的交易量中位数对应的交易价格，以及不同时间段的交易总量，加权计算出所述虚拟物品的估价值。

8.一种电子设备，其特征在于，所述电子设备包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为执行权利要求1-5任意一项所述的虚拟物品的数据处理方法。

9.一种计算机可读存储介质，其特征在于，所述存储介质存储有计算机程序，所述计算机程序可由处理器执行以完成权利要求1-5任意一项所述的虚拟物品的数据处理方法。