CN105045897B - 支持数据库扩容的业务处理系统及方法 - Google Patents
支持数据库扩容的业务处理系统及方法 Download PDFInfo
- Publication number
- CN105045897B CN105045897B CN201510466061.1A CN201510466061A CN105045897B CN 105045897 B CN105045897 B CN 105045897B CN 201510466061 A CN201510466061 A CN 201510466061A CN 105045897 B CN105045897 B CN 105045897B
- Authority
- CN
- China
- Prior art keywords
- user
- server
- class
- service
- database server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/21—Design, administration or maintenance of databases
- G06F16/215—Improving data quality; Data cleansing, e.g. de-duplication, removing invalid entries or correcting typographical errors
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/182—Distributed file systems
- G06F16/1824—Distributed file systems implemented using Network-attached Storage [NAS] architecture
- G06F16/183—Provision of network file services by network file servers, e.g. by using NFS, CIFS
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明实施例提供支持数据库扩容的业务处理系统及方法，能够克服“写冲突”，使得多数据库服务器可并行运算。所述业务处理系统包括：门户应用服务器、业务处理服务器、N个数据库服务器、存储设备；存储设备存储有M类用户的数据，M类用户的数据分别存储在不同的物理数据块中；N个数据库服务器中任意两个数据库服务器分别用于更新M类用户中两类不同用户的数据；门户应用服务器用于接收业务请求，根据用户的标识确定对应的数据库服务器及存储用户数据的物理数据块；向数据库服务器转发业务请求及物理数据块的标识，以使数据库服务器根据业务请求对物理数据块中存储的用户数据进行写操作。本发明适用于数据库领域。
Description
技术领域
本发明涉及数据库领域，尤其涉及支持数据库扩容的业务处理系统及方法。
背景技术
联机事务处理(On-Line Transaction Processing，OLTP)系统是一种面向交易的事务处理系统，其能够即时将用户提交的请求数据传送到计算中心进行处理，并在很短的时间内给出处理结果。例如，电子商务系统、银行系统都是典型的OLTP系统。
目前，OLTP系统中多采用Oracle数据库保存核心数据、执行核心业务逻辑。Oracle数据库特有的实时应用集群(Real Application Clusters，RAC)技术支持多个数据库服务器访问同一个Oracle数据库，理论上而言，多个数据库服务器可实现并行运算，因而通过增加数据库服务器的数目即可实现OLTP系统数据处理性能的线性增长，而事实上并非如此。这是因为数据库服务器增加后，多个数据库服务器可能需要对同一数据块进行更新操作(更新或删除)，此时，最先获取该数据块的数据库服务器没有完成更新操作之前，其他所有数据库服务器均需等待，这一现象被称为“写冲突”。显然，若OLTP系统中“写冲突”过多，则会使系统的数据处理性能快速下降。
因此，如果能够克服Oracle数据库RAC技术出现的“写冲突”问题，使得多个数据库服务器能够并行运算，那么就可通过增加数据库服务器提升OLTP系统的数据处理性能。
发明内容
为此，本发明实施例提供支持数据库扩容的业务处理系统及方法，以克服现有技术存在的“写冲突”，使得多数据库服务器能够并行运算，进而提升系统的数据处理性能。
第一方面，提供一种支持数据库扩容的业务处理系统，所述业务处理系统包括：门户应用服务器、业务处理服务器、N个数据库服务器、存储设备；其中，所述存储设备存储有M类用户的数据，所述M类用户中每类用户的数据存储在至少1个物理数据块中，且所述M类用户的数据分别存储在不同的物理数据块中；所述N个数据库服务器中任意两个数据库服务器分别用于更新所述M类用户中两类不同用户的数据，N、M为整数，N≥1，M≥1；
所述门户应用服务器，用于获取用户通过接入界面发起的业务请求，并向所述业务处理服务器发送所述业务请求，所述业务请求携带有所述用户的标识；
所述业务处理服务器用于：
接收所述业务请求，并根据所述用户的标识，确定所述用户所属的用户类别，结合预存的用户类别与数据库服务器的路由关系，确定对应的数据库服务器；
根据所述用户的标识，结合预存的用户与物理数据块间的对应关系，确定存储所述用户的数据的物理数据块；
向所述数据库服务器转发所述业务请求及所述物理数据块的标识，以使所述数据库服务器根据所述业务请求对所述物理数据块中存储的所述用户的数据进行写操作。
在第一方面第一种可能的实现方式中，结合第一方面，所述M类用户包括管理员用户及n类普通用户，所述M类用户的数据包括公共数据及所述n类普通用户的业务数据，所述N个数据库服务器包括1个第一数据库服务器、n个第二数据库服务器及至少1个第三数据库服务器，所述第一数据库服务器用于更新所述公共数据，所述n个第二数据库服务器分别用于更新及查询所述n类用户的业务数据，所述第三数据库服务器用于查询所述公共数据，n为整数，n＝M-1。
在第一方面第二种可能的实现方式中，结合第一方面第一种可能的实现方式，所述业务请求还携带有所请求业务的类型；
所述门户应用服务器，还用于在获取用户通过接入界面发起的业务请求之后，根据所述业务请求携带的所述用户的标识及所请求业务的类型，在所述业务处理服务器提供的服务接口中确定对应的服务接口；
所述门户应用服务器，具体用于调用所述服务接口向所述业务处理服务器发送所述业务请求。
在第一方面第三种可能的实现方式中，结合第一方面第二种可能的实现方式，所述业务处理服务器，还用于在接收所述业务请求之后，根据所述门户应用服务器所调用的服务接口，确定是否需要进行数据库访问；
所述业务处理服务器，具体用于若确定需要进行数据库访问，根据所述用户的标识，确定所述用户所属的用户类别，结合预存的用户类别与数据库服务器的路由关系，确定对应的数据库服务器。
在第一方面第四种可能的实现方式中，结合第一方面第三种可能的实现方式，所述业务处理服务器，具体用于根据所述门户应用服务器所调用的服务接口，确定是否需要对普通用户的业务数据进行处理；
若是，根据所述用户的标识，确定所述用户所属的用户类别，并结合预存的用户类别与数据库服务器的路由关系，从所述n个第二数据库服务器中确定对应的数据库服务器；
若否，根据所述业务请求携带的所请求业务的类型，确定所请求业务是否属于查询类业务请求；
若确定所请求业务属于查询类业务请求，根据负载均衡原则，在所述至少1个第三数据库服务器中确定对应的数据库服务器；
若确定所请求业务不属于查询类业务请求，将所述第二数据库服务器确定为对应的数据库服务器。
在第一方面第五种可能的实现方式中，结合第一方面，所述M类用户包括管理员用户及n类普通用户，所述M类用户的数据包括公共数据及所述n类普通用户的业务数据，所述N个数据库服务器包括1个第四数据库服务器及n个第五数据库服务器，所述第四数据库服务器用于更新及查询公共数据，所述n个第五数据库服务器分别用于更新及查询所述n类普通用户的业务数据，n为整数，n＝M-1。
第二方面，提供一种业务处理方法，所述方法应用于第一方面至第一方面第四种可能的实现方式中的任一种所述的业务处理系统，所述方法包括：
门户应用服务器获取用户通过接入界面发起的业务请求，并向业务处理服务器发送所述业务请求，所述业务请求携带有所述用户的标识；
所述业务处理服务器接收所述业务请求，并根据所述用户的标识，确定所述用户所属的用户类别，结合预存的用户类别与数据库服务器的路由关系，确定对应的数据库服务器；
所述业务处理服务器根据所述用户的标识，结合预存的用户与物理数据块间的对应关系，确定存储所述用户的数据的物理数据块；
所述业务处理服务器向所述数据库服务器转发所述业务请求及所述物理数据块的标识，以使所述数据库服务器根据所述业务请求对所述物理数据块中存储的所述用户的数据进行写操作。
在第二方面第一种可能的实现方式中，结合第一方面，所述业务请求还携带有所请求业务的类型，在所述门户应用服务器获取用户通过接入界面发起的业务请求之后，所述方法还包括：
所述门户应用服务器根据所述业务请求携带的所述用户的标识及所请求业务的类型，在所述业务处理服务器提供的服务接口中确定对应的服务接口；
所述门户应用服务器向业务处理服务器发送所述业务请求，包括：
所述门户应用服务器调用所述服务接口向所述业务处理服务器发送所述业务请求。
在第二方面第二种可能的实现方式中，结合第二方面第一种可能的实现方式，在所述业务处理服务器接收所述业务请求之后，所述方法还包括：
根据所述门户应用服务器所调用的服务接口，确定是否需要进行数据库访问；
所述业务处理服务器根据所述用户的标识，确定所述用户所属的用户类别，结合预存的用户类别与数据库服务器的路由关系，确定对应的数据库服务器，包括：
若所述业务处理服务器确定需要进行数据库访问，所述业务处理服务器根据所述用户的标识，确定所述用户所属的用户类别，结合预存的用户类别与数据库服务器的路由关系，确定对应的数据库服务器。
在第二方面第三种可能的实现方式中，结合第二方面第二种可能的实现方式，所述业务处理服务器根据所述用户的标识，确定所述用户所属的用户类别，结合预存的用户类别与数据库服务器的路由关系，确定对应的数据库服务器，包括：
所述业务处理服务器根据所述门户应用服务器所调用的服务接口，确定是否需要对普通用户的业务数据进行处理；
若是，所述业务处理服务器确定所述用户所属的用户类别，并结合预存的用户类别与数据库服务器的路由关系，从所述n个第二数据库服务器中确定对应的数据库服务器；
若否，所述业务处理服务器根据所述业务请求携带的所请求业务的类型，确定所请求业务是否属于查询类业务请求；
若确定所请求业务属于查询类业务请求，所述业务处理服务器根据负载均衡原则，在所述至少1个第三数据库服务器中确定对应的数据库服务器；
若确定所请求业务不属于查询类业务请求，所述业务处理服务器将所述第一数据库服务器确定为对应的数据库服务器。
基于本发明实施例提供的支持数据库扩容的业务处理系统及方法，通过将用户组划分为M类用户，并将M类用户的数据分别存储在存储设备的不同的物理数据块中，以将M类用户的数据在存储上隔离开来。同时，为系统中的N个数据库服务器分配不同类别的用户，使得N个数据库服务器中任意两个数据库服务器分别用于更新M类用户中两类不同的用户的数据。并且，在业务请求中携带发起业务请求的用户的标识，这样一来，在业务系统获取到业务请求后，即可根据业务请求所携带的用户标识从N个数据库服务器中确定唯一对应的一个数据库服务器，从而交由该数据库服务器处理该业务请求。由于N个数据库服务器中任意两个数据库服务器分别用于更新M类用户中两类不同的用户的数据，而M类用户的数据分别存储在不同的物理数据块上，因此不会出现多个数据库服务器更新同一物理数据块中的数据的情形，即多个数据库服务器之间不会出现“写冲突”。
综上，本发明实施例提供的支持数据库扩容的业务处理系统及方法能够避免多个数据库服务器之间的“写冲突”，使得多数据库服务器能够并行运算，进而提升系统的数据处理性能。另外，当用户数量增加，使得系统处理性能出现瓶颈时，可通过增加数据库服务器的数量提升数据处理性能，从而实现数据库的平滑扩容。
附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为“业务分库”技术的原理示意图；
图2为本发明实施例提供的一种支持数据库扩容的业务处理系统的组成示意图；
图3为本发明实施例提供的另一种支持数据库扩容的业务处理系统的组成示意图；
图4为本发明实施例提供的又一种支持数据库扩容的业务处理系统的组成示意图；
图5为本发明实施例提供的一种业务处理方法的交互示意图；
图6为本发明实施例提供的另一种业务处理方法的交互示意图；
图7为本发明实施例提供的又一种业务处理方法的交互示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
为突出本发明的优势，首先对现有的解决“写冲突”的方案-“业务分库”技术进行简要介绍如下：
“业务分库”技术将业务分解为多个子业务，并为每个子业务分配对应的数据库用户账号，使用不同的数据库用户账号保存对应子业务的数据。由于不同数据库用户的数据存储在不同的物理数据块上，因此通过数据库用户账号保存各子业务的数据，可以将各子业务的数据进行物理隔离。同时，在进行数据处理时，对于一种子业务，使用同一个数据库服务器进行处理，如图1所示，这样一来，每个物理数据块上的数据只能由某个特定的数据库服务器访问，因而就不会出现多个数据库服务器对同一物理数据块进行更新操作的情况，进而不同的数据库服务器之间也就不存在“写冲突”了。
然而，该方案要求各个子业务消耗的数据处理性能要相对平均，以使各数据库服务器的处理能力都能应对其对应的子业务的消耗。如果某个子业务数据处理性能消耗特别大，使得其对应的数据库服务器无法满足处理需求，则只能效仿传统的单实例数据库系统的解决办法，通过升级数据库服务器硬件来提升数据处理能力。而通过升级硬件来提升数据处理能力有一定的局限性：一方面，但单一硬件设备的处理性能是有上限的，而用户请求量却没有上限，随着用户数量的增加，这一解决办法仍会遇到瓶颈；另一方面，升级硬件设备需要一定的资金，这无疑会增加成本，使得利润降低。
为此，本发明实施例提供了一种支持数据库扩容的业务处理系统及方法，以克服现有技术存在的“写冲突”，实现多数据库服务器的并行运算，进而使得系统能够通过增加数据库服务器提升数据处理性能。
其次，需要说明的是，为了便于清楚描述本发明实施例的技术方案，在本发明的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分，本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定。
图2所示为本发明实施例提供的一种支持数据库扩容的业务处理系统20的组成示意图。
如图2所示，所述业务处理系统20具体可以包括：门户应用服务器201、业务处理服务器202、存储设备204以及N个数据库服务器203。
其中，存储设备204存储有M类用户的数据，M类用户中每类用户的数据存储在至少1个物理数据块中，且M类用户的数据分别存储在不同的物理数据块中；N个数据库服务器203中任意两个数据库服务器203分别用于更新M类用户中两类不同的用户的数据，N、M为整数，N≥1，M≥1。
门户应用服务器201，用于获取用户通过接入界面发起的业务请求，并向业务处理服务器202发送业务请求，业务请求携带有用户的标识。
业务处理服务器202用于：
接收业务请求，并根据用户的标识，确定用户所属的用户类别，结合预存的用户类别与数据库服务器203的路由关系，确定对应的数据库服务器203；
根据用户的标识，结合预存的用户与物理数据块间的对应关系，确定存储用户的数据的物理数据块；
向数据库服务器203转发业务请求及物理数据块的标识，以使数据库服务器203根据业务请求对物理数据块中存储的用户的数据进行写操作。
其中，需要说明的是，本发明实施例中，所述业务处理系统20具体可以是OLTP系统；所述业务具体可以是短消息服务(Short Message Service，SMS)业务、交互式语音应答(Interactive Voice Response，IVR)业务、非结构化补充数据(UnstructuredSupplementary Service Data，USSD)业务、回铃音(Ring Back Tone，RBT)业务(俗称“彩铃业务”)等等；所述业务请求具体可以是个人账户管理、个人业务管理、内容订购、批价计费、个人套餐管理、日志查询、数据统计等与业务数据相关的请求，还可以是权限角色维护、系统参数管理、配置管理、内容管理、套餐信息维护、管理员账户管理等与用户业务数据无关的请求，本发明实施例对此不作具体限定。
还需说明的是，可根据用户特征划分M类用户，例如，将用户组简单分为普通用户及管理员两类，再如，将用户组分为“全球通”用户、“动感地带”用户、“神州行”用户及管理员四类用户。当然，还可按照其他方式划分用户组，比如，将用户组分为两类用户，一类为“全球通”用户和管理员，一类为“动感地带”用户和“神州行”用户。应当理解，以上所述仅为本发明实施例为了解释说明而给出的简单示例，并不对本发明实施例构成任何限制。在实际应用中，无论按照何种方式划分M类用户，都需保证划分后的M类用户没有重叠部分，换言之，对于某个用户，其只能属于M类用户中的某一类用户，而不应当出现其既属于M类用户中的A类用户，又属于M类用户中的B类用户的情形。
值得说明的是，本领域技术人员容易想到，在存储M类用户的数据时，可使用Oracle数据库的分区表技术将M类用户的数据分别存储在不同的物理数据块中。具体而言，通过分区表技术可得到多个分区，不同的分区对应不同的物理数据块，在各分区添加“用户类别”字段，并为每一类别设置对应的键值，在存储用户数据时，将“用户类别”键值相同的用户存储在指定的分区中，如此，即可将不同类别的用户的数据分别存储在不同的物理数据块中。当然，以上所述仅为本发明实施例提供的一种实现方式，本领域技术人员可以理解，还有其他实现方式，本发明实施例对此不作具体限定。
另外，需要说明的是，本发明实施例所述的更新指写操作，如对数据的更新及删除操作。
综上，本发明实施例所述的业务处理系统20，通过将用户组划分为M类用户，并将M类用户的数据分别存储在存储设备204的不同的物理数据块中，以将M类用户的数据在存储上隔离开来。同时，为系统中的N个数据库服务器203分配不同类别的用户，使得N个数据库服务器203中任意两个数据库服务器分别用于更新M类用户中两类不同的用户的数据。并且，在业务请求中携带发起业务请求的用户的标识，这样一来，在业务系统20获取到业务请求后，即可根据业务请求所携带的用户标识从N个数据库服务器中确定唯一对应的一个数据库服务器，从而交由该数据库服务器处理该业务请求。由于N个数据库服务器20中任意两个数据库服务器分别用于更新M类用户中两类不同的用户的数据，而M类用户的数据分别存储在不同的物理数据块上，因此不会出现多个数据库服务器更新同一物理数据块中的数据的情形，即多个数据库服务器之间不会出现“写冲突”。
另外，当用户数量增加，使得系统处理性能出现瓶颈时，现有的“业务分库”技术需要通过升级硬件设备提升系统数据处理性能。而本发明实施例所述的业务处理系统可通过增加数据库服务器的数量提升系统数据处理性能，而无需升级硬件设备。因此，相比现有技术，本发明实施例所述业务处理系统可实现数据库的平滑扩容，同时成本较低。
本发明实施例的一种实现方式中，如图3所示，M类用户包括管理员用户及n类普通用户，M类用户的数据包括公共数据及n类普通用户的业务数据，N个数据库服务器203包括1个第一数据库服务器203a、n个第二数据库服务器203b及至少1个第三数据库服务器203c，第一数据库服务器203a用于更新公共数据，n个第二数据库服务器203b分别用于更新及查询n类用户的业务数据，第三数据库服务器203c用于查询公共数据。其中，n为整数，n＝M-1。
其中，需说明的是，如无特别说明，本发明实施例所述的公共数据指与普通用户的业务数据无关的公共数据。
另外，还需说明的是，类似于M类用户的划分，可依据用户特征来划分n类普通用户，如根据用户所使用的电话号码的号段来进行划分，比如将电话号码为“134XXXXXXXX”的用户划分为一类，将电话号码为“135XXXXXXXX”的用户划分为一类，将电话号码为“138XXXXXXXX”的用户划分为一类，......以此类推。本发明实施例对此不作具体限定。
本领域技术人员容易理解，随着用户事务交易和系统公共数据的增加，对于公共数据的查询也会快速上升。本发明实施例所述的业务系统20中，通过将系统公共数据单独存储在指定的物理数据块上，以将系统公共数据分离出来，并分配多个数据库服务器用于公共数据的查询，同时分配相应的数据库服务器用于公共数据的更新。由于查询操作属于“读”操作，因此多个数据库服务器可同时访问存储公共数据的物理数据块，多个数据库服务器之间不会出现冲突。同时，当用户对公共数据的查询需求上升后，可通过增加用于公共数据查询的数据库服务器来提升公共数据查询的处理性能。
进一步的，本发明实施例所述的业务处理系统20中，业务请求还携带有所请求业务的类型。
门户应用服务器201，还用于在获取用户通过接入界面发起的业务请求之后，根据业务请求携带的用户的标识及所请求业务的类型，在业务处理服务器202提供的服务接口中确定对应的服务接口。
门户应用服务器201，具体用于调用服务接口向业务处理服务器202发送业务请求。
通常，业务处理服务器202会对外提供多种服务接口用以供门户应用服务器201传递业务请求，并且，所传递的业务请求不同，门户应用服务器201所调用的服务接口也有所区别，具体调用哪些服务接口取决于用户发起的业务请求的类型。
更进一步的，业务处理服务器202，还用于在接收业务请求之后，根据门户应用服务器201所调用的服务接口，确定是否需要进行数据库访问。
业务处理服务器202，具体用于若确定需要进行数据库访问，根据用户的标识，确定用户所属的用户类别，结合预存的用户类别与数据库服务器203的路由关系，确定对应的数据库服务器203。
通常，可将业务请求分为需要进行数据库访问的业务请求，如内容订购的相关业务，以及，不需要进行数据库访问的业务请求，如协议转换的相关业务。相应的，也可将服务接口分为两类-需要进行数据库访问的接口及不需要进行数据库访问的接口。进一步的，根据所请求业务是否需要对普通用户的业务数据进行处理，又可将需要进行数据库访问的接口分为需要进行用户业务数据处理的接口和无需进行用户业务数据处理的接口。这样一来，业务处理服务器202即可根据被调用的服务接口确定该业务请求是否需要进行数据库访问以及是否需要对用户业务数据进行处理。若确定该业务请求需要进行数据库访问，再从多个数据库服务器中选择对应的数据库服务器来执行业务；若确定该业务请求不需要进行数据库访问(如读取系统物理文件的请求)，则由业务处理服务器202直接执行，而无需再通过数据库服务器对数据库进行访问。
示例性的，假设所请求业务为内容订购，则门户应用服务器201调用需要进行数据库访问的接口传递业务请求，同时，业务处理服务器202得知被调用的接口为需要进行数据库访问的接口，确定需要进行数据库访问。
由于业务处理系统20中存在多个数据库服务器，因此，在确定需要进行数据库访问后，还需要进一步从多个数据库服务器中选择对应的数据库服务器处理业务请求。
具体的，本发明实施例提供的支持数据库扩容的业务处理系统20中，业务处理服务器202具体可以用于：
根据门户应用服务器201所调用的服务接口，确定是否需要对普通用户的业务数据进行处理；
若是，根据用户的标识，确定用户所属的用户类别，并结合预存的用户类别与数据库服务器203的路由关系，从n个第二数据库服务器203b中确定对应的数据库服务器；
若否，根据业务请求携带的所请求业务的类型，确定所请求业务是否属于查询类业务请求；
若确定所请求业务属于查询类业务请求，根据负载均衡原则，在至少1个第三数据库服务器203c中确定对应的数据库服务器；
若确定所请求业务不属于查询类业务请求，将第一数据库服务器203a确定为对应的数据库服务器。
即，根据门户应用服务器201所调用的服务接口，确定需要对普通用户的业务数据进行处理后，从n个第二数据库服务器203b中确定对应的数据库服务器；确定不需要对普通用户的业务数据进行处理后，进一步确定所请求业务是否属于查询类业务请求，若是，在至少1个第三数据库服务器203c中确定对应的数据库服务器，若否，将第一数据库服务器203a确定为对应的数据库服务器。
本发明实施例的另一种实现方式中，如图4所示，M类用户具体可以包括管理员用户及n类普通用户，M类用户的数据包括公共数据及n类普通用户的业务数据，N个数据库服务器203包括1个第四数据库服务器203d及n个第五数据库服务器203e，第四数据库服务器203d用于更新及查询公共数据，n个第五数据库服务器203e分别用于更新及查询n类普通用户的业务数据。其中，n为整数，n＝M-1。
即，将M类用户划分为管理员用户及n类普通用户，分别用N个数据库服务器203中的n个数据库服务器对应管理n类普通用户，用N个数据库服务器203中的一个数据库服务器管理系统公共数据。
本发明实施例提供的支持数据库扩容的业务处理系统中，通过将用户组划分为M类用户，并将M类用户的数据分别存储在存储设备的不同的物理数据块中，以将M类用户的数据在存储上隔离开来。同时，为系统中的N个数据库服务器分配不同类别的用户，使得N个数据库服务器中任意两个数据库服务器分别用于更新M类用户中两类不同的用户的数据。并且，在业务请求中携带发起业务请求的用户的标识，这样一来，在业务系统获取到业务请求后，即可根据业务请求所携带的用户标识从N个数据库服务器中确定唯一对应的一个数据库服务器，从而交由该数据库服务器处理该业务请求。由于N个数据库服务器中任意两个数据库服务器分别用于更新M类用户中两类不同的用户的数据，而M类用户的数据分别存储在不同的物理数据块上，因此不会出现多个数据库服务器更新同一物理数据块中的数据的情形，即多个数据库服务器之间不会出现“写冲突”。
综上，本发明实施例提供的支持数据库扩容的业务处理系统能够避免多个数据库服务器之间的“写冲突”，使得多数据库服务器能够并行运算，进而提升系统的数据处理性能。另外，当用户数量增加，使得系统处理性能出现瓶颈时，本发明实施例提供的支持数据库扩容的业务处理系统，可通过增加数据库服务器的数量提升数据处理性能，从而实现数据库的平滑扩容。
如图5所示，本发明实施例提供一种业务处理方法，应用于如图3所示的业务处理系统20，方法包括：
S501、门户应用服务器获取用户通过接入界面发起的业务请求。
其中，所述业务请求携带有所述用户的标识。
S502、门户应用服务器向业务处理服务器发送业务请求。
S503、业务处理服务器接收业务请求。
S504、业务处理服务器根据用户的标识，确定用户所属的用户类别，结合预存的用户类别与数据库服务器的路由关系，确定对应的数据库服务器，以及，根据用户的标识，结合预存的用户与物理数据块间的对应关系，确定存储用户的数据的物理数据块。
S505、业务处理服务器向数据库服务器转发业务请求及物理数据块的标识。
S506、数据库服务器接收业务请求及物理数据块的标识，根据业务请求对物理数据块中存储的用户的数据进行写操作。
优选的，本发明实施例提供的业务处理方法中，业务请求还携带有所请求业务的类型。
则，如图6所示，在门户应用服务器获取用户通过接入界面发起的业务请求(即S501)之后，所述方法还可以包括：
S507、门户应用服务器根据业务请求携带的用户的标识及所请求业务的类型，在业务处理服务器提供的服务接口中确定对应的服务接口。
则，门户应用服务器向业务处理服务器发送业务请求(即S502)，具体可以包括：
S502’、门户应用服务器调用服务接口向业务处理服务器发送业务请求。
进一步的，如图7所示，本发明实施例提供的业务处理方法，在业务处理服务器接收业务请求(即S503)之后，还可以包括：
S508、业务处理服务器根据门户应用服务器所调用的服务接口，确定是否需要进行数据库访问。
则，步骤S504中，业务处理服务器根据用户的标识，确定用户所属的用户类别，结合预存的用户类别与数据库服务器的路由关系，确定对应的数据库服务器，具体可以包括：
若业务处理服务器确定需要进行数据库访问，业务处理服务器根据用户的标识，确定用户所属的用户类别，结合预存的用户类别与数据库服务器的路由关系，确定对应的数据库服务器。
更进一步的，业务处理服务器根据用户的标识，确定用户所属的用户类别，结合预存的用户类别与数据库服务器的路由关系，确定对应的数据库服务器，具体可以包括：
业务处理服务器根据门户应用服务器所调用的服务接口，确定是否需要对普通用户的业务数据进行处理；
若是，业务处理服务器确定所述用户所属的用户类别，并结合预存的用户类别与数据库服务器的路由关系，从n个第二数据库服务器中确定对应的数据库服务器；
若否，业务处理服务器根据业务请求携带的所请求业务的类型，确定所请求业务是否属于查询类业务请求；
若确定所请求业务属于查询类业务请求，业务处理服务器根据负载均衡原则，在至少1个第三数据库服务器中确定对应的数据库服务器；
若确定所请求业务不属于查询类业务请求，业务处理服务器将第一数据库服务器确定为对应的数据库服务器。
本发明实施例提供的业务处理方法应用于本发明实施例所述的业务处理系统，本发明实施例所述的业务处理系统通过将用户组划分为M类用户，并将M类用户的数据分别存储在存储设备的不同的物理数据块中，以将M类用户的数据在存储上隔离开来。同时，为系统中的N个数据库服务器分配不同类别的用户，使得N个数据库服务器中任意两个数据库服务器分别用于更新M类用户中两类不同的用户的数据。并且，在业务请求中携带发起业务请求的用户的标识，这样一来，在使用本发明实施例提供的业务处理方法进行业务处理时，业务处理服务器在获取到业务请求后，即可根据业务请求所携带的用户标识从N个数据库服务器中确定唯一对应的一个数据库服务器，从而交由该数据库服务器处理该业务请求。由于N个数据库服务器中任意两个数据库服务器分别用于更新M类用户中两类不同的用户的数据，而M类用户的数据分别存储在不同的物理数据块上，因此不会出现多个数据库服务器更新同一物理数据块中的数据的情形，即多个数据库服务器之间不会出现“写冲突”。
综上，本发明实施例提供的业务处理方法能够避免多个数据库服务器之间的“写冲突”，使得多数据库服务器能够并行运算，进而提升系统的数据处理性能。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。
Claims (10)
1.一种支持数据库扩容的业务处理系统，其特征在于，所述业务处理系统包括：门户应用服务器、业务处理服务器、N个数据库服务器、存储设备；其中，所述存储设备存储有M类用户的数据，所述M类用户中每类用户的数据存储在至少1个物理数据块中，且所述M类用户的数据分别存储在不同的物理数据块中；所述N个数据库服务器中任意两个数据库服务器分别用于更新所述M类用户中两类不同用户的数据，N、M为整数，N≥1，M≥1；
所述门户应用服务器，用于获取用户通过接入界面发起的业务请求，并向所述业务处理服务器发送所述业务请求，所述业务请求携带有所述用户的标识；
所述业务处理服务器，用于：
接收所述业务请求，并根据所述用户的标识，确定所述用户所属的用户类别，结合预存的用户类别与数据库服务器的路由关系，确定对应的数据库服务器；
根据所述用户的标识，结合预存的用户与物理数据块间的对应关系，确定存储所述用户的数据的物理数据块；
向所述数据库服务器转发所述业务请求及所述物理数据块的标识，以使所述数据库服务器根据所述业务请求对所述物理数据块中存储的所述用户的数据进行写操作。
2.根据权利要求1所述的业务处理系统，其特征在于，所述M类用户包括管理员用户及n类普通用户，所述M类用户的数据包括公共数据及所述n类普通用户的业务数据，所述N个数据库服务器包括1个第一数据库服务器、n个第二数据库服务器及至少1个第三数据库服务器，所述第一数据库服务器用于更新所述公共数据，所述n个第二数据库服务器分别用于更新及查询所述n类用户的业务数据，所述第三数据库服务器用于查询所述公共数据，n为整数，n＝M-1。
3.根据权利要求2所述的业务处理系统，其特征在于，所述业务请求还携带有所请求业务的类型；
所述门户应用服务器，还用于在获取用户通过接入界面发起的业务请求之后，根据所述业务请求携带的所述用户的标识及所请求业务的类型，在所述业务处理服务器提供的服务接口中确定对应的服务接口；
所述门户应用服务器，具体用于调用所述服务接口向所述业务处理服务器发送所述业务请求。
4.根据权利要求3所述的业务处理系统，其特征在于，
所述业务处理服务器，还用于在接收所述业务请求之后，根据所述门户应用服务器所调用的服务接口，确定是否需要进行数据库访问；
所述业务处理服务器，具体用于若确定需要进行数据库访问，根据所述用户的标识，确定所述用户所属的用户类别，结合预存的用户类别与数据库服务器的路由关系，确定对应的数据库服务器。
5.根据权利要求4所述的业务处理系统，其特征在于，
所述业务处理服务器，具体用于根据所述门户应用服务器所调用的服务接口，确定是否需要对普通用户的业务数据进行处理；
若是，根据所述用户的标识，确定所述用户所属的用户类别，并结合预存的用户类别与数据库服务器的路由关系，从所述n个第二数据库服务器中确定对应的数据库服务器；
若否，根据所述业务请求携带的所请求业务的类型，确定所请求业务是否属于查询类业务请求；
若确定所请求业务属于查询类业务请求，根据负载均衡原则，在所述至少1个第三数据库服务器中确定对应的数据库服务器；
若确定所请求业务不属于查询类业务请求，将所述第一数据库服务器确定为对应的数据库服务器。
6.根据权利要求1所述的业务处理系统，其特征在于，所述M类用户包括管理员用户及n类普通用户，所述M类用户的数据包括公共数据及所述n类普通用户的业务数据，所述N个数据库服务器包括1个第四数据库服务器及n个第五数据库服务器，所述第四数据库服务器用于更新及查询公共数据，所述n个第五数据库服务器分别用于更新及查询所述n类普通用户的业务数据，n为整数，n＝M-1。
7.一种业务处理方法，其特征在于，所述方法应用于如权利要求1-5任一项所述的业务处理系统，所述方法包括：
门户应用服务器获取用户通过接入界面发起的业务请求，并向业务处理服务器发送所述业务请求，所述业务请求携带有所述用户的标识；
所述业务处理服务器接收所述业务请求，并根据所述用户的标识，确定所述用户所属的用户类别，结合预存的用户类别与数据库服务器的路由关系，确定对应的数据库服务器；
所述业务处理服务器根据所述用户的标识，结合预存的用户与物理数据块间的对应关系，确定存储所述用户的数据的物理数据块；
所述业务处理服务器向所述数据库服务器转发所述业务请求及所述物理数据块的标识，以使所述数据库服务器根据所述业务请求对所述物理数据块中存储的所述用户的数据进行写操作。
8.根据权利要求7所述的方法，其特征在于，所述业务请求还携带有所请求业务的类型，在所述门户应用服务器获取用户通过接入界面发起的业务请求之后，所述方法还包括：
所述门户应用服务器根据所述业务请求携带的所述用户的标识及所请求业务的类型，在所述业务处理服务器提供的服务接口中确定对应的服务接口；
所述门户应用服务器向业务处理服务器发送所述业务请求，包括：
所述门户应用服务器调用所述服务接口向所述业务处理服务器发送所述业务请求。
9.根据权利要求8所述的方法，其特征在于，在所述业务处理服务器接收所述业务请求之后，所述方法还包括：
根据所述门户应用服务器所调用的服务接口，确定是否需要进行数据库访问；
所述业务处理服务器根据所述用户的标识，确定所述用户所属的用户类别，结合预存的用户类别与数据库服务器的路由关系，确定对应的数据库服务器，包括：
若所述业务处理服务器确定需要进行数据库访问，所述业务处理服务器根据所述用户的标识，确定所述用户所属的用户类别，结合预存的用户类别与数据库服务器的路由关系，确定对应的数据库服务器。
10.根据权利要求9所述的方法，其特征在于，所述业务处理服务器根据所述用户的标识，确定所述用户所属的用户类别，结合预存的用户类别与数据库服务器的路由关系，确定对应的数据库服务器，包括：
所述业务处理服务器根据所述门户应用服务器所调用的服务接口，确定是否需要对普通用户的业务数据进行处理；
若是，所述业务处理服务器确定所述用户所属的用户类别，并结合预存的用户类别与数据库服务器的路由关系，从n个第二数据库服务器中确定对应的数据库服务器；
若否，所述业务处理服务器根据所述业务请求携带的所请求业务的类型，确定所请求业务是否属于查询类业务请求；
若确定所请求业务属于查询类业务请求，所述业务处理服务器根据负载均衡原则，在至少1个第三数据库服务器中确定对应的数据库服务器；
若确定所请求业务不属于查询类业务请求，所述业务处理服务器将第一数据库服务器确定为对应的数据库服务器。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510466061.1A CN105045897B (zh) | 2015-07-31 | 2015-07-31 | 支持数据库扩容的业务处理系统及方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510466061.1A CN105045897B (zh) | 2015-07-31 | 2015-07-31 | 支持数据库扩容的业务处理系统及方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN105045897A CN105045897A (zh) | 2015-11-11 |
| CN105045897B true CN105045897B (zh) | 2019-01-25 |
Family
ID=54452444
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201510466061.1A Active CN105045897B (zh) | 2015-07-31 | 2015-07-31 | 支持数据库扩容的业务处理系统及方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN105045897B (zh) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106446268A (zh) * | 2016-10-19 | 2017-02-22 | 中国工商银行股份有限公司 | 一种数据库横向扩展系统及方法 |
| CN106777031A (zh) * | 2016-12-08 | 2017-05-31 | 腾讯音乐娱乐（深圳）有限公司 | 一种数据库扩容方法及装置 |
| CN106649751A (zh) * | 2016-12-26 | 2017-05-10 | 中国建设银行股份有限公司 | 一种现金管理服务数据的存储系统、方法及装置 |
| CN106775486A (zh) * | 2016-12-26 | 2017-05-31 | 中国建设银行股份有限公司 | 数据访问系统、方法及路由服务器、配置中心服务器 |
| CN107066591A (zh) * | 2017-04-18 | 2017-08-18 | 北京思特奇信息技术股份有限公司 | 一种对业务进行处理的方法及装置 |
| CN109213743B (zh) * | 2017-06-30 | 2021-10-15 | 北京京东尚科信息技术有限公司 | 一种数据查询方法和装置 |
| WO2021051569A1 (zh) * | 2019-09-18 | 2021-03-25 | 平安科技（深圳）有限公司 | 一种数据隔离方法、装置、计算机设备及存储介质 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103812915A (zh) * | 2012-11-15 | 2014-05-21 | 中兴通讯股份有限公司 | 资源共享方法、装置、系统及终端、资源管理中心 |
| CN104714837A (zh) * | 2013-12-11 | 2015-06-17 | 北京慧正通软科技有限公司 | 工作流引擎集群环境下实例并发处理的一种技术方法 |
-
2015
- 2015-07-31 CN CN201510466061.1A patent/CN105045897B/zh active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103812915A (zh) * | 2012-11-15 | 2014-05-21 | 中兴通讯股份有限公司 | 资源共享方法、装置、系统及终端、资源管理中心 |
| CN104714837A (zh) * | 2013-12-11 | 2015-06-17 | 北京慧正通软科技有限公司 | 工作流引擎集群环境下实例并发处理的一种技术方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN105045897A (zh) | 2015-11-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN105045897B (zh) | 支持数据库扩容的业务处理系统及方法 | |
| JP5092374B2 (ja) | データセンタ及びデータ転送方法 | |
| CN103390041B (zh) | 一种基于中间件提供数据服务的方法和系统 | |
| CN106599711A (zh) | 一种数据库访问控制方法，及装置 | |
| CN103064960B (zh) | 数据库查询方法及设备 | |
| JP4088549B2 (ja) | 電気通信網における方法 | |
| CN110278284A (zh) | 一种服务调用方法及装置 | |
| CN106790324A (zh) | 内容分发方法、虚拟服务器管理方法、云平台和系统 | |
| CN105095313B (zh) | 一种数据访问方法和设备 | |
| CN109408751A (zh) | 一种数据处理方法、终端、服务器及存储介质 | |
| CN105187503B (zh) | 一种支持数据分区的服务连接方法及系统 | |
| CN109005433B (zh) | 一种视频云服务平台架构及实现方法 | |
| CN101673272B (zh) | 搜索信息的方法、系统、装置及垂直搜索引擎注册的方法 | |
| CN112579319B (zh) | 一种基于LRU Cache优化的服务调用方法及装置 | |
| CA1252903A (en) | Dynamic update of database directories using directed or undirected mechanisms | |
| CN109639598A (zh) | 基于微服务的请求处理方法、服务器、存储介质及装置 | |
| CN112866421A (zh) | 基于分布式缓存以及nsq的智能合约运行方法及装置 | |
| CN106708636A (zh) | 基于集群的数据缓存方法及装置 | |
| CN105978744B (zh) | 一种资源分配方法、装置及系统 | |
| CN110401731A (zh) | 用于分配内容分发节点的方法和装置 | |
| EP2348676B1 (en) | Method for accessing magnanimity data of intelligent network service database and system and device thereof | |
| WO2020259191A1 (zh) | 一种数据中心节点分配方法、装置、系统及计算机设备 | |
| CN102833295B (zh) | 分布式缓存系统中的数据操作方法和装置 | |
| CN110995890B (zh) | 域名请求的调度方法及装置 | |
| CN108536854A (zh) | 数据交互的方法、装置及计算机可读存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20200217 Address after: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen Patentee after: HUAWEI TECHNOLOGIES Co.,Ltd. Address before: 210012 HUAWEI Nanjing base, 101 software Avenue, Yuhuatai District, Jiangsu, Nanjing Patentee before: Huawei Technologies Co.,Ltd. |