Purchase record query method and device

Abstract

The embodiment of the invention discloses a purchase record query method and device, and the method comprises the steps: receiving a first query request for querying whether a target user purchases a target commodity or not, querying a preset filter according to the first query request, and obtaining a first query result; if the first query result is that the target commodity is possibly purchased, sending a second query request for querying whether the target user purchases the target commodity or not to the preset cache, and obtaining a second query result; if a second query result returned by the cache in response to the second query request is not queried, sending a third query request for querying whether the target user purchases the target commodity to a preset database, and obtaining a third query result; and judging whether the target user purchases the target commodity or not according to the third query result. Through the scheme of the application, the purpose of quickly and accurately judging whether the target user purchases a certain commodity in mass data can be achieved.

Description

Technical Field

[0001] The present invention relates to the field of data processing technology, and in particular to a purchase record query method and device. Background Art

[0002] In today's digital age, knowledge payment has become an important business model. Users pay to obtain high-quality knowledge content, such as online courses, e-books, etc. In order to improve user experience and stickiness, and ensure that users can use the purchased products for free for a long time or permanently after purchase, the system needs to quickly and accurately determine whether the user has purchased a certain product. In the massive data, how to quickly determine is particularly important.

[0003] Currently, the commonly used methods to query whether the target user has purchased the target product are: 1. Query the user's purchase details log. The query storage media are such as SQL Server, Elasticsearch, HBase, etc. However, due to the large amount of data, the query response time is more than 500ms. There is a problem that the latest data cannot be queried due to write delay. In addition, due to the high query frequency, the hardware cost is expensive. 2. Query the user's purchase snapshot information (user ID, product ID, purchase time), and improve the reading and writing efficiency by partitioning the database and table by taking the user ID modulo partition. This solution will result in a large number of invalid query requests, resulting in high query pressure on the database (DB), after all, the probability of users making repeated purchases is not high. Summary of the invention

[0004] The present invention aims to solve at least one of the technical problems existing in the prior art. To this end, the present invention proposes a purchase record query method and device to solve the technical problems existing in the query scheme of the prior art, such as low query performance, poor real-time performance, and high hardware cost.

[0005] In a first aspect, the present invention provides a purchase record query method, the method comprising: receiving a first query request for querying whether a target user has purchased a target product, querying a preset filter according to the first query request, and obtaining a first query result; If the first query result indicates that the target user may have purchased the target product, a second query request is sent to a preset cache to query whether the target user has purchased the target product, and a second query result is obtained; If the second query result returned by the cache in response to the second query request is that no query is found, a third query request is sent to a preset database to query whether the target user has purchased the target product, and a third query result is obtained; It is determined whether the target user has purchased the target product according to the third query result.

[0006] Through the embodiments of the present application, by successively using preset filters to filter out most of the users who do not make repeated purchases, using the cache as a buffer to solve the instantaneous concurrency problem, and finally querying the preset database to obtain the final judgment result, it is possible to achieve the purpose of quickly and accurately determining whether the target user has purchased a certain product in massive data.

[0007] In a technical solution of the purchase record query method described above, the first query request includes at least a user identifier of the target user and a product identifier of the target product, and querying a preset filter according to the first query request to obtain a first query result includes: A corresponding hash value is calculated using a preset hash algorithm according to the user identifier and the product identifier; The preset filter is queried according to the hash value to obtain a first query result.

[0008] In a technical solution of the purchase record query method described above, the second query request includes at least a user identifier of the target user, and the sending of the second query request to the preset cache to query whether the target user has purchased the target product, and obtaining the second query result, includes: The preset cache is queried according to the user identifier, and if the commodity identifier of the target commodity does not exist in the preset cache, it is determined that the second query result is not found.

[0009] In a technical solution of the above purchase record query method, querying the preset cache according to the user identifier includes: Matching a corresponding target queue in a preset queue in the preset cache according to the user identifier, and querying whether the commodity identifier of the target commodity exists in the target queue; If the commodity identifier of the target commodity does not exist in the preset cache, it is determined that the second query result is not found.

[0010] In a technical solution of the above-mentioned purchase record query method, sending a second query request to a preset cache to query whether the target user has purchased the target product to obtain a second query result also includes: If the commodity identifier of the target commodity exists in the preset cache, it is determined that the second query result is found. At this time, it is determined that the target user has purchased the target commodity and the query process ends.

[0011] In a technical solution of the purchase record query method described above, the third query request includes at least a user identifier of the target user and a product identifier of the target product, and sending the third query request to a preset database to query whether the target user has purchased the target product, and obtaining a third query result includes: Query the preset database according to the user identifier to obtain a corresponding preset data table; Querying the preset data table according to the user identifier and the commodity identifier to obtain the purchase time when the target user purchased the target commodity; It is determined whether the purchase time is within a preset time range. If so, it is determined that the third query result means that the target user has purchased the target product. Otherwise, it is determined that the third query result means that the target user has not purchased the target product.

[0012] In a technical solution of the above-mentioned purchase record query method, the sending of a third query request to a preset database to query whether the target user has purchased the target product and obtaining a third query result further includes: If the purchase time of the target product by the target user is not obtained, it is determined that the third query result is that the target user has not purchased the target product.

[0013] In a technical solution of the above-mentioned purchase record query method, the preset filter includes a Bloom filter.

[0014] In a technical solution of the above-mentioned purchase record query method, the sending of a third query request to a preset database to query whether the target user has purchased the target product, and obtaining the third query result includes: receiving a plurality of third query requests, and assigning the plurality of third query requests to corresponding message queues, each of the message queues comprising a plurality of query processes; Obtaining a response time of the preset database processing the third query request in the message queue and a state parameter of the message queue; The number of threads included in the multiple query processes is adjusted according to the response duration and the state parameters of the message queue, so that the third query request in the message queue is pushed to the preset database for processing according to the adjusted number of threads.

[0015] Through the embodiments of the present application, on the one hand, multiple third query requests are stored in the message queue, so that the message queue can handle a large number of third query requests instantly, thereby avoiding transaction congestion or even the risk of collapse caused by the inability to process a large number of third query requests in time; on the other hand, each message queue will have multiple query processes, and the query process can dynamically adjust the push speed according to the business processing efficiency of the preset database, thereby ensuring that the database can process the third query requests smoothly and orderly under limited hardware resources without high concurrency downtime.

[0016] In a second aspect, the present invention provides a purchase record query device, the device comprising: A first query module is used to receive a first query request for querying whether a target user has purchased a target product, query a preset filter according to the first query request, and obtain a first query result; A second query module, configured to send a second query request to a preset cache to query whether the target user has purchased the target product, and obtain a second query result if the first query result indicates that the target user may have purchased the product; a third query module, configured to send a third query request to a preset database to query whether the target user has purchased the target product, and obtain a third query result if the second query result returned by the cache in response to the second query request is not found; A judgment module is used to judge whether the target user has purchased the target product according to the third query result.

[0017] In a third aspect, the present invention provides a computer device comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, and when the computer program is executed by the processor, the purchase record query method as described in any one of the first aspects is implemented.

[0018] In a fourth aspect, the present invention provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, wherein when the computer program is executed, the purchase record query method as described in any one of the first aspects is implemented.

[0019] The above one or more technical solutions of the present invention have at least one or more of the following beneficial effects: In the technical solution of the present invention, a first query request is received to query whether the target user has purchased the target product, and a preset filter is queried according to the first query request to obtain a first query result; if the first query result is that the target user may have purchased the target product, a second query request is sent to a preset cache to query whether the target user has purchased the target product to obtain a second query result; if the cache returns the second query result in response to the second query request as not found, a third query request is sent to a preset database to query whether the target user has purchased the target product to obtain a third query result; and it is determined whether the target user has purchased the target product according to the third query result. The present application solution can achieve the purpose of quickly and accurately determining whether the target user has purchased a certain product in massive data.

[0020] Additional aspects and advantages of the present invention will be given in part in the following description and in part will be obvious from the following description, or will be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The disclosure of the present invention will become more easily understood with reference to the accompanying drawings. It is easy for those skilled in the art to understand that these drawings are only for illustrative purposes and are not intended to limit the scope of protection of the present invention. In addition, similar numbers in the figures are used to represent similar components, among which:

[0022] Figure 1 is a flow chart of a purchase record query method provided in Example 1 of the present application; Figure 2 is a flow chart of the data writing process provided in Example 1 of the present application; Figure 3 is a flow chart of a purchase record query method provided in Embodiment 2 of the present application; Figure 4 It is a structural diagram of the purchase record query device provided in Example 3 of the present application.

[0023] Figure 5 It is a structural diagram of the computer device provided in Example 4 of the present application. DETAILED DESCRIPTION

[0024] Some embodiments of the present invention are described below with reference to the accompanying drawings. It should be understood by those skilled in the art that these embodiments are only used to explain the technical principles of the present invention and are not intended to limit the protection scope of the present invention.

[0025] As described in the background art, existing query solutions for querying whether a user has purchased a certain product either have low query performance and poor real-time performance, or have high hardware costs and are not perfect.

[0026] Based on this, the present application proposes a new purchase record query method, which first uses a preset filter to filter out most of the users who do not make repeated purchases, and secondly, uses the cache as a buffer to solve the instantaneous concurrency problem, and finally queries the preset database to obtain the final judgment result, thereby achieving the purpose of quickly and accurately determining whether the target user has purchased a certain product in massive data.

[0027] Embodiment 1 Figure 1 is a flowchart of the purchase record query method provided in Example 1 of the present application, referring to Figure 1 As shown, the method comprises the following steps: Step 1: Use preset filters to check whether the target user has purchased the target product.

[0028] It is understandable that in the embodiments of the present application, the target commodity is not specifically limited, and any known product can be used as the target commodity in the present application without violating the inventive concept of the present application. For example, as an illustrative and non-restrictive explanation, the target commodity in the embodiments of the present application can be an online course, an e-book, and other products.

[0029] It should be noted that, through investigation, it was found that the repeat purchase rate of the same product purchased by the same user is <10% within the last month, <2% within one month to one year, and <5‰ within one to two years, that is, the longer the time, the lower the repeat purchase rate. Based on this, about 90% of the query requests are for those who have not purchased, that is, invalid requests (false). It is understandable that in order to improve user experience and stickiness, and ensure that users can use the purchased products for a long time or permanently for free after purchase, the system needs to quickly and accurately determine whether the user has purchased a certain product. In order to achieve the above purpose, the embodiment of the present application first designs a high-concurrency and fast-response interface for determining whether the target user has purchased the target product. The interface can filter out the above-mentioned approximately 90% of invalid requests in the first stage, thereby improving query performance.

[0030] As a preferred implementation, in an embodiment of the present application, a preset filter is used as a filtering interface to filter the query request for whether the target user has purchased the target product, so as to filter out most of the non-repeat purchasing users, thereby reducing the subsequent database access volume.

[0031] It should be noted that in the embodiments of the present application, no specific limitation is made to the preset filter. Without violating the inventive concept of the present application, any known filter can be used as the preset filter in the present application. For example, as an exemplary but not restrictive description, the preset filter in the present application can be a Bloom filter.

[0032] It can be understood that Bloom filters can be used to query whether an element exists in a set, and the query results are one of the two: "this element may exist in this set" and "this element must not exist in this set". The advantage of Bloom filters is that the space efficiency and query time are much better than general algorithms. In practice, they are mainly used to solve problems such as web URL deduplication, spam detection, duplicate element judgment in large sets, and cache breakdown. Bloom filters usually consist of a set of hash functions and a bit array. The basic idea of ​​Bloom filters is to use the hash table data structure to map an element into a point in a bit array (each point can only be represented as 0 or 1) through a hash function. In this way, we only need to see if this point is 1 to know whether it exists in the set.

[0033] It is understandable that the data storage structure of the Bloom filter is in the form of key-value pairs. It should be noted that in the embodiment of the present application, the key and value used by the Bloom filter are not specifically limited, and can be set according to actual query requirements without violating the inventive concept of the present application. As an illustrative and non-restrictive explanation, in the embodiment of the present application, the key of the Bloom filter can be designed with a combination of user identification + product identification (ie, user ID + product ID), and its corresponding value is a hash value calculated using a hash algorithm based on the combination of user identification + separator + product identification (ie, user ID + separator + product ID).

[0034] In some specific embodiments, a single key can be designed to store 100 million pieces of data (user ID + product ID) with a permissible error rate of 1%. With 2 billion pieces of data per year, 20 keys are planned per year, and the redis key is generated using year + user ID%20. The storage space of each key is about 100M, and the total space occupied is 0.1*20*5=10G.

[0035] It is understandable that in order to avoid storing a large amount of invalid data in the key storage space and wasting storage space memory, in an embodiment of the present application, invalid data in the storage space can be cleaned up regularly. For example, keys in the storage space five years ago can be cleaned up.

[0036] The following describes the present application scheme by taking the preset filter as a Bloom filter as an example.

[0037] When performing a specific query, first calculate the hash value based on the target user ID + separator + target product ID, and then query the Bloom filter based on the hash value. If the query is not found, it can be determined that the target user has definitely not purchased the product, and the program ends directly. This can filter most query requests. If the query is found, it means that the product may have been purchased, and it is necessary to continue to search accurately in the cache layer and storage layer.

[0038] Step 2: Query the preset cache area to see whether the target user has purchased the target product.

[0039] It is understandable that excessive traffic on the query interface may cause the server to freeze, and in the case of server freeze, users may click related buttons (such as purchase buttons, etc.) multiple times, causing the database to be under great pressure. In response to the above problems, the embodiment of the present application adopts a buffer design, that is, before performing an accurate search in the storage layer (i.e., the database), a query is first performed in the buffer to prevent the database from crashing due to excessive instantaneous traffic.

[0040] During specific implementation, a preset cache is used as a buffer, and relevant data (such as instant purchase records, etc.) is written to the buffer first, and then read from the buffer first. It can be understood that the data storage structure of the buffer also adopts the key-value pair (key-value) form. It should be noted that in the embodiment of the present application, the key (key) and value (value) used in the buffer are not specifically limited. Without violating the inventive concept of the present application, it can be set according to actual query requirements. As an exemplary and non-restrictive explanation, in the embodiment of the present application, the key (key) of the buffer can be designed with a combination of user identification (ie user ID), and its corresponding value (value) can be a set of commodity identification (commodity ID). Preferably, the set of commodity identification (commodity ID) can use a queue (list) data structure.

[0041] It should be noted that in the embodiments of the present application, no specific limitation is made to the preset cache. Without violating the inventive concept of the present application, any known cache can be used as the preset cache in the present application. For example, as an exemplary but not restrictive description, the preset cache in the present application can use Redis.

[0042] It is understandable that Redis is a key-value storage system that supports more value types, including string, list, set, and zset. These data types support push / pop, add / remove, intersection, union, difference, and richer operations, and these operations are atomic. On this basis, Redis supports various different sorting methods. To ensure efficiency, Redis data is cached in memory. Redis also periodically writes updated data to disk or writes modification operations to additional record files, and on this basis, master-slave synchronization is implemented.

[0043] The following describes the application scheme by taking Redis as an example.

[0044] When querying specifically, first find the corresponding queue (i.e., the product ID set) in Redis based on the target user ID, and then find out whether the target product ID exists in the corresponding queue (i.e., the product ID set). If it exists, it is determined that the target user has purchased the target product, and the program ends directly. Otherwise, continue to search accurately in the storage layer.

[0045] Step 3: Query the preset database to see whether the target user has purchased the target product.

[0046] It should be noted that in the embodiments of the present application, the preset database is not specifically limited. Without violating the inventive concept of the present application, any known database can be used as the preset database in the present application. For example, as an exemplary but not restrictive description, the preset database in the present application can adopt a relational database, such as MySQL, Oracle, SQLite, Access, MS SQL Server, etc.

[0047] It is understandable that MySQL is a relational database management system that allows users to store, retrieve, modify and manage data. MySQL is widely popular for its free use, simple configuration, good stability and excellent performance.

[0048] It is understandable that MySQL stores data in different tables instead of putting all data in a large warehouse, which increases speed and flexibility. It should be noted that the capacity and size of the data table are not specifically limited in the embodiment of the present application. During the specific implementation, it can be set according to the data business requirements to control the query speed and operating costs. As an exemplary and non-restrictive explanation, in the embodiment of the present application, the single table data capacity of the data table in the preset database can be set to 100 million, the data volume can be 10 billion, and it can be split into 100 tables for storage and the table sequence number can be obtained by the user ID. The elements in the data table include but are not limited to information such as user ID, product ID, purchase time, etc.

[0049] The following describes the present application scheme by taking MySQL as an example.

[0050] When specifically querying, you can first obtain the table number according to the user ID, then query the data row according to the user ID and the product ID, obtain the corresponding purchase time, and then determine whether the corresponding purchase time meets the preset requirements. If it does, it is determined that the target user has purchased the target product, otherwise it is determined that the target user has not purchased the target product. Furthermore, if no purchase record is found, it is also determined that the target user has not purchased the target product.

[0051] It is understandable that in the embodiments of the present application, the preset requirements are not specifically limited, and can be set according to actual business needs during implementation. For example, as an exemplary and non-restrictive description, it can be set that if the purchase time is within five years, it is determined that the target user has purchased the target product, otherwise it is determined that the target user has not purchased the target product.

[0052] Reference Figure 2 As shown, as a preferred implementation, the embodiment of the present application also includes a data writing process. Since Redis has a faster writing speed and MySQL has a slower writing speed, in the embodiment of the present application, Redis is set to use a synchronous writing method and MySQL to use an asynchronous writing method.

[0053] Further references Figure 2As shown, the data writing process includes two parts: the main process and the auxiliary process, wherein the main process mainly includes the processes of writing to the bloom filter, writing to the redis buffer, and writing to the jvm memory queue, and the auxiliary process mainly includes the process of the jvm memory queue dequeuing and continuing to write to MySQL. In order to improve the high availability of the writing process, in the embodiment of the present application, in the auxiliary process, if it is determined that the writing to the bloom filter, the redis buffer, or the MySQL fails, the delay queue is re-entered, and if the retry is not successful for several times, it is determined that the writing fails. In addition, it is also set to dequeue the unprocessed data in the queue through the jvm hook to ensure the elegant closure of the program.

[0054] Furthermore, you can also set up a data verification and compensation mechanism to write a copy of the requested original data to the Redis queue during the writing process of the Redis buffer, and verify the compensation through the compensation task. If the writing is not successful, rewrite it to ensure high availability of writing.

[0055] It is understandable that the purchase record query method provided in the embodiment of the present application has the characteristics of fast query performance, low hardware cost, strong scalability, etc. It has been verified that its query performance can reach tp99<100 ms, and its hardware only requires 10G Redis memory and 200G solid-state hard disk, and when expanding, it only needs to increase Redis memory and expand MySQL hard disk, the program modification cost is small, and the performance indicators remain unchanged.

[0056] Embodiment 2 Corresponding to the above-mentioned embodiment 1, the present application also provides a purchase record query method. In this embodiment, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction, and will not be described in detail later. Figure 3 As shown, the method comprises the following steps:

[0057] S100: receiving a first query request for querying whether a target user has purchased a target product, querying a preset filter according to the first query request, and obtaining a first query result.

[0058] It is understandable that in the embodiments of the present application, the target commodity is not specifically limited, and any known product can be used as the target commodity in the present application without violating the inventive concept of the present application. For example, as an illustrative and non-restrictive explanation, the target commodity in the embodiments of the present application can be an online course, an e-book, and other products.

[0059] It should be noted that, in the embodiments of the present application, no specific limitation is made to the preset filter, and during specific implementation, it can be selected according to actual business conditions. As an exemplary and non-restrictive description, the preset filter can be a Bloom filter.

[0060] It is understandable that the first query result includes two situations: possible purchase and no purchase. When the first query result is possible purchase, it is necessary to continue to search accurately in the cache layer and the storage layer. When the first query result is no purchase, the query process ends. It is understandable that in the embodiment of the present application, the cache layer is the preset cache and the storage layer is the preset database.

[0061] S200: If the first query result indicates that the target product may have been purchased, a second query request is sent to a preset cache to query whether the target user has purchased the target product, and a second query result is obtained.

[0062] It should be noted that in the embodiments of the present application, no specific limitation is made to the preset cache. Without violating the inventive concept of the present application, any known cache can be used as the preset cache in the present application. For example, as an exemplary but not restrictive description, the preset cache in the present application can use Redis.

[0063] It can be understood that the second query result includes two situations: queried and not queried. When the second query result is queried, it can be determined that the target user has purchased the target product, and the query process is directly terminated. When the second query result is not queried, it is necessary to continue to search accurately in the storage layer.

[0064] S300: If the second query result returned by the cache in response to the second query request is not found, a third query request is sent to a preset database to query whether the target user has purchased the target product, and a third query result is obtained.

[0065] It should be noted that in the embodiments of the present application, the preset database is not specifically limited. Without violating the inventive concept of the present application, any known database can be used as the preset database in the present application. For example, as an exemplary but not restrictive description, the preset database in the present application can adopt a relational database, such as MySQL, Oracle, SQLite, Access, MS SQL Server, etc.

[0066] S400: Determine whether the target user has purchased the target product according to the third query result.

[0067] As an exemplary and non-restrictive description, in an embodiment of the present application, the third query result can be set as the purchase record of the target user purchasing the target product. It is understandable that when no purchase record of the target user purchasing the target product is found, it can be directly determined that the target user has not purchased the target product; when the purchase record of the target user purchasing the target product is found, it is determined whether the target user has purchased the target product based on the purchase time in the purchase record. As mentioned above, since the longer the time, the lower the repeat purchase rate, therefore, as an exemplary and non-restrictive description, in an embodiment of the present application, it can be set that if the purchase time is within five years, it is determined that the target user has purchased the target product, otherwise it is determined that the target user has not purchased the target product.

[0068] It can be understood that the purchase record query method provided in the embodiment of the present application can achieve the purpose of quickly and accurately determining whether the target user has purchased a certain product in massive data by successively using preset filters to filter out most of the users who do not make repeated purchases, using the cache as a buffer to solve the instantaneous concurrency problem, and finally querying the preset database to obtain the final judgment result.

[0069] As a preferred implementation, in an embodiment of the present application, the first query request includes at least a user identifier of the target user and a product identifier of the target product, and querying a preset filter according to the first query request to obtain a first query result includes: A corresponding hash value is calculated using a preset hash algorithm according to the user identifier and the product identifier; The preset filter is queried according to the hash value to obtain a first query result.

[0070] It is understandable that since the Bloom filter is usually composed of a set of hash functions and a bit array, and its data storage structure is in the form of key-value pairs, the user ID + product ID can be used as the key of the Bloom filter. When querying, first calculate the hash value based on the target user ID + separator + target product ID, and then query the Bloom filter based on the hash value. If it is not found, it can be determined that the target user has definitely not purchased it, and the program ends directly. This can filter most query requests. If it is found, it means that it may have been purchased, and it is necessary to continue to search accurately at the cache layer and storage layer.

[0071] As a preferred implementation, in an embodiment of the present application, the second query request includes at least a user identifier of the target user, and the sending of the second query request to the preset cache to query whether the target user has purchased the target product to obtain the second query result includes: querying the preset cache according to the user identifier, and if the commodity identifier of the target commodity does not exist in the preset cache, determining that the second query result is not found; If the commodity identifier of the target commodity exists in the preset cache, it is determined that the second query result is found. At this time, it is determined that the target user has purchased the target commodity and the query process ends.

[0072] It is understandable that since the data storage structure of Redis also adopts the key-value pair format. Therefore, as an exemplary but not restrictive explanation, in the embodiment of the present application, the user ID can be used as the key of Redis, and the product ID can be used as its corresponding value. During a specific query, you can query Redis based on the user ID of the target user to see whether the product ID of the target product exists. If not, it is determined that the second query result is not found, and it is necessary to continue to search accurately in the storage layer; if it exists, it is determined that the second query result is found, and it is judged that the target user has purchased the target product, and the program ends directly.

[0073] As a preferred implementation, in the embodiment of the present application, querying the preset cache according to the user identifier includes: Matching a corresponding target queue in a preset queue in the preset cache according to the user identifier, and querying whether the commodity identifier of the target commodity exists in the target queue; If the commodity identifier of the target commodity does not exist in the preset cache, it is determined that the second query result is not found.

[0074] It is understandable that Redis supports more types of value storage, including string, list, set, and zset. As an exemplary but not restrictive explanation, in the embodiment of the present application, the type of value stored in Redis can be list. When making a specific query, first find the corresponding queue (i.e., the set of commodity identifiers) in Redis according to the target user identifier, and then find out whether the target commodity identifier exists in the corresponding queue (i.e., the set of commodity identifiers). If it exists, it is determined that the target user has purchased the target commodity, and the program ends directly, otherwise continue to search accurately in the storage layer.

[0075] As a preferred implementation manner, in the embodiment of the present application, the third query request includes at least the user identifier of the target user and the product identifier of the target product, and the third query request is sent to the preset database to query whether the target user has purchased the target product, and the third query result is obtained, including: Query the preset database according to the user identifier to obtain a corresponding preset data table; Querying the preset data table according to the user identifier and the commodity identifier to obtain the purchase time when the target user purchased the target commodity; It is determined whether the purchase time is within a preset time range. If so, it is determined that the third query result means that the target user has purchased the target product. Otherwise, it is determined that the third query result means that the target user has not purchased the target product.

[0076] It is understandable that the data in the preset database is stored in a preset data table, and the elements in the preset data table include but are not limited to information such as user identification, product identification, purchase time, etc. When specifically querying, the table sequence number can be obtained according to the user identification, and then the data row can be queried according to the user identification and product identification to obtain the corresponding purchase time, and then it is determined whether the corresponding purchase time meets the preset requirements. If so, it is determined that the target user has purchased the target product, otherwise it is determined that the target user has not purchased the target product.

[0077] As a preferred implementation, in the embodiment of the present application, the sending of a third query request to a preset database to query whether the target user has purchased the target product, and obtaining a third query result, further includes: If the purchase time of the target product by the target user is not obtained, it is determined that the third query result is that the target user has not purchased the target product.

[0078] It is understandable that if the purchase time of the target user purchasing the target product is not found (ie, no purchase record is found), it is determined that the target user has not purchased the target product.

[0079] As a preferred implementation, in the embodiment of the present application, the sending of a third query request to a preset database to query whether the target user has purchased the target product, and obtaining the third query result includes: receiving a plurality of third query requests, and assigning the plurality of third query requests to corresponding message queues, each of the message queues comprising a plurality of query processes; Obtaining a response time of the preset database processing the third query request in the message queue and a state parameter of the message queue; The number of threads included in the multiple query processes is adjusted according to the response duration and the state parameters of the message queue, so that the third query request in the message queue is pushed to the preset database for processing according to the adjusted number of threads.

[0080] It is understandable that by storing multiple third query requests in the message queue, the message queue can handle a large number of third query requests instantly, thereby avoiding transaction congestion or even the risk of collapse caused by a large number of third query requests not being able to be processed in time.

[0081] Furthermore, by setting each message queue to have multiple query processes, the query process can dynamically adjust the push speed according to the business processing efficiency of the preset database, thereby ensuring that the database can process the third query request smoothly and orderly under limited hardware resources without high concurrency downtime.

[0082] Embodiment 3 Corresponding to the above-mentioned embodiments 1 and 2, the present application further provides a purchase record query device, which is used to implement the purchase record query method provided in any one of embodiments 1 or 2. In this embodiment, the same or similar contents as those in the above-mentioned embodiments 1 or 2 can be referred to the above introduction and will not be described in detail later. Figure 4 As shown, the device comprises:

[0083] The first query module 10 is used to receive a first query request for querying whether a target user has purchased a target product, query a preset filter according to the first query request, and obtain a first query result; A second query module 20 is configured to send a second query request to a preset cache to query whether the target user has purchased the target product, and obtain a second query result if the first query result indicates that the target user may have purchased the product; A third query module 30 is configured to send a third query request to a preset database to query whether the target user has purchased the target product, and obtain a third query result if the second query result returned by the cache in response to the second query request is not found; The judgment module 40 is used to judge whether the target user has purchased the target product according to the third query result.

[0084] As a preferred implementation, in the embodiment of the present application, the first query module 10 is specifically used for: A corresponding hash value is calculated using a preset hash algorithm according to the user identifier and the product identifier; The preset filter is queried according to the hash value to obtain a first query result.

[0085] As a preferred implementation, in the embodiment of the present application, the second query module 20 is specifically used for: The preset cache is queried according to the user identifier, and if the commodity identifier of the target commodity does not exist in the preset cache, it is determined that the second query result is not found.

[0086] As a preferred implementation, in the embodiment of the present application, the second query module 20 is further used for: Matching a corresponding target queue in a preset queue in the preset cache according to the user identifier, and querying whether the commodity identifier of the target commodity exists in the target queue; If the commodity identifier of the target commodity does not exist in the preset cache, it is determined that the second query result is not found.

[0087] As a preferred implementation, in the embodiment of the present application, the second query module 20 is further used for: If the commodity identifier of the target commodity exists in the preset cache, it is determined that the second query result is found. At this time, it is determined that the target user has purchased the target commodity and the query process ends.

[0088] As a preferred implementation, in the embodiment of the present application, the third query module 30 is specifically used for: Query the preset database according to the user identifier to obtain a corresponding preset data table; Querying the preset data table according to the user identifier and the commodity identifier to obtain the purchase time when the target user purchased the target commodity; It is determined whether the purchase time is within a preset time range. If so, it is determined that the third query result means that the target user has purchased the target product. Otherwise, it is determined that the third query result means that the target user has not purchased the target product.

[0089] As a preferred implementation, in the embodiment of the present application, the third query module 30 is further used for: If the purchase time of the target product by the target user is not obtained, it is determined that the third query result is that the target user has not purchased the target product.

[0090] As a preferred implementation, in the embodiment of the present application, the preset filter includes a Bloom filter.

[0091] As a preferred implementation, in the embodiment of the present application, the third query module 30 is further used for: receiving a plurality of third query requests, and assigning the plurality of third query requests to corresponding message queues, each of the message queues comprising a plurality of query processes; Obtaining a response time of the preset database processing the third query request in the message queue and a state parameter of the message queue; The number of threads included in the multiple query processes is adjusted according to the response duration and the state parameters of the message queue, so that the third query request in the message queue is pushed to the preset database for processing according to the adjusted number of threads.

[0092] Embodiment 4 Corresponding to the above-mentioned embodiment one or two, the present application also provides a computer device, including: a processor and a memory, the memory stores a computer program that can be run on the processor, and when the computer program is executed by the processor, the purchase record query method provided in any one of the above-mentioned embodiments is executed.

[0093] in, Figure 5 The computer device 1500 is shown as an example, and may include a processor 1510, a video display adapter 1511, a disk drive 1512, an input / output interface 1513, a network interface 1514, and a memory 1520. The processor 1510, the video display adapter 1511, the disk drive 1512, the input / output interface 1513, the network interface 1514, and the memory 1520 may be communicatively connected via a communication bus 1530.

[0094] Among them, the processor 1510 can be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits, etc., to execute relevant programs to implement the technical solution provided by the present invention.

[0095] The memory 1520 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1520 can store an operating system 1521 for controlling the operation of the electronic device and a basic input and output system (BIOS) for controlling the low-level operation of the electronic device. In addition, a web browser 1523, a data storage management system 1524, and a device identification information processing system 1525, etc. can also be stored. The above-mentioned device identification information processing system 1525 can be an application program that specifically implements the operations of the aforementioned steps in the embodiment of the present invention. In short, when the technical solution provided by the present invention is implemented by software or firmware, the relevant program code is stored in the memory 1520 and is called and executed by the processor 1510.

[0096] The input / output interface 1513 is used to connect the input / output module to realize information input and output. The input / output module can be configured in the device as a component (not shown in the figure), or it can be externally connected to the device to provide corresponding functions. The input device may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output device may include a display, a speaker, a vibrator, an indicator light, etc.

[0097] The network interface 1514 is used to connect to a communication module (not shown) to achieve communication interaction between the device and other devices. The communication module can achieve communication through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0098] The bus includes a path that transmits information between the various components of the device (eg, processor 1510 , video display adapter 1511 , disk drive 1512 , input / output interface 1513 , network interface 1514 , and memory 1520 ).

[0099] In addition, the electronic device can also obtain information on specific collection conditions from the virtual resource object collection condition information database for use in condition judgment, etc.

[0100] It should be noted that, although the above device only shows a processor 1510, a video display adapter 1511, a disk drive 1512, an input / output interface 1513, a network interface 1514, a memory 1520, a bus, etc., in the specific implementation process, the device may also include other components necessary for normal operation. In addition, it can be understood by those skilled in the art that the above device may also only include components necessary for implementing the solution of the present invention, and does not necessarily include all the components shown in the figure.

[0101] Embodiment 5 Corresponding to the above-mentioned embodiment one or two, the embodiment of the present application further provides a computer-readable storage medium, wherein, in this embodiment, the same or similar contents as those of the above-mentioned embodiment one or two can be referred to the above introduction and will not be repeated later.

[0102] The computer-readable storage medium stores a computer program, and when the computer program is executed by the processor, the purchase record query method described above is implemented.

[0103] In some implementations, in the embodiments of the present application, when the computer program is executed by the processor, the steps corresponding to the method described in Embodiment 1 may also be implemented. Please refer to the detailed description in Embodiment 1 and no further details will be given here.

[0104] It can be known from the above description of the implementation mode that those skilled in the art can clearly understand that the present invention can be implemented by means of software plus a necessary general hardware platform. Based on such an understanding, the technical solution of the present invention can be essentially or partly contributed to the prior art in the form of a software product, which can be stored in a storage medium such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in the various embodiments of the present invention or certain parts of the embodiments.

[0105] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can refer to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system or system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can refer to the partial description of the method embodiment. The system and system embodiments described above are merely schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without creative work.

[0106] It should be understood that the various parts of the present invention can be implemented by hardware, software, firmware or a combination thereof. In the above-mentioned embodiments, a plurality of steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0107] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "examples", "specific examples", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0108] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of the features. In the description of the present invention, the meaning of "plurality" is at least two, such as two, three, etc., unless otherwise clearly and specifically defined.

[0109] Although the embodiments of the present invention have been shown and described above, it is to be understood that the above embodiments are exemplary and are not to be construed as limitations of the present invention. A person skilled in the art may change, modify, replace and vary the above embodiments within the scope of the present invention.

Claims

1. A purchase record query method, characterized in that: The method comprises: receiving a first query request for querying whether a target user has purchased a target product, querying a preset filter according to the first query request, and obtaining a first query result; If the first query result indicates that the target user may have purchased the target product, a second query request is sent to a preset cache to query whether the target user has purchased the target product, and a second query result is obtained; If the second query result returned by the cache in response to the second query request is that no query is found, a third query request is sent to a preset database to query whether the target user has purchased the target product, and a third query result is obtained; It is determined whether the target user has purchased the target product according to the third query result.

2. The purchase record query method according to claim 1, characterized in that: The first query request at least includes a user identifier of the target user and a product identifier of the target product, and querying a preset filter according to the first query request to obtain a first query result includes: A corresponding hash value is calculated using a preset hash algorithm according to the user identifier and the product identifier; The preset filter is queried according to the hash value to obtain a first query result.

3. The purchase record query method according to claim 1 or 2, characterized in that: The second query request at least includes a user identifier of the target user, and the sending of the second query request to the preset cache to query whether the target user has purchased the target product to obtain a second query result includes: The preset cache is queried according to the user identifier, and if the commodity identifier of the target commodity does not exist in the preset cache, it is determined that the second query result is not found.

4. The purchase record query method according to claim 3, characterized in that: The querying the preset cache according to the user identifier includes: Matching a corresponding target queue in a preset queue in the preset cache according to the user identifier, and querying whether the commodity identifier of the target commodity exists in the target queue; If the commodity identifier of the target commodity does not exist in the preset cache, it is determined that the second query result is not found.

5. The purchase record query method according to claim 3, characterized in that: The sending of a second query request to a preset cache to query whether the target user has purchased the target product to obtain a second query result also includes: If the commodity identifier of the target commodity exists in the preset cache, it is determined that the second query result is found. At this time, it is determined that the target user has purchased the target commodity and the query process ends.

6. The purchase record query method according to claim 1 or 2, characterized in that: The third query request includes at least a user identifier of the target user and a product identifier of the target product, and sending the third query request to a preset database to query whether the target user has purchased the target product to obtain a third query result includes: Query the preset database according to the user identifier to obtain a corresponding preset data table; Querying the preset data table according to the user identifier and the commodity identifier to obtain the purchase time when the target user purchased the target commodity; It is determined whether the purchase time is within a preset time range. If so, it is determined that the third query result means that the target user has purchased the target product. Otherwise, it is determined that the third query result means that the target user has not purchased the target product.

7. The purchase record query method according to claim 6, characterized in that: The sending of a third query request to a preset database to query whether the target user has purchased the target product, and obtaining a third query result, further includes: If the purchase time of the target product by the target user is not obtained, it is determined that the third query result is that the target user has not purchased the target product.

8. The purchase record query method according to claim 1 or 2, characterized in that: The preset filter includes a Bloom filter.

9. The purchase record query method according to claim 1 or 2, characterized in that: The sending a third query request to the preset database to query whether the target user has purchased the target product, and obtaining the third query result includes: receiving a plurality of third query requests, and assigning the plurality of third query requests to corresponding message queues, each of the message queues comprising a plurality of query processes; Obtaining a response time of the preset database processing the third query request in the message queue and a state parameter of the message queue; The number of threads included in the multiple query processes is adjusted according to the response duration and the state parameters of the message queue, so that the third query request in the message queue is pushed to the preset database for processing according to the adjusted number of threads.

10. A purchase record query device, characterized in that: The device comprises: A first query module is used to receive a first query request for querying whether a target user has purchased a target product, query a preset filter according to the first query request, and obtain a first query result; A second query module, configured to send a second query request to a preset cache to query whether the target user has purchased the target product, and obtain a second query result if the first query result indicates that the target user may have purchased the target product; a third query module, configured to send a third query request to a preset database to query whether the target user has purchased the target product, and obtain a third query result if the second query result returned by the cache in response to the second query request is not found; A judgment module is used to judge whether the target user has purchased the target product according to the third query result.

Images