A routing distribution method and device, electronic equipment and storage medium

Abstract

The application relates to the computer technical field, in particular to a routing distribution method and device, electronic equipment and storage medium, to improve routing distribution efficiency. The method comprises the following steps: receiving first transaction version information of a target service object reported by an associated target gateway; the target gateway and a storage node serve the same service object set containing the target service object; determining to-be-pushed transaction version information of the target service object based on each second transaction version information of the target service object and the first transaction version information; each transaction version information corresponds to a routing transaction used for representing corresponding routing information change; and pushing the to-be-pushed transaction version information and corresponding routing information to the target gateway. Since the application pushes routing information to the target gateway by combining the transaction version information reported by the storage node and the target gateway, and balancing the storage node scheduling, the routing distribution efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more particularly to a routing and distribution method, apparatus, electronic device, and storage medium. Background Technology

[0002] Metadata refers to the metadata used to manage the stored data of business objects. To improve data reliability, metadata can also be divided into layers such as partitions and replicas. A partition's data typically consists of multiple replicas. Routing information refers to all the information needed by the gateway (GW) to locate data replicas (such as the address where the data replicas are stored), and is part of the metadata.

[0003] When a large number of business objects are connected to a massive cluster, how to quickly synchronize routes becomes a problem. As data grows, partitions within the cluster will split and merge, and replicas within the cluster will also migrate and balance, causing the storage addresses corresponding to replicas to change. At this time, it is necessary to update the replica location information cached in the Gateway in a timely manner.

[0004] In related technologies, metadata is stored in the distributed file storage database MongoDB, and each Gateway (GW) retrieves routing information from MongoDB. Due to the large cluster size, with thousands of GW instances, if each GW pulls routing information, it will put significant pressure on MongoDB, easily causing overload and resulting in untimely route updates.

[0005] Therefore, how to achieve efficient and accurate route distribution synchronization is an urgent problem to be solved. Summary of the Invention

[0006] This application provides a route distribution method, apparatus, electronic device, and storage medium to improve the efficiency of route distribution and route management.

[0007] This application provides a routing distribution method applied to a storage node, comprising:

[0008] Receive the first transaction version information for the target business object reported by the associated target gateway; the target gateway and the storage node serve the same set of business objects containing the target business object, and each set of business objects contains at least one business object;

[0009] Based on the currently stored second transaction version information for the target business object and the first transaction version information, the transaction version information to be pushed for the target business object is determined; wherein, each transaction version information corresponds to a routing transaction used to characterize the corresponding routing information change;

[0010] The version information of the transaction to be pushed and the corresponding routing information are pushed to the target gateway.

[0011] Another routing distribution method provided in this application embodiment, applied to a target gateway, includes:

[0012] The first transaction version information for the target business object is reported to the associated storage node, so that the storage node determines the transaction version information to be pushed for the target business object based on the currently stored second transaction version information for the target business object and the first transaction version information; the target gateway and the storage node serve the same set of business objects containing the target business object, and each set of business objects contains at least one business object;

[0013] Receive the transaction version information to be pushed and the corresponding routing information for the target business object pushed by the storage node.

[0014] This application provides a routing and distribution system, including: at least one gateway and at least one storage node; the associated storage node and gateway serve the same set of business objects, and each set of business objects contains at least one business object;

[0015] Each of the storage nodes is configured to receive, from the associated gateway, first transaction version information for a business object in the set of serviced business objects; determine, based on the currently stored second transaction version information for each business object and the first transaction version information, transaction version information to be pushed for the business object; and push the transaction version information to be pushed and corresponding routing information to the associated gateway.

[0016] Each gateway is configured to report the first transaction version information to the associated storage node; and to receive the transaction version information to be pushed and the routing information pushed by the storage node.

[0017] This application provides a routing distribution device, comprising:

[0018] The transmission unit is used to receive the first transaction version information for the target service object reported by the associated target gateway; the target gateway and the storage node serve the same set of service objects containing the target service object, and each set of service objects contains at least one service object;

[0019] The determining unit is configured to determine the transaction version information to be pushed for the target business object based on the currently stored second transaction version information for each target business object and the first transaction version information; wherein, each transaction version information corresponds to a routing transaction used to characterize the corresponding routing information change;

[0020] The push unit is used to push the version information of the transaction to be pushed and the corresponding routing information to the target gateway.

[0021] Optionally, the first transaction version information is the latest transaction version information for the target business object currently stored by the target gateway;

[0022] The determining unit is specifically used for:

[0023] The latest transaction version information for the target business object among the currently stored second transaction version information is taken as the target transaction version information;

[0024] If the first transaction version information is detected to be different from the target transaction version information, the incremental transaction version information determined based on the difference between the first transaction version information and the target transaction version information will be used as the transaction version information to be pushed.

[0025] Optionally, the device further includes:

[0026] The detection unit is used to detect in real time the database used to store metadata of various business objects, the metadata including routing information;

[0027] If it is determined that the database generates a routing transaction for the target business object, then the corresponding second transaction version information and routing information are obtained from the database and stored.

[0028] Optionally, the transmission unit is further configured to:

[0029] Before receiving the first transaction version information for the target business object reported by the associated target gateway, receive the registration request sent by the target gateway;

[0030] Based on the number of currently registered gateways, determine whether there is the ability to register for the target gateway;

[0031] If it is determined that the system has the capability to register with the target gateway, a long-lived connection is established with the target gateway.

[0032] Optionally, the transmission unit is further configured to:

[0033] If it is determined that the target gateway does not have the registration capability, then the connection information of other currently connectable storage nodes is fed back to the target gateway, so that the target gateway can send a registration request to the other storage nodes and establish a long connection based on the connection information;

[0034] Among them, the other currently connectable storage nodes and the target gateway serve the same set of business objects.

[0035] Optionally, each business object corresponds to a business object tree, and each tree node in the business object tree represents the metadata storage resources at each level corresponding to the business object, and each tree node corresponds to a transaction version information; wherein, the metadata includes routing information;

[0036] The transaction version information corresponding to each business object is determined based on the transaction version information corresponding to each tree node in the corresponding business object tree.

[0037] Optionally, each transaction version information includes: the transaction number of the corresponding route transaction, and the operation sequence number under the corresponding route transaction; each route transaction includes at least one operation.

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

[0039] Another routing distribution apparatus provided in this application includes:

[0040] The reporting unit is used to report the first transaction version information of the target business object to the associated storage node, so that the storage node can determine the transaction version information to be pushed for the target business object based on the currently stored second transaction version information of the target business object and the first transaction version information; the target gateway and the storage node serve the same set of business objects containing the target business object, and each set of business objects contains at least one business object;

[0041] The receiving unit is used to receive the transaction version information to be pushed for the target business object and the corresponding routing information pushed by the storage node.

[0042] Optionally, the reporting unit is further configured to:

[0043] Before reporting the first transaction version information for the target business object to the associated storage node, a registration request is sent to the storage node;

[0044] If the storage node has registration capability, a long-lived connection is established with the storage node. The registration capability is determined by the storage node based on the number of currently registered gateways.

[0045] Optionally, the device further includes:

[0046] A transmission unit is used to receive connection information of other currently connectable storage nodes sent by the storage node, wherein the connection information is sent by the storage node after determining that it does not have the registration capability; wherein the other currently connectable storage nodes and the target gateway serve the same set of business objects.

[0047] Based on the connection information, a registration request is sent to the other storage nodes and a long connection is established.

[0048] Optionally, the reporting unit is specifically used for:

[0049] The latest transaction version information currently stored for the target business object is used as the first transaction version information;

[0050] The first transaction version information is reported to the storage node via a heartbeat signal.

[0051] An electronic device provided in this application includes a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of any of the above-described routing and distribution methods.

[0052] This application provides a computer-readable storage medium including a computer program. When the computer program is run on an electronic device, the computer program is used to cause the electronic device to perform the steps of any of the above-described routing and distribution methods.

[0053] This application provides a computer program product, which includes a computer program stored in a computer-readable storage medium. When a processor of an electronic device reads the computer program from the computer-readable storage medium, the processor executes the computer program, causing the electronic device to perform the steps of any of the above-described routing and distribution methods.

[0054] The beneficial effects of this application are as follows:

[0055] This application provides a routing distribution method, apparatus, electronic device, and storage medium. Because this application adds a storage node between the gateway and the database used to store metadata, and partitions the storage node, gateway, and business objects, associated storage nodes and gateways serve the same set of business objects. In this approach, the storage node stores version information (i.e., transaction version information) of the routing transactions corresponding to the business objects it serves. The gateway reports its currently stored transaction version information, which characterizes the routing transactions corresponding to the target business object, to the associated storage node in real time. Thus, by comparing the transaction version information, the storage node can determine the transaction version information to be pushed to the target business object, and then push the determined transaction version information and corresponding routing information to the target gateway at the transaction level. In the above embodiments, the pressure on the database side is balanced through scheduling different storage nodes. Even if the cluster stores massive amounts of business object data, the partitioning technique can balance the data of various types of business objects, improving the efficiency of routing distribution and management, thereby enhancing overall resource utilization.

[0056] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0057] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0058] Figure 1 This is a logical diagram of a route update method in the related technology of this application;

[0059] Figure 2 This is a schematic diagram of an application scenario in an embodiment of this application;

[0060] Figure 3 This is a flowchart illustrating a routing distribution method according to an embodiment of this application;

[0061] Figure 4 This is a schematic diagram of a database instance partition in an embodiment of this application;

[0062] Figure 5 This is a schematic diagram of a metadata structure in an embodiment of this application;

[0063] Figure 6 This is a schematic diagram of a business object tree in an embodiment of this application;

[0064] Figure 7A This is a logical diagram illustrating a route push mechanism in one embodiment of this application;

[0065] Figure 7B This is a logical diagram illustrating another routing push in an embodiment of this application;

[0066] Figure 8 This is a flowchart illustrating another routing distribution method in an embodiment of this application;

[0067] Figure 9 This is a schematic diagram of the structure of a routing distribution system according to an embodiment of this application;

[0068] Figure 10 This is an interaction sequence diagram of a routing distribution method according to an embodiment of this application;

[0069] Figure 11 This is a schematic diagram of the composition structure of a routing distribution device according to an embodiment of this application;

[0070] Figure 12 This is a schematic diagram of the composition structure of another routing distribution device in an embodiment of this application;

[0071] Figure 13 This is a schematic diagram of the composition structure of an electronic device according to an embodiment of this application;

[0072] Figure 14 This is a schematic diagram of the composition structure of a computing device according to an embodiment of this application. Detailed Implementation

[0073] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings of the embodiments of this application. Obviously, the described embodiments are only some embodiments of the technical solutions of this application, and not all embodiments. Based on the embodiments recorded in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the technical solutions of this application.

[0074] The following describes some of the concepts involved in the embodiments of this application.

[0075] Storage node: A storage node is a logical node with caching or storage functions, such as a container group (pod) in a Kubernetes cluster. In this embodiment, the storage node is a node in the caching layer designed between the gateway and the database, used to control the logic of incremental push of routing information.

[0076] Business objects: These refer to the tenants in the cluster, i.e., the users of the cluster. Tenants may be divided by project or different applications. Each tenant is equivalent to a resource pool. The administrator configures certain cluster resources for the tenant, and all users under the tenant (i.e., users of cluster resources) share the resources in the resource pool. Multiple tenants can share a big data cluster.

[0077] Transaction version information: When routing information changes, a corresponding routing transaction (also known as a routing event) is generated. Transaction version information is a unique identifier used to represent the version of the routing transaction. Therefore, each transaction version information corresponds to a routing transaction used to represent the corresponding routing information change.

[0078] Metadata refers to the metadata used to manage the stored data of business objects. Data in any file system is divided into data and metadata. Data refers to the actual data in a regular file, while metadata refers to system data used to describe the characteristics of a file, such as access permissions, file owner, and the distribution information of file data blocks (inodes, etc.). In a clustered file system, distribution information includes the file's location on the disk and the disk's location within the cluster. A business object needing to operate on a file must first obtain its metadata to locate the file and obtain its content or related attributes. In this embodiment, metadata includes, but is not limited to, the name of the data set, various functional attribute settings, and the address where data replicas are stored.

[0079] Routing information (or simply route): This refers to all the information needed by the compute layer (GW) to locate data replicas. For example, the address where the data replicas are stored, the name of the data set, etc. Routing is part of metadata.

[0080] GW: Gateway, also known as a compute and access module. Data access requests from business objects are first sent to the GW. The GW then uses its routing component to parse the requests layer by layer, thereby correctly accessing the data on the disk.

[0081] Partition: This is a space for storing specific data; essentially, it's a folder on the disk where data is stored.

[0082] Replica: The concept of replicas is actually defined at the partition level. Each partition is configured with several replicas, and the data in each replica within the same partition is consistent.

[0083] The routing distribution method in this application also involves cloud storage and database-related technologies:

[0084] Cloud storage is a new concept that extends and develops from the concept of cloud computing. A distributed cloud storage system (hereinafter referred to as a storage system) refers to a storage system that uses cluster applications, grid technology and distributed storage file systems to bring together a large number of storage devices of various types in the network to work together and provide data storage and business access functions to the outside world.

[0085] A database, simply put, can be viewed as an electronic filing cabinet—a place to store electronic files, where users can perform operations such as adding, querying, updating, and deleting data. A "database" is a collection of data stored together in a certain way, capable of being shared by multiple users, with minimal redundancy, and independent of application programs.

[0086] In this embodiment, the database used to store metadata can be a distributed file storage database, such as MongoDB. MongoDB, written in C++, is a product that falls between relational and non-relational databases, and is the most feature-rich and relational-database-like among non-relational databases. It supports very flexible data structures, allowing the storage of complex data types; and its query language is very powerful, with syntax somewhat similar to object-oriented query languages, enabling almost all the functionalities of single-table queries in relational databases, and also supporting the creation of indexes for data.

[0087] In addition, other types of databases can also be used; this article does not make any specific restrictions.

[0088] The design concept of the embodiments of this application is briefly introduced below:

[0089] Metadata refers to system data used to describe the characteristics of a file, such as access permissions, file owner, and the distribution information of file data blocks. In a clustered file system, distribution information includes the file's location on the disk and the disk's location within the cluster. A business object needing to operate on a file must first obtain its metadata to locate the file and retrieve its content or related attributes. The business object's request is first sent to the Gateway (GW), which then uses its routing components to parse the request layer by layer to correctly access the data on the disk.

[0090] In related technologies, metadata is typically stored in MongoDB. See also... Figure 1 The diagram shown is a logical illustration of a route update method in related technologies. Taking MongoDB route update as an example, a brief introduction to a route update method in related technologies is given:

[0091] exist Figure 1 In China, the Gateway primarily updates routes by pulling routing information. Metadata is stored in shards. Figure 1 Three data shards are listed, namely sh0, sh1, and sh2, and the specific process is as follows:

[0092] First, when MongoDB starts up, it pulls routing information from the configuration and caches it.

[0093] To ensure data load balancing, MongoDB supports chunk migration between shards. When a chunk migration occurs, the routing information changes, but not all MongoDB routers are aware of this.

[0094] Therefore, when a user requests data from MongoDB through a client, MongoDB sends the request to the Shards along with the route version number. If the route version carried in the request is too low, the request is rejected, triggering MongoDB to fetch the latest route information from the config.

[0095] In practical applications, due to the large cluster size and thousands of Gateway instances, if each Gateway pulls routing information and the pull interval is too close, MongoDB will be under great pressure and easily overloaded. When the pull interval is too large, it may cause the routing to be updated in a timely manner. In addition, the changes in routing are transactional, and direct pulling may pull intermediate states, requiring the Gateway to perform a lot of shielding logic, which increases the logical complexity of the Gateway.

[0096] In view of this, embodiments of this application propose a routing distribution method, apparatus, electronic device, and storage medium. This application adds a storage node between the gateway and the database. Furthermore, partitioning is performed between the storage node, the gateway, and the business objects, with associated storage nodes and gateways serving the same set of business objects. In this approach, the storage node stores transaction version information corresponding to the business objects it serves, and the gateway reports its currently stored transaction version information, which characterizes the routing transactions corresponding to the target business object, to the associated storage node in real time. Thus, by comparing the transaction version information, the storage node can determine the transaction version information to be pushed for the target business object, and then push the determined transaction version information to be pushed and the corresponding routing information to the target gateway at the transaction granularity. In the above embodiments, the pressure on the database side is balanced through the scheduling of different storage nodes. Even if the cluster stores massive amounts of business object data, the partitioning technique can balance the data of various types of business objects, improving the efficiency of routing distribution and routing management, thereby enhancing overall resource utilization.

[0097] The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0098] like Figure 2 The diagram shown illustrates an application scenario according to an embodiment of this application. The application scenario diagram includes two terminal devices 210 and one server 220.

[0099] In this embodiment, the terminal device 210 includes, but is not limited to, mobile phones, tablets, laptops, desktop computers, e-book readers, smart voice interaction devices, smart home appliances, and in-vehicle terminals. The terminal device may have a client installed, which can be software (e.g., a browser), a webpage, or a mini-program. The server 220 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0100] It should be noted that the routing distribution method in each embodiment of this application can be executed by an electronic device, which can be a terminal device 210 or a server 220. That is, the method can be executed by the terminal device 210 or the server 220 alone, or by the terminal device 210 and the server 220 together.

[0101] The storage nodes, gateway, and database all run on server 220.

[0102] In a multi-tenant architecture, each tenant has its own metadata, and all tenant-related operations are driven by this metadata. During metadata usage, each time a terminal device uses the data, it must query and perform calculations from the database. Each tenant represents a business object.

[0103] The following is a brief introduction to the routing distribution method in this embodiment, using the joint execution of terminal device 210 and server 220 as an example:

[0104] The client sends a data access request to the gateway in the server 220 through the terminal device 210. The gateway can then parse the data access request layer by layer based on its own routing component, thereby correctly accessing the data on the disk. Accessing the data requires corresponding routing information (part of metadata). After obtaining the relevant data based on the routing information, it can be fed back to the relevant client through the terminal device 210.

[0105] To ensure the timeliness of routing information, the target gateway can establish a long connection with the associated storage node upon startup and report the latest transaction version information for the target business object (client) to the storage node. After receiving the latest transaction version information sent by the target gateway, the storage node compares it with the transaction version information currently stored for the target business object to determine the transaction version information to be pushed for the target business object. Then, the storage node pushes the determined transaction version information to be pushed, along with the corresponding routing information, to the target gateway.

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

[0107] In addition, the target gateway can also associate the received push transaction version information with the corresponding target business object and store it, and update the latest transaction version information corresponding to the target business object.

[0108] The transaction version information and routing information of the business objects stored in the storage nodes are obtained from the database through real-time monitoring.

[0109] In one alternative implementation, the terminal device 210 and the server 220 can communicate via a communication network.

[0110] In one alternative implementation, the communication network is a wired network or a wireless network.

[0111] It should be noted that, Figure 2 The examples shown are merely illustrative; in reality, the number of terminal devices and servers is unlimited and is not specifically limited in the embodiments of this application.

[0112] In this embodiment of the application, when there are multiple servers, the multiple servers can form a blockchain, and the servers are nodes on the blockchain; as disclosed in the routing distribution method of this embodiment, the metadata, transaction version information, etc. involved can be stored on the blockchain, such as first transaction version information, second transaction version information, routing information, etc.

[0113] Furthermore, the embodiments of this application can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, and assisted driving.

[0114] The routing distribution method provided by the exemplary embodiments of this application will be described below with reference to the accompanying drawings and the application scenarios described above. It should be noted that the application scenarios described above are only shown to facilitate understanding of the spirit and principles of this application, and the embodiments of this application are not limited in any way.

[0115] See Figure 3 The diagram shown is a flowchart of a routing distribution method provided in an embodiment of this application, applied to a storage node. The specific implementation flow of this method is as follows: S31-S33:

[0116] S31: The storage node receives the first transaction version information for the target business object reported by the associated target gateway.

[0117] The target gateway and the storage node serve the same set of business objects containing the target business objects, and each set of business objects contains at least one business object.

[0118] In this embodiment, the storage node is a logical node with caching or storage functions, such as a pod in a Kubernetes cluster. Specifically, this storage node is a node in the caching layer designed between the gateway and the database in this application, used to control the logic of incremental push of routing information.

[0119] Considering that in related technologies, when the cluster size is large, there are often many gateways simultaneously pulling routing information from MongoDB, leading to high pressure on MongoDB and potential overload. Therefore, this application proposes a database instance partitioning approach.

[0120] Specifically, storage nodes and gateways are grouped according to business objects, and each group of storage nodes and gateways only processes specific business objects. Storage nodes and gateways assigned to the same group are associated with each other, and therefore, associated storage nodes and gateways serve the same set of business objects.

[0121] Optionally, the number of business objects contained in each business object set is associated with the storage nodes and gateways serving the business object set, so as to realize partition management for tenants of different sizes.

[0122] In this embodiment, a group of storage nodes and gateways used to serve business objects can be referred to as a service set, where each storage node in the service set is associated with a gateway. For example, the number of storage nodes and gateways in each group is set to be the same, meaning that each service set can serve the same number of tenants.

[0123] like Figure 4 The diagram shown illustrates a database instance partitioning scheme in an embodiment of this application. For example, there are 10 business objects and 3 sets consisting of gateways and storage nodes. Each service set contains four gateways and two storage nodes. Business object 1 is a large tenant, business objects 2-4 are three medium tenants, and business objects 5-10 are six small tenants. Based on this, and considering that the number of gateways and storage nodes is consistent across each service set, the following can be configured: 1) Service set 1 and the service object set 1 containing only business object 1 form a group, meaning that the four gateways and two storage nodes in service set 1 all serve business object 1; 2) Service set 2 and the service object set 2 consisting of business objects 2-4 form a group, meaning that the four gateways and two storage nodes in service set 2 jointly serve business objects 2-4; 3) Service set 3 and the service object set 3 consisting of business objects 5-10 form a group, meaning that the four gateways and two storage nodes in service set 3 jointly serve business objects 5-10.

[0124] It should be noted that the above example uses a balanced partitioning of service sets. Of course, unbalanced partitioning is also possible, such as service set 1 containing two gateways and one storage node; service set 2 containing four gateways and two storage nodes, and so on. In practice, the partitioning method of service sets can be flexibly set according to the actual situation. In addition, the number of gateways and storage nodes in each service set can be in a certain ratio, etc., which are not specifically limited in this article.

[0125] In the above implementation, through partitioned management, larger tenants can have independent gateway and storage node services, ensuring resource isolation and improving routing efficiency. For a large number of small tenants, resource utilization is improved by sharing services.

[0126] Optionally, before executing step S31, 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 business object reported by the associated target gateway, the storage node will also receive a registration request sent by the target gateway.

[0127] In this embodiment of the application, the target gateway can select an associated storage node to register upon startup, and the specific process is as follows:

[0128] The target gateway selects an associated storage node and sends a registration request to that storage node to request the establishment of a connection. After receiving the registration request, the storage node determines whether it has the ability to register with the target gateway based on the number of currently registered gateways.

[0129] In this embodiment, a certain ratio can be set between gateways and storage nodes within the same service set. This ensures a more balanced number of gateways that each storage node can serve within the same service set. Consequently, storage nodes know how many gateways they are serving and how many gateways need their services.

[0130] When a storage node determines that it has the ability to register with the target gateway, it means that the number of gateways currently connected to the storage node has not yet reached the upper limit, and it can establish communication with the target gateway, thus establishing a long connection with the target gateway.

[0131] For example, service set 2 has four gateways (gateways 1-4) and two storage nodes (storage nodes a and b). The target gateway, gateway 1, sends a registration request to storage node a. Currently, storage node a is only connected to gateway 2. Therefore, storage node a also has the ability to register with the target gateway and establishes a long connection with gateway 1.

[0132] Optionally, if the number of gateways currently connected to the storage node reaches the upper limit, it can be determined that it does not have the registration capability for the target gateway. In this case, the storage node will send the connection information of other currently connectable storage nodes back to the target gateway, so that the target gateway can send registration requests to other storage nodes and establish long connections based on the connection information. Then, the target gateway can communicate with other storage nodes that have established connections, report the first transaction version information, and receive the transaction version information to be pushed and the corresponding routing information from the other storage nodes.

[0133] The connection information refers to the identifiers and connection addresses of other currently connectable storage nodes. In this step, the target gateway may receive one or more currently connectable storage nodes; this document does not specify a particular number.

[0134] Furthermore, the other currently connectable storage nodes serve the same set of business objects as the target gateway. In this embodiment, the storage node can report other associated storage nodes to the target gateway, and these other storage nodes are connectable, i.e., they have the ability to register with the target gateway.

[0135] Taking service set 2 above as an example, for instance, the target gateway - gateway 1 - sends a registration request to storage node a. However, the current gateways connected to storage node a are gateway 2 and gateway 3. Therefore, storage node a does not have the ability to register with the target gateway. Meanwhile, the associated storage node b is currently only connected to gateway 4. Thus, storage node b can be regarded as "other currently connectable storage nodes". The connection information of storage node b is fed back to gateway 1. Then, gateway 1 sends a registration request to storage node b and establishes a long connection with storage node b.

[0136] In this embodiment, the target gateway can periodically report the first transaction version information corresponding to each business object it serves to the storage node. Therefore, the target business object can be any one or more objects in the set of business objects served by the target gateway, or one or more specified objects, which is not specifically limited herein.

[0137] Optionally, the target gateway may report the first transaction version information to the storage node via a heartbeat signal.

[0138] Specifically, the target gateway sends the first transaction version information for the target business object to the interconnected storage nodes at regular intervals to update the routing in a timely manner.

[0139] For example, at time T1, the target gateway sends the latest transaction version information for the target business object currently stored as V1 to the storage node via a heartbeat signal; at time T2, the target gateway sends the latest transaction version information for the target business object currently stored as V2 to the storage node via a heartbeat signal, and so on.

[0140] S32: Based on the currently stored second transaction version information for each target business object, and the first transaction version information, the storage node determines the transaction version information to be pushed for the target business object.

[0141] Each transaction version information corresponds to a routing transaction that represents the corresponding routing information change, such as a partition splitting or merging within the cluster, or a replica migration and balancing within the cluster.

[0142] Optionally, the first transaction version information is the latest transaction version information for the target business object currently stored by the target gateway; step S32 further includes the following sub-steps S321-S322 ( Figure 3 (Not shown):

[0143] S321: The storage node will take the latest transaction version information for the target business object from the currently stored second transaction version information as the target transaction version information;

[0144] S322: If the storage node detects that the first transaction version information is different from the target transaction version information, it will use the incremental transaction version information determined based on the difference between the first transaction version information and the target transaction version information as the transaction version information to be pushed.

[0145] For example, at time T1, the latest transaction version information for the target business object currently stored on the target gateway side is V1, while the latest transaction version information for the same target business object currently stored on the storage node side is V2. That is, the first transaction version information for the target business object is V1, and the target transaction version information is V2. Clearly, the first transaction version information and the target transaction version information are inconsistent. In this case, the storage node can determine the corresponding incremental transaction version information as V2 based on the difference between the first and target transaction version information; that is, the transaction version information to be pushed is V2.

[0146] Optionally, if the storage node detects that the version information of the first transaction is the same as the version information of the target transaction, it indicates that no new routing transaction for the target business object has been generated within this period. Then, it can send a prompt message to the target gateway to indicate that no routing update is required.

[0147] Alternatively, no feedback may be sent to the target gateway. If the target gateway does not receive the pending transaction version information or prompt message from the storage node within a certain period after sending the heartbeat signal, it can be determined that no routing update is required for that period.

[0148] It should be noted that the above methods are merely illustrative examples, and any feedback method is applicable to the embodiments of this application, without any specific limitations.

[0149] In the above implementation, the transactional nature of route changes is taken into account. Incremental route push is performed to the gateway at the transaction granularity. Compared with the method of the gateway pulling route information in related technologies, the occurrence of intermediate states can be effectively avoided. Therefore, there is no need for the gateway to perform a lot of shielding logic, and there is no need to increase the logical complexity of the gateway.

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

[0151] In this embodiment, the target gateway can query relevant data based on the received routing information. The routing information refers to all the information needed by the gateway to locate the data replica, such as the address where the data replica is stored and the name of the data set.

[0152] In addition, after receiving the transaction version information to be pushed, the target gateway will also associate and store the transaction version information to be pushed with the corresponding target business object, and update the latest transaction version information corresponding to the target business object.

[0153] Taking the above example, after receiving the transaction version information to be pushed, the target gateway can update the latest transaction version information corresponding to the target business object to V2.

[0154] At time T2, the latest transaction version information for the target business object currently stored on the target gateway side is V2, while the latest transaction version information for the same target business object currently stored on the storage node side is V4. This means the first transaction version information for the target business object is V2, and the target transaction version information is V4. Therefore, the storage node can determine that the corresponding incremental transaction version information is V3 and V4; that is, the transaction version information to be pushed is V3 and V4.

[0155] After receiving the aforementioned transaction version information to be pushed, the target gateway can update the latest transaction version information corresponding to the target business object to V4.

[0156] In the above embodiments, a storage node is added between the gateway and the database. Furthermore, partitioning is performed between the storage node, the gateway, and the business objects, with associated storage nodes and gateways serving the same set of business objects. In this approach, the storage node stores the version information (i.e., transaction version information) of the routing transactions corresponding to the business objects it serves. The gateway reports its currently stored transaction version information, which characterizes the routing transactions corresponding to the target business object, to the associated storage node in real time. Thus, by comparing the transaction version information, the storage node can determine the transaction version information to be pushed to the target business object. Then, at the transaction level, it pushes the determined transaction version information to be pushed and the corresponding routing information to the target gateway. In the above embodiments, the pressure on the database side is balanced through the scheduling of different storage nodes. Even if the cluster stores massive amounts of business object data, the partitioning technique can balance the data of various types of business objects, improving the efficiency of routing distribution and management, thereby enhancing overall resource utilization.

[0157] Optionally, the storage node also needs to monitor the database used to store metadata for each business object in real time. The metadata includes routing information. If it is determined that the database has generated a routing transaction for the target business object, the corresponding second transaction version information and routing information are obtained from the database and stored.

[0158] like Figure 5 As shown, it is a schematic diagram of a metadata structure in an embodiment of this application.

[0159] in, Figure 5 The metadata shown is divided into 5 levels, from top to bottom: Account, KeySpace, Collection, Partition, and Replica.

[0160] In this structure, Account is the instance visible to the business object, KeySpace is the namespace of the data collection, and Collection is the data collection (similar to the concept of a database table). These three layers are visible to the business object, while the Partition and Replica layers are not.

[0161] A collection can be divided into multiple partitions by a partitioning policy set by the business object, allowing for horizontal scaling of the collection's size. The data within a partition is stored on disk using a Raft group consisting of three redundant replicas. A crucial piece of information in the replica's metadata is the disk address where the replica is stored.

[0162] In practical applications, all metadata related to the entire cloud storage product can be stored in MongoDB according to the above hierarchical structure. Each node corresponds to an independent document record.

[0163] In light of the aforementioned metadata structure, and to address the transaction issues in routed push notifications and better implement incremental push notifications, this application designs a transaction version information mechanism based on the business object Account.

[0164] In this embodiment of the application, each business object corresponds to a business object tree, and each tree node in the business object tree represents the metadata storage resources at each level corresponding to the business object. Each tree node corresponds to a transaction version information. The transaction version information corresponding to each business object is determined based on the transaction version information corresponding to each tree node in the corresponding business object tree.

[0165] The metadata includes routing information.

[0166] See Figure 6 As shown, this is a schematic diagram of a business object tree in an embodiment of this application. Figure 6 As shown, this application uses Account as a unit and designs a transaction version information for each Account, denoted as RouteVer.

[0167] The AccountTree is a tree structure that uses related metadata storage resources at various levels as tree nodes, combined with... Figure 5 The metadata structure shown consists of various levels of metadata storage resources (i.e., DB Resource resources) – Account, KeySpace, Collection, and Partition – forming an AccountTree. Each tree node has its own RouteVersion, and the RouteVersion of the AccountTree is determined based on the RouteVersions of the tree nodes it contains.

[0168] Optionally, each transaction version information includes: the transaction number of the corresponding route transaction, and the operation sequence number under the corresponding route transaction; each route transaction includes at least one operation. Based on this, the transaction version information can also be called the transaction version number or the route version number.

[0169] RouteVer: {Mm}, where M represents a transaction and m represents the sequence number of the operation within that transaction.

[0170] Based on the premise that each routing transaction contains at least one operation, the RouteVer of an AccountTree is the maximum value of all the tree nodes it contains, which represents the RouteVer corresponding to the last operation under the latest routing transaction.

[0171] exist Figure 6 The document lists three steps, each corresponding to a routing transaction. The following section provides a detailed explanation of each step:

[0172] for example Figure 6 Step 1: Create an Account. The entire routing transaction consists of one operation, so the corresponding transaction number is 1 and the corresponding operation sequence number is 0. Together, they form the transaction version information (RouteVer) for the routing transaction in Step 1: Ver1.0.

[0173] In step 1, the RouteVer of the AccountTree is Ver1.0.

[0174] For example Figure 6 Step 2: Under the Accunt in Step 1, create KeySpace. The entire routing transaction also consists of only one operation. Therefore, the corresponding transaction number is 2 and the corresponding operation sequence number is 0. Combined, they form the transaction version information (RouteVer) for the routing transaction in Step 2: Ver2.0.

[0175] In step 2, the RouteVer of the AccountTree is Ver2.0.

[0176] For example Figure 6Step 3: Under the KeySpace of Step 2, a Collection is created. This Collection consists of two Partitions. The entire routing transaction comprises three operations (i.e., sub-steps): creating the Collection and creating the two Partitions. All three operations have a transaction number of 3, but their sequence numbers differ. Therefore, the Collection's RouteVer is 3.0, and its two Partitions are 3.1 and 3.2 respectively. The entire 3.x routing transaction is pushed together upon completion, rather than a separate sub-step, to avoid intermediate routing states (such as situations where only some Partitions are successfully created).

[0177] In step 3, the RouteVer of the AccountTree is Ver3.2.

[0178] In the above implementation, the transaction version information of the business object is represented by a tree structure, and incremental route push is realized based on the route version number tree structure.

[0179] Since the metadata listed in this article is stored in MongoDB, this application utilizes MongoDB's ChangeStream feature for route push. ChangeStream is MongoDB's solution for implementing change detection, similar to triggers in relational databases. It provides a simple interface for businesses to obtain real-time database data changes, while also being more secure and convenient.

[0180] Considering the performance limitations of MongoDB's ChangeStream (it cannot handle too many streams), and the large clusters with their massive data volumes, numerous accounts, and a large number of gateways, this application designs a hierarchical routing and partitioned push mechanism to improve the overall performance and efficiency of the push process.

[0181] The routing push mechanism related to storage nodes in this embodiment will be described in detail below with reference to the accompanying drawings:

[0182] See Figure 7A As shown, it is a logical diagram of a routing push in an embodiment of this application. Figure 7AThe system is divided into three parts: the control plane, the data plane, and the MongoDB database. The control plane refers to the part of the system used to transmit instructions and calculate table entries. In this embodiment, the route change operator (RouteChange OP) of the control plane is used to control route updates and is divided into system administration (System Admin), workflow, and resource management (Resource Mgr). System Admin manages instructions for business objects, Workflow corresponds to the related processes of instructions, and Resource Mgr involves interaction with MongoDB. Specifically, Resource Mgr mainly manages transaction modifications, routing events, and related metadata (referred to as events and metadata). Figure 7A The Transaction ModifyEvent & Meta. (For example, combining...) Figure 6 As shown in step 3, when a business object needs to create a data collection, System Admin mainly manages the relevant creation commands, the Workflow part executes the command-related operations, and finally, the Resource Mgr generates the corresponding transaction version information based on the above route changes and notifies MongoDB. The relevant metadata is stored in the MetaStorage part of MongoDB, and the relevant transaction version information is stored in the RouteEvent part of MongoDB.

[0183] The data plane, also known as the user plane, refers to the part of the device that forwards and processes user services based on instructions generated by the control plane. In this embodiment, the interaction between the gateway and the storage node is mainly completed on the data plane.

[0184] Specifically, this application is in GW (i.e. Figure 7A Between the Gateway and MongoDB, a resource cache layer was designed to control the incremental push logic. This layer contains multiple ResourceCaches, i.e., storage nodes. Figure 7A This is an example of a logical node with caching functionality, also known as a cache node.

[0185] When GW starts up, it will select an associated Resource Cache to register (i.e., Figure 7AThe Register (in the database) reports the latest transaction version number (i.e., first transaction version information) of all Accounts it currently manages to the Resource Cache via heartbeat and maintains a long connection to wait for the route to be pushed. The Resource Cache, in turn, detects MongoDB (i.e.,...) through ChangeStream. Figure 7A In the Watch mechanism, whenever a routing event occurs, such as creating a Collection, splitting a Partition, or merging a Partition, incremental route pushes and related metadata pushes are sent to the GW at the transaction level. Figure 7A (DeltaPush in MongoDB). When there is new transaction version information in the RouteEvent of MongoDB, it will notify (i.e., notify) the cache node, and the cache node will pull the relevant metadata from the MetaStorage in MongoDB (i.e., pull Meta).

[0186] exist Figure 7A In the diagram, the two white gateways and the white cache node belong to the same service set, and the black gateways and the black cache node belong to the same service set. Figure 7A This is illustrated using the example of each service set containing one cache node.

[0187] See Figure 7B As shown, this is a logical diagram of another routing push in an embodiment of this application. Figure 7B In the example, the two white gateways and the white cache node belong to the same service set, and the black gateway and the black cache node belong to the same service set. Figure 7A The difference is, Figure 7B The example below uses the case where each service set contains multiple cache nodes; the other logic is the same, and the repeated parts will not be repeated.

[0188] In the above implementation, the method of improving subscription push capability through layered design and reducing the amount of data pushed by routing through database instance partitioning can effectively improve subscription push capability.

[0189] See Figure 8 The diagram shown is a flowchart of another routing distribution method provided in this application embodiment, applied to a target gateway. The specific implementation process of this method is as follows:

[0190] S81: The target gateway reports the first transaction version information for the target business object to the associated storage node, so that the storage node can determine the transaction version information to be pushed for the target business object based on the currently stored second transaction version information for the target business object and the first transaction version information.

[0191] The target gateway and storage node serve the same set of business objects containing the target business objects, and each set of business objects contains at least one business object.

[0192] Optionally, a communication connection needs to be established between the target gateway and the storage node before executing step S81. In this embodiment, the target gateway can select an associated storage node to register upon startup, as follows:

[0193] The target gateway selects an associated storage node and sends a registration request to that storage node. Upon receiving the registration request, the storage node determines whether it has the registration capability for the target gateway based on the number of gateways it currently has registered. If it determines that the storage node has the registration capability, a long-lived connection is established with the storage node. For specific implementation details, please refer to the above embodiments; repeated details will not be elaborated further.

[0194] Optionally, if the storage node does not have the ability to register with the target gateway, it can send connection information of other currently connectable storage nodes to the target gateway. After receiving the connection information, the target gateway sends registration requests to other storage nodes and establishes long connections based on the connection information. For specific implementation details, please refer to the above embodiments. Repeated details will not be repeated.

[0195] After the target gateway establishes a long connection with the storage node, it can report the first transaction version information for the target business object to the associated storage node.

[0196] Optionally, this reporting operation can be performed periodically, meaning the target gateway can periodically report the first transaction version information corresponding to each business object it serves to the storage node. The target business object can be any one or more objects in the set of business objects served by the target gateway, or one or more specified objects; this document does not impose specific limitations.

[0197] Specifically, the following operations are performed during each periodic reporting process:

[0198] First, the target gateway needs to use the latest transaction version information currently stored for the target business object as the first transaction version information; then, it needs to report this first transaction version information to the storage node through a heartbeat signal.

[0199] Taking the target business objects as an example, which include business object 3 and business object 4:

[0200] For example, at time T1, the latest transaction version information for business object 3 stored by the target gateway is V3-1, and the latest transaction version information for business object 4 is V4-2. Therefore, the target gateway can report V3-1 as the first transaction version information corresponding to business object 3 and V4-2 as the first transaction version information corresponding to business object 4 to the relevant storage node through a heartbeat signal.

[0201] At time T2, the latest transaction version information stored on the target gateway side is V3-2 for business object 3 and V4-2 for business object 4. Therefore, the target gateway can use V3-2 as the first transaction version information corresponding to business object 3 and V4-2 as the first transaction version information corresponding to business object 4, respectively, and report them to the relevant storage nodes via heartbeat signals. T1 and T2 are separated by a preset period.

[0202] It should be noted that the above example is based on the gateway's periodic reporting. Other reporting methods are also applicable to the embodiments of this application, such as non-periodic reporting, and are not specifically limited in this document.

[0203] S82: The target gateway receives the transaction version information and corresponding routing information to be pushed for the target business object from the storage node.

[0204] In this embodiment, the target gateway can query relevant data based on the received routing information. Furthermore, upon receiving the transaction version information to be pushed, it can associate and store the transaction version information with the corresponding target business object, and update the latest transaction version information corresponding to the target business object. Specific implementation details can be found in the above embodiments; repeated details will not be elaborated further.

[0205] The routing distribution system in the embodiments of this application is briefly described below:

[0206] like Figure 9 The diagram shown is a structural schematic of a routing distribution system according to an embodiment of this application. The routing distribution system 900 includes: at least one gateway 910 and at least one storage node 920; the associated storage node and the gateway serve the same set of business objects, and each set of business objects contains at least one business object.

[0207] Each storage node 920 is used to receive the first transaction version information of the business objects in the set of business objects it serves, reported by the associated gateway 910; determine the transaction version information to be pushed for the business objects based on the second transaction version information of each business object currently stored, as well as the first transaction version information; and push the transaction version information to be pushed and the corresponding routing information to the associated gateway 910.

[0208] Each gateway 910 is used to report the first transaction version information to the associated storage node; and to receive the pending transaction version information and routing information pushed by the storage node 920.

[0209] Optionally, the system also includes database 930:

[0210] Database 930 is used to store metadata for each business object and transaction version information corresponding to each business object; the metadata includes routing information.

[0211] Each storage node 920 is also used to monitor the database 930 in real time; if it is determined that the database 930 has generated a routing transaction for a business object, the corresponding second transaction version information and routing information are obtained from the database 930 and stored.

[0212] It should be noted that the specific implementation methods of the above storage nodes and gateways can be found in the above embodiments, and repeated details will not be repeated.

[0213] The following uses a storage node as an example, specifically a logical node with caching functionality, referred to as a cache node, to briefly illustrate the interaction process between the gateway and the cache node in this embodiment:

[0214] See Figure 10 The diagram shown is an interaction sequence diagram of a routing distribution method in an embodiment of this application. The specific implementation process of this method is as follows:

[0215] Step S1001: The target gateway selects an associated cache node and sends a registration request to that cache node;

[0216] Step S1002: The cache node establishes a long connection with the target gateway;

[0217] Step S1003: The target gateway sends the latest transaction version number of business object 1 to the cache node via a heartbeat signal;

[0218] Step S1004: The cache node compares the latest transaction version number received for business object 1 with the latest transaction version number for business object 1 stored in its own cache.

[0219] The transaction version number and related routing information stored by the cache node itself are obtained by real-time database monitoring.

[0220] Step S1005: If the cache node determines, based on the comparison results, that no new routing transactions for the target service object have been generated within the period, it will send a prompt message to the target gateway.

[0221] Step S1006: After a period of time, the target gateway sends the latest transaction version number for business object 1 to the cache node again;

[0222] Step S1007: The cache node compares the latest transaction version number received for business object 1 with the latest transaction version number for business object 1 stored in its own cache.

[0223] Step S1008: The cache node determines the corresponding incremental transaction version number based on the comparison result, and sends the determined incremental transaction version number and the corresponding routing information to the target gateway.

[0224] Step S1009: The target gateway associates the received transaction version number to be pushed with the corresponding business object 1 and stores it, and updates the latest transaction version number corresponding to business object 1.

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

[0226] Based on the same inventive concept, embodiments of this application also provide a routing distribution device. For example... Figure 11 As shown, this is a schematic diagram of the routing distribution device 1100, which may include:

[0227] Transmission unit 1101 is used to receive the first transaction version information for the target service object reported by the associated target gateway; the target gateway and the storage node serve the same set of service objects containing the target service object, and each set of service objects contains at least one service object;

[0228] The determining unit 1102 is used to determine the transaction version information to be pushed for the target business object based on the currently stored second transaction version information for each target business object and the first transaction version information; wherein, each transaction version information corresponds to a routing transaction used to represent the corresponding routing information change;

[0229] The push unit 1103 is used to push the transaction version information to be pushed and the corresponding routing information to the target gateway.

[0230] Optionally, the first transaction version information is the latest transaction version information for the target business object currently stored by the target gateway;

[0231] The determining unit 1102 is specifically used for:

[0232] The latest transaction version information for the target business object among the currently stored second transaction version information is used as the target transaction version information;

[0233] If the first transaction version information is detected to be different from the target transaction version information, the incremental transaction version information determined based on the difference between the first transaction version information and the target transaction version information will be used as the transaction version information to be pushed.

[0234] Optionally, the device also includes:

[0235] The detection unit 1104 is used to detect in real time the database used to store metadata of various business objects, and the metadata includes routing information;

[0236] If it is determined that the database generates a routing transaction for the target business object, then the corresponding second transaction version information and routing information are retrieved from the database and stored.

[0237] Optionally, the transmission unit 1101 is also used for:

[0238] Before receiving the first transaction version information for the target business object reported by the associated target gateway, receive the registration request sent by the target gateway;

[0239] Based on the number of currently registered gateways, determine whether there is the ability to register for the target gateway;

[0240] If it is determined that the system has the capability to register with the target gateway, a long-lived connection is established with the target gateway.

[0241] Optionally, the transmission unit 1101 is also used for:

[0242] If it is determined that there is no registration capability for the target gateway, the connection information of other currently connectable storage nodes is fed back to the target gateway, so that the target gateway can send registration requests to other storage nodes and establish long connections based on the connection information;

[0243] Among them, the other storage nodes that can be connected currently serve the same set of business objects as the target gateway.

[0244] Optionally, each business object corresponds to a business object tree, and each tree node in the business object tree represents the metadata storage resources at each level corresponding to the business object. Each tree node corresponds to a transaction version information; wherein, the metadata includes routing information.

[0245] The transaction version information corresponding to each business object is determined based on the transaction version information corresponding to each tree node in the corresponding business object tree.

[0246] Optionally, each transaction version information includes: the transaction number of the corresponding route transaction, and the operation sequence number under the corresponding route transaction; each route transaction includes at least one operation.

[0247] Optionally, the number of business objects contained in each business object set is associated with the storage nodes and gateways serving the business object sets.

[0248] Based on the same inventive concept, embodiments of this application also provide a routing distribution device. For example... Figure 12 As shown, this is a schematic diagram of the routing distribution device 1200, which may include:

[0249] The reporting unit 1201 is used to report the first transaction version information of the target business object to the associated storage node, so that the storage node can determine the transaction version information to be pushed for the target business object based on the second transaction version information of each target business object currently stored, as well as the first transaction version information; the target gateway and the storage node serve the same set of business objects containing the target business object, and each set of business objects contains at least one business object;

[0250] The receiving unit 1202 is used to receive the transaction version information to be pushed for the target business object and the corresponding routing information pushed by the storage node.

[0251] Optionally, the reporting unit 1201 is also used for:

[0252] Before reporting the first transaction version information for the target business object to the associated storage node, a registration request is sent to the storage node.

[0253] If a storage node has registration capabilities, a long-lived connection will be established with the storage node. The registration capability is determined by the storage node based on the number of currently registered gateways.

[0254] Optionally, the device also includes:

[0255] The transmission unit 1203 is used to receive connection information of other currently connectable storage nodes sent by the storage node. The connection information is sent by the storage node after it determines that it does not have the registration capability. The other currently connectable storage nodes and the target gateway serve the same set of business objects.

[0256] Based on the connection information, a registration request is sent to other storage nodes and a long connection is established.

[0257] Optionally, reporting unit 1201 is specifically used for:

[0258] Use the latest transaction version information currently stored for the target business object as the first transaction version information;

[0259] The first transaction version information is reported to the storage node via a heartbeat signal.

[0260] This application adds a storage node between the gateway and the database. Furthermore, partitioning is implemented between the storage node, the gateway, and the business objects, with associated storage nodes and gateways serving the same set of business objects. In this approach, the storage node stores the transaction version information corresponding to the business objects it serves. The gateway reports its currently stored transaction version information, which represents the routing transactions corresponding to the target business object, to the associated storage node in real time. Thus, by comparing the transaction version information, the storage node can determine the transaction version information to be pushed for the target business object. Then, at the transaction level, it pushes the determined transaction version information to be pushed and the corresponding routing information to the target gateway. In the above implementation, the pressure on the database side is balanced through the scheduling of different storage nodes. Even if the cluster stores massive amounts of business object data, the partitioning technique can balance the data of various types of business objects, improving the efficiency of routing distribution and management, thereby enhancing overall resource utilization.

[0261] For ease of description, the above sections are divided into modules (or units) according to their functions and described separately. Of course, in implementing this application, the functions of each module (or unit) can be implemented in one or more software or hardware components.

[0262] Having introduced the routing distribution method and apparatus according to exemplary embodiments of this application, we will now introduce an electronic device according to another exemplary embodiment of this application.

[0263] Those skilled in the art will understand that various aspects of this application can be implemented as a system, method, or program product. Therefore, various aspects of this application can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, collectively referred to herein as a "circuit," "module," or "system."

[0264] Based on the same inventive concept as the above-described method embodiments, this application also provides an electronic device. In this embodiment, the structure of the electronic device can be as follows: Figure 13 As shown, it includes a memory 1301, a communication module 1303, and one or more processors 1302.

[0265] The memory 1301 is used to store computer programs executed by the processor 1302. The memory 1301 may mainly include a program storage area and a data storage area. The program storage area may store the operating system and programs required to run instant messaging functions, etc.; the data storage area may store various instant messaging information and operation instruction sets, etc.

[0266] Memory 1301 may be volatile memory, such as random-access memory (RAM); memory 1301 may also be non-volatile memory, such as read-only memory, flash memory, hard disk drive (HDD), or solid-state drive (SSD); or memory 1301 may be any other medium capable of carrying or storing a desired computer program having the form of instructions or data structures and accessible by a computer, but is not limited thereto. Memory 1301 may be a combination of the above-described memories.

[0267] Processor 1302 may include one or more central processing units (CPUs) or digital processing units, etc. Processor 1302 is used to implement the above-described routing and distribution method when calling computer programs stored in memory 1301.

[0268] The communication module 1303 is used to communicate with terminal devices and other servers.

[0269] This application embodiment does not limit the specific connection medium between the memory 1301, communication module 1303, and processor 1302. This application embodiment... Figure 13 The memory 1301 and the processor 1302 are connected via a bus 1304, and the bus 1304 is in Figure 13 The diagram uses thick lines to describe the connections between other components; these are for illustrative purposes only and should not be considered limiting. The 1304 bus can be divided into address bus, data bus, control bus, etc. For ease of description, Figure 13 It is described using only a thick line, but does not indicate that there is only one bus or one type of bus.

[0270] The memory 1301 stores a computer storage medium, which stores computer-executable instructions for implementing the routing distribution method of this application embodiment. The processor 1302 is used to execute the above-described routing distribution method, such as... Figure 3 or Figure 8 As shown.

[0271] The following reference Figure 14 To describe a computing device 140 according to this embodiment of the present application. Figure 14 The computing device 140 is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0272] like Figure 14 The computing device 140 is manifested in the form of a general-purpose computing device. The components of the computing device 140 may include, but are not limited to: at least one processing unit 141, at least one storage unit 142, and a bus 143 connecting different system components (including storage unit 142 and processing unit 141).

[0273] Bus 143 represents one or more of several bus structures, including a memory bus or memory controller, peripheral bus, processor, or local bus using any of the various bus structures.

[0274] Storage unit 142 may include a readable medium in the form of volatile memory, such as random access memory (RAM) 1421 and / or cache storage unit 1422, and may further include read-only memory (ROM) 1423.

[0275] 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 these examples may include an implementation of a network environment.

[0276] The computing device 140 can 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 device that enables the computing device 140 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 145. Furthermore, the computing device 140 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 146. As shown, network adapter 146 communicates with other modules for the computing device 140 via bus 143. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with the computing device 140, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0277] In some possible implementations, various aspects of the routing distribution method provided in this application can also be implemented as a program product, including a computer program. When the program product is run on an electronic device, the computer program causes the electronic device to perform the steps in the routing distribution method according to the various exemplary embodiments of this application described above. For example, the electronic device can perform actions such as... Figure 3 The steps are shown in the figure.

[0278] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, 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), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0279] The program product of the embodiments of this application may employ a portable compact disc read-only memory (CD-ROM) and include a computer program, and may run on an electronic device. However, the program product of this application is not limited thereto. In this document, the readable storage medium may be any tangible medium that contains or stores a program that may be used by or in conjunction with a command execution system, apparatus, or device.

[0280] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a readable computer program. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with a command execution system, apparatus, or device.

[0281] Computer programs contained on readable media may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0282] Computer programs for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The computer program can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0283] It should be noted that although several units or sub-units of the device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units.

[0284] Furthermore, although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0285] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing a computer-usable computer program.

[0286] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can 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 instructions, which execute via the processor of the computer or other programmable data processing apparatus, produce a machine for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0287] These computer program commands may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the commands stored in the computer-readable storage medium produce an article of manufacture including command means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0288] These computer program commands can also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing the commands executed on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0289] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0290] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A route distribution method, characterized in that, Applied to storage nodes, the method includes: Receive the first transaction version information for the target business object reported by the associated target gateway; the target gateway and the storage node serve the same set of business objects containing the target business object, and each set of business objects contains at least one business object; Based on the currently stored second transaction version information for the target business object and the first transaction version information, the transaction version information to be pushed for the target business object is determined; wherein, each transaction version information corresponds to a routing transaction used to characterize the corresponding routing information change; The version information of the transaction to be pushed and the corresponding routing information are pushed to the target gateway.

2. The method as described in claim 1, characterized in that, The first transaction version information is the latest transaction version information for the target business object currently stored by the target gateway; The step of determining the transaction version information to be pushed for the target business object based on the currently stored second transaction version information for each target business object and the first transaction version information includes: The latest transaction version information for the target business object among the currently stored second transaction version information is taken as the target transaction version information; If the first transaction version information is detected to be different from the target transaction version information, the incremental transaction version information determined based on the difference between the first transaction version information and the target transaction version information will be used as the transaction version information to be pushed.

3. The method as described in claim 1, characterized in that, The method further includes: Real-time detection of the database used to store metadata for various business objects, the metadata including routing information; If it is determined that the database generates a routing transaction for the target business object, then the corresponding second transaction version information and routing information are obtained from the database and stored.

4. The method as described in claim 1, characterized in that, Before receiving the first transaction version information for the target service object reported by the associated target gateway, the method further includes: Receive the registration request sent by the target gateway; Based on the number of currently registered gateways, determine whether there is the ability to register for the target gateway; If it is determined that the system has the capability to register with the target gateway, a long-lived connection is established with the target gateway.

5. The method as described in claim 4, characterized in that, The method further includes: If it is determined that the target gateway does not have the registration capability, then the connection information of other currently connectable storage nodes is fed back to the target gateway, so that the target gateway can send a registration request to the other storage nodes and establish a long connection based on the connection information; Among them, the other currently connectable storage nodes and the target gateway serve the same set of business objects.

6. The method according to any one of claims 1 to 5, characterized in that, Each business object corresponds to a business object tree, and each tree node in the business object tree represents the metadata storage resources at each level corresponding to the business object. Each tree node corresponds to a transaction version information; wherein, the metadata includes routing information. The transaction version information corresponding to each business object is determined based on the transaction version information corresponding to each tree node in the corresponding business object tree.

7. The method as described in claim 6, characterized in that, Each transaction version information includes: the transaction number of the corresponding route transaction, and the operation sequence number under the corresponding route transaction; each route transaction includes at least one operation.

8. The method according to any one of claims 1 to 5, characterized in that, The number of business objects contained in each business object set is associated with the storage node and gateway serving the business object set.

9. A route distribution method, characterized in that, Applied to a target gateway, the method includes: The first transaction version information for the target business object is reported to the associated storage node, so that the storage node determines the transaction version information to be pushed for the target business object based on the currently stored second transaction version information for the target business object and the first transaction version information; the target gateway and the storage node serve the same set of business objects containing the target business object, and each set of business objects contains at least one business object; Receive the transaction version information to be pushed and the corresponding routing information for the target business object pushed by the storage node.

10. The method as described in claim 9, characterized in that, Before reporting the first transaction version information for the target business object to the associated storage node, the following steps are also included: Send a registration request to the storage node; If the storage node has registration capability, a long-lived connection is established with the storage node. The registration capability is determined by the storage node based on the number of currently registered gateways.

11. The method as described in claim 10, characterized in that, The method further includes: The system receives connection information from the storage node regarding other currently connectable storage nodes, which is sent after the storage node determines it does not have registration capabilities; wherein, the other currently connectable storage nodes and the target gateway serve the same set of business objects. Based on the connection information, a registration request is sent to the other storage nodes and a long connection is established.

12. The method according to any one of claims 9 to 11, characterized in that, The reporting of the first transaction version information for the target business object to the associated storage node includes: The latest transaction version information currently stored for the target business object is used as the first transaction version information; The first transaction version information is reported to the storage node via a heartbeat signal.

13. A routing distribution system, characterized in that, The system includes: at least one gateway and at least one storage node; the associated storage node and gateway serve the same set of business objects, and each set of business objects contains at least one business object; Each of the storage nodes is configured to receive, from the associated gateway, first transaction version information for a business object in the set of serviced business objects; determine, based on the currently stored second transaction version information for each business object and the first transaction version information, transaction version information to be pushed for the business object; and push the transaction version information to be pushed and corresponding routing information to the associated gateway. Each gateway is configured to report the first transaction version information to the associated storage node; and to receive the transaction version information to be pushed and the routing information pushed by the storage node.

14. The system as described in claim 13, characterized in that, The system also includes a database: The database is used to store metadata for each business object, and transaction version information corresponding to each business object; the metadata includes routing information. Each of the storage nodes is also used to monitor the database in real time; if it is determined that the database generates a routing transaction for the business object, the corresponding second transaction version information and routing information are obtained from the database and stored.

15. A routing distribution device, characterized in that, Applied to storage nodes, including: The transmission unit is used to receive the first transaction version information for the target service object reported by the associated target gateway; the target gateway and the storage node serve the same set of service objects containing the target service object, and each set of service objects contains at least one service object; The determining unit is configured to determine the transaction version information to be pushed for the target business object based on the currently stored second transaction version information for each target business object and the first transaction version information; wherein, each transaction version information corresponds to a routing transaction used to characterize the corresponding routing information change; The push unit is used to push the version information of the transaction to be pushed and the corresponding routing information to the target gateway.

16. A routing distribution device, characterized in that, Applied to the target gateway, including: The reporting unit is used to report the first transaction version information of the target business object to the associated storage node, so that the storage node can determine the transaction version information to be pushed for the target business object based on the currently stored second transaction version information of the target business object and the first transaction version information; the target gateway and the storage node serve the same set of business objects containing the target business object, and each set of business objects contains at least one business object; The receiving unit is used to receive the transaction version information to be pushed for the target business object and the corresponding routing information pushed by the storage node.

17. An electronic device, characterized in that, It includes a processor and a memory, wherein the memory stores a computer program that, when executed by the processor, causes the processor to perform the steps of any of the methods described in claims 1 to 12.

18. A computer-readable storage medium, characterized in that, It includes a computer program that, when run on an electronic device, causes the electronic device to perform the steps of any of the methods described in claims 1 to 12.

19. A computer program product, characterized in that, The method includes a computer program stored in a computer-readable storage medium; when a processor of an electronic device reads the computer program from the computer-readable storage medium, the processor executes the computer program, causing the electronic device to perform the steps of any one of claims 1 to 12.

Images