Member benefit data query method and device, storage medium and electronic equipment

Abstract

The application relates to a member benefit data query method and device, a storage medium and electronic equipment. The method comprises the following steps: when a member benefit query request is received, a Bloom filter is called to perform existence judgment on a target member benefit identifier in the member benefit query request; in the case that the target member benefit identifier does not exist in a member benefit identifier set as judged by the Bloom filter, a benefit invalid result is directly returned; in the case that the target member benefit identifier may exist in the member benefit identifier set as judged by the Bloom filter, the target member benefit identifier is sequentially queried in a cache layer and a database to obtain corresponding member benefit data and return the data; in the case that the target member benefit identifier is not queried in the cache layer and the database, a benefit invalid result is returned, and a null value of the target member benefit identifier is written in the cache layer and an effective period is set. The application solves the technical problem that the prior art lacks an efficient existence prediction mechanism.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a method, apparatus, storage medium, and electronic device for querying membership rights data. Background Technology

[0002] With the widespread adoption of internet membership systems, membership benefits, as fundamental business data supporting the operation of membership systems, are extensively used in core business processes such as eligibility verification, benefit redemption, order discounts, and content access control. In actual operation, business systems typically need to determine the existence and validity of corresponding benefits based on the benefit identifier (benefit ID) carried in the request, thereby deciding the execution of subsequent business logic.

[0003] With the continuous expansion of business scale and the evolution of system architecture towards microservices and cloud-native architecture, membership benefits query interfaces are often deployed in multi-instance environments and subjected to high concurrency access pressure. In this scenario, the number and frequency of benefits query requests increase significantly, placing higher demands on the stability and performance of the backend storage system.

[0004] In existing technologies, membership benefits queries typically employ a two-tier access architecture of "caching + database." The typical processing flow is as follows: first, benefits data is retrieved from a caching system such as Redis; if the cache misses, the benefits information is obtained from a relational database such as MySQL, and the query results are written back to the cache. This technical solution effectively reduces database access pressure and improves overall system performance when processing legitimate and existing benefits requests.

[0005] However, in actual business operations, the above solutions reveal significant shortcomings when the stake ID carried in the request does not exist or is invalid. Specifically, for stake IDs that do not exist in either the cache or the database, the request will directly penetrate the cache and access the database, resulting in a cache penetration problem. In high-concurrency or malicious request scenarios, attackers can construct a large number of random or invalid stake IDs to continuously trigger database queries, leading to a surge in the number of database connections and affecting system stability. Even if some systems employ protective measures such as null value caching, it is still difficult to fundamentally suppress the impact of invalid requests on the database when the stake ID space is large or the scale of invalid requests is high.

[0006] In summary, the fundamental flaw of existing membership benefits query solutions lies in the lack of a low-cost, high-efficiency existence prediction mechanism before accessing the cache and database. This mechanism would filter out obviously non-existent benefit requests in advance, thereby effectively reducing the pressure on the backend storage system caused by invalid requests. Summary of the Invention

[0007] This application provides a method, apparatus, storage medium, and electronic device for querying membership rights data, in order to solve the technical problem that the prior art lacks an efficient existence prediction mechanism.

[0008] Firstly, this application provides a method for querying membership benefits data, comprising: upon receiving a membership benefits query request, calling a Bloom filter to determine the existence of a target membership benefits identifier in the query request, wherein the Bloom filter stores a set of currently valid membership benefits identifiers in the database; if the Bloom filter determines that the target membership benefits identifier does not exist in the set of membership benefits identifiers, directly returning an invalid benefit result; if the Bloom filter determines that the target membership benefits identifier may exist in the set of membership benefits identifiers, sequentially querying the target membership benefits identifier in the cache layer and the database to obtain and return the corresponding membership benefits data; if the target membership benefits identifier is not found in either the cache layer or the database, returning an invalid benefit result, and writing a null value for the target membership benefits identifier and setting an expiration period in the cache layer so that the target membership benefits identifier is not triggered to access the database again within the expiration period.

[0009] Secondly, this application provides a device for querying membership benefits data, comprising: a judgment module, configured to, upon receiving a membership benefits query request, invoke a Bloom filter to determine the existence of a target membership benefits identifier in the query request, wherein the Bloom filter stores a set of currently valid membership benefits identifiers in a database; a first return module, configured to, if the Bloom filter determines that the target membership benefits identifier does not exist in the set of membership benefits identifiers, directly return an invalid benefit result; a query module, configured to, if the Bloom filter determines that the target membership benefits identifier may exist in the set of membership benefits identifiers, sequentially query the target membership benefits identifier in a cache layer and the database to obtain the corresponding membership benefits data and return it; and a second return module, configured to, if the target membership benefits identifier is not found in either the cache layer or the database, return an invalid benefit result, and write a null value for the target membership benefits identifier and set an expiration period in the cache layer, so that the target membership benefits identifier is not triggered to access the database again within the expiration period.

[0010] As an optional example, the above apparatus further includes: an acquisition module, configured to acquire a set of currently valid member benefit identifiers from the database before receiving a member benefit query request, during system startup or restart; an initialization module, configured to initialize the Bloom filter based on the set of member benefit identifiers, so as to batch write the set of member benefit identifiers into the Bloom filter through the batch write interface of the Bloom filter; and a first setting module, configured to set the estimated capacity and target false positive rate for the Bloom filter.

[0011] As an optional example, the above initialization module includes: a management unit, used to create, configure parameters, and write data to the Bloom filter through the Bloom filter management interface provided by the distributed cache client, wherein the Bloom filter management interface is used to encapsulate the initialization, existence judgment, and data maintenance logic of the Bloom filter.

[0012] As an optional example, the above query module includes: a first query unit, used to query the target member benefit identifier in the cache layer; a first return unit, used to obtain and return the corresponding member benefit data if the target member benefit identifier is found in the cache layer; a second query unit, used to query the target member benefit identifier in the database if the target member benefit identifier is not found in the cache layer; and a second return unit, used to obtain and return the corresponding member benefit data if the target member benefit identifier is found in the database.

[0013] As an optional example, the above apparatus further includes: a new addition module, used to write the corresponding new member benefit identifier into the database when new or activated new member benefit data is detected, and to simultaneously write the new member benefit identifier into the Bloom filter; and a first update module, used to update the cache layer according to the new member benefit data.

[0014] As an optional example, the above apparatus further includes: a second update module, configured to update the set of member benefits identifiers in the Bloom filter by periodically rebuilding or reinitializing the Bloom filter when any member benefits data in the database is detected to have been updated or invalidated.

[0015] As an optional example, the above device further includes: a second setting module, used to uniformly encapsulate the cache read and write logic of member rights data through a cache access abstraction framework, so as to complete the access to the above cache layer through a unified cache access interface.

[0016] Thirdly, this application provides a storage medium storing a computer program, wherein the computer program is executed by a processor to perform the aforementioned method for querying membership rights data.

[0017] Fourthly, this application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the above-mentioned method for querying membership rights data through the computer program.

[0018] The technical solutions provided in this application have the following advantages compared with the prior art: This application employs a method where, upon receiving a membership benefits query request, a Bloom filter is invoked to determine the existence of the target membership benefits identifier in the query request. The Bloom filter stores a set of currently valid membership benefits identifiers in the database. If the Bloom filter determines that the target membership benefits identifier does not exist in the set of membership benefits identifiers, an invalid benefit result is directly returned. If the Bloom filter determines that the target membership benefits identifier may exist in the set of membership benefits identifiers, the target membership benefits identifier is queried sequentially in the cache layer and the database to obtain the corresponding membership benefits data and return it. If the target member benefit identifier is not found in the database, an invalid benefit result is returned. A null value for the target member benefit identifier and an expiration date are written to the cache layer to prevent the target member benefit identifier from being accessed again within the expiration period. This method utilizes a Bloom filter introduced before the member benefit query process to quickly determine the existence of the member benefit identifier in the request, filtering out obviously non-existent invalid benefit requests before accessing the cache layer and database. If the Bloom filter determines that an invalid benefit might exist, a tiered query is performed in conjunction with the cache layer and database, and null value caching and expiration date control mechanisms are used for data that cannot be found. This achieves efficient interception of invalid benefit requests, significantly reduces cache penetration and database access pressure, improves the stability of the member benefit query interface in high-concurrency scenarios and the overall system performance, and solves the technical problem of existing technologies lacking an efficient existence prediction mechanism. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0022] Figure 1 This is a flowchart of an optional method for querying membership rights data according to an embodiment of this application; Figure 2 This is a system structure diagram of an optional method for querying membership rights data according to an embodiment of this application; Figure 3 This is a flowchart illustrating the specific implementation of an optional method for querying membership rights data according to an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an optional membership rights data query device according to an embodiment of this application; Figure 5 This is a schematic diagram of an optional electronic device according to an embodiment of this application. Detailed Implementation

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

[0024] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0025] According to a first aspect of the embodiments of this application, a method for querying membership rights data is provided, optionally, as follows: Figure 1 As shown, the above method includes: S102, When a member benefits query request is received, the Bloom filter is called to determine the existence of the target member benefits identifier in the member benefits query request. The Bloom filter stores the set of currently valid member benefits identifiers in the database. S104: If the target member's benefit identifier is not found in the set of member benefit identifiers through the Bloom filter, the result of invalid benefit is returned directly. S106, if the target member benefit identifier may exist in the set of member benefit identifiers by using a Bloom filter, query the target member benefit identifier in the cache layer and the database in turn to obtain the corresponding member benefit data and return it; S108: If the target member's benefit identifier is not found in either the cache layer or the database, return an invalid benefit result, and write a null value for the target member's benefit identifier and set an expiration period in the cache layer so that the target member's benefit identifier will not be triggered to access the database again within the expiration period.

[0026] Optionally, in this embodiment, a method for querying membership rights data is proposed, which is applicable to Internet systems where membership-based businesses are widely used. This method is used to efficiently and stably complete the validity judgment of membership rights and data acquisition in high-concurrency access scenarios, avoiding unnecessary pressure on the caching system and backend database caused by invalid requests.

[0027] like Figure 2The system architecture diagram shown illustrates a system comprised of a client, a membership benefits service (Spring Boot), a Bloom filter (RedisBloom), a Redis cache, and a MySQL database. The client initiates a membership benefits query request to the membership benefits service over the network. The membership benefits service, implemented using the Spring Boot framework, is used to uniformly receive and process query requests from clients. Upon receiving a query request, the membership benefits service first invokes the Bloom filter (RedisBloom) deployed in the distributed cache system to perform an existence check on the membership benefits identifier carried in the request, quickly determining whether the identifier belongs to the current set of valid benefits. If the Bloom filter returns no result, the membership benefits service directly returns an invalid benefit response to the client; if the Bloom filter returns a possible result, it continues to initiate a query request to the Redis cache. The Redis cache stores frequently accessed membership benefits data and null flags. If the cache is hit, the corresponding membership benefits data is returned directly; if the cache is not hit, the membership benefits service further accesses the backend MySQL database to retrieve the membership benefits data. The MySQL database serves as persistent storage for member benefits data and is used to return the final query results. When the target member benefit identifier is not found in the database, the member benefits service writes a corresponding null value to the Redis cache and sets an expiration date, thereby preventing the same invalid benefit request from repeatedly triggering database access within the expiration period. Through the above system architecture, layered processing and efficient protection of member benefit query requests are achieved.

[0028] It's important to note that a Bloom filter is a space-efficient probabilistic data structure based on a bit array and multiple hash functions. When a membership benefit identifier is added, multiple independent hash functions calculate multiple bit positions, and these positions are set to 1. When querying whether an element exists, these hash positions are calculated again. If all bits are 1, it returns "possibly exists"; if any bit is 0, it is 100% certain that the element is not in the set. This design achieves fast existence prediction with minimal memory overhead, but sacrifices absolute accuracy, allowing for a certain probability of false positives. The "possibly exists" result stems from the inevitability of hash collisions: different elements may be mapped to the same bits by the hash function, causing all the check bits of an element that has never been stored to be "accidentally" set to 1 by other elements, thus being falsely judged as existing. Therefore, a Bloom filter cannot guarantee the absolute truth of "existence," but can only provide a probabilistic conclusion. In the system process, when a "may exist" message is received, it means that the request has passed the initial screening, but it must continue to be verified in the cache or database for secondary verification to finally confirm whether the rights are real and valid. This ensures that valid requests are not mistakenly rejected while effectively protecting invalid requests.

[0029] In specific implementations, such as Figure 3 The flowchart shown illustrates the specific implementation process. When the system receives a membership benefits query request, the request typically carries a target membership benefit identifier to identify the member's benefits. To quickly filter this target membership benefit identifier before accessing the cache layer and database, a Bloom filter is introduced as an existence prediction component in the pre-stage of the query process. The Bloom filter pre-stores a set of currently valid membership benefit identifiers loaded from the database, representing the range of configured and usable benefit identifiers in the system.

[0030] Upon receiving a membership benefits query request, the system first invokes a Bloom filter to check the existence of the target membership benefit identifier. If the Bloom filter determines that the target membership benefit identifier does not exist in the set of membership benefit identifiers, the system can determine that the benefit identifier is invalid. The system then does not need to access the cache layer or database and directly returns the query result indicating invalid benefits to the requester, thus intercepting obviously non-existent invalid requests at the very beginning of the request chain.

[0031] If the Bloom filter determines that the target membership benefit identifier may exist in the set of membership benefit identifiers, it means that the identifier has a certain probability of existence in the system. At this point, the system enters the normal data query process, sequentially querying the target membership benefit identifier in the cache layer and the database. Preferably, the cache layer can use a distributed caching system to store hot information about membership benefit data, thereby reducing the frequency of database access. When the corresponding membership benefit data is found in the cache layer, the system directly returns the data, completing the query.

[0032] When the cache layer does not find the target membership benefit identifier, the system further accesses the database for querying. If the database contains membership benefit data corresponding to the target membership benefit identifier, the query result is returned to the requester, and the membership benefit data can be written to the cache layer according to the caching strategy for reuse in subsequent requests.

[0033] If no membership benefit data corresponding to the target membership benefit identifier is found in either the cache layer or the database, the system determines that the target membership benefit identifier is invalid under the current business status and returns an invalid benefit result. Simultaneously, to prevent the same invalid benefit identifier from being frequently queried within a short period and triggering further cache and database accesses, a null value corresponding to the target membership benefit identifier is written to the cache layer, and a preset validity period is set for this null value. Within the validity period, subsequent query requests for the same target membership benefit identifier can directly hit the null value result in the cache, thereby avoiding repeated cache-penetrating database accesses.

[0034] Optionally, this embodiment constructs a multi-layer protection mechanism of "Bloom filter prediction + cache layer interception + database storage" in the member rights query process, enabling the system to efficiently filter a large number of non-existent or illegal rights identifier requests with low computational and storage costs.

[0035] By introducing a Bloom filter at the beginning of the query process, the existence of member benefit identifiers can be quickly determined, effectively reducing invalid requests accessing the cache and database. Combined with a null value caching mechanism, the cache penetration problem is further suppressed, significantly reducing the database load in high-concurrency and malicious request scenarios. At the same time, this method has low intrusion into existing business query logic, is easy to deploy and implement in distributed and microservice architectures, and has good engineering feasibility and promotion value.

[0036] As an optional example, the above method may also include the following before receiving a membership benefits query request: When the system starts up or restarts, retrieve the set of currently valid member benefit identifiers from the database; A Bloom filter is initialized based on a set of member benefit identifiers, so that the set of member benefit identifiers can be written into the Bloom filter in batches through the batch write interface of the Bloom filter. Set the estimated capacity and target false positive rate for the Bloom filter.

[0037] Optionally, in this embodiment, before receiving a membership benefits query request, an initialization and configuration process for the Bloom filter is included to ensure a stable and reliable existence prediction capability in subsequent query stages. Specifically, when the system starts up or restarts, the membership benefits service first establishes a connection with the database, queries the MySQL database, and retrieves the set of all currently valid membership benefits identifiers. The set of membership benefits identifiers is used to fully reflect the range of membership benefits data that actually exist and can be used normally in the system, avoiding the inclusion of expired or ineffective benefits in subsequent judgment logic.

[0038] After obtaining the set of member benefit identifiers, the system initializes the Bloom filter based on this set. Specifically, through the batch write interface provided by the Bloom filter, such as using the "BF.MADD" command of the RedisBloom module, the set of member benefit identifiers is written into the Bloom filter all at once, so as to build the corresponding bit array and multi-hash mapping structure inside the Bloom filter. Compared with the write-by-write method, the batch write mechanism can significantly reduce the number of network interactions and system overhead during the initialization process, and improve the overall efficiency of the system startup or restart phase.

[0039] Simultaneously, during the initialization of the Bloom filter, the system also uniformly configures key operating parameters of the Bloom filter. This includes setting the estimated capacity of the Bloom filter based on business scale, such as estimating it can handle one million membership benefit records; and setting the target false positive rate, such as one in ten thousand, based on the system's accuracy requirements. By reasonably configuring these parameters, the Bloom filter achieves a balance between memory usage, query performance, and false positive probability, ensuring fast judgment capabilities in high-concurrency scenarios while avoiding the impact of an excessively high false positive rate on the accuracy of subsequent caching and database queries.

[0040] As an optional example, initializing a Bloom filter based on a set of membership benefit identifiers includes: The distributed caching client provides a Bloom filter management interface for creating, configuring, and writing data to Bloom filters. The Bloom filter management interface encapsulates the logic for initializing, determining the existence of, and maintaining Bloom filters.

[0041] Optionally, in this embodiment, the process of initializing the Bloom filter based on the set of member rights identifiers can be implemented through the Bloom filter management interface (RBloomFilter interface) provided by the distributed cache client, so as to reduce the system's direct dependence on the underlying cache commands and improve the maintainability and stability of the system.

[0042] Specifically, in a Java application environment, the membership benefits service introduces a distributed caching client component, which calls its unified management interface for Bloom filters to perform operations such as creating, configuring parameters, and writing data to Bloom filters. The Bloom filter management interface encapsulates the implementation details of the underlying Bloom filters, allowing business systems to initialize and use Bloom filters without directly calling the native commands provided by the underlying caching system, thereby effectively reducing the coupling between business code and the underlying caching implementation.

[0043] During the Bloom filter creation phase, the system, through the Bloom filter management interface, calculates and initializes the size of the internal bit array and the number of hash functions of the Bloom filter based on pre-set estimated capacity and target false positive rate parameters. This ensures that the Bloom filter can meet the query performance and judgment accuracy requirements under the current scale of member benefit data. During the data writing phase, the system, based on the set of member benefit identifiers obtained from the database, writes each member benefit identifier into the Bloom filter through the management interface to construct the corresponding existence judgment structure.

[0044] Furthermore, during the membership benefits query process, the Bloom filter management interface also provides a unified existence determination method, enabling membership benefits services to call the Bloom filter in a standardized manner to complete the "whether it is possible to exist" judgment operation. Simultaneously, in scenarios such as adding, updating, or invalidating membership benefits, the management interface can also be used to maintain the data in the Bloom filter or update it through reconstruction, thereby ensuring that the set of membership benefit identifiers in the Bloom filter remains consistent with the actual valid data in the database.

[0045] By encapsulating the initialization, existence judgment, and data maintenance logic of the Bloom filter in the management interface provided by the distributed cache client, the complexity and risks of business systems directly operating the underlying commands are not only avoided, but also the scalability and maintainability of the system are improved, making it easier to adapt smoothly when different deployment environments or underlying cache implementations change.

[0046] As an optional example, the target membership benefit identifier is queried sequentially in the cache layer and the database to obtain the corresponding membership benefit data and return it, including: Query the target member's benefits identifier in the cache layer; If the target member benefit identifier is found in the cache layer, the corresponding member benefit data is retrieved and returned. If the target member benefit identifier is not found in the cache layer, the target member benefit identifier is queried in the database. If the target member benefit identifier is found in the database, the corresponding member benefit data is retrieved and returned.

[0047] Optionally, in this embodiment, if the target member benefit identifier is determined to exist by using a Bloom filter, the above-mentioned member benefit data query method further adopts a hierarchical query mechanism, sequentially querying the target member benefit identifier in the cache layer and the database to obtain the corresponding member benefit data and return it, thereby ensuring the accuracy of the query while taking into account system performance and stability.

[0048] Specifically, upon receiving a membership benefits query request and receiving a "may exist" result from the Bloom filter, the membership benefits service first initiates a query request to the cache layer to check if membership benefits data corresponding to the target membership benefits identifier is already stored in the cache layer. The cache layer can employ an in-memory or distributed caching system to store frequently accessed membership benefits data, thereby reducing direct access to the backend database. When the target membership benefits identifier is successfully found in the cache layer, the system directly retrieves the corresponding membership benefits data from the cache layer and returns it to the caller, thus avoiding subsequent database access and significantly reducing overall query latency and system resource consumption.

[0049] If the target membership benefit identifier is not found in the cache layer, the membership benefit service further initiates a query request to the database to retrieve the membership benefit data corresponding to the target membership benefit identifier. The database is used to store a complete and authoritative set of membership benefit data and is the final data source. When the target membership benefit identifier is found in the database, the system retrieves the corresponding membership benefit data and writes the membership benefit data to the cache layer while returning the query results, so that subsequent identical or similar query requests can directly hit the cache, thereby improving overall query efficiency.

[0050] By sequentially querying the cache layer and the database as described above, the membership benefits query process prioritizes leveraging the high performance of the cache layer to handle most requests, only accessing the database when a cache miss occurs, effectively reducing database access pressure. Simultaneously, this tiered query mechanism, combined with the pre-emptive Bloom filter existence check, further reduces invalid requests and duplicate queries in high-concurrency scenarios, improving the response speed of the membership benefits query service and the overall system stability.

[0051] As an optional example, the above method also includes: When new or activated member benefits data is detected, the corresponding new member benefits identifier is written to the database, and the new member benefits identifier is simultaneously written to the Bloom filter. Update the cache layer based on new member benefits data.

[0052] Optionally, this embodiment includes a membership benefit addition and update process, which is used to ensure data consistency between the Bloom filter, cache layer and database when introducing new membership benefits into the system or activating existing but inactive membership benefits, thereby ensuring the accuracy and timeliness of subsequent membership benefit query results.

[0053] Specifically, during system operation, when newly added membership benefit data is detected, or when existing membership benefits change from inactive to active, the membership benefits service first writes the new membership benefit data into the database. The database, as the final storage medium for membership benefit data, is used to persistently store the complete information of the new membership benefits and their corresponding membership benefit identifiers, ensuring that newly added or activated benefits can be reliably managed and accessed by the system for a long period.

[0054] After completing the database write operation, the system synchronously writes the membership benefit identifier corresponding to the new membership benefit into the Bloom filter. This synchronous write operation enables the Bloom filter to promptly detect newly added or activated membership benefit identifiers, preventing subsequent queries from misjudging legitimate benefit requests as non-existent due to the Bloom filter not being updated. This ensures the accuracy and real-time nature of the existence determination results.

[0055] In addition, the system updates the cache layer accordingly based on new member benefits data. For example, after adding or activating benefits, the corresponding member benefits data can be directly written to the cache layer, or the cache can be updated by writing back to the cache from the database during the first query. By updating the cache layer in a timely manner, new member benefits can be quickly cached, reducing the need for subsequent query requests to directly access the database and improving overall query performance.

[0056] Through the aforementioned mechanism for adding and updating membership benefits, collaborative updates between the database, Bloom filter, and cache layer are achieved, ensuring that the system can still stably and accurately provide membership benefit query services to external parties even in dynamically changing membership benefit scenarios.

[0057] As an optional example, the above method also includes: If any member benefit data in the database is detected to have been updated or become invalid, the set of member benefit identifiers in the Bloom filter is updated by periodically rebuilding or reinitializing the Bloom filter.

[0058] Optionally, this embodiment includes a Bloom filter maintenance mechanism for scenarios where member rights data is updated or expired. This mechanism ensures the consistency between the set of member rights identifiers in the Bloom filter and the actual valid data in the database, even if the Bloom filter does not support single-item deletion operations, thereby maintaining the reliability of the existence judgment result.

[0059] Specifically, during system operation, when any member benefit data in the database is detected to have been updated, expired, or logically deleted, the member benefit service will not directly delete the corresponding member benefit identifier in the Bloom filter. Instead, it will periodically rebuild or reinitialize the Bloom filter to update the entire set of member benefit identifiers maintained in the Bloom filter. Detection can be achieved through scheduled tasks, data change event listening, or version number comparison to ensure timely awareness of changes in benefit data.

[0060] When rebuilding or reinitializing a Bloom filter, the system retrieves a new set of currently valid member benefit identifiers from the database and reconstructs the internal data structure of the Bloom filter based on this set, including bit arrays and hash mappings. This method naturally excludes expired or outdated member benefit identifiers from the new Bloom filter, thus avoiding the problem of a gradual increase in false positive rates due to the long-term accumulation of historical data.

[0061] Meanwhile, during the reconstruction process, the system can retain existing estimated capacity and target false positive rate parameters, or dynamically adjust the parameters based on the current scale of membership benefit data and business access characteristics, in order to maintain a reasonable balance between memory usage, query performance, and judgment accuracy. After reconstruction, the system will replace the original Bloom filter with a new one, ensuring that subsequent membership benefit query requests are all based on the updated set of membership benefit identifiers for existence determination.

[0062] Through the aforementioned periodic reconstruction or re-initialization mechanism, the data consistency problem caused by the inability to delete elements by the Bloom filter is effectively solved without increasing the overhead of a single query. This ensures that the membership rights query process can maintain a stable and accurate protection effect even in long-term operation and frequent data changes.

[0063] As an optional example, the above method also includes: The cache access abstraction framework encapsulates the cache read and write logic of member rights data in a unified manner, so as to complete the access to the cache layer through a unified cache access interface.

[0064] Optionally, this embodiment includes a unified abstraction and encapsulation mechanism for cache access logic to reduce the dependence of business code on specific cache implementations and improve the scalability, maintainability and overall architecture stability of the system.

[0065] Specifically, the system introduces a cache access abstraction framework (Spring Cache framework) to uniformly encapsulate the read and write operations of member benefits data in the cache layer, centrally managing common logic such as cache retrieval, writing, updating, and invalidation handling. The cache access abstraction framework provides a unified cache access interface, allowing the member benefits service to access the cache layer only through this unified interface when executing business logic, without needing to concern itself with the specific type, deployment method, or access protocol of the underlying cache system.

[0066] Under this abstraction mechanism, different types of cache implementations (such as local caches or distributed caches) can be connected to the cache access abstraction framework via adapters, ensuring that cache components can be replaced or extended without modifying business code. Simultaneously, the cache access abstraction framework can centrally handle common cache-related strategies, such as cache hit and miss handling logic, null value cache writing and expiration control, and fault tolerance handling in abnormal scenarios, thereby avoiding the duplication of the same cache control logic in business code.

[0067] Furthermore, through a unified cache access interface, the system can more easily work in conjunction with the aforementioned Bloom filter existence judgment mechanism and database access logic to form a clearly structured and separated membership rights query process.

[0068] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0069] According to another aspect of the embodiments of this application, a device for querying membership rights data is also provided, such as... Figure 4 As shown, it includes: The judgment module 402 is used to call the Bloom filter to determine the existence of the target member benefit identifier in the member benefit query request when a member benefit query request is received. The Bloom filter stores the set of currently valid member benefit identifiers in the database. The first return module 404 is used to directly return an invalid benefit result if the target member benefit identifier is not found in the set of member benefit identifiers determined by the Bloom filter. Query module 406 is used to query the target member benefit identifier in the cache layer and the database in turn when it is determined by the Bloom filter that the target member benefit identifier may exist in the set of member benefit identifiers, so as to obtain the corresponding member benefit data and return it. The second return module 408 is used to return an invalid benefit result when the target member benefit identifier is not found in either the cache layer or the database, and to write an empty value of the target member benefit identifier and set an expiration period in the cache layer so that the target member benefit identifier will not be triggered to access the database again within the expiration period.

[0070] It should be noted that the judgment module 402 in this embodiment can be used to execute step S102 in this application embodiment, the first calculation module 204 in this embodiment can be used to execute step S104 in this application embodiment, the query module 406 in this embodiment can be used to execute step S106 in this application embodiment, and the second return module 408 in this embodiment can be used to execute step S108 in this application embodiment.

[0071] As an optional example, the above-described apparatus further includes: The acquisition module is used to retrieve the set of currently valid member benefits identifiers from the database before the system starts or restarts, before receiving a member benefits query request. The initialization module is used to initialize a Bloom filter based on a set of member benefit identifiers, so that the set of member benefit identifiers can be written into the Bloom filter in batches through the batch write interface of the Bloom filter. The first setting module is used to set the estimated capacity and target false positive rate for the Bloom filter.

[0072] As an optional example, the initialization module includes: The management unit is used to create, configure parameters, and write data to Bloom filters through the Bloom filter management interface provided by the distributed cache client. The Bloom filter management interface is used to encapsulate the logic for initializing, determining the existence of, and maintaining Bloom filters.

[0073] As an optional example, the query module includes: The first query unit is used to query the target member's rights identifier in the cache layer; The first return unit is used to retrieve and return the corresponding membership benefits data when the target membership benefit identifier is found in the cache layer. The second query unit is used to query the target member benefit identifier in the database when the target member benefit identifier is not found in the cache layer. The second return unit is used to retrieve and return the corresponding membership benefits data when the target membership benefit identifier is found in the database.

[0074] As an optional example, the above-described apparatus further includes: A new module is added to write the corresponding new member benefit identifier to the database when new or activated member benefit data is detected, and simultaneously write the new member benefit identifier to the Bloom filter. The first update module is used to update the cache layer based on new member benefits data.

[0075] As an optional example, the above-described apparatus further includes: The second update module is used to update the set of member benefit identifiers in the Bloom filter by periodically rebuilding or reinitializing the Bloom filter when any member benefit data in the database is detected to have been updated or become invalid.

[0076] As an optional example, the above-described apparatus further includes: The second settings module is used to uniformly encapsulate the cache read and write logic of member rights data through the cache access abstract framework, so as to complete the access to the cache layer through a unified cache access interface.

[0077] For other examples of this embodiment, please refer to the examples above, which will not be repeated here.

[0078] Figure 5 This is a schematic diagram of an optional electronic device according to an embodiment of this application, such as... Figure 5As shown, it includes a processor 502, a communication interface 504, a memory 506, and a communication bus 508. The processor 502, communication interface 504, and memory 506 communicate with each other via the communication bus 508. Memory 506 is used to store computer programs; When processor 502 executes a computer program stored in memory 506, it performs the following steps: When a membership benefits query request is received, a Bloom filter is invoked to determine the existence of the target membership benefits identifier in the query request. The Bloom filter stores the set of currently valid membership benefits identifiers in the database. If the Bloom filter determines that the target member's benefit identifier does not exist in the set of member benefit identifiers, it directly returns an invalid benefit result. If the target member benefit identifier is determined to exist in the set of member benefit identifiers by using a Bloom filter, the target member benefit identifier is queried in the cache layer and the database in turn to obtain the corresponding member benefit data and return it. If the target member's benefit identifier is not found in either the cache layer or the database, an invalid benefit result is returned. An empty value for the target member's benefit identifier is written to the cache layer, and an expiration period is set so that the target member's benefit identifier is not triggered to access the database again within the expiration period.

[0079] Optionally, in this embodiment, the communication bus can be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. This communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 5 The symbol is represented by a single thick line, but this does not indicate that there is only one bus or one type of bus. The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0080] The memory may include RAM, or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0081] As an example, the memory 506 described above may include, but is not limited to, the judgment module 402, the first return module 404, the query module 406, and the second return module 408 from the membership rights data query device. Furthermore, it may include, but is not limited to, other module units from the membership rights data query device, which will not be elaborated upon in this example.

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

[0083] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments, and will not be repeated here.

[0084] Those skilled in the art will understand that Figure 5 The structure shown is for illustrative purposes only. The device used to implement the above method for querying membership rights data can be a terminal device, such as a smartphone (e.g., Android phone, iOS phone), tablet computer, PDA, mobile Internet Devices (MID), PAD, etc. Figure 5 This does not limit the structure of the aforementioned electronic devices. For example, the electronic device may also include components that are more... Figure 5 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 5 The different configurations shown.

[0085] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, ROM, RAM, disk or optical disk, etc.

[0086] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer program, which, when executed by a processor, performs the steps in the above-described method for querying membership rights data.

[0087] Optionally, in this embodiment, those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0088] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0089] If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0090] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0091] In the several embodiments provided in this application, it should be understood that the disclosed client can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between units or modules, and may be electrical or other forms.

[0092] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0093] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0094] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for querying membership benefits data, characterized in that, include: Upon receiving a membership benefits query request, a Bloom filter is invoked to determine the existence of the target membership benefits identifier in the query request. The Bloom filter stores a set of currently valid membership benefits identifiers in the database. If the Bloom filter determines that the target member benefit identifier does not exist in the set of member benefit identifiers, the result of invalid benefit is returned directly. If the target member benefit identifier is determined to exist in the set of member benefit identifiers by the Bloom filter, the target member benefit identifier is queried sequentially in the cache layer and the database to obtain the corresponding member benefit data and return it. If the target member benefit identifier is not found in either the cache layer or the database, an invalid benefit result is returned. An empty value for the target member benefit identifier and an expiration period are written to the cache layer to prevent the target member benefit identifier from being accessed in the database again during the expiration period.

2. The method according to claim 1, characterized in that, Before receiving a membership benefits inquiry request, the method further includes: When the system starts up or restarts, it retrieves the set of currently valid member benefit identifiers from the database; The Bloom filter is initialized based on the set of member benefits identifiers, so that the set of member benefits identifiers can be written into the Bloom filter in batches through the batch write interface of the Bloom filter; Set the estimated capacity and target false positive rate for the Bloom filter.

3. The method according to claim 2, characterized in that, Initializing the Bloom filter based on the set of membership benefit identifiers includes: The Bloom filter is created, its parameters are configured, and data is written through the Bloom filter management interface provided by the distributed cache client. The Bloom filter management interface is used to encapsulate the initialization, existence judgment, and data maintenance logic of the Bloom filter.

4. The method according to claim 1, characterized in that, The target membership benefit identifier is queried sequentially in the cache layer and the database to obtain the corresponding membership benefit data and return it, including: Query the target member benefits identifier in the cache layer; If the target member benefit identifier is found in the cache layer, the corresponding member benefit data is obtained and returned. If the target member benefit identifier is not found in the cache layer, the target member benefit identifier is queried in the database. If the target member benefit identifier is found in the database, the corresponding member benefit data is retrieved and returned.

5. The method according to any one of claims 1 to 4, characterized in that, The method further includes: When new or activated member benefits data is detected, the corresponding new member benefits identifier is written into the database, and the new member benefits identifier is simultaneously written into the Bloom filter; The cache layer is updated based on the new member benefits data.

6. The method according to any one of claims 1 to 4, characterized in that, The method further includes: If any member benefit data in the database is detected to have been updated or become invalid, the set of member benefit identifiers in the Bloom filter is updated by periodically rebuilding or reinitializing the Bloom filter.

7. The method according to any one of claims 1 to 4, characterized in that, The method further includes: The cache access abstraction framework encapsulates the cache read and write logic of member rights data in a unified manner, so as to complete the access to the cache layer through a unified cache access interface.

8. A device for querying membership rights data, characterized in that, include: The judgment module is used to call a Bloom filter to determine the existence of the target member benefit identifier in the member benefit query request when a member benefit query request is received. The Bloom filter stores a set of currently valid member benefit identifiers in the database. The first return module is used to directly return an invalid benefit result if the target member benefit identifier is not found in the set of member benefit identifiers determined by the Bloom filter. The query module is used to query the target member benefit identifier sequentially in the cache layer and the database when it is determined by the Bloom filter that the target member benefit identifier may exist in the set of member benefit identifiers, so as to obtain the corresponding member benefit data and return it. The second return module is used to return an invalid benefit result when the target member benefit identifier is not found in either the cache layer or the database, and to write a null value for the target member benefit identifier and set an expiration period in the cache layer so that the target member benefit identifier is not triggered to access the database again within the expiration period.

9. A computer-readable storage medium storing a computer program, characterized in that, The computer program is executed by the processor to perform the method described in any one of claims 1 to 7.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to execute the method described in any one of claims 1 to 7 through the computer program.

Images