CN117808602B - Hot account billing method and related device based on sub-account expansion - Google Patents

Abstract

The application relates to the technical field of data processing, and discloses a hot-spot account billing method based on sub-account expansion and a related device. The method comprises the following steps: carrying out concurrent request real-time monitoring on the primary main account to obtain concurrent request data of the primary main account; performing hot spot account judgment on the primary main account according to the concurrent request data, and performing service scene matching on the concurrent request data when the primary main account is a hot spot account to obtain a target service scene; judging whether to split the account of the primary main account or not through a target service scene, if so, splitting the account of the primary main account through a preset load balancing algorithm to obtain a plurality of target sub-accounts; the method comprises the steps of updating data of a plurality of target sub-accounts to obtain a plurality of updated sub-accounts, and updating account data of an initial main account through the plurality of updated sub-accounts to obtain a target main account.

Description

Hot account billing method and related device based on sub-account expansion

Technical Field

The application relates to the field of data processing, in particular to a hot-spot account billing method based on sub-account expansion and a related device.

Background

With the rapid development of the internet and information technology, various online service platforms and financial systems face more and more complex challenges in processing large-scale concurrent requests. The proliferation of user numbers, the diversification of business scenes and the high requirement on real-time performance make the traditional account management mode faced with bottlenecks.

In the prior art, part of systems lack a high-precision means for real-time monitoring of concurrent requests, so that the grasping of the system load condition is not accurate enough. Secondly, some systems rely on static rules too much on judgment of hot spot accounts and service scene matching, lack intelligent decision making capability, and are difficult to deal with changeable service scenes. In addition, the existing system has relatively simple design of account splitting and load balancing algorithms, lacks flexibility and intelligence, and cannot be well adapted to complex and changeable practical application environments. These shortcomings directly limit the performance and stability of the system in high concurrency scenarios.

Disclosure of Invention

The application provides a hot-spot account billing method based on sub-account expansion and a related device, which are used for the efficiency of hot-spot account billing based on sub-account expansion.

In a first aspect, the present application provides a method for billing a hot-spot account based on sub-account extension, where the method for billing a hot-spot account based on sub-account extension includes: carrying out concurrent request real-time monitoring on an initial main account to obtain concurrent request data of the initial main account;

Performing hot spot account judgment on the primary main account according to the concurrent request data, and performing service scene matching on the concurrent request data when the primary main account is a hot spot account to obtain a target service scene;

judging whether to split the account of the primary main account or not through the target service scene, if so, splitting the account of the primary main account through a preset load balancing algorithm to obtain a plurality of target sub-accounts;

And carrying out data updating on the plurality of target sub-accounts to obtain a plurality of updated sub-accounts, and carrying out account data updating on the initial main account through the plurality of updated sub-accounts to obtain the target main account.

With reference to the first aspect, in a first implementation manner of the first aspect of the present application, performing a hot spot account judgment on the primary main account according to the concurrent request data, and performing a service scene matching on the concurrent request data when the primary main account is a hot spot account, to obtain a target service scene, where the method includes:

carrying out data analysis on the concurrent request data to obtain an analysis data set, wherein the analysis data set comprises request time data and request identification data;

Calibrating the request times of the concurrent request data according to the request time data to obtain target request times;

analyzing the data request quantity of the concurrent request data through the request identification data to obtain a target data request quantity;

Carrying out account hotspot value analysis on the target request times and the target data request quantity to obtain a target account hotspot value;

and carrying out hot spot account judgment on the primary main account based on the hot spot value of the target account, and carrying out service scene matching on the concurrent request data when the primary main account is the hot spot account to obtain the target service scene.

With reference to the first aspect, in a second implementation manner of the first aspect of the present application, performing a hotspot account judgment on the primary main account based on the target account hotspot value, and performing service scene matching on the concurrent request data when the primary main account is a hotspot account to obtain the target service scene, where the method includes:

carrying out numerical range analysis on the hot spot value of the target account to obtain a to-be-compared numerical range;

data comparison is carried out on the to-be-compared value range and a preset standard data range, and a comparison result is obtained;

And carrying out hot spot account judgment on the primary main account according to the comparison result, and carrying out service scene matching on the concurrent request data when the primary main account is a hot spot account to obtain the target service scene.

With reference to the first aspect, in a third implementation manner of the first aspect of the present application, the determining, through the target service scenario, whether to split the account of the primary main account, if yes, performing account splitting on the primary main account through a preset load balancing algorithm, to obtain a plurality of target sub-accounts includes:

Extracting the service type of the target service scene to obtain a target service type;

screening account splitting conditions for the target service types to obtain splitting condition data;

And judging whether to split the account of the primary main account according to the splitting condition data, if so, splitting the account of the primary main account by the load balancing algorithm to obtain a plurality of target sub-accounts.

With reference to the first aspect, in a fourth implementation manner of the first aspect of the present application, the performing account splitting on the primary main account by using the load balancing algorithm to obtain a plurality of target sub-accounts includes:

Carrying out account structure construction on the initial main account through the load balancing algorithm to obtain a target account structure;

Creating a sub-account list according to the target account structure, and extracting a plurality of initial sub-accounts and index data of each initial sub-account from the target sub-account list;

performing weight matching on each primary sub-account to obtain weight data of each primary sub-account;

Defining a polling pointer structure according to the load balancing algorithm to obtain a target polling pointer structure;

and carrying out account splitting on a plurality of primary sub-accounts through the target polling pointer structure based on the index data of each primary sub-account and the weight data of each primary sub-account to obtain a plurality of target sub-accounts.

With reference to the first aspect, in a fifth implementation manner of the first aspect of the present application, the performing, by using the target polling pointer structure, account splitting on the plurality of primary sub-accounts based on the index data of each primary sub-account and the weight data of each primary sub-account to obtain a plurality of target sub-accounts includes:

Based on the target polling pointer structure and the index data of each primary sub-account, acquiring real-time performance indexes of a plurality of primary sub-accounts through the target polling pointer to obtain real-time performance index data of each primary sub-account;

Carrying out account change trend prediction on the real-time performance index data of each primary sub-account to obtain a plurality of change trend data;

According to the change trend data, carrying out weight data correction on each primary sub-account to obtain corrected weight data of each primary sub-account;

Constructing an account queue through index data of each primary sub-account to obtain a target account queue;

And carrying out account splitting on the target account queue through the target polling finger based on the correction weight data of each initial sub-account to obtain a plurality of target sub-accounts.

With reference to the first aspect, in a sixth implementation manner of the first aspect of the present application, the updating the data on the plurality of target sub-accounts to obtain a plurality of updated sub-accounts, updating the account data on the initial main account by the plurality of updated sub-accounts to obtain a target main account includes:

analyzing the data updating items of each target sub-account to obtain the data updating items of each target sub-account;

Based on the data update item of each target sub-account, carrying out data update content matching on each target sub-account to obtain an update content set;

Data updating is carried out on the target sub-accounts through the updated content set, so that a plurality of updated sub-accounts are obtained;

and updating account data of the initial main account through a plurality of updated sub-accounts to obtain a target main account.

In a second aspect, the present application provides a sub-account extension-based hot spot account billing apparatus, the sub-account extension-based hot spot account billing apparatus comprising:

the monitoring module is used for carrying out concurrent request real-time monitoring on the primary main account to obtain concurrent request data of the primary main account;

the matching module is used for judging the hot spot account of the primary main account according to the concurrent request data, and carrying out service scene matching on the concurrent request data when the primary main account is the hot spot account to obtain a target service scene;

The splitting module is used for judging whether to split the account of the primary main account through the target service scene, if so, the account of the primary main account is split through a preset load balancing algorithm, and a plurality of target sub-accounts are obtained;

And the updating module is used for carrying out data updating on the plurality of target sub-accounts to obtain a plurality of updated sub-accounts, and carrying out account data updating on the initial main account through the plurality of updated sub-accounts to obtain the target main account.

A third aspect of the present application provides a hot-spot account billing apparatus based on sub-account extension, comprising: a memory and at least one processor, the memory having instructions stored therein; the at least one processor invokes the instructions in the memory to cause the sub-account extension-based hotspot account billing device to perform the sub-account extension-based hotspot account billing method described above.

A fourth aspect of the application provides a computer readable storage medium having instructions stored therein that, when executed on a computer, cause the computer to perform the sub-account extension based hot spot account billing method described above.

In the technical scheme provided by the application, the concurrent request real-time monitoring is carried out on the primary main account to obtain the concurrent request data of the primary main account; performing hot spot account judgment on the primary main account according to the concurrent request data, and performing service scene matching on the concurrent request data when the primary main account is a hot spot account to obtain a target service scene; judging whether to split the account of the primary main account or not through a target service scene, if so, splitting the account of the primary main account through a preset load balancing algorithm to obtain a plurality of target sub-accounts; and updating the data of the plurality of target sub-accounts to obtain a plurality of updated sub-accounts, and updating the account data of the initial main account through the plurality of updated sub-accounts to obtain the target main account. In the scheme of the application, the concurrent request data of the primary main account can be obtained in real time by carrying out the concurrent request real-time monitoring on the primary main account. Through analysis of concurrent request data, hot spot account judgment of the primary main account is achieved. By analyzing indexes such as the request times, the data request quantity and the like, the feature can accurately judge whether the main account is in a hot spot state. The accurate definition of the hot spot accounts enables accounts with higher loads to be timely identified, so that high-load scenes can be better dealt with. The judgment of the hot spot account is not only the reflection of the account state, but also the intelligent response to the whole load. And when the primary main account is judged to be a hot spot account, obtaining a target service scene by carrying out service scene matching on the concurrent request data. This feature enables a deep understanding of business needs to better make subsequent account splitting decisions. The accuracy of the service scene matching is directly related to the rationality of the subsequent decision, and whether the account splitting is carried out on the primary main account is judged through the target service scene. The flexibility of the decision comes from the deep understanding of the business scenario, and whether to split the account can be decided according to specific business requirements. Meanwhile, in order to realize load balancing after splitting, a preset load balancing algorithm is adopted. The characteristic ensures that each sub-account can share the load more uniformly in the account splitting process, and the overall stability and performance are improved. And updating the data of the plurality of target sub-accounts, and updating the account data of the initial main account through the updated sub-accounts to obtain the target main account. This feature ensures that the state of the primary account after splitting and updating is accurate and consistent. Meanwhile, the concurrent updating of a plurality of target sub-accounts enables a large number of concurrent requests to be processed more efficiently, and concurrent processing capacity is improved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for the description of the embodiments will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present invention, and other drawings may be obtained based on these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic diagram of one embodiment of a method for hot-spot account billing based on sub-account expansion in an embodiment of the application;

FIG. 2 is a schematic diagram of an embodiment of a sub-account extension-based hot spot account billing apparatus according to an embodiment of the application.

Detailed Description

The embodiment of the application provides a hot-spot account billing method based on sub-account expansion and a related device. The terms "first," "second," "third," "fourth" and the like in the description and in the claims and in the above drawings, if any, are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments described herein may be implemented in other sequences than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed or inherent to such process, method, article, or apparatus.

For ease of understanding, a specific flow of an embodiment of the present application is described below with reference to fig. 1, where an embodiment of a hot-spot account billing method based on sub-account expansion in an embodiment of the present application includes:

step S101, carrying out concurrent request real-time monitoring on an initial main account to obtain concurrent request data of the initial main account;

It will be appreciated that the executing entity of the present application may be a sub-account extension-based hot spot account billing device, or may be a terminal or a server, which is not limited herein. The embodiment of the application is described by taking a server as an execution main body as an example.

Specifically, firstly, an efficient monitoring system is constructed, and the system should integrate real-time data acquisition and analysis functions so as to continuously track and record concurrent requests of a main account. All requested data initiated with respect to the primary account can be captured and sent in real time to the central processing system by deploying data collection agents or listeners to the critical network nodes or servers. These data, including key indicators of request timestamp, frequency, duration, origin, request type, etc., can provide a comprehensive view to analyze account behavior. The central processing system then analyzes and processes the collected data in real time using data processing capabilities and efficient algorithms. The system may employ stream processing techniques such as APACHE KAFKA or APACHE FLINK that are capable of handling high-speed, large-volume data streams and support complex event processing and real-time analysis. By setting specific rules and thresholds, the system can alert in real-time to abnormal request patterns, surges in request volume, or other indicia that an account is hot. Finally, the accuracy and the prediction capability of the monitoring are further improved by integrating a machine learning algorithm. The algorithms can automatically adjust thresholds and recognition patterns based on historical data, thereby enabling the system to adapt to changing request patterns and business scenarios. By the method, the system can monitor concurrent requests of the main account in real time, and can dynamically identify and adapt to various complex scenes, so that reliable and detailed data support is provided for subsequent hot spot account judgment and service scene matching.

Step S102, carrying out hot spot account judgment on the primary main account according to the concurrent request data, and carrying out service scene matching on the concurrent request data when the primary main account is the hot spot account to obtain a target service scene;

Specifically, first, data analysis is performed on the concurrent request data, and key information is extracted from a large amount of concurrent request data so as to perform deep analysis. Each request is marked and recorded, including key information such as the time and unique identifier of the request, which constitutes an analysis dataset. Next, the request time data in the analysis data sets is used for calibrating the request times, and the total number of requests in a specific time period is calculated, so that the activity degree of the account is estimated. Meanwhile, the concurrent request quantity is analyzed by using the request identification data, which comprises multi-dimensional analysis of the request size, the type, the user behavior and the like, so that the target data request quantity is obtained. This reveals the request nature of the account and the user behavior pattern, providing a basis for subsequent analysis. And then, combining the target request times and the target data request quantity to analyze the account hot spot value. This analysis process aims to comprehensively consider the number of requests and the amount of requests to determine the liveness of the account and the potential hot spot level. By setting specific thresholds and parameters, the system can determine which accounts show abnormally active behavior for a specific period of time, thereby marking them as hot spot accounts. And finally, after the primary main account is judged to be the hot spot account, carrying out service scene matching on the concurrent request data. Data analysis and pattern recognition techniques, such as machine learning and natural language processing algorithms, are utilized to identify specific patterns and trends in account request data. These patterns and trends reflect the behavior characteristics and business needs of the user, helping the system to accurately match to the target business scenario.

First, the target account hotspot values are subjected to numerical range analysis, and the values are placed in different ranges or categories to facilitate further analysis. Such numerical range analysis helps to understand how account behavior varies under different parameters, such as differences in behavior during peak hours and off-peak hours, or differences between ordinary days and holidays, etc. And then, comparing the numerical value ranges to be compared with a preset standard data range. These standard data ranges are formulated based on historical data, industry standards, or expected user behavior patterns, which represent expected behavior patterns of the account under normal operation. By comparing the actual observed hotspot values with these standard ranges, the system can determine which accounts behave away from the normal mode, thereby becoming hotspot accounts. This comparison is a key factor in determining whether an account is marked as a hotspot. If the comparison result shows that the hot spot value of a certain account is beyond the normal range, the system judges the account as the hot spot account. The judging method is not only based on static data comparison, but also can be combined with dynamic behavior analysis to improve the accuracy and sensitivity of judgment. Once the primary account is marked as a hot spot account, business scenario matching is performed on the concurrent request data of these accounts. This matching process is accomplished by analyzing various factors such as the specific content of the concurrent request, the user behavior pattern, the frequency of the request, etc. Specific business scenarios are identified and matched by data analysis techniques, such as machine learning algorithms. This enables not only a determination of which accounts are hot spot accounts, but also an understanding of the specific needs and behavioral characteristics of these accounts.

Step S103, judging whether to split the account of the primary main account through a target service scene, if so, splitting the account of the primary main account through a preset load balancing algorithm to obtain a plurality of target sub-accounts;

Specifically, firstly, extracting a service type of a target service scene to obtain the target service type. Including analysis of account activity patterns, request types, user behavior, etc., by which the system can identify core features of business scenarios, such as e-commerce transactions, online service requests, or financial operations, etc. While different traffic types require different processing schemes and resource allocation. And then, screening account splitting conditions for the target service types to obtain splitting condition data, wherein the splitting condition data comprises analysis of processing requirements, resource use conditions and user behavior patterns of different service types so as to determine whether an account needs to be split or not and how to split. The generation of the split condition data involves comprehensive consideration of different characteristics of the service type, such as the concurrency of requests, the data amount processed, the response time requirement and the like. And judging whether to split the primary main account according to the split condition data. If it is determined that splitting is required, a preset load balancing algorithm is employed to perform this process. The design of this algorithm is intended to ensure that each sub-account is able to share the load of the original account evenly, while maintaining efficient and stable operation. In the implementation of splitting, the system can distribute the data and functions of the original account to a plurality of sub-accounts according to the service type and splitting conditions, so that the load pressure of a single account can be effectively reduced, and the overall performance and response capability of the system are improved.

Firstly, constructing an account structure of an initial main account through a load balancing algorithm, and creating an account structure capable of efficiently distributing requests and processing loads, so that each sub-account can uniformly share the overall workload. The construction of the target account structure needs to comprehensively consider various factors such as the service type, processing capacity, historical load data and the like of the account so as to form a balanced and efficient account system. Next, a sub-account list is created from this newly constructed target account structure. In this list, the system assigns a unique index data to each primary sub-account, which helps to quickly identify and locate individual accounts in subsequent processing. Each primary sub-account is split from the primary account and contains specific business and data processing functions. The index data of these primary sub-accounts not only helps account management, but is also critical to achieving load balancing. Next, the system performs weight matching on each primary sub-account, and assigns weight data to each account. The assignment of weight data is based on the processing power and expected load of each sub-account, with the aim of ensuring that each account can take on a workload matching its power. Weight matching ensures the efficiency and stability of the system as a whole. The system then defines a poll pointer structure according to a load balancing algorithm, which is a common load balancing strategy by which the system can uniformly distribute requests to different sub-accounts. The design of the target poll pointer structure allows for even distribution among accounts, as well as ensures that each request is processed quickly and accurately. Finally, the accounts are split by the target poll pointer structure based on the index data and the weight data of each primary sub-account. In this process, the system will determine how to assign the business and data of the main account to each sub-account based on the weight and index of each account. The split strategy based on the weight and the polling not only improves the processing efficiency, but also enhances the stability and the response capability of the system when facing high concurrent requests.

First, based on the target polling pointer structure and the index data of each primary sub-account, the collection of real-time performance indicators is performed. The performance of each primary sub-account is monitored in real time, and the performance comprises key indexes such as response time, processing capacity, load condition and the like. By collecting the performance indexes in real time, the system can know the running condition of each account in time. These real-time performance index data are then used to make account trend predictions. The performance change trend of each account in a future period of time is predicted through data analysis and prediction algorithms, such as time sequence analysis, a machine learning model and the like. Such predictions help to adjust account processing power and resource allocation, as it helps the system to identify problems and bottlenecks in advance, taking precautions. Then, the weight data of each primary sub-account is corrected based on the predicted trend data. The correction of the weight data is used for ensuring that the load balance of the account is matched with the actual performance, and ensuring the efficient and stable operation of the whole system. If the performance of an account is expected to drop, the system will reduce its load, and conversely, increase the amount of requests it processes. The dynamic adjustment mechanism enables the system to flexibly cope with changing workload and optimize the utilization of resources. Then, account queues are built through index data of each primary sub-account. The account queues are constructed by taking into account not only the index and the corrected weight of each account, but also the interrelationship and coordination among the accounts. The design of the target account queue allows requests to be efficiently distributed among different accounts according to predetermined rules and priorities. And finally, carrying out account splitting on the target account queue through the target polling pointer based on the correction weight data of each initial sub-account, thereby obtaining a plurality of target sub-accounts. By adjusting the load of each account, the overall account system is ensured to be efficient and stable in handling a large number of requests.

Step S104, data updating is carried out on the plurality of target sub-accounts to obtain a plurality of updated sub-accounts, and account data updating is carried out on the initial main account through the plurality of updated sub-accounts to obtain the target main account.

Specifically, first, data update item analysis is performed on each target sub-account, and data items needing to be updated or modified in each account are identified. This includes transaction records for the account, user information, account status, etc. Next, matching of the data update contents is performed according to the data update item of each target sub-account. The system will analyze the specific update requirements of each sub-account and match those requirements with the actual stored data. Through the data query and processing algorithm, it is ensured that data corresponding to the update requirements can be found quickly and accurately. The generation of the update content collection is the core of the overall data update process, which contains all the necessary information to effectively update the sub-account data. Then, the data of the plurality of target sub-accounts is updated by using the updated content sets. The data updating process comprises operations of modifying database records, synchronizing various information, updating account states and the like. This requires efficient data processing capability of the system and a stable and reliable data synchronization mechanism to avoid data inconsistency or update errors. And finally, updating account data of the primary main account through the updated sub-accounts to obtain a target main account, so as to ensure that all data changes from the sub-accounts to the main account can be correctly reflected and synchronized. This includes not only data updates within a single account, but also data integration and reconciliation between accounts.

In the embodiment of the application, the concurrent request real-time monitoring is carried out on the primary main account to obtain the concurrent request data of the primary main account; performing hot spot account judgment on the primary main account according to the concurrent request data, and performing service scene matching on the concurrent request data when the primary main account is a hot spot account to obtain a target service scene; judging whether to split the account of the primary main account or not through a target service scene, if so, splitting the account of the primary main account through a preset load balancing algorithm to obtain a plurality of target sub-accounts; and updating the data of the plurality of target sub-accounts to obtain a plurality of updated sub-accounts, and updating the account data of the initial main account through the plurality of updated sub-accounts to obtain the target main account. In the scheme of the application, the concurrent request data of the primary main account can be obtained in real time by carrying out the concurrent request real-time monitoring on the primary main account. Through analysis of concurrent request data, hot spot account judgment of the primary main account is achieved. By analyzing indexes such as the request times, the data request quantity and the like, the feature can accurately judge whether the main account is in a hot spot state. The accurate definition of the hot spot accounts enables accounts with higher loads to be timely identified, so that high-load scenes can be better dealt with. The judgment of the hot spot account is not only the reflection of the account state, but also the intelligent response to the whole load. And when the primary main account is judged to be a hot spot account, obtaining a target service scene by carrying out service scene matching on the concurrent request data. This feature enables a deep understanding of business needs to better make subsequent account splitting decisions. The accuracy of the service scene matching is directly related to the rationality of the subsequent decision, and whether the account splitting is carried out on the primary main account is judged through the target service scene. The flexibility of the decision comes from the deep understanding of the business scenario, and whether to split the account can be decided according to specific business requirements. Meanwhile, in order to realize load balancing after splitting, a preset load balancing algorithm is adopted. The characteristic ensures that each sub-account can share the load more uniformly in the account splitting process, and the overall stability and performance are improved. And updating the data of the plurality of target sub-accounts, and updating the account data of the initial main account through the updated sub-accounts to obtain the target main account. This feature ensures that the state of the primary account after splitting and updating is accurate and consistent. Meanwhile, the concurrent updating of a plurality of target sub-accounts enables a large number of concurrent requests to be processed more efficiently, and concurrent processing capacity is improved.

In a specific embodiment, the process of executing step S102 may specifically include the following steps:

(1) Carrying out data analysis on the concurrent request data to obtain an analysis data set, wherein the analysis data set comprises request time data and request identification data;

(2) Calibrating the request times of the concurrent request data through the request time data to obtain target request times;

(3) Analyzing the data request quantity of the concurrent request data through the request identification data to obtain a target data request quantity;

(4) Carrying out account hot spot numerical analysis on the target request times and the target data request quantity to obtain a target account hot spot numerical value;

(5) And carrying out hot-spot account judgment on the primary main account based on the hot-spot value of the target account, and carrying out service scene matching on the concurrent request data when the primary main account is the hot-spot account to obtain a target service scene.

Specifically, first, data parsing is performed on the concurrent request data to generate a parsed data set, where the parsed data set includes two key components: request time data and request identification data. The request time data records the specific times each request occurred, helping to understand the request pattern and identify peak hours. At the same time, the request identification data provides information about the type and source of each request. This includes the type of service requested, the geographic location of the user, the type of device used, etc. By analyzing these identification data, the system can understand the different demands of different types of requests for resources, e.g., some requests require a large amount of data processing, while others rely more on quick responses. Based on the two types of data, the system performs request times calibration on the concurrent request data, and obtains target request times by calculating the total number of requests in a specific time period. By accurately identifying and calculating the request frequency, it is convenient to determine which periods are request peaks and which periods are relatively few. Then, data request amount analysis is performed on the concurrent request data by using the request identification data. The data load of each request is evaluated to obtain a target data request amount. Such analysis may reveal which types of requests are data intensive, thereby putting a greater stress on system resources. In this way, the system can better understand the needs of different requests for resources and make appropriate optimizations accordingly. And then, carrying out account hot spot numerical analysis, and comprehensively considering the target request times and the target data request quantity. Account hotspot value is a comprehensive assessment that quantifies the flow and data request strength of an account. When the hotspot value of a certain account exceeds a preset threshold, the system may mark it as a hotspot account. This helps the system identify those accounts that cause performance bottlenecks and take measures accordingly, such as increasing resource allocation or performing deeper monitoring. And finally, carrying out hot-spot account judgment on the primary main account based on the hot-spot value of the target account, and carrying out service scene matching on the concurrent request data when the primary main account is the hot-spot account. And determining the main service scene of the hot spot account by analyzing the specific content of the request data. For example, the system may find that most of the requests for a certain hotspot account are focused on a particular type of service, or that the user is primarily from a certain geographic area. By this matching, the system is able to more accurately identify not only hot spot accounts, but also understand the specific needs and behavior patterns of these accounts.

In a specific embodiment, the process of performing the service scene matching step on the concurrent request data may specifically include the following steps:

(1) Carrying out numerical range analysis on the hot spot value of the target account to obtain a to-be-compared numerical range;

(2) Data comparison is carried out on the to-be-compared value range and a preset standard data range, and a comparison result is obtained;

(3) And carrying out hot spot account judgment on the primary main account according to the comparison result, and carrying out service scene matching on the concurrent request data when the primary main account is the hot spot account to obtain a target service scene.

Specifically, first, a numerical range analysis is performed on the target account hotspot values. The activity data, such as request frequency, data transfer amount, etc., of each account is analyzed to determine its hotspot value. This value is a quantized representation of the current activity level of the account, reflecting the activity level of the account over a particular time. And then, comparing the hot spot numerical ranges to be compared with a preset standard data range. These standard data ranges are set based on historical data, industry standards, or expected patterns of user behavior. They represent the expected activity level of an account under normal conditions. By comparing the actual observed hotspot values with these standard ranges, the system can determine which accounts behave away from the normal mode, thereby becoming hotspot accounts. Once the system judges that the primary main account is a hot spot account according to the comparison result, then service scene matching is carried out on concurrent request data of the accounts. This matching process requires the use of data analysis techniques, such as machine learning algorithms, to identify specific patterns and trends in the account request data. Through this analysis, the system is able to recognize not only hot spot accounts, but also specific business needs and behavioral characteristics of those accounts.

In a specific embodiment, the process of executing step S103 may specifically include the following steps:

(1) Extracting service types from the target service scene to obtain target service types;

(2) Carrying out account splitting condition screening on the target service type to obtain splitting condition data;

(3) And judging whether to split the primary main account according to the splitting condition data, if so, splitting the primary main account by a load balancing algorithm to obtain a plurality of target sub-accounts.

Specifically, first, a target service scenario in a large number of concurrent requests is analyzed, and different service types are extracted from the target service scenario. This extraction process relies on data analysis techniques to identify and classify different traffic types by analyzing the nature of the request, such as frequency, amount of data, and user interaction pattern. The identified traffic types include a variety of different operations and interactions, each type having its particular resource requirements and processing priorities. The conditions for account splitting are then screened based on these identified traffic types. Assessing the demand for resources for each traffic type, for example, some traffic types require more computing resources, while other types are more focused on data storage or network bandwidth. The system will analyze the characteristics of these traffic types to determine which traffic types become performance bottlenecks or require additional resources in certain situations. In addition, how to balance the loads of different service types by splitting accounts is also considered to improve the efficiency and response capability of the overall system. Then, it is determined whether to split the primary main account or not based on the split condition data. This decision is based on a comprehensive assessment of the efficiency of the current account structure, and the system will consider whether the processing efficiency can be significantly improved or the resource bottleneck reduced by splitting. If it is determined that splitting is necessary, the system initiates a splitting process, which typically involves using a load balancing algorithm to optimize resource allocation and management. And finally, applying a load balancing algorithm to split the account of the primary main account to form a plurality of target sub-accounts. In this process, the functions and data of the primary account will be assigned to the newly created sub-account according to the specific requirements of each service type. The load balancing algorithm ensures that each sub-account bears the appropriate load so that the overall system can operate efficiently and in balance. By the method, the system not only can dynamically adjust the account structure according to the actual service demand, but also can optimize the resource allocation, thereby improving the service efficiency and the user experience.

In a specific embodiment, the process of performing the account splitting step on the primary main account may specifically include the following steps:

(1) Carrying out account structure construction on the initial main account through a load balancing algorithm to obtain a target account structure;

(2) Creating a sub-account list according to the target account structure, and extracting a plurality of initial sub-accounts and index data of each initial sub-account from the target sub-account list;

(3) Performing weight matching on each primary sub-account to obtain weight data of each primary sub-account;

(4) Defining a polling pointer structure according to a load balancing algorithm to obtain a target polling pointer structure;

(5) And carrying out account splitting on the plurality of primary sub-accounts through the target polling pointer structure based on the index data of each primary sub-account and the weight data of each primary sub-account to obtain a plurality of target sub-accounts.

Specifically, firstly, account structure construction is carried out on an initial main account through a load balancing algorithm, and a target account structure is obtained. The goal is to ensure that all requests and tasks are distributed efficiently and evenly among the individual accounts. The load balancing algorithm takes into account various factors such as the processing power of each account, historical load data, and the type of request expected. For example, if an online service platform processes multiple different types of requests, such as data queries, transaction processing, and user authentication, the system may build account structures based on these different types of processing requirements. The account structure is designed to ensure that each type of request is assigned to the account that is most suitable for handling it, to avoid the situation where one account is overloaded while the other accounts are idle. Next, a sub-account list is created from the target account structure. This list includes all sub-accounts that are newly created from the target account structure, each with their unique functions and responsibilities. The system will assign a unique index data to each sub-account, which will help to quickly and accurately identify and locate individual accounts in subsequent processing. For example, the system may create a sub-account that handles data queries specifically, a sub-account that handles transactions, and a sub-account that handles user authentication, each with a unique index identification. Next, weight matching is performed on each primary sub-account to determine weight data for each account. The weight data reflects the processing power and priority of each account relative to the other accounts. This determines how the request is distributed among the different accounts. In the weight matching process, the system may consider factors such as processing power, historical response time, and expected load for each account. In this way, the system ensures that high load tasks are assigned to accounts with more performance, while low load tasks are assigned to accounts with relatively lower performance. The system then defines a poll pointer structure according to a load balancing algorithm. The poll pointer structure is a common load balancing method that allocates requests to individual accounts in turn in a predetermined order. The design of the target poll pointer structure allows for load balancing among accounts as well as ensures that each request is processed quickly and accurately. For example, the system may design a polling mechanism such that each data query request is assigned to a different query processing sub-account in turn, and each transaction processing request is assigned to a different transaction processing sub-account. Finally, the accounts are split by the target poll pointer structure based on the index data of each primary sub-account and its weight data. During this splitting process, the system will determine how to assign requests and tasks to the sub-accounts based on the weight and index of each account. Through the splitting strategy based on the weight and the polling, the system not only improves the processing efficiency, but also enhances the adaptability to the continuous changing demands under the high concurrency environment.

In a specific embodiment, the process of performing the account splitting step on the plurality of primary sub-accounts may specifically include the steps of:

(1) Based on the target polling pointer structure and the index data of each primary sub-account, acquiring real-time performance indexes of the plurality of primary sub-accounts through the target polling pointer to obtain real-time performance index data of each primary sub-account;

(2) Carrying out account change trend prediction on the real-time performance index data of each primary sub-account to obtain a plurality of change trend data;

(3) According to the multiple change trend data, carrying out weight data correction on each primary sub-account to obtain corrected weight data of each primary sub-account;

(4) Constructing an account queue through index data of each primary sub-account to obtain a target account queue;

(5) And carrying out account splitting on the target account queue through the target polling pointer based on the correction weight data of each initial sub-account to obtain a plurality of target sub-accounts.

Specifically, first, the real-time performance index is collected for each primary sub-account based on the target poll pointer structure and the index data for those accounts. This requires the system to continuously monitor the performance of each sub-account, including key indicators of processing speed, response time, error rate, etc. For example, response time and processing load on different servers are monitored. By collecting these real-time performance data, the system is able to learn about the operating conditions of each sub-account in real-time. Then, account change trend of each primary sub-account is predicted by using the real-time performance index data. Future performance trends for each account are predicted by using time series analysis, machine learning, and other analysis techniques. From these analyses, the system predicts which accounts will be faced with performance degradation or overload issues. Such predictions help to adjust account configuration and load distribution as it can help the system to discover potential problems ahead of time and take action to optimize. Then, the weight data of each primary sub-account is corrected according to the change trend data. The purpose of the weight data correction is to ensure that the load of each account is matched with the performance of each account, so that the stability and the efficiency of the whole system are ensured. For example, if a predicted performance indicator for an account indicates that it cannot withstand future increased loads, the system may decrease the weight of that account, thereby assigning more requests to other more powerful accounts. This dynamic adjustment mechanism enables the system to flexibly cope with changing workload and optimize allocation of resources. And then, constructing an account queue by using the index data of each primary sub-account to form a target account queue. The account queues are constructed taking into account the index and revised weights of each account, as well as the interrelationship and coordination between the accounts. This target account queue is intended to process the requests for access in an optimized order so that each request can be assigned to the most appropriate account for processing. And finally, carrying out account splitting on the target account queue through the target polling pointer based on the correction weight data of each initial sub-account, thereby obtaining a plurality of target sub-accounts. Based on the weight and index of each account, it is decided how to assign requests and tasks to the various sub-accounts. This weight and poll based splitting strategy aims to optimize the response capacity and processing efficiency of the overall system. By the method, the system can ensure that each service type can obtain proper resource support when processing a large number of concurrent requests, and meanwhile, the stability and the efficient operation of the system are maintained.

In a specific embodiment, the process of executing step S104 may specifically include the following steps:

(1) Based on the target polling pointer structure and the index data of each primary sub-account, acquiring real-time performance indexes of the plurality of primary sub-accounts through the target polling pointer to obtain real-time performance index data of each primary sub-account;

(2) Carrying out account change trend prediction on the real-time performance index data of each primary sub-account to obtain a plurality of change trend data;

(3) According to the multiple change trend data, carrying out weight data correction on each primary sub-account to obtain corrected weight data of each primary sub-account;

(4) Constructing an account queue through index data of each primary sub-account to obtain a target account queue;

(5) And carrying out account splitting on the target account queue through the target polling pointer based on the correction weight data of each initial sub-account to obtain a plurality of target sub-accounts.

Specifically, first, the real-time performance index is collected for each primary sub-account based on the target poll pointer structure and the index data of the account. Key performance parameters, such as processing speed, response time, request throughput, etc., for each sub-account are continuously monitored. And then, predicting the account change trend by using the real-time performance index data of each primary sub-account. Future performance trends for each account are analyzed and predicted by machine learning or statistical models. Then, the weight data of each primary sub-account is corrected according to the predicted change trend data. The relative importance and resource allocation of each account in the overall system is adjusted based on the predicted performance changes. For example, reducing the load of servers where some performance is expected to be reduced, while increasing the load of servers where other performance is more stable. This dynamic weight adjustment ensures optimal allocation of resources, improving overall stability and efficiency of the system. Next, a target account queue is constructed from the index data for each of the primary sub-accounts. This queue is constructed based on the weight and index data corrected for each account in order to efficiently utilize system resources when processing requests. Finally, splitting the target account queue through a target polling pointer based on the corrected weight data of each initial sub-account, thereby forming a plurality of target sub-accounts. In this process, the system will decide how to assign requests and tasks to each account based on the weight and index data for those accounts.

The description of the method for billing a hot-spot account based on sub-account extension in the embodiment of the present application is described below, referring to fig. 2, an embodiment of the hot-spot account billing device based on sub-account extension in the embodiment of the present application includes:

The monitoring module 201 is configured to monitor the concurrent request of the primary main account in real time, so as to obtain concurrent request data of the primary main account;

The matching module 202 is configured to perform hot-spot account judgment on the primary main account according to the concurrent request data, and perform service scene matching on the concurrent request data when the primary main account is a hot-spot account, so as to obtain a target service scene;

The splitting module 203 is configured to determine whether to split the account of the primary main account through the target service scenario, if yes, split the account of the primary main account through a preset load balancing algorithm, and obtain a plurality of target sub-accounts;

and the updating module 204 is configured to perform data updating on the plurality of target sub-accounts to obtain a plurality of updated sub-accounts, and perform account data updating on the initial main account through the plurality of updated sub-accounts to obtain a target main account.

Through the cooperation of the components, the concurrent request real-time monitoring is carried out on the primary main account, and the concurrent request data of the primary main account is obtained; performing hot spot account judgment on the primary main account according to the concurrent request data, and performing service scene matching on the concurrent request data when the primary main account is a hot spot account to obtain a target service scene; judging whether to split the account of the primary main account or not through a target service scene, if so, splitting the account of the primary main account through a preset load balancing algorithm to obtain a plurality of target sub-accounts; and updating the data of the plurality of target sub-accounts to obtain a plurality of updated sub-accounts, and updating the account data of the initial main account through the plurality of updated sub-accounts to obtain the target main account. In the scheme of the application, the concurrent request data of the primary main account can be obtained in real time by carrying out the concurrent request real-time monitoring on the primary main account. Through analysis of concurrent request data, hot spot account judgment of the primary main account is achieved. By analyzing indexes such as the request times, the data request quantity and the like, the feature can accurately judge whether the main account is in a hot spot state. The accurate definition of the hot spot accounts enables accounts with higher loads to be timely identified, so that high-load scenes can be better dealt with. The judgment of the hot spot account is not only the reflection of the account state, but also the intelligent response to the whole load. And when the primary main account is judged to be a hot spot account, obtaining a target service scene by carrying out service scene matching on the concurrent request data. This feature enables a deep understanding of business needs to better make subsequent account splitting decisions. The accuracy of the service scene matching is directly related to the rationality of the subsequent decision, and whether the account splitting is carried out on the primary main account is judged through the target service scene. The flexibility of the decision comes from the deep understanding of the business scenario, and whether to split the account can be decided according to specific business requirements. Meanwhile, in order to realize load balancing after splitting, a preset load balancing algorithm is adopted. The characteristic ensures that each sub-account can share the load more uniformly in the account splitting process, and the overall stability and performance are improved. And updating the data of the plurality of target sub-accounts, and updating the account data of the initial main account through the updated sub-accounts to obtain the target main account. This feature ensures that the state of the primary account after splitting and updating is accurate and consistent. Meanwhile, the concurrent updating of a plurality of target sub-accounts enables a large number of concurrent requests to be processed more efficiently, and concurrent processing capacity is improved.

The application also provides a sub-account extension-based hot spot account billing device, which comprises a memory and a processor, wherein the memory stores computer readable instructions which, when executed by the processor, cause the processor to execute the steps of the sub-account extension-based hot spot account billing method in the above embodiments.

The present application also provides a computer readable storage medium, which may be a non-volatile computer readable storage medium, and may also be a volatile computer readable storage medium, where instructions are stored in the computer readable storage medium, when the instructions are executed on a computer, cause the computer to perform the steps of the sub-account extension-based hot spot account billing method.

It will be clearly understood by those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, systems and units may refer to the corresponding processes in the foregoing method embodiments, which are not repeated herein.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be embodied essentially or in part or all of the technical solution or in part in the form of a software product stored in a storage medium, including instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a read-only memory (ROM), a random access memory (random acceS memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

The above embodiments are only for illustrating the technical solution of the present application, and not for limiting the same; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims (4)

1. The hot-spot account billing method based on the sub-account extension is characterized by comprising the following steps of:

The method comprises the steps of carrying out real-time monitoring on concurrent requests of an initial main account to obtain concurrent request data of the initial main account, and specifically comprises the following steps: constructing a monitoring system, integrating real-time data acquisition and analysis functions, continuously tracking and recording concurrent requests of an initial main account, and deploying data acquisition agents which can acquire and send all request data initiated by the initial main account to a central processing system in real time, wherein the request data comprises a request time stamp, a frequency, a duration, a source place and a request type, and the central processing system analyzes and processes the collected request data in real time; the monitoring system alarms in real time on abnormal request modes, the rapid increase of request quantity or marks indicating that the primary main account becomes a hot spot through the set rules and threshold values; automatically adjusting a threshold value and an identification mode according to historical data by integrating a machine learning algorithm;

Performing hot spot account judgment on the primary main account according to the concurrent request data, and performing service scene matching on the concurrent request data when the primary main account is a hot spot account to obtain a target service scene; the method specifically comprises the following steps: carrying out data analysis on the concurrent request data to obtain an analysis data set, wherein the analysis data set comprises request time data and request identification data; calibrating the request times of the concurrent request data according to the request time data to obtain target request times; analyzing the data request quantity of the concurrent request data through the request identification data to obtain a target data request quantity; carrying out account hotspot value analysis on the target request times and the target data request quantity to obtain a target account hotspot value; carrying out numerical range analysis on the hot spot value of the target account to obtain a to-be-compared numerical range; data comparison is carried out on the to-be-compared value range and a preset standard data range, and a comparison result is obtained; performing hot spot account judgment on the primary main account according to the comparison result, and performing service scene matching on the concurrent request data when the primary main account is a hot spot account to obtain the target service scene;

Judging whether to split the account of the primary main account or not through the target service scene, if so, splitting the account of the primary main account through a preset load balancing algorithm to obtain a plurality of target sub-accounts; the method specifically comprises the following steps: extracting the service type of the target service scene to obtain a target service type; screening account splitting conditions for the target service types to obtain splitting condition data; judging whether to split the account of the primary main account according to the splitting condition data, if so, constructing an account structure of the primary main account by the load balancing algorithm to obtain a target account structure; creating a sub-account list according to the target account structure, and extracting a plurality of initial sub-accounts and index data of each initial sub-account from the target sub-account list; performing weight matching on each primary sub-account to obtain weight data of each primary sub-account; defining a polling pointer structure according to the load balancing algorithm to obtain a target polling pointer structure; based on the target polling pointer structure and the index data of each primary sub-account, acquiring real-time performance indexes of a plurality of primary sub-accounts through the target polling pointer to obtain real-time performance index data of each primary sub-account; carrying out account change trend prediction on the real-time performance index data of each primary sub-account to obtain a plurality of change trend data; according to the change trend data, carrying out weight data correction on each primary sub-account to obtain corrected weight data of each primary sub-account; constructing an account queue through index data of each primary sub-account to obtain a target account queue; based on the correction weight data of each primary sub-account, carrying out account splitting on the target account queue through the target polling finger to obtain a plurality of target sub-accounts;

Carrying out data updating on the plurality of target sub-accounts to obtain a plurality of updated sub-accounts, and carrying out account data updating on the initial main account through the plurality of updated sub-accounts to obtain a target main account; the method specifically comprises the following steps: analyzing the data updating items of each target sub-account to obtain the data updating items of each target sub-account; based on the data update item of each target sub-account, carrying out data update content matching on each target sub-account to obtain an update content set; data updating is carried out on the target sub-accounts through the updated content set, so that a plurality of updated sub-accounts are obtained; and updating account data of the initial main account through a plurality of updated sub-accounts to obtain a target main account.

2. A sub-account extension-based hotspot account billing apparatus, the sub-account extension-based hotspot account billing apparatus comprising:

The monitoring module is used for carrying out concurrent request real-time monitoring on the primary main account to obtain concurrent request data of the primary main account, and specifically comprises the following steps: constructing a monitoring system, integrating real-time data acquisition and analysis functions, continuously tracking and recording concurrent requests of an initial main account, and deploying data acquisition agents which can acquire and send all request data initiated by the initial main account to a central processing system in real time, wherein the request data comprises a request time stamp, a frequency, a duration, a source place and a request type, and the central processing system analyzes and processes the collected request data in real time; the monitoring system alarms in real time on abnormal request modes, the rapid increase of request quantity or marks indicating that the primary main account becomes a hot spot through the set rules and threshold values; automatically adjusting a threshold value and an identification mode according to historical data by integrating a machine learning algorithm;

The matching module is used for judging the hot spot account of the primary main account according to the concurrent request data, and carrying out service scene matching on the concurrent request data when the primary main account is the hot spot account to obtain a target service scene; the method specifically comprises the following steps: carrying out data analysis on the concurrent request data to obtain an analysis data set, wherein the analysis data set comprises request time data and request identification data; calibrating the request times of the concurrent request data according to the request time data to obtain target request times; analyzing the data request quantity of the concurrent request data through the request identification data to obtain a target data request quantity; carrying out account hotspot value analysis on the target request times and the target data request quantity to obtain a target account hotspot value; carrying out numerical range analysis on the hot spot value of the target account to obtain a to-be-compared numerical range; data comparison is carried out on the to-be-compared value range and a preset standard data range, and a comparison result is obtained; performing hot spot account judgment on the primary main account according to the comparison result, and performing service scene matching on the concurrent request data when the primary main account is a hot spot account to obtain the target service scene;

The splitting module is used for judging whether to split the account of the primary main account through the target service scene, if so, the account of the primary main account is split through a preset load balancing algorithm, and a plurality of target sub-accounts are obtained; the method specifically comprises the following steps: extracting the service type of the target service scene to obtain a target service type; screening account splitting conditions for the target service types to obtain splitting condition data; judging whether to split the account of the primary main account according to the splitting condition data, if so, constructing an account structure of the primary main account by the load balancing algorithm to obtain a target account structure; creating a sub-account list according to the target account structure, and extracting a plurality of initial sub-accounts and index data of each initial sub-account from the target sub-account list; performing weight matching on each primary sub-account to obtain weight data of each primary sub-account; defining a polling pointer structure according to the load balancing algorithm to obtain a target polling pointer structure; based on the target polling pointer structure and the index data of each primary sub-account, acquiring real-time performance indexes of a plurality of primary sub-accounts through the target polling pointer to obtain real-time performance index data of each primary sub-account; carrying out account change trend prediction on the real-time performance index data of each primary sub-account to obtain a plurality of change trend data; according to the change trend data, carrying out weight data correction on each primary sub-account to obtain corrected weight data of each primary sub-account; constructing an account queue through index data of each primary sub-account to obtain a target account queue; based on the correction weight data of each primary sub-account, carrying out account splitting on the target account queue through the target polling finger to obtain a plurality of target sub-accounts;

The updating module is used for carrying out data updating on the plurality of target sub-accounts to obtain a plurality of updated sub-accounts, and carrying out account data updating on the initial main account through the plurality of updated sub-accounts to obtain a target main account; the method specifically comprises the following steps: analyzing the data updating items of each target sub-account to obtain the data updating items of each target sub-account; based on the data update item of each target sub-account, carrying out data update content matching on each target sub-account to obtain an update content set; data updating is carried out on the target sub-accounts through the updated content set, so that a plurality of updated sub-accounts are obtained; and updating account data of the initial main account through a plurality of updated sub-accounts to obtain a target main account.

3. A sub-account extension-based hotspot account billing apparatus, the sub-account extension-based hotspot account billing apparatus comprising: a memory and at least one processor, the memory having instructions stored therein;

The at least one processor invoking the instructions in the memory to cause the sub-account extension based hot spot account billing device to perform the sub-account extension based hot spot account billing method as defined in claim 1.

4. A computer readable storage medium having instructions stored thereon, which when executed by a processor implement the sub-account extension based hot spot account billing method of claim 1.