计费批价方法、装置、电子设备及存储介质

技术领域

本申请涉及计算机应用技术领域，特别是涉及一种计费批价方法、装置、电子设备及存储介质。

背景技术

随着通信技术的快速发展，运营商的业务模式日趋复杂，运营商在为用户提供丰富多彩的电信业务的同时，单个用户实例化的资料和参数的复杂度不断增加，对用户进行计费批价的要求也越来越高。

目前，每次在要对用户进行计费批价时，都需要通过信息处理等方式得到用户的批价资料，进而根据用户的批价资料对用户进行计费批价。如果用户的批价资料较多，则需要耗费较长时间才能得到完整的批价资料，进而需要耗费较长时间才能完成对用户的计费批价，导致批价效率较低，容易影响用户满足度。

发明内容

本申请的目的是提供一种计费批价方法、装置、电子设备及存储介质，以提高批价效率，提升用户满意度。

为解决上述技术问题，本申请提供如下技术方案：

第一方面，提供了一种计费批价方法，包括：

在触发对第一用户进行计费批价的情况下，在第一数据库中查询所述第一用户的批价资料；

根据所述第一用户的批价资料，对所述第一用户进行计费批价；

其中，所述第一数据库中预先存储有多个用户的批价资料，每个用户的批价资料是根据相应用户订购的电信业务确定的。

可选地，所述第一数据库中预先存储的第二用户的批价资料通过以下步骤确定：

在第二数据库中查询所述第二用户订购的电信业务；

分别在每个业务场景中确定所述第二用户订购的每项电信业务对应的批价资料；

其中，所述第二用户为所述多个用户中的任意一个用户。

可选地，所述分别在每个业务场景中确定所述第二用户订购的每项电信业务对应的批价资料，包括：

按照计费业务逻辑，确定多个业务场景的寻址顺序；

根据所述寻址顺序，分别在每个业务场景中确定所述第二用户订购的每项电信业务对应的批价资料。

可选地，所述业务场景包括以下至少一项：

综合虚拟专用网业务场景、亲情网业务场景、主副卡业务场景、大群优惠业务场景、跨域融合业务场景、普通优惠业务场景、普选优惠业务场景、基础套餐业务场景。

可选地，所述第一数据库和/或所述第二数据库为分布式数据库。

可选地，所述第一数据库中预先存储的每个用户的批价资料为二叉树的形式，所述二叉树为事件策略、段落、资费、优惠规则信息按顺序排列组合而成；

所述在第一数据库中查询所述第一用户的批价资料，包括：

对所述第一数据库中预先存储的所述第一用户对应的二叉树进行遍历，根据遍历结果，得到所述第一用户的批价资料。

可选地，所述多个用户的批价资料是通过多台服务器处理得到，每台服务器部署相同的处理进程。

第二方面，提供了一种计费批价装置，包括：

查询模块，用于在触发对第一用户进行计费批价的情况下，在第一数据库中查询所述第一用户的批价资料；

批价模块，用于根据所述第一用户的批价资料，对所述第一用户进行计费批价；

其中，所述第一数据库中预先存储有多个用户的批价资料，每个用户的批价资料是根据相应用户订购的电信业务确定的。

第三方面，提供了一种电子设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如第一方面所述的计费批价方法的步骤。

第四方面，提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如第一方面所述的计费批价方法的步骤。

第五方面，提供了一种计算机程序产品，所述计算机程序产品包括计算机指令，所述计算机指令存储在计算机可读存储介质中，且适于由处理器读取并执行，以使得具有所述处理器的计算机设备执行如第一方面所述的计费批价方法的步骤。

应用本申请实施例所提供的技术方案，在第一数据库中预先存储有多个用户的批价资料，每个用户的批价资料是根据相应用户订购的电信业务确定的，即预先处理得到每个用户的批价资料，并存储到第一数据库中，当触发对第一用户进行计费批价时，在第一数据库中可以直接查询得到第一用户的批价资料，进而根据第一用户的批价资料，进行相应的计费批价操作。在触发对用户进行计费批价时，直接在第一数据库中即可查询得到相应用户的批价资料，缩短了批价资料获取时间，有助于提高批价效率，提升用户满意度。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例中一种计费批价方法的实施流程图；；

图2为本申请实施例中集团VPN业务模式示意图；

图3为本申请实施例中融合关系账户逻辑示意图；

图4为本申请实施例中跨域融合关系示意图；

图5为本申请实施例中批价资料寻址过程示意图；

图6为本申请实施例中分布式数据库结构示意图；

图7为本申请实施例中二叉树结构示意图；

图8为本申请实施例中批价资料寻址位置示意图；

图9为本申请实施例中一种计费批价装置的结构示意图；；

图10为本申请实施例中一种电子设备的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面结合附图和具体实施方式对本申请作进一步的详细说明。显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，，都属于本申请保护的范围。

本申请的核心是提供一种计费批价方法，该方法可以应用于运营商对用户进行计费批价等场景中。

随着通信技术的飞速发展，新的技术、业务层出不穷，运营商针对市场推出符合用户要求的资费产品也越来越复杂，用户受理的计费资料、批价参数也越来越多，这使得计费系统批价计算能力越发显得重要，同时批价的算力能力也成为了制约计费系统效率、提升用户感知的瓶颈之一。

本申请实施例提供的技术方案是在电信运营商计费系统批价之前进行资料或参数寻址，提前集中处理得到所有用户的批价资料，而不是传统方式的在批价过程中逐一寻址得到用户的批价资料，同时为了提升算力资源利用率，采用了分布式业务处理机制及分布式数据库，当资料或业务需要消耗较多资源时，可以实现设备动态扩缩容，同时也具备高可用特性，即使某台设备宕机也不影响业务连续性，保障了用户的良好体验。

本申请实施例在第一数据库中预先存储有多个用户的批价资料，每个用户的批价资料是根据相应用户订购的电信业务确定的，即预先处理得到每个用户的批价资料，并存储到第一数据库中，当触发对第一用户进行计费批价时，在第一数据库中可以直接查询得到第一用户的批价资料，进而根据第一用户的批价资料，进行相应的计费批价操作。在触发对用户进行计费批价时，直接在第一数据库中即可查询得到相应用户的批价资料，缩短了批价资料获取时间，有助于提高批价效率，提升用户满意度。

参见图1所示，为本申请实施例所提供的一种计费批价方法的实施流程图，该方法可以包括以下步骤：

S110：在触发对第一用户进行计费批价的情况下，在第一数据库中查询第一用户的批价资料。

其中，第一数据库中预先存储有多个用户的批价资料，每个用户的批价资料是根据相应用户订购的电信业务确定的。

在本申请实施例中，在对用户进行计费批价之前，可以先处理得到所有用户的批价资料。针对每个用户，可以根据该用户订购的电信业务确定该用户的批价资料。将确定出的每个用户的批价资料存储到第一数据库中，这样第一数据库中即可预先存储有多个用户的批价资料。

可选地，对于任意一个用户而言，在该用户入网后，即可先根据该用户订购的电信业务确定该用户的批价资料，或者，在该用户订购的电信业务发生变化时，根据该用户订购的变化后的电信业务，确定该用户的批价资料，或者，按照一定的周期，如每月，根据该用户订购的电信业务确定该用户的批价资料。

在触发对第一用户进行计费批价的情况下，可以根据第一用户的标识，在第一数据库中查询第一用户的批价资料。第一用户为待计费批价的任意一个用户。第一用户的标识可以是第一用户使用的手机号码。每个手机号码可以对应一个用户。

可选地，可以根据预先设定的批价条件，触发对第一用户进行计费批价。如，在接收到对第一用户的批价指令时，触发对第一用户进行计费批价，或者，在达到对第一用户的批价周期时，触发对第一用户进行计费批价。

S120：根据第一用户的批价资料，对第一用户进行计费批价。

在第一数据库中查询得到第一用户的批价资料后，可以根据第一用户的批价资料，对第一用户进行计费批价。

可选地，如果在第一数据库中未查询得到第一用户的批价资料，则可以根据第一用户订购的电信业务确定第一用户的批价资料，进而根据第一用户的批价资料，对第一用户进行计费批价。

应用本申请实施例所提供的方法，在第一数据库中预先存储有多个用户的批价资料，每个用户的批价资料是根据相应用户订购的电信业务确定的，即预先处理得到每个用户的批价资料，并存储到第一数据库中，当触发对第一用户进行计费批价时，在第一数据库中可以直接查询得到第一用户的批价资料，进而根据第一用户的批价资料，进行相应的计费批价操作。在触发对用户进行计费批价时，直接在第一数据库中即可查询得到相应用户的批价资料，缩短了批价资料获取时间，有助于提高批价效率，提升用户满意度。

在本申请的一些实施例中，第一数据库中预先存储的第二用户的批价资料通过以下步骤确定：

步骤一：在第二数据库中查询第二用户订购的电信业务；；

步骤二：分别在每个业务场景中确定第二用户订购的每项电信业务对应的批价资料；

其中，第二用户为多个用户中的任意一个用户。

为方便描述，将上述两个步骤结合起来进行说明。

在本申请实施例中，第一数据库中预先存储有多个用户的批价资料，第二用户为多个用户中的任意一个用户。

第二数据库中可以存储当前已入网所有用户的电信业务订购信息。对于第二用户而言，可以先在第二数据库中查询得到第二用户订购的电信业务。可选地，可以根据第二用户的标识进行查询。第二用户的标识可以是第二用户使用的手机号码。

查询得到第二用户订购的电信业务后，进一步可以分别在每个业务场景中确定第二用户订购的每项电信业务对应的批价资料。可选地，针对每个业务场景，可以确定第二用户订购的每项电信业务是否属于该业务场景中的销售品，如果属于，则可以根据该销售品，确定相应电信业务对应的批价资料。

分别在每个业务场景中确定第二用户订购的每项电信业务对应的批价资料，有助于得到第二用户完整准确的批价资料。

第二用户为多个用户中的任意一个用户，对于任意一个用户都可以通过上述方式处理得到相应的批价资料，进而可以将多个用户的批价资料预先存储到第一数据库中，以在触发对用户进行计费批价时，在第一数据库中查询相应的批价资料，提高批价效率。

在本申请的一些实施例中，分别在每个业务场景中确定第二用户订购的每项电信业务对应的批价资料，可以包括以下步骤：

第一个步骤：按照计费业务逻辑，确定多个业务场景的寻址顺序；

第二个步骤：根据寻址顺序，分别在每个业务场景中确定第二用户订购的每项电信业务对应的批价资料。

为方便描述，将上述两个步骤结合起来进行说明。

在本申请实施例中，可以预先确定计费业务逻辑。可选地，可以根据业务优先级确定计费业务逻辑。根据计费业务逻辑，可以确定多个业务场景的寻址顺序。在各业务场景中确定批价资料的过程也可认为是一种批价资料寻址过程。

业务场景可以包括以下至少一项：

1)综合虚拟专用网(Integrated Virtual Private Network，IVPN)业务场景；IVPN是在公共交换电话网(Public Switched Telephone Network，PSTN)和公共陆地移动网(Public Land Mobile Network，PLMN)上建立一个逻辑话路专用网。IVPN通过综合的智能平台，可以扩展企业集中小交换业务(Central office exchange service，Centrex)至移动网络，实现固定电话和移动手机等多种终端的短号互打，群内呼叫可以免费。IVPN业务是指互联网协议(Internet Protocol，IP)虚拟专网业务(VPN+)，其依托于下一代承载网，采用多协议标记交换(Multi-Protocol Label Switching，MPLS)方式，为用户在多个节点间实现IP虚拟专网功能，提供安全的数据信息传输服务。可将分布在不同区域的用户组成一个逻辑专网。1～N个用户入群，网内用户之间可以使用短号或真实号码互相拨打免费。根据用户资料的标识分为综合(Virtual Private Network，VPN)、集团VPN和虚拟VPN三种业务。如果有标识就进入IVPN寻址过程。如图2所示，一个IVPN集群下包含多个闭合群，每个闭合群下包含一个或者多个号码；闭合群下的每个号码可以是本地也可以是异地的；一个IVPN下不包含游离的号码，针对游离的号码可以组合成一个特殊的闭合群，主要体现在资费上不一样；一个IVPN可以设定一组亲情号码。通过群组关系找到定价计划后，直接使用定价计划作为批价资料。

2)亲情网业务场景；

全国亲情网业务是一项通话优惠业务，用户组网后可享受亲情网内所有成员国内互打不限时长优惠，不含设定地区。只允许当前运营商手机用户创建全国亲情网，创建亲情网的号码即为该网的发起人(主号)，一个用户只可创建或加入一个亲情网，一个全国亲情网中只能有一个主号。亲情网的成员可以是省内号码，也可以是省外号码，两个及以上用户即可组网。全国亲情网业务共包含两种销售品，分别适用于主号和成员订购。根据用户主被叫号码在产品关系资料表中的标识是否一致来判断是否享受亲情网优惠批价。以一个主号A有三个亲情号码B、C、D为例，单向：是指A拨打B、C、D才算亲情通话，B、C、D拨打A不算亲情通话；双向：是指A拨打B、C、D、或B、C、D拨打A都算亲情通话，但B、C、D之间互打不算亲情通话；；互拨：是指A、B、C、D互拨都算亲情通话。

3)主副卡业务场景；

集团主副卡模型通过套餐明细体现，将主副卡同时与基础套餐建立订购关系，通过角色标识区分当前产品是主卡还是副卡。如图3所示，主副卡之间为融合关系同账户，共享一个套餐的资源进行批价。该业务场景主要记录主副卡资料标识，批价时调用相同的量本。

4)大群优惠业务场景；

大群优惠销售品记录，不需要实例化，直接从表中获取有效销售品后查询定价计划作为批价资料，进行后续的批价处理。

5)跨域融合业务场景；

针对自主融合套餐，将移动产品和固网产品同时与融合促销销售品建立销售品产品实例关系，从而达到共享一个量本进行批价的目的，根据产品关系表的资料进行打标处理。可跨账务虚拟组网，如图4所示，政企大客户在省内四个地市同时有业务，需建立统一收费、共享套餐池业务，业务受理上需将四个本地网账户A、账户B、账户C、账户D虚拟组网成一个群，同时设置该群的收费账户，批价寻址通过受理实例共享流量池，收费收在指定账户下。

6)普通优惠业务场景；

查找用户实例订购的其他优惠资料，打标获得批价资料。普通优惠支持四种模式，A1：用户级、E1：账户级、R1：捆绑群组级、G1：亲情网，通过不同的优惠实例模式进行批价优惠。

7)普选优惠业务场景；

针对普选优惠，不再由客户关系管理(Customer Relationship Management，CRM)对每个用户进行实例化操作，改由计费默认挂载一个普适性的套餐(全网所有用户)。主要针对主套餐封顶资料打标。

8)基础套餐业务场景；

如用户无以上各类优惠套餐时，使用基础套餐作为批价资料，即标准资费批价。

按照计费业务逻辑，确定多个业务场景的寻址顺序。比如，确定的寻址顺序为上述八项业务场景的顺序。

按照寻址顺序，可以分别在每个业务场景中寻址得到第二用户订购的每项电信业务对应的批价资料，从而得到第二用户的批价资料，即批价结果文件，如图5所示。这样有助于提高批价资料确定的准确性。

在本申请的一些实施例中，第一数据库和/或第二数据库为分布式数据库。

在本申请实施例中，第一数据库中预先存储有多个用户的批价资料，第二数据库中可以存储当前已入网所有用户的电信业务订购信息。第一数据库和第二数据库可以是同一数据库，还可以是独立的不同数据库。

随着用户资料的不断增长，需要弹性扩容增加数据库存储容量，同时为节省算力，提升存储资源利用率，本申请实施例将第一数据库和/或第二数据库构建为分布式数据库，提出独立高效的分布式资料存储及读取机制。

如图6所示，该分布式数据库可以是基于关系型数据库管理系统，如MySQL的分布式数据库，该数据库具备弹性扩缩容功能，并且随着资料的增长可以动态扩缩容，将系统资源利用率最大化，其次寻址业务也部署在基于JSTORM的分布式处理框架，提升了算力。其中，TeleDB是一种基于开源MySQL数据库系统加上相关功能组件架构而成的一款易用、易安装的数据库集群系统。

即该分布式数据库由分布式数据库集群部署得到，分布式数据库集群包含多个服务器组，每个服务器组包含多台服务器，如包含一主两从三台服务器，用于存储用户资料及参数，如存储用户的批价资料，和/或存储已入网用户的电信业务订购信息。分布式数据库集群通过分布式应用程序协调服务，如ZooKeeper进行管理，能够进行横向扩缩容。

随着运营商用户和业务的不断发展，需要存储的用户资料及参数会越来越多，传统存储方式扩容空间有限，本申请实施例提供的存储架构可以横向扩容较多数据库节点，提升服务器的存储能力。同时，一主两从的服务器部署架构保障了数据库的高可用性，即使一台甚至两台服务器宕机也不影响数据库的正常使用。另外，分布式数据库集群的建设成本较低，可以节省资源投入的成本，提升系统的扩展性和可靠性。

其中，分布式数据库的分片算法采用对分片键取模、取余分片方式：分片键(一个列，可以是主键)与服务器节点数量进行取余，得到余数，将数据写入余数对应的服务器节点。分片键标识可以是用户标识的哈希值，例如两个服务器节点的分布式数据库，分片键id＝1，1％2＝1，则该分片键对应用户的用户资料落在标识为1的服务器节点上，分片键id＝2，2％2＝0，则该分片键对应用户的用户资料落在标识为0的服务器节点上。

在本申请的一些实施例中，多个用户的批价资料是通过多台服务器处理得到，每台服务器部署相同的处理进程。

本申请实施例采用分布式批价资料寻址处理机制，通过多台服务器处理得到多个用户的批价资料，在多台服务器的每台服务器上均部署相同的处理进程，可以采用分布式实时计算引擎，如JSTORM流处理机制，及哈希一致性分片算法。可以先获取用户标识，通过哈希算法得出具体的值，然后再对服务器节点数取模，得到的结果就是这个用户被分配的处理服务器。例如用户标识是23，先对23做哈希计算，假设得到的值是17，将这个哈希值对服务器节点数4进行取模，17％4＝1，则这个用户就被分配到服务器节点1进行处理。

通过多台服务器分布式处理得到多个用户的批价资料，有助于提高处理效率。

在本申请的一些实施例中，第一数据库中预先存储的每个用户的批价资料为二叉树的形式，二叉树为事件策略、段落、资源、优惠规则信息按顺序排列组合而成；

在第一数据库中查询第一用户的批价资料，可以包括以下步骤：

对第一数据库中预先存储的第一用户对应的二叉树进行遍历，根据遍历结果，得到第一用户的批价资料。

在本申请实施例中，根据各业务场景找到对应的销售品，通过事件策略找对应的段落、资费、优惠。将销售品对应的事件策略、段落、资费、优惠规则信息按顺序排列，可以组合成一棵二叉树。对第一数据库中预先存储的第一用户对应的二叉树进行遍历，根据遍历结果，可以得到第一用户的批价资料。

二叉树遍历规则如下：

1)对于树中的每个节点，它的左子树中的所有值都小于该节点的值，而它的右子树中的所有值都大于该节点的值；

2)左子树和右子树也是二叉树。

基于这些特性，可以使用以下原理进行二叉树的遍历操作，如图7所示：

从根节点开始，将要查找的值与当前节点的值进行比较；；

如果查找值等于当前节点的值，则返回当前节点；

如果查找值小于当前节点的值，则在当前节点的左子树中继续查找；

如果查找值大于当前节点的值，则在当前节点的右子树中继续查找；

重复上述步骤，直到找到目标值或者遍历到叶子节点。

如果遍历到叶子节点仍未找到目标值，则表示目标值不存在于树中。

通过这种方式，可以实现高效的遍历操作。由于每次遍历都会根据目标值与当前节点的比较结果进一步缩小查找范围，平均时间复杂度为O(log n)，其中n是树中节点的数量。

需要说明的是，本申请实施例的批价资料寻址过程在话单采集预处理之后、对用户正式批价之前，对用户实例参数集中获取并处理得到所有用户的批价资料，如图8所示，对话单预处理后，查询用户订购的电信业务，即产品实例，根据产品实例进行批价资料寻址，得到批价资料，在计费批价时，根据定价计划得到定价组合，根据事件类型确定事件定价策略，得到定价段落，进一步确定资费标准和优惠计算。对批价资料进行集中处理可以节省算力，提升资源利用率。

为方便理解，下面通过具体示例对本申请实施例进行说明。

步骤一：计费系统批价服务器通过主被叫用户号码，获取用户实例ID，区分同网、异网进入定价资料寻址环节。

步骤二：根据步骤一资料校验确定主被叫用户实例ID、主被叫用户网类型，进入定价寻址流程。定价寻址流程包括VPN流程、亲情号码流程、主副卡流程、自主融合流程、IVPN流程。上述流程均需要查询主被叫的主产品实例信息与销售品产品实例关系，再通过判断主被叫的角色标识或关系类型来判定是走上哪个寻址流程。

1)、查询主被叫号码的产品实例，获取产品实例信息；

2)、查询主被叫产品实例关系，增强群组VPN类型；

3)、查询主被叫的销售品产品实例关系获取销售品编码；；

4)、若主被叫均能查询出上述信息，则为同网用户，按下列优先级依次进行判断：亲情号码、主副卡判断；

5)、根据上述环节获取到销售品编码获取定价计划编码；；

6)、查询量本对象实例获取流量卡相关定价编码。

步骤三：根据步骤二寻址找到对应的销售品，通过事件策略找对应的段落、资费、优惠规则信息。将销售品对应的事件策略、段落、资费、优惠规则信息按顺序排列，组合成一棵二叉树，根据二叉树的遍历结果得到批价结果文件。

总体而言，本申请实施例在运营商计费系统批价过程中可以快速高效访问计费批价资料及参数，用户批价通过主被叫号码或其产品实例查询订购关系，获取可以使用的销售品或批价参数，包括：IVPN、亲情网、主副卡、大群优惠、跨域融合、普通优惠、普选优惠、基础套餐等的定价寻址逻辑，并将这些资料存储在分布式数据库中，提升了批价计算效率，降低了系统部署及运维成本。

本申请实施例在不增加系统投入的情况下，提供了一种分布式、高效率、高可靠的计费批价方案。

相较于传统方案，本申请实施例对批价资料进行集中处理，效率更高，提高了批价处理效率，缩短了批价处理时间。

相较于传统部署模式，本申请实施例提供了分布式系统架构和处理机制，在资料存储方面也提供了一套分布式、高可用的系统架构，其具有较强扩展能力、弹性伸缩能力和高可用能力。

本申请实施例的分布式数据库可以通过个人计算机(Personal Computer，PC)机部署，较传统大型服务器部署更加节省成本。

本申请实施例基于MySQL的分布式数据库资料存储和读取，通过梳理业务大类，重新组合批价资料或参数的寻址方式，并采用分布式业务处理机制，提升了计费系统批价过程的效率，提升了计费系统准确性，从而提升客户满意度。

相应于上面的方法实施例，本申请实施例还提供了一种计费批价装置，下文描述的计费批价装置与上文描述的计费批价方法可相互对应参照。

参见图9所示，计费批价装置900可以包括以下步骤：

查询模块910，用于在触发对第一用户进行计费批价的情况下，在第一数据库中查询第一用户的批价资料；

批价模块920，用于根据第一用户的批价资料，对第一用户进行计费批价；

其中，第一数据库中预先存储有多个用户的批价资料，每个用户的批价资料是根据相应用户订购的电信业务确定的。

应用本申请实施例所提供的装置，在第一数据库中预先存储有多个用户的批价资料，每个用户的批价资料是根据相应用户订购的电信业务确定的，即预先处理得到每个用户的批价资料，并存储到第一数据库中，当触发对第一用户进行计费批价时，在第一数据库中可以直接查询得到第一用户的批价资料，进而根据第一用户的批价资料，进行相应的计费批价操作。在触发对用户进行计费批价时，直接在第一数据库中即可查询得到相应用户的批价资料，缩短了批价资料获取时间，有助于提高批价效率，提升用户满意度。

在本申请的一些实施例中，计费批价装置900还包括确定模块，用于通过以下步骤确定第一数据库中预先存储的第二用户的批价资料：：

在第二数据库中查询第二用户订购的电信业务；

分别在每个业务场景中确定第二用户订购的每项电信业务对应的批价资料；

其中，第二用户为多个用户中的任意一个用户。

在本申请的一些实施例中，确定模块，用于：

按照计费业务逻辑，确定多个业务场景的寻址顺序；

根据寻址顺序，分别在每个业务场景中确定第二用户订购的每项电信业务对应的批价资料。

在本申请的一些实施例中，业务场景包括以下至少一项：：

综合虚拟专用网业务场景、亲情网业务场景、主副卡业务场景、大群优惠业务场景、跨域融合业务场景、普通优惠业务场景、普选优惠业务场景、基础套餐业务场景。

在本申请的一些实施例中，第一数据库和/或第二数据库为分布式数据库。

在本申请的一些实施例中，第一数据库中预先存储的每个用户的批价资料为二叉树的形式，二叉树为事件策略、段落、资费、优惠规则信息按顺序排列组合而成；

查询模块，用于：

对第一数据库中预先存储的第一用户对应的二叉树进行遍历，根据遍历结果，得到第一用户的批价资料。

在本申请的一些实施例中，多个用户的批价资料是通过多台服务器处理得到，每台服务器部署相同的处理进程。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

相应于上面的方法实施例，本申请实施例还提供了一种电子设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行计算机程序时实现上述计费批价方法的步骤。

如图10所示，为电子设备的组成结构示意图，电子设备可以包括：处理器10、存储器11、通信接口12和通信总线13。处理器10、存储器11、通信接口12均通过通信总线13完成相互间的通信。

在本申请实施例中，处理器10可以为中央处理器(Central Processing Unit，CPU)、特定应用集成电路、数字信号处理器、现场可编程门阵列或者其他可编程逻辑器件等。

处理器10可以调用存储器11中存储的程序，具体的，处理器10可以执行计费批价方法的实施例中的操作。

存储器11中用于存放一个或者一个以上程序，程序可以包括程序代码，程序代码包括计算机操作指令，在本申请实施例中，存储器11中至少存储有用于实现以下功能的程序：

在触发对第一用户进行计费批价的情况下，在第一数据库中查询第一用户的批价资料；

根据第一用户的批价资料，对第一用户进行计费批价；

其中，第一数据库中预先存储有多个用户的批价资料，每个用户的批价资料是根据相应用户订购的电信业务确定的。

在一种可能的实现方式中，存储器11可包括存储程序区和存储数据区，其中，存储程序区可存储操作系统，以及至少一个功能所需的应用程序等；存储数据区可存储使用过程中所创建的数据。

此外，存储器11可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件或其他易失性固态存储器件。

通信接口12可以为通信模块的接口，用于与其他设备或者系统连接。

当然，需要说明的是，图10所示的结构并不构成对本申请实施例中电子设备的限定，在实际应用中电子设备可以包括比图10所示的更多或更少的部件，或者组合某些部件。

相应于上面的方法实施例，本申请实施例还提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述计费批价方法的步骤。

此外，需要说明的是：本申请实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或者计算机程序可以包括计算机指令，该计算机指令可以存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器可以执行该计算机指令，使得该计算机设备执行前文所对应实施例中计费批价方法的描述，因此，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。对于本申请所涉及的计算机程序产品或者计算机程序实施例中未披露的技术细节，，请参照本申请方法实施例的描述。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的技术方案及其核心思想。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。