CN105205182A - 多机房部署系统及跨机房的业务数据处理方法 - Google Patents

Abstract

本发明公开了一种多机房部署系统及跨机房的业务数据处理方法。其中，系统包括：主机房和备机房，主机房包括至少一个业务服务器以及用于存储业务数据的主缓存数据库和主数据库，备机房包括至少一个业务服务器以及用于存储业务数据的备缓存数据库和备数据库；主缓存数据库和备缓存数据库之间双向同步业务数据，主数据库与备数据库之间双向同步业务数据；备机房的至少一个业务服务器用于：在接收到业务数据读请求时，从主数据库中读取业务数据；以及，在接收到业务数据写请求时，向主数据库写入业务数据。该系统中，在主数据库和备数据库之间双向同步业务数据时，以主数据库的业务数据为主，使得备数据库与主数据库的数据能够保持强一致性。

Description

多机房部署系统及跨机房的业务数据处理方法

技术领域

本发明涉及计算机网络技术领域，具体涉及一种多机房部署系统及跨机房的业务数据处理方法。

背景技术

随着网络服务的日益普及，经常需要将一些常用的数据(如业务数据等)同时存储在多个机房的服务器上。例如，为了向全国各地的用户提供相同的服务，分别在北京、广州和西藏设置了三个机房，用户通过任一机房节点都能访问到所需的服务，一般情况下用户访问最近的机房节点即可。这时，北京、广州和西藏三个地区的机房中存储的数据均相同。另外，有时为了防止因一个机房中的服务器挂掉而导致服务中断的情况发生，也会同时部署多个存储有相同数据的机房，以便在一个机房挂掉后能够通过另外的机房为用户提供可靠服务。

在上述情况中，多个机房中的数据需要保持一致，一旦各机房中的数据出现了不一致的情况就会影响用户的正常使用。由于业务数据经常发生变更，一旦某机房中的数据变更后，其他机房没有及时进行同步更新就会导致数据不一致的情况发生，因此，目前还没有一种有效的机制能够确保多个机房中的数据的强一致性。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的多机房部署系统及跨机房的业务数据处理方法。

根据本发明的一个方面，提供了多机房部署系统，包括：主机房和备机房，所述主机房包括至少一个业务服务器以及用于存储业务数据的主缓存数据库和主数据库，所述备机房包括至少一个业务服务器以及用于存储业务数据的备缓存数据库和备数据库；所述主缓存数据库和所述备缓存数据库之间双向同步业务数据，所述主数据库与所述备数据库之间双向同步业务数据；

所述备机房的至少一个业务服务器用于：在接收到业务数据读请求时，从所述主数据库中读取业务数据；以及，在接收到业务数据写请求时，向所述主数据库写入业务数据。

根据本发明的另一方面，提供了跨机房的业务数据处理方法，包括：

主机房的主缓存数据库和备机房的备缓存数据库之间双向同步业务数据，主机房的主数据库与备机房的备数据库之间双向同步业务数据；

当备机房的业务服务器接收到业务数据读请求时，从所述主数据库中读取业务数据；或者，当备机房的业务服务器接收到业务数据写请求时，向所述主数据库写入业务数据。

根据本发明提供的多机房部署系统及跨机房的业务数据处理方法，主备机房都部署有各自的缓存数据库和数据库，主备机房的缓存数据库之间双向同步业务数据，数据库之间也双向同步业务数据。当备机房的业务服务器接收到业务数据读请求时，从主机房的主数据库读取业务数据，当备机房的业务服务器接收到业务数据写请求时，向主机房的主数据库写入业务数据。该系统中，业务数据的更新主要发生在主数据库，在主数据库和备数据库之间双向同步业务数据时，以主数据库的业务数据为主，使得备数据库与主数据库的数据能够保持强一致性。而且，这种部署方式也提高了主数据库和备数据库之间同步数据的便捷性，避免了主数据库和备数据的业务数据同时发生不同程度的更新而造成的数据同步困难的问题，降低了主备同步的难度。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了根据本发明一个实施例的多机房部署系统的功能框图；

图2示出了根据本发明另一个实施例的多机房部署系统的功能框图；

图3示出了根据本发明一个实施例的跨机房的业务数据处理方法的流程图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

图1示出了根据本发明一个实施例的多机房部署系统的功能框图。如图1所示，该系统包括：主机房和备机房。主机房包括至少一个业务服务器以及用于存储业务数据的主缓存数据库和主数据库，备机房包括至少一个业务服务器以及用于存储业务数据的备缓存数据库和备数据库；主缓存数据库和备缓存数据库之间双向同步业务数据，主数据库与备数据库之间双向同步业务数据。

主机房的至少一个业务服务器用于：在接收到业务数据读请求时，从主缓存数据库或主数据库中读取业务数据；以及，在接收到业务数据写请求时，依次向主数据库和主缓存数据库中写入业务数据。

备机房的至少一个业务服务器用于：在接收到业务数据读请求时，从主数据库中读取业务数据；以及，在接收到业务数据写请求时，向主数据库写入业务数据。

主机房作为主要机房，其承担了大部分的业务服务。主机房部署有多个业务服务器，如果1个业务服务器能同时处理500个业务请求，那么N个业务服务器就能同时处理500*N个业务请求。通过部署多个业务服务器能够大大提高主机房的并发处理能力，在面对一些高并发的场景，保证主机房能有效应对。主机房的业务服务器与主缓存数据库、主数据库都建立有通信连接。在接收到业务数据读请求时，主机房的业务服务器可以从主缓存数据库或主数据库中读取业务数据；在接收到业务数据写请求时，主机房的业务服务器向主缓存数据库和主数据库中写入业务数据。

备机房作为备用机房，部署它的主要目的是在主机房挂掉后使之能够接替主机房提供服务。但为了保证备用机房的可用性，在主机房能正常提供业务服务时，备机房也在同时运转，只不过备机房承担的业务量远远小于主机房。备机房也部署有多个业务服务器，通过部署多个业务服务器能够大大提高备机房的并发处理能力，在面对一些高并发的场景，保证备机房也能有效应对。备机房的业务服务器与备缓存数据库、主数据库建立有通信连接。在接收到业务数据读请求时，备机房的业务服务器从主数据库中读取业务数据；以及，在接收到业务数据写请求时，备机房的业务服务器向主数据库写入业务数据。

由上面的描述可以看出，当备机房的业务服务器有业务数据读请求或写请求时，备机房的业务服务器不向自己的备数据库读写数据，而是向主机房的主数据库读写数据。采用这种方式的优点在于，业务数据的更新主要发生在主数据库，在主数据库和备数据库之间双向同步业务数据时，以主数据库的业务数据为主，使得备数据库与主数据库的数据能够保持强一致性。而且，这种方式也提高了主数据库和备数据库之间同步数据的便捷性，避免了主数据库和备数据库的业务数据同时发生不同程度的更新而造成的数据同步困难的问题，降低了主备同步的难度。

进一步的，备机房的业务服务器用于：在接收到业务数据写请求时，先向主数据库写入业务数据，而后向备缓存数据库写入业务数据；在接收到业务数据读请求时，先查询备缓存数据库是否存储有业务数据，若是，则从备缓存数据库中读取业务数据；若否，则从主数据库中查询并读取业务数据；以及，若在接收到业务数据读请求后，未在备缓存数据库中查询到业务数据，则在从主数据库读取到业务数据后，将业务数据写入到备缓存数据库中。

备机房部署有备缓存数据库，一方面，能加快备机房的业务服务器对短期内存储在该备缓存数据库中的业务数据的读取速度；另一方面，在写业务数据时，先向主数据库写入业务数据，再向备缓存数据库写入数据；在读业务数据时，先从备缓存数据库中读数据，如果没有，在从主数据库读数据，这样可以解决主数据库负载过高的问题。而且，备缓存数据库与主缓存数据库之间双向同步业务数据，保证缓存之间数据的强一致性。

根据本实施例提供的多机房部署系统，主备机房都部署有各自的缓存数据库和数据库，主备机房的缓存数据库之间双向同步业务数据，数据库之间也双向同步业务数据。当备机房的业务服务器接收到业务数据读请求时，从主机房的主数据库读取业务数据，当备机房的业务服务器接收到业务数据写请求时，向主机房的主数据库写入业务数据。该系统中，业务数据的更新主要发生在主数据库，在主数据库和备数据库之间双向同步业务数据时，以主数据库的业务数据为主，使得备数据库与主数据库的数据能够保持强一致性。而且，这种部署方式也提高了主数据库和备数据库之间同步数据的便捷性，避免了主数据库和备数据的业务数据同时发生不同程度的更新而造成的数据同步困难的问题，降低了主备同步的难度。

图2示出了根据本发明另一个实施例的多机房部署系统的功能框图。如图2所示，本实施例与图1所示的实施例的不同之处在于，主数据库进一步包括MySQL主数据库和SSDB主数据库，备数据库包括MySQL备数据库和SSDB备数据库，其中，MySQL主数据库和MySQL备数据库之间双向同步业务数据，SSDB主数据库和SSDB备数据库之间双向同步业务数据。

MySQL是一种关联数据库管理系统，关联数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。由于其体积小、速度快、总体拥有成本低，尤其是开放源码这一特点，一般中小型网站的开发都选择MySQL作为网站数据库。由于性能卓越，搭配PHP和Apache可组成良好的开发环境。但是，MySQL仍属于传统的关系数据库，在应付超大规模和高并发的网站系统已经显得力不从心，暴露了很多难以克服的问题。

SSDB是一个高性能的支持丰富数据结构的NoSQL数据库,它的访问速度更快，自带数据压缩功能，占用存储空间小。但目前SSDB的Windows版本在多线程环境下还不稳定，经常出现超时的问题。

本发明综合MySQL和SSDB的优缺点，在主数据库和备数据库中分别部署了对应的MySQL数据库和SSDB数据库。采用SSDB+MYSQL进行数据库保存工作，其中将查询关系保存到MySQL数据库中，而将数据存储到SSDB数据库进行持久化存储。

具体来说，主机房的业务服务器在接收到业务数据读请求时，优先从主缓存数据库中查询业务数据，若查询到，则读取；若未查询到，则从MySQL主数据库和SSDB主数据库中查询并读取业务数据。主机房的业务服务器在接收到业务数据写请求时，先向MySQL主数据库和SSDB主数据库中写入业务数据，而后向主缓存数据库写入业务数据。主机房的主缓存数据库只存储短期内的数据，超出一定时间范围内的数据定时清除；而MySQL主数据库和SSDB主数据库对数据进行持久化存储。

备机房的业务服务器在接收到业务数据读请求时，优先从备缓存数据库中查询业务数据，若查询到，则读取；若未查询到，则从MySQL主数据库和SSDB主数据库中查询并读取业务数据。备机房的业务服务器在接收到业务写请求时，先向MySQL主数据库和SSDB主数据库中写入业务数据，而后向备缓存数据库中写入业务数据。备机房的备缓存数据库只存储短期内的数据，超出一定时间范围内的数据定时清除；而MySQL主数据库和SSDB主数据库对数据进行持久化存储。

MySQL主数据库和MySQL备数据库之间双向同步业务数据，SSDB主数据库和SSDB备数据库之间双向同步业务数据，保证MySQL主数据库和MySQL备数据库之间、SSDB主数据库和SSDB备数据库存储数据的强一致性。

进一步的，本实施例中主缓存数据库和备缓存数据库可以均为SSDB缓存数据库，SSDB做缓存时，读取速度远远高于其它类型的缓存，也可以解决MySQL数据库负载过高的问题，进一步的提高了系统的处理性能。

下面以用户注册请求和用户登录请求为例来进一步说明本系统的数据处理过程。用户注册请求可理解为业务数据写请求的一种类型，在接收到用户注册请求后，根据用户注册信息确定允许登录，则将用户注册信息写入缓存和数据库中。用户登录请求可理解为业务数据读请求的一种类型，在接收到用户登录请求后，查询缓存和数据库中是否存储有用户注册信息，若是，则读取用户注册信息判定用户登录成功；否则，用户登录失败。

主机房的业务服务器首先接收到用户A的用户注册请求，在确定允许登录后，主机房的业务服务器将用户注册信息写入主缓存数据库、MySQL主数据库和SSDB主数据库中。在用户A注册成功后，如果用户A向备机房发起用户登录请求，备机房的业务服务器接收到用户A的用户登录请求后，首先在备缓存数据库中查询用户注册信息。如果备缓存数据库通过双向同步从主缓存数据库中获得了用户A的用户注册信息，则从备缓存数据库中可以读取到该用户注册信息，依此判定用户登录成功。如果备缓存数据库中没有查询到用户A的用户注册信息，则备机房的业务服务器从MySQL主数据库和SSDB主数据库中查询并读取用户注册信息。

由此可见，主备机房的业务服务器在MySQL主数据库和SSDB主数据库写数据，也在MySQL主数据库和SSDB主数据库读数据，使得业务数据的更新主要发生的MySQL主数据库和SSDB主数据库。在主备数据库之间双向同步业务数据时，以MySQL主数据库和SSDB主数据库的业务数据为主，使得主备数据库的数据能够保持强一致性。而且，这种方式也提高了主数据库和备数据库之间同步数据的便捷性，避免了主数据库和备数据库的业务数据同时发生不同程度的更新而造成的数据同步困难的问题，降低了主备同步的难度。

另外，主缓存数据库和备缓存数据库之间双向同步业务数据。当某些业务数据通过主机房的业务服务器写入主缓存数据库时，在一定时间内，用户向备机房的业务服务器发起业务数据读请求，备机房的业务服务器可以从备缓存数据库中查询到这些业务数据，提升了业务数据的读取速度。

进一步的，本发明中MySQL主数据库和MySQL备数据库都采用分表技术存储业务数据，即将数据库维护有多张数据表，用于分别存储业务数据。在主机房和备机房的业务服务器从MySQL主数据库中查询业务数据时，并发地从多个数据表查询，提升了数据查询的效率。尤其是在高并发的场景下，采用MySQL分表技术与缓存查询相结合，能大大提升数据读写速度，使主机房能有效应对。

对于用户注册场景，本发明的主备机房提供了不同的用户账号生成规则。具体的，主机房的至少一个业务服务器用于：在接收到用户注册请求时，为用户生成符合第一规则的用户账号，将用户账号和用户注册信息写入主缓存数据库和主数据库中。备机房的至少一个业务服务器用于：在接收到用户注册请求时，为用户生成符合第二规则的用户账号，将用户账号和用户注册信息写入备缓存数据库和主数据库中；其中第一规则不同于第二规则。

以一个备机房为例，主机房的业务服务器在接收到用户注册请求时，生成偶数的用户账号，而备机房的业务服务器在接收到用户注册请求时，生成奇数的用户账号。主备机房的用户账号采用不同的生成规则来生成，避免了若用户账号生成器的初始值相差不大，导致主备机房生成的用户账号可能出现重复，后续主备机房的缓存和数据库进行同步时，会出现错误导致同步失败。

上述奇偶区分仅为一示例，当备机房为多个时，可以为各个机房配置不同的用户账号生成规则，用以对不同机房的用户账号进行区分。

进一步的，本发明中主数据库中可存储有系统账号打通表，在图2对应的实施例中，系统账号打通表可选地存储在SSDB主数据库中。系统账号打通表内记录有系统的用户账号和与系统关联的其它系统的用户账号。

主机房的至少一个业务服务器和/或备机房的至少一个业务服务器还用于：在接收到业务数据读请求或业务数据写请求时，查询系统账号打通表，根据系统账号打通表内是否记录业务数据读请求或业务数据写请求携带的用户账号来确定是否提供业务数据读写服务。也就是说，本发明的多机房部署系统不仅支持本系统内注册用户的数据访问服务，还支持与本系统关联的其它系统注册用户的数据访问服务。通过以系统账号打通表的形式记录用户账号，可以更方便的拓展本系统的用户数量，用更简便的方式将关联的其它系统的用户吸收进来。

在以上各个实施例中，以备机房为一个举例说明，但在实际中，也可部署多个备机房。多个备机房的业务服务器都向主机房的主数据库读写数据，多个备机房的缓存数据库和主数据库与主机房的缓存数据库和主数据库之间数据同步保持一致。

根据本实施例提供的多机房部署系统，主备机房都部署有各自的缓存数据库和数据库，主备机房的缓存数据库之间双向同步业务数据，数据库之间也双向同步业务数据。当备机房的业务服务器接收到业务数据读请求时，从主机房的主数据库读取业务数据，当备机房的业务服务器接收到业务数据写请求时，向主机房的主数据库写入业务数据。该系统中，业务数据的更新主要发生在主数据库，在主数据库和备数据库之间双向同步业务数据时，以主数据库的业务数据为主，使得备数据库与主数据库的数据能够保持强一致性。而且，这种部署方式也提高了主数据库和备数据库之间同步数据的便捷性，避免了主数据库和备数据的业务数据同时发生不同程度的更新而造成的数据同步困难的问题，降低了主备同步的难度。进一步的，主机房和备机房都分别部署了MySQL数据库和SSDB数据库，采用SSDB+MYSQL进行数据库保存工作，集合了MySQL和SSDB的数据存储优势。而且，缓存数据库也采用SSDB缓存，读取速度远远高于其它类型的缓存，进一步的提高了系统的处理性能。本实施例的系统中还可采用MySQL分表技术与缓存查询相结合，大大提升数据读写速度，使得系统能有效应对高并发场景。

图3示出了根据本发明一个实施例的跨机房的业务数据处理方法的流程图。如图3所示，该方法包括如下步骤：

步骤S301，主机房的主缓存数据库和备机房的备缓存数据库之间双向同步业务数据，主机房的主数据库与备机房的备数据库之间双向同步业务数据。

步骤S302，当备机房的业务服务器接收到业务数据读请求时，从主数据库中读取业务数据；或者，当备机房的业务服务器接收到业务数据写请求时，向主数据库写入业务数据。

其中，在步骤S302中，当备机房的业务服务器接收到业务数据读请求时，查询备缓存数据库是否存储有业务数据；若查询备缓存数据库存储有业务数据，则从备缓存数据库中读取业务数据；若查询备缓存数据库没有存储业务数据，则从主数据库中读取业务数据。进一步的，在从主数据库中读取业务数据之后，还将业务数据写入到备缓存数据库中。

当备机房的业务服务器接收到业务数据写请求时，首先向主数据库写入业务数据，然后向备缓存数据库写入业务数据。

进一步的，该方法还包括：当主机房的业务服务器接收到业务数据读请求时，从主缓存数据库或主数据库中读取业务数据；或者，当主机房的业务服务器接收到业务数据写请求时，依次向主数据库和主缓存数据库写入业务数据。

本实施例提供的方法可适用于上述图1或图2所示的系统中，主数据库包括MySQL主数据库和SSDB主数据库，备数据库包括MySQL备数据库和SSDB备数据库；主机房的主数据库与备机房的备数据库之间双向同步业务数据进一步包括：MySQL主数据库和MySQL备数据库之间双向同步业务数据，SSDB主数据库和SSDB备数据库中间双向同步业务数据。

MySQL主数据库用于采用分表技术存储业务数据；当主备机房的业务服务器从主数据库中读取业务数据时，并发地从MySQL主数据库的多个数据表中查询业务数据，根据查询结果读取业务数据。假设MySQL主数据库中共有10个数据表，业务服务器可并发地同时在10个数据表中查找数据，在查找到数据的数据表中读取数据。

进一步的，该方法还包括：当主机房的业务服务器接收到用户注册请求时，为用户生成符合第一规则的用户账号，将用户账号和用户注册信息写入主缓存数据库和主数据库中；当备机房的业务服务器接收到用户注册请求时，为用户生成符合第二规则的用户账号，将用户账号和用户注册信息写入备缓存数据库和主数据库中。第一规则不同于第二规则。有关第一规则和第二规则的描述可参见上述实施例。

本方法中，主数据库中存储有系统账号打通表，系统账号打通表内记录有本系统的用户账号和与本系统关联的其它系统的用户账号。

在主机房的业务服务器和/或备机房的业务服务器接收到业务数据读请求或业务数据写请求时，查询系统账号打通表，根据系统账号打通表内是否记录业务数据读请求或业务数据写请求携带的用户账号来确定是否提供业务数据读写服务。

根据本实施例提供的跨机房的业务数据处理方法，主备机房的缓存数据库之间双向同步业务数据，数据库之间也双向同步业务数据。当备机房的业务服务器接收到业务数据读请求时，从主机房的主数据库读取业务数据，当备机房的业务服务器接收到业务数据写请求时，向主机房的主数据库写入业务数据。本方法中，业务数据的更新主要发生在主数据库，在主数据库和备数据库之间双向同步业务数据时，以主数据库的业务数据为主，使得备数据库与主数据库的数据能够保持强一致性。而且，本方法也提高了主数据库和备数据库之间同步数据的便捷性，避免了主数据库和备数据的业务数据同时发生不同程度的更新而造成的数据同步困难的问题，降低了主备同步的难度。本方法中还可采用MySQL分表技术与缓存查询相结合，大大提升数据读写速度，使得系统能有效应对高并发场景。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的多机房部署系统中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

本发明公开了：

A1、一种多机房部署系统，包括：主机房和备机房，所述主机房包括至少一个业务服务器以及用于存储业务数据的主缓存数据库和主数据库，所述备机房包括至少一个业务服务器以及用于存储业务数据的备缓存数据库和备数据库；所述主缓存数据库和所述备缓存数据库之间双向同步业务数据，所述主数据库与所述备数据库之间双向同步业务数据；

所述备机房的至少一个业务服务器用于：在接收到业务数据读请求时，从所述主数据库中读取业务数据；以及，在接收到业务数据写请求时，向所述主数据库写入业务数据。

A2、根据A1所述的系统，所述备机房的至少一个业务服务器进一步用于：在接收到业务数据读请求时，先查询所述备缓存数据库是否存储有业务数据，若是，则从所述备缓存数据库中读取业务数据；若否，则从所述主数据库中查询并读取业务数据。

A3、根据A2所述的系统，所述备机房的至少一个业务服务器进一步用于：若在接收到业务数据读请求后，未在所述备缓存数据库中查询到业务数据，则在从所述主数据库读取到业务数据后，将业务数据写入到所述备缓存数据库中。

A4、根据A1-A3任一项所述的系统，所述备机房的至少一个业务服务器进一步用于：在接收到业务数据写请求时，先向所述主数据库写入业务数据，而后向所述备缓存数据库写入业务数据。

A5、根据A1-A4任一项所述的系统，所述主机房的至少一个业务服务器用于：在接收到业务数据读请求时，从所述主缓存数据库或主数据库中读取业务数据；以及，在接收到业务数据写请求时，依次向所述主数据库和所述主缓存数据库中写入业务数据。

A6、根据A1-A5任一项所述的系统，所述主数据库包括MySQL主数据库和SSDB主数据库，所述备数据库包括MySQL备数据库和SSDB备数据库；

所述MySQL主数据库和所述MySQL备数据库之间双向同步业务数据，所述SSDB主数据库和所述SSDB备数据库中间双向同步业务数据。

A7、根据A6所述的系统，所述MySQL主数据库用于采用分表技术存储业务数据，在从所述MySQL主数据库查询业务数据时，并发地从多个数据表查询业务数据。

A8、根据A1-A7任一项所述的系统，所述主机房的至少一个业务服务器用于：在接收到用户注册请求时，为用户生成符合第一规则的用户账号，将所述用户账号和用户注册信息写入所述主缓存数据库和所述主数据库中；

所述备机房的至少一个业务服务器用于：在接收到用户注册请求时，为用户生成符合第二规则的用户账号，将所述用户账号和用户注册信息写入所述备缓存数据库和所述主数据库中；

所述第一规则不同于所述第二规则。

A9、根据A1-A8任一项所述的系统，所述主数据库中存储有系统账号打通表，所述系统账号打通表内记录有所述系统的用户账号和与所述系统关联的其它系统的用户账号；

所述主机房的至少一个业务服务器和/或备机房的至少一个业务服务器还用于：在接收到业务数据读请求或业务数据写请求时，查询所述系统账号打通表，根据所述系统账号打通表内是否记录所述业务数据读请求或业务数据写请求携带的用户账号来确定是否提供业务数据读写服务。

B10、一种跨机房的业务数据处理方法，包括：

主机房的主缓存数据库和备机房的备缓存数据库之间双向同步业务数据，主机房的主数据库与备机房的备数据库之间双向同步业务数据；

当备机房的业务服务器接收到业务数据读请求时，从所述主数据库中读取业务数据；或者，当备机房的业务服务器接收到业务数据写请求时，向所述主数据库写入业务数据。

B11、根据B10所述的方法，所述当备机房的业务服务器接收到业务数据读请求时，所述方法还包括：查询所述备缓存数据库是否存储有业务数据；若查询所述备缓存数据库存储有业务数据，则从所述备缓存数据库中读取业务数据；

所述从主数据库中读取业务数据具体为：若查询所述备缓存数据库没有存储业务数据，则从主数据库中读取业务数据。

B12、根据B11所述的方法，在所述从主数据库中读取业务数据之后，所述方法还包括：将业务数据写入到所述备缓存数据库中。

B13、根据B10-B12任一项所述的方法，当备机房的业务服务器接收到业务数据写请求时，所述方法还包括：在向所述主数据库写入业务数据之后，向所述备缓存数据库写入业务数据。

B14、根据B10-B13任一项所述的方法，所述方法还包括：

当主机房的业务服务器接收到业务数据读请求时，从所述主缓存数据库或主数据库中读取业务数据；或者，当主机房的业务服务器接收到业务数据写请求时，依次向所述主数据库和所述主缓存数据库写入业务数据。

B15、根据B10-B14任一项所述的方法，所述主数据库包括MySQL主数据库和SSDB主数据库，所述备数据库包括MySQL备数据库和SSDB备数据库；

所述主机房的主数据库与备机房的备数据库之间双向同步业务数据进一步包括：所述MySQL主数据库和所述MySQL备数据库之间双向同步业务数据，所述SSDB主数据库和所述SSDB备数据库中间双向同步业务数据。

B16、根据B15所述的方法，所述MySQL主数据库用于采用分表技术存储业务数据；

所述从主数据库中读取业务数据进一步包括：并发地从所述MySQL主数据库的多个数据表中查询业务数据，根据查询结果读取业务数据。

B17、根据B10-B16任一项所述的方法，所述方法还包括：

当主机房的业务服务器接收到用户注册请求时，为用户生成符合第一规则的用户账号，将所述用户账号和用户注册信息写入所述主缓存数据库和所述主数据库中；

当备机房的业务服务器接收到用户注册请求时，为用户生成符合第二规则的用户账号，将所述用户账号和用户注册信息写入所述备缓存数据库和所述主数据库中；

所述第一规则不同于所述第二规则。

B18、根据B10-B17任一项所述的方法，所述主数据库中存储有系统账号打通表，所述系统账号打通表内记录有所述系统的用户账号和与所述系统关联的其它系统的用户账号；

所述方法还包括：

在主机房的业务服务器和/或备机房的业务服务器接收到业务数据读请求或业务数据写请求时，查询所述系统账号打通表，根据所述系统账号打通表内是否记录所述业务数据读请求或业务数据写请求携带的用户账号来确定是否提供业务数据读写服务。

Claims (10)

1.一种多机房部署系统，包括：主机房和备机房，所述主机房包括至少一个业务服务器以及用于存储业务数据的主缓存数据库和主数据库，所述备机房包括至少一个业务服务器以及用于存储业务数据的备缓存数据库和备数据库；所述主缓存数据库和所述备缓存数据库之间双向同步业务数据，所述主数据库与所述备数据库之间双向同步业务数据；

所述备机房的至少一个业务服务器用于：在接收到业务数据读请求时，从所述主数据库中读取业务数据；以及，在接收到业务数据写请求时，向所述主数据库写入业务数据。

2.根据权利要求1所述的系统，所述备机房的至少一个业务服务器进一步用于：在接收到业务数据读请求时，先查询所述备缓存数据库是否存储有业务数据，若是，则从所述备缓存数据库中读取业务数据；若否，则从所述主数据库中查询并读取业务数据。

3.根据权利要求2所述的系统，所述备机房的至少一个业务服务器进一步用于：若在接收到业务数据读请求后，未在所述备缓存数据库中查询到业务数据，则在从所述主数据库读取到业务数据后，将业务数据写入到所述备缓存数据库中。

4.根据权利要求1-3任一项所述的系统，所述备机房的至少一个业务服务器进一步用于：在接收到业务数据写请求时，先向所述主数据库写入业务数据，而后向所述备缓存数据库写入业务数据。

5.根据权利要求1-4任一项所述的系统，所述主机房的至少一个业务服务器用于：在接收到业务数据读请求时，从所述主缓存数据库或主数据库中读取业务数据；以及，在接收到业务数据写请求时，依次向所述主数据库和所述主缓存数据库中写入业务数据。

6.根据权利要求1-5任一项所述的系统，所述主数据库包括MySQL主数据库和SSDB主数据库，所述备数据库包括MySQL备数据库和SSDB备数据库；

所述MySQL主数据库和所述MySQL备数据库之间双向同步业务数据，所述SSDB主数据库和所述SSDB备数据库中间双向同步业务数据。

7.根据权利要求6所述的系统，所述MySQL主数据库用于采用分表技术存储业务数据，在从所述MySQL主数据库查询业务数据时，并发地从多个数据表查询业务数据。

8.根据权利要求1-7任一项所述的系统，所述主机房的至少一个业务服务器用于：在接收到用户注册请求时，为用户生成符合第一规则的用户账号，将所述用户账号和用户注册信息写入所述主缓存数据库和所述主数据库中；

所述备机房的至少一个业务服务器用于：在接收到用户注册请求时，为用户生成符合第二规则的用户账号，将所述用户账号和用户注册信息写入所述备缓存数据库和所述主数据库中；

所述第一规则不同于所述第二规则。

9.根据权利要求1-8任一项所述的系统，所述主数据库中存储有系统账号打通表，所述系统账号打通表内记录有所述系统的用户账号和与所述系统关联的其它系统的用户账号；

所述主机房的至少一个业务服务器和/或备机房的至少一个业务服务器还用于：在接收到业务数据读请求或业务数据写请求时，查询所述系统账号打通表，根据所述系统账号打通表内是否记录所述业务数据读请求或业务数据写请求携带的用户账号来确定是否提供业务数据读写服务。

10.一种跨机房的业务数据处理方法，包括：

主机房的主缓存数据库和备机房的备缓存数据库之间双向同步业务数据，主机房的主数据库与备机房的备数据库之间双向同步业务数据；

当备机房的业务服务器接收到业务数据读请求时，从所述主数据库中读取业务数据；或者，当备机房的业务服务器接收到业务数据写请求时，向所述主数据库写入业务数据。