CN114331576A - Electronic ticket number rapid ticket taking method based on high concurrency scene and storage medium - Google Patents
Electronic ticket number rapid ticket taking method based on high concurrency scene and storage medium Download PDFInfo
- Publication number
- CN114331576A CN114331576A CN202111646085.7A CN202111646085A CN114331576A CN 114331576 A CN114331576 A CN 114331576A CN 202111646085 A CN202111646085 A CN 202111646085A CN 114331576 A CN114331576 A CN 114331576A
- Authority
- CN
- China
- Prior art keywords
- ticket
- redis
- ticket number
- queue
- taking
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
The invention relates to an electronic ticket number rapid ticket taking method and a storage medium based on a high concurrency scene, wherein the method comprises the following steps: taking out partial ticket number segments from the ticket number segment inventory data owned by the inventory main body, and storing the partial ticket number segments in a number segment cache table; splitting the extracted ticket number segment into independent ticket numbers and inserting the independent ticket numbers into a queue to be numbered of Redis; and after receiving the invoicing instruction, taking out the corresponding ticket number from the queue to be number-fetched of the Redis, binding the obtained ticket number with the identification ID in the invoicing instruction, returning the ticket number, and deducting the ticket number from the queue to be number-fetched of the Redis. By means of the relational data and Redis cluster, different number taking strategies are met, and number taking is guaranteed to be rapid and stable and to be performed orderly.
Description
Technical Field
The application relates to the technical field of electronic ticket numbers, in particular to a method for quickly taking an electronic ticket number based on a high concurrency scene and a storage medium.
Background
At present, in different business fields, there are voucher carriers using ordered numbers as basic element information, such as non-tax receipts, value-added tax receipts, hospital outpatient invoices, movie tickets, etc., in these scenes, the numbers of each voucher have the characteristics of order, uniqueness and no repeated use, and at the same time, the numbers are required to be managed strictly and normatively, and no accident generation or loss is allowed. With the development of network technology, the online ticket issuing traffic is getting larger and larger, and how to ensure the ticket number to be fast, stable and ordered under the condition of high concurrency is a technical problem.
When a ticket issuing business command enters back-end service, firstly, whether the stock main body which is required to deduct the ticket number currently has stock is determined, then, a database row lock is used for locking all stock data under the stock main body, and stock resource contention of other concurrent business commands is prevented from causing number duplication. After the locking is successful, adding 1 to the initial number field of the number segment where the ticket number is located to represent that the current ticket number is deducted, then storing the main service information, finally releasing the row lock and submitting the database transaction, and then successfully drawing the ticket.
However, in the existing solution, all the inventory data are stored in the relational database, which is limited by the number of connections and the limitation of the database itself, and under a high concurrency request, the performance of the database will be rapidly reduced, even abnormal occurs, resulting in failure of querying and updating the inventory. When the same stock main body is connected with a plurality of external billing systems, the data of the stock main body is locked by using a database row lock in the business, so that only one ticket drawing command obtains the row lock at the same time, and then the request A, B, C is to sequentially deduct the stock in a serial mode, and the performance is too low to meet the production requirement. The scheme only meets the condition that the number draws tickets from a starting number to an ending number (namely from small to large), and other service scenes such as: the designated number is deducted, the number is taken first and then deducted, and the like, and the database is used for storing, so that the scheme has large adaptation limitation, and the number section data row searching, splitting and merging are involved, and a new performance bottleneck can be caused.
Disclosure of Invention
In view of the above problems, the present application provides a method and a storage medium for fast obtaining an electronic ticket number based on a high concurrency scenario, which solves the problem that only one ticket drawing instruction obtains a lock at the same time in the existing ticket number system, and the ticket drawing speed is slow.
In order to achieve the above object, the inventor provides an electronic ticket number fast ticket fetching method based on a high concurrency scene, which comprises the following steps:
taking out partial ticket number segments from the ticket number segment inventory data owned by the inventory main body, and storing the partial ticket number segments in a number segment cache table;
splitting the extracted ticket number segment into independent ticket numbers and inserting the independent ticket numbers into a queue to be numbered of Redis;
and after receiving the invoicing instruction, taking out the corresponding ticket number from the queue to be number-fetched of the Redis, binding the obtained ticket number with the identification ID in the invoicing instruction, returning the ticket number, and deducting the ticket number from the queue to be number-fetched of the Redis.
Further optimization, the step of binding the acquired ticket number with the identification ID in the billing instruction and then returning the ticket number specifically comprises the following steps:
after the obtained ticket number is bound with the identification ID in the billing instruction, writing the ticket number bound with the identification ID into an identity occupation information set of Redis, and taking the score value as an unlocking timestamp;
the ticket number is returned from the identity occupancy information set of Redis.
Further optimization, the step of taking out the corresponding ticket number from the queue to be numbered of Redis after receiving the billing instruction specifically comprises the following steps:
after receiving the billing instruction, confirming whether a ticket number occupied by the identification ID in the billing instruction exists or not from the identity occupation information set of the Redis, and if so, returning the ticket number from the identity occupation information set of the Redis;
and if not, taking out the corresponding ticket number from the queue to be numbered of Redis.
Further optimization, the method also comprises the following steps:
inquiring whether a ticket number with an unlocking timestamp exceeding a current timestamp exists in an identity occupation information set of Redis;
if yes, the number information of the ticket number is updated to be unused,
removing the ticket number and the information of the bound identification ID in the identity occupation information set of Redis;
the ticket number is inserted into the priority queue of Redis.
Further optimization, the step of taking out the corresponding ticket number from the queue to be numbered of Redis after receiving the billing instruction specifically comprises the following steps:
after receiving the billing instruction, confirming whether a ticket number occupied by the identification ID in the billing instruction exists or not from the identity occupation information set of the Redis, and if so, returning the ticket number from the identity occupation information set of the Redis;
if not, judging whether the priority number taking queue of the Redis has a corresponding ticket number;
if so, taking out the corresponding ticket number from the priority number taking queue of Redis and returning the taken-out ticket number;
and if not, taking out the corresponding ticket number from the queue to be numbered of Redis.
Further optimization, before the step of "taking out the corresponding ticket number from the queue to be numbered of Redis", the step includes an automatic warehousing step:
judging whether a ticket number exists in a queue to be numbered of Redis;
if yes, taking out the corresponding ticket number from the queue to be numbered of Redis;
if not, judging whether a ticket number exists in the stock main body;
if yes, deducting ticket number sections with preset number from the stock main body;
and the deducted ticket number segments with the preset number are scattered and inserted into a queue to be numbered of Redis.
Further optimization, the step of "taking out a corresponding ticket number from a queue to be numbered of Redis" specifically includes the following steps:
and taking out the ticket number with the minimum number or the ticket number occupied by the ID in the billing information or the ticket numbers with the preset number from the queue to be numbered of Redis.
Further optimization, the method also comprises the following steps:
when a new ticket number segment is stored in the stock main body, judging whether a number which is repeated in the stored ticket number segment exists in the current stock main body or not;
if yes, prompting failure of warehousing;
if not, judging whether repeated numbers exist in the to-be-number-taking queue, the priority number-taking queue and the identity occupation information set of the Redis;
if yes, prompting failure of warehousing;
if not, a new ticket number segment is inserted into the inventory body.
Further optimization, the method also comprises the following steps:
inquiring all ticket numbers once entering the number segment cache table;
grouping all tickets which once enter the number segment cache table according to the stock main body;
traversing each ticket number in each group, and calling a ticket number service interface to inquire the service data corresponding to each ticket number;
if the service data exists, the ticket number is not processed;
and if no service data exists, inserting the ticket number into a priority number queue of Redis.
Still provide another technical scheme: a storage medium storing a computer program which, when executed by a processor, performs the steps of the method described above.
Different from the prior art, according to the technical scheme, a part of ticket number segments are taken out from the stored data of the ticket number segments in the stock main body and are put into a ticket number pool as hot data, namely, the ticket number data to be used in a short time are stored in a number segment cache table, then the taken out ticket number segments are divided into independent ticket numbers and are inserted into a queue to be numbered of Redis, when a ticket drawing instruction enters a back-end system, namely after the ticket drawing instruction is received, wherein the ticket drawing instruction carries a unique identification ID capable of judging the identity of the instruction, the corresponding ticket number is taken out from the queue to be numbered of Redis, the obtained ticket number and the identification ID in the ticket drawing instruction are bound after the identities are carried out, the ticket number is returned, and the ticket number is deducted from the queue to be numbered of Redis; by means of the relational data and Redis cluster, different number taking strategies are met, and number taking is guaranteed to be rapid and stable and to be performed orderly.
The above description of the present invention is only an overview of the technical solutions of the present application, and in order to make the technical solutions of the present application more clearly understood by those skilled in the art, the present invention may be further implemented according to the content described in the text and drawings of the present application, and in order to make the above objects, other objects, features, and advantages of the present application more easily understood, the following description is made in conjunction with the detailed description of the present application and the drawings.
Drawings
The drawings are only for purposes of illustrating the principles, implementations, applications, features, and effects of particular embodiments of the present application, as well as others related thereto, and are not to be construed as limiting the application.
In the drawings of the specification:
fig. 1 is a schematic flowchart of a method for fast obtaining tickets for electronic tickets based on high concurrency scenario according to an embodiment of the invention;
FIG. 2 is a schematic view of a process of recycling unused numbers by the number recycling apparatus according to an embodiment;
FIG. 3 is a flow chart illustrating a process of the number taking device for taking numbers in a certain number order according to an embodiment;
FIG. 4 is a flowchart illustrating a process of a number fetching device for fetching a number according to a specific number of numbers;
FIG. 5 is a flowchart illustrating a process of the number fetching device for fetching a number at a designated number according to an embodiment;
FIG. 6 is a flowchart illustrating a number deduction step performed by the number deduction device according to an embodiment of the present invention;
FIG. 7 is a flow chart illustrating an automatic warehousing operation of the inventory management device according to an embodiment;
FIG. 8 is a schematic diagram illustrating a flow chart of a daily usage number segment summary of the collating device according to one embodiment;
FIG. 9 is a flow chart illustrating warehousing of total inventory by the inventory management device according to an embodiment;
FIG. 10 is a schematic flow chart of the data recovery apparatus for performing data recovery according to the embodiment;
FIG. 11 is a flowchart illustrating a storage medium according to an embodiment.
The reference numerals referred to in the above figures are explained below:
110. a storage medium.
Detailed Description
In order to explain in detail possible application scenarios, technical principles, practical embodiments, and the like of the present application, the following detailed description is given with reference to the accompanying drawings in conjunction with the listed embodiments. The embodiments described herein are merely for more clearly illustrating the technical solutions of the present application, and therefore, the embodiments are only used as examples, and the scope of the present application is not limited thereby.
Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the application. The appearances of the phrase "an embodiment" in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or related to other embodiments specifically defined. In principle, in the present application, the technical features mentioned in the embodiments can be combined in any manner to form a corresponding implementable technical solution as long as there is no technical contradiction or conflict.
Unless defined otherwise, technical terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs; the use of relational terms herein is intended only to describe particular embodiments and is not intended to limit the present application.
In the description of the present application, the term "and/or" is a expression for describing a logical relationship between objects, meaning that three relationships may exist, for example a and/or B, meaning: there are three cases of A, B, and both A and B. In addition, the character "/" herein generally indicates that the former and latter associated objects are in a logical relationship of "or".
In this application, terms such as "first" and "second" are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions.
Without further limitation, in this application, the use of "including," "comprising," "having," or other similar expressions in phrases and expressions of "including," "comprising," or "having," is intended to cover a non-exclusive inclusion, and such expressions do not exclude the presence of additional elements in a process, method, or article that includes the recited elements, such that a process, method, or article that includes a list of elements may include not only those elements but also other elements not expressly listed or inherent to such process, method, or article.
As is understood in the examination of the guidelines, the terms "greater than", "less than", "more than" and the like in this application are to be understood as excluding the number; the expressions "above", "below", "within" and the like are understood to include the present numbers. In addition, in the description of the embodiments of the present application, "a plurality" means two or more (including two), and expressions related to "a plurality" similar thereto are also understood, for example, "a plurality of groups", "a plurality of times", and the like, unless specifically defined otherwise.
In the description of the embodiments of the present application, spatially relative expressions such as "central," "longitudinal," "lateral," "length," "width," "thickness," "up," "down," "front," "back," "left," "right," "vertical," "horizontal," "vertical," "top," "bottom," "inner," "outer," "clockwise," "counterclockwise," "axial," "radial," "circumferential," and the like are used, and the indicated orientations or positional relationships are based on the orientations or positional relationships shown in the specific embodiments or drawings and are only for convenience of describing the specific embodiments of the present application or for the convenience of the reader, and do not indicate or imply that the device or component in question must have a specific position, a specific orientation, or be constructed or operated in a specific orientation and therefore should not be construed as limiting the embodiments of the present application.
Unless specifically stated or limited otherwise, the terms "mounted," "connected," "secured," and "disposed" used in the description of the embodiments of the present application are to be construed broadly. For example, the connection can be a fixed connection, a detachable connection, or an integrated arrangement; it can be a mechanical connection, an electrical connection, or a communication connection; they may be directly connected or indirectly connected through an intermediate; which may be communication within two elements or an interaction of two elements. Specific meanings of the above terms in the embodiments of the present application can be understood by those skilled in the art to which the present application pertains in accordance with specific situations.
Referring to fig. 1, the present embodiment provides a method for fast obtaining an electronic ticket number based on a high concurrency scenario, where the method is applied to a management device for fast obtaining an electronic ticket number based on a high concurrency scenario, the management device includes a number obtaining device, a number deducting device, a number recycling device, an inventory management device, a number sorting device, and a data recovery device, and the number obtaining device: for acquiring one or more available ticket numbers and holding them for a prescribed time until a ticket is deducted or released; the number deducting device comprises: after a certain identity is used for taking a number, the action of confirming the number deduction is carried out, and the action is usually generated along with the business of submitting an order, confirming payment and the like; the number recovery device: the number which is not deducted in time within the specified time after the number is fetched is recovered at regular time for other identities to fetch the number again; the inventory management device: the method is used for automatic warehousing when the buffer number in the current Redis is insufficient in inventory, and managing all inventory export and import services under the inventory main body; the number collating device: the method is used for sorting out the used number sections of each day at the end of each day, and the collected used number sections are used for the settlement system to collect, settle and check the main information of the ticket faces using the numbers. The data recovery apparatus: for data recovery when, in extreme cases, a Redis data file is lost. Specifically, the ticket picking method comprises the following steps:
step S101: taking out partial ticket number segments from the ticket number segment inventory data owned by the inventory main body, and storing the partial ticket number segments in a number segment cache table;
step S102: splitting the extracted ticket number segment into independent ticket numbers and inserting the independent ticket numbers into a queue to be numbered of Redis;
step S103: and after receiving the invoicing instruction, taking out the corresponding ticket number from the queue to be number-fetched of the Redis, binding the obtained ticket number with the identification ID in the invoicing instruction, returning the ticket number, and deducting the ticket number from the queue to be number-fetched of the Redis.
Redis (remote Dictionary Server), a remote Dictionary service, is an open source log-type and Key-Value database written in ANSI C language, supporting network, based on memory and persistent, and provides API of multiple languages. redis is a key-value storage system. Similar to Memcached, it supports relatively more stored value types, including string, list, set, zset, and hash. These data types all support push/pop, add/remove, and intersect union and difference, and richer operations, and these operations are all atomic. On this basis, redis supports various different ways of ordering. Like memcached, data is cached in memory to ensure efficiency. The difference is that the redis can periodically write updated data into a disk or write modification operation into an additional recording file, and master-slave synchronization is realized on the basis of the update.
The method comprises the steps that a part of ticket number segments of stored data of ticket number segments owned by a stock main body are taken out and placed into a ticket number pool to serve as hot data, namely ticket number data to be used in a short time, then the taken out ticket number segments are divided into independent ticket numbers and are inserted into a queue to be numbered of Redis, when an invoicing instruction enters a back-end system, namely after the invoicing instruction is received, the invoicing instruction carries a unique identification ID capable of judging the identity of the instruction, the corresponding ticket numbers are taken out from the queue to be numbered of Redis, the obtained ticket numbers and the identification ID in the invoicing instruction are bound in identity, the ticket numbers are returned, and meanwhile the ticket numbers are deducted from the queue to be numbered of Redis; by means of the relational data and Redis cluster, different number taking strategies are met, and number taking is guaranteed to be rapid and stable and to be performed orderly. The identification ID may be a user ID, a system identification, a service identification, or the like.
The step of "taking out the corresponding ticket number from the queue to be numbered of Redis" specifically includes the following steps:
and taking out the ticket number with the minimum number or the ticket number occupied by the ID in the billing information or the ticket numbers with the preset number from the queue to be numbered of Redis.
The number taking mode of the electronic ticket number comprises single number sequential number taking, number taking of a specified number and number taking of a specified number, and the corresponding ticket number can be taken out according to actual needs.
In some embodiments, the step of "binding the acquired ticket number with the identification ID in the ticket drawing instruction and returning the ticket number" specifically includes the following steps:
after the obtained ticket number is bound with the identification ID in the billing instruction, writing the ticket number bound with the identification ID into an identity occupation information set of Redis, and taking the score value as an unlocking timestamp;
the ticket number is returned from the identity occupancy information set of Redis.
And after taking out the corresponding ticket number from the queue to be numbered of the Redis, performing identity binding on the obtained ticket number and the identification ID in the billing instruction, downloading the ticket number bound with the identification ID into an identity occupation information set of the Redis, taking the score value of the identity occupation information set of the Redis as an unlocking timestamp, and returning the ticket number after the timestamp is reached. Wherein, the step of taking out the corresponding ticket number from the queue to be number-fetched of Redis after receiving the billing instruction specifically comprises the following steps:
after receiving the billing instruction, confirming whether a ticket number occupied by the identification ID in the billing instruction exists or not from the identity occupation information set of the Redis, and if so, returning the ticket number from the identity occupation information set of the Redis;
and if not, taking out the corresponding ticket number from the queue to be numbered of Redis.
After receiving the billing instruction, firstly confirming whether a ticket number occupied by the identification ID in the billing instruction exists in the identity occupation information set of the Redis, if so, returning the ticket number from the identity occupation information set of the Redis, and if not, taking out the corresponding ticket number from a queue to be numbered of the Redis.
Referring to fig. 2, in some embodiments, when the number recycling device recycles the unused number, the process includes the following steps:
step S201: inquiring whether a ticket number with an unlocking timestamp exceeding a current timestamp exists in an identity occupation information set of Redis;
if yes, go to step S202: the number information of the ticket number is updated to be unused,
step S203: removing the ticket number and the information of the bound identification ID in the identity occupation information set of Redis;
step S204: the ticket number is inserted into the priority queue of Redis.
And executing a ZRANGEBYSCORE command in a Redis identity occupation information set (ordered set) to search data with score value smaller than the current timestamp, namely inquiring whether a ticket number with unlocking timestamp exceeding the current timestamp exists in the identity occupation information set of Redis, and if the ticket number exists, executing an HSET command in Redis number state information (Hash) to update the number state of the current ticket number to be unused. Executing the ZREM command in the Redis identity occupancy information set (ordered set) removes information of the current identity and the current number. The ticket number that the ZADD command is currently to reclaim is executed in a Redis priority number fetch queue (ordered set). Subsequent number fetching requests will preferentially read the numbers in this queue. All Redis operation commands are compiled into Lua scripts and then executed at one time, and atomicity is guaranteed.
In some embodiments, the step "after receiving the billing instruction, take out the corresponding ticket number from the queue to be numbered of Redis" specifically includes the following steps:
after receiving the billing instruction, confirming whether a ticket number occupied by the identification ID in the billing instruction exists or not from the identity occupation information set of the Redis, and if so, returning the ticket number from the identity occupation information set of the Redis;
if not, judging whether the priority number taking queue of the Redis has a corresponding ticket number;
if so, taking out the corresponding ticket number from the priority number taking queue of Redis and returning the taken-out ticket number;
and if not, taking out the corresponding ticket number from the queue to be numbered of Redis.
Referring to fig. 3, in an embodiment, when the number fetching device fetches numbers in a certain number order, the following steps are performed:
step S301: executing a ZRANGE command in the Redis identity occupation information (ordered set) to search whether the current number taking identity has an occupied ticket number, if so, returning the ticket number, otherwise, executing the step S302.
Step S302: the ZPOPMIN command is executed in the Redis queue (ordered set) to fetch the smallest ticket number.
Step S303: and judging whether the result of the step S302 has a number, if so, returning the ticket number, otherwise, executing the step S304.
Step S304: the LPOP command is executed in a Redis queue of numbers to be fetched (doubly linked list) to fetch the ticket number with the smallest number.
Step S305: and judging whether the result of the step S304 has a number, if so, executing the step S306, otherwise, executing the step S307.
Step S306: and binding the acquired number with the current identity, executing a ZADD command, and writing data into an identity occupation information set (ordered set), wherein the score value is an unlocking timestamp. And finishing the number fetching action.
Step S307: and when the buffer number section in the current ticket number pool is insufficient, calling an inventory management device to automatically store the ticket number. If the warehousing is successful, returning to the step S304 to continue to execute the number fetching, otherwise, prompting that the inventory is insufficient.
All Redis operation commands of the S301-S306 are compiled into Lua scripts and then executed at one time, and atomicity is guaranteed.
Referring to fig. 4, in an embodiment, when the number fetching device fetches numbers at a specified number of numbers, the following steps are performed:
step S401: and executing a ZRANGE command in the Redis identity occupation information (ordered set) to search the number occupied by the current number taking identity.
Step S402: and subtracting the occupied number of the current identity from the number required by the current number fetching instruction, and calculating the remaining number to be fetched.
Step S403: and judging whether the number taking priority queue (ordered set) and the number queue to be taken (doubly linked list) in the ticket number pool have enough number for taking the number, if so, executing the step S404, otherwise, executing the step S407.
Step S404: the ZPOPMIN command is executed in the Redis queue (ordered set) to fetch the number.
Step S405: and executing the LPOP command in a Redis number queue (doubly linked list) to be fetched, and fetching the number.
Step S406: and binding the acquired number with the current identity, executing a ZADD command, and writing data into identity occupation information (an ordered set), wherein the score value is an unlocking timestamp. And finishing the number fetching action.
Step S407: and when the buffer number section in the current ticket number pool is insufficient, calling an inventory management device to automatically store the ticket number. And if the warehousing is successful, executing the step S404, otherwise, prompting that the inventory is insufficient.
All Redis operation commands of S401-S406 are compiled into Lua scripts and then executed at one time, and atomicity is guaranteed.
Referring to fig. 5, in an embodiment, when the number fetching device fetches a number at a designated number, the following steps are performed:
step S501: and executing a ZRANGE command in the Redis identity occupation information (ordered set) to find whether the current number taking identity occupies the number, if so, returning the number, otherwise, executing the step S302.
Step S502: the zrankegescrore command is executed in the Redis priority number fetch queue (ordered set) to fetch the specified number.
Step S503: and judging whether the result of the step S502 has a number, if so, returning the number, otherwise, executing the step S304.
Step S504: the LRANGE command is executed in the Redis queue of numbers to fetch (doubly linked list) to fetch the specified number.
Step S505: and judging whether the result of the step S504 has a number, if so, executing the step S306, otherwise, executing the step S307.
Step S506: and binding the acquired number with the current identity, executing a ZADD command, and writing data into identity occupation information (an ordered set), wherein the score value is an unlocking timestamp. And finishing the number fetching action.
Step S507: and when the buffer number section in the current ticket number pool is insufficient, calling an inventory management device to automatically store the ticket number. If the warehousing is successful, returning to the step S304 to continue to execute the number fetching, otherwise, prompting that the number does not exist.
All Redis operation commands of the S501-S506 are compiled into Lua scripts and then executed at one time, and atomicity is guaranteed.
Referring to fig. 6, in some embodiments, the process of the number deduction device in the step of assigning the number deduction includes the following steps:
step S601: and executing a ZRANGE command in the Redis identity occupation information (ordered set) to find whether the current number taking identity occupies the number, if so, executing a step S602, otherwise, prompting that the ticket deduction identity is not consistent.
Step S602: executing the HSET command in the Redis number status information (Hash) updates the current number status to a pre-deduct ticket.
Step S603: executing the ZREM command in the Redis identity occupancy information (ordered set) removes information of the current identity and the current number.
Step S604: the ZADD command is executed in Redis daily usage summary information (ordered set) to insert the current date and current number.
Step S605: a callback thread is created in the thread pool using the thread pool, identifying that the thread is executed when the current database transaction successfully commits.
Step S606: when the database transaction is successfully committed, an HSET command is executed in the Redis number status information (Hash) to update the current number status to used.
All Redis operation commands of the S601-S604 are compiled into Lua scripts and then executed at one time, and atomicity is guaranteed.
Referring to fig. 7, in some embodiments, the inventory management device performs automatic warehousing when the stock of the ticket number pool is insufficient, and specifically, before the step "take out the corresponding ticket number from the queue to be numbered of Redis", the step includes an automatic warehousing step:
step S701: judging whether a ticket number exists in a queue to be numbered of Redis;
if yes, go to step S702: taking out the corresponding ticket number from a queue to be numbered of Redis;
if not, go to step S703: judging whether a ticket number exists in the stock main body;
if yes, go to step S704: deducting ticket number sections with preset number from the stock main body;
step S705: and the deducted ticket number segments with the preset number are disassembled and inserted into a queue to be numbered of Redis.
Judging whether enough number section inventory exists under the inventory main body in the database, and if not, prompting the failure of warehousing; if yes, the ticket number pool defaults to the automatic warehousing number of 100 each time, deducts 100 numbers from the warehousing main body, and updates the numbers to the database to obtain buffered ticket number segments N to M to be warehoused. The data of the ticket number segments from N to M are stored in a number segment buffer table (namely a ticket number pool) in a database, and a unique identifier is generated for the buffer number segment. And (3) splitting the ticket number segment of the number segment from N to M into independent numbers, sequentially inserting all ticket numbers into a queue (a bidirectional linked list) to be numbered of Redis, and simultaneously inserting each ticket number and a corresponding buffer number segment into a Hash table of Redis, so that the ticket number pool is put into storage. All Redis operation commands are compiled into Lua scripts and then executed at one time, and atomicity is guaranteed. And ensuring that enough ticket numbers can be issued in the queue to be numbered of Redis.
Referring to fig. 8, in some embodiments, when the finishing device performs the daily usage number segment summary at the end of a day, the method specifically includes the following steps:
step S801: the zrankegescrore command is executed in the Redis daily usage summary information (ordered set) to look up score as data of the current day, and if it exists, step S802 is executed.
Step S802: all the used numbers are grouped according to the stock main body and used for confirming the daily use condition of each stock main body.
Step S803: and calculating in a memory, sequencing the numbers of each hash, and combining the numbers which can be combined into a plurality of number segments after sequencing.
Step S804: and storing the combined number segments, the corresponding stock main bodies and the use dates into a daily use table of the database.
Referring to fig. 9, in some embodiments, the inventory management device warehousing the total inventory of the inventory entity specifically includes the following steps:
step S901: when a new ticket number segment is stored in the stock main body, judging whether a number which is repeated in the stored ticket number segment exists in the current stock main body or not;
if yes, prompting failure of warehousing;
if not, go to step S902: judging whether repeated numbers exist in the queue to be numbered, the queue with the priority number taking and the identity occupation information set of the Redis;
if yes, prompting failure of warehousing;
if not, go to step S903: a new ticket number segment is inserted into the stock body.
Judging whether the number segment to be put in storage has a repeated number in the database under the current stock main body, if not, executing the next step; and if so, prompting failure of warehousing. Judging whether repeated numbers exist in the number segments to be put in storage under the waiting number queue, the priority number queue and the identity occupation information set in Redis, if not, executing the next step: inserting the number segment to be put in storage into a database, and finishing putting in storage; and if so, prompting failure of warehousing. Duplicate ticket numbers are prevented from being deposited into the inventory body.
Referring to fig. 10, in some embodiments, when the data recovery apparatus performs data recovery, the specific process includes the following steps:
step S1001: inquiring all ticket numbers once entering the number segment cache table;
step S1002: grouping all tickets which once enter the number segment cache table according to the stock main body;
step S1003: traversing each ticket number in each group, and calling a ticket number service interface to inquire the service data corresponding to each ticket number;
if the service data exists, the ticket number is not processed;
if there is no service data, step S1004 is executed: the ticket number is inserted into the queue of priority numbering for Redis.
And inquiring number segment data of the ticket number pool which is put in storage in a number segment buffer table of the database, wherein the numbers are data which need to be recovered. And grouping all used numbers according to the inventory main body, and performing service data query according to the inventory main body. Traversing each ticket number in the memory, calling a service interface related to the ticket number, inquiring service data corresponding to the ticket number, if the service data exists, indicating that the service data is used without processing, and if the service data does not exist, storing the service data in a ticket number pool again, executing a ZADD command in Redis, and inserting the ZADD command into a priority number taking queue (ordered set).
Referring to fig. 11, in another embodiment, a storage medium 110, the storage medium 110 storing a computer program, the computer program being executed by a processor to perform the steps of the method:
taking out partial ticket number segments from the ticket number segment inventory data owned by the inventory main body, and storing the partial ticket number segments in a number segment cache table;
splitting the extracted ticket number segment into independent ticket numbers and inserting the independent ticket numbers into a queue to be numbered of Redis;
and after receiving the invoicing instruction, taking out the corresponding ticket number from the queue to be number-fetched of the Redis, binding the obtained ticket number with the identification ID in the invoicing instruction, returning the ticket number, and deducting the ticket number from the queue to be number-fetched of the Redis.
Redis (remote Dictionary Server), a remote Dictionary service, is an open source log-type and Key-Value database written in ANSI C language, supporting network, based on memory and persistent, and provides API of multiple languages. redis is a key-value storage system. Similar to Memcached, it supports relatively more stored value types, including string, list, set, zset, and hash. These data types all support push/pop, add/remove, and intersect union and difference, and richer operations, and these operations are all atomic. On this basis, redis supports various different ways of ordering. Like memcached, data is cached in memory to ensure efficiency. The difference is that the redis can periodically write updated data into a disk or write modification operation into an additional recording file, and master-slave synchronization is realized on the basis of the update.
The method comprises the steps that a part of ticket number segments of stored data of ticket number segments owned by a stock main body are taken out and placed into a ticket number pool to serve as hot data, namely ticket number data to be used in a short time, then the taken out ticket number segments are divided into independent ticket numbers and are inserted into a queue to be numbered of Redis, when an invoicing instruction enters a back-end system, namely after the invoicing instruction is received, the invoicing instruction carries a unique identification ID capable of judging the identity of the instruction, the corresponding ticket numbers are taken out from the queue to be numbered of Redis, the obtained ticket numbers and the identification ID in the invoicing instruction are bound in identity, the ticket numbers are returned, and meanwhile the ticket numbers are deducted from the queue to be numbered of Redis; by means of the relational data and Redis cluster, different number taking strategies are met, and number taking is guaranteed to be rapid and stable and to be performed orderly.
The step of "taking out the corresponding ticket number from the queue to be numbered of Redis" specifically includes the following steps:
and taking out the ticket number with the minimum number or the ticket number occupied by the ID in the billing information or the ticket numbers with the preset number from the queue to be numbered of Redis.
The number taking mode of the electronic ticket number comprises single number sequential number taking, number taking of a specified number and number taking of a specified number, and the corresponding ticket number can be taken out according to actual needs.
In some embodiments, the step of "binding the acquired ticket number with the identification ID in the ticket drawing instruction and returning the ticket number" specifically includes the following steps:
after the obtained ticket number is bound with the identification ID in the billing instruction, writing the ticket number bound with the identification ID into an identity occupation information set of Redis, and taking the score value as an unlocking timestamp;
the ticket number is returned from the identity occupancy information set of Redis.
And after taking out the corresponding ticket number from the queue to be numbered of the Redis, performing identity binding on the obtained ticket number and the identification ID in the billing instruction, downloading the ticket number bound with the identification ID into an identity occupation information set of the Redis, taking the score value of the identity occupation information set of the Redis as an unlocking timestamp, and returning the ticket number after the timestamp is reached. Wherein, the step of taking out the corresponding ticket number from the queue to be number-fetched of Redis after receiving the billing instruction specifically comprises the following steps:
after receiving the billing instruction, confirming whether a ticket number occupied by the identification ID in the billing instruction exists or not from the identity occupation information set of the Redis, and if so, returning the ticket number from the identity occupation information set of the Redis;
and if not, taking out the corresponding ticket number from the queue to be numbered of Redis.
After receiving the billing instruction, firstly confirming whether a ticket number occupied by the identification ID in the billing instruction exists in the identity occupation information set of the Redis, if so, returning the ticket number from the identity occupation information set of the Redis, and if not, taking out the corresponding ticket number from a queue to be numbered of the Redis.
In some embodiments, when the number recycling device recycles the unused number, the process portion comprises the following steps:
inquiring whether a ticket number with an unlocking timestamp exceeding a current timestamp exists in an identity occupation information set of Redis;
if yes, the number information of the ticket number is updated to be unused,
removing the ticket number and the information of the bound identification ID in the identity occupation information set of Redis;
the ticket number is inserted into the priority queue of Redis.
And executing a ZRANGEBYSCORE command in a Redis identity occupation information set (ordered set) to search data with score value smaller than the current timestamp, namely inquiring whether a ticket number with unlocking timestamp exceeding the current timestamp exists in the identity occupation information set of Redis, and if the ticket number exists, executing an HSET command in Redis number state information (Hash) to update the number state of the current ticket number to be unused. Executing the ZREM command in the Redis identity occupancy information set (ordered set) removes information of the current identity and the current number. The ticket number that the ZADD command is currently to reclaim is executed in a Redis priority number fetch queue (ordered set). Subsequent number fetching requests will preferentially read the numbers in this queue. All Redis operation commands are compiled into Lua scripts and then executed at one time, and atomicity is guaranteed.
In some embodiments, the step "after receiving the billing instruction, take out the corresponding ticket number from the queue to be numbered of Redis" specifically includes the following steps:
after receiving the billing instruction, confirming whether a ticket number occupied by the identification ID in the billing instruction exists or not from the identity occupation information set of the Redis, and if so, returning the ticket number from the identity occupation information set of the Redis;
if not, judging whether the priority number taking queue of the Redis has a corresponding ticket number;
if so, taking out the corresponding ticket number from the priority number taking queue of Redis and returning the taken-out ticket number;
and if not, taking out the corresponding ticket number from the queue to be numbered of Redis.
In one embodiment, when the number fetching device fetches numbers in a certain number order, the following steps are performed:
executing a ZRANGE command in the Redis identity occupation information (ordered set) to search whether the current number taking identity has an occupied ticket number, if so, returning the ticket number, otherwise, executing the step S302.
The ZPOPMIN command is executed in the Redis queue (ordered set) to fetch the smallest ticket number.
Judging whether the priority number taking queue has a number, if so, returning the ticket number, otherwise, executing LPOP command in the Redis number taking queue (bidirectional linked list) to take out the ticket number with the minimum number.
And judging whether the number queue to be subjected to number fetching has a number, if so, binding the obtained number with the current identity, executing a ZADD command to write data into an identity occupation information set (ordered set), wherein the score value is an unlocking timestamp. And finishing the number fetching action.
Otherwise, the buffer number section in the current ticket number pool is insufficient, and the inventory management device is called to automatically store the ticket number section. And if the warehousing is successful, continuously executing number fetching, otherwise, prompting that the inventory is insufficient.
Compiling all Redis operation commands of the steps into Lua scripts and then executing the Lua scripts once, so that atomicity is guaranteed.
In one embodiment, when the number fetching device fetches numbers at a specified number of numbers, the following steps are performed:
and executing a ZRANGE command in the Redis identity occupation information (ordered set) to search the number occupied by the current number taking identity.
And subtracting the occupied number of the current identity from the number required by the current number fetching instruction, and calculating the remaining number to be fetched.
And judging whether the number taking priority queue (ordered set) and the number queue to be taken (bidirectional linked list) in the ticket number pool have enough number to take the number, if so, executing a ZOPMIN command in a Redis number taking priority queue (ordered set) and taking out the number.
And executing the LPOP command in a Redis number queue (doubly linked list) to be fetched, and fetching the number.
And binding the acquired number with the current identity, executing a ZADD command, and writing data into identity occupation information (an ordered set), wherein the score value is an unlocking timestamp. And finishing the number fetching action.
Otherwise, if the buffer number section in the current ticket number pool is insufficient, the inventory management device is called to automatically store the ticket number section. If the warehousing is successful, executing an LPOP command in a Redis number queue (a bidirectional linked list) to be fetched, and fetching a number; otherwise, the stock shortage is prompted.
Compiling all Redis operation commands of the steps into Lua scripts and then executing the Lua scripts once, so that atomicity is guaranteed.
In one embodiment, when the number fetching device fetches a number at a designated number, the following steps are performed:
and executing a ZRANGE command in the Redis identity occupation information (ordered set) to find whether the current number taking identity occupies the number, if so, returning the number, otherwise, executing the step S302.
The zrankegescrore command is executed in the Redis priority number fetch queue (ordered set) to fetch the specified number.
And judging whether the number is in the Redis number-taking priority queue or not, if so, returning the number, otherwise, executing an LRANGE command in the Redis number-taking waiting queue (a double linked list) to take out the specified number.
And judging whether the number of the code queue to be subjected to number fetching in the Redis step exists, if so, binding the obtained number with the current identity, executing a ZADD command to write data into identity occupation information (ordered set), wherein the score value is an unlocking timestamp. And finishing the number fetching action. Otherwise, the buffer number section in the current ticket number pool is insufficient, and the inventory management device is called to automatically store the ticket number section. And if the warehousing is successful, continuing to execute the number fetching, otherwise, prompting that the number does not exist.
Compiling all Redis operation commands of the steps into Lua scripts and then executing the Lua scripts once, so that atomicity is guaranteed.
In some embodiments, the process of the number deduction device in the step of assigning the number deduction comprises the following steps:
and executing a ZRANGE command in the Redis identity occupation information (ordered set) to search whether the current number taking identity occupies the number, and if so, executing an HSET command in Redis number state information (Hash) to update the current number state into a pre-deduction ticket. Otherwise, the deduction identity is not matched.
Executing the HSET command in the Redis number status information (Hash) updates the current number status to a pre-deduct ticket.
Executing the ZREM command in the Redis identity occupancy information (ordered set) removes information of the current identity and the current number.
The ZADD command is executed in Redis daily usage summary information (ordered set) to insert the current date and current number.
A callback thread is created in the thread pool using the thread pool, identifying that the thread is executed when the current database transaction successfully commits.
When the database transaction is successfully committed, an HSET command is executed in the Redis number status information (Hash) to update the current number status to used.
Compiling all Redis operation commands of the steps into Lua scripts and then executing the Lua scripts once, so that atomicity is guaranteed.
In some embodiments, the inventory management device performs automatic warehousing when the stock of the ticket number pool is insufficient, and specifically, before the step "take out the corresponding ticket number from the queue to be numbered of Redis", the method includes the automatic warehousing step:
judging whether a ticket number exists in a queue to be numbered of Redis;
if yes, taking out the corresponding ticket number from the queue to be numbered of Redis;
if not, judging whether a ticket number exists in the stock main body;
if yes, deducting ticket number sections with preset number from the stock main body;
and the deducted ticket number segments with the preset number are disassembled and inserted into a queue to be numbered of Redis.
Judging whether enough number section inventory exists under the inventory main body in the database, and if not, prompting the failure of warehousing; if yes, the ticket number pool defaults to the automatic warehousing number of 100 each time, deducts 100 numbers from the warehousing main body, and updates the numbers to the database to obtain buffered ticket number segments N to M to be warehoused. The data of the ticket number segments from N to M are stored in a number segment buffer table (namely a ticket number pool) in a database, and a unique identifier is generated for the buffer number segment. And (3) splitting the ticket number segment of the number segment from N to M into independent numbers, sequentially inserting all ticket numbers into a queue (a bidirectional linked list) to be numbered of Redis, and simultaneously inserting each ticket number and a corresponding buffer number segment into a Hash table of Redis, so that the ticket number pool is put into storage. All Redis operation commands are compiled into Lua scripts and then executed at one time, and atomicity is guaranteed. And ensuring that enough ticket numbers can be issued in the queue to be numbered of Redis.
In some embodiments, when the finishing device performs daily usage number segment summarization at the end of a day, the method specifically includes the following steps:
the zrankegescrore command is executed in Redis daily usage summary information (ordered set) to look up score for data of the current day.
If the used numbers exist, all the used numbers are grouped according to the stock main bodies and used for confirming the daily use condition of each stock main body.
And calculating in a memory, sequencing the numbers of each hash, and combining the numbers which can be combined into a plurality of number segments after sequencing.
And storing the combined number segments, the corresponding stock main bodies and the use dates into a daily use table of the database.
Referring to fig. 9, in some embodiments, the inventory management device enters the inventory entity into the inventory, which specifically includes the following steps:
when a new ticket number segment is stored in the stock main body, judging whether a number which is repeated in the stored ticket number segment exists in the current stock main body or not;
if yes, prompting failure of warehousing;
if not, judging whether repeated numbers exist in the to-be-number-taking queue, the priority number-taking queue and the identity occupation information set of the Redis;
if yes, prompting failure of warehousing;
if not, a new ticket number segment is inserted into the inventory body.
Judging whether the number segment to be put in storage has a repeated number in the database under the current stock main body, if not, executing the next step; and if so, prompting failure of warehousing. Judging whether repeated numbers exist in the number segments to be put in storage under the waiting number queue, the priority number queue and the identity occupation information set in Redis, if not, executing the next step: inserting the number segment to be put in storage into a database, and finishing putting in storage; and if so, prompting failure of warehousing. Duplicate ticket numbers are prevented from being deposited into the inventory body.
In some embodiments, when the data recovery device performs data recovery, the specific process includes the following steps:
inquiring all ticket numbers once entering the number segment cache table;
grouping all tickets which once enter the number segment cache table according to the stock main body;
traversing each ticket number in each group, and calling a ticket number service interface to inquire the service data corresponding to each ticket number;
if the service data exists, the ticket number is not processed;
and if no service data exists, inserting the ticket number into a priority number queue of Redis.
And inquiring number segment data of the ticket number pool which is put in storage in a number segment buffer table of the database, wherein the numbers are data which need to be recovered. And grouping all used numbers according to the inventory main body, and performing service data query according to the inventory main body. Traversing each ticket number in the memory, calling a service interface related to the ticket number, inquiring service data corresponding to the ticket number, if the service data exists, indicating that the service data is used without processing, and if the service data does not exist, storing the service data in a ticket number pool again, executing a ZADD command in Redis, and inserting the ZADD command into a priority number taking queue (ordered set).
Finally, it should be noted that, although the above embodiments have been described in the text and drawings of the present application, the scope of the patent protection of the present application is not limited thereby. All technical solutions which are generated by replacing or modifying the equivalent structure or the equivalent flow according to the contents described in the text and the drawings of the present application, and which are directly or indirectly implemented in other related technical fields, are included in the scope of protection of the present application.
Claims (10)
1. A method for quickly taking an electronic ticket number based on a high concurrency scene is characterized by comprising the following steps:
taking out partial ticket number segments from the ticket number segment inventory data owned by the inventory main body, and storing the partial ticket number segments in a number segment cache table;
splitting the extracted ticket number segment into independent ticket numbers and inserting the independent ticket numbers into a queue to be numbered of Redis;
and after receiving the invoicing instruction, taking out the corresponding ticket number from the queue to be number-fetched of the Redis, binding the obtained ticket number with the identification ID in the invoicing instruction, returning the ticket number, and deducting the ticket number from the queue to be number-fetched of the Redis.
2. The electronic ticket number rapid ticket taking method based on the high concurrency scene as claimed in claim 1, wherein the step of "binding the acquired ticket number with the identification ID in the ticket issuing instruction and then returning the ticket number" specifically comprises the following steps:
after the obtained ticket number is bound with the identification ID in the billing instruction, writing the ticket number bound with the identification ID into an identity occupation information set of Redis, and taking the score value as an unlocking timestamp;
the ticket number is returned from the identity occupancy information set of Redis.
3. The electronic ticket number rapid ticket taking method based on the high concurrency scene as claimed in claim 2, wherein the step of taking out the corresponding ticket number from the queue to be taken by the Redis after receiving the ticket making instruction specifically comprises the following steps:
after receiving the billing instruction, confirming whether a ticket number occupied by the identification ID in the billing instruction exists or not from the identity occupation information set of the Redis, and if so, returning the ticket number from the identity occupation information set of the Redis;
and if not, taking out the corresponding ticket number from the queue to be numbered of Redis.
4. The electronic ticket number rapid ticket collecting method based on the high concurrency scene as claimed in claim 2, further comprising the steps of:
inquiring whether a ticket number with an unlocking timestamp exceeding a current timestamp exists in an identity occupation information set of Redis;
if yes, the number information of the ticket number is updated to be unused,
removing the ticket number and the information of the bound identification ID in the identity occupation information set of Redis;
the ticket number is inserted into the priority queue of Redis.
5. The electronic ticket number rapid ticket taking method based on the high concurrency scene as claimed in claim 4, wherein the step of taking out the corresponding ticket number from the queue to be taken by Redis after receiving the ticket issuing command specifically comprises the following steps:
after receiving the billing instruction, confirming whether a ticket number occupied by the identification ID in the billing instruction exists or not from the identity occupation information set of the Redis, and if so, returning the ticket number from the identity occupation information set of the Redis;
if not, judging whether the priority number taking queue of the Redis has a corresponding ticket number;
if so, taking out the corresponding ticket number from the priority number taking queue of Redis and returning the taken-out ticket number;
and if not, taking out the corresponding ticket number from the queue to be numbered of Redis.
6. The electronic ticket number rapid ticket taking method based on the high concurrency scene as claimed in claim 1, wherein before said step of "taking out the corresponding ticket number from the queue to be taken by Redis" comprises an automatic entering step:
judging whether a ticket number exists in a queue to be numbered of Redis;
if yes, taking out the corresponding ticket number from the queue to be numbered of Redis;
if not, judging whether a ticket number exists in the stock main body;
if yes, deducting ticket number sections with preset number from the stock main body;
and the deducted ticket number segments with the preset number are scattered and inserted into a queue to be numbered of Redis.
7. The electronic ticket number rapid ticket collecting method based on the high concurrency scenario as claimed in any one of claims 1 to 6, wherein said step of "taking out the corresponding ticket number from the queue to be taken by Redis" specifically comprises the following steps:
and taking out the ticket number with the minimum number or the ticket number occupied by the ID in the billing information or the ticket numbers with the preset number from the queue to be numbered of Redis.
8. The electronic ticket number rapid ticket collecting method based on the high concurrency scene as claimed in claim 1, further comprising the steps of:
when a new ticket number segment is stored in the stock main body, judging whether a number which is repeated in the stored ticket number segment exists in the current stock main body or not;
if yes, prompting failure of warehousing;
if not, judging whether repeated numbers exist in the to-be-number-taking queue, the priority number-taking queue and the identity occupation information set of the Redis;
if yes, prompting failure of warehousing;
if not, a new ticket number segment is inserted into the inventory body.
9. The electronic ticket number rapid ticket collecting method based on the high concurrency scene as claimed in claim 1, further comprising the steps of:
inquiring all ticket numbers once entering the number segment cache table;
grouping all tickets which once enter the number segment cache table according to the stock main body;
traversing each ticket number in each group, and calling a ticket number service interface to inquire the service data corresponding to each ticket number;
if the service data exists, the ticket number is not processed;
and if no service data exists, inserting the ticket number into a priority number queue of Redis.
10. A storage medium storing a computer program, characterized in that the computer program, when being executed by a processor, is adapted to carry out the steps of the method according to any one of claims 1-9.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111646085.7A CN114331576A (en) | 2021-12-30 | 2021-12-30 | Electronic ticket number rapid ticket taking method based on high concurrency scene and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111646085.7A CN114331576A (en) | 2021-12-30 | 2021-12-30 | Electronic ticket number rapid ticket taking method based on high concurrency scene and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114331576A true CN114331576A (en) | 2022-04-12 |
Family
ID=81017970
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111646085.7A Pending CN114331576A (en) | 2021-12-30 | 2021-12-30 | Electronic ticket number rapid ticket taking method based on high concurrency scene and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114331576A (en) |
Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2009026819A1 (en) * | 2007-08-23 | 2009-03-05 | Huawei Technologies Co., Ltd. | A method and device for merging bill and saving the state of the buffer queue |
| CN103886079A (en) * | 2014-03-26 | 2014-06-25 | 北京京东尚科信息技术有限公司 | Data processing method and system |
| CN104809510A (en) * | 2015-05-21 | 2015-07-29 | 武汉大学 | Building method of ticket pool middleware for providing ticket support, ticket purchasing and ticket locking methods |
| CN106156864A (en) * | 2015-03-27 | 2016-11-23 | 天脉聚源（北京）科技有限公司 | A kind of method and system of big quantity ticket booking |
| CN107229572A (en) * | 2016-03-25 | 2017-10-03 | 北京京东尚科信息技术有限公司 | Obtain the method and system of information |
| CN108133399A (en) * | 2016-11-30 | 2018-06-08 | 北京京东尚科信息技术有限公司 | The second of high concurrent fast-response kills the method, apparatus and system that inventory precisely reduces |
| WO2019128535A1 (en) * | 2017-12-25 | 2019-07-04 | 腾讯科技（深圳）有限公司 | Message management method and device, and storage medium |
| WO2020192063A1 (en) * | 2019-03-28 | 2020-10-01 | 苏宁云计算有限公司 | Caching-based method and system for sales locking |
| CA3162740A1 (en) * | 2019-11-26 | 2021-06-03 | 10353744 Canada Ltd. | Traffic switching methods and devices based on multiple active data centers |
| CN112988812A (en) * | 2021-03-10 | 2021-06-18 | 京东数字科技控股股份有限公司 | Inventory data processing method, device, equipment and storage medium |
| CN113282626A (en) * | 2021-05-31 | 2021-08-20 | 平安国际智慧城市科技股份有限公司 | Redis-based data caching method and device, computer equipment and storage medium |
-
2021
- 2021-12-30 CN CN202111646085.7A patent/CN114331576A/en active Pending
Patent Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2009026819A1 (en) * | 2007-08-23 | 2009-03-05 | Huawei Technologies Co., Ltd. | A method and device for merging bill and saving the state of the buffer queue |
| CN103886079A (en) * | 2014-03-26 | 2014-06-25 | 北京京东尚科信息技术有限公司 | Data processing method and system |
| CN106156864A (en) * | 2015-03-27 | 2016-11-23 | 天脉聚源（北京）科技有限公司 | A kind of method and system of big quantity ticket booking |
| CN104809510A (en) * | 2015-05-21 | 2015-07-29 | 武汉大学 | Building method of ticket pool middleware for providing ticket support, ticket purchasing and ticket locking methods |
| CN107229572A (en) * | 2016-03-25 | 2017-10-03 | 北京京东尚科信息技术有限公司 | Obtain the method and system of information |
| CN108133399A (en) * | 2016-11-30 | 2018-06-08 | 北京京东尚科信息技术有限公司 | The second of high concurrent fast-response kills the method, apparatus and system that inventory precisely reduces |
| WO2019128535A1 (en) * | 2017-12-25 | 2019-07-04 | 腾讯科技（深圳）有限公司 | Message management method and device, and storage medium |
| WO2020192063A1 (en) * | 2019-03-28 | 2020-10-01 | 苏宁云计算有限公司 | Caching-based method and system for sales locking |
| CA3162740A1 (en) * | 2019-11-26 | 2021-06-03 | 10353744 Canada Ltd. | Traffic switching methods and devices based on multiple active data centers |
| CN112988812A (en) * | 2021-03-10 | 2021-06-18 | 京东数字科技控股股份有限公司 | Inventory data processing method, device, equipment and storage medium |
| CN113282626A (en) * | 2021-05-31 | 2021-08-20 | 平安国际智慧城市科技股份有限公司 | Redis-based data caching method and device, computer equipment and storage medium |
Non-Patent Citations (2)
| Title |
|---|
| 王玉涛: ""高性能的 Web 服务及其在机票系统中的应用研究"", 《中国优秀硕士学位论文全文数据库信息科技辑》 * |
| 钟林森: "《分布式中间件技术实战》", 31 January 2020, 机械工业出版社 * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11080260B2 (en) | Concurrent reads and inserts into a data structure without latching or waiting by readers | |
| CN106886375B (en) | The method and apparatus of storing data | |
| US8682941B2 (en) | Database apparatus | |
| US7668851B2 (en) | Lockless hash table lookups while performing key update on hash table element | |
| US8868531B2 (en) | Concurrent access methods for tree data structures | |
| EP3418883B1 (en) | Apparatus and method for read optimized bulk data storage | |
| CN107608773B (en) | Task concurrent processing method and device and computing equipment | |
| TW200849097A (en) | Transactional memory using buffered writes and enforced serialization order | |
| US11321302B2 (en) | Computer system and database management method | |
| CN102955792A (en) | Method for implementing transaction processing for real-time full-text search engine | |
| CN105183915B (en) | Reduce the multi version management method of index maintenance expense | |
| CN109670975B (en) | Method, medium, and electronic device for generating a single number in a computer system | |
| JP5075653B2 (en) | Database management method, database management apparatus, database management program, and database system | |
| CN111316255B (en) | Data storage system and method for providing a data storage system | |
| US8495041B2 (en) | Data structure, computer system, method and computer program for searching database | |
| CN106682139A (en) | Method and system for achieving HBase multi-condition query based on Solr | |
| CN114282074A (en) | Database operation method, device, equipment and storage medium | |
| CN103207872A (en) | Real-time indexing method and server | |
| CN114331576A (en) | Electronic ticket number rapid ticket taking method based on high concurrency scene and storage medium | |
| US9652766B1 (en) | Managing data stored in memory locations having size limitations | |
| CN103177026A (en) | Data management method and data management system | |
| CN115469810A (en) | Data acquisition method, device, equipment and storage medium | |
| CN109492020A (en) | A kind of data cache method, device, electronic equipment and storage medium | |
| CN109213760A (en) | The storage of high load business and search method of non-relation data storage | |
| CN103514185A (en) | Method and device for managing access to database files in multiple updated areas of navigation map |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |