CN101499913B - 一种业务处理的方法、系统和设备 - Google Patents

Abstract

本发明公开了一种业务处理的方法、系统和设备，属于通信领域。所述方法包括：区域服务器接收按时扣费请求，将请求中携带的帐号、扣费金额，写入当前账单；当满足转移账单的条件后，将当前账单转移成待处理账单并将待处理账单转发给全局服务器；全局服务器对帐号进行按时扣费处理。本发明通过区域服务器和全局服务器实现帐户集中、账单分布，并通过累积账单、合并账单、批量扣款的方式实现按时长收费类业务的支付，并能实现查询、充值等业务的处理，实现业务的快速处理，提高用户的使用体验。

Description

一种业务处理的方法、系统和设备

技术领域

本发明涉及通信领域，特别涉及一种业务处理的方法、系统和设备。

背景技术

随着互联网技术的普及，基于互联网的各类业务（如MMOG（MassivelyMultiplayer Online Game,大型多人在线游戏）等）受到了用户广泛的应用，而很多互联网业务都需要用户支付一定的费用。其中，根据业务支付模式的不同，互联网业务可以分为下列两类：按条支付类业务和按时长支付类业务，所谓按条支付类业务是指支付行为由用户主动触发，单次支付金额较大，且总体来看发生次数不多；该类业务通常是集中部署，并且该类业务支付过程中不允许帐户透支；所谓按时长支付类业务是指支付行为由用户的在线状态累积到一定时长而触发（如每在线15分钟扣一次费），单次支付金额较小，发生次数较多（如每小时4次），该类业务通常分布式部署，分布于全国各地IDC（InternetData Center，互联网数据中心）；该类业务支付过程中允许帐户透支。

针对上述两类业务，需要提供一套完整的帐户体系以便能够很好的支持充值、查询、按条扣费、按时长扣费等基本操作。

现有技术提供了一种业务处理的方案，参见图1，为现有技术1提供的实现业务处理的架构示意图，包括：GAC（Globle Account Center,全局帐户中心）用于保存帐户的路由信息，LAC（Local Account Center,区域帐户中心）用于保存用户的帐户，基于该架构方式，用户可以在就近的IDC里的LAC进行扣费，当需要帐户漫游的时候通过GAC中转进行扣费，该方式下，由于需要通过GAC进行中转，且每次支付都要通过专线到达全国各地IDC，响应速度较慢；并且，一旦IDC间专线出现故障，则某个（或某几个）LAC上的帐户即不可用。

为了解决上述响应速度慢的问题，现有技术还提供了另一种业务处理的方案，参见图2，为现有技术2提供的实现业务处理的架构示意图，包括：位于总部GAC、以及位于各区域的LAC，其中，LAC、GAC各保留一份帐户余额信息，分别为按条包月支付、按时长支付方式做支撑。由于LAC和GAC能同时对两类业务提供支撑，所以能够对业务进行快速响应，但是，由于存在两套帐户两边都提供扣款功能，并做定时同步信息，必然存在帐户同步、帐户异常处理等问题；同步过于频繁则大量占用专线带宽；同步间隔时间过长则两套帐户存在差异的概率加大；另外，针对在一套帐户充值/扣费成功，而在另一套帐户充值/扣费失败的情况，没有很好的解决方案。

发明内容

为了实现业务的快速处理，提高用户的使用体验，本发明实施例提供了一种业务处理的方法、系统和设备，所述技术方案如下：

一方面，本发明实施例提供了一种业务处理的方法，当需要执行按时扣费业务时，所述方法包括：

当需要执行按时扣费业务时：

区域服务器接收按时扣费业务的客户端发送的按时扣费请求，所述按时扣费请求中携带待扣费的帐号、扣费金额；

将所述帐号、扣费金额，写入当前账单；

当满足转移账单的预设时间到达后，将所述当前账单转移成待处理账单，并将所述待处理账单发送给全局服务器；

当所述全局服务器收到一个待处理账单，根据接收的待处理账单中携带的帐号及其扣费金额，对所述帐号进行按时扣费处理；

当所述全局服务器收到多个待处理账单，根据收到的待处理账单中的帐号，进行扣费金额信息汇总，对所述帐号进行批量按时扣费处理；

当需要执行按条扣费业务时：

所述全局服务器还接收按条扣费的业务的提供方发送的按条扣费请求，所述按条扣费请求中携带待扣费的帐号、扣费金额；

根据所述帐号以及扣费金额，直接对所述帐号进行按条扣费处理。

其中，所述对所述帐号进行按时扣费处理之后，还包括：

所述全局服务器向所述区域服务器返回按时扣费响应，所述区域服务器收到所述按时扣费响应后，将所述待处理账单转移成已处理账单。

再一方面，本发明实施例还提供了一种业务处理的方法，当需要执行充值业务时，所述方法包括：

全局服务器接收充值请求，所述充值请求中携带待充值的帐号、充值金额；

根据所述帐号以及充值金额，对所述帐号进行充值处理。

再一方面，本发明实施例还提供了一种业务处理的方法，当需要执行查询业务时，所述方法包括：

区域服务器接收客户端发送的余额查询请求，所述余额查询请求中携带待查询的帐号；

根据所述待查询的帐号，判断在所述区域服务器中是否能查找到所述帐号的余额信息；

如果是，则向所述客户端返回所述帐号的余额信息；

如果否，则将所述余额查询请求转发到全局服务器，所述全局服务器根据收到的余额查询请求中携带的帐号，查找所述帐号的余额信息，并向所述区域服务器返回查找到的余额信息；所述区域服务器收到余额信息，向所述客户端返回所述帐号的余额信息。

进一步地，所述方法还包括：

在所述区域服务器中能查找到所述帐号的余额信息后，判断所述帐号的余额是否低于预设值，如果是，则将所述余额查询请求转发到所述全局服务器。

进一步地，所述方法还包括：

所述全局服务器将预设时间内余额有变化的帐号、余额信息导出，形成余额文件；

所述区域服务器向所述全局服务器获取所述余额文件；

所述区域服务器根据余额文件中携带的帐号和余额信息，对位于自身的帐号进行余额信息更新；

所述区域服务器根据帐号的最近一次生成当前账单的时间，对所述帐号的余额信息进行清理。

再一方面，本发明实施例还提供了一种业务处理的系统，所述系统包括：全局服务器和至少一个区域服务器，当需要执行扣费业务时，

所述区域服务器，包括：

接收模块，用于接收按时扣费业务的客户端发送的按时扣费请求，所述按时扣费请求中携带待扣费的帐号、扣费金额；

处理模块，用于将所述帐号、扣费金额，写入当前账单；当满足转移账单的预设时间到达后，将所述当前账单转移成待处理账单；

发送模块，用于将所述待处理账单发送给所述全局服务器；

所述全局服务器，包括：

接收模块，用于接收至少一个待处理账单；

处理模块，用于根据接收的待处理账单中携带的帐号及其扣费金额，对所述帐号进行按时扣费处理；还用于接收按条扣费的业务的提供方发送的按条扣费请求，所述按条扣费请求中携带待扣费的帐号、扣费金额，根据所述帐号以及扣费金额，直接对所述帐号进行按条扣费处理。

进一步地，所述全局服务器，还包括发送模块，用于当对所述帐号进行按时扣费处理之后，向所述区域服务器返回按时扣费响应；

所述区域服务器中的处理模块，还用于收到所述按时扣费响应后，将所述待处理账单转移成已处理账单。

再一方面，本发明实施例还提供了一种业务处理的系统，所述系统包括：全局服务器和至少一个区域服务器，当需要执行充值业务时，

所述全局服务器，用于接收充值请求，所述充值请求中携带待充值的帐号、充值金额；根据所述帐号以及充值金额，对所述帐号进行充值处理。

再一方面，本发明实施例还提供了一种业务处理的系统，所述系统包括：全局服务器和至少一个区域服务器，当需要执行查询业务时，

所述区域服务器，用于接收客户端发送的余额查询请求，所述余额查询请求中携带待查询的帐号；根据所述待查询的帐号，判断在所述区域服务器中是否能查找到所述帐号的余额信息；如果是，则向所述客户端返回查找到的所述帐号的余额信息；如果否，则将所述余额查询请求转发到所述全局服务器，并接收所述全局服务器返回的余额信息；向所述客户端返回所述帐号的余额信息；

所述全局服务器，用于接收所述区域服务器转发的余额查询请求，根据所述余额查询请求中携带的帐号，查找所述帐号的余额信息，并向所述区域服务器返回查找到的余额信息。

进一步地，所述区域服务器，还用于当在所述区域服务器中能查找到所述帐号的余额信息后，判断所述帐号的余额是否低于预设值，如果是，则将所述余额查询请求转发到所述全局服务器。

进一步地，所述全局服务器，还用于将预设时间内余额有变化的帐号、余额信息导出，形成余额文件；

相应地，所述区域服务器，还用于向所述全局服务器获取所述余额文件；所述区域服务器根据余额文件中携带的帐号和余额信息，对位于自身的帐号进行余额信息更新；

所述区域服务器，还用于根据帐号的最近一次生成当前账单的时间，对所述帐号的余额信息进行清理。

本发明实施例提供的技术方案的有益效果是：

通过区域服务器和全局服务器实现帐户集中、账单分布，并通过累积账单、合并账单、批量扣款的方式实现按时长收费类业务的支付，并能实现查询、充值等业务的处理，从而实现业务的快速处理，提高用户的使用体验。

附图说明

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

图1是现有技术提供的实现业务处理的架构示意图；

图2是现有技术提供的实现业务处理的另一架构示意图；

图3是本发明实施例提供的实现业务处理的方法流程图；

图4是本发明实施例1提供的实现业务处理的架构示意图；

图5是本发明实施例1提供的充值流程示意图；

图6是本发明实施例1提供的按条扣费的流程示意图；

图7是本发明实施例1提供的按时长扣费的流程示意图；

图8是本发明实施例1提供的查询业务的流程示意图；

图9是本发明实施例2提供的实现业务处理的系统示意图；

图10是本发明实施例2提供的LAC具体实现的示意图；

图11是本发明实施例2提供的GAC具体实现的示意图；

图12是本发明实施例2提供的集中帐户系统具体实现的示意图；

图13是本发明实施例3提供的区域服务器的示意图；

图14是本发明实施例3提供的区域服务器的详细示意图；

图15是本发明实施例4提供的全局服务器的示意图；

图16是本发明实施例4提供的全局服务器的详细示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

为了实现业务的快速处理，提高用户的使用体验，本发明实施例提供了一种业务处理的方法，其中，全局服务器用于保存用户帐户信息，实现帐户集中管理，各个区域服务器用于生成位于自身区域服务器的帐号的当前账单，当满足转移账单的条件后，将当前账单转移成待处理账单，发送给全局服务器，由全局服务器对所收到的各区域服务器发送的待处理账单，根据帐号进行汇总处理，详见图3，该方法内容如下：

当需要执行按时扣费业务时，所述方法包括：

301：区域服务器接收客户端发送的按时扣费请求，其中，该按时扣费请求中携带待扣费的帐号、扣费金额；

302：将帐号、扣费金额，写入当前账单；

303：当满足转移账单的条件后，将当前账单转移成待处理账单，并将待处理账单发送给全局服务器；

304：全局服务器收到至少一个待处理账单，根据接收的待处理账单中携带的帐号及其扣费金额，对帐号进行按时扣费处理。

另外，本发明实施例提供的方法，当需要执行按条扣费业务时，方法包括：

全局服务器接收按条扣费请求，按条扣费请求中携带待扣费的帐号、扣费金额；

根据帐号以及扣费金额，对帐号进行按条扣费处理。

另外，本发明实施例提供的方法，当需要执行充值业务时，方法包括：

全局服务器接收充值请求，充值请求中携带待充值的帐号、充值金额；

根据帐号以及充值金额，对帐号进行充值处理。

另外，本发明实施例提供的方法，当需要执行查询业务时，方法包括：

区域服务器接收客户端发送的余额查询请求，余额查询请求中携带待查询的帐号；

根据待查询的帐号，判断在区域服务器中是否能查找到帐号的余额信息；

如果是，则向客户端返回查找到的帐号的余额信息；

如果否，则将余额查询请求转发到全局服务器，全局服务器根据收到的余额查询请求中携带的帐号，查找帐号的余额信息，并向区域服务器返回查找到的余额信息；区域服务器收到余额信息，向客户端返回帐号的余额信息。

综上，本发明实施例提供的方法，通过区域服务器和全局服务器实现帐户集中、账单分布，并通过累积账单、合并账单、批量扣款的方式实现按时长收费类业务的支付，并能实现查询、充值等业务的处理，实现业务的快速处理，提高用户的使用体验。

为了对上述本发明实施例提供的方法进行详细说明，请参见如下实施例：

实施例1

为了实现业务的快速处理，提高用户的使用体验，本发明实施例提供了一种业务处理的方法，为了对本发明实施例提供的方法进行说明，参见图4，为本发明实施例提供的实现业务处理的架构示意图，包括位于总部的集中帐户系统和GAC（构成了上述全局服务器）、位于各区域的LAC（即区域服务器），其中，集中帐户系统以及GAC属于逻辑功能实体，在具体实现时，上述集中帐户系统以及GAC可以通过一个物理实体实现，也可以分别部署一个单独的物理实体实现，本实施例对此不做限制。基于该架构示意图，对本发明实施例提供的方法进行说明，详见如下：

由于业务处理通常包括的类型有：充值、支付（即扣费）、查询。其中，支付又分为按条支付（即按条扣费）和按时长支付（即按时扣费）。业务处理也包括一些附加的操作，例如帐单文件发送、批量扣款、LAC余额定时更新、LAC余额定时清理等，下面分别进行说明：

一、针对充值业务

用户在为自己的业务帐号的充值时，通过总部的GAC直接充值到集中帐户系统，在各区域LAC上不进行帐号的存储。参见图5，为本发明实施例提供的充值流程示意图，详见如下：

501：用户通过充值接口向GAC发送充值请求，该充值请求中携带用户的帐号、充值金额。

502：GAC收到充值请求后，向集中帐户系统转发该充值请求。

其中，集中帐户系统用于保存多个帐号的帐户信息，进行帐号的管理，例如实现帐号的充值、扣费等功能。

503：集中帐户系统收到该充值请求后，根据该充值请求中携带的帐号、充值金额，为该帐号进行充值。

具体实现时，可以通过为用户提供网页的形式，用户通过在该网页中填入相应的业务的帐号、网银帐号以及充值金额的方式，实现通过总部的GAC直接充值到集中帐户系统中。

二、针对支付业务

如前所述，支付业务分为按条支付（按条扣费）和按时长支付（按时长扣费），下面针对这两类支付业务分别进行说明：

1、按条扣费

由于用户充值是在总部的集中帐户系统完成的，所以相应地，在执行按条扣费时，直接在集中帐户系统进行扣费操作，参见图6，为本发明实施例提供的按条扣费的流程示意图，详见如下：

601：向GAC发送扣费请求，该扣费请求中携带用户的帐号、扣费金额。

其中，针对用户正在使用的某种按条扣费的业务，由该按条扣费的业务的提供方发送该扣费请求，例如，当用户通过互联网，使用虚拟货币购买一件物品，则由该物品的提供方执行该按条扣费的业务的扣费请求的发送。

602：GAC收到扣费请求后，将该扣费请求转发到集中帐户系统。

603：集中帐户系统收到扣费请求后，根据该扣费请求中携带的用户的账号和扣费金额，扣除相应的费用。

通过在集中帐户系统扣费的形式，在集中帐户系统中，各帐户集中在按条业务所临近的IDC中，因此，不存在跨专线扣费的情况，从而响应速度得到保证，提高了用户的使用体验。

2、按时长扣费

目前，按时长扣费的业务常见有MMOG业务等，本实施例为了便于说明，以MMOG业务为例，即以使用该MMOG业务用户的帐号在线时间进行扣费的，参见图7，为本发明实施例提供的按时长扣费的流程示意图，内容如下：

701：MMOG业务的客户端记录在该客户端上使用该MMOG业务的用户的帐号的在线时间。

702：客户端根据记录的该帐号的在线时间，判断在线时间是否达到发送扣费请求的条件，如果是，则执行步骤703；否则，返回执行701。

其中，发送扣费请求的条件可以根据具体的需要进行设置，例如设置为每在线15分钟发送一次扣费请求。

703：向该客户端所在的LAC发送扣费请求，该扣费请求中携带使用该MMOG业务的用户的帐号、扣费金额。

其中，每次扣费的金额可以根据具体的需要进行设置，例如设置为每次扣除5个虚拟货币，其中虚拟货币和真实货币之间存在映射关系，不实施例对此不做限制。

704:LAC收到扣费请求后，根据该扣费请求中携带的帐号、扣费金额，将相应的信息写入当前账单。

其中，通过上述步骤701-704，LAC可以在当前账单中实时记录所收到的需要进行扣费的帐号信息以及对应的扣费金额信息。参见表1，为本发明实施例提供的一种当前账单内容示意表。

表1

帐号	扣费金额
		1111	5
2222	5
		3333	10
……	……

705：LAC判断是否满足转移账单的条件，如果是，则执行步骤706；否则，执行步骤707。

其中，转移账单的条件为是否达到预设时间，其中，该预设时间可以根据具体的需要进行设定，例如设定为0.5个小时，则LAC每0.5个小时触发一次判断。

706：当满足转移账单的条件后，LAC将收到的所有当前账单转移成待处理账单,然后执行步骤708。

其中，待处理账单中至少携带需要进行扣费的帐号及其扣费金额信息，还可以携带日期时间等信息，本实施例对此不做限制。

707:继续等待，直到满足转移账单的条件。

708：LAC将待处理账单发送给GAC。

其中，本实施例以一个LAC进行处理为例，其余LAC的处理情况与此类似，不再赘述。

709：GAC收到LAC发送的待处理账单，向LAC返回确认信息，并将待处理账单转发给集中帐户系统。

其中，GAC收到LAC发送的待处理账单，向LAC返回确认信息，返回确认信息的目的是为了通知LAC已经成功收到发送的待处理账单。可选的，GAC收到LAC发送的待处理账单后，可以对收到的待处理账单进行完整性检验，当完整性检验通过后，则认为成功收到该LAC发送的待处理账单，则向LAC返回确认信息。

当GAC收到来自多个LAC发送的待处理账单后，将多个待处理账单汇总后发送给集中帐户系统，情况类似，不再赘述。其中，所谓GAC将多个待处理账单汇总，是指将收到的帐单中以帐号为索引，对该帐号所需要进行扣费的总金额进行汇总。

710：集中帐户系统收到待处理账单后，根据待处理账单中携带的需要进行扣费的帐号及其扣费金额信息，执行相应的扣费处理。

711：当扣费处理完成后，集中帐户系统返回执行完毕通知，通过GAC将该执行完毕通知返回给LAC。

712：LAC收到返回的执行完毕通知后，将待处理账单转移成已处理账单。

至此，上述步骤701-712，通过累计账单、合并账单、批量扣费的方式成功地完成了按时长扣费的业务的扣费处理操作过程。

三、针对查询业务

仍以用户在使用MMOG业务为例进行说明，在使用该MMOG业务的过程中，触发了查询余额的业务需求，针对查询业务本发明实施例提供的查询业务的流程示意图，参见图8，该方法内容如下：

801：MMOG客户端向自身所在的LAC发送查询请求，该查询请求中携带用户的帐号。

802：LAC收到查询请求，根据查询请求中携带用户的帐号，判断该帐号是否在自身有余额记录，如果是，则执行步骤803；否则，执行步骤804。

其中，由于LAC有查询帐号余额的需求，因此，在LAC上需要保存一份用户的帐号余额以及状态信息，并且这个余额信息要尽量的准确。由于集中帐户系统中个账上充值、扣款操作比较频繁，因此需要较频繁的将个账上的余额同步到LAC上。其中，同步的方式和方法可以如下：

首先，集中帐户系统将最近预设时间（例如1分钟）内余额或状态有变化的帐号及其余额、状态导出到余额文件中；

其次，各LAC根据自身设置的查询频率（例如每1分钟查询一次）向GAC发送查询请求，GAC通过将查询请求转发到集中帐户系统。

然后，集中帐户系统收到查询请求后，将前述导出的余额文件通过GAC返回给各LAC。

通过上述步骤，各LAC实现通过GAC将余额文件拉回的目的。

最后，各LAC收到余额文件后，根据余额文件中携带的帐号和其余额信息，对位于自身的帐号信息进行更新。

803：判断查询到的余额是否低于预设额度，如果是，则执行步骤804；否则，执行步骤805。

其中，由于在进行查询时，用户可能已经为该帐号进行了充值，只是尚未同步到该LAC上，因此，针对该情况，为了确保用户的使用体验、提高用户的满意度，当判断查询到的余额低于预设额度后，则执行步骤804。其中，该预设额度可以根据实际情况进行设定，例如设定为1个虚拟货币值，本实施例对此不做任何限制。

804：LAC向GAC发送查询请求，该查询请求中携带该用户的帐号，GAC收到该查询请求后，将该用户的帐号对应的余额返回给LAC。

805：LAC判断该用户的帐号是否处于冻结状态，如果是，则执行步骤806；否则，执行步骤807。

其中，为了确保用户的帐号的安全性和可靠性，可以为帐号设置状态，当状态为冻结时，则禁止向MMOG客户端提供该帐号的余额信息。

806：LAC向MMOG客户端返回信息，提示该帐户冻结，结束。

807：LAC向MMOG客户端返回查询到的余额信息，结束。

综上，通过上述步骤801至807，实现了对帐号余额的查询。

进一步地，为了提高LAC的利用率、节省LAC的存储资源，LAC还可以对自身的帐号信息进行定时清理，由于LAC上已不存在帐户，而只存在帐单，因此一个用户也就没有必要跟一个LAC进行绑定，当一个用户长时间（具体的时间根据需要进行设置，例如可以为一周或一月）没有在某个LAC上生成过帐单时，则该LAC上将这个帐户的余额信息进行清除，既可以提高LAC的利用率、节省LAC的存储资源，又可以减少在该LAC进行余额更新时的操作量。并且，当清除该用户在该LAC上的余额信息后，若该用户再次在该LAC对应的MMOG客户端登录，则通过上述步骤804的内容，可以再次从GAC获取到该帐号的实时的余额信息。

综上，本发明实施例分别针对上述充值、支付、查询业务进行了说明，本发明实施例提供的方法，通过区域服务器和全局服务器实现帐户集中、账单分布，并通过累积账单、合并账单、批量扣款的方式实现按时长收费类业务的支付，并能实现查询、充值等业务的处理，实现业务的快速处理，提高用户的使用体验。

实施例2

为了实现业务的快速处理，提高用户的使用体验，与方法实施例相应，本发明实施例2提供了一种业务处理的系统，参见图9，该系统包括：全局服务器901和至少一个区域服务器902，其中，

1、当需要执行按时扣费业务时，

区域服务器902，用于接收客户端发送的按时扣费请求，按时扣费请求中携带待扣费的帐号、扣费金额；将帐号、扣费金额，写入当前账单；当满足转移账单的条件后，将当前账单转移成待处理账单，并将待处理账单发送给全局服务器901；

全局服务器901，用于接收至少一个待处理账单，根据接收的待处理账单中携带的帐号及其扣费金额，对帐号进行扣费处理。

进一步地，全局服务器901，还用于当对帐号进行扣费处理之后，向区域服务器902返回按时扣费响应；区域服务器902，还用于收到按时扣费响应后，将待处理账单转移成已处理账单。

2、当需要执行按条扣费业务时，

全局服务器901，还用于接收按条扣费请求，按条扣费请求中携带待扣费的帐号、扣费金额；根据帐号以及扣费金额，对帐号进行按条扣费处理。

3、当需要执行充值业务时，全局服务器901，还用于接收充值请求，充值请求中携带待充值的帐号、充值金额；根据帐号以及充值金额，对帐号进行充值处理。

4、当需要执行查询业务时，

区域服务器902，还用于接收客户端发送的余额查询请求，余额查询请求中携带待查询的帐号；根据待查询的帐号，判断在区域服务器902中是否能查找到帐号的余额信息；如果是，则向客户端返回查找到的帐号的余额信息；如果否，则将余额查询请求转发到全局服务器901，并接收全局服务器901返回的余额信息；向客户端返回帐号的余额信息；

全局服务器901，还用于接收区域服务器902转发的余额查询请求，根据余额查询请求中携带的帐号，查找帐号的余额信息，并向区域服务器902返回查找到的余额信息。

进一步地，区域服务器902，还用于当在区域服务器902中能查找到帐号的余额信息后，判断帐号的余额是否低于预设值，如果是，则将余额查询请求转发到全局服务器901。

进一步地，区域服务器902，还用于在向客户端返回查找到的帐号的余额信息之前，判断帐号是否处于冻结状态，如果否，向客户端返回帐号的余额信息。

进一步地，全局服务器901，还用于将预设时间内余额有变化的帐号、余额信息导出，形成余额文件；

相应地，区域服务器902，还用于向全局服务器901获取余额文件；区域服务器902根据余额文件中携带的帐号和余额信息，对位于自身的帐号进行余额信息更新。

进一步地，区域服务器902，还用于根据帐号的最近一次生成当前账单的时间，对帐号的余额信息进行定时清理。

如前文所述，本发明实施例提供的系统在具体实现时，可以如下,参见图10，为本发明实施例提供的区域服务器的示意图，通过LAC实现该区域服务器的功能，其中，

1、LAC内各实体

1）BRS（Bill Record Server）帐单记录服务器

性质：服务器

功能：提供查询服务给MMOG；提供扣费服务给MMOG；记录帐单到“当前帐单文件”中；每1小时将“当前帐单文件”移到“待执行帐单文件目录”中；从个账（Cache）或本地内存查询帐户余额；每次扣费时修改本地内存里的帐户余额

交互：内部：帐户余额、状态信息表（内存）、帐单文件（硬盘）；外部：MMOG、个账（Cache）

2）发送程序

性质：脚本/程序

功能：将“待执行帐单文件目录”下的所有帐单文件发送GAC

执行时机：每小时一次

交互：内部：“待执行帐单文件”；外部：GAC。

3）更新服务器

性质：服务器

功能：从个账拉取待更新的帐户余额、信息文件，并更新到帐户余额、状态信息表中；定期从帐户余额、状态信息表中删除长时间未在本LAC产生过帐户信息；接受GAC通知的“成功执行的帐单文件名”；将成功执行的帐单文件从“待执行帐单文件目录”下移到“已执行帐单文件目录”下

交互：内部：帐户余额、状态信息表；外部：个账、GAC。

4）帐户余额、状态信息表

性质：内存表

功能：存储近期在本LAC产生过帐单或做过查询操作的帐户的余额、状态信息，参见表2，提供了一种格式示意表。

表2

帐号	余额	状态	最后操作时间
				11111	63	非冻结	2008.10.1
11112	20	冻结	2008.10.1
				……	……	……	……

交互：内部：BRS、更新程序。

5)帐单文件

性质：文件;

功能：存放帐单（包括当前帐单、待执行帐单、已执行帐单）

命名规则：bill_id_yyyymmddhh.txt，其中id是LAC的编号，yyyymmddhh是年月日时;

格式：完全记录一条扣费流水的各个字段，各字段间用“|”隔开

交互：内部：BRS、发送程序。

2、LAC提供的接口

1）BRS提供给外部的接口

查询余额：提供给MMOG等客户端，查询帐户余额；

扣费：提供给MMOG等客户端，进行计时类扣费；

2）更新服务器提供给外部的接口

通知执行成功的帐单文件名：提供给GAC，用于通知更新服务器在GAC上执行成功的帐单文件名

3）BRS用到的外部接口

查询余额的接口，个账（Cache）提供

另分别参见图11和图12，为本发明实施例提供的全局服务器的具体实现示意图，通过GAC和集中帐户系统实现该区域服务器的功能，其中，

如图11所示，上述GAC具体实现时，

1、GAC内的实体包括：

1）BPS（Bill Process Server）帐单处理服务器

性质：服务器

功能：检查是否有未处理的帐单文件送过来；如果有，则读入帐单，并校验完整性，完成后发送帐单文件名给相应的LAC；入明细扣费流水表（每天一张表）；如果插表成功（没有帐单号冲突），汇总同帐单文件中同一个帐号的多条扣费记录，并生成汇总帐单文件；将处理过的帐单文件移走备份

注意：BPS通过记录已执行帐单文件的文件名来防止异常情况下LAC重复发送同一个帐单文件（只保留几天之内的文件名即可）

交互：内部：帐单文件、明细扣费流水表；外部：个账、LAC

2）发送程序

性质：程序/脚本

功能：将汇总帐单文件发送给个账模块

运行时机：BPS生成汇总帐单文件时（由BPS触发执行）

交互：

内部：汇总帐单文件、BPS；外部：个账

3）明细扣费流水表

性质：数据库

功能：存储用户每一条MMOG计时扣费的流水

字段：与现有计时扣费流水一致

交互：内部：BPS、帐单汇总程序；

4）帐单文件

性质：文件

功能：由各个LAC发过来，记录各个LAC上待执行的帐单

命名规则：bill_id_yyyymmddhh.txt，其中id是LAC的编号，yyyymmddhh是年月日时

格式：完全记录一条扣费流水的各个字段，各字段间用“|”隔开

交互：内部：BPS；外部：LAC

5）汇总帐单文件

性质：文件

功能：将一个或多个帐单文件中同一个帐号的多个扣费请求合并成一个

命名规则：combill_yyyymmddhh_id.txt，其中yyyymmddhh是年月日时,id编号（同一个小时内可能有多个汇总帐单文件）

格式：按个账流水表字段存储，各字段间用“|”隔开

2、GAC的接口

1）BPS用到的外部接口

通知执行成功的帐单文件名的接口，LAC提供。

另，如图12所示，集中帐户系统实现时，详见如下：

1、集中帐户系统内各实体

1）个账服务器

性质：服务器

功能：处理帐户充值、按条包月扣费、查询、冻结、激活等操作

交互：内部：Cache服务器、营销服务器、个账数据库；外部：按条包月业务、充值渠道、流水查询网页等

2）Cache缓存服务器

性质：服务器

功能：提供高速查询服务

交互：内部：个账服务器、个账数据库；外部：LAC、各业务、查询网页

3）营销服务器

性质：服务器

功能：根据个账操作，记录有充值、扣款、状态变化等操作的帐户信息到“帐户余额、状态变更文件”，每分钟生成一个

交互：内部：个账服务器、帐户余额状态变更文件；外部：LAC

4）批扣程序

性质：程序/服务器

功能：将GAC发送过来的汇总帐单文件进行批量扣款

交互：内部：汇总帐单文件、个账数据库

5）个账数据库

性质：数据库

功能：存储个人帐户余额、流水等信息

交互：内部：个账服务器、Cache服务器、批扣程序

6）帐户余额、状态变更文件

性质：文件

功能：存储每分钟内有余额或状态变化的帐户信息，供LAC拉取并更新LAC上的帐户信息

命名方式：acct_id_YYYYMMDDhhmm.txt，其中id是LAC编号，YYYYMMDDhhmm是年月日时分

格式：参见表3，提供了一种格式示意表，

表3

帐号

余额

状态

11111	63	非冻结
			11112	20	冻结
……	……	……

交互：

内部：营销服务器；外部：LAC

7）汇总帐单文件

性质：文件

功能：将一个帐单文件中同一个帐号的多个扣费请求合并成一个

命名规则：combill_yyyymmddhh_id.txt，其中yyyymmddhh是年月日时,id编号（同一个小时内可能有多个汇总帐单文件）

格式：按个账流水表字段存储，各字段间用“|”隔开

2、该集中帐户系统所提供的接口

1）个账服务器用到的接口：操作数据库的接口（mysql提供），通知营销服务器的接口（营销服务器提供），通知Cache服务器的接口（Cache服务器提供）

提供的接口：查询、充值、按条包月扣费、计时扣费（直扣）

2）Cache服务器用到的接口：操作数据库的接口（mysql提供）

提供的接口：查询接口、通知接口（个账服务器用）

3）营销服务器提供的接口：通知接口（个账服务器用）

综上，本发明实施例分别针对上述充值、支付、查询业务进行了说明，本发明实施例提供的系统，通过区域服务器和全局服务器实现帐户集中、账单分布，并通过累积账单、合并账单、批量扣款的方式实现按时长收费类业务的支付，并能实现查询、充值等业务的处理，实现业务的快速处理，提高用户的使用体验。

实施例3

参见图13，与方法实施例和系统实施例相应，本发明实施例提供了一种区域服务器，区域服务器包括：

接收模块1301，用于接收客户端发送的按时扣费请求，按时扣费请求中携带待扣费的帐号、扣费金额；

处理模块1302，用于将帐号、扣费金额，写入当前账单；当满足转移账单的条件后，将当前账单转移成待处理账单；

发送模块1303，用于将待处理账单发送给全局服务器，以使得全局服务器根据接收的待处理账单中携带的帐号及其扣费金额，对帐号进行按时扣费处理。

进一步地，

接收模块1301，还用于接收全局服务器对帐号进行扣费处理之后，返回的按时扣费响应；

处理模块1302，还用于当接收到的按时扣费响应后，将待处理账单转移成已处理账单。

当需要执行查询业务时，

接收模块1301，还用于接收客户端发送的余额查询请求，余额查询请求中携带待查询的帐号；

处理模块1302，还用于根据待查询的帐号，判断在区域服务器中是否能查找到帐号的余额信息；如果是，则向客户端返回查找到的帐号的余额信息；如果否，则将余额查询请求转发到全局服务器，并接收全局服务器返回的余额信息；向客户端返回帐号的余额信息。

进一步地，处理模块1302，还用于当在区域服务器中能查找到帐号的余额信息后，判断帐号的余额是否低于预设值，如果是，则将余额查询请求转发到全局服务器。

处理模块1302，还用于在向客户端返回查找到的帐号的余额信息之前，判断帐号是否处于冻结状态，如果否，则向客户端返回帐号的余额信息。

进一步地，参见图14，区域服务器还包括：

获取模块1304，用于根据自身设置的查询频率，向全局服务器获取余额文件；余额文件为全局服务器将预设时间内余额有变化的帐号、余额信息导出所形成的；

更新模块1305，用于根据获取模块1304获取的余额文件中携带的帐号和余额信息，对位于自身的帐号进行余额信息更新。

进一步地，区域服务器还包括：

清理模块1306，用于根据帐号的最近一次生成当前账单的时间，对帐号的余额信息进行清理。

本发明实施例提供的区域服务器，针对充值、支付、查询业务进行了说明，通过该区域服务器和全局服务器实现帐户集中、账单分布，并通过累积账单、合并账单、批量扣款的方式实现按时长收费类业务的支付，并能实现查询、充值等业务的处理，实现业务的快速处理，提高用户的使用体验。

实施例4

参见图15，与方法实施例和系统实施例相应，本发明实施例提供了一种全局服务器，该全局服务器包括：

接收模块1501，用于接收至少一个待处理账单，其中，待处理账单为区域服务器在接收到的客户端发送的按时扣费请求后，将按时扣费请求中携带的帐号、扣费金额，写入当前账单；当满足转移账单的条件后，将当前账单转移得到的；用于接收按条扣费请求，按条扣费请求中携带待扣费的帐号、扣费金额；

处理模块1502，用于根据接收模块接收的待处理账单中携带的帐号及其扣费金额，对帐号进行按条扣费处理；还用于根据接收模块1501接收的按条扣费请求中携带的帐号以及扣费金额，对帐号进行按条扣费处理。

进一步地，参见图16，全局服务器还包括：

发送模块1503，用于当对帐号进行扣费处理之后，向区域服务器返回按时扣费响应；以使得区域服务器收到按时扣费响应后，将待处理账单转移成已处理账单。

当需要执行充值业务时，

接收模块1501，还用于接收充值请求，充值请求中携带待充值的帐号、充值金额；

处理模块1502，还用于根据帐号以及充值金额，对帐号进行充值处理。

当需要执行查询业务时，

接收模块1501，还用于接收区域服务器转发的余额查询请求，余额查询请求中携带待查询的帐号；

处理模块1502，还用于根据余额查询请求中携带的帐号，查找帐号的余额信息，并向区域服务器返回查找到的余额信息。

进一步地，全局服务器还包括：

余额生成模块1504，用于将预设时间内余额有变化的帐号、余额信息导出，形成余额文件；

提供模块1505，用于将形成模块形成的余额文件，提供给区域服务器，以使得区域服务器根据余额文件中携带的帐号和余额信息，对位于该区域服务器自身的帐号进行余额信息更新。

如前所述，本发明实施例提供的全局服务器，具体实现时，可以通过GAC和集中帐户系统实现，此处不再赘述。

本发明实施例提供的全局服务器，针对充值、支付、查询业务进行了说明，通过该全局服务器以及区域服务器实现帐户集中、账单分布，并通过累积账单、合并账单、批量扣款的方式实现按时长收费类业务的支付，并能实现查询、充值等业务的处理，实现业务的快速处理，提高用户的使用体验。

另外，发明人在实现本发明实施例提供的技术方案时，充分做了如下考虑，如果发生专线中断导致LAC上的帐单无法发送到GAC上时，则等到下次发送时间（1小时之后）再次发送；如果导致GAC执行完帐单无法通知LAC时，则可以采用多次尝试通知直到通知成功为止的方式；或不再通知，等LAC下次再送帐单上来后再行通知的方式，有可能造成LAC再次将GAC已执行的帐单文件送到GAC要求执行，此时GAC应有机制保证不重复执行帐单，并返回执行成功的帐单文件名给LAC；如果导致LAC无法从GAC上拉取用户信息变化列表，则等专线恢复后，LAC将累积的用户信息变化文件依次拉回并执行。如果全局服务器侧执行批扣失败，如果是少量帐单执行失败，则可以不做任何处理，容忍部分少扣的后果；同时加以监控，对一批帐单执行失败超过N条时，进行报警；如果是整个帐单文件无法执行，则不发送执行成功的确认给LAC，让LAC再次发送该帐单文件到GAC执行；同时对每个LAC上积压的待执行帐单文件的个数进行监控，超过3个时进行报警，人工查找失败的原因。涉及到数据安全问题时，在区域服务器LAC上，将用户余额、状态信息：写入共享内存，当程序异常退出后仍能读取，down机后丢失，但仍可从全局服务器的集中帐户系统进行查询获得；将帐单进行文件保存，定时进行备份；在全局服务器侧的GAC不产生数据（不包括绑定卡、交易数据）；在全局服务器侧的集中帐户系统所采用的数据库，采用热备（二级）、冷备等措施。

本发明实施例中的“接收”一词可以理解为主动从其他模块获取也可以是接收其他模块发送来的信息。

本领域技术人员可以理解附图只是一个优选实施例的示意图，附图中的模块或流程并不一定是实施本发明所必须的。

本领域技术人员可以理解实施例中的装置中的模块可以按照实施例描述分布于实施例的装置中，也可以进行相应变化位于不同于本实施例的一个或多个装置中。上述实施例的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

本发明实施例中的部分步骤，可以利用软件实现，相应的软件程序可以存储在可读取的存储介质中，如光盘或硬盘等。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (4)

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

当需要执行按时扣费业务时：

区域服务器接收按时扣费业务的客户端发送的按时扣费请求，所述按时扣费请求中携带待扣费的帐号、扣费金额；

将所述帐号、扣费金额，写入当前账单；

当满足转移账单的预设时间到达后，将所述当前账单转移成待处理账单，并将所述待处理账单发送给全局服务器；

当所述全局服务器收到一个待处理账单，根据接收的待处理账单中携带的帐号及其扣费金额，对所述帐号进行按时扣费处理；

当所述全局服务器收到多个待处理账单，根据收到的待处理账单中的帐号，进行扣费金额信息汇总，对所述帐号进行批量按时扣费处理；

当需要执行按条扣费业务时：

所述全局服务器接收按条扣费的业务的提供方发送的按条扣费请求，所述按条扣费请求中携带待扣费的帐号、扣费金额；

根据所述帐号以及扣费金额，直接对所述帐号进行按条扣费处理。

2.如权利要求1所述的方法，其特征在于，所述对所述帐号进行按时扣费处理之后，还包括：

所述全局服务器向所述区域服务器返回按时扣费响应，所述区域服务器收到所述按时扣费响应后，将所述待处理账单转移成已处理账单。

3.一种业务处理的系统，其特征在于，所述系统包括：全局服务器和至少一个区域服务器，当需要执行扣费业务时，

所述区域服务器，包括：

接收模块，用于接收按时扣费业务的客户端发送的按时扣费请求，所述按时扣费请求中携带待扣费的帐号、扣费金额；

处理模块，用于将所述帐号、扣费金额，写入当前账单；当满足转移账单的预设时间到达后，将所述当前账单转移成待处理账单；

发送模块，用于将所述待处理账单发送给所述全局服务器；

所述全局服务器，包括：

接收模块，用于接收至少一个待处理账单；

处理模块，用于根据接收的待处理账单中携带的帐号及其扣费金额，对所述帐号进行按时扣费处理；还用于接收按条扣费的业务的提供方发送的按条扣费请求，所述按条扣费请求中携带待扣费的帐号、扣费金额，根据所述帐号以及扣费金额，直接对所述帐号进行按条扣费处理。

4.如权利要求3所述的系统，其特征在于，

所述全局服务器，还包括发送模块，用于当对所述帐号进行按时扣费处理之后，向所述区域服务器返回按时扣费响应；

所述区域服务器中的处理模块，还用于收到所述按时扣费响应后，将所述待处理账单转移成已处理账单。