A user permission verification and data updating method and system

Abstract

The application relates to the technical field of data processing, and discloses a user permission verification and data updating method and system, a user permission verification and data updating method, which comprises the following steps: step S101, gateway side parameters are calculated and obtained; step S102, service side parameters are calculated and obtained; step S103, a planned submission time is generated; step S104, an actual submission time is calculated and obtained, and scheduling jitter is recorded; step S105, an audit vector is constructed; and step S106, an exponential moving average is updated, and a next round of processing time consumption estimation value is generated. According to the problems of uncontrollable submission time and difficult compliance audit in a token-based access control system, the two-layer time allowance of a gateway and a resource service is uniformly integrated, an instant feasible interval and a planned submission time are determined by combining link delay calculation, and the risk of unauthorized writing caused by submission after token expiration or submission before token taking effect is effectively avoided.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and more specifically, to a method and system for user permission verification and data update. Background Technology

[0002] Currently, enterprise distributed systems commonly adopt a microservice and gateway architecture. When a user initiates a data update request, they need to carry a token containing permission information. The request first enters the gateway, which determines whether to allow the request based on the token's built-in expiration time and ineffective time. For engineering practical reasons, the gateway will introduce a time grace period of several seconds to several minutes to offset the risk of misjudgment caused by the asynchronous clocks of different machines and network jitter. To strengthen the security boundary, the resource service will verify the validity of the token again after receiving the request, and also set an independent time grace period. At the same time, data writing often involves asynchronous links such as message queues, batch processing, transaction outgoing, and retries, and is not completed synchronously.

[0003] A data update, from gateway approval to actual resource service submission, involves multiple stages such as network transmission, service queuing, and business execution, resulting in an objective time difference. When the gateway approves the request, it determines the token's usability based on local time and its own grace period. The resource service also determines usability based on its own time and local grace period during subsequent verification. However, these two determinations are independent and not related to the actual delay in the link. During this period, the token may have exceeded its expiration time or may not have reached the start of its ineffective time. Coupled with the uncertain delays in transmission, queuing, and other stages, the request may complete data writing at a time when it should logically be rejected.

[0004] Existing solutions either rely solely on a single gateway decision or employ independent verification at each layer, lacking unified control over the submission timing. System default grace periods, service clock deviations, and the uncertainties of asynchronous links collectively lead to uncontrollable submission times. This not only introduces the risk of unauthorized writes, resulting in submissions after token expiration or before tokens take effect, but also causes audit logs to record only scattered time points, making it difficult to prove that permission verification events actually occurred before data submission. When encountering retries or batch processing scenarios, these problems are further amplified, posing significant challenges to permission revocation and compliance documentation, and failing to meet enterprises' needs for data operation security and traceability. Summary of the Invention

[0005] This invention provides a method and system for user permission verification and data update, which solves the technical problems mentioned in the background.

[0006] This invention provides a method for user permission verification and data update, comprising the following steps:

[0007] Step S101: When the user permission verification is passed, obtain the gateway side parameters, calculate the expired remaining budget and effective advance amount on the gateway side, and pass them to the resource service with the request.

[0008] Gateway-side parameters include: gateway grant time, token expiration time, token effective time, and gateway tolerance.

[0009] Step S102: When the resource service receives a request, record the service enqueue time, obtain the gateway side parameters and service tolerance, calculate the service side parameters accordingly, and convert the expired remaining budget and effective lead time at the arrival time.

[0010] Server-side parameters include: path latency, earliest commit time, latest commit time, and upper and lower bounds of the immediate feasible interval;

[0011] Step S103: Obtain the estimated processing time through the processing time prediction model, calculate the compression factor based on the overdue remaining budget and the effective lead time at the arrival time, and generate the plan submission time.

[0012] Step S104: According to the planned submission time, perform waiting and submission within the upper and lower bounds of the immediate feasible interval, obtain the actual submission time and record the scheduling jitter;

[0013] Step S105: Calculate the normalized utilization rate, the remaining budget on the expired side and the advance amount on the effective side based on the actual submission time, the earliest submission time, and the latest submission time; construct the audit vector and persist it.

[0014] Step S106: Obtain the actual processing time based on the actual submission time and the service enqueue time, update the exponential moving average, and generate the estimated processing time for the next round.

[0015] Further, the sum of the token expiration time and the gateway tolerance is calculated, and then the difference between this sum and the gateway release time is calculated. The maximum value between 0 and this difference is taken to obtain the remaining expiration budget on the gateway side. The difference between the token activation time and the gateway tolerance is calculated, and then this difference is subtracted from the gateway release time to obtain the activation advance on the gateway side. The gateway side parameters, the remaining expiration budget on the gateway side, and the activation advance are combined to form a time budget vector, and the time budget vector is set to read-only and passed to the resource service with the request.

[0016] Further, step S102 includes the following steps:

[0017] Step S201: Calculate the difference between the service enqueue time and the gateway release time as the path delay;

[0018] Step S202: Calculate the sum of the gateway tolerance and the service tolerance, and then subtract this sum from the token effective time to obtain the earliest submission time;

[0019] Step S203: Calculate the sum of the gateway tolerance and the service tolerance, and then add the token expiration time to the sum to obtain the latest submission time;

[0020] Step S204: Take the maximum value between the earliest submission time and the service enqueue time as the lower bound of the immediate feasible interval, and take the latest submission time as the upper bound of the immediate feasible interval.

[0021] Step S205: Calculate the difference between the expired remaining budget on the gateway side and the path delay to obtain the expired remaining budget at the arrival time;

[0022] Step S206: Calculate the sum of the effective advance and path delay on the gateway side to obtain the effective advance at the arrival time.

[0023] Furthermore, the difference between the earliest submission time and the service enqueue time is calculated, and the maximum value between 0 and this difference is taken to obtain the waiting time required for the earliest submission. The input of the processing time prediction model is a feature vector representation composed of the average processing time of historical requests of the same type, the data size of the current request, the current CPU utilization of the resource service, and the business type of the current request. During the operation of the resource service, the feature vector of each request is recorded, and the service enqueue time and the actual submission time of the request are recorded synchronously. The difference between the actual submission time and the service enqueue time is calculated as a sample label for a training sample. The processing time prediction model is built based on a multilayer perceptron.

[0024] Furthermore, first calculate the difference between the latest submission time and the service enqueue time, then calculate the ratio of this difference to the processing time, and take the minimum value between 1 and this ratio to obtain the service-side compression factor; calculate the ratio of the expired remaining budget at the arrival time to the estimated processing time, and take the minimum value between 1 and this ratio to obtain the gateway-side compression factor; take the minimum value between the service-side compression factor and the gateway-side compression factor to obtain the target compression factor; first calculate the sum of the service enqueue time and the waiting time required for the earliest submission, then add this sum to the product of the target compression factor and the estimated processing time, and take the minimum value between this calculation result and the latest submission time to obtain the planned submission time.

[0025] Furthermore, the maximum value between the lower bound of the immediate feasible interval and the current time is taken as the waiting baseline. The difference between the planned submission time and the waiting baseline is then calculated, and the maximum value between 0 and this difference is taken as the waiting time. The waiting operation is performed according to the waiting time. When the time reaches the planned submission time, the data submission operation is immediately performed, and the actual submission time of this data submission is recorded. The difference between the actual submission time and the planned submission time is calculated as the scheduling jitter.

[0026] Furthermore, the difference between the latest submission time and the actual submission time is calculated to obtain the remaining budget on the expired side; the difference between the actual submission time and the earliest submission time is calculated to obtain the advance amount on the effective side; the difference between the actual submission time and the lower bound of the immediate feasible interval is used as the numerator, and the difference between the latest submission time and the lower bound of the immediate feasible interval is used as the denominator, and the ratio of the numerator to the denominator is used as the normalized utilization rate; and the gateway-side parameters, service-side parameters, service enqueue time, service tolerance, actual submission time, remaining budget on the expired side, advance amount on the effective side, and normalized utilization rate are combined to form an audit vector and persistently stored.

[0027] Further, calculate the difference between the actual submission time and the service enqueue time to obtain the actual processing time; calculate the product of the smoothing coefficient and the currently stored exponential moving average to obtain the first product; calculate the difference between 1 and the smoothing coefficient, and then calculate the product of this difference and the actual processing time to obtain the second product; calculate the sum of the first product and the second product to obtain the updated exponential moving average.

[0028] Furthermore, the difference between the latest and earliest submission times is calculated to obtain the subsequent write window width; the normalized utilization rate is subtracted from 0.5, and then the difference is multiplied by the subsequent write window width to obtain the position offset correction; the updated exponential moving average, scheduling jitter, and position offset correction are added together to obtain the estimated processing time for the next round.

[0029] This invention provides a user permission verification and data update system, comprising:

[0030] The gateway-side parameter calculation module is used to obtain gateway-side parameters when the user's permission verification is successful, calculate the expired remaining budget and effective advance amount on the gateway side, and pass them to the resource service with the request.

[0031] The service-side parameter calculation module is used to record the service enqueue time when the resource service receives a request, obtain the gateway-side parameters and service tolerance, calculate the service-side parameters based on these parameters, and convert them into the expired remaining budget and effective lead time at the arrival time.

[0032] The planned submission time generation module is used to obtain the estimated processing time through the processing time prediction model, calculate the compression factor based on the overdue remaining budget and the effective lead time at the arrival time, and generate the planned submission time.

[0033] The scheduling jitter calculation module is used to perform waiting and submission within the upper and lower bounds of the immediate feasible interval according to the planned submission time, obtain the actual submission time and record the scheduling jitter.

[0034] The audit vector construction module is used to calculate the normalized utilization rate, the remaining budget on the expired side and the advance amount on the effective side based on the actual submission time, the earliest submission time, and the latest submission time, and to construct and persist the audit vector.

[0035] The processing time estimation module is used to obtain the actual processing time based on the actual submission time and the service enqueue time, update the exponential moving average, and generate the processing time estimate for the next round.

[0036] The beneficial effects of this invention are as follows: Addressing the issues of uncontrolled submission times and difficulties in compliance auditing in token-based access control systems, this invention unifies and integrates the time grace periods of the gateway and resource service layers. By combining link latency calculations to determine the immediately feasible interval and planned submission time, it effectively avoids the risk of unauthorized writes, such as submissions after token expiration or submissions before tokens take effect. Simultaneously, it constructs and persists an audit vector containing gateway-side parameters, service-side parameters, and submission deviation data, which can reconstruct the entire time logic from gateway approval to resource service submission, meeting the needs of compliance auditing and issue tracing. Furthermore, by updating the exponential moving average of actual processing time, it generates an adaptive estimate of the next round of processing time, making subsequent planned submission times more closely match the actual execution scenario, reducing resource waste, and improving the overall security, compliance, and process stability of data operations. Attached Figure Description

[0037] Figure 1 This is a flowchart of a user permission verification and data update method according to the present invention;

[0038] Figure 2 This is a flowchart of step S102 of the present invention;

[0039] Figure 3 This is a schematic diagram of a user permission verification and data update system according to the present invention.

[0040] In the diagram: Gateway side parameter calculation module 301, Service side parameter calculation module 302, Plan submission time generation module 303, Scheduling jitter calculation module 304, Audit vector construction module 305, Processing time estimation module 306. Detailed Implementation

[0041] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and implement the subject matter described herein, and changes may be made to the function and arrangement of the elements discussed without departing from the scope of this specification. Various processes or components may be omitted, substituted, or added as needed in the examples. Furthermore, features described in some examples may be combined in other examples.

[0042] It should be noted that, unless otherwise defined, the technical or scientific terms used in one or more embodiments of the present invention should have the ordinary meaning understood by one of ordinary skill in the art to which this invention pertains. The terms "first," "second," and similar terms used in one or more embodiments of the present invention do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" indicate that the element or object preceding the term encompasses the elements or objects listed following the term and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0043] like Figures 1-3 As shown, a user permission verification and data update method includes the following steps:

[0044] Step S101: When the user permission verification is passed, obtain the gateway side parameters, calculate the expired remaining budget and effective advance amount on the gateway side, and pass them to the resource service with the request.

[0045] Gateway-side parameters include: gateway grant time, token expiration time, token effective time, and gateway tolerance.

[0046] Step S102: When the resource service receives a request, record the service enqueue time, obtain the gateway side parameters and service tolerance, calculate the service side parameters accordingly, and convert the expired remaining budget and effective lead time at the arrival time.

[0047] Server-side parameters include: path latency, earliest commit time, latest commit time, and upper and lower bounds of the immediate feasible interval;

[0048] Step S103: Obtain the estimated processing time through the processing time prediction model, calculate the compression factor based on the overdue remaining budget and the effective lead time at the arrival time, and generate the plan submission time.

[0049] Step S104: According to the planned submission time, perform waiting and submission within the upper and lower bounds of the immediate feasible interval, obtain the actual submission time and record the scheduling jitter;

[0050] Step S105: Calculate the normalized utilization rate, the remaining budget on the expired side and the advance amount on the effective side based on the actual submission time, the earliest submission time, and the latest submission time; construct the audit vector and persist it.

[0051] Step S106: Obtain the actual processing time based on the actual submission time and the service enqueue time, update the exponential moving average, and generate the estimated processing time for the next round.

[0052] It should be noted that this invention is applied to a token-based access control system, which includes a two-layer architecture of gateway and resource service. When a user initiates a data access or update request, they must carry a token containing identity and permission information. After the request reaches the gateway, the gateway verifies the legality of the token and the user's permissions. After the verification is successful, the process proceeds to step S101. The resource service refers to the application service that receives and processes the user's specific business request. It needs to perform subsequent time constraint verification and submission time control based on the time budget vector transmitted by the gateway to ensure that the data operation complies with the token's time validity rules. The time when the verification is successful is recorded as the gateway's release time. The preset token expiration time and token activation time are read from the token carried by the user. The gateway tolerance pre-configured by the gateway is read. This tolerance is the time grace period set by the gateway to cope with different machine clock deviations.

[0053] Specifically, the gateway permission time indicates the exact time when the gateway completes user permission verification and allows the request to continue being passed to the resource service; the token expiration time indicates the time when the token is set to be no longer valid, meaning that after this time, the token should be rejected; the token validity time indicates the time when the token is set to be valid, meaning that before this time, the token should be rejected; the gateway tolerance indicates the time grace period set by the gateway when verifying the validity of the token to compensate for the problem of clock asynchrony between different machines. For example, if the tolerance is 5 seconds and the token expiration time is 10:00:00, the gateway will consider all requests before 10:00:05 as not expired.

[0054] In one embodiment of the present invention, the sum of the token expiration time and the gateway tolerance is calculated, and then the difference between the sum and the gateway release time is calculated. The maximum value between 0 and the difference is taken to obtain the expiration remaining budget on the gateway side.

[0055] In one embodiment of the present invention, the difference between the token activation time and the gateway tolerance is calculated, and then the gateway release time is subtracted from the difference to obtain the activation advance on the gateway side.

[0056] In one embodiment of the present invention, the gateway-side parameters, the expired remaining budget and the effective lead time on the gateway side are combined to form a time budget vector, and the time budget vector is set to read-only and passed to the resource service with the request.

[0057] Specifically, the expired remaining budget on the gateway side The calculation formula is as follows:

[0058] ,in Indicates the token's expiration time. Indicates gateway tolerance. This indicates the time when the gateway allows access.

[0059] Specifically, the lead time for gateway-side activation. The calculation formula is as follows:

[0060] ,in Indicates the effective time of the token.

[0061] It should be noted that the expiration remaining budget on the gateway side represents the remaining time between the gateway release time and the token expiration time plus the latest acceptable time point (gateway tolerance). It is used to quantify the time margin that the request can still use on the expiration side when the gateway releases the request. If the result is 0, it means that the latest acceptable time has been exceeded. The activation advance on the gateway side represents the time difference between the gateway release time and the token activation time minus the earliest acceptable time point (gateway tolerance). It is used to quantify how far ahead the request is from the earliest acceptable time point when the gateway releases the request. If the result is negative, it means that the earliest acceptable time has not yet been reached.

[0062] In one embodiment of the present invention, such as Figure 2 As shown, step S102 includes the following steps:

[0063] Step S201: Calculate the difference between the service enqueue time and the gateway release time as the path delay;

[0064] Step S202: Calculate the sum of the gateway tolerance and the service tolerance, and then subtract this sum from the token effective time to obtain the earliest submission time;

[0065] Step S203: Calculate the sum of the gateway tolerance and the service tolerance, and then add the token expiration time to the sum to obtain the latest submission time;

[0066] Step S204: Take the maximum value between the earliest submission time and the service enqueue time as the lower bound of the immediate feasible interval, and take the latest submission time as the upper bound of the immediate feasible interval.

[0067] Step S205: Calculate the difference between the expired remaining budget on the gateway side and the path delay to obtain the expired remaining budget at the arrival time;

[0068] Step S206: Calculate the sum of the effective advance and path delay on the gateway side to obtain the effective advance at the arrival time.

[0069] It should be noted that path latency represents the time difference between the moment the gateway allows the request and the moment the resource service receives the request and completes queuing. It is used to quantify the time consumed by the request in the transmission and queuing processes between the gateway and the resource service. The earliest commit time represents the earliest time point allowed to execute the commit action within the token's effective time, ensuring that the commit action is not earlier than the token's logical effective range. The latest commit time represents the latest time point allowed to execute the commit action within the token's expiration time, ensuring that the commit action is not later than the token's logical expiration range. The lower bound of the immediately feasible interval is used to limit the earliest time boundary that can be scheduled for commit from the moment the service is enqueued. The upper bound of the immediately feasible interval is used to limit the latest time boundary that can be scheduled for commit from the moment the service is enqueued. The upper and lower bounds of the immediately feasible interval together constitute the time range within which the service can currently execute a commit.

[0070] It should be noted that the remaining budget at arrival time measures the available time remaining between the service enqueue time and the latest allowed commit time, while the effective lead time at arrival time measures how early the service enqueue time is relative to the earliest allowed commit time. If the result is negative, it means that the earliest commit time has not yet arrived. Service tolerance represents the time grace period set by the resource service when verifying token validity to compensate for clock asynchrony issues between itself and other machines (such as the gateway and the token issuer). That is, gateway tolerance is the time grace period used by the gateway when verifying tokens, and service tolerance is the time grace period used by the resource service when verifying tokens. Both are custom parameters, which are pre-configured in the system parameters of the gateway and resource service by the system administrator or developer based on factors such as the clock stability and network jitter of the deployment environment. They will not be elaborated on here.

[0071] In one embodiment of the present invention, the difference between the earliest submission time and the service enqueue time is calculated, and the maximum value between 0 and the difference is taken to obtain the waiting time required for the earliest submission.

[0072] In one embodiment of the present invention, the difference between the effective advance of the negative arrival time and the service tolerance can also be calculated, and the maximum value between 0 and the difference can be taken to obtain the waiting amount required for the earliest submission.

[0073] It should be noted that the earliest submission wait time represents the time required from the service enqueuing time to the earliest time when the submission action can be performed. If the service enqueuing time is later than the earliest submission time, the wait time is 0, meaning that no waiting is required and submission can be prepared directly. If the service enqueuing time is earlier than the earliest submission time, the wait time is the time difference between the two, meaning that it is necessary to wait until the earliest submission time before submission can be prepared.

[0074] In one embodiment of the present invention, the input to the processing time prediction model is a feature vector representation composed of the average processing time of historical requests of the same type, the data size of the current request, the current CPU utilization of the resource service, and the business type of the current request. During the operation of the resource service, the feature vector of each request is recorded and the service enqueue time and the actual submission time of the request are recorded synchronously. The difference between the actual submission time and the service enqueue time is calculated as a sample label for a training sample. The processing time prediction model is constructed based on a multilayer perceptron.

[0075] It should be noted that the requested business types include query, add, modify, and delete, etc. The average processing time of historical requests of the same type can be obtained manually. The multilayer perceptron consists of an input layer, a first hidden layer, a second hidden layer, and an output layer. For example, the number of neurons in the first hidden layer can be set to 64, and the number of neurons in the second hidden layer can be set to 32. The activation function can be ReLU or PReLU, etc. In addition, the training samples are divided into training set and validation set in a 7:3 ratio. During the training of the processing time prediction model, the mean squared error function is selected as the loss function, and the Adam optimizer is used for model training. The iteration continues until the loss on the validation set is stable and converges, which will not be elaborated here.

[0076] In one embodiment of the present invention, the difference between the latest submission time and the service enqueue time is first calculated, and then the ratio of the difference to the processing time is calculated. The minimum value between 1 and the ratio is taken to obtain the service-side compression factor. The ratio of the expired remaining budget at the arrival time to the estimated processing time is calculated, and the minimum value between 1 and the ratio is taken to obtain the gateway-side compression factor. The minimum value between the service-side compression factor and the gateway-side compression factor is taken to obtain the target compression factor.

[0077] It should be noted that the service-side compression factor is a coefficient used to control the planned submission time to be no later than the latest submission time. If the ratio involved in the calculation is greater than 1, it means that the estimated time can fall completely within the interval from the service enqueue time to the latest submission time, and the compression factor is 1, meaning no compression is needed. If the ratio involved in the calculation is less than 1, it means that the estimated time exceeds this interval, and the compression factor is the ratio, meaning that the estimated time needs to be compressed proportionally to avoid the planned submission time exceeding the latest submission time. The gateway-side compression factor is a coefficient used to control the planned submission time to not exceed the remaining budget expired at the arrival time. If the ratio involved in the calculation is greater than 1, it means that the estimated time can fall completely within the remaining budget expired at the arrival time, and the compression factor is 1, meaning no compression is needed. If the ratio involved in the calculation is less than 1, it means that the estimated time exceeds this budget, and the compression factor is the ratio, meaning that the estimated time needs to be compressed proportionally to avoid the planned submission time exceeding the budget. The target compression factor is the final coefficient that simultaneously satisfies the constraints of the service side and the gateway side, ensuring that the planned submission time is neither later than the latest submission time nor exceeds the expired remaining budget at the arrival time.

[0078] In one embodiment of the present invention, the sum of the service enqueue time and the waiting time required for the earliest submission is first calculated. Then, the sum is added to the product of the target compression factor and the estimated processing time. The minimum value between the calculated result and the latest submission time is taken to obtain the planned submission time.

[0079] Specifically, the planned submission time The calculation formula is as follows:

[0080] ,in The 'h' indicates the service enqueue time, and 'h' indicates the waiting time required for the earliest submission. Indicates the target compression factor. Indicates the latest submission time.

[0081] It should be noted that the estimated processing time represents the time required from the moment the service is enqueued to the moment the request actually completes the data submission and storage. This time includes the total time spent on internal queuing, business logic processing, and data writing and storage.

[0082] It should be noted that the planned submission time cannot be earlier than the lower bound of the immediately feasible interval to avoid the earliest possible submission time. Similarly, the planned submission time cannot be earlier than the effective advance of the arrival time, which indirectly ensures that the planned submission time is not earlier than the earliest submission time and that the planned submission time must fall before the latest submission time. This ensures that the subsequent actual submission action will not exceed the time range allowed by the token and avoids the situation of submission after expiration.

[0083] In one embodiment of the present invention, the maximum value between the lower bound of the immediately feasible interval and the current time is taken as the waiting baseline. Then, the difference between the planned submission time and the waiting baseline is calculated, and the maximum value between 0 and the difference is taken as the waiting time. The waiting operation is performed according to the waiting time. When the time reaches the planned submission time, the data submission operation is immediately performed, and the actual submission time of this data submission is recorded. The difference between the actual submission time and the planned submission time is calculated as the scheduling jitter.

[0084] It should be noted that waiting and committing are performed according to the planned commit time, which is no earlier than the lower bound of the immediately feasible interval and no later than the upper bound of the immediately feasible interval. The earliest allowed commit boundary is locked by the waiting baseline, and the latest allowed commit boundary is locked by the early constraint of the planned commit time. Ultimately, the actual commit action must fall within the compliant time interval, avoiding ineffective or expired commits. The non-negative calculation of waiting time avoids early or invalid waiting, ensuring that the planned commit time is accurately reached after waiting, reducing resource waste or commit delays. Scheduling jitter is used to quantify the deviation between the actual commit and the planned commit, providing a clear time trace for each commit action, which can facilitate the reconstruction of the complete timeline from the waiting operation to the commit operation during auditing, and achieve operation traceability.

[0085] In one embodiment of the present invention, the difference between the latest submission time and the actual submission time is calculated to obtain the remaining budget on the expired side; the difference between the actual submission time and the earliest submission time is calculated to obtain the advance amount on the effective side.

[0086] It should be noted that the remaining budget on the expired side represents the available time remaining between the actual submission time and the latest allowed submission boundary. If the difference is positive, it means that the actual submission is before the latest boundary, indicating time redundancy. If the difference is negative, it means that the actual submission exceeds the latest boundary, indicating compliance risk. The advance amount on the effective side represents the offset of the actual submission time relative to the earliest allowed submission boundary. If the difference is positive, it means that the actual submission is after the earliest boundary, meeting the effectiveness requirements. If the difference is negative, it means that the actual submission is earlier than the earliest boundary, indicating compliance risk of an ineffective submission. Both are only involved in compliance measurement and audit traceability and do not directly participate in the calculation of subsequent steps.

[0087] In one embodiment of the present invention, the difference between the actual submission time and the lower bound of the immediate feasible interval is used as the numerator, and the difference between the latest submission time and the lower bound of the immediate feasible interval is used as the denominator. The ratio of the numerator to the denominator is used as the normalized utilization rate. The gateway-side parameters, service-side parameters, service enqueue time, service tolerance, actual submission time, expired remaining budget, effective advance amount, and normalized utilization rate are combined to form an audit vector and persistently stored.

[0088] It should be noted that the normalized utilization rate is used to quantify the relative position of the actual submission time within the immediate feasible interval. When the ratio is close to 0, it indicates that the actual submission time is close to the lower bound of the immediate feasible interval, i.e., close to the earliest possible submission time; when the ratio is close to 1, it indicates that the actual submission time is close to the upper bound of the immediate feasible interval, i.e., close to the latest possible submission time. This ratio can be used to quickly determine the time distribution characteristics of the actual submission within the compliance interval. In addition, an audit vector is constructed to cover the entire process from gateway approval to service queuing to actual submission, including time and budget dimensions. Persistent storage allows for quick retrieval of the entire process parameters in subsequent compliance checks and issue tracing, meeting the needs of audit tracing and risk assessment. Common storage methods include writing to a dedicated audit log file, storing in a relational database or time-series database, and backing up to a distributed storage system.

[0089] In one embodiment of the present invention, the difference between the actual submission time and the service enqueue time is calculated to obtain the actual processing time; the product of the smoothing coefficient and the currently stored exponential moving average is calculated to obtain the first product; the difference between 1 and the smoothing coefficient is calculated, and the product of the difference and the actual processing time is calculated to obtain the second product; the sum of the first product and the second product is calculated to obtain the updated exponential moving average.

[0090] It should be noted that the smoothing coefficient is a custom parameter ranging from 0 to 1. Preferably, the smoothing coefficient is set to 0.9. When the smoothing coefficient is close to 1, the calculation of the updated exponential moving average will focus more on historical data, resulting in a stronger smoothing effect and reducing the impact of single abnormal time consumption on the results. When the smoothing coefficient is close to 0, it will focus more on the current actual time consumption data, making it more sensitive to the latest time consumption changes, but the smoothing effect is weaker and it is more susceptible to short-term fluctuations. The exponential moving average achieves smoothing of data fluctuations by assigning different weights to data at different time points, obtaining a more stable time consumption baseline and avoiding the impact of single abnormal data on the overall estimate. The default value of the currently stored exponential moving average used for the initial calculation can be set to the actual processing time of the first request or the industry experience average time consumption of similar requests.

[0091] In one embodiment of the present invention, the difference between the latest submission time and the earliest submission time is calculated to obtain the subsequent write window width; the normalized utilization rate is subtracted from 0.5, and the difference is multiplied by the subsequent write window width to obtain the position offset correction amount; the updated exponential moving average, scheduling jitter and position offset correction amount are added together to obtain the estimated processing time for the next round.

[0092] Specifically, the estimated processing time for the next round. The calculation formula is as follows:

[0093] ,in This represents the updated exponential moving average. Indicates scheduling jitter. U represents the normalization utilization rate, U represents the latest submission time, and L represents the earliest submission time.

[0094] It should be noted that the updated exponential moving average is a stable time baseline formed by balancing historical processing times with current actual processing times; scheduling jitter is the time deviation between the actual submission time and the planned submission time in the previous round; the position offset correction is an amount used to adjust the estimate based on the position of the actual submission in the previous round within the immediate feasible interval; the updated exponential moving average, scheduling jitter, and position offset correction are added together to integrate the stable time baseline, compensate for fluctuations in actual submissions, and make fine adjustments based on the submission position, thereby forming the estimated processing time for the next round.

[0095] It should be noted that the next round of processing time estimation is directly applied to step S103. This estimation replaces the processing time estimation output by the processing time prediction model. Combined with the expired remaining budget and the effective lead time at the arrival time, it helps to calculate the compression factor and finally generate the planned submission time. The next round of processing time estimation integrates the stable baseline of historical processing time, the compensation amount for the scheduling jitter in the previous round, and the fine-tuning amount of the submission position, which is closer to the actual execution situation than the initial model estimation. Applying it to step S103 makes the generated planned submission time more consistent with the real business scenario, avoiding the need for long waiting times due to estimation deviations or exceeding the compliance boundary due to the planned submission time being too early, thereby reducing resource waste and the risk of overdue, and improving the stability and compliance of the entire scheduling process.

[0096] In one embodiment of the present invention, such as Figure 3 As shown, a user permission verification and data update system includes:

[0097] The gateway-side parameter calculation module 301 is used to obtain gateway-side parameters when the user permission verification is passed, calculate the expired remaining budget and effective advance amount on the gateway side, and pass them to the resource service with the request.

[0098] The service-side parameter calculation module 302 is used to record the service enqueue time when the resource service receives a request, and obtain the gateway-side parameters and service tolerance. Based on this, the service-side parameters are calculated, and the expired remaining budget and effective lead time at the arrival time are converted.

[0099] The planned submission time generation module 303 is used to obtain the estimated processing time through the processing time prediction model, calculate the compression factor based on the overdue remaining budget and the effective lead time at the arrival time, and generate the planned submission time.

[0100] The scheduling jitter calculation module 304 is used to perform waiting and submission within the upper and lower bounds of the immediate feasible interval according to the planned submission time, obtain the actual submission time and record the scheduling jitter.

[0101] Audit vector construction module 305 is used to calculate the normalized utilization rate, the remaining budget on the expired side and the advance amount on the effective side based on the actual submission time, the earliest submission time, and the latest submission time, and to construct and persist the audit vector.

[0102] The processing time estimation module 306 is used to obtain the actual processing time based on the actual submission time and the service enqueue time, update the exponential moving average, and generate the next round of processing time estimation value.

[0103] It should be noted that the interval and threshold sizes are set for ease of comparison. The size of the threshold depends on the amount of sample data and the base number set by those skilled in the art for each set of sample data, as long as it does not affect the proportional relationship between the parameter and the quantized value. Furthermore, the above formulas are all dimensionless calculations, and the formulas are derived from software simulations using a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

[0104] The embodiments of this example have been described above. However, this example is not limited to the specific implementation methods described above. The specific implementation methods described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms based on the guidance of this example, and all of them are within the protection scope of this example.

Claims

1. A method for user permission verification and data update, characterized in that, Includes the following steps: Step S101: Obtain gateway-side parameters when the user permission verification is successful. The gateway-side parameters include: gateway access time, token expiration time, token effective time, and gateway tolerance. Based on this, the expired remaining budget and activation lead time on the gateway side are calculated and transmitted to the resource service with the request; in: The remaining budget for expiration on the gateway side is calculated as follows: the sum of the token expiration time and the gateway tolerance is calculated, and then the difference between this sum and the gateway release time is calculated. The maximum value between 0 and this difference is taken. The gateway-side lead time is calculated as follows: the difference between the token activation time and the gateway tolerance is calculated, and then the gateway release time is subtracted from the difference. Step S102: When the resource service receives a request, record the service enqueue time, obtain the gateway side parameters and service tolerance, calculate the service side parameters accordingly, and convert the expired remaining budget and effective lead time at the arrival time. Server-side parameters include: path latency, earliest commit time, latest commit time, and upper and lower bounds of the immediate feasible interval; in: The expired remaining budget at the arrival time is obtained by calculating the difference between the expired remaining budget on the gateway side and the path delay; The effective advance time of arrival is calculated by summing the effective advance time at the gateway side and the path delay. Step S103: Obtain the estimated processing time through the processing time prediction model, calculate the compression factor based on the overdue remaining budget and the effective lead time at the arrival time, and generate the plan submission time. in: The compression factor is calculated as follows: First, calculate the difference between the latest submission time and the service enqueue time. Then, calculate the ratio of this difference to the processing time. Take the minimum value between 1 and this ratio to obtain the service-side compression factor. Calculate the ratio of the expired remaining budget at the arrival time to the estimated processing time. Take the minimum value between 1 and this ratio to obtain the gateway-side compression factor. Take the minimum value between the service-side compression factor and the gateway-side compression factor to obtain the target compression factor. The planned submission time is generated as follows: First, calculate the sum of the service enqueue time and the waiting time required for the earliest submission. Then, add the product of the target compression factor and the estimated processing time to this sum. Take the minimum value between this calculation result and the latest submission time to obtain the planned submission time. Step S104: According to the planned submission time, perform waiting and submission within the upper and lower bounds of the immediate feasible interval, obtain the actual submission time and record the scheduling jitter; Step S105: Calculate the normalized utilization rate, the remaining budget on the expired side and the advance amount on the effective side based on the actual submission time, the earliest submission time, and the latest submission time; construct the audit vector and persist it. in: The normalized utilization rate is calculated as follows: the difference between the actual submission time and the lower bound of the immediate feasible interval is used as the numerator, and the difference between the latest submission time and the lower bound of the immediate feasible interval is used as the denominator. The ratio of the numerator to the denominator is the normalized utilization rate. The remaining budget on the expired side is obtained by calculating the difference between the latest commit time and the actual commit time; The effective side advance amount is obtained by calculating the difference between the actual commit time and the earliest commit time; Step S106: Obtain the actual processing time based on the actual submission time and the service enqueue time, update the exponential moving average and generate the estimated processing time for the next round. in: The updated exponential moving average is as follows: calculate the difference between the actual submission time and the service enqueue time to obtain the actual processing time; calculate the product of the smoothing coefficient and the currently stored exponential moving average to obtain the first product; calculate the difference between 1 and the smoothing coefficient, and then calculate the product of this difference and the actual processing time to obtain the second product; calculate the sum of the first product and the second product to obtain the result. The estimated processing time for the next round is as follows: calculate the difference between the latest and earliest submission times to obtain the post-submission write window width; first subtract the normalized utilization rate from 0.5, then multiply the difference by the post-submission write window width to obtain the position offset correction; add the updated exponential moving average, scheduling jitter, and position offset correction to obtain the result.

2. The user permission verification and data update method according to claim 1, characterized in that, The gateway-side parameters, along with the gateway-side expired remaining budget and effective lead time, are combined to form a time budget vector, which is then set to read-only and passed to the resource service with the request.

3. The user permission verification and data update method according to claim 1, characterized in that, Step S102 includes the following steps: Step S201: Calculate the difference between the service enqueue time and the gateway release time as the path delay; Step S202: Calculate the sum of the gateway tolerance and the service tolerance, and then subtract this sum from the token effective time to obtain the earliest submission time; Step S203: Calculate the sum of the gateway tolerance and the service tolerance, and then add the token expiration time to the sum to obtain the latest submission time; Step S204: Take the maximum value between the earliest submission time and the service enqueue time as the lower bound of the immediate feasible interval, and take the latest submission time as the upper bound of the immediate feasible interval.

4. The user permission verification and data update method according to claim 1, characterized in that, The difference between the earliest submission time and the service enqueue time is calculated, and the maximum value between 0 and this difference is taken to obtain the waiting time required for the earliest submission. The input of the processing time prediction model is a feature vector representation composed of the average processing time of historical requests of the same type, the data size of the current request, the current CPU utilization of the resource service, and the business type of the current request. During the operation of the resource service, the feature vector of each request is recorded, and the service enqueue time and the actual submission time of the request are recorded synchronously. The difference between the actual submission time and the service enqueue time is calculated and used as the sample label of a training sample. The processing time prediction model is built based on a multilayer perceptron.

5. The user permission verification and data update method according to claim 1, characterized in that, Take the maximum value between the lower bound of the immediate feasible interval and the current time as the waiting baseline, then calculate the difference between the plan submission time and the waiting baseline, and take the maximum value between 0 and the difference as the waiting time; The waiting operation is performed according to the waiting time. When the time reaches the planned submission time, the data submission operation is performed immediately, and the actual submission time of this data submission is recorded. Calculate the difference between the actual submission time and the planned submission time as the scheduling jitter.

6. The user permission verification and data update method according to claim 1, characterized in that, The gateway-side parameters, service-side parameters, service enqueue time, service tolerance, actual commit time, expired remaining budget, effective advance amount, and normalization utilization rate are combined to form an audit vector and persistently stored.

7. A user permission verification and data update system, characterized in that, Performing a user permission verification and data update method as described in any one of claims 1 to 6, comprising: The gateway-side parameter calculation module is used to obtain gateway-side parameters when the user's permission verification is successful, calculate the expired remaining budget and effective advance amount on the gateway side, and pass them to the resource service with the request. The service-side parameter calculation module is used to record the service enqueue time when the resource service receives a request, obtain the gateway-side parameters and service tolerance, calculate the service-side parameters based on these parameters, and convert them into the expired remaining budget and effective lead time at the arrival time. The planned submission time generation module is used to obtain the estimated processing time through the processing time prediction model, calculate the compression factor based on the overdue remaining budget and the effective lead time at the arrival time, and generate the planned submission time. The scheduling jitter calculation module is used to perform waiting and submission within the upper and lower bounds of the immediate feasible interval according to the planned submission time, obtain the actual submission time and record the scheduling jitter. The audit vector construction module is used to calculate the normalized utilization rate, the remaining budget on the expired side and the advance amount on the effective side based on the actual submission time, the earliest submission time, and the latest submission time, and to construct and persist the audit vector. The processing time estimation module is used to obtain the actual processing time based on the actual submission time and the service enqueue time, update the exponential moving average, and generate the processing time estimate for the next round.

Images