Social user discovery method and system based on multi-level cache and intelligent recommendation pool

Abstract

The invention discloses a social user discovery method and system based on a multi-level cache and an intelligent recommendation pool, and relates to the technical field of information retrieval, and the method comprises the steps: receiving a nearby user discovery request, and updating a position cache; reading a recommended user set from the first cache, and when a preset recommendation condition is met, selecting a target recommended user and returning the target recommended user to the client; when the recommendation condition is not met, the candidate user set is read from the second cache, and when the preset candidate condition is not met, new candidate users are inquired; and inputting the candidate user set into a recommendation algorithm service, generating a recommendation user list according to the matching score, selecting a target recommendation user, returning the target recommendation user to the client, and writing unselected recommendation users into a first cache. Through the technical scheme of the invention, the synchronous calling frequency is obviously reduced, the response time is shortened, the system resource utilization rate is improved, repeated recommendation is effectively reduced, and the freshness of a recommendation result and the user experience are improved.

Description

Technical Field

[0001] This invention relates to the field of information retrieval technology, and in particular to a social user discovery method and a social user discovery system based on multi-level caching and intelligent recommendation pools. Background Technology

[0002] In current social applications, user discovery features such as "people nearby" and "people you may be interested in" have become fundamental capabilities for improving activity and retention rates. A common implementation involves receiving a user's request to discover nearby users, then using the user's current location information to search for users within a preset distance from a geolocation index in real time. This search is then combined with certain interest tags, basic profiles, or simple social relationship characteristics for filtering and sorting, before the resulting user list is directly returned to the client.

[0003] In these traditional solutions, on the one hand, each request relies on online retrieval and online matching calculations. The calculation results are mostly one-time results, lacking a recommendation result caching mechanism for individual users. When the same user initiates multiple nearby user discovery requests within a short period, the backend needs to repeatedly execute candidate user query and matching sorting logic, leading to request response delays and high backend service pressure, making it difficult to support stable responses in high-concurrency scenarios. On the other hand, existing implementations often obtain candidate users based on only a single data source (such as a location index). When there are insufficient active users in the area or a limited number of candidates, problems such as insufficient candidate users and unstable recommendation results can easily occur.

[0004] Furthermore, traditional nearby user discovery features typically lack a fine-grained management mechanism for "displayed users," failing to maintain an ordered set of recommended users for each user who initiated the recommendation. This results in the same batch of recommended users being returned to the same user multiple times within a short period, leading to a poor user experience. Additionally, because "read" information is not included in the candidate filtering criteria, the backend query phase cannot effectively remove displayed users, making duplicate recommendations particularly noticeable when the number of candidate users is limited.

[0005] As social platforms increasingly demand sophisticated recommendations and highly available architectures, recommendation algorithm services often provide complex matching calculations as independent services. However, existing nearby user discovery solutions rely heavily on recommendation algorithm services, lacking reasonable multi-level caching and intelligent candidate pool designs, as well as corresponding asynchronous pre-filling and degradation strategies. When the algorithm service experiences performance fluctuations or becomes unavailable, overall link timeouts or empty results can easily occur, making it difficult to guarantee the stability and availability of the system.

[0006] Therefore, in social user discovery scenarios, how to reduce redundant calculations and recommendations without compromising recommendation matching quality by rationally organizing recommendation result caching, candidate recommendation pools, and read user sets, while balancing response latency, resource utilization, and service availability under high concurrency, has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0007] To address the aforementioned issues, this invention provides a social user discovery method and system based on multi-level caching and an intelligent recommendation pool. By constructing a multi-level caching structure, the discovery of nearby users is shifted from real-time full calculation to a cache-first, fallback-to-last processing mode. This enables the direct output of recommendation results based on the first cache in most requests, significantly reducing the number of synchronous calls and shortening response time. By introducing a second cache and fusing candidate data streams with multiple data sources, the coverage and diversity of candidate users are improved. User recommendations are performed using recommendation algorithms and matching scores. In a single recommendation calculation, the target recommended user for the current request is output, and unselected recommended users are written to the first cache for direct reuse of historical calculation results in subsequent iterations, improving system resource utilization. Through a closed-loop recommendation data stream of "read filtering → candidate generation → recommendation output → read update," duplicate recommendations for the same user in multiple nearby user discovery processes are effectively reduced, improving the freshness of recommendation results and user experience.

[0008] To achieve the above objectives, this invention provides a social user discovery method based on multi-level caching and intelligent recommendation pools, comprising: Receive a nearby user discovery request for a first user from a social application, the request containing at least the first user's user identifier and location information, and update the location cache based on the first user's user identifier and location information; Based on the user identifier of the first user, a set of recommended users pre-stored for the first user is read from the first cache. When the set of recommended users meets the preset recommendation conditions, a target recommended user is selected from the set of recommended users to form the recommendation result based on the preset sorting and truncation rules. The user identifier corresponding to the target recommended user is written into the set of read users associated with the first user, and the recommendation result is returned to the client. When the recommended user set does not meet the preset recommendation conditions, the candidate user set for the first user is read from the second cache. When the candidate user set does not meet the preset candidate conditions, new candidate users are queried for the first user based on multiple preset data sources and merged to obtain a fused candidate user set, which is then written into the second cache to obtain an updated candidate user set. The updated candidate user set is input into the recommendation algorithm service to obtain a matching score for the first user. A recommended user list is generated based on the matching score. Target recommended users for constituting the recommendation result are selected from the recommended user list. The user identifier corresponding to the target recommended user is written into the read user set. The recommendation result is returned to the client. Recommended users that are not selected as the target recommended users are written into the first cache.

[0009] In the above technical solution, preferably, the social user discovery method based on multi-level caching and intelligent recommendation pool also includes initial request processing and asynchronous maintenance of multi-level caching, specifically including: When processing the nearby user discovery request, the data status in the first cache and the second cache corresponding to the first user is detected. When both the first cache and the second cache are empty, the current nearby user discovery request for the first user is determined as the first request. If it is determined to be the first request, candidate users are queried for the first user based on the multiple preset data sources within a limited first candidate number range. On the premise of excluding users recorded in the read user set associated with the first user and the first user himself, the candidate users from each preset data source are merged and deduplicated according to the user identifier to obtain the first candidate user set. The initial candidate user set is input into the recommendation algorithm service as the candidate user set to be evaluated to obtain matching score data for the first user. An initial recommended user list is generated based on the matching score data. Target recommended users for constituting the recommendation result are selected from the initial recommended user list and returned to the client. While returning the recommendation result, other recommended users who were not selected as the target recommended user in the initial recommended user list are written into the first cache through an asynchronous execution channel. A candidate filling operation for the first user is triggered based on the multiple preset data sources. Within the limited target total number of candidates, new candidate users are queried and written into the second cache to form a candidate user set for subsequent request processing. After completing the synchronous processing of the nearby user discovery request, the data status associated with the first cache, the second cache, and the set of read users is submitted as a maintenance task to the asynchronous execution channel, and multi-level cache maintenance is performed in a decoupled manner from the synchronous processing thread of the nearby user discovery request. Based on the maintenance task in the asynchronous execution channel, the second cache is preheated and filled, including: detecting the number of candidate users for the first user in the second cache; when the number of candidate users is lower than a preset first threshold, excluding the users recorded in the read user set and the first user himself, calling the preset data source to query new candidate users for the first user, writing the queried candidate users into the second cache to form an updated candidate user set. Based on the maintenance task in the asynchronous execution channel, a preheating and filling operation is performed on the first cache, including: detecting the number of recommended users for the first user in the first cache; when the number of recommended users is lower than a preset second threshold and the number of candidate users for the first user in the second cache reaches a preset third threshold, selecting a preset number of candidate users from the second cache as a preheating candidate user set and inputting it into the recommendation algorithm service to obtain the corresponding matching score data and data related to the location information; generating a preheating recommended user list based on the matching score data and the data related to the location information; and writing the recommended users in the preheating recommended user list into the first cache. The first threshold, the second threshold, and the third threshold constitute a threshold triggering mechanism, which is used to automatically trigger corresponding asynchronous maintenance and preheating operations when the data status stored in the first cache and the second cache meets the threshold conditions.

[0010] In the above technical solution, preferably, the first cache is used to store recommended users whose recommendation calculations have been completed, and includes: The first sorting structure is used to store recommended users with the user ID of the recommended user as the index and the score value calculated based on the matching score as the sorting criterion. The first detailed storage structure is used to store the display information corresponding to the recommended user, indexed by the user ID of the recommended user. The display information includes the username, avatar, and relationship tag. The specific process of reading the pre-stored set of recommended users for the first user from the first cache includes: Based on the first sorting structure, a set of candidate recommended user identifiers is determined from high to low according to the score value, and the display information corresponding to the set of candidate recommended user identifiers is obtained based on the first detailed storage structure, so as to form a set of recommended users for participating in the judgment of the preset recommendation conditions.

[0011] In the above technical solution, preferably, the second cache is used to store candidate users whose recommendation calculation has not yet been completed, and includes: The second sorting structure is used to store candidate users based on their user IDs as indexes and candidate score values ​​calculated based on the distance between the candidate user and the first user and social relationship features. The second detailed storage structure is used to store detailed information of candidate users with the candidate user's user identifier as an index. The detailed information includes at least the candidate user's user identifier, the distance between the candidate user and the location corresponding to the location information, and the data source identifier from which the candidate user originates. The specific process of reading the candidate user set for the first user from the second cache includes: selecting a set of candidate user identifiers that meet the preset candidate conditions according to the order of the candidate score values ​​based on the second sorting structure, and obtaining the detailed information corresponding to the candidate user identifier set based on the second detailed storage structure to form a candidate user set for input to the recommendation algorithm service.

[0012] In the above technical solution, preferably, the set of read users associated with the first user is implemented using an ordered set structure, with the key value used to identify the first user as the index, the user identifier of the read user as the member, and the timestamp corresponding to the return time of the recommendation result as the sorting basis; When writing the user identifier corresponding to the target recommended user into the read user set, each member is written into the ordered set structure and the current timestamp is recorded. When the number of members in the ordered set structure exceeds the preset capacity limit, the member with the smallest score is deleted to implement the least recently used elimination strategy. An expiration time threshold is configured for the ordered set structure so that read records that exceed the expiration time threshold are automatically invalidated. This allows for the construction of filtering conditions to exclude read users based on the read user set when querying new candidate users for the first user based on the multiple preset data sources.

[0013] In the above technical solution, preferably, the plurality of preset data sources include at least location data sources, social relationship data sources, and interest preference data sources; The specific process of querying new candidate users for the first user based on multiple preset data sources and merging them to obtain a fused candidate user set includes: Configure weight parameters for each preset data source, and determine the candidate quantity quota corresponding to each preset data source based on the current target candidate quantity for the first user; For each preset data source, excluding the first user and the users recorded in the set of read users, a list of candidate users matching the first user is queried according to their respective preset sorting rules, and a subset of candidate users for fusion is selected from the list of candidate users based on the corresponding candidate quantity quota. The candidate user subsets from each preset data source are merged according to the candidate user's user identifier. When the same candidate user appears in multiple preset data sources, the corresponding source data source identifiers are merged and recorded to form a fused candidate user set for writing to the second cache.

[0014] In the above technical solution, preferably, the process of inputting at least a portion of the updated candidate user set into the recommendation algorithm service specifically includes: The updated set of candidate users is divided into multiple candidate batches according to a preset batch size; Configure an asynchronous execution thread pool for the recommendation algorithm call, and encapsulate each candidate batch into an independent algorithm call task and submit it to the asynchronous execution thread pool; Configure a first timeout period for the algorithm call of a single candidate batch. When the algorithm call of any candidate batch exceeds the first timeout period or an error occurs, generate a recommended user list based on the matching score data returned by the candidate batches that have completed the algorithm call and the data related to the location information. Specifically, when the recommendation algorithm service is detected to be unavailable, a basic matching score is calculated based on the distance between the candidate user and the first user and the social relationship features. This basic matching score is then used as matching score data to participate in the generation of the recommended user list.

[0015] In the above technical solutions, preferably, the social user discovery method based on multi-level caching and intelligent recommendation pool also includes: In the process of querying new candidate users for the first user based on multiple preset data sources and writing the fused candidate user set into the second cache, when the number of candidate users after fusion and deduplication is less than a preset depletion detection threshold, it is determined that the data of nearby users corresponding to the first user is in a data depletion state, and a data depletion mark is written into the key value used to identify the first user in the key-value cache database, and a preset expiration time is set for the data depletion mark. Furthermore, before performing warm-up and filling operations on the second cache based on the asynchronous execution channel, it is first detected whether there is a data depletion mark corresponding to the first user that has not expired. When the data depletion mark is detected, the current asynchronous warm-up and filling operation for the first user is skipped until the data depletion mark automatically expires due to exceeding the preset expiration time or is cleared by an external instruction, and then the warm-up and filling operation for the first user is resumed.

[0016] In the above technical solution, preferably, the specific process of updating the location cache based on the user identifier of the first user and the location information includes: In the key-value cache database, the key value used to identify the first user is used as an index. A hash structure is used to store at least the longitude field, latitude field, and location update time field corresponding to the location information. A location data expiration time is set for the key value so that the location information that exceeds the location data expiration time will automatically become invalid. The location of the first user is determined based on the longitude and latitude fields in the location cache.

[0017] This invention also proposes a social user discovery system based on multi-level caching and intelligent recommendation pools, applying the social user discovery method based on multi-level caching and intelligent recommendation pools disclosed in any of the above technical solutions, including: The user location update module is used to receive a nearby user discovery request for a first user in a social application. The request includes at least the user identifier and location information of the first user, and updates the location cache based on the user identifier and location information of the first user. The recommended user set module is used to read a pre-stored recommended user set for the first user from the first cache based on the user identifier of the first user. When the recommended user set meets the preset recommendation conditions, the module selects the target recommended user to form the recommendation result from the recommended user set based on the preset sorting and truncation rules, writes the user identifier corresponding to the target recommended user into the read user set associated with the first user, and returns the recommendation result to the client. The candidate user update module is used to read the candidate user set for the first user from the second cache when the recommended user set does not meet the preset recommendation conditions; and when the candidate user set does not meet the preset candidate conditions, to query new candidate users for the first user based on multiple preset data sources and merge them to obtain a fused candidate user set, and write it into the second cache to obtain an updated candidate user set. The recommended user matching module is used to input at least a portion of the updated candidate user set into the recommendation algorithm service to obtain a matching score for the first user, generate a recommended user list based on the matching score, select target recommended users from the recommended user list to constitute the recommendation result, write the user identifier corresponding to the target recommended user into the read user set, return the recommendation result to the client, and write recommended users that were not selected as the target recommended users into the first cache.

[0018] Compared with the prior art, the beneficial effects of the present invention are as follows: (1) By constructing a multi-level cache structure consisting of a location cache, a first cache, a second cache, and a set of read users associated with the first user, the discovery of nearby users is changed from "full calculation in real time every time" to a "cache priority, calculation fallback" processing mode. This enables the output of recommendation results directly based on the first cache in most requests, significantly reducing the number of synchronous calls to recommendation algorithm services and external data sources, reducing server-side computational overhead and external interface access pressure, and shortening the end-to-end response time of nearby user discovery requests.

[0019] (2) When the recommended user set is insufficient, a data flow of "second cache + multiple preset data source fusion candidates" is introduced. The multi-source data such as location data, social relationship data, and interest preference data are queried according to preset rules and deduplicated and merged on the premise of excluding read users and the first user himself. A fusion candidate user set for the first user is constructed. Compared with the scheme that relies on a single data source or simple sequential data source call, the coverage and diversity of candidate users are improved, and the relevance of the final recommendation result to the first user's interests and social relationships is enhanced.

[0020] (3) By inputting the updated candidate user set into the recommendation algorithm service to obtain the matching score, and generating a list of recommended users based on the matching score, the target recommended users for the current request are output in one recommendation calculation, and the recommended users that are not selected as target recommended users are written into the first cache. This realizes the incremental accumulation and reuse of recommendation results in the first cache, so that the subsequent nearby users of the same first user can directly reuse the historical calculation results for their discovery requests. This further improves the overall throughput and system resource utilization while ensuring the recommendation effect.

[0021] (4) By writing the user identifier corresponding to the target recommended user into the set of read users associated with the first user each time a recommendation result is generated, and constructing exclusion conditions based on the set of read users in subsequent multi-data source candidate queries and candidate filling processes, a closed-loop recommendation data flow of "read filtering → candidate generation → recommendation output → read update" is formed, which effectively reduces the repeated recommendation of the same user in multiple nearby user discovery, and improves the freshness of the recommendation results and user experience. Attached Figure Description

[0022] Figure 1 This is a flowchart illustrating a social user discovery method based on multi-level caching and intelligent recommendation pool, as disclosed in an embodiment of the present invention. Figure 2 This is a schematic diagram of a weighted fusion process for multiple data sources disclosed in an embodiment of the present invention; Figure 3 This is a schematic diagram of a two-layer cache architecture disclosed in one embodiment of the present invention; Figure 4This is a flowchart illustrating the intelligent preheating and asynchronous filling mechanism disclosed in one embodiment of the present invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0024] The present invention will now be described in further detail with reference to the accompanying drawings: like Figure 1 As shown, a social user discovery method based on multi-level caching and intelligent recommendation pool provided by the present invention includes: Receive a nearby user discovery request from a social application for the first user. The request must include at least the first user's user ID and location information. Update the location cache based on the first user's user ID and location information. Based on the user identifier of the first user, the recommended user set pre-stored for the first user is read from the first cache. When the recommended user set meets the preset recommendation conditions, the target recommended user is selected from the recommended user set to form the recommendation result based on the preset sorting and truncation rules. The user identifier corresponding to the target recommended user is written into the read user set associated with the first user, and the recommendation result is returned to the client. When the recommended user set does not meet the preset recommendation conditions, the candidate user set for the first user is read from the second cache. When the candidate user set does not meet the preset candidate conditions, new candidate users are queried for the first user based on multiple preset data sources and merged to obtain a fused candidate user set, which is then written to the second cache to obtain an updated candidate user set. The candidate user set, which is at least partially updated, is input into the recommendation algorithm service to obtain the matching score for the first user. A list of recommended users is generated based on the matching score. Target recommended users are selected from the list of recommended users to form the recommendation result. The user identifier corresponding to the target recommended user is written into the read user set. The recommendation result is returned to the client. Recommended users that are not selected as target recommended users are written into the first cache.

[0025] In this implementation, by constructing a multi-level caching structure, the discovery of nearby users is changed from real-time full calculation to a cache-first, fallback-to-the-bottom processing mode. This enables the output of recommendation results directly based on the first cache in most requests, significantly reducing the number of synchronous calls and shortening the response time. By introducing a second cache and fusing candidate data streams with multiple data sources, the coverage and diversity of candidate users are improved. User recommendations are performed through recommendation algorithm services and matching scores. In a single recommendation calculation, the target recommended user for the current request is output, and unselected recommended users are written to the first cache for direct reuse of historical calculation results in subsequent calculations, improving system resource utilization. Through a closed-loop recommendation data stream of "read filtering → candidate generation → recommendation output → read update", the duplicate recommendations of the same user in multiple nearby user discovery processes are effectively reduced, improving the freshness of recommendation results and user experience.

[0026] In this implementation, the social user discovery method based on multi-level caching and intelligent recommendation pool is deployed on the server side of the social application. The server receives "people nearby" discovery requests from mobile clients / web pages through an interface.

[0027] The server receives a nearby user discovery request for the first user. The request includes at least the first user's user ID (userId) and the geographic coordinates of their current location. After parsing the request, the server calls the location caching component to write the userId, current location, and location update time into the location cache for subsequent candidate queries and distance calculations. The location cache can be implemented using a hash structure from a key-value cache database (such as Redis), with the key being `nearby:location:{userId}`. Fields must include at least longitude, latitude, and update time, and an expiration time is configured to ensure the timeliness of the location data.

[0028] Furthermore, based on the user identifier of the first user, the server reads the pre-stored set of recommended users for that user from the first cache. Specifically, the first cache can be implemented using HookCache to store recommended users whose recommendation calculations have been completed. The server determines whether the set of recommended users meets preset recommendation conditions, such as whether the number of recommended users is greater than or equal to a preset number of recommendations (e.g., 20). When the preset recommendation conditions are met, the server selects target recommended users based on preset sorting and truncation rules (e.g., sorting by comprehensive score from high to low and then truncating the top 20) and generates the current recommendation result.

[0029] While returning the recommendation results, the server writes the user identifier of each target recommended user in this recommendation result into the set of read users associated with the first user. This is to record the users that the first user has already viewed, avoiding duplicate recommendations in the future. The set of read users can be implemented using a cached database structure. Subsequently, the server returns the recommendation results (including display information such as user nickname, avatar, distance, and relationship tags) to the client to complete this processing.

[0030] like Figure 2 As shown, further, when the set of recommended users in the first cache does not meet the preset recommendation conditions (e.g., the number of recommended users is less than 20), the server reads the set of candidate users from the second cache based on the user identifier of the first user. In a specific implementation, the second cache can correspond to a CandidatePool, used to store candidate users that have not yet completed recommendation calculations but have been generated through the fusion of multiple data sources. When the set of candidate users in the second cache does not meet the preset candidate conditions (e.g., the number is insufficient to support this recommendation and there is a certain amount of cache space), the server, excluding the first user and the users recorded in the read user set, queries for new candidate users for the first user based on multiple preset data sources (such as geographic location data sources, social relationship data sources, interest circle data sources, and open homepage data sources). The server performs deduplication and merging of candidate users from different data sources according to user identifiers to obtain a fused candidate user set, and writes this fused candidate user set into the second cache to form an updated candidate user set.

[0031] Furthermore, the server selects at least a portion of the candidate users from the updated candidate user set as the candidate user set to be evaluated, and calls the recommendation algorithm service to calculate the matching score of each candidate user relative to the first user. The recommendation algorithm service can output matching scores based on factors such as social relationship features, interest similarity, and historical interactions. The server generates a list of recommended users based on the matching scores, for example, sorting them from high to low to obtain a sorted list of recommended users.

[0032] The server selects target recommended users (e.g., the top 20) from the recommended user list to form the current recommendation result, writes the user identifiers corresponding to these target recommended users into the read user set, and returns the recommendation result to the client. Simultaneously, to avoid duplicate calculations, the server writes the remaining recommended users from the current recommended user list that were not selected as target recommended users into a first cache, so that subsequent nearby user discovery requests for the same user can directly and quickly return recommendation results from the first cache.

[0033] In the above embodiments, preferably, the social user discovery method based on multi-level caching and intelligent recommendation pool further includes initial request processing and asynchronous maintenance of multi-level caching, specifically including: When processing a nearby user discovery request, the data status in the first cache and the second cache corresponding to the first user is checked. When both the first cache and the second cache are empty, the current nearby user discovery request for the first user is determined as the first request. If it is determined to be the first request, candidate users are queried for the first user based on multiple preset data sources within a limited first candidate number range. On the premise of excluding users recorded in the set of read users associated with the first user and the first user himself, the candidate users from each preset data source are merged and deduplicated according to the user identifier to obtain the first candidate user set. The initial set of candidate users is input into the recommendation algorithm service as the set of candidate users to be evaluated. The matching score data for the first user is obtained. The initial recommended user list is generated based on the matching score data. The target recommended users to be used to constitute the recommendation result are selected from the initial recommended user list and returned to the client. While returning the recommendation results, other recommended users who were not selected as target recommended users in the initial recommended user list are written to the first cache through the asynchronous execution channel. A candidate filling operation for the first user is triggered based on multiple preset data sources. Within the limited total number of target candidates, new candidate users are queried and written to the second cache to form a set of candidate users for subsequent request processing. After completing the synchronous processing of the nearby user discovery request, the data state associated with the first cache, the second cache, and the set of read users is submitted as a maintenance task to the asynchronous execution channel, and multi-level cache maintenance is performed in a decoupled manner from the synchronous processing thread of the nearby user discovery request. Based on the maintenance task in the asynchronous execution channel, the second cache is warmed up and filled, including: detecting the number of candidate users for the first user in the second cache; when the number of candidate users is lower than the preset first threshold, excluding the users recorded in the read user set and the first user himself, calling the preset data source to query for new candidate users for the first user, writing the queried candidate users into the second cache, and forming an updated candidate user set. Based on the maintenance task in the asynchronous execution channel, a preheating and filling operation is performed on the first cache, including: detecting the number of recommended users for the first user in the first cache; when the number of recommended users is lower than a preset second threshold and the number of candidate users for the first user in the second cache reaches a preset third threshold, selecting a preset number of candidate users from the second cache as a preheating candidate user set and inputting it into the recommendation algorithm service to obtain the corresponding matching score data and location-related data; generating a preheating recommended user list based on the matching score data and location-related data; and writing the recommended users in the preheating recommended user list into the first cache. The first threshold, the second threshold, and the third threshold constitute a threshold triggering mechanism, which is used to automatically trigger the corresponding asynchronous maintenance operation and preheating operation when the data status stored in the first cache and the second cache meets the threshold conditions.

[0034] like Figure 3 As shown, specifically, in scenarios involving the first request and insufficient caching, an asynchronous maintenance mechanism for the first request fast path and multi-level caching is introduced.

[0035] Regarding the determination of the first request, when processing a nearby user discovery request, the server first checks the data status of the first and second caches corresponding to the first user. If it detects that there is no record for the user in either the first or second cache (for example, the number of elements in the Hook Cache and Candidate Pool are both 0), the current request is determined to be the first request.

[0036] In the initial request scenario, the server queries candidate users in parallel for the first user based on multiple preset data sources, within a limited initial candidate range (e.g., 50). During the query process, the first user and all users in their read user set are excluded. The candidate results from each data source are merged and deduplicated according to user identifiers, based on preset weights configured for each data source, resulting in an initial candidate user set. The server uses this initial candidate user set as the candidate user set to be evaluated, calls the recommendation algorithm service to calculate the matching score, generates an initial recommended user list, and selects the target recommended users (e.g., the top 20) from this list to constitute the current recommendation result. This list is then directly returned to the client, shortening the response time for the initial request.

[0037] While returning the recommendation results for the first request, the server writes other recommended users who were not selected as target recommended users in the initial recommended user list into the first cache through an asynchronous execution channel, so that they can be quickly hit in subsequent requests; and triggers a candidate filling operation for the first user through the asynchronous execution channel, calling multiple preset data sources to query and add new candidate users within a limited target total number of candidates (e.g., target 200), and writes them into the second cache after fusion and deduplication, forming a larger set of candidate users for subsequent requests.

[0038] Regarding multi-level cache maintenance, after completing the synchronous processing of any nearby user discovery request, the server no longer blocks the current request. Instead, it encapsulates the data states of the first cache, second cache, and the set of read users related to that request into a maintenance task and submits it to the asynchronous execution channel. In the asynchronous execution channel, the system background thread is decoupled from the main request processing thread to perform multi-level cache maintenance.

[0039] like Figure 4As shown, in terms of warming up and filling the second cache, the asynchronous maintenance task will detect the number of candidate users for the first user. When the number of candidate users is lower than the preset first threshold (e.g., 50), after excluding the already read user set and the first user himself, multiple preset data sources will be called again to query for new candidate users. The queried candidate users will be merged, deduplicated, and written into the second cache to form an updated candidate user set in order to maintain the candidate size of the Candidate Pool.

[0040] Regarding the preheating and filling of the first cache, the asynchronous maintenance task detects the number of recommended users for the first user in the first cache. When the number of recommended users is lower than a preset second threshold (e.g., 20) and the number of candidate users in the second cache reaches a preset third threshold (e.g., 50), a preset number of candidate users are selected from the second cache according to the sorting result as a preheating candidate user set. The recommendation algorithm service is then called to calculate the matching score and location-related data to generate a preheating recommended user list. This list is then written into the first cache, realizing the background pre-calculation and filling of the Hook Cache. The aforementioned first, second, and third thresholds constitute a threshold triggering mechanism, which automatically triggers the corresponding asynchronous maintenance and preheating actions when the cached data volume is lower than a preset level.

[0041] In the above embodiments, preferably, the first cache is used to store recommended users whose recommendation calculations have been completed, and includes: The first sorting structure is used to store recommended users with their user IDs as indexes and their ratings calculated based on matching scores as sorting criteria. The first detailed storage structure is used to store the display information corresponding to the recommended user, indexed by the user ID of the recommended user. The display information includes the username, avatar, and relationship tag. The specific process of reading the pre-stored set of recommended users for the first user from the first cache includes: Based on the first sorting structure, a set of candidate recommended user identifiers is determined according to the score value from high to low. Based on the first detailed storage structure, the display information corresponding to the set of candidate recommended user identifiers is obtained to form a set of recommended users for participating in the judgment of preset recommendation conditions.

[0042] In this implementation, the first cache is used to store recommended users whose recommendation calculations have been completed, which can be implemented through a dual structure of Hook Cache.

[0043] The first sorting structure can adopt an ordered set structure from a cached database, such as a Redis ZSet. The key can be designed as `nearby:hooks:zset:{userId}`, where `{userId}` is the user identifier of the first user; `Member` is the user identifier of the recommended user, `targetUserId`; the score is used as the sorting criterion, a composite score calculated based on the matching score and distance, for example, `compositeScore = matchScore × 1000000 - distance`, where `matchScore` is the matching score returned by the recommendation algorithm service, and `distance` is the geographical distance between the first user and the candidate users. This design ensures that matching score is given priority during sorting, and distance is considered only when matching scores are the same or similar.

[0044] The first detailed storage structure can be implemented using a hash structure, such as Redis Hash. The key can be nearby:hooks:data:{userId}, the field is targetUserId, and the value is a JSON string containing the display information of the recommended user, such as username, avatar, matching score, hook title, hook content, relationship tags, etc., for front-end display and business logic rendering.

[0045] When retrieving the pre-stored set of recommended users for the first user from the first cache, the server first uses a first sorting structure to call an ordered set pop or query command (such as ZPOPMAX) according to the score value from high to low to determine the set of candidate recommended user identifiers. Then, based on the first detailed storage structure, it uses these user identifiers as field keys to read the corresponding JSON details, parses them to obtain the display information, and forms the set of recommended users used to participate in the preset recommendation criteria. If the number of recommended users is greater than or equal to the preset number of recommendations, they can be directly sorted and truncated according to the score to form the recommendation result for this time.

[0046] In the above embodiment, preferably, the second cache is used to store candidate users whose recommendation calculation has not yet been completed, and includes: The second sorting structure is used to store candidate users based on their user IDs as indexes and their candidate score values ​​calculated based on the distance between the candidate user and the first user and social relationship features. The second detailed storage structure is used to store the detailed information of candidate users with the candidate user's user identifier as the index. The detailed information includes at least the candidate user's user identifier, the distance between the candidate user and the location corresponding to the location information, and the data source identifier from which the candidate user comes. The specific process of reading the candidate user set for the first user from the second cache includes: selecting a set of candidate user identifiers that meet the preset candidate conditions according to the order of candidate score values ​​based on the second sorting structure, and obtaining the detailed information corresponding to the candidate user identifier set based on the second detailed storage structure to form a candidate user set for input to the recommendation algorithm service.

[0047] In this implementation, the second cache is used to store candidate users whose recommendation calculations have not yet been completed, which can be implemented through a dual structure of the Candidate Pool.

[0048] The second sorting structure can adopt an ordered set structure in a cache database (such as Redis ZSet), with the key being nearby:candidate:{userId}, the member being the candidate user's user identifier targetUserId, and the score being the basic comprehensive score (candidate score value). This candidate score value can be calculated based on factors such as the geographical distance between the candidate user and the first user, social relationship characteristics (such as the number of mutual friends and the number of mutual group chats), etc. For example, when the algorithm service is not invoked, the basic matching score is composed of distance and social relationship characteristics.

[0049] The second detailed storage structure can adopt a hash structure (such as Redis Hash), with the key being nearby:candidate:detail:{userId}, the field being the candidate user identifier targetUserId, and the value being detailed information in JSON format, including at least the candidate user's user identifier, the distance between the candidate user and the first user's location, the data source identifier of the candidate user's source (such as ES geolocation, second-degree friends, high-quality circles, open homepage), and information such as the number of mutual friends and mutual group chats.

[0050] When reading the candidate user set from the second cache, the server selects a set of candidate user identifiers that meet preset candidate conditions based on the second sorting structure, according to the candidate score values ​​from high to low (for example, selecting the top few candidate users for this recommendation or pre-launch). Then, it obtains the detailed information of these candidate users based on the second detailed storage structure. The above candidate user set is passed as input to the recommendation algorithm service to calculate a more refined matching score and further generate a list of recommended users.

[0051] In the above implementation, preferably, the set of read users associated with the first user is implemented using an ordered set structure, with the key value used to identify the first user as the index, the user ID of the read user as the member, and the timestamp corresponding to the time of the recommendation result return as the sorting basis; When writing the user identifier corresponding to the target recommended user into the set of read users, each user is written into an ordered set structure and the current timestamp is recorded. When the number of members in the ordered set structure exceeds the preset capacity limit, the member with the smallest score is deleted to implement the least recently used elimination strategy. An expiration time threshold is configured for the ordered set structure so that read records that exceed the expiration time threshold are automatically invalidated. This allows for the construction of filtering conditions to exclude read users based on the set of read users when querying new candidate users for the first user based on multiple preset data sources.

[0052] In another implementation, the set of read users associated with the first user can be implemented through a Viewed Pool of read users, which uses an ordered set structure to record read users.

[0053] Specifically, the Viewed Pool uses an ordered set structure (such as Redis ZSet) in the cache database, with the key being nearby:viewed:{userId}, indexed by the first user's identifier, userId. The members of the ordered set are the user identifiers of the users who have read the data (viewedUserId), and the score is the corresponding viewing timestamp. When the system writes the target recommended user to the set of read users, it performs an add operation on each target recommended user in the current recommendation result, adding their user identifier to the ZSet and using the current timestamp (which can be incremented slightly to ensure order uniqueness) as the score.

[0054] To control the size of the set of read users, the Viewed Pool is configured with a capacity limit, such as 500. When the number of members in the set exceeds the capacity limit, the system deletes the member with the lowest score, i.e., the earliest user to view the data, thus implementing an eviction policy similar to Least Recently Used (LRU). Meanwhile, to prevent read records from permanently occupying memory resources, an expiration time threshold is set on the Viewed Pool, such as 24 hours; ZSet keys exceeding this time automatically expire. When performing candidate queries or candidate population from multiple data sources, the system first reads the currently valid set of read users from the Viewed Pool, and uses these user identifiers as exclusion conditions to pass to each data source query interface, avoiding repeatedly recommending users who have already viewed the data to the same user, forming a closed loop of "read filtering → candidate generation → recommendation output → read update".

[0055] In the above embodiments, preferably, the multiple preset data sources include at least location data sources, social relationship data sources, and interest preference data sources; The specific process of querying new candidate users for the first user based on multiple preset data sources and merging them to obtain a fused candidate user set includes: Configure weight parameters for each preset data source, and determine the candidate quantity quota corresponding to each preset data source based on the current target candidate quantity for the first user; For each preset data source, after excluding the first user and the users recorded in the set of read users, a list of candidate users matching the first user is queried according to their respective preset sorting rules, and a subset of candidate users for fusion is selected from the candidate user list based on the corresponding candidate quantity quota. The candidate user subsets from each preset data source are merged according to the candidate user's user identifier. When the same candidate user appears in multiple preset data sources, the corresponding source data source identifiers are merged and recorded to form a fused candidate user set for writing to the second cache.

[0056] In this implementation, multi-data source candidate queries and fusion can be achieved using a scalable multi-data source framework.

[0057] Multiple pre-defined data sources include at least location data sources (such as Elasticsearch geolocation indexes), social relationship data sources (such as second-degree friend services), interest preference data sources (such as high-quality circles / interest groups services), and open homepage data sources as a fallback supplement. The system pre-configures weight parameters for each data source; for example, location data sources have a weight of 0.5, social relationship data sources have a weight of 0.2, interest preference data sources have a weight of 0. The open homepage data source, as a fallback data source, can have a weight set to 0 and is only used when the primary data source is insufficient.

[0058] When querying for new candidate users for the first user based on multiple preset data sources, the system calculates the candidate quota corresponding to each preset data source based on the current target number of candidates for the first user (e.g., 200) and the weight of each data source. For example, 100 for ES geographic queries, 40 for second-degree friends, and 60 for high-quality circles. For each data source, after excluding the first user and users in the set of users who have read the data, the system queries a list of candidate users matching the first user according to its preset sorting rules (e.g., from closest to furthest, from most to fewest mutual friends, from highest to lowest circle activity, etc.), and extracts a subset of candidate users corresponding to the quota from each list.

[0059] The system merges subsets of candidate users from multiple preset data sources according to their user identifiers. When the same candidate user appears in different data sources, the system merges and records the corresponding source data source identifiers or data source lists to form a fused candidate user set. Finally, this fused candidate user set is written into the ZSet and Hash structures of the second cache (Candidate Pool) to provide candidate input for subsequent recommendation algorithm calls.

[0060] In the above embodiments, preferably, the process of inputting at least partially updated candidate user sets into the recommendation algorithm service specifically includes: The updated candidate user set is divided into multiple candidate batches according to the preset batch size; Configure an asynchronous execution thread pool for the recommendation algorithm calls, and encapsulate each candidate batch into an independent algorithm call task and submit it to the asynchronous execution thread pool; Configure a first timeout for the algorithm call of a single candidate batch. When the algorithm call of any candidate batch exceeds the first timeout or an error occurs, generate a list of recommended users based on the matching score data returned by the candidate batches that have completed the algorithm call and the data related to location information. Specifically, when the recommendation algorithm service is detected to be unavailable, a basic matching score is calculated based on the distance between the candidate user and the first user and the social relationship features. This basic matching score is then used as the matching score data to participate in the generation of the recommended user list.

[0061] In this implementation, when inputting the updated candidate user set into the recommendation algorithm service, a batch parallel call and timeout degradation strategy are adopted to improve the overall throughput and availability.

[0062] Regarding the batching strategy, when recommendation calculations are needed for, for example, 50 candidate users, the server divides the candidate users into multiple candidate batches (e.g., 5 batches) according to a preset batch size (e.g., 10). The system configures an asynchronous execution thread pool for recommendation algorithm calls, for example, using a separate thread pool executor (ThreadPoolTaskExecutor) with 4 core threads, a maximum of 8 threads, a queue capacity of 200, and thread name prefixes that can be set to "nearby-algorithm-" for easy logging and monitoring. Each candidate batch is encapsulated as an independent algorithm call task and submitted to the thread pool for parallel execution via an asynchronous mechanism (e.g., CompletableFuture).

[0063] Regarding timeout control, a first timeout is configured for each candidate batch. For example, this can be configured via client calls, setting the connection timeout for the algorithm service to 1 second and the read timeout to 1.5 seconds. When the algorithm call for any candidate batch exceeds the first timeout or an exception occurs, the system stops waiting for the batch's results and generates the recommended user list for the current round solely based on the matching score data from other successfully returned batches and location-related data. Optionally, the system can also configure an overall timeout for batch calls (e.g., 2 seconds) to prevent the overall call from being blocked by a single slow query.

[0064] Regarding the degradation strategy, when the overall availability of the recommendation algorithm service is detected (e.g., continuous call failures reaching the circuit breaker threshold), the system no longer calls the algorithm interface. Instead, it calculates a basic matching score based on the distance and social relationship features between the candidate user and the first user. This basic matching score is used as the matching score data in the generation of the recommended user list, and the default Hook text can be used as the display content. Through the above-mentioned batch parallelism, timeout control, and degradation strategies, the recommendation latency is reduced while ensuring high system availability.

[0065] In the above embodiments, preferably, the social user discovery method based on multi-level caching and intelligent recommendation pool further includes: In the process of querying new candidate users for the first user based on multiple preset data sources and writing the fused candidate user set into the second cache, when the number of candidate users after fusion and deduplication is less than the preset depletion detection threshold, it is determined that the data of nearby users corresponding to the first user is in a data depletion state, and a data depletion mark is written to the key value used to identify the first user in the key-value cache database, and a preset expiration time is set for the data depletion mark. Furthermore, before performing warm-up and filling operations on the second cache based on the asynchronous execution channel, it is first checked whether there is a data depletion mark corresponding to the first user that has not expired. When a data depletion mark is detected, the current asynchronous warm-up and filling operation for the first user is skipped until the data depletion mark automatically expires due to exceeding the preset expiration time or is cleared by an external instruction, and then the warm-up and filling operation for the first user is resumed.

[0066] In this implementation, for remote areas or situations where users have viewed a large number of users, resulting in almost no new users nearby, the system introduces a data depletion detection and marking mechanism.

[0067] During the process of querying new candidate users for the first user based on multiple preset data sources and writing the merged candidate user set into the second cache, the system counts the number of candidate users after merging and deduplication. When this number is less than a preset exhaustion detection threshold (e.g., 10), it is determined that the data of nearby users corresponding to the first user is in a data exhaustion state. At this time, the system writes a data exhaustion flag for the user in the key-value cache database, for example, using a Redis String structure, with the key being nearby:exhausted:{userId}, and the value being the current timestamp or a fixed flag value, and sets an expiration time for the flag (e.g., 10 minutes) to avoid long-term blocking of filling.

[0068] Before performing preheating and filling operations on the second cache via the asynchronous execution channel, the system first checks for the existence of a data exhaustion flag corresponding to the user that has not expired. If a data exhaustion flag is detected, the asynchronous filling and preheating operations for that user will be skipped, and multiple preset data sources will not be called for queries, avoiding repeated access to the database and external services in invalid areas. As the exhaustion flag automatically expires due to exceeding its expiration time, or is externally cleared when the user actively triggers a reset operation, the system can resume the preheating and filling operations for that user during subsequent asynchronous maintenance, achieving a balance between resource conservation and user experience.

[0069] In the above embodiments, preferably, the specific process of updating the location cache based on the user identifier and location information of the first user includes: In a key-value cache database, the key value used to identify the first user is used as an index. A hash structure is used to store at least the longitude field, latitude field, and location update time field corresponding to the location information. An expiration time for the location data is set for the key value so that the location information that exceeds the location data expiration time will automatically become invalid. The location of the first user is determined based on the longitude and latitude fields in the location cache.

[0070] In this implementation, the location cache can be implemented through the hash structure of the cache database to record the current location of the first user and its update time, which is used for subsequent distance calculation and candidate filtering.

[0071] Upon receiving a nearby user discovery request with location parameters, the server uses a key-value cache database indexed by the key identifying the first user (e.g., `nearby:location:{userId}`). This cache stores at least three fields using a hash structure: longitude, latitude, and updateTime. The system sets an expiration time (e.g., 30 minutes) for this key. Location information exceeding this expiration time automatically becomes invalid to prevent the prolonged use of expired locations for nearby user recommendations. In subsequent multi-data source queries and recommendation calculations, the system can directly read the longitude and latitude fields from the location cache, convert them to geographic coordinates for distance calculations and region filtering, without repeatedly relying on request parameters, ensuring the consistency and reusability of location data.

[0072] This invention also proposes a social user discovery system based on multi-level caching and intelligent recommendation pools, applying the social user discovery method based on multi-level caching and intelligent recommendation pools disclosed in any of the above embodiments, including: The user location update module is deployed in the business gateway or user service. It is used to receive the nearby user discovery request for the first user in the social application. The request contains at least the user identifier and location information of the first user, and updates the location cache based on the user identifier and location information of the first user. The recommended user set module is used to read the recommended user set pre-stored for the first user from the first cache (Hook Cache) based on the user identifier of the first user. When the recommended user set meets the preset recommendation conditions, the module selects the target recommended user to form the recommendation result from the recommended user set based on the preset sorting and truncation rules, writes the user identifier corresponding to the target recommended user into the read user set associated with the first user, and returns the recommendation result to the client. The candidate user update module is used to read the candidate user set for the first user from the second cache (Candidate Pool) when the recommended user set does not meet the preset recommendation conditions. When the candidate user set does not meet the preset candidate conditions, it queries for new candidate users for the first user based on multiple preset data sources and merges them to obtain a fused candidate user set, which is then written to the second cache to obtain the updated candidate user set. The recommended user matching module is used to input at least a partially updated set of candidate users into the recommendation algorithm service, obtain a matching score for the first user, generate a list of recommended users based on the matching score, select target recommended users from the list of recommended users to form the recommendation result, write the user identifier corresponding to the target recommended user into the read user set, return the recommendation result to the client, and write recommended users that were not selected as target recommended users into the first cache.

[0073] The modules mentioned above communicate via internal RPC or message queues to achieve a high-performance, highly available "people nearby" recommendation service.

[0074] The social user discovery system based on multi-level caching and intelligent recommendation pool disclosed in the above embodiments has the same functions as the steps of the social user discovery method based on multi-level caching and intelligent recommendation pool disclosed in the above embodiments. In the implementation process, the above embodiments are referred to for operation, and will not be repeated here.

[0075] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A social user discovery method based on multi-level caching and intelligent recommendation pool, characterized in that, include: Receive a nearby user discovery request for a first user from a social application, the request containing at least the first user's user identifier and location information, and update the location cache based on the first user's user identifier and location information; Based on the user identifier of the first user, a set of recommended users pre-stored for the first user is read from the first cache. When the set of recommended users meets the preset recommendation conditions, a target recommended user is selected from the set of recommended users to form the recommendation result based on the preset sorting and truncation rules. The user identifier corresponding to the target recommended user is written into the set of read users associated with the first user, and the recommendation result is returned to the client. When the recommended user set does not meet the preset recommendation conditions, the candidate user set for the first user is read from the second cache. When the candidate user set does not meet the preset candidate conditions, new candidate users are queried for the first user based on multiple preset data sources and merged to obtain a fused candidate user set, which is then written into the second cache to obtain an updated candidate user set. The updated candidate user set is input into the recommendation algorithm service to obtain a matching score for the first user. A recommended user list is generated based on the matching score. Target recommended users for constituting the recommendation result are selected from the recommended user list. The user identifier corresponding to the target recommended user is written into the read user set. The recommendation result is returned to the client. Recommended users that are not selected as the target recommended users are written into the first cache.

2. The social user discovery method based on multi-level caching and intelligent recommendation pool according to claim 1, characterized in that, This also includes initial request processing and asynchronous maintenance of multi-level caches, specifically including: When processing the nearby user discovery request, the data status in the first cache and the second cache corresponding to the first user is detected. When both the first cache and the second cache are empty, the current nearby user discovery request for the first user is determined as the first request. If it is determined to be the first request, candidate users are queried for the first user based on the multiple preset data sources within a limited first candidate number range. On the premise of excluding users recorded in the read user set associated with the first user and the first user himself, the candidate users from each preset data source are merged and deduplicated according to the user identifier to obtain the first candidate user set. The initial candidate user set is input into the recommendation algorithm service as the candidate user set to be evaluated to obtain matching score data for the first user. An initial recommended user list is generated based on the matching score data. Target recommended users for constituting the recommendation result are selected from the initial recommended user list and returned to the client. While returning the recommendation result, other recommended users who were not selected as the target recommended user in the initial recommended user list are written into the first cache through an asynchronous execution channel. A candidate filling operation for the first user is triggered based on the multiple preset data sources. Within the limited target total number of candidates, new candidate users are queried and written into the second cache to form a candidate user set for subsequent request processing. After completing the synchronous processing of the nearby user discovery request, the data status associated with the first cache, the second cache, and the set of read users is submitted as a maintenance task to the asynchronous execution channel, and multi-level cache maintenance is performed in a decoupled manner from the synchronous processing thread of the nearby user discovery request. Based on the maintenance task in the asynchronous execution channel, the second cache is preheated and filled, including: detecting the number of candidate users for the first user in the second cache; when the number of candidate users is lower than a preset first threshold, excluding the users recorded in the read user set and the first user himself, calling the preset data source to query new candidate users for the first user, writing the queried candidate users into the second cache to form an updated candidate user set. Based on the maintenance task in the asynchronous execution channel, a preheating and filling operation is performed on the first cache, including: detecting the number of recommended users for the first user in the first cache; when the number of recommended users is lower than a preset second threshold and the number of candidate users for the first user in the second cache reaches a preset third threshold, selecting a preset number of candidate users from the second cache as a preheating candidate user set and inputting it into the recommendation algorithm service to obtain the corresponding matching score data and data related to the location information; generating a preheating recommended user list based on the matching score data and the data related to the location information; and writing the recommended users in the preheating recommended user list into the first cache. The first threshold, the second threshold, and the third threshold constitute a threshold triggering mechanism, which is used to automatically trigger corresponding asynchronous maintenance and preheating operations when the data status stored in the first cache and the second cache meets the threshold conditions.

3. The social user discovery method based on multi-level caching and intelligent recommendation pool according to claim 1, characterized in that, The first cache is used to store recommended users whose recommendation calculations have been completed, and includes: The first sorting structure is used to store recommended users with the user ID of the recommended user as the index and the score value calculated based on the matching score as the sorting criterion. The first detailed storage structure is used to store the display information corresponding to the recommended user, indexed by the user ID of the recommended user. The display information includes the username, avatar, and relationship tag. The specific process of reading the pre-stored set of recommended users for the first user from the first cache includes: Based on the first sorting structure, a set of candidate recommended user identifiers is determined from high to low according to the score value, and the display information corresponding to the set of candidate recommended user identifiers is obtained based on the first detailed storage structure, so as to form a set of recommended users for participating in the judgment of the preset recommendation conditions.

4. The social user discovery method based on multi-level caching and intelligent recommendation pool according to claim 3, characterized in that, The second cache is used to store candidate users for whom recommendation calculations have not yet been completed, and includes: The second sorting structure is used to store candidate users based on their user IDs as indexes and candidate score values ​​calculated based on the distance between the candidate user and the first user and social relationship features. The second detailed storage structure is used to store detailed information of candidate users with the candidate user's user identifier as an index. The detailed information includes at least the candidate user's user identifier, the distance between the candidate user and the location corresponding to the location information, and the data source identifier from which the candidate user originates. The specific process of reading the candidate user set for the first user from the second cache includes: selecting a set of candidate user identifiers that meet the preset candidate conditions according to the order of the candidate score values ​​based on the second sorting structure, and obtaining the detailed information corresponding to the candidate user identifier set based on the second detailed storage structure to form a candidate user set for input to the recommendation algorithm service.

5. The social user discovery method based on multi-level caching and intelligent recommendation pool according to claim 4, characterized in that, The set of read users associated with the first user is implemented using an ordered set structure, with the key value used to identify the first user as the index, the user ID of the read user as the member, and the timestamp corresponding to the time the recommendation result is returned as the sorting basis; When writing the user identifier corresponding to the target recommended user into the read user set, each member is written into the ordered set structure and the current timestamp is recorded. When the number of members in the ordered set structure exceeds the preset capacity limit, the member with the smallest score is deleted to implement the least recently used elimination strategy. An expiration time threshold is configured for the ordered set structure so that read records that exceed the expiration time threshold are automatically invalidated. This allows for the construction of filtering conditions to exclude read users based on the read user set when querying new candidate users for the first user based on the multiple preset data sources.

6. The social user discovery method based on multi-level caching and intelligent recommendation pool according to claim 5, characterized in that, The multiple preset data sources include at least location data sources, social relationship data sources, and interest preference data sources; The specific process of querying new candidate users for the first user based on multiple preset data sources and merging them to obtain a fused candidate user set includes: Configure weight parameters for each preset data source, and determine the candidate quantity quota corresponding to each preset data source based on the current target candidate quantity for the first user; For each preset data source, excluding the first user and the users recorded in the set of read users, a list of candidate users matching the first user is queried according to their respective preset sorting rules, and a subset of candidate users for fusion is selected from the list of candidate users based on the corresponding candidate quantity quota. The candidate user subsets from each preset data source are merged according to the candidate user's user identifier. When the same candidate user appears in multiple preset data sources, the corresponding source data source identifiers are merged and recorded to form a fused candidate user set for writing to the second cache.

7. The social user discovery method based on multi-level caching and intelligent recommendation pool according to claim 6, characterized in that, The process of inputting at least a portion of the updated candidate user set into the recommendation algorithm service specifically includes: The updated set of candidate users is divided into multiple candidate batches according to a preset batch size; Configure an asynchronous execution thread pool for the recommendation algorithm call, and encapsulate each candidate batch into an independent algorithm call task and submit it to the asynchronous execution thread pool; Configure a first timeout period for the algorithm call of a single candidate batch. When the algorithm call of any candidate batch exceeds the first timeout period or an error occurs, generate a recommended user list based on the matching score data returned by the candidate batches that have completed the algorithm call and the data related to the location information. Specifically, when the recommendation algorithm service is detected to be unavailable, a basic matching score is calculated based on the distance between the candidate user and the first user and the social relationship features. This basic matching score is then used as matching score data to participate in the generation of the recommended user list.

8. The social user discovery method based on multi-level caching and intelligent recommendation pool according to claim 2, characterized in that, Also includes: In the process of querying new candidate users for the first user based on multiple preset data sources and writing the fused candidate user set into the second cache, when the number of candidate users after fusion and deduplication is less than a preset depletion detection threshold, it is determined that the data of nearby users corresponding to the first user is in a data depletion state, and a data depletion mark is written into the key value used to identify the first user in the key-value cache database, and a preset expiration time is set for the data depletion mark. Furthermore, before performing warm-up and filling operations on the second cache based on the asynchronous execution channel, it is first detected whether there is a data depletion mark corresponding to the first user that has not expired. When the data depletion mark is detected, the current asynchronous warm-up and filling operation for the first user is skipped until the data depletion mark automatically expires due to exceeding the preset expiration time or is cleared by an external instruction, and then the warm-up and filling operation for the first user is resumed.

9. The social user discovery method based on multi-level caching and intelligent recommendation pool according to claim 2, characterized in that, The specific process of updating the location cache based on the user identifier of the first user and the location information includes: In the key-value cache database, the key value used to identify the first user is used as an index. A hash structure is used to store at least the longitude field, latitude field, and location update time field corresponding to the location information. A location data expiration time is set for the key value so that the location information that exceeds the location data expiration time will automatically become invalid. The location of the first user is determined based on the longitude and latitude fields in the location cache.

10. A social user discovery system based on multi-level caching and intelligent recommendation pool, characterized in that, The social user discovery method based on multi-level caching and intelligent recommendation pool as described in any one of claims 1 to 9 includes: The user location update module is used to receive a nearby user discovery request for a first user in a social application. The request includes at least the user identifier and location information of the first user, and updates the location cache based on the user identifier and location information of the first user. The recommended user set module is used to read a pre-stored recommended user set for the first user from the first cache based on the user identifier of the first user. When the recommended user set meets the preset recommendation conditions, the module selects the target recommended user to form the recommendation result from the recommended user set based on the preset sorting and truncation rules, writes the user identifier corresponding to the target recommended user into the read user set associated with the first user, and returns the recommendation result to the client. The candidate user update module is used to read the candidate user set for the first user from the second cache when the recommended user set does not meet the preset recommendation conditions; and when the candidate user set does not meet the preset candidate conditions, to query new candidate users for the first user based on multiple preset data sources and merge them to obtain a fused candidate user set, and write it into the second cache to obtain an updated candidate user set. The recommended user matching module is used to input at least a portion of the updated candidate user set into the recommendation algorithm service to obtain a matching score for the first user, generate a recommended user list based on the matching score, select target recommended users from the recommended user list to constitute the recommendation result, write the user identifier corresponding to the target recommended user into the read user set, return the recommendation result to the client, and write recommended users that were not selected as the target recommended users into the first cache.

Images