Request processing method and device, computer equipment and storage medium
By storing only the tag data of candidate stores and users in the cache database and building a query index, the problems of high storage cost and low query efficiency of the cache database are solved, and the stability of high-concurrency queries and accurate distribution of activity benefits are achieved.
Patent Information
- Application Number
- CN202610103812.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-01-26
- Publication Date
- 2026-04-21
AI Technical Summary
With the development of the live streaming industry, the amount of tag data in the cache database continues to grow, resulting in excessively high storage costs and low query efficiency, making it difficult to meet the needs of high-concurrency queries.
The cache database stores only the tag data of candidate stores and users. By building a store and user query index, the target store and user tags can be quickly located, reducing the storage of full data and prioritizing queries from the cache database to dynamically update the tag data.
It reduces the storage cost of the cache database, improves query efficiency, and can stably support high-concurrency query needs, ensuring the accuracy of activity benefit distribution and merchant marketing efficiency.
Smart Images
Figure CN121908032A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of database technology, and in particular to a request processing method, apparatus, computer device, and storage medium. Background Technology
[0002] With the rapid development of the live streaming industry, live streaming-related business scenarios are becoming increasingly diverse. When conducting these businesses, merchants need to accurately screen target users and distribute benefits through user tags.
[0003] In related technologies, all the store's tag data is usually synchronized to a cache database (such as Redis) to support the tag query needs of client business.
[0004] However, the total amount of tag data continues to grow, and storing all tag data requires a significant upgrade to the cache database configuration. Moreover, as the data volume increases, the storage cost of the cache database becomes too high. Summary of the Invention
[0005] Therefore, it is necessary to provide a request processing method, apparatus, computer equipment, and storage medium to address the aforementioned technical problems, which can reduce the storage cost of the cache database while meeting the needs of high-concurrency queries.
[0006] Firstly, this application provides a request processing method applied to a server, comprising:
[0007] Obtain the interactive activity participation request from the viewing terminal; the interactive activity participation request is generated after the target viewing account corresponding to the viewing terminal enters the target store's live broadcast room, and the interactive activity participation request includes the target store identifier of the target store and the target user identifier of the target viewing account;
[0008] The target store identifier is retrieved from the cache database; wherein, the cache database stores the store identifier of the candidate store and the user tag of the candidate user identifier; the candidate store is the store that has used the user tag, and the candidate user identifier is the user identifier of the viewing account that has entered the live broadcast room of the candidate store;
[0009] If the target store identifier is found, the user tag corresponding to the target user identifier is retrieved from the cache database;
[0010] The system responds to user participation requests based on the retrieved user tags.
[0011] In one embodiment, querying the target store identifier from the cache database includes:
[0012] Based on the target store identifier, construct a store query index;
[0013] The target store identifier is retrieved from the identifier set corresponding to the store query index stored in the cache database.
[0014] In one embodiment, constructing a store query index based on the target store identifier includes:
[0015] Extract the target characters from the target store identifier;
[0016] Based on the target characters, construct a store query index.
[0017] In one embodiment, querying the user tag corresponding to the target user identifier from the cache database includes:
[0018] Construct a user query index based on the target user identifier and the target store identifier;
[0019] Based on the user query index, the tag set corresponding to the user query index is queried from the cache database to obtain the user tag corresponding to the target user identifier.
[0020] In one embodiment, the method further includes:
[0021] During the initialization of the cache database, a full scan of the tag usage records of each store is performed to obtain candidate stores, and the store identifiers of the candidate stores are written into the cache database; and / or,
[0022] If an activity involving user tags is detected by an unlabeled store, or if a user tag is assigned to a user identifier associated with the unlabeled store, the store identifier of the unlabeled store is written to the cache database; wherein, the unlabeled store is a store that has not used user tags.
[0023] In one embodiment, the method further includes at least one of the following:
[0024] During the initialization of the cache database, candidate user identifiers are determined, and user tags corresponding to the candidate user identifiers are written into the cache database;
[0025] If a new viewing account is detected entering any candidate store's live stream, the user tag corresponding to the new viewing account is written into the cache database;
[0026] If a change in the user tag of any candidate user identifier is detected, the updated user tag will be written to the cache database;
[0027] If the target store identifier of the target store is found in the cache database, but the user query index corresponding to the target user identifier is not found in the cache database, and the user tag corresponding to the target user identifier is found in the relational database, then the user tag found in the relational database will be written into the cache database.
[0028] In one embodiment, responding to the interactive activity participation request based on the queried user tags includes:
[0029] Based on the retrieved user tags and the participation rules of the interactive activity corresponding to the interactive activity participation request, the participation permissions of the target viewing account for the interactive activity are determined.
[0030] Based on the participation permissions, output the response result for the participation request in the interactive activity.
[0031] Secondly, this application also provides a request processing apparatus, which is applied to a server and includes:
[0032] The acquisition module is used to acquire interactive activity participation requests from the viewing terminal; the interactive activity participation request is generated after the target viewing account corresponding to the viewing terminal enters the target store's live broadcast room, and the interactive activity participation request includes the target store identifier of the target store and the target user identifier of the target viewing account;
[0033] The first query module is used to query the target store identifier from the cache database; wherein, the cache database stores the store identifier of the candidate store and the user tag of the candidate user identifier; the candidate store is the store that has used the user tag, and the candidate user identifier is the user identifier of the viewing account that has entered the live broadcast room of the candidate store;
[0034] The second query module is used to query the user tag corresponding to the target user identifier from the cache database when the target store identifier is found;
[0035] The response module is used to respond to the interactive activity participation request based on the retrieved user tags.
[0036] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:
[0037] Obtain the interactive activity participation request from the viewing terminal; the interactive activity participation request is generated after the target viewing account corresponding to the viewing terminal enters the target store's live broadcast room, and the interactive activity participation request includes the target store identifier of the target store and the target user identifier of the target viewing account;
[0038] The target store identifier is retrieved from the cache database; wherein, the cache database stores the store identifier of the candidate store and the user tag of the candidate user identifier; the candidate store is the store that has used the user tag, and the candidate user identifier is the user identifier of the viewing account that has entered the live broadcast room of the candidate store;
[0039] If the target store identifier is found, the user tag corresponding to the target user identifier is retrieved from the cache database;
[0040] The system responds to user participation requests based on the retrieved user tags.
[0041] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:
[0042] Obtain the interactive activity participation request from the viewing terminal; the interactive activity participation request is generated after the target viewing account corresponding to the viewing terminal enters the target store's live broadcast room, and the interactive activity participation request includes the target store identifier of the target store and the target user identifier of the target viewing account;
[0043] The target store identifier is retrieved from the cache database; wherein, the cache database stores the store identifier of the candidate store and the user tag of the candidate user identifier; the candidate store is the store that has used the user tag, and the candidate user identifier is the user identifier of the viewing account that has entered the live broadcast room of the candidate store;
[0044] If the target store identifier is found, the user tag corresponding to the target user identifier is retrieved from the cache database;
[0045] The system responds to user participation requests based on the retrieved user tags.
[0046] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:
[0047] Obtain the interactive activity participation request from the viewing terminal; the interactive activity participation request is generated after the target viewing account corresponding to the viewing terminal enters the target store's live broadcast room, and the interactive activity participation request includes the target store identifier of the target store and the target user identifier of the target viewing account;
[0048] The target store identifier is retrieved from the cache database; wherein, the cache database stores the store identifier of the candidate store and the user tag of the candidate user identifier; the candidate store is the store that has used the user tag, and the candidate user identifier is the user identifier of the viewing account that has entered the live broadcast room of the candidate store;
[0049] If the target store identifier is found, the user tag corresponding to the target user identifier is retrieved from the cache database;
[0050] The system responds to user participation requests based on the retrieved user tags.
[0051] The aforementioned request processing method, apparatus, computer equipment, and storage medium acquire interactive activity participation requests from the viewing client. These requests are generated when the target viewing account enters the target store's live stream room. The interactive activity participation request includes the target store identifier and the target user identifier of the target viewing account. The method retrieves the target store identifier from a cache database. The cache database stores store identifiers for candidate stores and user tags for candidate user identifiers. Candidate stores are stores that have used user tags, and candidate user identifiers are user identifiers of viewing accounts that have entered the candidate store's live stream room. If the target store identifier is found, the method retrieves the user tag corresponding to the target user identifier from the cache database. Based on the retrieved user tag, the method responds to the interactive activity participation request. This scheme stores only live stream-related user tag data in the cache database, which satisfies high-concurrency query requirements while reducing the amount of data stored in the cache database, thereby lowering the cache database storage cost. Attached Figure Description
[0052] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0053] Figure 1 This is a flowchart illustrating a request processing method in one embodiment;
[0054] Figure 2This is a flowchart illustrating the request processing method in another embodiment;
[0055] Figure 3 This is a structural block diagram of a request processing device in one embodiment;
[0056] Figure 4 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation
[0057] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0058] The request processing method provided in this application can be applied to live interactive application scenarios. This method can be executed by a server. The server can be a standalone physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server providing cloud computing services.
[0059] In one exemplary embodiment, such as Figure 1 As shown, a request processing method is provided. Taking the application of this method to a server as an example, the method includes the following steps:
[0060] S101, Obtain the interactive activity participation request from the viewing client.
[0061] The interactive activity participation request is generated after the target viewing account on the viewing terminal enters the target store's live stream room. This request includes the target store's identifier and the target user's identifier. For example, a request to complete a live stream task may be actively or passively triggered by the user entering the target store's live stream room. The viewing terminal refers to the user's terminal device for watching the live stream, including mobile phones, computers, tablets, etc. For example, a user might use a mobile phone to log into a live stream application (APP) to watch the target store's live stream room.
[0062] For example, the server can receive request data sent by the viewer through the backend interface of the live streaming app. The request data carries the target store identifier, the target user identifier, and the type of interactive activity. For instance, when a user clicks the "Participate in Live Streaming Task" button in the mobile live streaming app, the app's backend will send request data containing "app_123456", "user_789012", and "Participate in Live Streaming Task" to the server.
[0063] S102, query the target store identifier from the cache database.
[0064] The cache database stores the store identifiers of candidate stores and the user tags of candidate users. The target store identifier (app_id) is used to uniquely distinguish different stores, such as "app_123456", where "123456" is a store-specific code. The cache database can use Redis, an open-source, high-performance key-value store that supports various data structures. Candidate stores are those that have used user tags. Stores that have used user tags to conduct live streaming interactive activities, or those that have manually assigned tags to users, are candidate stores. For example, if a store has used tags to select users and distribute live streaming resources, then that store is a candidate store. The candidate user identifier is the user identifier corresponding to the viewing account that has entered the live streaming room of a candidate store. For example, if user "user_789012" has entered the live streaming room of candidate store "app_123456", then that user identifier is a candidate user identifier.
[0065] For example, the server uses Redis set query commands (such as SISMEMBER) to query whether the target store identifier exists in the Redis store tag usage status set.
[0066] In some optional implementations, a store query index can be built based on the target store identifier; and the target store identifier can be queried from the set of identifiers corresponding to the store query index stored in the cache database.
[0067] The store query index refers to the index structure used to quickly locate the target store identifier. It can be built based on the characteristics of the store identifier. For example, the target store identifier can be used directly as the store query index, or some characters of the target store identifier can be concatenated with preset characters to obtain the store query index.
[0068] In some optional implementations, target characters can be extracted from the target store identifier; and a store query index can be built based on the target characters.
[0069] For example, the target character can refer to the feature character extracted from the target store identifier for building the store query index. In this embodiment, it can be the two digits at the end of the store identifier. For example, the target character of the store identifier "app_123456" is "56".
[0070] For example, a string truncation function can be used to extract the last two characters of the store-specific code from the target store identifier. Then, a pre-defined prefix "app_is_use_tags_" can be concatenated with the target characters to form the key for the store query index. For instance, if the target character is "23", the constructed index key would be "app_is_use_tags_23".
[0071] In the above embodiments, dividing the keys by the last two digits of the store ID allows the store identifier to be evenly distributed across multiple keys, avoiding an excessively large set of data corresponding to a single key and ensuring query response speed. Furthermore, the extracted target characters are strongly correlated with the store identifier, and the constructed index is unique and targeted, which can accurately locate the set where the target store identifier is located, reducing the query range.
[0072] In this embodiment, the key format is "app_is_use_tags_xx" (xx is the last two digits of the store ID), and each key corresponds to an identifier set (a list of store IDs that have used the tags). The identifier set is a list of store IDs stored in a Redis collection type. For example, the identifier set corresponding to the key "app_is_use_tags_56" is ["app_123456", "app_789012", "app_345678"].
[0073] In Redis, store identifiers are stored using a key-based strategy. 100 keys are created based on the last two digits of the store ID, with the key format "app_is_use_tags_xx" (where xx represents the last two digits of the store ID). The value is a list of store IDs that have used the tags. For example, if the target store identifier is "app_123456" and its last two digits are "56", then the query will look up the set with the key "app_is_use_tags_56" to determine if "app_123456" is in that set.
[0074] For example, the last two characters of the target store identifier can be extracted as the suffix of the subkey, and a fixed prefix "app_is_use_tags_" can be concatenated to form the key of the store query index. For example, if the target store identifier is "app_987654" and the last two characters of its ID are "54", then the constructed store query index key is "app_is_use_tags_54".
[0075] Next, the Redis SISMEMBER command is used to determine whether the target store identifier exists in the set corresponding to the index key. If the return result is "1", it means that the target store identifier was found; if the return result is "0", it means that it was not found.
[0076] In the above embodiments, the index is constructed using a key-based approach. The store identifiers that have used tags are distributed and stored in multiple sets corresponding to multiple keys. This avoids the problem of low query efficiency caused by storing too much data in a single key and improves the query speed of store identifiers. Furthermore, the index structure is simple and is built based on the inherent characteristics of store identifiers. There is no need to maintain complex index relationships, which reduces system maintenance costs. In addition, key-based storage can balance the load of Redis shards, avoid resource overload on a single shard due to storing too many store identifiers, and ensure query stability in high-concurrency scenarios.
[0077] S103, if the target store identifier is found, retrieve the user tag corresponding to the target user identifier from the cache database.
[0078] The target user identifier (user_id) is used to uniquely distinguish different viewers, such as "user_789012", where "789012" is a user-specific code. User tags are markers used to describe user attributes or behavioral characteristics, and are divided into manual tags and automatic tags, such as "new user", "high-spending user", "user who has watched the broadcast for 3 consecutive days", etc. They are stored in the form of a list of tag IDs, such as ["110","112","113"], where "110" corresponds to the "new user" tag and "112" corresponds to the "high-spending user" tag.
[0079] For example, a correspondence between target user identifiers and associated user tags can be established in advance, and then the user tags corresponding to the target user identifiers can be queried based on the correspondence.
[0080] In some optional implementations, a user query index can be constructed based on the target user identifier and the target store identifier; and based on the user query index, the tag set corresponding to the user query index can be retrieved from the cache database to obtain the user tags corresponding to the target user identifier.
[0081] The user query index refers to the index structure used to quickly locate target user tag data. It is built based on the target user identifier and the target store identifier. The user query index, i.e., the key format in Redis is "user_crowd_tags:app_id:user_id". The tag set is a list of user tag IDs stored in a Redis collection type. For example, the tag set corresponding to the key "user_crowd_tags:app_123456:user_789012" is ["110","112","113"].
[0082] For example, the user query index key can be formed by concatenating strings in the format "user_crowd_tags:target store identifier:target user identifier". For instance, if the target store identifier is "app_123456" and the target user identifier is "user_789012", then the constructed user query index key would be "user_crowd_tags:app_123456:user_789012".
[0083] In the above embodiments, an index is constructed based on both store identifiers and user identifiers to ensure the uniqueness of user tag data across stores and avoid confusion between user tag data from different stores. Furthermore, the user query index format is uniform, the query logic is simple, and the user query index can be quickly constructed directly by concatenating identifiers, improving the query efficiency of user tags. In addition, the tag set is stored in the form of an ID list, which occupies little Redis storage space and further reduces storage costs.
[0084] For example, if the target store identifier exists in the store tag usage status set, the server can use Redis key query commands (such as SMEMBERS) to query the list of tags corresponding to the key (in the format "user_crowd_tags:app_id:user_id") of the user tag. For example, if the target store identifier is "app_123456" and the target user identifier is "user_789012", then the set with key "user_crowd_tags:app_123456:user_789012" can be queried to obtain the tag ID list ["110","112"].
[0085] S104, respond to the interactive activity participation request based on the retrieved user tags.
[0086] For example, the server can determine the response result of the interaction activity participation request based on the user's tags, and output the response result.
[0087] In some optional implementations, the participation permissions of the target viewing account for the interactive activity are determined based on the queried user tags and the participation rules of the interactive activity corresponding to the participation request; then, the response result for the interactive activity participation request is output according to the participation permissions.
[0088] The participation rules refer to the pre-set conditions for participating in the interactive activity, which can be based on user tags, such as "new users only," "high-spending users only," or "new users or users who have watched the broadcast for 3 consecutive days only." Participation permissions refer to whether the target viewing account meets the participation rules of the interactive activity, which can be divided into two states: "has participation permissions" and "does not have participation permissions." The response result refers to the processing result returned by the server to the viewing client, including a prompt that participation is allowed, prize distribution information, and a prompt indicating the reason for not having participation permissions, such as "You do not meet the conditions for new users and cannot participate in this activity."
[0089] For example, the retrieved user tags can be compared with the participation rules of the interactive activity to determine whether the user has the permission to participate, and then a response result, such as "no permission to participate", can be returned to the viewing end through the backend interface.
[0090] For example, suppose user A (user_789012) logs into a live streaming app on their mobile phone, enters the live stream room of store B (app_123456), and clicks the "Participate in Live Stream Task" button, triggering an interactive activity participation request. The server receives this request and extracts the target store identifier "app_123456" and the target user identifier "user_789012". First, it queries the Redis set with the key "app_is_use_tags_56" (the last two digits of store B's ID are 56), and finds that "app_123456" exists in this set, indicating that store B is a candidate store. Next, it queries the Redis set with the key "user_crowd_tags:app_123456:user_789012" to obtain the tag ID list ["110", "112"] (corresponding to the "new user" and "high-spending user" tags). The participation rule for this live streaming task is "new users can participate". User A's tag includes "new user", so the server returns a "allow participation in live streaming task" response to User A's mobile APP, and the APP displays the page for participating in the live streaming task.
[0091] In this way, users are accurately screened based on user tags and participation rules, ensuring that event benefits are distributed to the target users, improving event effectiveness and merchant marketing efficiency, and avoiding waste of benefits.
[0092] In the above embodiments, only the identifiers of candidate stores and the tag data of candidate users are cached in Redis, instead of the tag data of all stores and all users. This reduces the amount of data stored in Redis and meets storage requirements without upgrading Redis configuration. This satisfies the high-concurrency query requirements while reducing the amount of data stored in the cache database, thereby reducing the storage cost of the cache database. Furthermore, it prioritizes querying frequently accessed data from Redis, avoiding accessing the MySQL database storing the full data for every query. The response latency is controlled at the millisecond level, which can stably support the high-concurrency query requirements of 100,000 QPS and adapt to the high-concurrency characteristics of live streaming scenarios. In addition, by filtering by store identifier, subsequent user tag queries are only performed on stores that have used tags, reducing invalid query operations and improving query efficiency.
[0093] In some optional implementations, during the initialization of the cache database, a full scan of the tag usage records of each store can be performed to obtain candidate stores, and the store identifiers of the candidate stores can be written into the cache database.
[0094] The initialization of the cache database refers to the initialization operations performed when the cache database is deployed for the first time or when a full data update is required. This is achieved by executing a script, which can be a pre-written Python script used to scan all tag usage records and synchronize the data. Tag usage records are historical records of store tag usage stored in a MySQL database, including store ID, tag usage time, associated interaction activity type, etc. The table name can be set to db_tag.t_user_tag.
[0095] For example, a script can be executed to connect to a MySQL database, query all tag usage records in the `db_tag.t_user_tag` table, filter out stores with tag usage records as candidate stores, and then write the identifiers of the candidate stores into the corresponding Redis set "app_is_use_tags_xx" according to a key-based strategy. For instance, if the store "app_111222" is found to have tag usage records and its ID has the last two digits "22", then "app_111222" will be added to the set with the key "app_is_use_tags_22".
[0096] Alternatively, when an activity involving user tags is detected by an untagged store, or when a user tag is assigned to a user identifier associated with an untagged store, the store identifier of the untagged store can be written to the cache database. An untagged store is a store that has not used user tags before.
[0097] For example, by listening to tag-related operation events on the merchant's side, such as creating tag activities and assigning user tags, when a store without tags creates a live streaming task activity on the merchant's side and sets tag participation rules, or assigns tags to users entering its live streaming room, a data write operation is triggered, and the store's identifier is written to the "app_is_use_tags_xx" set in Redis according to the key-based strategy, while marking the store as a candidate store.
[0098] In the above embodiments, candidate store identifiers are fully synchronized during initialization to ensure that the cache database contains all stores that have historically used tags, thus guaranteeing query coverage. Furthermore, the tag usage behavior of stores without tags is dynamically monitored, and these stores are included in the candidate stores and written to the cache in real time to ensure the timeliness of cached data and avoid missing newly added stores using tags. In addition, only the identifiers of candidate stores are written, and the identifiers of stores without tags are not written, further reducing the storage pressure on Redis and improving the utilization of cache resources.
[0099] In some optional implementations, embodiments of this application may also include at least one of the following solutions:
[0100] During the initialization of the cache database, candidate user identifiers are determined, and the user tags corresponding to the candidate user identifiers are written into the cache database.
[0101] For example, a script can be executed to simultaneously synchronize candidate store identifiers and query the tag data of all users under the candidate store in MySQL to determine the candidate user identifier (i.e., the user identifier under the store). A key is then constructed in the format "user_crowd_tags:app_id:user_id", and the list of tag IDs is written to Redis. The cache expiration period can be set to 30 days. For instance, if the tag data of user "user_789012" under the candidate store "app_123456" in MySQL is ["110","112"], then a key "user_crowd_tags:app_123456:user_789012" is created in Redis with the value ["110","112"] and an expiration period of 30 days.
[0102] If a new viewing account is detected entering any candidate store's live stream room, the user tag corresponding to the new viewing account will be written to the cache database.
[0103] Among them, the new viewing account refers to the viewing account that enters any candidate store's live broadcast room for the first time, and the corresponding user identifier does not store tag data in Redis.
[0104] For example, a Kafka message queue can be used to listen for user entry events into a live stream. A Python script can consume this event, extract the user identifier and corresponding candidate store identifier of the new viewer account, query the user's tag data in MySQL, and write it to Redis according to the above key format, setting an expiration period of 30 days. If there is no tag data for the user in MySQL, an empty value is stored in Redis to avoid cache penetration. For example, when a new user "user_345678" enters the live stream of candidate store "app_654321", Kafka pushes this event. Script 2 queries MySQL and finds that there is no tag data for the user, so it creates the key "user_crowd_tags:app_654321:user_345678" in Redis, stores an empty value, and sets an expiration period of 30 days.
[0105] If a change in the user tag of any candidate user identifier is detected, the updated user tag will be written to the cache database.
[0106] Among them, changes in user tags refer to the addition, modification, or deletion of user tags. For example, a user changes from "new user" to "old user" (tag modification), a new tag "user who has watched the broadcast for 7 consecutive days" is added (tag addition), and a tag "user who has not consumed" is deleted (tag deletion). Change events are pushed through the Kafka message queue.
[0107] For example, user tag change events can be listened for through a Kafka message queue. A Python script can consume the event, extract the changed user identifier, store identifier, and updated tag data, and update the tag data in Redis according to the key format mentioned above, extending the validity period to 30 days. For instance, if user "user_789012" adds the tag "113" (a user who has watched the live stream for 3 consecutive days) to the store "app_123456", Kafka pushes a change event, script 3 updates the stored value of the key "user_crowd_tags:app_123456:user_789012" in Redis to ["110","112","113"], resetting the validity period to 30 days.
[0108] If the target store identifier of the target store is found in the cache database, but the user query index corresponding to the target user identifier is not found in the cache database, and the user tag corresponding to the target user identifier is found in the relational database, then the user tag found in the relational database will be written to the cache database.
[0109] The relational database can be a MySQL database, which stores all tag data (including manual and automatic tags), with the table name db_tag.t_user_tag, supporting CRUD operations on tag data and incremental synchronization.
[0110] For example, after a user triggers an interactive activity participation request, if the target store identifier exists in Redis but the corresponding user query index does not exist, the server queries the MySQL database. If the user's tag data exists in MySQL, the tag data is written to Redis according to the key format described above, with a validity period of 30 days. If the user's tag data also does not exist in MySQL, an empty value is stored in Redis. For instance, if user "user_901234" triggers a request to participate in a live stream task for store "app_123456", the identifier "app_123456" exists in Redis, but the key "user_crowd_tags:app_123456:user_901234" does not exist. Querying MySQL reveals that the user's tag is ["115"] (user not using live stream resources), so the tag data is written to Redis, a corresponding key is created, and a validity period of 30 days is set.
[0111] In the above embodiments, initialization synchronization, incremental synchronization, and passive caching are combined to ensure that user tag data in Redis is comprehensive and up-to-date, improve cache hit rate, reduce reliance on MySQL queries, and reduce the pressure on MySQL. Furthermore, data is synchronized in real time for new users and users with changed tags, ensuring that users can use the latest tag data in a timely manner when participating in interactive activities, thereby improving user experience.
[0112] In some alternative implementations, see [link to relevant documentation]. Figure 2 , Figure 2 A flowchart illustrating another request processing method is provided, which includes the following steps:
[0113] First, the tag service configuration for the B-end (merchant side):
[0114] B-end businesses create or edit live streaming services that use user tags. After completing the tag rule settings for these services, they enter the C-end business process.
[0115] Furthermore, the tag query process for the C-end (user end):
[0116] When a C-end user enters the live broadcast room, or when various business units need to verify user tags, the following steps are executed:
[0117] Prioritize querying the Redis cache. Redis is a high-performance caching database, and querying the cache first is to quickly retrieve data and reduce database pressure.
[0118] Two-step judgment logic:
[0119] First check: Does the user's key exist?
[0120] If "yes", directly read the user's tag data from Redis, and finally return the query result. The process ends at the end.
[0121] If "No", proceed to the second check to see if the store has used the label.
[0122] If "No", return "empty label data", and finally return the query results. The process ends at the end.
[0123] If "yes", query the full set of tag data from MySQL (this step is "passive caching"), synchronize the queried tag data to the Redis cache, and then return the query results. The process ends here.
[0124] Furthermore, the synchronization process of proactive caching:
[0125] To preload data into Redis (improving query efficiency on the client side), two proactive caching scenarios were set up, triggered by push events via Kafka (message queue).
[0126] Scenario 1: User enters the live stream room.
[0127] The user's entry into the live stream will trigger a Kafka push event, which will then trigger script 2 to consume the event, synchronize the user's tag data to Redis, and set the Redis cache validity period to 30 days to achieve proactive caching.
[0128] Scenario 2: User tag change event.
[0129] When a user's tag changes (e.g., from "new user" to "active user"), a Kafka push event is triggered to Script 1 to synchronize all tag data and the tags used by the store's live streaming business to Redis, set the cache validity period to 30 days, and mark the store as a "store that has used the tag" to achieve proactive caching.
[0130] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.
[0131] Based on the same inventive concept, this application also provides a request processing apparatus for implementing the request processing method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more request processing apparatus embodiments provided below can be found in the limitations of the request processing method described above, and will not be repeated here.
[0132] In one exemplary embodiment, such as Figure 3 As shown, a request processing apparatus is provided, which is applied to a server and includes:
[0133] The acquisition module 10 is used to acquire interactive activity participation requests from the viewing terminal. The interactive activity participation request is generated after the target viewing account corresponding to the viewing terminal enters the target store's live broadcast room. The interactive activity participation request includes the target store identifier of the target store and the target user identifier of the target viewing account.
[0134] The first query module 20 is used to query the target store identifier from the cache database; wherein, the cache database stores the store identifier of the candidate store and the user tag of the candidate user identifier; the candidate store is the store that has used the user tag, and the candidate user identifier is the user identifier of the viewing account that has entered the live broadcast room of the candidate store;
[0135] The second query module 30 is used to query the user tag corresponding to the target user identifier from the cache database when the target store identifier is found;
[0136] The response module 40 is used to respond to interactive activity participation requests based on the retrieved user tags.
[0137] The aforementioned request processing method, apparatus, computer equipment, and storage medium acquire interactive activity participation requests from the viewing client. These requests are generated when the target viewing account enters the target store's live stream room. The interactive activity participation request includes the target store identifier and the target user identifier of the target viewing account. The method retrieves the target store identifier from a cache database. The cache database stores store identifiers for candidate stores and user tags for candidate user identifiers. Candidate stores are stores that have used user tags, and candidate user identifiers are user identifiers of viewing accounts that have entered the candidate store's live stream room. If the target store identifier is found, the method retrieves the user tag corresponding to the target user identifier from the cache database. Based on the retrieved user tag, the method responds to the interactive activity participation request. This scheme stores only live stream-related user tag data in the cache database, which satisfies high-concurrency query requirements while reducing the amount of data stored in the cache database, thereby lowering the cache database storage cost.
[0138] In one embodiment, the first query module 20 is specifically used for:
[0139] Based on the target store identifier, construct a store query index; query the target store identifier from the identifier set corresponding to the store query index stored in the cache database.
[0140] In one embodiment, the first query module 20 is specifically used for:
[0141] Extract the target characters from the target store identifier; construct a store query index based on the target characters.
[0142] In one embodiment, the second query module 30 is specifically used for:
[0143] Based on the target user identifier and the target store identifier, a user query index is constructed; based on the user query index, the tag set corresponding to the user query index is retrieved from the cache database to obtain the user tags corresponding to the target user identifier.
[0144] In one embodiment, the device further includes a writing module for:
[0145] During the initialization of the cache database, a full scan of the tag usage records of each store is performed to obtain candidate stores, and the store identifiers of the candidate stores are written into the cache database; and / or, if it is detected that a store without tags has initiated an activity involving user tags, or if a user tag is assigned to a user identifier associated with a store without tags, the store identifier of the store without tags is written into the cache database; wherein, a store without tags is a store that has not used user tags.
[0146] In one embodiment, the writing module is further configured to:
[0147] During the initialization of the cache database, candidate user identifiers are determined, and the corresponding user tags are written to the cache database. If a new viewing account is detected entering any candidate store's live stream, the user tag corresponding to the new viewing account is written to the cache database. If the user tag for any candidate user identifier changes, the updated user tag is written to the cache database. If the target store identifier of the target store is found in the cache database, but the corresponding user query index is not found in the cache database, and the user tag corresponding to the target user identifier is found in the relational database, the user tag found in the relational database is written to the cache database.
[0148] In one embodiment, the response module 40 is specifically used for:
[0149] Based on the retrieved user tags and the participation rules of the interactive activity corresponding to the participation request, determine the participation permissions of the target viewing account for the interactive activity; based on the participation permissions, output the response result for the interactive activity participation request.
[0150] Each module in the aforementioned request processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can invoke and execute the operations corresponding to each module.
[0151] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores live-stream related data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When executed by the processor, the computer program implements a request processing method.
[0152] Those skilled in the art will understand that Figure 4The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0153] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the request processing method described in any of the above embodiments.
[0154] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the request processing method described in any of the above embodiments.
[0155] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the request processing method described in any of the above embodiments.
[0156] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.
[0157] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.
[0158] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.
[0159] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.
Claims
1. A request processing method, characterized in that, Applied to a server, the method includes: Obtain the interactive activity participation request from the viewing terminal; the interactive activity participation request is generated after the target viewing account corresponding to the viewing terminal enters the target store's live broadcast room, and the interactive activity participation request includes the target store identifier of the target store and the target user identifier of the target viewing account; The target store identifier is retrieved from the cache database; wherein, the cache database stores the store identifier of the candidate store and the user tag of the candidate user identifier; the candidate store is the store that has used the user tag, and the candidate user identifier is the user identifier of the viewing account that has entered the live broadcast room of the candidate store; If the target store identifier is found, the user tag corresponding to the target user identifier is retrieved from the cache database; The system responds to user participation requests based on the retrieved user tags.
2. The method according to claim 1, characterized in that, The step of querying the target store identifier from the cache database includes: Based on the target store identifier, construct a store query index; The target store identifier is retrieved from the identifier set corresponding to the store query index stored in the cache database.
3. The method according to claim 2, characterized in that, The step of constructing a store query index based on the target store identifier includes: Extract the target characters from the target store identifier; Based on the target characters, construct a store query index.
4. The method according to claim 1, characterized in that, Retrieve the user tag corresponding to the target user identifier from the cache database, including: Construct a user query index based on the target user identifier and the target store identifier; Based on the user query index, the tag set corresponding to the user query index is queried from the cache database to obtain the user tag corresponding to the target user identifier.
5. The method according to claim 1, characterized in that, The method further includes: During the initialization of the cache database, a full scan of the tag usage records of each store is performed to obtain candidate stores, and the store identifiers of the candidate stores are written into the cache database; and / or, If an activity involving user tags is detected by an unlabeled store, or if a user tag is assigned to a user identifier associated with the unlabeled store, the store identifier of the unlabeled store is written to the cache database; wherein, the unlabeled store is a store that has not used user tags.
6. The method according to claim 1, characterized in that, The method further includes at least one of the following: During the initialization of the cache database, candidate user identifiers are determined, and user tags corresponding to the candidate user identifiers are written into the cache database; If a new viewing account is detected entering any candidate store's live stream, the user tag corresponding to the new viewing account is written into the cache database; If a change in the user tag of any candidate user identifier is detected, the updated user tag will be written to the cache database; If the target store identifier of the target store is found in the cache database, but the user query index corresponding to the target user identifier is not found in the cache database, and the user tag corresponding to the target user identifier is found in the relational database, then the user tag found in the relational database will be written into the cache database.
7. The method according to any one of claims 1 to 6, characterized in that, The step of responding to the interactive activity participation request based on the retrieved user tags includes: Based on the retrieved user tags and the participation rules of the interactive activity corresponding to the interactive activity participation request, the participation permissions of the target viewing account for the interactive activity are determined. Based on the participation permissions, output the response result for the participation request in the interactive activity.
8. A request processing apparatus, characterized in that, The device is used in a server, and the device includes: The acquisition module is used to acquire interactive activity participation requests from the viewing terminal; the interactive activity participation request is generated after the target viewing account corresponding to the viewing terminal enters the target store's live broadcast room, and the interactive activity participation request includes the target store identifier of the target store and the target user identifier of the target viewing account; The first query module is used to query the target store identifier from the cache database; wherein, the cache database stores the store identifier of the candidate store and the user tag of the candidate user identifier; the candidate store is the store that has used the user tag, and the candidate user identifier is the user identifier of the viewing account that has entered the live broadcast room of the candidate store; The second query module is used to query the user tag corresponding to the target user identifier from the cache database when the target store identifier is found; The response module is used to respond to the interactive activity participation request based on the retrieved user tags.
9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.