Multi-tenant data source management method, system and equipment

Abstract

The invention discloses a multi-tenant data source management method, system and device. The method comprises the steps of obtaining a service request of a target tenant, and determining an operation request and a tenant identifier of the target tenant based on the service request; and when the operation request is a write operation or a core operation, determining a target database as a main database based on the tenant identifier. And when the operation request is a read operation or a non-core operation, determining that the target database is one of the plurality of slave databases based on the tenant identifier. And establishing connection with the target database based on the connection interface of the target database. And performing an operation corresponding to the operation request on the target database. According to the method, data operations such as query and reading are performed by using the slave database, the data processing pressure of the master database is shared, the overhigh load of a single database is avoided, the performance loss is reduced, the core business processing speed is increased, and the system reliability is improved.

Description

Technical Field

[0001] This invention relates to the field of cloud computing, and in particular to a multi-tenant data source management method, system, and device. Background Technology

[0002] With the widespread adoption of cloud computing models such as Software as a Service (SaaS) and Platform as a Service (PaaS), multi-tenant architecture has become a crucial technology supporting rapid business growth. Current technologies often employ a single processing strategy for read and write operations on multi-tenant databases, leading to excessive database load, especially in scenarios with frequent write operations. This can easily become a system bottleneck, impacting overall performance. Processing delays or instability in core business data reduce system reliability. Therefore, improving system performance and reliability has become a pressing issue in the field of data source management under multi-tenant architectures. Summary of the Invention

[0003] To address the aforementioned issues, embodiments of the present invention provide a multi-tenant data source management method, system, and device that can intelligently select the primary or secondary database of a tenant based on different operation request types, thereby improving the overall performance and reliability of the system.

[0004] According to a first aspect of the present invention, a multi-tenant data source management method is provided, the method comprising: Obtain the business request of the target tenant, and determine the operation request and tenant identifier of the target tenant based on the business request; When the operation request is a write operation or a core operation, the target database of the target tenant is determined to be the primary database based on the tenant identifier; wherein, the target tenant is configured with the primary database and multiple secondary databases; If the operation request is a read operation or a non-core operation, the target database of the target tenant is determined to be one of the multiple slave databases based on the tenant identifier; Establish a connection with the target database based on the target database's connection interface; Perform the operation corresponding to the operation request on the target database.

[0005] In an alternative approach, determining the target database as one of the multiple slave databases based on the tenant identifier when the operation request is a read operation or a non-core operation includes: The set of online connection counts is obtained based on the tenant identifier, wherein the set of online connection counts is the online connection count of each slave database of the target tenant; Based on the set of online connections and a preset threshold, a target database is determined from multiple slave databases, wherein the preset threshold is the maximum number of online connections allowed for each slave database.

[0006] In one alternative approach, obtaining the set of online connections based on the tenant identifier includes: Based on the tenant identifier, the address information of each slave database of the target tenant is obtained from the central configuration database. The central configuration database stores the basic configuration information of all tenants. The basic configuration information of each tenant includes the tenant identifier, the master database address information and multiple slave database address information. Based on the address information of each slave database, the number of online connections for each slave database corresponding to the target tenant is obtained, and the set of online connection counts is obtained.

[0007] In one alternative approach, the set of online connections includes multiple connection counts, and determining the target database from multiple databases based on the set of online connection counts and a preset threshold includes: Select one connection number from the set of online connections as a candidate connection number, and determine whether the candidate connection number is less than a preset threshold. If the number of candidate connections is less than the preset threshold, then the availability status of the slave database corresponding to the number of candidate connections is obtained; If the availability status of the slave database corresponding to the candidate connection number is available, then the slave database corresponding to the candidate connection number is determined to be the target database; If the availability status of the slave database corresponding to the candidate connection number is unavailable, and there are no unselected connections in the online connection number set, then the master database is determined as the target database or the operation is output as failed. If the availability status of the slave database corresponding to the candidate connection number is unavailable, and there are unselected connections in the online connection number set, then return to the step of selecting a connection from the online connection number set as a candidate connection number, and determine whether the candidate connection number is less than a preset threshold.

[0008] In one alternative approach, after selecting a connection number from the set of online connections as a candidate connection number and determining whether the candidate connection number is less than a preset threshold, the method further includes: If the number of candidate connections is greater than or equal to the preset threshold, and there are unselected connections in the set of online connections, then return to the step of selecting a connection from the set of online connections as a candidate connection, and determine whether the number of candidate connections is less than the preset threshold. If the number of candidate connections is greater than or equal to the preset threshold, and there are no unselected connections in the set of online connections, then the main database is determined as the target database or the operation is output as failed.

[0009] In an alternative approach, after performing the operation corresponding to the operation request on the target database, the method further includes: Identify the associated databases related to the target database; Perform the operation corresponding to the operation request on the associated database, wherein the associated database is a database in the target tenant's database other than the target database.

[0010] In one alternative approach, performing the operation corresponding to the operation request on the associated database includes: When a first operation is performed on the target database, a second operation is performed on the associated database, wherein the first operation is a data creation operation and the second operation is a data update operation.

[0011] In one alternative approach, establishing a connection to the target database based on the target database's connection interface includes: Obtain the connection interface of the target database from the data access component; A connection to the target database is established based on the connection interface.

[0012] According to a second aspect of the present invention, a multi-tenant data source management system is provided, the system comprising: The application service layer is used to obtain the business requests of the target tenant and determine the operation requests and tenant identifiers of the target tenant based on the business requests. The data management and access layer is used to determine the target database as the primary database based on the tenant identifier when the operation request is a write operation or a core operation; wherein the target tenant is configured with the primary database and multiple slave databases; If the operation request is a read operation or a non-core operation, the target database is determined to be one of the multiple slave databases based on the tenant identifier; The data management and access layer is also used to establish a connection with the target database based on the connection interface of the target database; The application service layer is also used to perform the operation corresponding to the operation request on the target database.

[0013] According to a third aspect of the present invention, an electronic device is provided, the device including a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the multi-tenant data source management method as described above.

[0014] The beneficial effects of this invention are as follows: This application parses the tenant identifier from the business requests of the target tenant. When the operation request is a write operation or a core operation, the primary database of the target tenant is determined as the target database based on the tenant identifier. When the operation request is a read operation or a non-core operation, one of the multiple secondary databases of the target tenant is dynamically selected as the target database based on the tenant identifier. By utilizing the secondary database for data operations such as querying and reading, the data processing pressure of the primary database is distributed, avoiding excessive load on a single database, reducing performance loss, and improving the processing speed of core business operations, thereby enhancing system reliability. Furthermore, this application separates the data source switching logic from the specific data operation logic through a data access component, achieving modularization and standardization of the data access logic, greatly simplifying the data access process. Integrating distributed transaction management ensures effective data consistency in complex operations involving multiple independent databases, improving system reliability and consistency. Attached Figure Description

[0015] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a schematic diagram of an implementation environment provided by an embodiment of the present invention; Figure 2 This is a flowchart illustrating a multi-tenant data source management method provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a multi-tenant data source management system provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of a multi-tenant data source management device provided in an embodiment of the present invention. Detailed Implementation

[0016] To enable those skilled in the art to better understand the technical solutions of this application, the application will be described in detail below with reference to the accompanying drawings and specific embodiments. Although the accompanying drawings and specific embodiments describe exemplary embodiments of the present invention, it should be understood that the present invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0017] The terms "first," "second," and similar words used in this application do not indicate any order, quantity, or importance, but are merely used for distinction. The terms "including," "comprising," and similar words used in this application mean that the element preceding the word encompasses the elements listed after the word, and do not exclude the possibility of encompassing other elements as well. The technical solutions of this application are not limited to the execution order described in the embodiments. The steps in the execution order can be combined, broken down, or their order can be changed, as long as the logical relationship of the execution content is not affected.

[0018] All terms used in this application (including technical or scientific terms) have the same meaning as understood by one of ordinary skill in the art to which this application pertains, unless otherwise specifically defined. It should also be understood that terms defined in general dictionaries should be interpreted as having meanings consistent with their meanings in the context of the relevant art, and not as idealized or highly formalized, unless expressly defined herein. Technologies and equipment known to one of ordinary skill in the art may not be discussed in detail, but where appropriate, such technologies and equipment should be considered part of the specification.

[0019] First, the relevant terms involved in the application embodiments will be explained.

[0020] Cloud technology is a technological model that centrally manages and allocates computing, storage, and network resources on demand via the internet. Users do not need to build and maintain their own hardware infrastructure; they can directly access resources such as servers, databases, and software and pay only for what they use. Cloud technology encompasses various service types, including Software as a Service (SaaS) and Platform as a Service (PaaS), collectively known as cloud services. Cloud services are widely used in areas such as enterprise digital transformation, big data processing, artificial intelligence, and the Internet of Things.

[0021] Multi-tenant architecture is the core design logic of cloud services (especially SaaS model), which aims to allow multiple user groups (tenants) to share the same software system or infrastructure, while ensuring that the data and configurations of each tenant are isolated from each other and do not interfere with each other.

[0022] A database is an electronic system used for structured storage, management, and organization of data. It stores data in an ordered manner according to a specific data model (such as relational model, document model, etc.), supporting efficient query, insertion, update, and deletion operations. By establishing relationships between data, a database ensures data integrity, consistency, and security, while providing multi-user access control and transaction processing mechanisms to avoid data conflicts and loss.

[0023] With the widespread adoption of cloud computing models such as Software as a Service (SaaS) and Platform as a Service (PaaS), multi-tenant architecture has become a crucial technology supporting rapid business growth. Current technologies often employ a single processing strategy for read and write operations on multi-tenant databases, leading to excessive database load, especially in scenarios with frequent write operations. This can easily become a system bottleneck, impacting overall performance. Delays or instability in processing critical business data reduce system reliability. Therefore, improving system performance and reliability has become a pressing issue in the field of data source management under multi-tenant architectures.

[0024] To address the aforementioned issues, embodiments of the present invention provide a multi-tenant data source management method and system that can select the primary or secondary database of a tenant based on different operation request types, thereby improving the overall performance and reliability of the system.

[0025] Please see Figure 1 The diagram shown is an implementation environment provided by an embodiment of the present invention, which may include a client, a server, and a database.

[0026] The client and server, as well as the server and database, can communicate via a network.

[0027] The client devices include, but are not limited to, mobile phones, computers, smart voice interaction devices, smart home appliances, in-vehicle clients, and aircraft. Each client runs an application with human-computer interaction capabilities. This application is used to send business requests to the target tenant.

[0028] The server can obtain the business requests of the target tenant and determine the operation requests and tenant identifiers of the target tenant based on the business requests. If the operation request is a write operation or a core operation, the target database is determined to be the primary database based on the tenant identifier. The target tenant is configured with the primary database and multiple secondary databases. If the operation request is a read operation or a non-core operation, the target database is determined to be one of the multiple secondary databases based on the tenant identifier. A connection is established with the target database using its connection interface. The operation corresponding to the operation request is performed on the target database. This embodiment of the application can achieve read-write separation through primary-secondary database configuration and dynamic switching of primary and secondary databases according to different business requests, greatly alleviating the pressure on the primary database and effectively improving overall operating efficiency and system stability.

[0029] It should be noted that the server in this application embodiment can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0030] The database can include a database that stores data for all tenants. The database can be stored on a separate server or multiple storage devices.

[0031] In one exemplary implementation, the client, server, and database can all be node devices in the blockchain system, capable of sharing acquired and generated data with other node devices in the blockchain system, thus enabling data sharing among multiple node devices. Multiple node devices in the blockchain system can be configured with the same blockchain, which consists of multiple blocks, and adjacent blocks are related, ensuring that any tampering with data in any block can be detected by the next block. This prevents data tampering in the blockchain and guarantees the security and reliability of the data in the blockchain.

[0032] Please see Figure 2 The diagram shown is a flowchart of a multi-tenant data source management method provided by an embodiment of the present invention. This method can be applied to... Figure 1 The implementation environment shown can be the subject executing this method. Figure 1 The server or server cluster performing multi-tenant data source processing can also be located on the client or other server nodes performing multi-tenant data source processing. It should be noted that this specification provides the operational steps of the methods described in the embodiments or flowcharts, but based on conventional or non-inventive labor, more or fewer operational steps may be included. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only execution order. In actual system or product execution, the methods can be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment) as shown in the embodiments or accompanying drawings. Specifically, as... Figure 2 As shown, the method may include the following steps S110-S150.

[0033] S110: Obtain the business request of the target tenant, and determine the operation request and tenant identifier of the target tenant based on the business request.

[0034] In this embodiment, the target tenant can use the application in the aforementioned client to log in with their tenant account and password and send business requests.

[0035] In some implementations, a service request may include the target tenant's tenant account and operation request.

[0036] For example, the server can parse the business request to obtain the target tenant's tenant account and operation request, and then obtain the corresponding tenant identifier based on the tenant account. It should be noted that the tenant identifier can be the tenant's ID, and each tenant corresponds to a unique tenant identifier. Furthermore, the tenant identifier is globally unique to prevent errors caused by tenant identifier conflicts.

[0037] In some implementations, a tenant identifier can correspond to a single tenant account, or it can correspond to a primary tenant account and multiple sub-tenant accounts. For example, when an individual uses the service, a tenant identifier can correspond to the tenant's own account; when an enterprise uses the service, a tenant identifier can correspond to a primary administrator account and multiple sub-accounts of enterprise employees, and so on.

[0038] In some implementations, the target tenant's operation request can be a read operation request, a write operation request, a core operation request, or a non-core operation request.

[0039] In some implementations, a service request may include the target tenant's tenant identifier and operation request.

[0040] For example, the server can parse business requests to obtain the tenant identifier and operation request of the target tenant.

[0041] S120: If the operation request is a write operation or a core operation, determine the target database of the target tenant as the primary database based on the tenant identifier; wherein the target tenant is configured with the primary database and multiple secondary databases.

[0042] In some implementations, when a new tenant completes registration, a corresponding tenant identifier is generated, a primary database and a secondary database are configured for the new tenant, and the correspondence between the tenant identifier and the tenant's primary and secondary databases is recorded. When a client sends a service request, the server can quickly and accurately determine the primary and secondary databases of the tenant corresponding to the tenant identifier using the tenant identifier.

[0043] It should be noted that when a new tenant completes registration, a master database can be configured for the new tenant without configuring a slave database. This implementation method is not specifically limited here.

[0044] In the database field, master and slave databases are logical relationships based on a master-slave backup structure. They are primarily used to achieve read / write separation, high availability, load balancing, and disaster recovery. The master database is responsible for write operations (such as adding, deleting, and modifying data); all write operations are performed on the master database. The slave database replicates data from the master database to maintain data consistency and is used for read operations.

[0045] The master database and the slave database can reside in the same physical memory at the same time, or they can reside in different physical memories. This embodiment does not make any specific limitations here.

[0046] In some embodiments, core operations can be critical operations that play a decisive role in business functionality, data consistency, and system stability. For example, core operations can be operations performed on basic configuration information such as tenant account passwords, or operations performed on core business data of the tenant.

[0047] In this embodiment, the target tenant is configured with a single primary database. In other embodiments, the target tenant may be configured with multiple primary databases.

[0048] In some embodiments, the tenant's master and slave databases may reside in the server's data storage area or in the data storage area of ​​a dedicated storage device. The data storage area may include independent physical storage areas, logically isolated storage areas, and shared data storage areas. The functions of each storage area are as follows: An independent physical storage area is a physical database allocated to a specific tenant.

[0049] Logically isolated storage is a shared physical database that creates logically independent databases for different tenants.

[0050] A shared data storage area is where multiple tenants' data are stored in the same table within the same group of tables, and the data is distinguished by a tenant identifier field.

[0051] It should be noted that the security of independent physical storage areas is greater than that of logically isolated storage areas, and the security of logically isolated storage areas is greater than that of shared data storage areas.

[0052] In some embodiments, to avoid confusion across multiple databases or storage areas, it is stipulated that table names, like tenant identifiers, must be globally unique across all data sources in a multi-tenant platform, and standardized naming rules are preset. For example, if a table named Shared_company exists in a shared data storage area, then no other table named Shared_company is allowed to be created in any tenant database or other type of database. This guideline simplifies developers' understanding of data structures and reduces the risk of errors caused by table name conflicts.

[0053] In some embodiments, this application can be classified according to the tenant package type into a first type of tenant, a second type of tenant, and a third type of tenant.

[0054] If the target tenant is a Category 1 tenant, at least one of the target tenant's databases must be located in a separate physical storage area. A separate physical storage area is allocated to a dedicated database server for tenants with extremely high requirements for data isolation, performance, or compliance (such as large enterprise customers).

[0055] When the target tenant is a Type 2 tenant, at least one of the target tenant's databases must be located in a logically isolated storage area, and none of its databases must be located in a separate physical storage area. A logically isolated storage area creates independent logical databases for different tenants within the same physical database instance through logical partitioning. This is suitable for medium to large-sized customers, offering a certain level of isolation at a lower cost than independent physical databases.

[0056] When the target tenant is a third-class tenant, all databases of the target tenant reside in a shared data storage area. The shared data storage area stores data from multiple tenants in shared databases and tables, distinguishing data from different tenants by adding a tenant identifier field to each business table. This model offers the lowest cost, high resource utilization, and is suitable for small to medium-sized customers with low isolation requirements.

[0057] By providing various tenant storage areas such as independent physical, logical isolation, and shared data, tenants can flexibly choose according to their size, security needs, and cost budget, achieving the best balance between isolation and cost.

[0058] S130: If the operation request is a read operation or a non-core operation, the target database of the target tenant is determined to be one of the multiple slave databases based on the tenant identifier.

[0059] It should be noted that in this embodiment, the slave database is configured as a read-only model, and the database cannot be modified. This configuration can offload a large number of read requests to the slave database, relieving the pressure on the master database. Simultaneously, the slave database, acting as a data replica, can provide read-only service in the event of a master database failure, enhancing system disaster recovery capabilities and reducing the risk of data loss.

[0060] In some embodiments, non-core operations can be operations with relatively low requirements for real-time performance and consistency, or operations that have a significant impact on the performance of the main database. For example, non-core operations can be operations performed by a tenant to generate reports from its own data, or operations such as querying non-core business data.

[0061] In this embodiment, the target tenant is configured with multiple slave databases. In some other embodiments, the target tenant may be configured with only one slave database.

[0062] S140: Establish a connection with the target database based on the connection interface of the target database.

[0063] It should be noted that the connection interface in this embodiment can come from a connection pool. Each database can be configured with a corresponding connection pool.

[0064] A connection pool is a cache pool of database connections that improves the performance and resource utilization of the database connection interface by reusing connections, avoiding the overhead of frequently creating and destroying connections.

[0065] For example, the target database's connection pool includes a preset number of idle and online connection interfaces. Idle connection interfaces are those obtained by pre-initializing the target database's connection interfaces, while online connection interfaces are those established after the idle connection interfaces have connected to the target database. When an operation request needs to access the target database, the server can directly obtain an idle connection interface from the target database's connection pool. After use, the server returns the idle connection interface to the pool, making it a new idle connection interface, rather than directly closing the connection interface, allowing it to be reused by subsequent business requests.

[0066] This embodiment avoids the latency and waste of computing resources caused by configuring a connection pool for the target database, which requires a connection creation process (including TCP three-way handshake to establish a network connection, database authentication, permission verification, and initialization of the session environment) for each operation on the target database, thus greatly improving the connection efficiency of the target database.

[0067] In some implementations, a timeout setting can be set for the online connection interfaces in the connection pool. After the online connection interface has been in a connected state for a certain preset time, the server will automatically disconnect the online connection interface and return it to the connection pool to become a new idle connection interface.

[0068] S150: Perform the operation corresponding to the operation request on the target database.

[0069] For example, when the target database is the primary database of the target tenant and the operation request is a write operation, the server performs a write operation on the primary database according to the write operation of the target tenant.

[0070] When the target database is the primary database of the target tenant, and the operation request is a core operation, the server performs core modification operations on the primary database based on the core operation of the target tenant.

[0071] It should be noted that the master database updates data in real time and synchronizes the data in the master database to all slave databases of the target tenant in real time based on the master-slave backup relationship, so as to maintain data consistency between the master database and the slave databases.

[0072] For example, when the target database is a slave database of the target tenant and the operation request is a read operation, the server performs a read operation on the slave database according to the read operation of the target tenant.

[0073] When the target database is a slave database of the target tenant, and the operation request is a non-core operation, the server generates reports for the slave database based on the non-core operation of the target tenant.

[0074] In some implementations, after completing the operation corresponding to the operation request, the server can also dynamically clear the tenant identifier and interaction relationship with the target database stored in the above method to avoid affecting subsequent business requests. This dynamic clearing mechanism allows the same code to serve different tenants; simply switching the interaction relationship between different tenant identifiers and different databases is sufficient when the above method is running.

[0075] This application embodiment parses the tenant identifier from the target tenant's business requests. When the operation request is a write operation or a core operation, the primary database of the target tenant is determined as the target database based on the tenant identifier. When the operation request is a read operation or a non-core operation, one of the target tenant's multiple secondary databases is dynamically selected as the target database based on the tenant identifier. By utilizing the secondary database for data operations such as querying and reading, the data processing pressure of the primary database is distributed, avoiding excessive load on a single database while improving overall performance and ensuring the timeliness and stability of core business data processing.

[0076] In some embodiments, determining the target database as one of the multiple slave databases based on the tenant identifier when the operation request is a read operation or a non-core operation includes: The set of online connection counts is obtained based on the tenant identifier, wherein the set of online connection counts is the online connection count of each slave database of the target tenant.

[0077] Based on the set of online connections and a preset threshold, a target database is determined from multiple slave databases, wherein the preset threshold is the maximum number of online connections allowed for each slave database.

[0078] It should be noted that, in this embodiment, since there are real-time business requests accessing the database, each slave database's connection pool will have idle connection interfaces with no connected business requests and online connection interfaces with connected business requests. This embodiment compares the number of online connections for each slave database with a preset threshold to determine the target database, avoiding excessive load on the target database, which could lead to slow data processing and wasted resources due to excessive idle resources in other slave databases, thus ensuring reasonable resource allocation.

[0079] In some implementations, the method described in this embodiment also applies to situations where a tenant has multiple master databases. The specific implementation is similar to that for slave databases, and will not be repeated here.

[0080] In some embodiments, obtaining the set of online connections based on the tenant identifier includes: Based on the tenant identifier, the address information of each slave database of the target tenant is obtained from the central configuration database. The central configuration database stores the basic configuration information of all tenants, and the basic configuration information of each tenant includes the tenant identifier, the master database address information and multiple slave database address information.

[0081] In some implementations, the central configuration repository can be a highly available relational database or a NoSQL database. By storing tenants' basic configuration information uniformly in a central configuration repository for centralized management and configuration, the standardization and flexibility of configuration management are effectively improved.

[0082] It should be noted that the basic configuration information of a tenant may also include the tenant's metadata (such as the tenant's name or company name, creation date, service expiration date, service level or package type, etc.), global configuration parameters (such as the maximum number of online connections allowed in the connection pool, the minimum number of idle connections allowed in the connection pool, data retention days, etc.), and data source connection information (such as the database driver class name, database server hostname or IP address, database server port number, etc.).

[0083] In some implementations, the core operation of the target tenant can also be to read and write the basic configuration information stored in the central configuration database, establish a connection with the central configuration database through the connection interface of the central configuration database, and perform corresponding read and write operations on the central configuration database.

[0084] In some implementations, the address information of the target tenant's primary database can be obtained by loading it from the central configuration library based on the tenant identifier, which is similar to obtaining the address information of the secondary database, and will not be described in detail here.

[0085] In some implementations, the number of online connections for each slave database corresponding to the target tenant is obtained based on the address information of each slave database, thus obtaining the set of online connection counts.

[0086] In this implementation, the current online connection count for each slave database can be obtained based on the address information of each slave database of the target tenant and by reading the current online connection count of each slave database (i.e., the number of connection interfaces currently being used by each slave database) from the connection pool. By obtaining the online connection count of each slave database of the target tenant, it is easier to quickly determine the target database in the subsequent process.

[0087] In some embodiments, the set of online connections includes multiple connection counts, and determining the target database from multiple databases based on the set of online connection counts and a preset threshold includes: Select one connection number from the set of online connections as a candidate connection number, and determine whether the candidate connection number is less than a preset threshold. If the number of candidate connections is less than the preset threshold, then the availability status of the slave database corresponding to the number of candidate connections is obtained; If the availability status of the slave database corresponding to the candidate connection number is available, then the slave database corresponding to the candidate connection number is determined to be the target database; If the availability status of the slave database corresponding to the candidate connection number is unavailable, and there are no unselected connections in the online connection number set, then the master database is determined as the target database or the operation is output as failed. If the availability status of the slave database corresponding to the candidate connection number is unavailable, and there are unselected connections in the online connection number set, then return to the step of selecting a connection from the online connection number set as a candidate connection number, and determine whether the candidate connection number is less than a preset threshold.

[0088] In some implementations, the preset threshold can be set to 30.

[0089] In some implementations, the selection of candidate connection numbers can adopt a load balancing strategy, selecting the slave database with the fewest current connections or the lowest load; a round-robin or random strategy can also be adopted, simply selecting or randomly allocating requests among available slave databases; or a health status priority strategy can be adopted, prioritizing slave databases with good health status and automatically avoiding faulty or slow-responding slave databases.

[0090] It should be noted that availability status refers to the ability and status of a database to provide services normally within a specific time period, and is measured by core dimensions such as whether the connection is available, whether the service is stable, whether the data is consistent, and whether the resources are sufficient.

[0091] By determining the availability status of the database, the impact of failures on operational requests can be further reduced, thereby improving server stability.

[0092] By adopting the above strategies, setting preset thresholds, and judging availability status, a suitable target database can be effectively selected, avoiding problems such as slow response or errors caused by excessive load or failure of the target database itself.

[0093] In some implementations, the method described in this embodiment also applies to situations where a tenant has multiple master databases. The specific implementation is similar to that for slave databases, and will not be repeated here.

[0094] In some embodiments, after selecting a connection number from the set of online connections as a candidate connection number and determining whether the candidate connection number is less than a preset threshold, the method further includes: If the number of candidate connections is greater than or equal to the preset threshold, and there are unselected connections in the set of online connections, then return to the step of selecting a connection from the set of online connections as a candidate connection, and determine whether the number of candidate connections is less than the preset threshold. If the number of candidate connections is greater than or equal to the preset threshold, and there are no unselected connections in the set of online connections, then the main database is determined as the target database or the operation is output as failed.

[0095] In this embodiment, by setting a threshold for the number of online connections to be less than a preset threshold and checking the availability status of the secondary database, this dual verification method ensures that the business requests of the target tenant can be matched with the appropriate target database for connection and corresponding operation. Furthermore, a fallback strategy is implemented: if no unselected connections exist, the system can either degrade to the primary database or directly output an operation failure, ensuring the server's high efficiency and stability.

[0096] In some embodiments, after performing the operation corresponding to the operation request on the target database, the method further includes: Identify the associated databases related to the target database; Perform the operation corresponding to the operation request on the associated database, wherein the associated database is a database in the target tenant's database other than the target database.

[0097] In this embodiment, distributed transaction management can be used to perform associated operations on other databases of the target tenant. By integrating distributed transaction management, this invention ensures that data consistency is effectively guaranteed in complex operations involving multiple independent databases or storage areas, thereby improving system reliability and consistency.

[0098] In some embodiments, performing the operation corresponding to the operation request on the associated database includes: When a first operation is performed on the target database, a second operation is performed on the associated database, wherein the first operation is a data creation operation and the second operation is a data update operation.

[0099] In some implementations, the first operation can be any one of a write operation, a read operation, a data creation operation, or a data update operation, and the second operation can also be any one of a write operation, a read operation, a data creation operation, or a data update operation. When the above operations are performed on the target database, the associated database will simultaneously perform the corresponding associated operations. For example, if a business process is completed collaboratively by multiple services, and each service manages independent data (for example, after the order service creates an order, it needs to call the inventory service and deduct inventory; these two operations need to be included in the same distributed transaction); when updating the global configuration parameters related to the tenant in the central configuration database, the relevant status flags in the tenant database need to be updated synchronously.

[0100] In some embodiments, establishing a connection to the target database based on the target database's connection interface includes: Obtain the connection interface of the target database from the data access component; A connection to the target database is established based on the connection interface.

[0101] In some embodiments, the data access component may include a tenant database access component.

[0102] The tenant database access component provides data manipulation capabilities for different types of tenant data storage areas. It includes corresponding entity models, data access objects (mappers / DAOs), and service interfaces for processing tenant business data (such as customer information, conversation logs, and order data). Specifically, the service interface for connecting to the target database can be obtained from the tenant database access component within the data access component. This service interface is then used to connect to the target database's connection interface, thus establishing a connection with the target database.

[0103] In some embodiments, the data access component may also include a data source management core component and a central configuration data access component.

[0104] The core data source management component is responsible for the basic dynamic management and switching logic of data sources. It does not include specific database entity models, data access objects (mappers / DAOs), or service interfaces; it only provides a general interface for switching data source contexts. Specifically, based on different business requests from the target tenant, it switches to the corresponding target database through the general interface provided by the core data source management component, and then calls the corresponding data access component of the target database to establish a connection with the target database.

[0105] The central configuration data access component encapsulates specific data operation capabilities for the central configuration repository, including predefined models, mappers, and services. These are used to read or modify central configuration repository data such as tenant global configuration parameters and data source mapping relationships. Specifically, when a target tenant needs to operate on the basic configuration information stored in the central configuration repository, it can obtain a service interface that interfaces with the central configuration repository through the central configuration data access component. This service interface then connects to the central configuration repository's connection interface, thus establishing a connection with the central configuration repository.

[0106] In some other embodiments, the data access component may include other components besides those described above, or the number of data access components may be reduced or added as needed. This embodiment does not impose specific limitations on this.

[0107] The data access component separates the data source switching logic from the specific data operation logic, encapsulating the operational capabilities of different data storage (such as the central configuration repository and the tenant master database) into independent components, thus improving the modularity and reusability of the method code. This eliminates the need for application developers to concern themselves with the complex configuration and switching details of the underlying data source; they only need to import the corresponding component and call its interface, reducing development difficulty. When it is necessary to support new data storage types or modify the access methods of existing data storage, only the corresponding data access component needs to be adjusted or added. This modularization and standardization of data access logic greatly simplifies the data access process.

[0108] This application also provides a multi-tenant data source management system. Please refer to [link / reference]. Figure 3 The diagram shown is a structural schematic of a multi-tenant data source management system provided in an embodiment of the present invention. Specifically, as shown... Figure 3 As shown, the system includes: The application service layer is used to obtain the business requests of the target tenant and determine the operation requests and tenant identifiers of the target tenant based on the business requests.

[0109] The data management and access layer is used to determine the target database as the primary database based on the tenant identifier when the operation request is a write operation or a core operation; wherein the target tenant is configured with the primary database and multiple slave databases.

[0110] If the operation request is a read operation or a non-core operation, the target database is determined to be one of the multiple slave databases based on the tenant identifier.

[0111] The data management and access layer is also used to establish a connection with the target database based on the connection interface of the target database.

[0112] The application service layer is also used to perform the operation corresponding to the operation request on the target database.

[0113] This embodiment utilizes the aforementioned multi-tenant data source management system. The application service layer obtains the business requests from the target tenant, the data management and access layer determines the target database based on the business requests and establishes a connection with the target database, and finally, the application service layer performs corresponding operations on the target database. This achieves stable and efficient system operation and improves system reliability.

[0114] In some embodiments, such as Figure 3 As shown, the system may also include a configuration layer and a data storage layer. The configuration layer is used to configure the tenant's basic configuration information, and the data storage layer is used to store the tenant's database.

[0115] The configuration layer can include a configuration center and a central configuration repository. The configuration center manages data source configurations, loading the target tenant's database address information from the central configuration repository based on the tenant identifier. For example, configuration management services such as Nacos or Consul can be used. The configuration center provides unified access and management of the central configuration repository, caches hot configuration data, dynamically synchronizes and updates it, strengthens security, and controls access permissions. This ensures the security of tenants' basic configuration information while improving the overall system efficiency.

[0116] The data storage layer can include data storage areas, which can include independent physical storage areas, logically isolated storage areas, and shared data storage areas. Data storage areas are used to store the databases of all tenants.

[0117] In some embodiments, such as Figure 3 As shown, the application service layer can also include multiple application services (e.g., application service 1 and application service 2). These multiple application services can obtain business requests from different tenants and determine the corresponding tenant's operation request and tenant identifier based on the business requests. The multiple application services are also used to perform corresponding operation requests on the target databases corresponding to different tenants.

[0118] The data management and access layer includes the data source manager, data access components, and distributed transaction manager.

[0119] The data source manager is used to determine the target database as the primary database based on the tenant identifier when the operation request is a write operation or a core operation. The target tenant is configured with the primary database and multiple secondary databases. When the operation request is a read operation or a non-core operation, the target database is determined as one of the multiple secondary databases based on the tenant identifier. It is also used to establish a connection with the target database based on the target database's connection interface.

[0120] The data access components include a core data source management component, a central configuration data access component, and a tenant business data access component. The core data source management component provides the connection interface between the application service and the database; the central configuration data access component provides the connection interface between the application service and the central configuration database; and the tenant business data access component provides the connection interface between the application service and the tenant database.

[0121] The distributed transaction manager is used to perform association operations on other databases of the target tenant, wherein the other databases are databases other than the target database in the tenant's database.

[0122] like Figure 4 As shown in the figure, this application embodiment also provides an electronic device, including a processor and a memory, wherein the memory stores a computer program, and the processor executes the computer program to implement the multi-tenant data source management method described in the above embodiment.

[0123] It should be noted that a processor can be a central processing unit (CPU), a data processing unit (DPU), a graphics processing unit (GPU), or other integrated circuits used to execute program instructions, process data, and control system operation.

[0124] In this embodiment, the memory can be used to store software programs. The processor executes various functional applications and multi-tenant data source management methods by running the software programs stored in the memory. Furthermore, the memory may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory may also include a memory controller to provide the processor with access to the memory.

[0125] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. Similarly, for the sake of brevity and to aid in understanding one or more aspects of the invention, in the description of exemplary embodiments of the invention above, various features of the embodiments are sometimes grouped together in a single embodiment, figure, or description thereof. The claims, which follow the detailed description, are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of the invention.

[0126] It should be noted that the above embodiments are illustrative of the invention and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware.

[0127] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0128] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A multi-tenant data source management method, characterized in that, The method includes: Obtain the business request of the target tenant, and determine the operation request and tenant identifier of the target tenant based on the business request; When the operation request is a write operation or a core operation, the target database of the target tenant is determined to be the primary database based on the tenant identifier; wherein, the target tenant is configured with the primary database and multiple secondary databases; If the operation request is a read operation or a non-core operation, the target database of the target tenant is determined to be one of the multiple slave databases based on the tenant identifier; Establish a connection with the target database based on the target database's connection interface; Perform the operation corresponding to the operation request on the target database.

2. The method according to claim 1, characterized in that, In the case where the operation request is a read operation or a non-core operation, determining the target database as one of the multiple slave databases based on the tenant identifier includes: The set of online connection counts is obtained based on the tenant identifier, wherein the set of online connection counts is the online connection count of each slave database of the target tenant; Based on the set of online connections and a preset threshold, a target database is determined from multiple slave databases, wherein the preset threshold is the maximum number of online connections allowed for each slave database.

3. The method according to claim 2, characterized in that, The method of obtaining the set of online connections based on the tenant identifier includes: Based on the tenant identifier, the address information of each slave database of the target tenant is obtained from the central configuration database. The central configuration database stores the basic configuration information of all tenants. The basic configuration information of each tenant includes the tenant identifier, the master database address information and multiple slave database address information. Based on the address information of each slave database, the number of online connections for each slave database corresponding to the target tenant is obtained, and the set of online connection counts is obtained.

4. The method according to claim 3, characterized in that, The set of online connections includes multiple connection counts, and determining the target database from multiple databases based on the set of online connection counts and a preset threshold includes: Select one connection number from the set of online connections as a candidate connection number, and determine whether the candidate connection number is less than a preset threshold. If the number of candidate connections is less than the preset threshold, then the availability status of the slave database corresponding to the number of candidate connections is obtained; If the availability status of the slave database corresponding to the candidate connection number is available, then the slave database corresponding to the candidate connection number is determined to be the target database; If the availability status of the slave database corresponding to the candidate connection number is unavailable, and there are no unselected connections in the online connection number set, then the master database is determined as the target database or the operation is output as failed. If the availability status of the slave database corresponding to the candidate connection number is unavailable, and there are unselected connections in the online connection number set, then return to the step of selecting a connection from the online connection number set as a candidate connection number, and determine whether the candidate connection number is less than a preset threshold.

5. The method according to claim 4, characterized in that, After selecting a connection number from the set of online connections as a candidate connection number and determining whether the candidate connection number is less than a preset threshold, the method further includes: If the number of candidate connections is greater than or equal to the preset threshold, and there are unselected connections in the set of online connections, then return to the step of selecting a connection from the set of online connections as a candidate connection, and determine whether the number of candidate connections is less than the preset threshold. If the number of candidate connections is greater than or equal to the preset threshold, and there are no unselected connections in the set of online connections, then the main database is determined as the target database or the operation is output as failed.

6. The method according to any one of claims 1-5, characterized in that, After performing the operation corresponding to the operation request on the target database, the method further includes: Identify the associated databases related to the target database; Perform the operation corresponding to the operation request on the associated database, wherein the associated database is a database in the target tenant's database other than the target database.

7. The method according to claim 6, characterized in that, The operation performed on the associated database corresponding to the operation request includes: When a first operation is performed on the target database, a second operation is performed on the associated database, wherein the first operation is a data creation operation and the second operation is a data update operation.

8. The method according to claim 7, characterized in that, Establishing a connection to the target database based on the target database's connection interface includes: Obtain the connection interface of the target database from the data access component; A connection to the target database is established based on the connection interface.

9. A multi-tenant data source management system, characterized in that, include: The application service layer is used to obtain the business requests of the target tenant and determine the operation requests and tenant identifiers of the target tenant based on the business requests. The data management and access layer is used to determine the target database as the primary database based on the tenant identifier when the operation request is a write operation or a core operation; wherein the target tenant is configured with the primary database and multiple slave databases; If the operation request is a read operation or a non-core operation, the target database is determined to be one of the multiple slave databases based on the tenant identifier; The data management and access layer is also used to establish a connection with the target database based on the connection interface of the target database; The application service layer is also used to perform the operation corresponding to the operation request on the target database.

10. An electronic device, characterized in that, It includes a processor and a memory, wherein the memory stores a computer program, and the processor executes the computer program to implement the multi-tenant data source management method as described in any one of claims 1-8.

Images