CN116996583A

CN116996583A - Route distribution method and device, electronic equipment and storage medium

Info

Publication number: CN116996583A
Application number: CN202211067923.XA
Authority: CN
Inventors: 肖啸
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2022-09-01
Filing date: 2022-09-01
Publication date: 2023-11-03

Abstract

The present application relates to the field of computer technologies, and in particular, to a route distribution method, a device, an electronic device, and a storage medium, which are used to improve the route distribution efficiency. The method comprises the following steps: receiving first transaction version information aiming at a target service object and reported by an associated target gateway; the target gateway and the storage node serve the same service object set containing the target service object; determining transaction version information to be pushed for the target service object based on the second transaction version information and the first transaction version information which are currently stored and are used for the target service object; each transaction version information corresponds to a routing transaction for characterizing the change of the corresponding routing information; and pushing the transaction version information to be pushed and the corresponding routing information to the target gateway. According to the application, the newly added storage node is combined with the transaction version information reported by the storage node and the target gateway, so that the route information is pushed to the target gateway, and the route distribution efficiency is improved through the scheduling balance of the storage node.

Description

Route distribution method and device, electronic equipment and storage medium

Technical Field

The present application relates to the field of computer technologies, and in particular, to a route distribution method, a route distribution device, an electronic device, and a storage medium.

Background

Metadata refers to meta-information for managing business object storage data. In order to improve data reliability, metadata may be further divided into Partition (Partition) and duplicate (duplicate) levels, where data of a Partition is typically composed of multiple replicas. The routing information refers to all information (such as the address where the data copy is stored) required for how the Gateway (GW) locates the data copy, and is part of the metadata.

When a very large scale cluster has access to a large number of business objects, how fast synchronous routing becomes a problem. As data grows: the Partition in the cluster will split and merge, the Replica in the cluster will also migrate and balance, the storage address corresponding to the Replica will change, and the Replica position information cached in the GW needs to be modified in time.

In the related art, metadata is stored in a distributed file storage database MongoDB, and each GW pulls route information from the MongoDB by pulling the route information. Because of the large cluster scale, thousands of GW instances can lead to MongoDB pressure being large and easy to overload if each GW adopts a mode of pulling route information, thereby leading to untimely route update.

Thus, how to efficiently and accurately implement route distribution synchronization is needed to be solved.

Disclosure of Invention

The embodiment of the application provides a route distribution method, a device, electronic equipment and a storage medium, which are used for improving the efficiency of route distribution and route management.

The route distribution method provided by the embodiment of the application is applied to the storage node and comprises the following steps:

receiving first transaction version information aiming at a target service object and reported by an associated target gateway; the target gateway and the storage node serve the same service object set containing the target service object, and each service object set contains at least one service object;

determining transaction version information to be pushed for the target service object based on the second transaction version information and the first transaction version information which are currently stored for the target service object; wherein, each transaction version information corresponds to a routing transaction for characterizing the change of the corresponding routing information;

and pushing the transaction version information to be pushed and the corresponding routing information to the target gateway.

The other route distribution method provided by the embodiment of the application is applied to the target gateway and comprises the following steps:

Reporting first transaction version information for a target service object to an associated storage node, so that the storage node determines transaction version information to be pushed for the target service object based on currently stored second transaction version information for the target service object and the first transaction version information; the target gateway and the storage node serve the same service object set containing the target service object, and each service object set contains at least one service object;

and receiving the transaction version information to be pushed aiming at the target service object and the corresponding routing information pushed by the storage node.

The route distribution system provided by the embodiment of the application comprises: at least one gateway and at least one storage node; the associated storage node and gateway serve the same set of business objects, each set of business objects containing at least one business object;

each storage node is used for receiving first transaction version information of a service object in a service object set, which is reported by an associated gateway; determining transaction version information to be pushed for the service object based on the second transaction version information and the first transaction version information which are currently stored for the service object; pushing the transaction version information to be pushed and corresponding routing information to the associated gateway;

Each gateway is used for reporting the first transaction version information with the associated storage node; and receiving the transaction version information to be pushed and the routing information pushed by the storage node.

The route distribution device provided by the embodiment of the application comprises:

the transmission unit is used for receiving first transaction version information aiming at a target service object and reported by an associated target gateway; the target gateway and the storage node serve the same service object set containing the target service object, and each service object set contains at least one service object;

a determining unit, configured to determine, based on the second transaction version information and the first transaction version information stored currently for the target service object, transaction version information to be pushed for the target service object; wherein, each transaction version information corresponds to a routing transaction for characterizing the change of the corresponding routing information;

and the pushing unit is used for pushing the transaction version information to be pushed and the corresponding routing information to the target gateway.

Optionally, the first transaction version information is the latest transaction version information currently stored by the target gateway and aimed at the target service object;

The determining unit is specifically configured to:

taking the latest transaction version information aiming at the target business object in the second transaction version information stored currently as target transaction version information;

if the first transaction version information is detected to be different from the target transaction version information, the determined increment transaction version information is taken as the transaction version information to be pushed based on the difference between the first transaction version information and the target transaction version information.

Optionally, the apparatus further includes:

a detection unit, configured to detect, in real time, a database for storing metadata of each service object, where the metadata includes routing information;

and if the database is determined to generate the routing transaction aiming at the target business object, acquiring corresponding second transaction version information and routing information from the database and storing the second transaction version information and the routing information.

Optionally, the transmission unit is further configured to:

before receiving first transaction version information aiming at a target service object and reported by an associated target gateway, receiving a registration request sent by the target gateway;

determining whether there is registration capability for the target gateway based on the number of currently registered gateways;

And if the registration capability for the target gateway is determined, establishing long connection with the target gateway.

Optionally, the transmission unit is further configured to:

if the target gateway does not have the registration capability, feeding back the connection information of other storage nodes which can be connected currently to the target gateway, so that the target gateway sends a registration request to the other storage nodes based on the connection information and establishes long connection;

wherein the other storage nodes currently connectable serve the same set of business objects as the target gateway.

Optionally, each service object corresponds to a service object tree, each tree node in the service object tree represents metadata storage resources of each level corresponding to the service object, and each tree node corresponds to transaction version information; wherein the metadata comprises routing information;

the transaction version information corresponding to each business object is determined according to the transaction version information corresponding to each tree node in the corresponding business object tree.

Optionally, each transaction version information includes: transaction numbers of corresponding routing transactions, operation serial numbers under corresponding routing transactions; each routing transaction includes at least one operation.

Optionally, the number of business objects contained in each set of business objects is associated with a storage node and gateway serving the set of business objects.

Another route distribution device provided by the embodiment of the present application includes:

a reporting unit, configured to report, to an associated storage node, first transaction version information for a target service object, so that the storage node determines transaction version information to be pushed for the target service object based on second transaction version information currently stored for the target service object and the first transaction version information; the target gateway and the storage node serve the same service object set containing the target service object, and each service object set contains at least one service object;

and the receiving unit is used for receiving the transaction version information to be pushed aiming at the target service object and the corresponding routing information pushed by the storage node.

Optionally, the reporting unit is further configured to:

before reporting first transaction version information for a target service object to an associated storage node, sending a registration request to the storage node;

If the storage node has a registration capability, a long connection is established with the storage node, the registration capability being determined by the storage node based on the number of currently registered gateways.

Optionally, the apparatus further includes:

the transmission unit is used for receiving the connection information of other storage nodes which can be connected currently and are sent by the storage nodes, wherein the connection information is sent after the storage nodes are determined to have no registration capability; wherein the other storage nodes which can be connected at present and the target gateway serve the same service object set;

and sending a registration request to the other storage nodes based on the connection information and establishing a long connection.

Optionally, the reporting unit is specifically configured to:

taking the latest transaction version information which is currently stored and aims at the target service object as the first transaction version information;

and reporting the first transaction version information to the storage node through a heartbeat signal.

An electronic device provided by an embodiment of the present application includes a processor and a memory, where the memory stores a computer program, and when the computer program is executed by the processor, causes the processor to execute any one of the steps of the route distribution method described above.

An embodiment of the present application provides a computer-readable storage medium including a computer program for causing an electronic device to execute the steps of any one of the route distribution methods described above, when the computer program is run on the electronic device.

Embodiments of the present application provide a computer program product comprising a computer program stored in a computer readable storage medium; when the processor of the electronic device reads the computer program from the computer readable storage medium, the processor executes the computer program, so that the electronic device performs the steps of any one of the route distribution methods described above.

The application has the following beneficial effects:

the embodiment of the application provides a route distribution method, a route distribution device, electronic equipment and a storage medium. Since the present application adds a storage node between the gateway and the database for storing metadata. And, the storage nodes, the gateway and the business objects are partitioned, and the associated storage nodes and the gateway serve the same business object set. In the method, the storage node stores version information (namely transaction version information) of the routing transaction corresponding to the service object served by the storage node, and the gateway reports the currently stored transaction version information of the routing transaction corresponding to the target service object to the associated storage node in real time, so that the storage node can determine the transaction version information to be pushed for the target service object through comparison of the transaction version information, and further pushes the determined transaction version information to be pushed and the corresponding routing information to the target gateway with the transaction as granularity. In the above embodiment, the pressure on the database side is balanced through different storage node scheduling, and even if the data of a huge amount of service objects are stored in the cluster, the data of various types of service objects can be balanced through the partition technology, so that the efficiency of route distribution and route management is improved, and the overall resource utilization rate is improved.

Additional features and advantages of the application will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the application. The objectives and other advantages of the application will be realized and attained by the structure particularly pointed out in the written description and claims thereof as well as the appended drawings.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this specification, illustrate embodiments of the application and together with the description serve to explain the application and do not constitute a limitation on the application. In the drawings:

fig. 1 is a logic diagram of a route updating method in the related art of the present application;

fig. 2 is a schematic diagram of an application scenario in an embodiment of the present application;

fig. 3 is a flow chart of a route distribution method according to an embodiment of the present application;

FIG. 4 is a schematic diagram of a database instance partition in an embodiment of the present application;

FIG. 5 is a diagram illustrating a metadata structure according to an embodiment of the present application;

FIG. 6 is a schematic diagram of a business object tree in an embodiment of the present application;

FIG. 7A is a schematic diagram of a route push in an embodiment of the present application;

FIG. 7B is a logic diagram of another route push in an embodiment of the present application;

fig. 8 is a flow chart of another route distribution method according to an embodiment of the present application;

FIG. 9 is a schematic diagram of a route distribution system according to an embodiment of the present application;

FIG. 10 is an interactive timing diagram of a route distribution method according to an embodiment of the present application;

fig. 11 is a schematic diagram of a composition structure of a route distribution device according to an embodiment of the present application;

fig. 12 is a schematic diagram of a composition structure of another route distribution device according to an embodiment of the present application;

fig. 13 is a schematic diagram of a composition structure of an electronic device according to an embodiment of the present application;

fig. 14 is a schematic diagram of a computing device according to an embodiment of the application.

Detailed Description

For the purpose of making the objects, technical solutions and advantages of the embodiments of the present application more apparent, the technical solutions of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application, and it is apparent that the described embodiments are some embodiments of the technical solutions of the present application, but not all embodiments. All other embodiments, based on the embodiments described in the present document, which can be obtained by a person skilled in the art without any creative effort, are within the scope of protection of the technical solutions of the present application.

Some of the concepts involved in the embodiments of the present application are described below.

Storage node: is a logical node with a cache or storage function, such as a container group (pod) in a K8S cluster. In the embodiment of the application, the storage node is a node in a designed cache layer between the gateway and the database and is used for controlling logic for incremental pushing of the routing information.

Business object: refers to the tenants in the cluster, i.e., the cluster users. The tenant may be divided in terms of items or different applications. Each tenant is equivalent to a resource pool, an administrator configures a certain cluster resource for the tenant, all users under the tenant (namely users of the cluster resource) share the resources in the resource pool, and a large data cluster can be commonly used by a plurality of tenants.

Transaction version information: when the routing information is changed, a corresponding routing transaction (also called a routing event) is generated, and the transaction version information is a unique identifier for characterizing the version of the routing transaction, so that each transaction version information corresponds to a routing transaction for characterizing the change of the corresponding routing information.

Metadata (metadata): refers to meta information for managing business object storage data. Data in any file system is divided into data and metadata. The data refers to actual data in a general file, and the metadata refers to system data for describing characteristics of one file, such as access rights, file owners, and distribution information (inode.) of file data blocks, and the like. In a cluster file system, the distribution information includes the location of the file on the disk and the location of the disk in the cluster. The business object needs to manipulate a file to first obtain its metadata to locate the file and obtain the content or related attributes of the file. In an embodiment of the present application, metadata includes, but is not limited to, for example: the name of the data set, various functional attribute settings, the address where the data copy Replica is stored, etc.

Route information (route info or route for short): all that is required to calculate how the layer GW locates the data copy. Such as: an address where the copy of the data is located, a data set name, etc. The route is part of the metadata.

GW: the gateway, also called a compute and access module. The data access request of the service object is sent to the GW first, and the GW analyzes the service object request layer by layer according to a routing Component (Router Component) of the GW, so that the data on the disk is accessed correctly.

Partition: the space for storing specific data is essentially a folder for storing data on a disk.

Replica: the concept of replicas is actually defined under the partition hierarchy, each partition is configured with several replicas, and the data in the replicas under the same partition is consistent.

The route distribution method in the embodiment of the application also relates to the related technologies of cloud storage and databases:

cloud storage (cloud storage) is a new concept that extends and develops in the concept of cloud computing, and a distributed cloud storage system (hereinafter referred to as a storage system for short) refers to a storage system that integrates a large number of storage devices of various types in a network to work cooperatively through application software or application interfaces through functions such as cluster application, grid technology, and a distributed storage file system, so as to provide data storage and service access functions for the outside.

The Database (Database), which can be considered as an electronic filing cabinet, is a place for storing electronic files, and users can perform operations such as adding, inquiring, updating, deleting and the like on the data in the files. A "database" is a collection of data stored together in a manner that can be shared with multiple users, with as little redundancy as possible, independent of the application.

In the embodiment of the present application, the database for storing metadata may be a database based on distributed file storage, such as mongo db. MongoDB is written in C++ language, is a product between a relational database and a non-relational database, and has the most abundant functions in the non-relational database, like the relational database. The data structure supported by the device is very loose, and can store more complex data types; and the query language supported by the method is very powerful, the grammar is similar to that of an object-oriented query language, almost most functions similar to the query of a relational database list can be realized, and the indexing of data is also supported.

In addition, other types of databases are possible, and are not particularly limited herein.

The following briefly describes the design concept of the embodiment of the present application:

Metadata refers to system data used to describe characteristics of a file, such as access rights, file owners, and distribution information of file data blocks. In a cluster file system, the distribution information includes the location of the file on the disk and the location of the disk in the cluster. The business object needs to manipulate a file to first obtain its metadata to locate the file and obtain the content or related attributes of the file. The request of the service object is sent to the GW in the first step, and the GW analyzes the request of the service object layer by layer according to a routing Component (Router Component) of the GW, so that the data on the disk is correctly accessed.

In the related art, general metadata may be stored in the mongo db. Referring to fig. 1, which is a logic diagram of a route update method in the related art, taking a route update of MongoDB as an example, a route update method in the related art is briefly described:

in fig. 1, the GW mainly performs route update by pulling route information, where metadata is stored in fragments (Shards) in the form of fragments, and fig. 1 lists three data fragments, which are sh0, sh1, and sh2, respectively, and the specific flow is as follows:

First, when MongoDB is just started, routing information is pulled from configuration (config) and cached.

Wherein, in order to ensure data load balancing, mongoDB support blocks (Chunk) migrate between the shards. When Chunk migration occurs, the routing information changes, but not all mongdb routers (routers) are aware.

Thus, when a user requests access to data from a mongo db through a client, the mongo db will send a request to Shards with the routing version number. When the route version carried by the request is lower, the request is refused, and the MongoDB is triggered to re-pull the latest route information to config.

In practical application, because the cluster scale is larger, the number of GW examples is thousands, if each GW adopts a mode of pulling route information, and the pulling interval is too close, mongoDB pressure is large, and overload is easy to occur; when the pulling interval is too large, the route update may be not timely caused; in addition, the routing change is transactional, and direct pull may be to an intermediate state, requiring a large amount of masking logic by the GW, increasing the logic complexity of the GW.

In view of this, the embodiments of the present application provide a route distribution method, apparatus, electronic device, and storage medium. Because the application adds a storage node between the gateway and the database. And, the storage nodes, the gateway and the business objects are partitioned, and the associated storage nodes and the gateway serve the same business object set. In the method, the storage node stores transaction version information corresponding to the service object served by the storage node, and the gateway reports the transaction version information which is stored currently and can characterize the routing transaction corresponding to the target service object to the associated storage node in real time, so that the storage node can determine the transaction version information to be pushed aiming at the target service object through comparison of the transaction version information, and further pushes the determined transaction version information to be pushed and the corresponding routing information to the target gateway with the transaction as granularity. In the above embodiment, the pressure on the database side is balanced through different storage node scheduling, and even if the data of a huge amount of service objects are stored in the cluster, the data of various types of service objects can be balanced through the partition technology, so that the efficiency of route distribution and route management is improved, and the overall resource utilization rate is improved.

The preferred embodiments of the present application will be described below with reference to the accompanying drawings of the specification, it being understood that the preferred embodiments described herein are for illustration and explanation only, and not for limitation of the present application, and embodiments of the present application and features of the embodiments may be combined with each other without conflict.

Fig. 2 is a schematic diagram of an application scenario according to an embodiment of the present application. The application scenario diagram includes two terminal devices 210 and a server 220.

In the embodiment of the present application, the terminal device 210 includes, but is not limited to, a mobile phone, a tablet computer, a notebook computer, a desktop computer, an electronic book reader, an intelligent voice interaction device, an intelligent home appliance, a vehicle-mounted terminal, and the like; the terminal device may have a client installed thereon, which may be software (e.g., a browser), a web page, an applet, etc. The server 220 may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (Content Delivery Network, CDN), basic cloud computing services such as big data and artificial intelligence platforms, and the like.

It should be noted that, the route distribution method in the embodiments of the present application may be performed by an electronic device, which may be the terminal device 210 or the server 220, that is, the method may be performed by the terminal device 210 or the server 220 alone, or may be performed by both the terminal device 210 and the server 220 together.

Wherein the storage nodes, gateways, and databases all run in server 220.

Under the multi-tenant architecture, all tenants have metadata of their own, and all operations related to the tenants are not separated and driven by the metadata. In the metadata use process, the terminal equipment needs to query and calculate from the database every time. Wherein each tenant is a business object.

The following is a simple description of the route distribution method in the embodiment of the present application, taking the common implementation of the terminal device 210 and the server 220 as an example:

the client sends a data access request to the gateway in the server 220 through the terminal device 210, and the gateway can parse the data access request layer by layer based on its own routing component, so as to access the data on the disk correctly. The access data requires corresponding routing information (a part of metadata), and after acquiring relevant data based on the routing information, the relevant data can be fed back to the relevant client through the terminal device 210.

In order to ensure timeliness of the routing information, the gateway side can establish long connection with an associated storage node when the target gateway is started, report latest transaction version information aiming at a target service object (client) to the storage node, and compare the latest transaction version information which is sent by the target gateway and the transaction version information which is stored currently and aims at the target service object with the latest transaction version information which is stored currently and aims at the target service object to determine transaction version information to be pushed aiming at the target service object; and the storage node pushes the determined transaction version information to be pushed and the corresponding routing information to the target gateway.

After receiving the routing information, the target gateway can correctly access the data on the disk based on the routing information and feed back the data to the relevant client through the terminal device 210.

In addition, the target gateway can also store the transaction version information to be pushed and the corresponding target service object in a correlated way based on the received transaction version information to be pushed, and update the latest transaction version information corresponding to the target service object.

The transaction version information and the routing information of the business objects stored by the storage nodes are acquired from a database through real-time detection.

In an alternative embodiment, the terminal device 210 and the server 220 may communicate via a communication network.

In an alternative embodiment, the communication network is a wired network or a wireless network.

It should be noted that, the number of terminal devices and servers shown in fig. 2 is merely illustrative, and the number of terminal devices and servers is not limited in practice, and is not particularly limited in the embodiment of the present application.

In the embodiment of the application, when the number of the servers is multiple, the multiple servers can be formed into a blockchain, and the servers are nodes on the blockchain; the route distribution method disclosed by the embodiment of the application, wherein the related metadata, transaction version information and the like can be stored on a blockchain, such as first transaction version information, second transaction version information, route information and the like.

In addition, the embodiment of the application can be applied to various scenes, including but not limited to cloud technology, artificial intelligence, intelligent transportation, auxiliary driving and other scenes.

The route distribution method provided by the exemplary embodiments of the present application will be described below with reference to the accompanying drawings in conjunction with the application scenarios described above, and it should be noted that the application scenarios described above are only shown for the convenience of understanding the spirit and principles of the present application, and the embodiments of the present application are not limited in any way in this respect.

Referring to fig. 3, a flow chart of a route distribution method according to an embodiment of the present application is applied to a storage node, and a specific implementation flow of the method is as follows:

s31: the storage node receives first transaction version information aiming at a target service object, which is reported by an associated target gateway.

Wherein the target gateway and the storage node serve the same set of business objects comprising target business objects, each set of business objects comprising at least one business object.

In the embodiment of the application, the storage node is a logic node with a cache or storage function, such as pod in a K8S cluster. Specifically, the storage node is a node in a cache layer designed between a gateway and a database and used for controlling logic of incremental pushing of routing information.

Considering that when the cluster size is large in the related art, a large number of GWs can simultaneously pull routing information from the MongoDB in the related art, which results in high MongoDB pressure and easy overload. Based on this, in the present application, an idea of database instance partitioning is presented.

In particular, storage nodes and gateways are grouped by business objects, with each group of storage nodes and gateways handling only specific business objects. The storage nodes and the gateways divided into the same group have an association relationship, so that the associated storage nodes and the gateways serve the same business object set.

Optionally, the number of business objects contained in each business object set is associated with a storage node and gateway serving the business object set to implement partition management for tenants of different sizes.

In embodiments of the present application, a set of storage nodes and gateways for servicing business objects may be referred to as a service set, with the storage nodes in each service set being associated with a gateway. For example, the number of storage nodes and gateways of each group is set to be consistent, that is, the sizes of tenants that can be served by each service set are consistent.

FIG. 4 is a schematic diagram of database instance partitioning according to an embodiment of the present application. For example, there are 10 business objects altogether, and 3 sets of gateways and storage nodes, there are four gateways in each service set, two storage nodes; wherein, the service object 1 is 1 large tenant, the service objects 2-4 are 3 medium tenants, the service objects 5-10 are 6 small tenants, based on this, the number of gateways and storage nodes between each service set is consistent, and the method can be set: 1) The service set 1 and the service object set 1 only comprising the service object 1 are a group, namely, four gateways and two storage nodes in the service set 1 serve the service object 1; 2) The service set 2 and the service object set 2 formed by the service objects 2-4 are a group, namely, four gateways and two storage nodes in the service set 2 serve the service objects 2-4 together; 3) The service set 3 and the service object set 3 formed by the service objects 5-10 are a group, i.e. four gateways and two storage nodes in the service set 3 jointly serve the service objects 5-10.

It should be noted that the foregoing is exemplified by the balanced division of the service set, and of course, the balanced division may also be performed, for example, the service set 1 includes two gateways and 1 storage node; the service set 2 comprises four gateways and two storage nodes, etc. In practice, the dividing manner of the service sets may be flexibly set according to practical situations, and in addition, the number of gateways and storage nodes in each service set may be proportional, etc., which is not specifically limited herein.

In the embodiment, through a partition management mode, a larger tenant can have independent gateway and storage node service, so that isolation of resources is ensured, and meanwhile, the efficiency of route pushing is improved. For massive small tenants, the utilization rate of resources is improved in a service sharing mode.

Optionally, before step S31 is performed, a communication connection needs to be established between the target gateway and the storage node, that is, before receiving the first transaction version information for the target service object reported by the associated target gateway, the storage node also receives a registration request sent by the target gateway.

In the embodiment of the application, the target gateway can select an associated storage node for registration when starting, and the specific process is as follows:

The target gateway selects an associated storage node and sends a registration request to the storage node to request connection establishment, and the storage node determines whether the storage node has registration capability for the target gateway based on the number of currently registered gateways after receiving the registration request.

In the embodiment of the application, a certain proportion can be arranged between the gateways and the storage nodes in the same service set, so that the number of the gateways which can be served by each storage node in the same service set is balanced. Thus, the storage node knows how many gateways it has served and also how many gateways need to serve.

When the storage node determines that the storage node has the registration capability for the target gateway, namely the number of gateways connected by the storage node at present is not up to the upper limit temporarily, communication can be established with the target gateway, and long connection is established with the target gateway.

For example, there are four gateways (gateways 1-4) and two storage nodes (storage nodes a-b) for service set 2, where the target gateway-gateway 1 sent a registration request to storage node a, and the gateway to which storage node a is currently connected was only gateway 2, so that storage node a also has registration capability for the target gateway, and also establishes a long connection with gateway 1.

Optionally, if the number of gateways currently connected to the storage node reaches an upper limit, that is, it is determined that the storage node does not have the registration capability for the target gateway, connection information of other storage nodes currently connectable is fed back to the target gateway, so that the target gateway sends a registration request to other storage nodes based on the connection information and establishes long connection; furthermore, the target gateway can communicate with other storage nodes which have established connection, report the first transaction version information, receive the transaction version information to be pushed and corresponding routing information and the like fed back by the other storage nodes.

Wherein, the connection information refers to the identification, connection address and the like of other storage nodes which can be connected currently. In this step, there may be one or more other currently connectable storage nodes that feed back to the target gateway, which is not specifically limited herein.

In addition, other storage nodes that are currently connectable serve the same set of business objects as the target gateway. In embodiments of the present application, the storage node may feed back to the target gateway the associated other storage node, and the other storage node is connectable, i.e. has registration capability for the target gateway.

Taking the service set 2 as an example, the target gateway-gateway 1 sends a registration request to the storage node a, but the gateway to which the storage node a is currently connected has the gateway 2 and the gateway 3, so the storage node a does not have the registration capability for the target gateway, and the associated storage node b is currently connected only to the gateway 4, so the storage node b can be used as a "currently connectable other storage node", the connection information of the storage node b is fed back to the gateway 1, and the gateway 1 sends a registration request to the storage node b to establish a long connection with the storage node b.

In the embodiment of the application, the target gateway can periodically report the first transaction version information corresponding to each service object served by the target gateway to the storage node. Thus, the target business object may be any one or more objects in the set of business objects served by the target gateway, or any one or some specified objects, without specific limitation herein.

Alternatively, the target gateway may report the first transaction version information to the storage node through a heartbeat signal.

Specifically, the target gateway sends the first transaction version information for the target transaction object to the interconnected storage nodes at intervals so as to update the route immediately.

For example, at time T1, the target gateway sends the latest transaction version information of the target service object, which is currently stored, to the storage node through a heartbeat signal, to be V1; at time T2, the target gateway sends the currently stored latest transaction version information for the target business object to the storage node via a heartbeat signal, V2, and so on.

S32: the storage node determines transaction version information to be pushed for the target service object based on the second transaction version information and the first transaction version information of the target service object which are currently stored.

Each transaction version information corresponds to a routing transaction for representing the change of the corresponding routing information, such as splitting and merging of Partition in a cluster, and migration balancing of Replica in the cluster.

Optionally, the first transaction version information is the latest transaction version information which is currently stored by the target gateway and aims at the target service object; step S32 further includes the following substeps S321-S322 (not shown in fig. 3):

s321: the storage node takes the latest transaction version information aiming at the target service object in the second transaction version information stored currently as target transaction version information;

S322: if the storage node detects that the first transaction version information is different from the target transaction version information, the storage node uses the determined increment transaction version information as the transaction version information to be pushed based on the difference between the first transaction version information and the target transaction version information.

For example, at time T1, the latest transaction version information of the target service object currently stored by the target gateway side is V1, and the latest transaction version information of the target service object currently stored by the storage node side is V2, that is, the first transaction version information of the target service object is V1, and the target transaction version information is V2. It is obvious that the first transaction version information is inconsistent with the target transaction version information, and at this time, the storage node can determine that the corresponding incremental transaction version information is V2 based on the difference between the first transaction version information and the target transaction version information, that is, the transaction version information to be pushed is V2.

Optionally, if the storage node detects that the first transaction version information is the same as the target transaction version information, it indicates that no new routing transaction is generated for the target service object in the period, and further, a prompt message for indicating that no routing update is required may be fed back to the target gateway.

Or, the feedback to the target gateway is not required, if the target gateway does not receive the transaction version information to be pushed or the prompt message fed back by the storage node within a period of time after sending the heartbeat signal, the period can be determined without route update.

It should be noted that the foregoing manner is merely illustrative, and any feedback manner is applicable to the embodiments of the present application, which are not limited herein.

In the embodiment, considering the transactional nature of route change, incremental route pushing is performed to the gateway by taking the transaction as granularity, and compared with the mode of pulling the route information by the gateway in the related art, the method can effectively avoid the occurrence of an intermediate state, so that the gateway does not need to do a large amount of shielding logic and the logic complexity of the gateway is not required to be increased.

S33: and the storage node pushes the transaction version information to be pushed and the corresponding routing information to the target gateway.

In the embodiment of the application, the target gateway can inquire related data based on the received routing information. The routing information refers to all information required by how the GW locates to the data copy. Such as the address where the copy of the data is located, the name of the data set, etc.

In addition, after receiving the transaction version information to be pushed, the target gateway also stores the transaction version information to be pushed and the corresponding target service object in a correlated manner, and updates the latest transaction version information corresponding to the target service object.

Taking the above example as an illustration, after receiving the transaction version information to be pushed, the target gateway can update the latest transaction version information currently corresponding to the target service object to V2.

At time T2, the latest transaction version information of the target service object currently stored by the target gateway side is V2, and the latest transaction version information of the target service object currently stored by the storage node side is V4, that is, the first transaction version information of the target service object is V2, and the target transaction version information is V4. Further, the storage node may determine that the corresponding incremental transaction version information is V3 and V4, i.e., the transaction version information to be pushed is V3 and V4.

After receiving the transaction version information to be pushed, the target gateway can update the latest transaction version information currently corresponding to the target service object to V4.

In the above embodiment, since the present application adds a storage node between the gateway and the database. And, the storage nodes, the gateway and the business objects are partitioned, and the associated storage nodes and the gateway serve the same business object set. In the method, the storage node stores version information (namely transaction version information) of the routing transaction corresponding to the service object served by the storage node, and the gateway reports the currently stored transaction version information of the routing transaction corresponding to the target service object to the associated storage node in real time, so that the storage node can determine the transaction version information to be pushed for the target service object through comparison of the transaction version information, and further pushes the determined transaction version information to be pushed and the corresponding routing information to the target gateway with the transaction as granularity. In the above embodiment, the pressure on the database side is balanced through different storage node scheduling, and even if the data of a huge amount of service objects are stored in the cluster, the data of various types of service objects can be balanced through the partition technology, so that the efficiency of route distribution and route management is improved, and the overall resource utilization rate is improved.

Optionally, the storage node further needs to detect a database for storing metadata of each service object in real time, where the metadata includes routing information; and if the database is determined to generate the routing transaction aiming at the target business object, acquiring corresponding second transaction version information and routing information from the database and storing the second transaction version information and the routing information.

Fig. 5 is a schematic diagram of a metadata structure according to an embodiment of the present application.

The metadata shown in fig. 5 is divided into 5 levels, from top to bottom: tenant Account Account, key space, data set Collection, partition, copy Replica.

Where Account is the instance visible to the business object, keySpace is the namespace of the data set (Namespace), collection is the data set (similar to the concept of a database table). These three-layer structures are perceptible to the service object, while the two-layer structures of Partition and reply are imperceptible to the service object.

One data set Collection can be divided into a plurality of partitions by a Partition Policy (Partition Policy) set by a service object, so as to transversely scale the Collection. And the data of a Partition is stored on a Disk (Disk) by forming a shift group by 3 redundant copies of duplicate. One important information in the metadata of Replica is: the Disk address that the copy holds.

In practical application, metadata related to the whole cloud storage product can be stored in the MongoDB according to the structures of all levels. Each node corresponds to an independent file Record (Document Record).

In combination with the metadata structure, the method aims at solving the transaction problem of route pushing and better realizing incremental pushing. The application designs a business version information mechanism based on a business object Account.

In the embodiment of the application, each service object corresponds to a service object tree, each tree node in the service object tree represents each level of metadata storage resources corresponding to the service object, and each tree node corresponds to one transaction version information; the transaction version information corresponding to each business object is determined according to the transaction version information corresponding to each tree node in the corresponding business object tree.

Wherein the metadata contains routing information.

Referring to fig. 6, a schematic diagram of a business object tree according to an embodiment of the present application is shown. As shown in fig. 6, the present application designs a transaction version information, denoted routevr, for each Account in an Account unit.

The business object tree (AccountTree) takes the associated metadata storage resources at all levels as tree nodes, and combines the metadata structure shown in FIG. 5, and the metadata storage resources (namely DB Resource) at all levels form an Account-Key space-Collection-Partition. Each tree node has its own routevr, and the routevr of the AccountTree is determined from the routevr of each tree node it contains.

Optionally, each transaction version information includes: transaction numbers of corresponding routing transactions, operation serial numbers under corresponding routing transactions; each routing transaction includes at least one operation. Based on this, the transaction version information may also be referred to as a transaction version number, or a routing version number.

RouteVer: { M.m }, M represents a transaction, and M represents the operation sequence number under this transaction.

On the basis that each routing transaction contains at least one operation, the routeVer of one AccountTree is the maximum value of each included tree node, and the maximum value is the routeVer corresponding to the last operation under the latest routing transaction.

In fig. 6, three steps are listed, each step corresponds to a routing transaction, and the following details are given by taking each step as an example respectively:

such as step1 in fig. 6: creating Account, wherein the whole routing transaction comprises an operation, thus, the corresponding transaction number is 1, the corresponding operation serial number is 0, and the combination is the transaction version information (RouteVer) corresponding to the step1 routing transaction: ver1.0.

In step1, routeVer for this AccountTree is Ver1.0.

As further step2 in fig. 6: under the Account of step1, keySpace is created, and the whole routing transaction also only comprises one operation, so that the corresponding transaction number is 2, the corresponding operation serial number is 0, and the combination is the transaction version information (RouteVer) corresponding to the step2 routing transaction: ver2.0.

In step2, routeVer for this AccountTree was Ver2.0.

Step3 in FIG. 6: the Collection is created under step 2's KeySpace, and consists of two partitions, the entire routing transaction contains three operations (i.e., sub-steps): create Collection and create two fractions. Wherein, the transaction numbers corresponding to the three operations are all 3, but the corresponding operation serial numbers are different, so the routeVer of the Collection is 3.0, and the two fractions contained in the routeVer are 3.1 and 3.2 respectively. The entire 3.X routing transaction is pushed together after completion, rather than pushing a single sub-step, avoiding the occurrence of intermediate routing states (e.g., where only a portion of the Partition creation is successful).

In step3, routeVer for this AccountTree is Ver3.2.

In the above embodiment, the transaction version information of the service object is represented by a tree structure, and the routing incremental push is implemented based on the routing version number tree structure.

Since the metadata listed here is stored in MongoDB, the present application makes use of the change stream (ChangeStream) characteristics of MongoDB for push of routes. The Change Stream is a solution for realizing Change detection by MongoDB, is similar to a trigger of a relational database, can provide a simple interface for acquiring database data Change in real time for a service, and is safer and more convenient.

Considering that the ChangeStream of MongoDB has a certain performance limit (cannot have too many streams), while the large cluster has a large data size, a large number of tenants (Account), and a very large number of Gateway. In order to improve the performance and efficiency of the whole pushing, the application designs a mechanism for route layering and partition pushing.

The following describes a route push mechanism related to a storage node in the embodiment of the present application in detail with reference to the accompanying drawings:

fig. 7A is a schematic diagram of route pushing according to an embodiment of the present application. In fig. 7A, the control plane (control plane), the data plane (dataplane), and the database MongoDB are divided into three parts. Wherein, the control plane refers to a part used for transmitting instructions and calculating table items in the system. In the embodiment of the application, a Route update operator (Route Change OP) of the control plane is used for controlling Route update and is divided into a System Admin (System Admin), a Workflow (Workflow) and a Resource Mgr (Resource Mgr). The System Admin can manage the instructions of the business objects, the Workflow corresponds to the relevant flow of the instructions, and the Resource Mgr relates to the interaction with the MongoDB. Specifically, resource Mgr mainly manages transaction modifications, routing events and related metadata (event and metadata for short), namely Transaction Modify Event & Meta in fig. 7A. When a data set needs to be created by combining step3 shown in fig. 6, a System Admin mainly manages related creation instructions, a Workflow part performs instruction related operations, finally, resource Mgr generates corresponding transaction version information based on the route change and notifies a mongo db, related metadata is stored in a metadata storage (MetaStorage) part in the mongo db, and related transaction version information is stored in a routing event (RouteEvent) part in the mongo db.

The data plane, that is, the user plane, refers to a part of the device that completes forwarding and processing of the user service according to the instruction generated by the control plane. In the embodiment of the application, the interaction between the gateway and the storage node is mainly completed on the data plane.

Specifically, the present application designs a Resource Cache (Resource Cache) layer between the GW (i.e., gateway in fig. 7A) and the mongo db to control the logic of incremental push. In this layer, the layer includes a plurality of Resource caches, i.e. storage nodes, and fig. 7A is an example of a logical node with a Cache function, which is also called a Cache node.

The GW will select an associated Resource Cache to Register (i.e., register in fig. 7A) when starting up, report the latest transaction version numbers (i.e., first transaction version information) of all the accounts currently managed by the GW to the Resource Cache through heartbeat, and keep long connection waiting for push route. While Resource Cache detects MongoDB (i.e., watch in fig. 7A) through ChangeStream, whenever a routing event occurs, such as creating Collection, partition splitting, partition merging, etc., incremental route pushing and related metadata pushing (i.e., deltaPush in fig. 7A) to GW will be performed with transaction granularity. When the RouteEvent in the MongoDB has new transaction version information, the cache node is notified (i.e., notify), and the cache node pulls related metadata (i.e., pull Meta) from the MetaStorage in the MongoDB.

In fig. 7A, two white gateways and a white cache node are in the same service set, and a black gateway and a black cache node are in the same service set. Fig. 7A is an illustration of one cache node per service set.

Fig. 7B is a schematic diagram of another route push according to an embodiment of the present application. In fig. 7B, two gateways that are also white are in the same service set as the white cache node, and the black gateway is in the same service set as the black cache node. Unlike fig. 7A, fig. 7B illustrates that each service set includes a plurality of cache nodes; other logic is the same and the repetition is not repeated.

In the embodiment, the method for effectively improving the subscription pushing capability can effectively reduce the routing pushing data volume by means of the database instance partition.

Referring to fig. 8, a flow chart of another route distribution method provided by an embodiment of the present application is applied to a target gateway, and a specific implementation flow of the method is as follows:

s81: the target gateway reports the first transaction version information aiming at the target service object to an associated storage node so that the storage node determines the transaction version information to be pushed aiming at the target service object based on the second transaction version information aiming at the target service object and the first transaction version information which are currently stored.

Optionally, before step S81 is performed, a communication connection needs to be established between the target gateway and the storage node. In the embodiment of the application, the target gateway can select an associated storage node for registration when starting, and the specific process is as follows:

the target gateway selects an associated storage node and sends a registration request to the storage node; after receiving the registration request, the storage node determines whether the storage node has registration capability for the target gateway based on the number of the gateways currently registered by the storage node. When it is determined that the storage node has the registration capability, a long connection is established with the storage node, and the specific implementation can refer to the above embodiment, and the repetition is omitted.

Optionally, if the storage node does not have the registration capability for the target gateway, the connection information of other storage nodes that can be currently connected may be fed back to the target gateway, and after the target gateway receives the connection information, a registration request is sent to the other storage nodes based on the connection information and a long connection is established based on the connection information.

After the target gateway establishes a long connection with the storage node, the first transaction version information for the target service object can be reported to the associated storage node.

Alternatively, the reporting operation may be performed periodically, that is, the target gateway may periodically report, to the storage node, the first transaction version information corresponding to each of the service objects served by the target gateway. The target service object may be any one or more objects in the service object set served by the target gateway, or any one or some specified objects, which are not specifically limited herein.

Specifically, each time the periodic reporting process, the following operations are performed:

firstly, the target gateway needs to take the latest transaction version information which is currently stored and aims at a target service object as first transaction version information; further, the first transaction version information is reported to the storage node by the heartbeat signal.

Taking the example that the target business object includes a business object 3 and a business object 4:

for example, at time T1, the target gateway currently stores the latest transaction version information for the service object 3 as V3-1 and the latest transaction version information for the service object 4 as V4-2, so that the target gateway may report V3-1 as the first transaction version information corresponding to the service object 3 and V4-2 as the first transaction version information corresponding to the service object 4 to the associated storage node through the heartbeat signal.

At time T2, the latest transaction version information of the service object 3 stored at the target gateway side is V3-2, and the latest transaction version information of the service object 4 is still V4-2, so that the target gateway can report the latest transaction version information of the service object 4 to the associated storage node through heartbeat signals by taking V3-2 as the first transaction version information corresponding to the service object 3 and V4-2 as the first transaction version information corresponding to the service object 4. Wherein, T1 and T2 are separated by a preset period.

It should be noted that, the foregoing is exemplified by periodic reporting by the gateway, and other reporting manners are also applicable to the embodiments of the present application, for example, non-periodic reporting, which is not limited herein.

S82: and the target gateway receives the transaction version information to be pushed aiming at the target service object and the corresponding routing information pushed by the storage node.

In the embodiment of the application, the target gateway can inquire related data based on the received routing information. And after receiving the transaction version information to be pushed, storing the transaction version information to be pushed and the corresponding target service object in a correlated manner, and updating the latest transaction version information corresponding to the target service object.

The route distribution system in the embodiment of the present application is briefly described below:

fig. 9 is a schematic structural diagram of a route distribution system according to an embodiment of the present application. The route distribution system 900 includes: at least one gateway 910 and at least one storage node 920; the associated storage node and gateway serve the same set of business objects, each set of business objects containing at least one business object.

Each storage node 920 is configured to receive first transaction version information for a service object in the service object set, which is reported by the associated gateway 910; determining transaction version information to be pushed for the service object based on the second transaction version information and the first transaction version information which are stored currently and used for the service object; the transaction version information to be pushed and the corresponding routing information are pushed to the associated gateway 910.

Each gateway 910 configured to report the first transaction version information with an associated storage node; transaction version information to be pushed and routing information pushed by the storage node 920 are received.

Optionally, the system further comprises a database 930:

the database 930 is configured to store metadata of each service object and transaction version information corresponding to each service object; the metadata contains routing information;

Each storage node 920 is further configured to detect a database 930 in real time; if it is determined that the database 930 generates a routing transaction for the service object, corresponding second transaction version information and routing information are acquired from the database 930 and stored.

It should be noted that, the specific implementation manners of the storage nodes and the gateway may refer to the above embodiments, and the repetition is not repeated.

Taking a storage node as a logic node with a cache function as an example, and taking a cache node for short as an example, the interaction process between the gateway and the cache node in the embodiment of the application is briefly described as follows:

referring to fig. 10, an interactive timing diagram of a route distribution method according to an embodiment of the present application is shown, and the specific implementation flow of the method is as follows:

step S1001: the target gateway selects an associated cache node and sends a registration request to the cache node;

step S1002: the cache node establishes long connection with the target gateway;

step S1003: the target gateway sends the latest transaction version number of the service object 1 to the cache node through a heartbeat signal;

step S1004: the cache node compares the received latest transaction version number aiming at the service object 1 with the latest transaction version number aiming at the service object 1 stored by the cache node;

The transaction version number and related routing information stored by the cache node are acquired through a real-time detection database.

Step S1005: according to the comparison result, the cache node determines that no new routing transaction aiming at the target service object is generated in the period, and feeds back a prompt message to the target gateway;

step S1006: after a period of interval, the target gateway sends the latest transaction version number for the service object 1 to the cache node again;

step S1007: the cache node compares the received latest transaction version number aiming at the service object 1 with the latest transaction version number aiming at the service object 1 stored by the cache node;

step S1008: the cache node determines a corresponding increment transaction version number according to the comparison result, and sends the determined increment transaction version number and corresponding routing information to the target gateway;

step S1009: and the target gateway carries out associated storage on the received transaction version number to be pushed and the corresponding service object 1, and updates the latest transaction version number corresponding to the service object 1.

In addition, the target gateway queries the relevant data based on the received routing information.

Based on the same inventive concept, the embodiment of the application also provides a route distribution device. As shown in fig. 11, which is a schematic structural diagram of the route distribution device 1100, may include:

A transmission unit 1101, configured to receive first transaction version information for a target service object, which is reported by an associated target gateway; the target gateway and the storage node serve the same service object set containing target service objects, and each service object set contains at least one service object;

a determining unit 1102, configured to determine, based on the second transaction version information and the first transaction version information of the target service object currently stored, transaction version information to be pushed for the target service object; wherein, each transaction version information corresponds to a routing transaction for characterizing the change of the corresponding routing information;

the pushing unit 1103 is configured to push the version information of the transaction to be pushed and the corresponding routing information to the target gateway.

Optionally, the first transaction version information is the latest transaction version information which is currently stored by the target gateway and aims at the target service object;

the determining unit 1102 is specifically configured to:

taking the latest transaction version information aiming at the target service object in the second transaction version information stored currently as target transaction version information;

Optionally, the apparatus further comprises:

a detection unit 1104 for detecting, in real time, a database for storing metadata of each service object, the metadata including routing information;

Optionally, the transmission unit 1101 is further configured to:

if it is determined to have registration capability for the target gateway, a long connection is established with the target gateway.

Optionally, the transmission unit 1101 is further configured to:

wherein other storage nodes that are currently connectable serve the same set of business objects as the target gateway.

Optionally, each service object corresponds to a service object tree, each tree node in the service object tree represents metadata storage resources of each level corresponding to the service object, and each tree node corresponds to a transaction version information; wherein the metadata comprises routing information;

Based on the same inventive concept, the embodiment of the application also provides a route distribution device. As shown in fig. 12, which is a schematic structural diagram of the route distribution device 1200, may include:

a reporting unit 1201, configured to report, to an associated storage node, first transaction version information for a target service object, so that the storage node determines, based on each currently stored second transaction version information for the target service object and the first transaction version information, transaction version information to be pushed for the target service object; the target gateway and the storage node serve the same service object set containing target service objects, and each service object set contains at least one service object;

The receiving unit 1202 is configured to receive transaction version information to be pushed and corresponding routing information, which are pushed by the storage node, for a target service object.

Optionally, the reporting unit 1201 is further configured to:

before reporting to an associated storage node first transaction version information for a target business object, sending a registration request to the storage node;

if the storage node has registration capability, a long connection is established with the storage node, the registration capability being determined by the storage node based on the number of currently registered gateways.

Optionally, the apparatus further comprises:

a transmission unit 1203, configured to receive connection information of other storage nodes that are currently connectable and sent by the storage node, where the connection information is sent after the storage node determines that the storage node does not have registration capability; the other storage nodes which can be connected at present and the target gateway serve the same service object set;

and sending a registration request to other storage nodes based on the connection information and establishing a long connection.

Optionally, the reporting unit 1201 is specifically configured to:

taking the latest transaction version information which is currently stored and aims at the target service object as first transaction version information;

and reporting the first transaction version information to the storage node through the heartbeat signal.

Because the application adds a storage node between the gateway and the database. And, the storage nodes, the gateway and the business objects are partitioned, and the associated storage nodes and the gateway serve the same business object set. In the method, the storage node stores transaction version information corresponding to the service object served by the storage node, and the gateway reports the transaction version information which is stored currently and can characterize the routing transaction corresponding to the target service object to the associated storage node in real time, so that the storage node can determine the transaction version information to be pushed aiming at the target service object through comparison of the transaction version information, and further pushes the determined transaction version information to be pushed and the corresponding routing information to the target gateway with the transaction as granularity. In the above embodiment, the pressure on the database side is balanced through different storage node scheduling, and even if the data of a huge amount of service objects are stored in the cluster, the data of various types of service objects can be balanced through the partition technology, so that the efficiency of route distribution and route management is improved, and the overall resource utilization rate is improved.

For convenience of description, the above parts are described as being functionally divided into modules (or units) respectively. Of course, the functions of each module (or unit) may be implemented in the same piece or pieces of software or hardware when implementing the present application.

Having described the route distribution method and apparatus of an exemplary embodiment of the present application, next, an electronic device according to another exemplary embodiment of the present application is described.

Those skilled in the art will appreciate that the various aspects of the application may be implemented as a system, method, or program product. Accordingly, aspects of the application may be embodied in the following forms, namely: an entirely hardware embodiment, an entirely software embodiment (including firmware, micro-code, etc.) or an embodiment combining hardware and software aspects may be referred to herein as a "circuit," module "or" system.

The embodiment of the application also provides electronic equipment based on the same conception as the embodiment of the method. In this embodiment, the electronic device may be configured as shown in fig. 13, including a memory 1301, a communication module 1303, and one or more processors 1302.

Memory 1301 is used for storing a computer program executed by processor 1302. The memory 1301 may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, a program required for running an instant communication function, and the like; the storage data area can store various instant messaging information, operation instruction sets and the like.

The memory 1301 may be a volatile memory (RAM) such as a random-access memory (RAM); the memory 1301 may also be a nonvolatile memory (non-volatile memory), such as a read-only memory, a flash memory (flash memory), a hard disk (HDD) or a Solid State Drive (SSD); or memory 1301, is any other medium that can be used to carry or store a desired computer program in the form of instructions or data structures and that can be accessed by a computer, but is not limited thereto. Memory 1301 may be a combination of the above.

The processor 1302 may include one or more central processing units (central processing unit, CPU) or digital processing units, etc. A processor 1302 for implementing the above-described route distribution method when calling the computer program stored in the memory 1301.

The communication module 1303 is used for communicating with the terminal device and other servers.

The specific connection medium between the memory 1301, the communication module 1303 and the processor 1302 is not limited in the embodiment of the present application. The embodiment of the present application is illustrated in fig. 13 by a bus 1304 between a memory 1301 and a processor 1302, where the bus 1304 is illustrated in fig. 13 by a bold line, and the connection between other components is merely illustrative, and not limiting. The bus 1304 may be classified as an address bus, a data bus, a control bus, and the like. For ease of description, only one thick line is depicted in fig. 13, but only one bus or one type of bus is not depicted.

The memory 1301 stores therein a computer storage medium in which computer executable instructions for implementing the route distribution method of the embodiment of the present application are stored. The processor 1302 is configured to perform the route distribution method described above, as shown in fig. 3 or 8.

A computing device 140 according to such an embodiment of the application is described below with reference to fig. 14. The computing device 140 of fig. 14 is only one example and should not be taken as limiting the functionality and scope of use of embodiments of the present application.

As shown in fig. 14, computing device 140 is in the form of a general purpose computing device. Components of computing device 140 may include, but are not limited to: the at least one processing unit 141, the at least one memory unit 142, a bus 143 connecting the different system components, including the memory unit 142 and the processing unit 141.

Bus 143 represents what may be one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a processor, and a local bus using any of a variety of bus architectures.

The storage unit 142 may include readable media in the form of volatile memory, such as Random Access Memory (RAM) 1421 and/or cache memory unit 1422, and may further include Read Only Memory (ROM) 1423.

The storage unit 142 may also include a program/utility 1425 having a set (at least one) of program modules 1424, such program modules 1424 including, but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of which may include an implementation of a network environment.

The computing device 140 may also communicate with one or more external devices 144 (e.g., keyboard, pointing device, etc.), one or more devices that enable a user to interact with the computing device 140, and/or any devices (e.g., routers, modems, etc.) that enable the computing device 140 to communicate with one or more other computing devices. Such communication may occur through an input/output (I/O) interface 145. Moreover, computing device 140 may also communicate with one or more networks, such as a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network, such as the Internet, via network adapter 146. As shown, network adapter 146 communicates with other modules for computing device 140 over bus 143. It should be appreciated that although not shown, other hardware and/or software modules may be used in connection with computing device 140, including, but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, data backup storage systems, and the like.

In some possible embodiments, aspects of the route distribution method provided by the present application may also be implemented in the form of a program product comprising a computer program for causing an electronic device to perform the steps of the route distribution method according to the various exemplary embodiments of the application described herein above when the program product is run on the electronic device, e.g. the electronic device may perform the steps as shown in fig. 3.

The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium can be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium would include the following: an electrical connection having one or more wires, a portable disk, a hard disk, random Access Memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

The program product of embodiments of the present application may take the form of a portable compact disc read only memory (CD-ROM) and comprise a computer program and may be run on an electronic device. However, the program product of the present application is not limited thereto, and in this document, a readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with a command execution system, apparatus, or device.

The readable signal medium may comprise a data signal propagated in baseband or as part of a carrier wave in which a readable computer program is embodied. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A readable signal medium may also be any readable medium that is not a readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with a command execution system, apparatus, or device.

A computer program embodied on a readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Computer programs for performing the operations of the present application may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer program may execute entirely on the user's computing device, partly on the user's computing device, as a stand-alone software package, partly on the user's computing device and partly on a remote computing device or entirely on the remote computing device or server. In the case of remote computing devices, the remote computing device may be connected to the user computing device through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computing device (e.g., connected via the Internet using an Internet service provider).

It should be noted that although several units or sub-units of the apparatus are mentioned in the above detailed description, such a division is merely exemplary and not mandatory. Indeed, the features and functions of two or more of the elements described above may be embodied in one element in accordance with embodiments of the present application. Conversely, the features and functions of one unit described above may be further divided into a plurality of units to be embodied.

Furthermore, although the operations of the methods of the present application are depicted in the drawings in a particular order, this is not required to either imply that the operations must be performed in that particular order or that all of the illustrated operations be performed to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step to perform, and/or one step decomposed into multiple steps to perform.

It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having a computer-usable computer program embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program commands may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the commands executed by the processor of the computer or other programmable data processing apparatus produce means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program commands may also be stored in a computer readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the commands stored in the computer readable memory produce an article of manufacture including command means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

While preferred embodiments of the present application have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. It is therefore intended that the following claims be interpreted as including the preferred embodiments and all such alterations and modifications as fall within the scope of the application.

It will be apparent to those skilled in the art that various modifications and variations can be made to the present application without departing from the spirit or scope of the application. Thus, it is intended that the present application also include such modifications and alterations insofar as they come within the scope of the appended claims or the equivalents thereof.

Claims

1. A method of route distribution, applied to a storage node, the method comprising:

2. The method of claim 1, wherein the first transaction version information is current stored by the target gateway for the most current transaction version information of the target business object;

the determining the transaction version information to be pushed for the target service object based on the second transaction version information and the first transaction version information stored currently for the target service object comprises:

3. The method of claim 1, wherein the method further comprises:

detecting a database for storing metadata of each business object in real time, wherein the metadata comprises routing information;

4. The method of claim 1, further comprising, prior to said receiving the first transaction version information for the target transaction object reported by the associated target gateway:

receiving a registration request sent by the target gateway;

5. The method of claim 4, wherein the method further comprises:

6. The method according to any one of claims 1 to 5, wherein each service object corresponds to a service object tree, each tree node in the service object tree represents metadata storage resources of each level corresponding to the service object, and each tree node corresponds to a transaction version information; wherein the metadata comprises routing information;

7. The method of claim 6, wherein each transaction version information comprises: transaction numbers of corresponding routing transactions, operation serial numbers under corresponding routing transactions; each routing transaction includes at least one operation.

8. A method according to any one of claims 1 to 5, wherein the number of business objects contained in each set of business objects is associated with storage nodes and gateways serving the set of business objects.

9. A method of route distribution, applied to a target gateway, the method comprising:

10. The method of claim 9, further comprising, prior to said reporting to the associated storage node the first transaction version information for the target transaction object:

sending a registration request to the storage node;

11. The method of claim 10, wherein the method further comprises:

receiving connection information of other storage nodes which can be connected currently and are sent by the storage nodes, wherein the connection information is sent after the storage nodes are determined to have no registration capability; wherein the other storage nodes which can be connected at present and the target gateway serve the same service object set;

12. The method according to any of claims 9-11, wherein reporting the first transaction version information for the target transaction object to the associated storage node comprises:

13. A route distribution system, the system comprising: at least one gateway and at least one storage node; the associated storage node and gateway serve the same set of business objects, each set of business objects containing at least one business object;

14. The system of claim 13, wherein the system further comprises a database:

the database is used for storing metadata of each business object and transaction version information corresponding to each business object; the metadata contains routing information;

each storage node is further used for detecting the database in real time; and if the database is determined to generate the routing transaction for the business object, acquiring corresponding second transaction version information and routing information from the database and storing the second transaction version information and the routing information.

15. A route distribution device, comprising:

16. A route distribution device, comprising:

17. An electronic device comprising a processor and a memory, wherein the memory stores a computer program which, when executed by the processor, causes the processor to perform the steps of the method of any of claims 1 to 12.

18. A computer readable storage medium, characterized in that it comprises a computer program for causing an electronic device to perform the steps of the method according to any one of claims 1-12 when said computer program is run on the electronic device.

19. A computer program product comprising a computer program, the computer program being stored on a computer readable storage medium; when the computer program is read from the computer readable storage medium by a processor of an electronic device, the processor executes the computer program, causing the electronic device to perform the steps of the method of any one of claims 1-12.