具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
正如前述,在现有技术中,若要对业务提供商在提供业务的过程中所生成的业务数据的统计属性进行统计时,通常是在业务数据生成后,从相应的业务数据表中对某种属性进行统计,或者,事前在业务程序中写入相应的计数程序,以对所需的某统计属性进行统计。前一种方式由于业务数据表中包含大量的业务数据,针对业务数据表使用相应的查询语句进行统计耗时较长,也会增加服务器的工作负荷;后一种方式中,每一种计数程序仅能对一种统计属性进行统计,如果需要多种统计属性,就要在业务程序中写入多种计数程序,在这些计数程序同时运行时,将影响业务性能(为了便于描述,以下将业务数据表简称为:数据表)。
显然,这就需要一种在对计数对象进行计数的过程中,效率较高、且不会影响业务性能的计数方式,基于此,在本申请实施例中,提供了一种针对业务数据的计数方法,以实现对计数对象进行统计的过程中,不依赖于数据表或是嵌入业务程序的计数程序进行查询。
需要说明的是,本申请实施例中的针对业务数据的计数方法基于如图1a所示的架构。对于图1a所示的架构而言,在图1a中,业务服务器用于提供相应的业务服务,当用户使用了该业务服务后,则业务服务器将生成相应的业务数据,并存储于数据库中。当然,业务服务器可采用诸如:增、删、改等操作将业务数据存储于数据库中。而图1a中的计数服务器,则独立于业务服务器,用于提供计数业务。某些场景下,计数服务器可看作是业务服务器中的计数功能单元。可以理解,为了不增加业务服务器的运行负荷,在本申请实施例中,计数服务器可看作独立于业务服务器。这里并不构成对本申请的限定。
上述的业务服务器可理解为业务提供方后台的、用于提供业务服务的服务器,在一种实施例场景下,业务提供方可提供各类业务服务,相应地,就需要不同的业务服务器实现,那么,可以认为,在本申请实施例中,图1a中所示的架构可以针对于提供不同业务服务的业务服务器,如:图1a中的业务服务器为支付服务器,用于提供支付业务;又如:业务服务器为账户服务器,用于提供账户的注册、管理业务。换言之,在本实施例场景下,对于每一种业务服务的业务服务器而言,均可采用该架构。
在另一种实施例场景下,图1a所示的业务服务器也可以理解为业务提供方所有业务服务所对应的业务服务器,即,图1a中的业务服务器是各类业务服务所对应的业务服务器的统称,业务服务器所生成的业务数据将存储于数据库中。
还需要说明的是,在如图1a所示的架构下,业务服务器与数据库之间的业务流程如图1b所示,在图1b中可见,业务服务器在业务操作的作用下,便会执行相应的业务处理,进一步生成业务数据,再将业务数据存储至数据库中。
基于以上内容,下面将对本申请实施例中所提供的针对业务数据的计数方法进行详细说明:
如图1c所示,为本申请实施例中的针对业务数据的计数过程,该方法应用于与业务流程相独立的计数流程中,具体包括以下步骤:
S101:获取业务流程中生成的业务数据。
如图1b所示,在业务流程中,当业务服务器接收到了相应的业务操作后,便会进行业务处理,从而生成业务数据,当然,这里的业务操作,可以是以用户为执行主体所发出,例如:用户使用网站提供的账户注册业务,当用户填写了相应信息并执行注册操作后,在网站后台的服务器中就会生成一条该用户数据(即,业务数据)。又例如:用户使用网站提供的在线支付业务,并支付相应的金额后,服务器将会生成一条支付数据(即,业务数据)。
当业务服务器生成了业务数据后,便可以获取到该业务数据。对业务数据的获取,具体可由独立于上述业务服务器的其他服务器所完成,也即,如图1a所示的计数服务器,或是由业务服务器中的特定的计数功能单元实现,这里并不构成对本申请的限定。但无论采用何种方式,本步骤中获取业务数据的过程都将独立于如图1b所示的业务流程,从而将不会对业务流程造成影响。
S102:根据预设的计数配置信息,确定获取到的所述业务数据对应的计数对象。
计数配置信息可用于标明需要进行计数的业务数据(也即,计数配置信息能够从业务数据中标示出计数对象),考虑到在实际应用中,部分业务操作通常均会带来业务数据的变化(如:涉及到业务数据的增、删、改等,均会造成业务数据的改变),那么,作为一种默认方式,通过计数配置信息,可以将发生了改变的业务数据作为一种计数对象,例如:账户中资源数量发生变更,那么,便可以将资源数量作为一种计数对象。当然,在另一种方式中,还可以根据实际应用的需要,针对某些业务数据设定计数对象。例如:用户浏览新闻时,其业务操作实质属于一种数据的查询操作,在数据表中,往往仅记录了用户每一次查询操作(可以认为,该过程中并未发生业务数据的改动),那么,在此情况下,可以将用户的浏览次数设定为计数对象。
换言之,在本申请实施例中,所述的计数对象既可以是业务数据所对应的业务数值(如:金额值、日期、存储空间容量等等),也可以是一种业务关系数值(如:用户的好友数量、用户发布文章的转发次数、新闻的浏览次数等)。当然,这里并不构成对本申请的限定。
S103:更新该计数对象对应的索引表。
当确定了业务数据对应的计数对象之后,为了便于对该计数对象进行计数,本申请实施例中采用索引表的方式。可以认为,由于计数对象属于业务数据的某一项属性或某几项数据,那么,针对计数对象所生成的索引表中的数据量将远小于数据表中的业务数据的数量,通过索引表能够便捷地对其中的计数对象进行计数,而且,索引表可看作是数据表中某项属性的一种索引,与数据表具有相应的关联关系,通过索引表中的数据,也能够对数据表进行查询。
本申请实施例中所述的索引表,通常是一种二级索引表(下文中统称为索引表),但在某些特殊的实际应用场景中,也可以采用多级索引表的方式,这里并不构成对本申请的限定。
例如:假设针对用户使用支付业务的场景而言,用户进行一次支付操作,支付业务服务器将生成一条支付业务数据,该支付业务数据中可能包括:用户ID、支付额度、支付时间、支付对象、支付单号等数据,那么,在此假设计数对象仅是用户的支付笔数,其索引表可以如下表1所示:
支付单号 |
用户ID |
1001 |
user1 |
1002 |
user1 |
表1
从表1中可见,索引表中仅包含用户ID、支付单号(可以理解,支付单号作为一种计数对象的标识,用于标示出每一笔支付操作)这两类数据,相较于数据表中大量的数据而言,索引表能够有效地减少数据量。当然,作为本申请实施例中的一种扩展方式,在如表1所示的索引表的基础上,可以根据实际应用的需要增加相应的附属信息,例如:可以在表1的基础上,增加每一笔支付操作的支付金额信息,也即,如下表2所示。
支付单号 |
用户ID |
支付额度 |
1001 |
user1 |
123 |
1002 |
user1 |
321 |
表2
当然,这里仅是对索引表的一种简单示例,这里并不构成对本申请的限定。
从上述示例中可见,对索引表的更新过程体现在:当用户进行了2次支付操作后,则索引表中将增加2条数据,而在某些场景下,还会从索引表中删除相应数量的数据,如:对用户的好友进行计数的索引表中,如果用户删除了一名好友,则计数服务器将在索引表中删除相应的一条数据。这里并不构成对本申请的限定。
S104:基于所述索引表对所述计数对象进行计数。
作为本申请实施例中的一种方式,基于索引表对计数对象进行计数的过程,也可采用诸如SQL中的select语句,或其他的查询语句实现,显然,在索引表中进行查询的效率将远高于在数据表中进行查询的效率。
延续如表1所示的上例,在创建了索引表的基础上,便可对计数对象(也即,用户的支付笔数)进行计数,具体而言,表1中的每一条数据代表一笔支付操作,那么,对表1中业务数据的条数计数,也就得到了用户的支付笔数,即,用户共进行了2笔支付操作。
此外,如果索引表中包括附属信息,则还可以实现对附属信息的计数,例如:针对表2而言,可进行支付金额的计数,可知用户的两笔支付操作的总金额为:123+321=444。
同样,基于索引表对计数对象进行计数的过程,将独立于业务服务器的业务流程(图1b所示的业务流程),也就是说,业务服务器中的业务程序并不会在生成业务数据后额外地执行计数过程,从而保证了业务程序的性能。
需要说明的是,结合上述步骤S103及本步骤S104,采用计数配置信息和索引表的方式,将独立于如图1b所示的业务流程,从而不需要在业务程序中写入计数程序,换言之,创建计数对象的索引表的过程,将不会影响业务服务器的业务流程,也就是说,业务服务器在生成了相应的业务数据后,仍会按照业务流程将业务数据存储于数据库中。因此,结合以上内容,本申请实施例中的对计数对象的计数流程可以如图2所示。
通过上述步骤,当业务服务器基于正常的业务流程而生成相应的业务数据后,具有计数功能的计数服务器便可以获取到业务流程中生成的业务数据,根据实际应用的需要,可以针对不同业务流程预先设定相应的计数配置信息,计数配置信息标明了需要执行计数操作的业务数据中的某个(或某些)属性,也就是计数对象,进而基于计数对象更新索引表,索引表中的索引数据就可以体现出计数对象的数量,从而,对索引表中的数据进行计数,也就实现了对计数对象的计数过程。本申请实施例中的获取业务数据、更新索引表、计数的过程,均独立于业务服务器中的业务流程,也就是说,无需在业务服务器的业务程序中写入额外的计数程序,显然,也就不会影响业务程序在正常执行时的业务性能;并且,索引表相对于数据库中的数据表而言,其中的数据量极小,基于索引表对计数对象进行计数的过程,所消耗的时长以及处理资源均极小,可以高效地得到计数结果。
在实际应用场景中,若要实现前述内容中对计数对象的计数过程,可采用相应的拦截技术,换言之,基于拦截技术,可在不影响业务流程的情况下,获得业务流程中生成的业务数据,并基于获得到的业务数据,独立于业务流程完成对计数对象计数。
作为本申请实施例中的一种可选方式,面向切面编程(Aspect OrientedProgramming,AOP)能够在不改变原有业务流程(不用在业务程序写入新的代码)的情况下,实现在业务中增加特定的功能。所以,可采用AOP实现上述获取业务数据、创建索引表、基于索引表对计数对象进行计数等独立于业务流程的过程。
在业务数据的获取阶段,业务服务器会将其生成的业务数据存储至数据库中,在此过程中,作为本申请实施例中的一种方式,可以通过诸如:接收业务服务发送的消息、获取业务服务对应的业务日志等方式获得业务数据。
作为本申请实施例中的另一种方式,也可在业务流程中生成业务数据的位置设置“拦截器(Counter Interceptor)”,该“拦截器”可以将业务流程中所生成的业务数据进行“拦截”,从而获取到相应的业务数据。当然,需要说明的是,拦截器的存在并不影响业务流程的正常运行,在实际应用中,拦截器所获取到的业务数据将在后续进行独立于业务流程的计数操作。在本申请实施例中,拦截器将会自行调用业务程序中的业务方法,或者,可在业务程序中设定拦截器的调用类,那么,当业务程序执行至生成业务数据的过程时,将调用拦截器的方法。上述的两种方式均可以使得拦截器获取到业务数据。
在获取到了业务数据之后,将确定出相应的计数对象。在本申请实施例中,计数对象的确定将依赖于预先设定的计数配置信息。所述预设的计数配置信息,包含针对各业务流程中指定的业务数据所设置的计数标识,以及所述指定的业务数据在所述业务流程所对应的数据表中的元数据。
具体而言,在实际应用中,通过业务流程能够获知该业务所要生成的业务数据的各类属性以及相应的描述信息。例如:当用户使用绑卡业务的过程中,用户会使用自身的网站账户与自身的银行卡进行绑定操作,以便于后续的支付、转账等业务,在该过程中,当用户绑定了某张银行卡后,该绑卡业务的业务流程中将建立账户与银行卡ID之间的关联关系,如果后续想要统计该用户所绑定的银行卡的数量,那么,便可以将与账户建立了绑定关系的银行卡作为计数对象,换言之,这里进行绑定的银行卡就是所要指定的业务数据。此外,在执行绑定的过程中,业务服务器还会生成诸如:业务类型(如:绑卡业务)、资源类型(如:银行卡)、资源ID(如:银行卡号)等业务数据,这些业务数据最终将存储在数据库的数据表中,并且,这些业务数据可用于描述计数对象所对应的业务数据,即,这些业务数据便可以看作是计数对应所对应的业务数据的元数据。
在上例中,指定的业务数据就是执行了绑定操作后的银行卡标识(每一张银行卡具有唯一的标识,对银行卡ID的计数,也就是对绑定的银行卡数量的计数),所以,计数配置信息中就可对银行卡ID设置计数标识;用于描述该银行卡ID的相关业务数据,可作为该银行卡ID的元数据。
在预设有计数配置信息的基础上,对于获取到的业务数据,也就可以确定出业务数据所对应的计数对象,其过程具体为:根据所述计数配置信息中的计数标识,在获取到的业务数据中,确定所述计数标识所对应的业务数据,根据所述计数标识所对应的业务数据,确定计数对象。
计数配置信息中所携带的计数标识,用来定义业务数据中需要进行计数的某项属性或某几项属性,故在本申请实施例中,从获取到的业务数据中确定出计数标识所对应的业务数据,作为计数对象。
例如:假设获取到的业务数据是某用户的支付业务数据,这些支付业务数据中包含了每一笔支付业务的支付时间、支付状态、所支付的对象、订单号、支付额度等数据;假设实际应用中需要对支付笔数进行计数,以便后续获知用户的支付总次数、或者是不同时间段内的支付次数等,那么,在本示例中,将会把支付业务数据中的支付笔数确定为计数对象。进一步地,每一笔支付业务将对应唯一的订单号,所以,对支付笔数的计数,也就是对订单号数量的计数,基于此,针对支付业务数据的计数标识定义为:订单号。后续,只需针对订单号的数量进行计数即可。
确定了计数对象,也就可以针对计数对象进行计数,在本申请实施例中,对计数对象的计数过程采用索引表的方式,具体而言,由于计数配置信息中包含指定的业务数据(即,计数对象)的元数据,那么,也就可以根据这些元数据更新相应的索引表,换言之,更新该计数对象对应的索引表,具体包括:确定所述计数配置信息中包含的、该统计对象所对应的业务数据的元数据,根据所述元数据及该计数对象对应的业务数据的参数,更新该计数对象所对应的索引表。
可以认为,元数据能够描述计数对象所对应的业务数据所属的业务类型、计数对象的名称、在数据表内的存储位置等等信息,那么,根据元数据便可以实现索引表与数据表之间的关联。业务数据的参数,可以理解为业务数据的具体取值,如:具体的银行卡ID、支付金额等等。
基于此,根据所述元数据及该计数对象对应的业务数据的参数,更新该计数对象所对应的索引表的过程具体包括:根据所述元数据,确定索引表的键,根据所述计数对象对应的业务数据的参数,确定各键对应的值,基于所述键和值更新索引表。
例如:假设用户使用银行卡的绑定业务,该绑定业务的计数标识信息所携带的计数标识对应于银行卡数据,其元数据包括了支付金额、用户ID、订单号,计数对象的业务数据的参数为:userID:user1;支付金额:123及321;订单号:1001及1002。基于此,所创建的索引表如下表3所示。
用户ID |
支付金额 |
订单号 |
user1 |
123 |
1001 |
user1 |
321 |
1002 |
表3
此外,需要说明的是,为了使得索引表适用于不同的业务服务,故在本申请实施例中的索引表可以采用较为通用的表结构,具体而言,其中的索引数据可以包括:用户ID、业务类型、资源类型、资源ID等。
用户ID,包括但不限于:用户的账户名、姓名、证件号等用来标示用户的标识。业务类型可以是业务服务所属的类型,如:支付、提现、订阅等。资源类型可以是业务服务中具体涉及的业务资源,如:用户使用绑卡业务,那么,资源是银行卡;又如:用户使用支付业务,则资源可以是支付业务的订单。资源ID可以是用来标示资源的标识,如:银行卡ID、订单号等。
基于此,创建的索引表可以如下例:假设用户使用银行卡的绑定业务,索引表如下表4所示。
user1 |
支付 |
银行卡 |
1234 |
user1 |
支付 |
银行卡 |
1235 |
表4
表4示出了一种计数对象的索引表的简单方式,在表4中,第一列为用户ID(这里使用user1代表该用户,实际应用中的用户ID不限于此);第二列为业务类型;第三列为资源类型;第四列为银行卡ID。
通过每一条索引数据均可以在数据表中查询到相应的业务数据,如:通过银行卡ID,可以在数据表中查询到具体的银行卡号、所属银行等更为具体的数据。
此外,仍以表4为例:每当用户进行绑卡操作后,在表4中将增加一条数据,当然,如果用户针对已绑定的某张银行卡进行解绑操作,那么,表4中的数据将减少一条。换言之,表4中的数据的条数也就能够反映出用户所持有的银行卡的数量。
在更新了索引表后,便可以实现对计数对象的计数操作,具体而言,基于所述索引表对所述计数对象进行计数,具体包括:按照预设的查询条件,在所述索引表中对满足该查询条件的所述计数对象进行计数。
具体来说,假设作为上述表4的一种扩展方式,若表4的数据中还包括绑定银行卡的时间数据,那么,便可以使用相应的查询语句,查询指定时间段内(如:最近三个月内)用户所绑定的银行卡的数量。当然,这里并不构成对本申请的限定。
经过上述内容,使用索引表的方式相较于从数据表中查询相应的业务数据以进行计数的方式而言,更加便捷快速,也能够较为有效地降低服务器的处理资源消耗,并且,上述计数过程均独立于业务流程之外,相较于现有在业务程序中写入计数器的方式而言,本申请中的上述计数方式将不会对业务流程造成影响,即,不会造成业务程序的性能负担。
此外,索引表与数据表之间具有关联关系,该索引表中的数据可作为数据表中业务数据的一种索引,通过索引表数据能够提升对数据表内业务数据的查询效率。同时,索引表中存储的数据属于计数对象所对应的业务数据,那么,根据索引表也就可以获得计数对象的计数结果,增加了数据表中的查询维度。
以上为本申请实施例提供的针对业务数据的计数方法,基于同样的思路,本申请实施例还提供一种针对业务数据的计数装置,如图3所示。
在图3中,针对业务数据的计数装置独立于业务服务器和数据库,其表示进行计数的过程将独立于业务流程,当然,在一些实际应用场景下,针对业务数据的计数装置也可以设置于业务服务器内,这里并不构成对本申请的限定。
所述装置包括:
获取模块301,获取业务流程中生成的业务数据;
计数对象模块302,根据预设的计数配置信息,确定获取到的所述业务数据对应的计数对象;
索引表模块303,更新该计数对象对应的索引表;
计数模块304,基于所述索引表对所述计数对象进行计数。
更为具体地:
所述预设的计数配置信息,包含针对各业务流程中指定的业务数据所设置的计数标识,以及所述指定的业务数据在所述业务流程所对应的数据表中的元数据。
进一步地,所述计数对象模块302,根据所述计数配置信息中的计数标识,在获取到的业务数据中,确定所述计数标识所对应的业务数据,根据所述计数标识所对应的业务数据,确定计数对象。
所述索引表模块303,确定所述计数配置信息中包含的、该统计对象所对应的业务数据的元数据,根据所述元数据及该计数对象对应的业务数据的参数,更新该计数对象所对应的索引表。
进一步地,所述索引表模块303,根据所述元数据,确定索引表的键,根据所述计数对象对应的业务数据的参数,确定各键对应的值,基于所述键和值更新索引表。
所述计数模块304,按照预设的查询条件,在所述索引表中对满足该查询条件的所述计数对象进行计数。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。