User tag query method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a user tag query method and device, electronic equipment and a storage medium, and the method is applied to a service node and comprises the steps that a query request is received, and the query request comprises a user identifier and at least one tag; for each label, according to a label source corresponding to the label, a label value corresponding to the user identifier and the label is inquired from the label source through a resource pool corresponding to the label source, and the service node comprises the resource pool corresponding to each label source; and sending the tag value corresponding to the at least one tag to a requester of the query request. The embodiment of the invention can save resources and reduce cost.

Description

Technical Field

[0001] The present invention relates to the technical field of data query, and in particular to a method, device, electronic device and storage medium for querying user tags. Background Art

[0002] With the continuous development of the Internet, user tag query has gradually become a key link in personalized services and accurate information push.

[0003] Traditional query methods need to handle a large number of concurrent requests and tag sources with different performance characteristics, and usually have problems such as excessive resource consumption, low query efficiency, and susceptibility to single-point failures. The existing technology mainly relies on a single resource pool for tag query, resulting in tag sources with poor performance occupying the entire resource pool, affecting the query of other tag sources to a certain extent, and thus may lead to the interruption of the query service, seriously affecting the stability of the system and the user experience.

[0004] In the prior art, in order to avoid mutual influence between different tag sources, the query of different tag sources can be isolated by different physical machines. However, this solution requires adding physical machines, which is often costly, not only consuming a large amount of resources, but also requiring high maintenance costs. Summary of the Invention

[0005] The purpose of the embodiments of the present invention is to provide a method, device, electronic device and storage medium for querying user tags to save resources and reduce costs. The specific technical solutions are as follows:

[0006] In the first aspect of the present invention, a method for querying user tags is first provided, which is applied to a service node and includes:

[0007] Receiving a query request, where the query request includes a user identifier and at least one tag;

[0008] For each of the tags, according to the tag source corresponding to the tag, querying a tag value corresponding to the user identifier and the tag from the tag source through a resource pool corresponding to the tag source, and the service node includes a resource pool corresponding to each tag source respectively;

[0009] Sending the tag values corresponding to the at least one tag to the requester of the query request.

[0010] In the second aspect of the present invention, a device for querying user tags is further provided, which is applied to a service node and includes:

[0011] A request receiving module, configured to receive a query request, where the query request includes a user identifier and at least one tag;

[0012] A label query module, which is used to, for each of the labels, according to the label source corresponding to the label, query a label value corresponding to the user identifier and the label from the label source through a resource pool corresponding to the label source, where the service node includes resource pools respectively corresponding to each label source;

[0013] A label return module, which is used to send the label value corresponding to each of the at least one label to the requester of the query request.

[0014] In another aspect of the implementation of the present invention, there is also provided a computer-readable storage medium, in which instructions are stored, and when it runs on a computer, it causes the computer to execute the query method for user labels described in any one of the above.

[0015] In another aspect of the implementation of the present invention, there is also provided a computer program product containing instructions, and when it runs on a computer, it causes the computer to execute the query method for user labels described in any one of the above.

[0016] The query method, device, electronic device and storage medium for user labels provided by the embodiments of the present invention can, for each label in the query request, according to the label source corresponding to the label, query a label value corresponding to the user identifier and the label from the label source through a resource pool corresponding to the label source, and after summarizing the label values of each label, send them to the requester. Since each label source in a service node corresponds to a resource pool, when performing label query, the resource pool corresponding to the label source is used to query the label source, realizing logical isolation of different label sources in the same service node, which can avoid mutual influence between different label sources. Compared with isolation at the machine dimension, using resource pools is more convenient for maintenance, can save resources, and reduce costs. Description of the Drawings

[0017] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art.

[0018] Figure 1 is a flowchart of a query method for user labels provided by an embodiment of the present invention;

[0019] Figure 2 is a schematic diagram of the processing process of user label query in an embodiment of the present invention;

[0020] Figure 3 is a schematic structural diagram of a query device for user labels provided by an embodiment of the present invention;

[0021] Figure 4 is a schematic structural diagram of an electronic device provided by an embodiment of the present invention. Specific Embodiments

[0022] Next, the technical solutions in the embodiments of the present invention will be described with reference to the accompanying drawings in the embodiments of the present invention.

[0023] The embodiments of the present invention provide a solution for resource allocation and management of user tag queries using thread pool technology. Considering that user tag queries may involve multiple tag sources with different performance characteristics, and there are significant differences in the query performance of these tag sources, multiple resource pools are designed, and each resource pool is specifically configured according to the performance and query pressure of the corresponding tag source. The tag query link can have multiple service nodes. Each service node will analyze which tag source the currently queried tag belongs to, and then hand over the current query to the resource pool corresponding to the tag source for processing. This forms an isolation logic in the entire request link, ensuring that query tasks can obtain effective resource allocation and processing at each service node. This can not only ensure the efficient utilization of high-performance tag sources but also avoid query service interruptions caused by single resource depletion or overload. The specific solution is as follows.

[0024] Figure 1 is a flowchart of a method for querying user tags provided by an embodiment of the present invention. This method for querying user tags can be executed by an electronic device such as a service node, and the service node is a physical device. As Figure 1 shown, the method includes the following steps:

[0025] Step 110, receive a query request, where the query request includes a user identifier and at least one tag.

[0026] The query request can be initiated by a tag query access party. The service node of the rule engine parses and calculates the query request to determine the user identifier and at least one tag included in the query request, and sends a new query request including the user identifier and at least one tag to the service node for tag query. After receiving the new query request, the service node for tag query can perform corresponding tag queries through subsequent steps. Among them, the tag query access party can be an upstream service node, such as an intelligent red envelope service node, a cashier desk service node, etc.

[0027] Step 120, for each of the tags, according to the tag source corresponding to the tag, query the tag value corresponding to the user identifier and the tag from the tag source through the resource pool corresponding to the tag source. The service node includes a resource pool corresponding to each tag source respectively.

[0028] Among them, the resource pool corresponding to the tag source is a resource for supporting the tag query of the tag source, which may include a thread pool for executing the tag query of the tag source. Those skilled in the art understand that the resource pool may also include other resources for supporting the operation of the thread pool, such as CPU, memory, etc. The resource pool corresponding to the tag source is configured based on the historical performance data of the tag source. The historical performance data can reflect the query performance characteristics and query pressure of the tag source. The historical performance data may include, for example, the historical query concurrency, historical query timeout time, etc. The tag source is a data source storing tag data. The tag source may be a database or a downstream service node. The tag source may be Redis, etc.

[0029] The association relationship between the tag and the identifier of the tag source and the corresponding relationship between the identifier of the tag source and the resource pool can be saved through a tag configuration table. After determining the user identifier and at least one tag to be queried based on the query request, for each tag, the service node for tag query respectively queries the tag configuration table to determine the tag source corresponding to the tag and the resource pool corresponding to the tag source, and then uses the resource pool corresponding to the tag source to process the query of the tag and the user identifier to obtain the tag value corresponding to the user identifier and the tag. Among them, the tag is the user tag, which is an attribute description of a certain dimension feature of the user, such as age, gender, occupation, region, etc. The tag value is the specific attribute value corresponding to the tag. For example, for the tag "age", the tag value may be 22.

[0030] Step 130, send the tag values corresponding to each of the at least one tag to the requester of the query request.

[0031] Summarize the user tags and the tag values of one of the tags obtained by each resource pool to obtain the tag values corresponding to each of all the tags to be queried, and uniformly send the tag values corresponding to each of all the tags to be queried to the requester of the query request.

[0032] In the method for querying user tags provided by the embodiments of the present application, for each tag in the query request, according to the tag source corresponding to the tag, the resource pool corresponding to the tag source is used to query the tag value corresponding to the user identifier and the tag from the tag source, and after summarizing the tag values of each tag, they are sent to the requester. Since each tag source corresponds to a resource pool in a service node, when performing tag query, the resource pool corresponding to the tag source is used to query the tag source, realizing the logical isolation of different tag sources in the same service node, which can avoid the mutual influence between different tag sources. Compared with the isolation at the machine dimension, using the resource pool is more convenient for maintenance, can save resources, and reduce costs.

[0033] Based on the above technical solution, before, for each of the tags, querying, from the tag source corresponding to the tag, a tag value corresponding to the user identifier and the tag through a resource pool corresponding to the tag source, the method further includes: for each of the tag sources, obtaining historical performance data of the tag source, where the historical performance data includes the historical concurrent request quantity and the historical request duration; configuring the number of threads in the resource pool corresponding to the tag source according to the historical concurrent request quantity; and configuring the timeout for the resource pool to process the query request according to the historical request duration.

[0034] When configuring the resource pool for a tag source, the historical concurrent request quantity and the historical request duration of the tag source can be obtained. By counting the historical concurrent request quantity, the maximum historical concurrent request quantity can be determined, and based on the maximum historical concurrent request quantity, the number of threads in the resource pool corresponding to the tag source can be configured. For example, when the resource pool includes a thread pool, the maximum historical concurrent request quantity can be used as the number of threads in the thread pool; or, when the resource pool includes the above-mentioned first thread pool and second thread pool, the maximum historical concurrent request quantity can be used as the number of threads in the first thread pool and the second thread pool respectively.

[0035] By counting the historical request duration, the maximum historical request duration can be determined, and based on the maximum historical request duration, the timeout for the resource pool to process the query request can be configured. For example, the maximum historical request duration can be used as the timeout for the resource pool to process the query request; or, a certain amount of time can be added to the maximum historical request duration as the timeout for the resource pool to process the query request. That is to say, the timeout for the resource pool to process the query request is greater than or equal to the maximum historical request duration.

[0036] By configuring the resource pool corresponding to the tag source based on the historical performance data of the tag source, the resource pool corresponding to the tag source can be accurately configured, avoiding problems such as resource waste or insufficient resources to process query requests in a timely manner.

[0037] Based on the above technical solution, the method may further include: obtaining the performance data of each resource pool within a target time period, where the performance data includes the concurrent request quantity and the request duration; counting the concurrent request quantity within the first target time period to determine the maximum concurrent request quantity, and counting the request duration within the target time period to determine the maximum request duration; adjusting the number of threads in the resource pool according to the maximum concurrent request quantity, and adjusting the timeout for the resource pool to process the query request according to the maximum request duration.

[0038] Monitor the performance status of each resource pool in real time, so that developers can dynamically adjust the resource pool according to the monitored performance data and optimize the resource configuration.

[0039] Exemplarily, the number of concurrent requests within a first target time period can be counted to determine the maximum number of concurrent requests, and the number of threads in the resource pool can be adjusted based on the size relationship between the maximum number of concurrent requests and the number of threads in the resource pool. For example, when the number of threads in the resource pool is less than the maximum number of concurrent requests of the corresponding tag source within the first target time period, the number of threads in the resource pool can be increased so that the number of threads in the resource pool is the maximum number of concurrent requests; or, when the number of threads in the resource pool is continuously greater than the maximum number of concurrent requests of the corresponding tag source within the first target time period, the number of threads in the resource pool can be decreased so that the number of threads in the resource pool is the maximum number of concurrent requests.

[0040] Exemplarily, the request duration within a first target time period can be counted to determine the maximum request duration, and the timeout time for the resource pool to process query requests configured can be adjusted based on the maximum request duration. For example, when the maximum request duration within the first target time period is close to the configured timeout time, the timeout time can be appropriately increased; or, when the maximum request duration within the first target time period is much less than the configured timeout time, the timeout time can be appropriately decreased.

[0041] By obtaining the performance data of each resource pool, it is convenient to dynamically adjust the resources of the resource pool based on the performance data, which can avoid problems such as resource waste or insufficient resources to process query requests in a timely manner.

[0042] On the basis of the above technical solution, the resource pool includes a first thread pool and a second thread pool;

[0043] The step of querying the tag value corresponding to the user identifier and the tag from the tag source through the resource pool corresponding to the tag according to the tag source, that is, step 120 above, includes: according to the tag source, sending a sub-query request including the user identifier and the tag to the second thread pool corresponding to the tag source through the first thread pool corresponding to the tag source; the second thread pool obtains the tag value corresponding to the user identifier and the tag by using a query method corresponding to the fault presence or absence information of the tag source according to the fault presence or absence information of the tag source, where the fault presence or absence information indicates whether the tag source has a fault, and the query methods are different when the tag source has a fault and when the tag source does not have a fault; the second thread pool sends the tag value corresponding to the user identifier and the tag to the first thread pool; the first thread pool performs preset post-processing on the tag value to obtain the processed tag value.

[0044] The resource pool may include two thread pools, namely the first thread pool and the second thread pool. The first thread pool may be a thread pool for business processing, mainly for data processing, such as data format conversion, etc. The second thread pool may be a thread pool for label query and fault handling.

[0045] For the query of each label, after determining the resource pool for the label query according to the label source of the label, first, the first thread pool in the resource pool is used to receive the query task of the label query. The first thread pool processes the request data of the label to a certain extent, determines the user identifier and label to be queried, and may also determine other query conditions, and then generates a sub-query request including the user identifier and the label. The sub-query request may also include other query conditions, and sends the sub-query request to the second thread pool to request the label value corresponding to the user identifier and the label from the second thread pool. When the first thread pool receives the query task of the label query, it determines the first thread for executing the query task from the first thread pool based on the scheduling method of the thread pool, and specifically executes the query task through this first thread.

[0046] The fault presence / absence information is determined based on historical query requests or current sub-query requests. For example, when querying the label source through a historical query request and no required data is queried, it is determined that the label source has a fault. It is considered that the label source has a fault within a certain period of time after that. If the time of the current sub-query request is within this time period, it is determined that the label source has a fault at this time; or, when querying the label source through a sub-query request, but abnormal data is received from the label source or no data is received from the label source within the timeout period, it is determined that the label source has a fault at this time.

[0047] When the second thread pool receives the sub-query request sent by the first thread pool, it determines whether the label source currently has a fault, and uses different query methods to obtain the label value corresponding to the user identifier and the label. In this way, even when the label source has a fault, the label value corresponding to the user identifier and the label can be obtained based on the corresponding query method, which can avoid the problem of being unable to obtain the label value when the label source has a fault. When the second thread pool receives the sub-query request, it determines the second thread for executing the sub-query request from the second thread pool based on the scheduling method of the thread pool, and specifically executes the sub-query request through this first thread.

[0048] After obtaining the label value corresponding to the user identifier and the label through the second thread pool, the label value is returned to the first thread pool. The first thread pool can perform some post-processing on the label value, such as unifying the data format of the label value, etc., and returns the processed label value to the thread or process for unified data aggregation, so as to aggregate the label values obtained from different label sources and send them to the requester.

[0049] By cooperating the first thread pool and the second thread pool to execute the query and fault handling of tags, it is possible to avoid the problem that the thread is always occupied due to the inability to obtain the tag value when the tag source fails, and the fault can be processed in a timely manner, further saving resources, and ensuring the stability and high availability of the query service.

[0050] Based on the above technical solution, the second thread pool obtains the tag value corresponding to the user identifier and the tag by using a query method corresponding to the fault presence information of the tag source, including:

[0051] When the second thread pool determines that the tag source has no fault, the sub-query request is sent to the tag source, and the tag value corresponding to the user identifier and the tag is determined; or

[0052] When the second thread pool receives the sub-query request during the fault time period of the tag source, the default value corresponding to the tag is used as the tag value corresponding to the user identifier and the tag.

[0053] In an alternative embodiment, when the second thread pool receives the sub-query request sent by the first thread pool, if the tag source has no fault currently, the second thread pool can send the sub-query request to the tag source, and the tag source queries the tag value corresponding to the user identifier and the tag in the database of the tag source. The second thread pool can determine the tag value corresponding to the user identifier and the tag based on the response information returned by the tag source.

[0054] In another alternative embodiment, when the second thread pool receives the sub-query request sent by the first thread pool, if the tag source has a fault currently, that is, the current time is within the fault time period of the tag source, at this time, the request for the tag value corresponding to the user identifier and the tag is no longer sent to the tag source, but the default value corresponding to the tag is used as the tag value corresponding to the user identifier and the tag, which can avoid the problem of inability to obtain the tag value when the tag source fails. The fault time period is the time period of fuse processing, that is, the time period when the tag source is considered to have a fault. The start time of this time period is the time when it is determined that the proportion of abnormal query volume of a tag source in the target time period exceeds the preset proportion threshold.

[0055] Based on the above technical solution, the determination of the tag value corresponding to the user identifier and the tag includes:

[0056] The second thread pool receives the tag value corresponding to the user identifier and the tag returned by the tag source; or

[0057] When it is determined that the sub-query request has a query exception through the second thread pool, the default value corresponding to the label is used as the label value corresponding to the user identifier and the label.

[0058] In an alternative embodiment, when the label source normally queries the label value corresponding to the user identifier and the label, it will return the label value, and the second thread pool can receive the label value.

[0059] In another alternative embodiment, when the second thread pool determines that the sub-query request has a query exception, that is, it does not normally receive the label value returned by the label source, it may receive an exception code returned by the label source or timeout without response. At this time, the default value corresponding to the label is used as the label value corresponding to the user identifier and the label, and the thread for this query can be recycled. When the label source is abnormal, the corresponding label value can also be given, avoiding query blocking, and the thread resources for this query processing can be released in time.

[0060] Based on the above technical solution, after sending the sub-query request to the label source when it is determined by the second thread pool that the label source does not have a fault, the following is further included:

[0061] When it is determined that the sub-query request has a query exception through the second thread pool, calculate the proportion of the abnormal query volume in the second target time period before the current time. If the proportion of the abnormal query volume is greater than or equal to the preset proportion threshold, the current time is used as the start time of the fault time period of the label source, and the current time is the time when it is determined by the second thread pool that the sub-query request has a query exception; if a sub-query request is received again during the fault time period, return the default value corresponding to the label in the sub-query request.

[0062] When the second thread pool determines that the label source does not have a fault, it will send the sub-query request to the label source. However, an exception may occur during the query process of the label source. At this time, the second thread pool may receive an exception code returned by the label source or the label source times out without response. This query is an abnormal query. Statistically analyze the abnormal queries in the second target time period before the current time, determine the abnormal query volume and the total query volume, and then determine the proportion of the abnormal query volume based on the abnormal query volume and the total query volume. If the proportion of the abnormal query volume is greater than or equal to the preset proportion threshold, record the fault time period of the label source starting from the current time. If the abnormal query volume is less than the preset proportion threshold, it is not considered that the label source has a fault. Among them, the preset proportion threshold can be set according to requirements, for example, it can be 50%.

[0063] By determining the fault time period of the tag source, when a sub-query request is received again within the fault time period, instead of requesting the tag source to query the tag, the default value corresponding to the tag can be directly returned, which can avoid resource occupation.

[0064] It should be noted that during the process of performing tag queries, it can be executed by a single service node or by multiple service nodes in cooperation. However, during the query processing of each service node, the corresponding tag source is isolated and queried based on the resource pool corresponding to the tag source. That is to say, on the entire query link, different tag sources in the same service node are processed using different resource pools and will not affect each other.

[0065] Figure 2 It is a schematic diagram of the processing process of user tag queries in an embodiment of the present invention. Figure 2 Taking the cooperation between service node A and service node B to execute user tag queries as an example. As Figure 2 shown, the method for querying user tags may include:

[0066] Step 1, resource pool initialization: Initialize multiple resource pools, with each tag source corresponding to a resource pool. For each tag source, configure the resource pool corresponding to the tag source according to the performance characteristics (historical request time consumption) and query pressure (historical concurrent request quantity) of the tag source (the specific configuration method can refer to the above embodiments and will not be elaborated here);

[0067] Step 2, distribution of query tasks: For query requests sent by different access parties (requesting parties), after determining the tag to be queried, each service node determines the tag source corresponding to each tag based on the tag configuration table and distributes the query task corresponding to the tag to the resource pool corresponding to the tag source to ensure that the query tasks can be effectively allocated and processed at each node;

[0068] Step 3, query task processing: Execute the corresponding query tasks through the first thread pool and the second thread pool in the resource pool;

[0069] Step 4, data aggregation: Aggregate the tag values queried from each tag source and return them to the access party;

[0070] Step 5, fault handling: When the second thread pool detects that the query task execution is abnormal or faulty, immediately trigger the fuse and fallback logic to ensure that the query service does not interrupt.

[0071] Among them, fusing means starting to record the fault time period of the tag source and no longer requesting tag data from the tag source within the fault time period. The fallback logic means using the default value of the tag as the tag value to be queried within the fault time period.

[0072] The method for querying user tags may further include: performance monitoring and adjustment, real-time monitoring of the performance status of each resource pool, so that developers can make dynamic adjustments according to the monitoring data and optimize resource allocation.

[0073] In the embodiments of the present invention, resource pool partitioning and configuration can be performed according to the performance characteristics and query pressure of different tag sources, which can efficiently utilize high-performance tag sources and improve the overall query efficiency; query tasks can be effectively managed and scheduled, resource contention and management costs can be reduced, and the high-concurrency processing ability of the system can be improved. Compared with machine-level isolation, using a thread pool is more lightweight, easier to maintain, and can significantly save resources; by analyzing the tag source to which the currently queried tag belongs at each service node, and then handing the current query task to the thread pool corresponding to the tag source, an isolation logic is formed in the entire request link, ensuring that query tasks can obtain effective resource allocation and processing at each service node, and improving the overall robustness and reliability of the system.

[0074] Figure 3 FIG. is a schematic structural diagram of a query device for user tags provided by an embodiment of the present invention, which is applied to a service node, such as Figure 3 shown, the device includes:

[0075] A request receiving module 310, configured to receive a query request, where the query request includes a user identifier and at least one tag;

[0076] A tag query module 320, configured to, for each of the tags, query a tag value corresponding to the user identifier and the tag from the tag source through a resource pool corresponding to the tag source according to the tag source corresponding to the tag, and the service node includes resource pools respectively corresponding to each tag source;

[0077] A tag return module 330, configured to send the tag values corresponding to the at least one tag to the requester of the query request.

[0078] Optionally, the device further includes:

[0079] A historical data acquisition module, configured to, for each of the tag sources, acquire historical performance data of the tag source, where the historical performance data includes the number of historical concurrent requests and the historical request duration;

[0080] A thread configuration module, configured to configure the number of threads in the resource pool corresponding to the tag source according to the number of historical concurrent requests;

[0081] A timeout configuration module, configured to configure a timeout for the resource pool to process the query request according to the historical request duration.

[0082] Optionally, the device further includes:

[0083] A performance data acquisition module, configured to acquire the performance data of each of the resource pools within a target time period, where the performance data includes the number of concurrent requests and the request duration.

[0084] A data statistics module, configured to count the number of concurrent requests within the first target time period to determine the maximum number of concurrent requests, and count the request duration within the target time period to determine the maximum request duration.

[0085] A dynamic adjustment module, configured to adjust the number of threads in the resource pool according to the maximum number of concurrent requests, and adjust the timeout period for the resource pool to process the query request according to the maximum request duration.

[0086] Optionally, the resource pool includes a first thread pool and a second thread pool.

[0087] The label query module includes:

[0088] A sub-request sending sub-module, configured to send a sub-query request including the user identifier and the label to a second thread pool corresponding to the label source through a first thread pool corresponding to the label source according to the label source.

[0089] A label value acquisition sub-module, configured to obtain a label value corresponding to the user identifier and the label through the second thread pool according to the fault presence / absence information of the label source, where the fault presence / absence information indicates whether the label source has a fault, and the query methods are different when the label source has a fault and when the label source does not have a fault.

[0090] A label value sending sub-module, configured to send the label value corresponding to the user identifier and the label to the first thread pool through the second thread pool.

[0091] A post-processing module, configured to perform a preset post-processing on the label value through the first thread pool to obtain a processed label value.

[0092] Optionally, the label value acquisition sub-module includes:

[0093] A first acquisition unit, configured to, when it is determined through the second thread pool that the label source does not have a fault, send the sub-query request to the label source and determine the label value corresponding to the user identifier and the label; or

[0094] A second acquisition unit, configured to, when receiving the sub-query request during a fault time period of the tag source through the second thread pool, use the default value corresponding to the tag as the tag value corresponding to the user identifier and the tag.

[0095] Optionally, the first acquisition unit includes:

[0096] A tag value receiving sub-unit, configured to receive, through the second thread pool, the tag value corresponding to the user identifier and the tag returned by the tag source; or

[0097] A tag value determination sub-unit, configured to, when determining that the sub-query request has an abnormal query through the second thread pool, use the default value corresponding to the tag as the tag value corresponding to the user identifier and the tag.

[0098] Optionally, the apparatus further includes:

[0099] A fault determination module, configured to, when determining that the sub-query request has an abnormal query through the second thread pool, calculate the proportion of the abnormal query volume within a second target time period before the current time. If the proportion of the abnormal query volume is greater than or equal to a preset proportion threshold, use the current time as the start time of the fault time period of the tag source, where the current time is the time when it is determined through the second thread pool that the sub-query request has an abnormal query;

[0100] A default value return module, configured to, when receiving a sub-query request again during the fault time period, return the default value corresponding to the tag in the sub-query request.

[0101] The query apparatus for user tags provided by the embodiments of the present application, for each tag in the query request, according to the tag source corresponding to the tag, queries the tag value corresponding to the user identifier and the tag from the tag source through the resource pool corresponding to the tag source, and after summarizing the tag values of each tag, sends them to the requestor. Since each tag source corresponds to a resource pool in a service node, when performing tag queries, the resource pool corresponding to the tag source is used to query the tag source, achieving logical isolation of different tag sources in the same service node, which can avoid mutual influence between different tag sources. Compared with isolation at the machine dimension, using resource pools is more convenient for maintenance, can save resources, and reduce costs.

[0102] Embodiments of the present invention further provide an electronic device, as Figure 4 shown, including a processor 401, a communication interface 402, a memory 403, and a communication bus 404. Among them, the processor 401, the communication interface 402, and the memory 403 communicate with each other through the communication bus 404.

[0103] A memory 403 for storing computer programs;

[0104] A processor 401, when executing the program stored in the memory 403, implements the following steps:

[0105] Receiving a query request, the query request including a user identifier and at least one tag;

[0106] For each of the tags, according to the tag source corresponding to the tag, querying, from the tag source, a tag value corresponding to the user identifier and the tag through a resource pool corresponding to the tag source, the electronic device including a resource pool corresponding to each tag source respectively;

[0107] Sending the tag value corresponding to each of the at least one tag to the requester of the query request.

[0108] Optionally, before the step of, for each of the tags, querying, from the tag source, a tag value corresponding to the user identifier and the tag according to the tag source corresponding to the tag through a resource pool corresponding to the tag source, further includes:

[0109] For each of the tag sources, obtaining historical performance data of the tag source, the historical performance data including historical concurrent request quantity and historical request duration;

[0110] Configuring the number of threads in the resource pool corresponding to the tag source according to the historical concurrent request quantity;

[0111] Configuring a timeout for the resource pool to process the query request according to the historical request duration.

[0112] Optionally, further includes:

[0113] Obtaining performance data of each of the resource pools within a target time period, the performance data including concurrent request quantity and request duration;

[0114] Counting the concurrent request quantity within the first target time period to determine the maximum concurrent request quantity, and counting the request duration within the target time period to determine the maximum request duration;

[0115] Adjusting the number of threads in the resource pool according to the maximum concurrent request quantity, and adjusting the timeout for the resource pool to process the query request according to the maximum request duration.

[0116] Optionally, the resource pool includes a first thread pool and a second thread pool;

[0117] Querying, according to the label source corresponding to the label, a label value corresponding to the user identifier and the label from the label source through a resource pool corresponding to the label source, includes:

[0118] According to the label source, send a sub-query request including the user identifier and the label to a second thread pool corresponding to the label source through a first thread pool corresponding to the label source;

[0119] Through the second thread pool, according to the fault presence / absence information of the label source, obtain a label value corresponding to the user identifier and the label by using a query method corresponding to the fault presence / absence information, where the fault presence / absence information indicates whether the label source has a fault, and the query methods are different when the label source has a fault and when the label source does not have a fault;

[0120] Send, through the second thread pool, the label value corresponding to the user identifier and the label to the first thread pool;

[0121] Perform preset post-processing on the label value through the first thread pool to obtain a processed label value.

[0122] Optionally, the obtaining, through the second thread pool, a label value corresponding to the user identifier and the label by using a query method corresponding to the fault presence / absence information of the label source includes:

[0123] When the second thread pool determines that the label source does not have a fault, send the sub-query request to the label source and determine the label value corresponding to the user identifier and the label; or

[0124] When the second thread pool receives the sub-query request during the fault time period of the label source, use the default value corresponding to the label as the label value corresponding to the user identifier and the label.

[0125] Optionally, the determining the label value corresponding to the user identifier and the label includes:

[0126] Receive, through the second thread pool, the label value corresponding to the user identifier and the label returned by the label source; or

[0127] When the second thread pool determines that the sub-query request has an abnormal query, use the default value corresponding to the label as the label value corresponding to the user identifier and the label.

[0128] Optionally, after sending the sub-query request to the label source when the second thread pool determines that the label source does not have a fault, further includes:

[0129] When it is determined that the sub-query request has a query exception through the second thread pool, the proportion of the abnormal query volume within the second target time period before the current time is statistically calculated. If the proportion of the abnormal query volume is greater than or equal to the preset proportion threshold, the current time is used as the start time of the fault time period of the tag source, and the current time is the time when it is determined that the sub-query request has a query exception through the second thread pool;

[0130] When a sub-query request is received again during the fault time period, the default value corresponding to the tag in the sub-query request is returned.

[0131] The communication bus mentioned in the above electronic device may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of representation, only a thick line is used in the figure, but it does not mean that there is only one bus or one type of bus.

[0132] The communication interface is used for communication between the above electronic device and other devices.

[0133] The memory may include a Random Access Memory (RAM), and may also include a non-volatile memory, such as at least one disk memory. Optionally, the memory may also be at least one storage device located far from the aforementioned processor.

[0134] The above-mentioned processor may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0135] In another embodiment provided by the present invention, a computer-readable storage medium is further provided. Instructions are stored in the computer-readable storage medium. When it runs on a computer, the computer is made to execute the query method of the user label described in any one of the above embodiments.

[0136] In another embodiment provided by the present invention, a computer program product containing instructions is further provided. When it runs on a computer, the computer is made to execute the query method of the user label described in any one of the above embodiments.

[0137] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present invention are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from a website, a computer, a server, or a data center to another website, computer, server, or data center by wire (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that the computer can access, or a data storage device such as a server or a data center that includes one or more integrated available media. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid state disk (SSD)).

[0138] It should be noted that in this article, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprising", "including", or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article, or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or elements inherent to such process, method, article, or device. Without further limitation, an element defined by the statement "including one..." does not exclude the existence of additional identical elements in the process, method, article, or device including the element.

[0139] Each embodiment in this specification is described in a related manner. For the same or similar parts among the embodiments, reference can be made to each other. Each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and reference can be made to the corresponding part of the method embodiment for the related content.

[0140] The above description is only for the preferred embodiments of the present invention and is not intended to limit the protection scope of the present invention. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention are included in the protection scope of the present invention.

Claims

1. A method for querying user tags, characterized in that: Applied to service nodes, including: receiving a query request, wherein the query request includes a user identifier and at least one tag; For each of the tags, according to the tag source corresponding to the tag, querying the tag value corresponding to the user identifier and the tag from the tag source through the resource pool corresponding to the tag source, wherein the service node includes a resource pool corresponding to each tag source; The tag value corresponding to each of the at least one tag is sent to the requester of the query request.

2. The method according to claim 1, characterized in that Before querying, for each of the tags, according to the tag source corresponding to the tag, from the tag source through a resource pool corresponding to the tag source, a tag value corresponding to the user identifier and the tag, the method further includes: For each of the tag sources, obtain historical performance data of the tag source, the historical performance data including the number of historical concurrent requests and the historical request duration; According to the number of historical concurrent requests, configure the number of threads in the resource pool corresponding to the tag source; According to the time consumption of the historical requests, a timeout period for the resource pool to process the query request is configured.

3. The method according to claim 1, characterized in that Also includes: Obtaining performance data of each resource pool within a target time period, the performance data including the number of concurrent requests and request duration; Counting the number of concurrent requests within the first target time period to determine the maximum number of concurrent requests, and counting the request duration within the target time period to determine the maximum request duration; According to the maximum number of concurrent requests, the number of threads in the resource pool is adjusted, and according to the maximum request duration, the timeout period for the resource pool to process the query request is adjusted.

4. The method according to any one of claims 1 to 3, characterized in that: The resource pool includes a first thread pool and a second thread pool; The step of querying a tag value corresponding to the user identifier and the tag from the tag source through a resource pool corresponding to the tag source according to the tag source corresponding to the tag includes: According to the tag source, sending a sub-query request to a second thread pool corresponding to the tag source through a first thread pool corresponding to the tag source, wherein the sub-query request includes the user identifier and the tag; The second thread pool uses a query method corresponding to the fault information of the tag source to obtain a tag value corresponding to the user identifier and the tag according to the fault information of the tag source, wherein the fault information indicates whether the tag source has a fault, and the query method is different when the tag source has a fault and when the tag source does not have a fault; Sending the tag value corresponding to the user identifier and the tag to the first thread pool through the second thread pool; The label value is post-processed by the first thread pool to obtain a processed label value.

5. The method according to claim 4, characterized in that The acquiring, by the second thread pool according to the fault information of the tag source, a tag value corresponding to the user identifier and the tag by adopting a query method corresponding to the fault information, comprises: When it is determined through the second thread pool that the tag source has no fault, the subquery request is sent to the tag source, and a tag value corresponding to the user identifier and the tag is determined; or When the sub-query request is received through the second thread pool within the failure time period of the tag source, a default value corresponding to the tag is used as a tag value corresponding to the user identifier and the tag.

6. The method according to claim 5, characterized in that The determining of the tag value corresponding to the user identifier and the tag includes: receiving, through the second thread pool, a tag value returned by the tag source and corresponding to the user identifier and the tag; or When it is determined through the second thread pool that the sub-query request is abnormal, the default value corresponding to the tag is used as the tag value corresponding to the user identifier and the tag.

7. The method according to claim 5, characterized in that When it is determined by the second thread pool that the tag source has no fault, after sending the subquery request to the tag source, the method further includes: When determining that the sub-query request query is abnormal through the second thread pool, the proportion of the abnormal query volume in the second target time period before the current time is counted, and if the proportion of the abnormal query volume is greater than or equal to a preset proportion threshold, the current time is used as the starting time of the fault time period of the label source, and the current time is the time when the sub-query request query is abnormal through the second thread pool; If a sub-query request is received again within the failure time period, a default value corresponding to the label in the sub-query request is returned.

8. A user tag query device, characterized in that: Applied to service nodes, including: A request receiving module, configured to receive a query request, wherein the query request includes a user identifier and at least one tag; A label query module, configured to query, for each label, a label value corresponding to the user identifier and the label from the label source through a resource pool corresponding to the label source, wherein the service node includes a resource pool corresponding to each label source; The tag returning module is used to send the tag value corresponding to each of the at least one tag to the requester of the query request.

9. An electronic device, characterized in that: It includes a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, for implementing the method steps described in any one of claims 1 to 7 when executing a program stored in a memory.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

11. A computer program product comprising computer program instructions, characterized in that When the computer program instructions are executed on a computer, the computer is caused to execute the method according to any one of claims 1 to 7.

Images