Convergence risk control methods, devices and media for multi-tenant object storage

Abstract

This application discloses a convergence risk control method, device, and medium for multi-tenant object storage, relating to the field of risk monitoring technology. The disclosed method includes: converting multiple operational events from different event sources in a multi-tenant management system into standardized events with a unified structure based on preset specifications; constructing object set states, cache pool states, and tenant risk states based on the standardized events; determining the risk budget occupancy of each tenant's global cache completion capability in the multi-tenant management system based on the object set states, cache pool states, and tenant risk states; and executing the corresponding control action when the risk budget occupancy exceeds a preset proportion. This method effectively improves system caching performance in multi-tenant scenarios.

Description

Technical Field

[0001] This application relates to the field of risk monitoring technology, and in particular to a convergence risk control method, device and medium for multi-tenant object storage. Background Technology

[0002] In object storage services, business workflows can continuously write objects to an object collection and enter a state of sealing or complete a state transition after certain conditions are met.

[0003] Most current object storage services adopt a multi-tenancy architecture, providing services to multiple independent tenants through shared infrastructure and resource pools to achieve economies of scale and reduce operating costs. In a multi-tenant scenario, if a tenant opens too many incomplete object collections, it will consume global cache completion capacity and affect the sealing of object collections already opened by other tenants, resulting in a decrease in system cache performance.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a convergence risk control method, device and medium for multi-tenant object storage, which aims to solve the technical problem of degraded system cache performance in multi-tenant scenarios.

[0006] To achieve the above objectives, this application proposes a convergence risk control method for multi-tenant object storage, the method comprising: Based on preset specifications, multiple operation and maintenance events from different event sources in the multi-tenant management system are transformed into standardized events with a unified structure. The object collection state, cache pool state, and tenant risk state are constructed based on standardized events. Based on the object collection state, cache pool state, and tenant risk state, determine the risk budget allocation of each tenant's global cache completion capacity in the multi-tenant management system. When the risk budget occupancy exceeds the preset ratio, the corresponding control action for the risk budget occupancy will be executed.

[0007] In one embodiment, the step of determining the risk budget occupancy of each tenant's global cache completion capability in the multi-tenant management system based on the object set state, the cache pool state, and the tenant risk state includes: Based on the object set status, cache pool status, and tenant risk status, determine at least one of the following for each tenant: remaining tenant sealing workload, tenant cache reservation amount, number of open object sets for tenants, number of stuck object sets for tenants, number of cache reservation failures, and deadline pressure. The risk budget allocation is determined based on at least one of the following: remaining archive workload, tenant cache reservation amount, number of open object sets for tenants, number of stuck object sets for tenants, number of cache reservation failures, and deadline pressure.

[0008] In one embodiment, when the risk budget occupancy exceeds a preset proportion, the step of executing the control action corresponding to the risk budget occupancy includes: When the risk budget usage exceeds a preset ratio, determine the risk level corresponding to the risk budget usage and the target tenant corresponding to the risk budget usage. When the risk level is Level 1, obtain the convergence risk score of the set of incomplete objects under the target tenant; Based on the priority ranking result of the incomplete object set after prioritizing the convergence risk score, the target tenant is subject to hierarchical object write rate adjustment and hierarchical sealing task scheduling priority adjustment.

[0009] In one embodiment, after determining the risk level corresponding to the risk budget occupancy and the target tenant corresponding to the risk budget occupancy when the risk budget occupancy exceeds a preset proportion, the convergence risk control method for multi-tenant object storage further includes: When the risk level is Level 2, write permissions for a preset proportion of the object sets are suspended based on the convergence risk score of the incomplete object sets under the target tenant's name. Release unused cached quotas until the risk budget usage drops below a preset percentage, where the percentage corresponding to the first level is less than that of the second level.

[0010] In one embodiment, after determining the risk level corresponding to the risk budget occupancy and the target tenant corresponding to the risk budget occupancy when the risk budget occupancy exceeds a preset proportion, the convergence risk control method for multi-tenant object storage further includes: When the risk level is level 3, the system enters cache protection mode. In cache protection mode, the multi-tenant management system only allows cache release, persistence, archiving, and preset recovery operations. The proportion corresponding to the second level is smaller than that of the third level.

[0011] In one embodiment, after the steps of constructing the object set state, cache pool state, and tenant risk state based on standardized events, the convergence risk control method for multi-tenant object storage includes: Get the persistent write time, cache usage, timeout period, and number of historical archive failures from the object collection state; Based on the continuous unwritten time, cache usage, timeout period, and number of historical archive failures, calculate the convergence risk score for each tenant's set of incomplete objects.

[0012] In one embodiment, after the steps of constructing the object set state, cache pool state, and tenant risk state based on standardized events, the convergence risk control method for multi-tenant object storage further includes: When the reconstruction process of the multi-tenant management system is triggered, the object collection state, cache pool state, and tenant risk state are reconstructed based on the event ledger, object metadata, cache index, persistent object index, cache reservation table, and monitoring snapshots of the multi-tenant management system. The reconstruction process is triggered when any of the following conditions are met: In response to risk engine restart commands, detection of missing status tables, detection of failed event handling processes, and detection of inconsistent cache pool status.

[0013] In one embodiment, the step of converting multiple operation and maintenance events from different event sources in a multi-tenant management system into standardized events with a unified structure based on preset specifications includes: Determine the object set identifier corresponding to the preset specification; Based on the object set identifier, multiple operation and maintenance events from different event sources are standardized to obtain standardized events with a unified structure. The object set identifier includes at least one of the following: event identifier, idempotent key, event type, event occurrence time, access time, object set identifier, tenant identifier, workflow identifier, cache pool identifier, object size, cache increment bytes, reserved increment bytes, and result code. When the object set identifier is empty, the object set identifier is determined based on the object list identifier, workflow identifier, combination of bucket and prefix path, combination of bucket and naming rules and time window, or multi-segment upload group.

[0014] Furthermore, to achieve the above objectives, this application also proposes a convergence risk control device for multi-tenant object storage. The convergence risk control device for multi-tenant object storage includes: a memory, a processor, and a computer program stored on the memory and executable on the processor. The computer program is configured to implement the steps of the convergence risk control method for multi-tenant object storage as described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the convergence risk control method described above.

[0016] This application provides a convergence risk control method for multi-tenant object storage. Based on a preset specification, multiple operational events from different event sources in a multi-tenant management system are converted into standardized events with a unified structure. Object set states, cache pool states, and tenant risk states are constructed based on these standardized events. Based on these states, the risk budget occupancy of each tenant's global cache completion capacity in the multi-tenant management system is determined. When the risk budget occupancy exceeds a preset proportion, corresponding control actions are executed. Through standardized processing of multi-source events and the construction of the three states (object set, cache pool, and tenant), globally transparent resource visibility is achieved, thereby accurately identifying the number of object sets opened by each tenant, the amount of cache resources occupied, and the scale of pending sealing tasks. Based on this, the risk budget occupancy of each tenant's global cache completion capacity is calculated. When the occupancy exceeds the limit, tiered control actions are executed. This allows for early identification of potential risks and the formation of executable control strategies in scenarios with limited cache resources, improving system cache performance in multi-tenant scenarios. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating the first embodiment of the convergence risk control method for multi-tenant object storage in this application. Figure 2 This application provides an object collection lifecycle state diagram for the first embodiment of the convergence risk control method for multi-tenant object storage. Figure 3 This is a flowchart of the event state construction provided in the first embodiment of the convergence risk control method for multi-tenant object storage in this application; Figure 4 This is a control decision closed-loop diagram provided in the second embodiment of the convergence risk control method for multi-tenant object storage in this application; Figure 5 This is a flowchart of the tenant risk budgeting process provided in the second embodiment of the convergence risk control method for multi-tenant object storage in this application. Figure 6This is a flowchart of the event replay recovery process provided in the seventh embodiment of the convergence risk control method for multi-tenant object storage in this application. Figure 7 Platform system architecture diagram provided for the convergence risk control method for multi-tenant object storage in the embodiments of this application; Figure 8 This is a schematic diagram of the hardware operating environment involved in the convergence risk control method for multi-tenant object storage in this application embodiment.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] Currently, in object storage services, business workflows can continuously write objects to an object collection, and after meeting predetermined conditions, the objects are either sealed or undergo a state transition. Most current object storage services adopt a multi-tenancy architecture, providing services to multiple independent tenants through shared infrastructure and resource pools to achieve economies of scale and reduce operating costs. In multi-tenant scenarios, if a tenant opens too many incomplete object collections, it will consume global cache completion capacity and affect the sealing of object collections already opened by other tenants, leading to a decrease in system cache performance.

[0023] This application provides a solution that, based on preset specifications, transforms multiple operational events from different event sources in a multi-tenant management system into standardized events with a unified structure. Based on these standardized events, it constructs object set states, cache pool states, and tenant risk states. Based on these object set states, cache pool states, and tenant risk states, it determines the risk budget allocation for each tenant's global cache completion capacity within the multi-tenant management system. When the risk budget allocation exceeds a preset proportion, it executes corresponding control actions. Through standardized processing of multi-source events and the construction of the three states (object set, cache pool, and tenant), the system achieves globally transparent resource visibility for the first time, accurately identifying the number of object sets opened by each tenant, the amount of cache resources occupied, and the scale of pending encapsulation tasks. Based on this, it calculates the risk budget allocation for each tenant's global cache completion capacity, and executes tiered control actions when the allocation exceeds the limit. This allows for early identification of potential risks and the formation of executable control strategies in scenarios with limited cache resources, effectively improving system cache performance in multi-tenant scenarios.

[0024] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device capable of performing the above functions, a convergence risk control device for multi-tenant object storage, etc. The following description uses a convergence risk control device for multi-tenant object storage as an example to illustrate this embodiment and the subsequent embodiments.

[0025] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0026] This application provides a convergence risk control method for multi-tenant object storage, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the convergence risk control method for multi-tenant object storage in this application.

[0027] In this embodiment, the convergence risk control method for multi-tenant object storage includes steps S10 to S40: Step S10: Based on preset specifications, convert multiple operation and maintenance events from different event sources in the multi-tenant management system into standardized events with a unified structure.

[0028] In this embodiment, the preset specification refers to the rules required to convert raw events from different sources into standardized events containing fixed fields. These include object set identifiers, reliability levels, and identifier mapping rules. The object set identifier includes event identifier, idempotent key, source system, event type, event time, access time, source sequence number, object set identifier, tenant identifier, workflow identifier, cache pool identifier, object key, object version, object size, cache increment, sealing condition increment, reserved increment, and result code. The reliability level includes strongly consistent events, at least once delivered events, eventually consistent index events, and periodic scan compensation events. The identifier mapping rules are used to derive the object set identifier when an event lacks a unified identifier, following the order of object list identifier, workflow identifier, bucket and prefix path combination, bucket and naming rule and time window combination, and multi-segment upload group rules. The tenant identifier is preferentially taken from the request authentication subject or bucket owner, the workflow identifier is preferentially taken from the upstream declaration, object list metadata, or completed marked object metadata, and the cache pool identifier is preferentially determined by the gateway routing result, cache node ownership, or object set cache reserved record.

[0029] Different event sources refer to the various modules that generate original operation and maintenance events, including the object gateway, caching module, archiving module, reservation module, recovery module, and tenant control module. Operation and maintenance events refer to the raw records generated by each event source that reflect changes in operational status, such as object collection creation events, object write success events, object write failure events, cache persistence start events, cache persistence confirmation events, archiving start events, archiving success events, archiving failure events, reservation creation events, reservation failure events, tenant rate limiting start events, tenant rate limiting removal events, recovery classification events, risk occurrence events, and risk resolution events.

[0030] Standardized events refer to structured event records that, after being transformed according to preset specifications, possess a fixed field structure, unified semantics, and complete contextual information. The system can directly parse standardized events and use them for state construction and risk calculation. Events with inconsistent structures are raw events collected directly from different event sources such as the object gateway, caching module, and encapsulation module. Their formats vary significantly, including plain text logs and semi-structured strings. Field naming is inconsistent, key context is missing, semantics are ambiguous, and they cannot be directly associated with specific entities. The system needs to write separate parsing adapters for each event source to process them. Simultaneously, the event collector collects raw operational events from multiple event sources, including the object gateway, caching module, and operations and maintenance system. Specifically, the event collector collects object read / write operation logs received from various business nodes by the object gateway, persistence actions and encapsulation lifecycle state changes in the cache pool of the caching module, and monitoring alarms and operations and maintenance work order records generated during system operation in the operations and maintenance system. The event collector uniformly accesses multi-source data distributed across different modules, forming an event stream to be processed, providing standardized data input for subsequent standardization transformation.

[0031] As an optional implementation, a strongly consistent event flow approach is used to generate standardized events with a unified structure.

[0032] Specifically, the event collector gathers raw events from event sources such as the object gateway, cache module, encapsulation module, and reservation module, and directly writes them to a Raft / etcd-based state service (a distributed state service that maintains state through a consistency protocol) or a strongly consistent event ledger implemented using database transaction tables. The event normalization module reads events sequentially from the ledger, performs field mapping and format conversion based on a preset unified object set identifier, and generates standardized events with a unified structure. Taking the object gateway as an example, the raw event before conversion is an unstructured text log "[2020-01-01 10:00:00.123] PUT / bucket-a / images / photo.jpg SUCCESS size=123 user=tenant-X", which lacks key fields such as event identifier, idempotent key, event type enumeration, and object set identifier, making it impossible for the system to parse directly. When using a strongly consistent event stream approach for transformation, the system generates a globally unique event identifier for the event, such as "evt-20200101-01234", maps "PUT SUCCESS" to the standardized event type "PutSucceeded", maps "user=tenant-X" to the tenant identifier "tenant-X", and derives the object set identifier "bucket-a / images / " based on the bucket and prefix path. Simultaneously, it supplements the idempotent key, access time, source system, source sequence number, and cache increment byte field to obtain a standardized event containing complete fields such as the event identifier and idempotent key. The strongly consistent event stream approach ensures that events are not duplicated, not lost, and are strictly ordered, making it suitable for scenarios with high requirements for state consistency.

[0033] As another alternative implementation, a standardized event with a unified structure is generated by using an eventually consistent event stream plus periodic reconciliation compensation method.

[0034] Specifically, the event collector asynchronously delivers raw events to a message queue. The event normalization module removes events from the message queue and performs normalization processing, allowing for a certain degree of out-of-order, duplicate, or delayed events. For late events caused by out-of-order delivery, deduplication and sorting compensation are performed using the idempotent key and source sequence number in the event. For missing events caused by delivery failure, the system initiates a periodic reconciliation and compensation task, which involves periodically scanning object metadata, cache indexes, and persistent object indexes, comparing them with the constructed state table, and filling in missing events or directly correcting the state after identifying gaps. By combining eventually consistent event streams with periodic reconciliation and compensation, the real-time requirements of event transmission are reduced, making it suitable for large-scale distributed deployments and scenarios that can tolerate brief state inconsistencies.

[0035] As another alternative implementation method, a standardized event with a unified structure is generated by using a hybrid reconstruction method based on monitoring snapshots and incremental events.

[0036] Specifically, a full snapshot of metrics is periodically pulled from a monitoring system, such as Prometheus (a monitoring metrics collection system), including continuous metrics such as cache pool capacity, cache usage for each tenant, and the number of object sets, as a baseline state. The event collector only collects critical state change events, such as successful sealing, cache reservation failure, and risk level changes, and does not collect fine-grained events such as high-frequency object writes. The event normalization module merges a small number of critical events with the latest monitoring snapshot, using incremental information from the events to correct outdated fields in the snapshot, such as deducting the remaining sealing workload for tenants from successful sealing events. When there is a conflict between the snapshot and the event, the snapshot takes precedence and the deviation log is recorded for auditing. By using a hybrid reconstruction method based on monitoring snapshots and incremental events, event throughput and storage costs are significantly reduced, making it suitable for lightweight deployment scenarios with low real-time requirements.

[0037] The above are only three feasible implementation methods of step S10 provided in this embodiment. This embodiment does not specifically limit the specific implementation method of step S10.

[0038] Furthermore, after converting multiple operation and maintenance events from different event sources into standardized events with a unified structure, the system writes the standardized events into a strongly consistent event ledger. Since the ledger relies on a consistency protocol or database transaction mechanism at its underlying level, the system automatically performs deduplication and sorting operations during persistent writing. That is, it eliminates duplicate events by comparing the idempotent keys of the events and ensures the chronological order of all event records according to a strict logical clock or physical timestamp, thereby forming a globally unique and strictly ordered event stream in the ledger, avoiding status errors and misjudgments caused by event duplication or disordered order.

[0039] Step S20: Construct the object collection state, cache pool state, and tenant risk state based on standardized events.

[0040] In this embodiment, the object collection status refers to the real-time status information of the object collection during its lifecycle, including lifecycle stage, write progress, persistence progress, object list gaps, cache usage, remaining sealing workload, and risk level and cause. Please refer to... Figure 2 , Figure 2This is a lifecycle state diagram of an object collection provided in the first embodiment of the convergence risk control method for multi-tenant object storage in this application. Specifically, the object lifecycle is as follows: First, the object collection is in the created state. The system reserves space for it in the cache and switches to the uploading state. If an abnormality occurs during the upload process, it enters the failed state. If the data upload is canceled or times out and fails to upload successfully, it enters the discarded state. After the data is successfully uploaded, the state changes to upload completed, and the uploaded data is sealed. After successful sealing, the state changes to sealed.

[0041] In this embodiment, the cache pool status refers to the overall operational status of the shared cache resource pool, used to determine whether the cache faces the risk of resource exhaustion, including total cache capacity, reserved capacity, used capacity, reclaimable capacity, and current archiving processing capacity. The tenant risk status refers to the risk of completion capacity occupancy caused by a particular tenant, used to determine whether rate limiting or admission control is needed for the tenant, including the tenant's remaining archiving workload, tenant cache reservation, number of open object sets, number of stuck object sets, deadline pressure, and completion risk budget occupancy.

[0042] As an optional implementation, a real-time event-driven state approach is used to construct the object collection state, cache pool state, and tenant risk state.

[0043] Specifically, each standardized event output by the event normalization module is distributed to the corresponding state processor in real time. The object collection state processor directly updates fields such as the collection's lifecycle stage, write progress, cache usage, and remaining sealing workload based on the event type. The cache pool state processor increases or decreases the used capacity and reclaimable capacity in real time based on cache reservation, release, and full events. The tenant risk state processor aggregates the latest status of all unsealed collections under a tenant and dynamically calculates indicators such as remaining sealing workload, number of open collections, and number of stuck collections. Through real-time event-driven state management, it can quickly complete the process after an event arrives, ensuring that the risk engine always holds the latest runtime view. This approach is suitable for scenarios with high real-time requirements and controllable event throughput.

[0044] As another optional implementation, an event ledger plus timed snapshot aggregation method is used to construct the object collection state, cache pool state, and tenant risk state.

[0045] Specifically, standardized events are first written to a persistent event ledger, such as a database table or log stream. State construction does not rely on real-time event pushes; instead, a scheduled task reads events within the most recent time period from the event ledger in batches, rescans and aggregates all relevant events, and reconstructs the state of the object collection, cache pool, and tenant risk status. Each reconstruction uses the most recent complete snapshot as a baseline, replaying all events after that snapshot to obtain the current state. By aggregating events using an event ledger and scheduled snapshots, even if a processing fails, the next scheduled task will recalculate based on the complete event stream, ensuring eventual consistency. This approach is suitable for deployment environments with unstable event sources but requiring high reliability and traceability.

[0046] Step S30: Based on the object set status, the cache pool status, and the tenant risk status, determine the risk budget occupancy of each tenant's global cache completion capability in the multi-tenant management system.

[0047] In this embodiment, global cache completion capacity refers to the total number of object marshalling operations that can be completed per unit of time, such as how many bytes of data can be marshalled per second. Risk budget refers to the upper limit of cache completion capacity allocated to each tenant. The calculation method for risk budget usage refers to the proportion of cache completion capacity currently actually used by a tenant to the allocated risk budget.

[0048] As an optional implementation method, a weighted comprehensive calculation method is used to determine the risk budget occupancy of each tenant's global cache completion capability in the multi-tenant management system, based on the object set state, cache pool state, and tenant risk state.

[0049] Specifically, metrics such as remaining sealed workload, cache reservation amount, number of open object sets, number of stuck object sets, number of cache reservation failures, and deadline pressure are extracted from the object set status, cache pool status, and tenant risk status. Each metric is assigned a preset weight coefficient. For example, the weight for remaining sealed workload is 0.3, the weight for stuck sets is 0.2, the weight for deadline pressure is 0.25, the weight for cache reservation failures is 0.15, and the weight for open sets is 0.1. The normalized value of each metric is multiplied by its corresponding weight and summed to obtain the tenant's comprehensive risk score. This score is then divided by the tenant's configured risk budget limit to obtain the risk budget utilization ratio. By assigning adjustable weights to multi-dimensional risk metrics and performing normalized weighted summation, a configurable comprehensive assessment of tenant risk budget utilization is achieved.

[0050] As another alternative implementation, based on the object set state, cache pool state, and tenant risk state, a predictive evaluation method based on an event source risk engine is used to determine the risk budget occupancy of each tenant's global cache completion capability in the multi-tenant management system.

[0051] Specifically, all or some fields from the object set state, cache pool state, and tenant risk state are used as feature vectors and input into a pre-trained machine learning model, such as a gradient boosting regression tree or a deep neural network. This model uses historical operational data as training samples and the degree to which the tenant actually causes a decrease in global cache completion capacity as a supervision signal. It outputs a predicted risk budget occupancy value ranging from 0 to infinity. Features are re-collected and inference is performed every evaluation cycle, eliminating the need for manual weight maintenance. By using an event-source risk engine for prediction and evaluation, it can adapt to changes in system load and capture nonlinear relationships.

[0052] Step S40: When the risk budget occupancy exceeds the preset ratio, execute the control action corresponding to the risk budget occupancy.

[0053] In this embodiment, when a tenant's risk budget usage exceeds a preset proportion, the system sorts and filters the object sets based on the convergence risk results (such as convergence risk scores) of each maintained object set. Based on the filtered results, targeted control decisions are output to improve the effectiveness of these decisions. Furthermore, since the convergence urgency and failure probability of different object sets under the same tenant vary greatly—some sets may have been stuck for a long time with high cache usage and high convergence risk scores, while others may have just been created, have normal write operations, and low convergence risk scores—if rate limiting or write suspension is applied to all object sets, low-risk sets that could converge normally would be unfairly affected, causing unnecessary business interruptions and resource waste. Therefore, by sorting by convergence risk results, the system can prioritize high-risk sets while maintaining normal operation for low-risk sets, thereby achieving precise differentiated control and improving the utilization efficiency of global cache resources as well as the stability and fairness of the system.

[0054] It should be noted that the global tenant safety completion budget is 10TB. Tenant A has 1000 incomplete object sets, each with 15GB of remaining workload, and each with low convergence risk. In this case, the tenant's total remaining workload is 15TB, the risk budget utilization ratio is 1.5, and the tenant's risk level is severe. Tenant B has 1 incomplete object set with 5TB of remaining workload, and each with extremely high convergence risk. In this case, the tenant's total remaining workload is 5TB, the risk budget utilization ratio is 0.5, and the tenant's risk level is normal. In other words, even if all object sets have low risk, as long as the aggregate workload exceeds the budget, the tenant will enter severe risk. Even if a single object set has extremely high risk, as long as the overall workload is within the budget, the tenant will not trigger any tenant-level controls.

[0055] Therefore, as an optional implementation method, a hierarchical threshold-triggered control method is adopted. When the risk budget occupancy exceeds a preset ratio, the control action corresponding to the risk budget occupancy is executed.

[0056] Specifically, multiple risk ratio thresholds are preset, such as 0.7, 0.9, and 1.0. Each threshold corresponds to a risk level and a set of predefined control actions. For example, when a tenant's risk budget occupancy ratio exceeds 0.7, it enters the early warning level, sending an alarm notification to the operations and maintenance system, reducing the new object set admission rate for that tenant by 50%, and increasing the scheduling priority of the tenant's sealing tasks by one level. When the ratio exceeds 0.9, it enters the high-risk level, suspending write permissions for the top 20% of object sets with the highest convergence risk scores under that tenant, releasing all unused cache reservation quotas for that tenant, and increasing the priority of all sealing tasks for that tenant to the highest level. When the ratio exceeds 1.0, it enters the severe risk level, entering cache protection mode, allowing only cache release, persistence, sealing, and preset recovery operations, and prohibiting any new writes and new reservations for that tenant. The control actions for each level continue to be executed until the ratio falls back below the corresponding level's release threshold.

[0057] As another optional implementation method, a dynamic adaptive feedback control method is adopted. When the risk budget occupancy exceeds a preset ratio, the control action corresponding to the risk budget occupancy is executed.

[0058] Specifically, the control decision engine generates personalized control action combinations in real time based on multi-dimensional inputs such as the changing trend of the risk budget occupancy ratio, the current overall load, and the risk status of other tenants. For example, when a tenant's risk budget occupancy ratio rapidly rises from 0.6 to 0.85, indicating a significant change, even if the high-risk threshold has not yet been reached, control measures will be implemented in advance, such as suspending write permissions, to prevent the risk from spiraling out of control. When the ratio slowly climbs to 0.88, the engine may only implement mild control, such as sending an alarm, to avoid excessive intervention. The intensity of the control actions, such as the percentage reduction in write rate, is dynamically adjusted by the control decision engine through a PID controller or reinforcement learning model to stabilize the risk budget occupancy ratio within the normal range as quickly as possible. Through dynamic adaptive feedback control, it can adapt to complex changes in the production environment, reducing false alarms and excessive intervention.

[0059] This embodiment provides a convergence risk control method for multi-tenant object storage. Please refer to... Figure 3 , Figure 3This is a flowchart illustrating the event state construction process provided in the first embodiment of the convergence risk control method for multi-tenant object storage in this application. Based on preset specifications, multiple operational events from different event sources in the multi-tenant management system are converted into standardized events with a unified structure. These standardized events are then written into an event ledger for deduplication and sorting. Subsequently, object set states, cache pool states, and tenant risk states are constructed based on these standardized events. Based on these states, the risk budget occupancy of each tenant's global cache completion capacity in the multi-tenant management system is determined. When the risk budget occupancy exceeds a preset proportion, the corresponding control action is executed. Through multi-source event standardization processing and the construction of the three states—object set, cache pool, and tenant—the system achieves globally transparent resource visibility for the first time, accurately identifying the number of object sets opened by each tenant, the amount of cache resources occupied, and the scale of pending encapsulation tasks. Based on this, the risk budget occupancy of each tenant's global cache completion capacity is calculated. When the occupancy exceeds the limit, tiered control actions are executed. This allows for early identification of potential risks and the formation of executable control strategies in scenarios with limited cache resources, effectively improving system cache performance in multi-tenant scenarios.

[0060] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 4 , Figure 4 This is a closed-loop control decision diagram provided in the second embodiment of the convergence risk control method for multi-tenant object storage in this application. After the risk calculation engine completes the risk assessment of objects, tenants, and cache pools, it will trigger multi-dimensional control and response actions in parallel. For real-time traffic, it will implement access rejection or queuing and rate limiting of the access system, execute runtime cache persistence and sealing through the scheduling system to avoid memory overload, drive the status feedback of faulty nodes and the isolation or retry mechanism of the recovery system, and issue alarm work orders (runbooks), i.e., work manual suggestions. The execution results and event details generated by the entire risk control chain will be uniformly written back to the event bill, and the status will be fed back to the risk calculation engine to realize the closed loop of risk handling control decision.

[0061] Please refer to Figure 5 , Figure 5 This is a flowchart illustrating the tenant risk budgeting process provided in the second embodiment of the convergence risk control method for multi-tenant object storage in this application. The system aggregates all objects by tenant and archives related sets. Then, it performs two key calculations in parallel: calculating the remaining archive workload and the tenant security budget, and further calculating the user completion risk ratio, i.e., risk budget occupancy. Based on the risk budget occupancy, tiered control is implemented. If a threshold is exceeded, draining or rate limiting can be performed; otherwise, normal access monitoring is conducted.

[0062] Therefore, as an optional implementation, step S30, which determines the risk budget occupancy of each tenant's global cache completion capability in the multi-tenant management system based on the object set state, the cache pool state, and the tenant risk state, includes: Step S31: Based on the object set status, cache pool status, and tenant risk status, determine at least one of the following for each tenant: remaining tenant sealing workload, tenant cache reservation amount, number of open object sets for tenants, number of stuck object sets for tenants, number of cache reservation failures, and deadline pressure.

[0063] As one implementation, the object collection status table records the object list gaps, the tenant's remaining sealing workload, the estimated sealing time, the risk level, and the cause of the risk; the cache pool status table records the cache capacity, the used capacity, and the reserved capacity information; and the tenant risk status table records the tenant's remaining sealing workload, the number of open object collections, the number of stuck object collections, and the number of cache reservation failures.

[0064] Specifically, the remaining sealing workload field of each set record in the object set status table is read, and the remaining sealing workload field values ​​of all object sets belonging to the tenant that have not yet been sealed (i.e., sets whose lifecycle status is sealing candidate, sealed, etc., are not yet finalized) are added together to obtain the tenant's remaining sealing workload. For example, if tenant A has 3 unsealed sets with remaining sealing workloads of 100GB, 200GB, and 50GB respectively, then the tenant's remaining sealing workload is 350GB. Alternatively, the remaining sealing workload of the same-tenant level tenants pre-stored in the tenant risk status table can be reused to obtain the tenant's remaining sealing workload.

[0065] Read the cache usage field of each collection record in the cache pool status table, add up the cache usage field values ​​of all unsealed object collections under that tenant, and obtain the tenant's cache reservation amount.

[0066] Read the lifecycle status field of the object collection status table, count the number of object collections under the tenant whose lifecycle status does not belong to the final state such as successful sealing, failed release, or obsolete, and get the number of open object collections of the tenant. For example, if tenant A has a total of 10 object collections, of which 3 have been successfully sealed, 1 has been obsolete, and the remaining 6 are in the state of being written or sealed, then the number of open object collections is 6. Alternatively, read the number of open object collections of the tenant pre-stored in the tenant risk status table.

[0067] Read the last event time field of the object collection status table and compare it with the current system time. Count the number of object collections of the tenant that have exceeded the preset timeout period since the last event update and have not yet been sealed. Get the number of tenant stuck object collections, or read the number of tenant stuck object collections pre-stored in the tenant risk status table.

[0068] Read the reservation failure event count recorded in the event ledger or tenant risk status, count the total number of cache reservation failure events that occurred for the tenant in the most recent time window, and obtain the cache reservation failure count.

[0069] The deadline field of each collection in the object collection status is read. Taking into account the urgency of all unsealed object collections under that tenant remaining until their respective business deadlines, the minimum remaining time percentage across all collections is taken, indicating the most urgent deadline. Alternatively, a weighted average based on the collection data volume is used to obtain the deadline pressure. By extracting at least one key indicator from multiple dimensions—object collections, cache pool, and tenants—at least one key indicator is extracted to accurately characterize the actual consumption and potential risks of each tenant's global cache completion capability.

[0070] Step S32: Determine the risk budget allocation based on at least one of the following: remaining archive workload, tenant cache reservation amount, number of open object sets for tenants, number of stuck object sets for tenants, number of cache reservation failures, and deadline pressure.

[0071] As one implementation method, risk budget occupancy = tenant's current actual cache completion capacity / tenant's allocated risk budget. The actual cache completion capacity is a weighted average obtained by multiplying preset weights, such as multiplying the remaining archived workload by weight coefficient A, the number of tenant stalled sets by weight coefficient B, and the deadline pressure by weight coefficient C. This average is then divided by the tenant's configured risk budget cap to obtain the risk budget occupancy ratio. By weighting and merging multiple indicators into the risk budget occupancy ratio, the degree to which tenants are crowding out shared cache completion capacity is directly reflected, allowing for the triggering of tiered control strategies based on this ratio.

[0072] In this embodiment, by measuring risk based on distributed events, the platform can dynamically adjust according to the real-time resource usage of tenants, preventing individual tenants from excessively consuming cache completion capacity and improving overall stability and resource utilization.

[0073] Based on any of the above embodiments of this application, Embodiment 3 of this application proposes a convergence risk control method for multi-tenant object storage, which can be referred to the above description and will not be repeated hereafter. Based on this, when the risk budget occupancy exceeds a preset proportion, the steps for executing the control action corresponding to the risk budget occupancy include: Step S41: When the risk budget occupancy exceeds the preset ratio, determine the risk level corresponding to the risk budget occupancy and the target tenant corresponding to the risk budget occupancy.

[0074] As one implementation method, when a tenant's risk budget usage exceeds a preset proportion, the risk level range of that proportion is determined, such as normal, warning, high risk, or severe risk. Simultaneously, the target tenant corresponding to this risk budget usage is identified, i.e., the tenant whose identity triggered the risk threshold. By determining the corresponding risk level and target tenant, the object requiring intervention and the severity of the risk are clearly identified. By quickly locating the target tenant and determining its risk level when a tenant's risk budget usage exceeds the limit, triggering conditions and targets for subsequent tiered interventions are provided.

[0075] Step S42: When the risk level is Level 1, obtain the convergence risk score of the set of incomplete objects under the target tenant.

[0076] In this embodiment, the first level refers to the warning level, which is the risk level corresponding to a tenant's risk budget occupancy ratio between 0.7 and 0.9. The convergence risk score, also known as the object set convergence risk, refers to a comprehensive score of the convergence urgency and failure probability of a single object set at the current moment. This score / risk can be calculated based on the object set state, cache pool state, and historical operating status. Calculation factors include, but are not limited to: remaining data to be sealed, cache occupancy, continuous unwritten time, continuous unsealed time, timeout, historical sealing failure count, historical recovery count, remaining capacity of the cache pool, current sealing processing capacity, and object set lifecycle status.

[0077] As one implementation method, when the risk level is at Level 1, i.e., the ratio is between 0.7 and 0.9, the convergence risk score of each incomplete object set under the target tenant is obtained. By quantifying the convergence urgency of each incomplete set under the warning level, a ranking basis is provided for fine-grained scheduling of the object sets.

[0078] Step S43: Based on the convergence risk score, prioritize the incomplete object set and perform hierarchical object write rate adjustment and hierarchical sealing task scheduling priority adjustment on the target tenant.

[0079] As one implementation method, based on the convergence risk score of each incomplete object set, all incomplete object sets are sorted in descending order of score to obtain a priority ranking result. For the target tenant, this ranking result is traversed, and according to the risk level of each object set, the pre-configured write rate limit value for the corresponding level is retrieved from the tenant rate limiting policy table. Dynamic rate adjustment is then performed on the write channel of that object set under the target tenant. Simultaneously, the priority of the sealing task for the corresponding level is retrieved from the scheduling priority table. If the high-risk level is set to the highest priority, the scheduling weight of that object set in the sealing task queue is updated to ensure that high-risk sets receive sealing resources first. After the adjustment is completed, the adjustment result is written back to the relevant fields of the object set status table for use in the next round of risk monitoring iteration. By performing differentiated adjustments on the target tenant based on the convergence risk score ranking result, the convergence of high-risk sets can be prioritized under limited resources, avoiding the spread of single-tenant problems.

[0080] In this embodiment, by refining the approach from tenant-level macro-level early warning to collection-level micro-level control, targeted regulatory measures can be taken in the early stages of risk. This prevents excessive intervention from affecting normal business operations while ensuring that the most urgent convergence tasks are given priority, thereby improving the overall utilization efficiency and stability of caching capabilities in a multi-tenant environment.

[0081] Based on any of the above embodiments of this application, Embodiment 4 of this application proposes a convergence risk control method for multi-tenant object storage, which can be referred to the above description and will not be repeated hereafter. In addition, after determining the risk level corresponding to the risk budget occupancy and the target tenant corresponding to the risk budget occupancy when the risk budget occupancy exceeds a preset proportion, the convergence risk control method for multi-tenant object storage further includes: Step S411: When the risk level is Level 2, based on the convergence risk score of the incomplete object sets under the target tenant, suspend the write permissions of a preset proportion of the object sets.

[0082] In this embodiment, the second level refers to the high-risk level, which corresponds to a tenant risk budget occupancy ratio between 0.9 and 1.0. The ratio corresponding to the first level is smaller than that of the second level.

[0083] As one implementation method, when the risk level is Level 2, i.e., the risk budget utilization ratio is between 0.9 and 1.0, all incomplete object sets under the target tenant are sorted from highest to lowest based on their convergence risk scores. Then, new object write permissions for the corresponding object sets are suspended according to a preset ratio, for example, suspending write permissions for the top 20% of sets with the highest scores. By quickly cutting off resource consumption of the highest-risk sets, the risk is prevented from escalating further to the severe level, while preserving write capabilities for other relatively safe sets.

[0084] Step S412: Release unused cache reserved quota until the risk budget usage drops below a preset ratio.

[0085] As one implementation method, all reserved but unused cache quotas under the target tenant are proactively scanned and released. This release operation continues until the tenant's risk budget occupancy ratio drops below a preset percentage. This preset percentage is the threshold for de-risking, falling within the range of the first level, for example, a preset percentage of 0.75. The percentage corresponding to the first level is lower than that of the second level, i.e., the percentage corresponding to the warning level (e.g., 0.7-0.9), which is lower than the percentage corresponding to the high-risk level (e.g., 0.9-1.0). After the risk budget occupancy drops below the preset percentage, an observation period of at least two evaluation cycles is entered. At the end of each evaluation cycle, the tenant's risk budget occupancy ratio is recalculated. Only when this ratio remains below the preset percentage for two consecutive assessment periods, and the current risk level is at least Level 2 (i.e., it has fallen from severe or high risk to warning or normal level), is the risk status determined to be stable. The tenant's risk status is then lifted, and the cache reservation table and write permission table are updated. Temporary rate-limiting flags associated with the tenant in the cache reservation table are cleared, and write permissions for previously suspended object sets in the write permission table are restored, allowing the tenant to create new object sets and write objects again. By releasing idle cache reservation quotas, tenant risk occupancy can be reduced without interrupting normal business operations, and a hysteresis mechanism can be used to prevent frequent fluctuations in control policies.

[0086] In this embodiment, by using a tiered risk reduction strategy ranging from forced blocking to resource recovery, it is possible to minimize interference with the normal operation of tenants while ensuring stability.

[0087] Based on any of the above embodiments of this application, Embodiment 5 of this application proposes a convergence risk control method for multi-tenant object storage, which can be referred to the above description and will not be repeated hereafter. In addition, after determining the risk level corresponding to the risk budget occupancy and the target tenant corresponding to the risk budget occupancy when the risk budget occupancy exceeds a preset proportion, the convergence risk control method for multi-tenant object storage further includes: Step S413: When the risk level is level 3, enter cache protection mode. In cache protection mode, the multi-tenant management system only allows cache release, persistence, sealing and preset recovery operations.

[0088] The proportion corresponding to the second level is smaller than that of the third level.

[0089] In this embodiment, the third level refers to the severe risk level, which is the risk level corresponding to a tenant risk budget occupancy ratio greater than 1.0.

[0090] As one implementation method, when the risk level is Level 3 (severe risk level) and the tenant risk budget utilization ratio is greater than 1.0, the system enters cache protection mode. In this mode, the multi-tenant management system only allows cache release, cache persistence, sealing, and preset recovery operations, while prohibiting all new object writing, cache reservation, and the creation of new object sets. The ratio corresponding to Level 2 is smaller than that of Level 3; Level 2 is high risk, with a ratio ranging from 0.9 to 1.0, while Level 3 is severe risk, corresponding to a ratio greater than 1.0. By entering cache protection mode under severe risk level, new resource consumption is completely blocked, retaining only necessary release and sealing operations, preventing the global cache completion capacity from collapsing.

[0091] In this embodiment, a tiered protection system from early warning to severe risk is constructed through a strictly incremental risk threshold design. This system can maintain global cache stability at minimal cost in extreme situations, while reserving recovery space for risk fallback.

[0092] Based on any of the above embodiments of this application, Embodiment Six of this application proposes a convergence risk control method for multi-tenant object storage, which can be referred to the above description and will not be repeated hereafter. Based on this, after the steps of constructing the object set state, cache pool state, and tenant risk state according to standardized events, the convergence risk control method for multi-tenant object storage includes: Step S21: Obtain the continuous unwritten time, cache usage, timeout period, and number of historical sealing failures from the object collection state.

[0093] In this embodiment, the continuous no-write time refers to the elapsed time from the last successful write to the current moment for the object collection, reflecting the activity level of the object collection. If no new objects are written for a long time, it may indicate that the collection has stagnated or that there is a problem with the upstream data source. Cache usage refers to the actual data capacity currently occupied by the object collection in the cache, directly reflecting the degree of cache resource consumption by the collection. The larger the usage, the more significant the crowding effect on the available cache of other tenants, and the higher the risk. Timeout refers to the remaining time from the current moment to the business deadline for the object collection, i.e., the latest deadline for completion of sealing, used to measure the urgency of the collection. The shorter the remaining time, the sooner sealing must be completed. Historical sealing failure count refers to the cumulative number of failed sealing attempts for the object collection in the past. The more failures, the more likely the collection has problems such as data corruption, inconsistent metadata, or underlying storage anomalies, resulting in a lower probability of success.

[0094] Step S22: Calculate the convergence risk score of each tenant's incomplete object set based on the continuous unwritten time, cache usage, timeout distance, and number of historical sealing failures.

[0095] As one implementation method, the continuous unwritten time, cache usage, timeout period, and number of historical sealing failures are extracted from the object set status table. Based on the four acquired indicators, a convergence risk score is generated for each incomplete object set using a preset weighted calculation model. The higher the convergence risk score, the greater the urgency and probability of failure for that set, thus providing a quantitative basis for subsequent priority ranking and hierarchical control.

[0096] Understandably, in addition to calculating the convergence risk score based on the duration of no writes, cache usage, timeout, and number of historical sealing failures, other risk factors for the object set can also be considered, such as the remaining amount of data to be sealed, the remaining capacity of the cache pool, the current sealing processing capacity, the lifecycle state of the object set, the number of historical recovery attempts, the duration of no sealing, and the number of missing objects in the object list. The remaining amount of data to be sealed refers to the total amount of data in the object set that has not yet been migrated from the cache to persistent storage. The larger the amount of data, the longer the sealing time required, and the higher the convergence risk. The remaining capacity of the cache pool refers to the current available space ratio of the cache pool containing the object set. The fuller the pool, the more intense the resource contention, and the higher the convergence risk. The current sealing processing capacity refers to the total number of sealing operations that the system can complete per unit of time. The lower the processing capacity, the higher the convergence risk. The lifecycle state of the object set refers to the current stage of the object set, such as writing, waiting for missing objects, or sealing candidate. The closer to the end, the higher the risk. The lower the stability risk, the longer the object set remains stuck in the middle, and the higher the convergence risk. Historical recovery counts refer to the number of times a set of objects has triggered recovery operations due to past failures; the more recovery counts, the worse the stability of the set and the higher the convergence risk. Continuous unsealed time refers to the duration for which an object set has been unsealed since meeting the sealing conditions; the longer the time, the more likely the scheduling priority is insufficient or there is hidden blocking, and the higher the convergence risk. The number of gaps in the object list refers to the number of differences between the objects already written and the expected business list; the larger the gap, the greater the workload required to fill it before sealing, and the higher the convergence risk. By combining these multiple dimensions of factors for weighted comprehensive calculation, the convergence risk score can more comprehensively and accurately reflect the true urgency of convergence and the probability of failure for each object set, thus providing a more reliable decision-making basis for subsequent priority ranking and hierarchical control.

[0097] In this embodiment, by extracting key risk factors such as continuous unwritten time, cache usage, timeout period, and number of historical sealing failures, and by calculating a weighted convergence risk score, the urgency of convergence for each object set is accurately quantified, providing a data basis for subsequent hierarchical scheduling and risk control.

[0098] Based on any of the above embodiments of this application, Embodiment Seven of this application proposes a convergence risk control method for multi-tenant object storage, which can be referred to the above description and will not be repeated hereafter. Building upon this, after the steps of constructing the object set state, cache pool state, and tenant risk state based on standardized events, the convergence risk control method for multi-tenant object storage further includes: Step S23: When the reconstruction process of the multi-tenant management system is triggered, the object collection state, cache pool state, and tenant risk state are reconstructed based on the event ledger, object metadata, cache index, persistent object index, cache reservation table, and monitoring snapshot of the multi-tenant management system.

[0099] The reconstruction process is triggered when any of the following conditions are met: In response to risk engine restart commands, detection of missing status tables, detection of failed event handling processes, and detection of inconsistent cache pool status.

[0100] As one implementation method, please refer to Figure 6 , Figure 6This is a flowchart illustrating the event replay recovery process provided in the seventh embodiment of the convergence risk control method for multi-tenant object storage in this application. When one of the following is detected—a risk engine restart command, a lost state table, an event processing failure, or an inconsistent cache pool state—indicating a state anomaly or engine restart, the multi-tenant management reconstruction process is triggered. After the reconstruction process is triggered, the object set state table, cache pool state table, and tenant risk state table in current memory are cleared, and the reconstruction start time is determined. All standardized event records from the reconstruction start time are read from the event ledger, and the events are sorted according to their occurrence time. For each event, event deduplication, idempotency checks, and late event compensation are performed based on the event identifier, idempotency key, and source sequence number. During event replay, if there are breakpoints or omissions in the event stream, the most recent monitoring snapshot is used to fill in the missing continuous indicators such as cache pool capacity and sealing rate. Next, the object collection state is reconstructed. The event stream is traversed, each object collection is identified, and its lifecycle state is updated according to the event type. Specifically, the write progress and cache usage are accumulated based on object write events, the persistence progress is updated based on cache persistence events, and the sealing status and remaining sealing workload are updated based on sealing events. Combined with object metadata, such as object size, version, and persistent object index, the integrity of the object collection is verified, and gaps in the object list are repaired. The cache pool state is reconstructed. The capacity information and actual usage of all current cache nodes are read from the cache index. Combined with the cache reservation and release records in the events, the reserved capacity, used capacity, and reclaimable capacity are calculated. The initial total cache pool capacity and sealing processing capacity baseline are obtained from the monitoring snapshot, and then corrected through event increments. The tenant risk state is reconstructed. The reservation record of each tenant is obtained from the cache reservation table. The status of all unsealed object collections belonging to the same tenant in the events is aggregated. Indicators such as the remaining sealing workload, number of open collections, and number of stuck collections for the tenant are calculated. At the same time, the number of cache reservation failures and deadline pressure for the tenant are counted from the event ledger. After rebuilding the object collection state, cache pool state, and tenant risk state, the system resumes the risk decision-making process and continues to control multi-tenant resources. Through the rebuilding process of the multi-tenant management system, it ensures that a complete runtime state can be automatically restored in the event of a fault or abnormal state, maintaining the continuity of risk monitoring and control.

[0101] Furthermore, cross-validation is performed on the three reconstructed states. For example, the sum of cache usage for object collections should equal the used capacity of the cache pool, and the remaining encapsulation workload for a tenant should be the same as the sum of the corresponding fields for all its collections. If inconsistencies are found, a periodic reconciliation and compensation task is triggered, scanning object metadata, persistent object indexes, and cache indexes to correct erroneous fields in the state table. By performing state consistency verification and compensation, it is ensured that even if state is lost, a complete runtime view can be recovered from multiple reliable data sources, maintaining the continuity of risk monitoring and control.

[0102] In this embodiment, a multi-source data reconstruction mechanism enables the system to automatically restore a complete runtime state view when encountering faults such as restart, state loss, processing failure, or data inconsistency, thereby ensuring the continuity and reliability of risk monitoring and control.

[0103] Based on any of the above embodiments of this application, Embodiment Eight of this application proposes a convergence risk control method for multi-tenant object storage, which can be referred to the above description and will not be repeated hereafter. Based on this, the steps of converting multiple operation and maintenance events from different event sources in the multi-tenant management system into standardized events with a unified structure based on preset specifications include: Step S11: Determine the object set identifier corresponding to the preset specification.

[0104] As one implementation method, a unique identifier, or object set identifier, is determined in a pre-defined specification to identify each object set. The priority and field mapping rules of the identifier are defined by the pre-defined specification to ensure that each operational event can be associated with the correct object set.

[0105] Step S12: Based on the object set identifier, convert multiple operation and maintenance events from different event sources into standardized events with a unified structure.

[0106] The object set identifier includes at least one of the following: event identifier, idempotent key, event type, event occurrence time, access time, object set identifier, tenant identifier, workflow identifier, cache pool identifier, object size, cache increment bytes, reserved increment bytes, and result code.

[0107] As one implementation method, based on a unified object set identifier defined by a pre-defined specification, operation and maintenance events from different event sources are converted into standardized events with a unified structure. A standardized event includes at least one of the following: event identifier, idempotent key, source system, event type, event time, access time, source sequence number, object set identifier, tenant identifier, workflow identifier, cache pool identifier, object key, object version, object size, cache increment, sealing condition increment, reserved increment, and result code. By filling in these fields, heterogeneous events have the same structure and semantics, facilitating subsequent state construction and risk calculation.

[0108] Step S13: When the object set identifier is empty, determine the object set identifier based on the object list identifier, workflow identifier, combination of bucket and prefix path, combination of bucket and naming rules and time window, or multi-segment upload group.

[0109] As one implementation method, when the object set identifier is empty, meaning the event does not directly carry a unified object set identifier, the identifier is determined sequentially according to a preset derivation rule. Specifically, the identifier is confirmed in the following order: object list identifier, workflow identifier, bucket and prefix path combination, bucket and naming rule and time window combination, and multipart upload group. When the object set identifier is empty, first check if the event contains a workflow identifier. If so, the workflow identifier is used as the object set identifier. If there is no workflow identifier, try to obtain the event's bucket name and prefix path (e.g., directory path), concatenating them into a string of the form "bucket+prefix" as the object set identifier. If there is no prefix path, use the bucket name plus the naming rule and time window, concatenating them into a string of the form "bucket+naming_rule+time_window" as the object set identifier. If none of the above applies, the multipart upload group identifier "multipart_upload_group" is used as the object set identifier. This hierarchical naming derivation strategy ensures that each event can be assigned to the correct object set.

[0110] In this embodiment, a standardized event field structure is defined by a preset specification, and the missing object set identifier is automatically deduced and filled in according to priority rules. This unifies operation and maintenance events from different event sources into standardized events with consistent structure and relevance, providing a data foundation for accurately constructing the object set status, cache pool status, and tenant risk status in the future.

[0111] For example, to help understand the implementation process of the convergence risk control method for multi-tenant object storage obtained by combining this embodiment with the first embodiment described above, please refer to... Figure 7 , Figure 7 The platform system architecture diagram provided for the convergence risk control method for multi-tenant object storage in this application embodiment is as follows: Raw operational events are collected from different event sources, such as the object gateway, caching module, and sealing module, by an event collector. These events are then standardized by the event normalization module according to a preset unified object set identifier, generating standardized events with consistent structure and writing them into the event ledger. Based on these standardized events, the object set status, cache pool status, and tenant risk status are continuously constructed. The risk calculation engine, based on these three constructed states, determines the risk budget occupancy ratio of each tenant's global cache completion capacity using a weighted comprehensive calculation method or predictive model, and compares it with a preset threshold to determine the risk level. When the risk budget occupancy exceeds the preset ratio, the control decision output interface executes tiered control actions according to the risk level, such as reducing the write rate and increasing the sealing priority at the warning level, and suspending high-risk operations at the high-risk level. The system grants write permissions to the risk set and releases unused cache reserved quotas. Under severe risk levels, it enters cache protection mode, allowing only release, persistence, sealing, and recovery operations. Simultaneously, the control decision output interface can also issue cache persistence and sealing instructions to the scheduling system to achieve automatic circuit breaking, or generate alarm work orders and associate them with the Runbook, i.e., the work manual recommends guiding maintenance personnel to intervene. In addition, the system has event replay and reconciliation compensation mechanisms. When the risk engine restarts, the status table is lost, or the cache pool status is inconsistent, the three major states can be reconstructed from the event ledger, object metadata, cache index, persistent object index, cache reserved table, and monitoring snapshots, ensuring the continuity and reliability of risk monitoring and control, forming a complete closed loop from event collection, status construction, risk calculation to hierarchical control and fault recovery.

[0112] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the convergence risk control method for multi-tenant object storage in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0113] This application provides a convergence risk control device for multi-tenant object storage. The convergence risk control device for multi-tenant object storage includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the convergence risk control method for multi-tenant object storage in the first embodiment described above.

[0114] The following is for reference. Figure 8This document illustrates a structural schematic of a convergence risk control device suitable for implementing the embodiments of this application for multi-tenant object storage. The convergence risk control device for multi-tenant object storage in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, personal digital assistants (PDAs), tablet computers (PADs), portable media players (PMPs), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 8 The convergence risk control device for multi-tenant object storage shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0115] like Figure 8 As shown, the convergence risk control device for multi-tenant object storage may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes based on a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the convergence risk control device for multi-tenant object storage. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the convergence risk control device for multi-tenant object storage to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a convergence risk control device for multi-tenant object storage with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or have alternatively.

[0116] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0117] The convergence risk control device for multi-tenant object storage provided in this application adopts the convergence risk control method for multi-tenant object storage in the above embodiments, which can solve the technical problem of degraded system cache performance in multi-tenant scenarios. Compared with the prior art, the beneficial effects of the convergence risk control device for multi-tenant object storage provided in this application are the same as the beneficial effects of the convergence risk control method for multi-tenant object storage provided in the above embodiments, and other technical features in the convergence risk control device for multi-tenant object storage are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0118] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0119] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0120] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the convergence risk control method for multi-tenant object storage in the above embodiments.

[0121] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory (EPROM, or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0122] The aforementioned computer-readable storage medium may be included in a convergence risk control device for multi-tenant object storage; or it may exist independently and not be assembled into a convergence risk control device for multi-tenant object storage.

[0123] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a convergence risk control device for multi-tenant object storage, the convergence risk control device for multi-tenant object storage: converts multiple operation and maintenance events from different event sources in the multi-tenant management system into standardized events with a unified structure based on preset specifications; constructs object set states, cache pool states, and tenant risk states based on the standardized events; determines the risk budget occupancy of each tenant's global cache completion capability in the multi-tenant management system based on the object set states, cache pool states, and tenant risk states; and executes the control action corresponding to the risk budget occupancy when the risk budget occupancy exceeds a preset ratio.

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

[0125] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0126] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0127] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described convergence risk control method for multi-tenant object storage, thereby solving the technical problem of degraded system cache performance in multi-tenant scenarios. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the convergence risk control method for multi-tenant object storage provided in the above embodiments, and will not be repeated here.

[0128] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A convergence risk control method for multi-tenant object storage, characterized in that, The convergence risk control method for multi-tenant object storage includes: Based on preset specifications, multiple operation and maintenance events from different event sources in the multi-tenant management system are transformed into standardized events with a unified structure. Based on the standardized events, construct the object set state, cache pool state, and tenant risk state; Based on the object set status, the cache pool status, and the tenant risk status, determine the risk budget allocation for each tenant's global cache completion capability in the multi-tenant management system. This includes: determining at least one of the following for each tenant based on the object set status, cache pool status, and tenant risk status: remaining tenant sealing workload, tenant cache reservation, number of open object sets, number of stalled object sets, number of cache reservation failures, and deadline pressure; and determining the risk budget allocation based on at least one of the following: remaining sealing workload, tenant cache reservation, number of open object sets, number of stalled object sets, number of cache reservation failures, and deadline pressure. When the risk budget occupancy exceeds a preset ratio, the control action corresponding to the risk budget occupancy is executed.

2. The convergence risk control method for multi-tenant object storage as described in claim 1, characterized in that, The step of executing the control action corresponding to the risk budget occupancy when the risk budget occupancy exceeds a preset ratio includes: When the risk budget occupancy exceeds a preset ratio, the risk level corresponding to the risk budget occupancy and the target tenant corresponding to the risk budget occupancy are determined. When the risk level is Level 1, obtain the convergence risk score of the set of incomplete objects under the target tenant. Based on the convergence risk score, the priority ranking result of the incomplete object set is used to perform hierarchical object write rate adjustment and hierarchical sealing task scheduling priority adjustment on the target tenant.

3. The convergence risk control method for multi-tenant object storage as described in claim 2, characterized in that, After the step of determining the risk level corresponding to the risk budget occupancy and the target tenant corresponding to the risk budget occupancy when the risk budget occupancy exceeds a preset proportion, the convergence risk control method for multi-tenant object storage further includes: When the risk level is Level 2, write permissions for a preset proportion of the incomplete object sets are suspended based on the convergence risk scores of the incomplete object sets under the target tenant's name. Release unused cache reserved quotas until the risk budget occupancy drops below the preset ratio, wherein the ratio corresponding to the first level is less than that of the second level.

4. The convergence risk control method for multi-tenant object storage as described in claim 3, characterized in that, After the step of determining the risk level corresponding to the risk budget occupancy and the target tenant corresponding to the risk budget occupancy when the risk budget occupancy exceeds a preset proportion, the convergence risk control method for multi-tenant object storage further includes: When the risk level is level 3, the system enters cache protection mode. In cache protection mode, the multi-tenant management system only allows cache release, persistence, archiving, and preset recovery operations. The proportion corresponding to the second level is smaller than that of the third level.

5. The convergence risk control method for multi-tenant object storage as described in claim 2, characterized in that, Following the step of constructing the object set state, cache pool state, and tenant risk state based on the standardized events, the convergence risk control method for multi-tenant object storage includes: Obtain the duration of no write, cache usage, timeout, and number of historical sealing failures from the state of the object collection. Based on the continuous unwritten time, cache usage, timeout period, and number of historical sealing failures, calculate the convergence risk score for each tenant executing the set of incomplete objects.

6. The convergence risk control method for multi-tenant object storage as described in claim 1, characterized in that, Following the step of constructing the object set state, cache pool state, and tenant risk state based on the standardized events, the convergence risk control method for multi-tenant object storage further includes: When the reconstruction process of the multi-tenant management system is triggered, the object collection state, the cache pool state, and the tenant risk state are reconstructed based on the event ledger, object metadata, cache index, persistent object index, cache reservation table, and monitoring snapshot of the multi-tenant management system. The reconstruction process is triggered when any of the following conditions are met: The system responds to a risk engine restart command, detects a missing status table, detects a failed event handling process, and detects inconsistencies in the cache pool status.

7. The convergence risk control method for multi-tenant object storage as described in claim 1, characterized in that, The steps for converting multiple operation and maintenance events from different event sources in the multi-tenant management system into standardized events with a unified structure based on preset specifications include: Determine the object set identifier corresponding to the preset specification; Based on the object set identifier, multiple operation and maintenance events from different event sources are standardized to obtain standardized events with a unified structure. The object set identifier includes at least one of the following: event identifier, idempotent key, event type, event occurrence time, access time, object set identifier, tenant identifier, workflow identifier, cache pool identifier, object size, cache increment bytes, reserved increment bytes, and result code. When the object set identifier is empty, the object set identifier is determined based on the object list identifier, workflow identifier, combination of bucket and prefix path, combination of bucket and naming rules and time window, or multi-segment upload group.

8. A convergence risk control device for multi-tenant object storage, characterized in that, The convergence risk control device for multi-tenant object storage includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the convergence risk control method for multi-tenant object storage as described in any one of claims 1 to 7.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the convergence risk control method for multi-tenant object storage as described in any one of claims 1 to 7.

Images