Tenant-based multi-tiered message delivery method and system

Abstract

The application provides a tenant-based multi-level message delivery method and system. The method comprises the following steps: obtaining a request context in a message request, and extracting a tenant context and at least one path information from the request context; constructing a message header according to the tenant context; converting all the path information into a range condition expressed uniformly to obtain a range condition set; identifying a main range condition and an auxiliary range condition in the range condition set, and obtaining an initial message delivery range according to the main range condition and the auxiliary range condition; obtaining a tenant boundary in the tenant context, and deleting a delivery range exceeding the tenant boundary in the initial message delivery range to obtain an effective message delivery range; generating a condition delivery message by combining the effective message delivery range with the message header, and sending the condition delivery message to a downstream condition queue. Thus, invalid retrieval and error delivery are reduced, and the efficiency of sending a message request by a downstream system is improved.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a tenant-based multi-level message delivery method and system. Background Technology

[0002] In related technologies, in multi-tenant data processing scenarios, message requests sent by tenants typically carry contextual information such as application, organization, node, and business type, as well as range conditions such as organization path, node path, or path list. However, due to the complex contextual information and path relationships, downstream systems struggle to send message requests efficiently. Summary of the Invention

[0003] The technical problem to be solved by this invention is: how to improve the efficiency of downstream systems in sending message requests.

[0004] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A tenant-based multi-level message delivery method includes: Obtain the request context from the message request, and extract the tenant context and at least one path information from the request context; Construct a message header based on the tenant context; All the path information is converted into a unified range condition to obtain a range condition set; Identify the primary and secondary range conditions in the range condition set, and obtain the initial message delivery range based on the primary and secondary range conditions; Obtain the tenant boundary in the tenant context, and delete the delivery range that exceeds the tenant boundary in the initial message delivery range to obtain the effective message delivery range; The valid message delivery range and the message header are used to generate a conditional delivery message, which is then sent to the downstream conditional queue.

[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A tenant-based multi-level message delivery system includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the tenant-based multi-level message delivery method described above.

[0006] The beneficial effects of this invention are as follows: When a message request is received, the tenant context and path information are extracted from the obtained request context, and all path information is converted into a unified range condition. This allows for unified processing of different path information after conversion, thereby identifying the main range condition and the auxiliary range condition to obtain the initial message delivery range. Then, the initial message delivery range is filtered according to the tenant boundary to obtain the effective message delivery range. Combined with the message header, a conditional delivery message is generated and sent to the downstream condition queue. This allows the downstream condition queue to directly expand the target path and execute the sending according to the effective message delivery range after receiving the conditional delivery message, without having to judge the relationship between path information and the tenant boundary again. This reduces invalid retrieval and erroneous delivery, and improves the efficiency of the downstream system in sending message requests. Attached Figure Description

[0007] Figure 1 This is a flowchart of a tenant-based multi-level message delivery method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of a tenant-based multi-level message delivery system according to an embodiment of the present invention. Detailed Implementation

[0008] Definitions:

[0009] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0010] In existing technologies, the complex context and path relationships involved in tenant-issued message requests make it difficult for downstream systems to send message requests efficiently. Specifically, the following problems exist: 1. Inconsistent tenant fields between the upper layer and the lower layer message protocol fields force downstream systems to repeatedly query the context. 2. Inconsistent expression of organizational conditions in query parameters and request bodies, resulting in fragmented condition encapsulation. 3. When multiple range conditions such as org_path, node_path, path_list, and instId exist simultaneously in the same request, existing solutions typically pass them directly without proper condition determination, conflict resolution, and priority merging mechanisms. 4. When organizational identifiers are missing or range conditions span tenants and nodes, downstream systems are prone to over-broadcasting or out-of-bounds delivery due to a lack of automatic pruning. 5. Downstream systems must understand tenant semantics and independently determine whether organizational conditions conflict or are available, resulting in high link coupling and unstable processing results.

[0011] To at least address the aforementioned issues, this invention provides a tenant-based multi-level message delivery method and system, applicable to systems that require message delivery to dynamic user sets based on institutions, organizational paths, node paths, and their combinations. It is particularly suitable for message delivery scenarios where multiple range conditions coexist and the target set needs automatic normalization, conflict resolution, and boundary trimming.

[0012] In this invention, upon receiving a message request, the tenant context and path information are extracted from the acquired request context. All path information is converted into a unified range condition. Then, the initial message delivery range is filtered based on tenant boundaries to obtain a valid message delivery range. Finally, the valid message delivery range and message header are used to generate a conditional delivery message, which is then sent to the downstream condition queue. This method allows the downstream condition queue, upon receiving the conditional delivery message, to directly expand the target path according to the valid message delivery range and execute the delivery without needing to re-determine the relationships between path information and tenant boundaries. This reduces invalid retrieval and erroneous delivery, improving the efficiency of message request sending in the downstream system.

[0013] The following details a tenant-based multi-level message delivery method according to the present invention. Please refer to [link / reference]. Figure 1 The method 100 includes steps 101 to 106: Step 101: Obtain the request context from the message request, and extract the tenant context and at least one path information from the request context. The request context refers to the HTTP Header and framework context of the message request. The extracted tenant context includes fields such as application identifier (appId), organization tenant identifier (tenantId), node identifier (nodeId), business type (bizType), and organization identifier (orgId). These fields are usually automatically injected by the upstream gateway or framework during request forwarding, identifying the application source and tenant affiliation of the current request. The extracted path information includes fields such as organization path (org_path), node path (node_path), path list (path_list), and organization identifier (instId). Different source fields may use different naming formats.

[0014] Step 102: Construct a message header based on the tenant context. Specifically, write the application identifier, organization tenant identifier, node identifier, service type, and organization identifier extracted in Step 101 into a unified message header and attach the complete tenant context. The complete tenant context needs to be serialized by tenant and then attached to the message header as the basis for subsequent conditional normalization and security verification. Specifically, it includes the following fields: Tenant Identifier: A unique identifier for the current tenant, used to determine tenant boundaries; Organization Identifier: A unique code for the current organization node; Node Identifier: A unique identifier for the current node (e.g., server node, region node); Organization Path: The complete path of the current organization node in the organization tree, in the format / A / B / C, used for path prefix matching and boundary pruning; Tenant Boundary Scope (tenantScope): The maximum range of organization paths that a tenant is allowed to deliver to, in the format / A / B. Paths outside this range will be pruned; Service Type: Identifies the service category of the message, used for conditional queue routing; Application Identifier: The application source identifier that initiated the request; Extended Attributes (extProps): Optional additional key-value pairs carrying tenant-level custom configuration information.

[0015] Step 103: Convert all the path information into a unified range condition to obtain a range condition set. For example, receive the organization identifier, organization code, organization path, node path, node path list, organization path list, and general path list from step 102 using a unified filtering parameter model, and convert fields from different sources into a unified range expression to obtain a range condition set.

[0016] Step 104: Identify the primary and secondary range conditions in the range condition set, and obtain the initial message delivery range based on the primary and secondary range conditions. For example, after obtaining multiple range conditions based on step 104, select the primary and secondary range conditions from the multiple range conditions based on preset rules, and obtain the initial message delivery range.

[0017] Step 105: Obtain the tenant boundary in the tenant context, and delete the delivery ranges that exceed the tenant boundary in the initial message delivery range to obtain the valid message delivery range. For example, the initial message delivery range can be pruned according to the tenant boundary scope (tenantScope) field to automatically remove invalid paths that exceed the tenant and node, thus obtaining the final valid message delivery range.

[0018] Step 106: Generate a conditional delivery message by combining the valid message delivery range with the message header, and send the conditional delivery message to the downstream conditional queue.

[0019] As described above, the beneficial effects of this invention are as follows: When a message request is received, the tenant context and path information are extracted from the obtained request context, and all path information is converted into a unified range condition. This allows for unified processing of different path information after conversion, thereby identifying the main range condition and the subordinate range condition to obtain the initial message delivery range. Then, the initial message delivery range is filtered according to the tenant boundary to obtain the effective message delivery range. Combined with the message header, a conditional delivery message is generated and sent to the downstream condition queue. This allows the downstream condition queue to directly expand the target path and execute the sending according to the effective message delivery range after receiving the conditional delivery message, without having to judge the relationship between path information and the tenant boundary again. This reduces invalid retrieval and erroneous delivery, and improves the efficiency of the downstream system in sending message requests.

[0020] In one embodiment of the present invention, step 103, which converts all the path information into a unified expression of the range condition, includes: obtaining the path type and path structure of the target path information to be converted, and obtaining a priority value based on the path type; mapping the target path information into a range condition, and using the priority value as the priority of the range condition, and using the path structure as the retrieval path of the range condition.

[0021] The unified range representation adopts a structured object format. Each condition includes a source field, a type (supporting path, path_list, inst, etc.), a condition value (value or values ​​array), and a priority (the larger the value, the stronger the constraint). Multiple conditions are normalized and loaded into a unified filtering parameter model, and different source fields are converted into a unified range representation. The specific format is as follows: { "conditions": [ { "source": "org_path", "type": "path", "value": " / A / B / C", "priority": 2 }, { "source": "node_path", "type": "path", "value": " / A / B / C / D", "priority": 3 }, { "source": "path_list", "type": "path_list", "values": [" / A / B / C / D", " / X / Y"], "priority": 1 }, { "source": "instId", "type": "inst", "value": "12345", "priority": 0 } ], "effectiveScope": [] } in: The source indicates the field name from which the condition originates (org_path, node_path, path_list, instId, etc.).

[0022] type indicates: condition type (path indicates organization / node path, path_list indicates path list, inst indicates organization identifier).

[0023] value / values ​​means: condition values, a single path is represented by value, and multiple paths are represented by the values ​​array.

[0024] priority indicates the condition priority value, which is used for subsequent priority arbitration (the larger the value, the higher the priority).

[0025] effectiveScope refers to the final effective scope generated after priority arbitration and conflict resolution.

[0026] The specific rules for converting fields from different sources into a unified range representation are as follows: 1. `org_path`: The condition for direct mapping to `type=path`. If the path starts with ` / `, it is an absolute path; otherwise, it is considered a relative path relative to the current organization path, concatenated to form an absolute path before being written. The default priority is set to 2.

[0027] 2. node_path: The condition for mapping to type=path. The difference between node_path and org_path is that node_path is precise to the node level, with a deeper path hierarchy and stronger constraints. Therefore, its priority is set to 3 by default (higher than org_path).

[0028] 3. path_list: Expands into multiple independent condition items with type=path, and each path in the path list is normalized to an absolute path. The priority is set to 1 by default (lower than a single path condition).

[0029] 4. instId: The condition for mapping to type=inst. instId is a numeric identifier (e.g., 0 represents default / all), and cannot directly form a valid path range; it needs to be resolved in conjunction with the orgPath in the tenant context. When instId is 0, it is marked as an empty range candidate. The priority is set to 0 by default.

[0030] 5. orgCode: Looks up the corresponding orgPath through the mapping table from organization code to organization path, and after conversion, it is treated as org_path. The priority is set to 2 by default.

[0031] During the conversion process, all relative paths are concatenated with absolute paths by referring to the orgPath in the current tenant context.

[0032] As described above, by converting all path information into a unified range condition, the different path information after conversion can be processed uniformly; at the same time, priorities are set so that subsequent steps can distinguish different path information based on priorities.

[0033] In one embodiment of the present invention, step 104, identifying the main range condition and the subordinate range condition in the range condition set, includes: obtaining the range condition with the highest priority in the range condition set as the main range condition; if there are at least two range conditions with the same priority, obtaining the range condition with the deepest level of the retrieval path as the main range condition; and using the remaining range conditions in the range condition set as the subordinate range conditions.

[0034] That is, it is necessary to perform primary condition identification and priority arbitration on multiple coexisting scope conditions, and prioritize the condition with stronger binding force as the primary scope condition, and the remaining scope conditions as secondary scope conditions. The specific determination method is as follows: (1) Default priority sorting When multiple range conditions exist simultaneously, they are arranged in descending order of the following default priority: node_path (priority 3): The node path constraint is the strongest, accurate to the specific node.

[0035] org_path (priority 2): Organization path constraints for the entire organization branch.

[0036] path_list (priority 1): The path list is a batch condition, and the constraint of a single path is relatively weak.

[0037] instId (priority 0): The organization identifier needs to be converted before a path range can be formed. It has the weakest binding force when used alone.

[0038] (2) Rules for determining the main scope When multiple conditions exist, the condition with the highest priority is selected as the primary scope. When multiple conditions of the same priority exist (e.g., multiple node_paths exist simultaneously), the longest path (deepest level) is selected as the primary scope. If two conditions have the same priority, they are marked as conflicts requiring manual handling. If the highest priority condition is empty after boundary pruning (exceeding the tenant boundary), the next valid condition is selected as the primary scope in descending order of priority. If all conditions are empty after pruning, delivery is rejected.

[0039] When path-exclusive conflicts and hierarchical conflicts exist within the scope condition set, they are handled according to the priority arbitration rules described above. Path-exclusive conflicts refer to two conditions pointing to different branch paths with no inclusion relationship. For example, `org_path= / A / B / C` and `node_path= / X / Y / Z` have completely different paths and their target sets do not intersect, thus constituting a conflict. Hierarchical conflicts refer to one condition specifying a shallower path, while another condition specifies a deeper node outside that path, and the two do not have a parent-child relationship. For example, `org_path= / A / B` and `node_path= / C / D / E`, where ` / C / D / E` is not under the organization tree of ` / A / B`. When path-exclusive and hierarchical conflicts occur, the condition with higher priority is selected as the main scope, while lower-priority conflicting conditions can be pruned.

[0040] As described above, by setting default priority sorting rules and main scope determination rules, it is possible to identify the main scope conditions and subordinate scope conditions in the scope condition set.

[0041] In one embodiment of the present invention, step 104, which involves obtaining the initial message delivery range based on the primary range conditions and the secondary range conditions, includes: The main delivery range is obtained based on the main range conditions; the remaining conditions outside the main delivery range are used as intersection constraints or supplementary ranges in descending order of priority; the specific identification method is: traversing the subordinate range conditions, and matching the target subordinate range conditions with the main range conditions for the traversed target subordinate range conditions. Among them, (3) the subordinate constraint condition processing rules include: If the retrieval path of the target subordinate range condition is a sub-path of the main range condition, then an intersection supplementary delivery range is generated. For example, it can be determined whether it is a sub-path based on the prefix matching of the retrieval path. If it is a sub-path, then an intersection supplementary delivery range is generated, thereby narrowing the delivery range. For example, when determining whether path a is a sub-path of path b: after splitting path b by / , if the first N segments of path a (N is the number of segments of path b) are completely consistent with path b, then a is a sub-path of b; the algorithm is expressed as: a.split(" / ").slice(0, b.split(" / ").length).join(" / ") === b. For example, if a= / A / B and b= / A / B / C / D, then the intersection result is / A / B / C / D.

[0042] If the retrieval path of the target subordinate scope condition does not intersect with the retrieval path of the main scope, and is within the tenant boundary, then a parallel supplementary delivery scope is generated.

[0043] Additionally, if the target's scope conditions exceed the tenant's boundaries, it will be trimmed and deleted.

[0044] Finally, the initial message delivery range is obtained based on the main delivery range, the intersection supplementary delivery range, and the parallel supplementary delivery range.

[0045] As described above, the rules for processing subordinate constraints can determine the relationship between subordinate scope conditions and main scope conditions, generate intersection supplementary delivery scope and parallel supplementary delivery scope, and thus preliminarily determine the message delivery scope.

[0046] In one embodiment of the present invention, step 105, deleting delivery ranges exceeding the tenant boundary in the initial message delivery range, includes: the tenant boundary being represented in the form of a path prefix; traversing the range conditions in the initial message delivery range; for each target range condition encountered, determining whether the prefix of the retrieval path of the target range condition matches the tenant boundary; if not, deleting the target range condition. For example, if the tenant boundary is tenantScope= / A / B and path_list=[ / A / B / C / D, / X / Y], then / X / Y exceeding the boundary will be truncated and deleted.

[0047] As described above, path matching based on the path prefix of the tenant boundary for the range conditions in the initial message delivery range can effectively delete retrieval paths that exceed the tenant boundary and invalid paths of nodes, generating a valid delivery range, thereby reducing invalid retrieval and erroneous delivery.

[0048] In one embodiment of the present invention, after obtaining the range condition set, the method further includes: determining whether there are range conditions with the same retrieval path in the range condition set; if so, retaining only the range condition with the highest priority. For example, deduplication is performed on the expanded path set of path_list, removing duplicates based on comparison of complete path strings.

[0049] As can be seen from the above description, by deleting duplicate range conditions from the range condition set, duplicate searches can be avoided, thus preventing resource waste.

[0050] In one embodiment of the present invention, after obtaining the valid message delivery range in step 105, the method further includes: performing a validity check on the valid message delivery range; if the check passes and the valid message delivery range is not an empty set, then generating a conditional delivery message by combining the valid message delivery range with the message header. For example, when the organization identifier is empty, the range condition is missing, or multiple conditions are pruned to an empty set, delivery is directly rejected.

[0051] One issue encountered during message delivery was an empty range contradiction. An empty range contradiction refers to a condition where the value is empty or invalid (e.g., instId=0 and there are no other valid path conditions), causing a logical contradiction when the condition semantically requires "full delivery" but coexists with other precise range conditions. When an empty range contradiction occurs, it is handled based on the empty set rejection rule. The empty set rejection rule is defined as follows: Delivery is directly rejected when any of the following conditions are met: 1. instId is empty or 0, and there are no other valid range conditions. 2. All range conditions are deleted after boundary pruning (the valid range is an empty set). 3. The main range condition is empty after pruning.

[0052] Meanwhile, when instId=0 coexists with other path conditions, the "full" semantics of instId are ignored, and the path condition takes precedence. When instId≠0, if the organizational path resolved by instId points to a different organizational branch than the explicit path condition, for example, instId resolves to organization / E / F, but org_path specifies / A / B, then the explicit path condition (org_path= / A / B) takes precedence, and instId is downgraded to a supplementary reference.

[0053] As described above, after obtaining the valid message delivery range, the validity of the valid message delivery range and the empty set are checked to avoid incorrect broadcasting due to invalid range or empty delivery range.

[0054] In one embodiment of the present invention, generating a conditional delivery message by combining the valid message delivery range with the message header includes: extracting a retrieval start identifier from the main range conditions; the retrieval start identifier is the starting position of the retrieval, i.e., the retrieval start identifier is the organization path (orgPath) in the current tenant context, identifying the starting retrieval node when the downstream system expands the target path set; generating the conditional delivery message by combining the retrieval start identifier, the valid message delivery range, and the message header. After generating the conditional delivery message, it is asynchronously sent to the target condition queue, whereby the downstream service directly expands the valid target set and executes the sending.

[0055] The retrieval start identifier refers to the node in the organizational tree from which the downstream system begins its search when expanding the target path set. Specifically, it is the root node of the organizational path associated with the current request, i.e., the orgPath value in the tenant context. For example, when the orgPath in the tenant context is / A / B, the downstream system starts searching for target paths within the valid range from the / A / B node in the organizational tree. The purpose of the retrieval start identifier is: 1. To limit the starting position of the search, avoiding a full traversal from the root node of the organizational tree and improving search efficiency; 2. To precisely limit the search range to the intersection of [start identifier, valid range boundary] in conjunction with the valid range condition; 3. In the conditional delivery message, the retrieval start identifier is passed to the downstream system as a field in the message body.

[0056] As described above, by setting a retrieval start identifier in the conditional delivery message, the downstream system can retrieve the target path from the guiding node within the effective delivery range based on the retrieval start identifier, thus avoiding a full traversal.

[0057] In one embodiment of the present invention, step 106, sending the condition delivery message to the downstream condition queue, includes: obtaining the service type and node type according to the tenant context; sending the condition delivery message to the condition queue corresponding to the service type; and determining the fragmentation position of the condition delivery message in the condition queue according to the node type.

[0058] The determination of the conditional queue is based on two dimensions: business type (bizType) and target node identifier (nodeId). The queue naming format is {bizType}.{nodeId}, where the business type determines the major category of the queue for message delivery, and the node identifier determines the queue sharding. When nodeId is empty, the message is routed to the default queue {bizType}.default. The mapping relationship between queues and business types, as well as the node sharding strategy, are maintained in the system configuration.

[0059] The determination of the condition queue is based on two dimensions: message business type (bizType) and target node identifier (nodeId), through route matching. The specific rules are as follows: 1. Routing by business type: Messages of different business types are delivered to different conditional queues. For example, notification messages are routed to queue.notify, and data synchronization messages are routed to queue.sync; the mapping relationship between business types and queues is maintained in the system configuration.

[0060] 2. Routing by Target Node: When the system is deployed in a multi-node architecture, queues of the same business type are further sharded according to the target node. For example, sharding can be set as queue.notify.node_A and queue.notify.node_B.

[0061] 3. Queue naming rules: Conditional queue names should use the format {bizType}.{nodeId} or {bizType}.{region}. When nodeId is empty or a default value, routing will take place to the default queue {bizType}.default for that business type.

[0062] 4. Dynamic queue management: When a new business type or a new node comes online, the system automatically creates a corresponding condition queue; when a node goes offline, the messages in the node's shard queue will be reassigned to other available node queues of the same business type.

[0063] As described above, by setting different condition queues according to the business type and setting different shards under the condition queues, it can be ensured that target path messages of the same node are processed by the same consumer, reducing cross-node communication.

[0064] To illustrate the above method, this embodiment provides a specific example to explain the steps described above: For example, when a school's messaging platform sends out a notification, the request includes instId=0, org_path= / A / B, node_path= / A / B / C and path_list=[ / A / B / C / D, / X / Y], as well as other contextual information.

[0065] S1. The system first extracts the tenant context of the request, identifies the allowed tenant boundary as tenantScope= / A / B, and obtains the path information: instId=0, org_path= / A / B, node_path= / A / B / C, and path_list=[ / A / B / C / D, / X / Y]. That is, step 101 is executed.

[0066] S2. Write the application identifier, organization tenant identifier, node identifier, service type, and organization identifier into the unified message header, and attach the complete tenant context. That is, execute step 102.

[0067] S3. Normalize instId=0, org_path= / A / B, node_path= / A / B / C, and path_list=[ / A / B / C / D, / X / Y] to obtain the range condition set, such as: Based on instId=0: type=inst, value=0, priority=0; Based on org_path= / A / B, we get: type=path, value= / A / B, priority=2; Based on node_path= / A / B / C, we get: type=path, value= / A / B / C, priority=3; Based on path_list=[ / A / B / C / D, / X / Y], we get: type=path, value= / A / B / C / D, priority=1; and type=path, value= / X / Y, priority=1.

[0068] S4. Determine that node_path= / A / B / C is the main range condition, and / A / B / C / D in path_list is the intersection supplementary condition; / X / Y in path_list is the parallel supplementary condition. That is, execute step 104.

[0069] S5. Based on the tenant boundary tenantScope= / A / B, / X / Y exceeding the boundary are automatically pruned and deleted. Since instId=0 cannot form a valid scope on its own, the system will not broadcast it globally. Therefore, the final valid message delivery scope is: / A / B / C / D. This leads to step 105.

[0070] S6. Generate conditional delivery messages from the valid message delivery range. That is, execute step 106.

[0071] Once the downstream service receives the message, it can directly expand the target path according to the valid path and execute the sending without having to judge the condition conflict and tenant boundary again, thereby reducing invalid retrieval and erroneous delivery.

[0072] Please refer to Figure 2The present invention also provides a tenant-based multi-level message delivery system, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the various steps of the tenant-based multi-level message delivery method described above.

[0073] In summary, the tenant-based multi-level message delivery method and system provided in this application first normalizes multi-source path information using tenant context, enabling unified processing of different path information after transformation. This allows for the identification of primary and secondary range conditions to obtain the initial message delivery range. During the identification process, condition conflict resolution and target range pruning are performed to obtain the effective message delivery range. This ensures that downstream systems receive a "converged, verified, and pruned" effective delivery range, thereby reducing invalid retrieval and erroneous delivery, and improving the efficiency of downstream systems in sending message requests.

[0074] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A tenant-based multi-level message delivery method, characterized in that, include: Obtain the request context from the message request, and extract the tenant context and at least one path information from the request context; Construct a message header based on the tenant context; All the path information is converted into a unified range condition to obtain a range condition set; Identify the primary and secondary range conditions in the range condition set, and obtain the initial message delivery range based on the primary and secondary range conditions; Obtain the tenant boundary in the tenant context, and delete the delivery range that exceeds the tenant boundary in the initial message delivery range to obtain the effective message delivery range; The valid message delivery range and the message header are used to generate a conditional delivery message, which is then sent to the downstream conditional queue.

2. The tenant-based multi-level message delivery method according to claim 1, characterized in that, The scope condition for converting all the path information into a unified expression includes: Obtain the path type and path structure of the target path information to be converted, and obtain the priority value based on the path type; The target path information is mapped to a range condition, and the priority value is used as the priority of the range condition, and the path structure is used as the retrieval path of the range condition.

3. The tenant-based multi-level message delivery method according to claim 2, characterized in that, The identification of the primary and secondary range conditions in the range condition set includes: The range condition with the highest priority in the range condition set is selected as the main range condition. If there are at least two range conditions with the same priority, the range condition with the deepest level in the search path is selected as the main range condition. The remaining range conditions in the range condition set are used as the auxiliary range conditions.

4. The tenant-based multi-level message delivery method according to claim 2, characterized in that, The process of obtaining the initial message delivery range based on the primary range conditions and the secondary range conditions includes: The main delivery range is obtained based on the aforementioned main range conditions; Traverse the subordinate range conditions, and match the target subordinate range conditions with the main range conditions for each target subordinate range condition encountered. If the retrieval path of the target subordinate range condition is a sub-path of the main range condition, then an intersection supplementary delivery range is generated; If the retrieval path of the target subordinate range condition does not intersect with the retrieval path of the main range, then a parallel supplementary delivery range is generated; The initial message delivery range is obtained based on the main delivery range, the intersection supplementary delivery range, and the parallel supplementary delivery range.

5. A tenant-based multi-level message delivery method according to claim 2, characterized in that, The step of deleting the delivery range that exceeds the tenant boundary from the initial message delivery range includes: The tenant boundary is represented in the form of a path prefix; The range conditions in the initial message delivery range are traversed. For each target range condition encountered, it is determined whether the prefix of the retrieval path of the target range condition matches the tenant boundary. If not, the target range condition is deleted.

6. The tenant-based multi-level message delivery method according to claim 2, characterized in that, After obtaining the range condition set, the following is also included: Determine whether there are range conditions with the same search path in the range condition set. If so, retain only the range condition with the highest priority.

7. The tenant-based multi-level message delivery method according to claim 1, characterized in that, After obtaining the effective message delivery range, the following is also included: The validity of the valid message delivery range is validated. If the validation passes and the valid message delivery range is not an empty set, then the valid message delivery range and the message header are used to generate a conditional message delivery.

8. The tenant-based multi-level message delivery method according to claim 1, characterized in that, The step of delivering the effective message delivery range and the message header generation condition includes: Extract the search start identifier from the main range conditions; the search start identifier is the starting position of the search; The conditional delivery message is generated by combining the retrieval start identifier, the valid message delivery range, and the message header.

9. A tenant-based multi-level message delivery method according to claim 1, characterized in that, Sending the condition delivery message to the downstream condition queue includes: The service type and node type are obtained based on the tenant context; Send the conditional delivery message to the conditional queue corresponding to the service type; The fragment position of the condition delivery message in the condition queue is determined based on the node type.

10. A tenant-based multi-level message delivery system, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements each step of the tenant-based multi-level message delivery method according to any one of claims 1 to 9.

Images