CN113129116A - High-performance bill-of-lading and rush-purchasing method and system - Google Patents
High-performance bill-of-lading and rush-purchasing method and system Download PDFInfo
- Publication number
- CN113129116A CN113129116A CN202110543772.XA CN202110543772A CN113129116A CN 113129116 A CN113129116 A CN 113129116A CN 202110543772 A CN202110543772 A CN 202110543772A CN 113129116 A CN113129116 A CN 113129116A
- Authority
- CN
- China
- Prior art keywords
- module
- robbery
- inventory
- order
- user
- 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
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
- G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
- G06Q30/0635—Processing of requisition or of purchase orders
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
- G06Q30/0605—Supply or demand aggregation
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
The invention provides a high-performance bill-picking and rush-purchasing method, which comprises the following steps: step S1, setting the commodity detail page into a staticizing page; step S2, setting a current limiting threshold value by adopting a token bucket current limiter algorithm, and limiting the current of the server interface; step S3, limiting the flow of a large number of robbery requests in a single IP short time; step S4, judging commodity stock from the cache of the server; step S5, adding the order in the pre-robbery state into a message queue; step S6, asynchronously processing the message queue, sequentially executing deduction and updating the order; step S7, the front end of the commodity detail page periodically and circularly queries the order state and feeds back the result of the robbery to the user; step S8, the user pays the order of successful purchase-robbing; asynchronously detecting overtime unpaid orders and returning the inventory of the goods to the database; the correctness of the data of the first-aid purchase is ensured.
Description
Technical Field
The invention relates to the technical field of computer communication, in particular to a high-performance bill-of-lading and rush-purchasing method and a system thereof.
Background
The second killing system mainly solves three problems: one, instantaneous high concurrent access. The shopping is different from the ordinary electric commerce sales, the flow is relatively even, and the flow is not particularly outstanding although the flow has wave crests and wave troughs. The first-aid purchase is a marketing activity carried out at a specific time point, and before the first-aid purchase is started, a user continuously refreshes a page to obtain a purchase button; and (4) concentrating and purchasing at the same time when the first-time purchase starts. And secondly, data correctness. After all, the first-time purchase is a purchase behavior, complex processes such as purchasing, inventory deduction, payment and the like are needed, and in the process, the correctness of data is guaranteed, and the occurrence of over-selling (selling amount exceeds the inventory) is prevented. And thirdly, cheating is prevented. Whether the purchase of train tickets or the promotion of low-price commodities, certain customers do not want to buy all commodities, and the fairness is ensured as much as possible. The technical users are required to be limited from bypassing websites when buying train tickets, moon cake events of Ali Baba and the like through ticket buying plug-ins, and poor benefits are obtained through technical means.
The second-killing and first-aid-purchasing is a most representative use scene in hot spot deduction, the instant request quantity brought by the second-killing is very large, millions of people simultaneously and online first-aid-purchase the same commodity, and at the moment, the huge concurrency quantity is brought. The accuracy requirement of second killing on deduction is high, and the second killing is a marketing means in most scenes, so that the second killing attracts users to achieve the purposes of refreshing, draining and the like. If a large area of oversell occurs, it is a significant loss.
The token bucket algorithm mechanism: when the network device measures whether the flow exceeds the rated bandwidth, a token bucket needs to be checked, a certain number of tokens are placed in the token bucket, one token allows an interface to send or receive 1-bit data (sometimes 1 Byte data), and when the interface passes through the 1-bit data, one token is removed from the bucket. Any traffic is considered to exceed the nominal bandwidth when there are no tokens in the bucket, and data may only pass through the interface when there are tokens in the bucket. Tokens in the token bucket can not only be removed, but also can be added in the past, so in order to ensure that the interface has data to pass through at any time, the tokens must be added into the bucket continuously, and therefore, the speed of adding the tokens into the bucket determines the speed of the data passing through the interface. Thus, the bandwidth of the user traffic is controlled by controlling the rate at which tokens are added to the token bucket. And the set rate at which this user transmits data is called the Committed Information Rate (CIR), typically in seconds. For example, the bandwidth of the user is set to be 1000 bits per second, and only 1000 tokens are required to be added into the bucket every second.
Disclosure of Invention
In order to overcome the problems, the invention aims to provide a high-performance bill-drawing and robbery-purchasing method which can support a high-concurrency second killing scene, can protect stock from being overflowed and ensures correct data.
The invention is realized by adopting the following scheme: a high performance bill of lading first order method, said method comprising the steps of:
step S1, setting the commodity detail page into a staticizing page;
step S2, setting a current limiting threshold value by adopting a token bucket current limiter algorithm, and limiting the current of the server interface;
step S3, limiting the flow of a large number of robbery requests in a single IP short time;
step S4, judging commodity stock from the cache of the server;
step S5, adding the order in the pre-robbery state into a message queue;
step S6, asynchronously processing the message queue, sequentially executing deduction and updating the order;
step S7, the front end of the commodity detail page periodically and circularly queries the order state and feeds back the result of the robbery to the user;
step S8, the user pays the order of successful purchase-robbing; asynchronously detecting outstanding orders over time and returning inventory to the database.
Further, a step S11 is included between the step S1 and the step S2, in which the robbery request is randomly discarded according to the probability, that is, if the inventory of the goods only occupies 1% of the number of users according to the estimated access amount of the robbery activity, the request in a certain proportion is randomly discarded; the proportion is set to 40-50%; since the popular goods are often subjected to non-manual shopping by using the program means, if all the goods are ordered according to the sequence, the shopping through the program means is faster than that of the normal user, and therefore, a certain proportion of requests are discarded randomly.
Further, a step S51 is included between the step S5 and the step S6, and the order information of the pre-preemptive purchase status is returned to the commodity detail page first to display the user preemptive purchase, so that the front end of the commodity detail page can poll to inquire the result of the preemptive purchase.
Further, the step S4 is further specifically: judging the inventory, reading the inventory of the goods from a redis cache of the server, if the inventory of the goods is insufficient, returning the inventory shortage of the user, and trying to detect the leakage later; if the user who successfully buys the order is not paid within the limited period, the stock is returned, and the user can continue to make the order; if the stock cached by the server redis is enough and does not represent certain successful robbery, whether the robbery is successful is determined after the stock is deducted by sequential execution, and the user has the temporarily pre-robbery state of the robbery.
Further, the step S6 is further specifically: starting a thread, asynchronously consuming orders in the message queue, reading real stock data from a database, deducting the stock one by one, modifying the order state into a successful purchase mode if the deduction is successful, and updating the redis stock; and if the inventory is insufficient, updating the orders in the remaining message queue to be in failure of the purchase.
The invention also provides a high-performance bill-picking and robbery-purchasing system, which comprises a page setting module, an interface current-limiting module, an IP request current-limiting module, an inventory judging module, a message queue establishing module, a message queue processing module, a state inquiring module and an inventory updating module;
the page setting module is used for setting the commodity detail page into a staticized page;
the interface current limiting module adopts a token bucket current limiter algorithm, sets a current limiting threshold value and limits the current of the server interface;
the IP request current limiting module is used for limiting a large number of robbery requests in a single IP short time;
the inventory judgment module judges the inventory of the commodities from the cache of the server;
the message queue creating module is used for adding the order in the pre-robbery state into a message queue;
the message queue processing module is used for asynchronously processing the message queue, sequentially executing deduction and updating the order;
the state query module periodically and circularly queries the order state through the front end of the commodity detail page and feeds back the robbery result to the user;
the inventory updating module is used for enabling a user to pay an order which is successfully purchased; asynchronously detecting outstanding orders over time and returning inventory to the database.
Further, a request discarding module is further included between the page setting module and the interface current limiting module, and the request discarding module randomly discards the robbery request according to probability, namely, if the commodity inventory only occupies 1% of the number of users according to the estimated access amount of the robbery activity, the request in a certain proportion is randomly discarded; the proportion is set to 40-50%; since the popular goods are often subjected to non-manual shopping by using the program means, if all the goods are ordered according to the sequence, the shopping through the program means is faster than that of the normal user, and therefore, a certain proportion of requests are discarded randomly.
Further, an order state display module is further included between the message queue creating module and the message queue processing module, and the order state display module firstly returns order information in a pre-preemptive state to the commodity detail page to display the user in the preemptive purchase, so that the front end of the commodity detail page can poll to inquire a preemptive purchase result.
Further, the implementation manner of the inventory judgment module is further specifically: judging the inventory, reading the inventory of the goods from a redis cache of the server, if the inventory of the goods is insufficient, returning the inventory shortage of the user, and trying to detect the leakage later; if the user who successfully buys the order is not paid within the limited period, the stock is returned, and the user can continue to make the order; if the stock cached by the server redis is enough and does not represent certain successful robbery, whether the robbery is successful is determined after the stock is deducted by sequential execution, and the user has the temporarily pre-robbery state of the robbery.
Further, the implementation manner of the message queue processing module is further specifically: starting a thread, asynchronously consuming orders in the message queue, reading real stock data from a database, deducting the stock one by one, modifying the order state into a successful purchase mode if the deduction is successful, and updating the redis stock; and if the inventory is insufficient, updating the orders in the remaining message queue to be in failure of the purchase.
The invention has the beneficial effects that: 1. the detail page of the commodity to be subjected to the emergency purchase is made to be static, the page reduces the reading of dynamic data, and the access speed of the detail page can be increased; 2. interface current limiting and user IP request current limiting are carried out, and the pressure of a server is reduced; the high-concurrency second killing scene can be supported; 3. the asynchronous processing is carried out through the message queue, so that the stock is protected from being overflowed, and the data are ensured to be correct.
Drawings
FIG. 1 is a schematic flow diagram of the process of the present invention.
Fig. 2 is a system schematic of the present invention.
Detailed Description
The invention is further described below with reference to the accompanying drawings.
Referring to fig. 1, a high-performance bill-of-lading and rush-purchasing method according to the present invention includes the following steps:
step S1, setting the commodity detail page into a staticizing page;
step S2, setting a current limiting threshold value by adopting a token bucket current limiter algorithm, and limiting the current of the server interface;
step S3, limiting the flow of a large number of robbery requests in a single IP short time;
step S4, judging commodity stock from the cache of the server;
step S5, adding the order in the pre-robbery state into a message queue;
step S6, asynchronously processing the message queue, sequentially executing deduction and updating the order;
step S7, the front end of the commodity detail page periodically and circularly queries the order state and feeds back the result of the robbery to the user;
step S8, the user pays the order of successful purchase-robbing; asynchronously detecting outstanding orders over time and returning inventory to the database.
The invention is further illustrated below with reference to a specific embodiment:
a high-performance bill-of-lading and rush-purchasing method comprises the following steps:
step 1, staticizing a commodity detail page:
the detail page of the commodity to be subjected to the emergency purchase is made to be static, the page reduces reading of dynamic data, the generation is good, and the access speed of the detail page can be accelerated.
Step 2, randomly discarding the emergency purchase request according to the probability:
according to the predicted visit amount of the activity, if the commodity inventory only accounts for 1% of the users, a certain proportion of requests can be randomly discarded, and the proportion is set to be 40% -50%; because the rush-buying of hot goods is often carried out by non-artificial rush-buying by using a program means, if all orders are placed according to the sequence, the rush-buying by using the program means is faster than that of normal users, the normal users have no chance, and the random discarding of a certain proportion of requests is also a fair way.
Step 3, interface current limiting:
in order to prevent the server from being overloaded and causing service rushing, a token bucket restrictor algorithm is adopted. The interface current limiting limits the number of requests in a certain time window, maintains the availability and stability of the system, and prevents the system from running slowly or down due to the sudden increase of the flow. Requests that exceed the current limit threshold will be discarded. The current limit threshold needs to be obtained through a pressure test, specifically, through a jmeter pressure measurement tool, 100 concurrent users are set, each user generates 100 requests, and the qps value obtained by the jmeter pressure measurement tool is taken as a reference, for example, qps is 3000/s, so as to avoid over-limit, and a qps value of 80% =2400/s can be taken as the interface current limit threshold of a single server.
Step 4, user IP requests for flow limitation:
in order to prevent illegal violent requests, a large number of requests in a short time for a single IP need to be restricted.
Step 5, judging inventory from cache:
after filtering layer by layer, the ordering stage is formally entered, firstly, the inventory judgment is carried out, the commodity inventory is read from the redis cache, if the inventory is insufficient, the inventory shortage of the user is returned, the user is requested to try to detect the omission later, if the user who successfully buys the order is not paid within a limited time, the inventory is returned in the step 11, and the user can continue ordering. If the redis inventory is enough and does not represent that the pre-robbery is successful, the step 8 is waited to sequentially execute deduction, and the pre-robbery state is temporarily set.
Step 6, adding the order into a message queue:
to prevent overruns, a common practice is to use distributed locks, which can degrade drop interface performance, causing greater congestion. The order in the pre-robbery state in the step 5 is added into a message queue by adopting an asynchronous sequential deduction mode, and the step 8 is waited for sequential deduction of the stock, so that the supersending can be prevented by sequential execution.
And 7, returning to the first-aid purchase:
since the user in the pre-preemptive state in the step 5 does not necessarily need to preempt the commodity, the result of the step 8 is waited, the user returns to the user for the preemptive, and the front end polls for the result of the preemptive.
Step 8, asynchronously processing the message queue, sequentially executing deduction and updating the order:
starting a thread, asynchronously consuming orders in the message queue, reading real stock data from a database, deducting the stock one by one, modifying the order state into a successful purchase mode if the deduction is successful, and updating the redis stock; and if the inventory is insufficient, updating the orders in the remaining message queue to be in failure of the purchase.
Step 9, the front end regularly polls the result of the emergency purchase:
the front end inquires the order state in a circulating mode at regular time of 1 second, if the order fails to be purchased, the user is prompted to fail to terminate the inquiry, and if the order state is successful to be purchased, the user is guided to pay.
Step 10, the user pays the order of successful purchase emergency:
the front end displays a 90 second payment countdown, where the user needs to make a payment within a time limit, and if the user does not pay for the time out, the inventory is released at step 11.
Step 11, asynchronously detecting an unpaid order when the time is out, and returning the order to the stock:
starting a planning task, circularly detecting the pre-robbery status order, if the order does not change into a payment status within 90 seconds, the user does not pay overtime, modifying the order status into a cancelled status, returning the goods stock to the database, and updating the redis stock data.
Referring to fig. 2, the present invention further provides a high-performance bill picking and robbery system, which includes a page setting module, an interface current limiting module, an IP request current limiting module, an inventory judging module, a message queue creating module, a message queue processing module, a status query module, and an inventory updating module;
the page setting module is used for setting the commodity detail page into a staticized page; the detail page of the commodity to be subjected to the emergency purchase is made to be static, the page reduces reading of dynamic data, the generation is good, and the access speed of the detail page can be accelerated.
The interface current limiting module adopts a token bucket current limiter algorithm, sets a current limiting threshold value and limits the current of the server interface;
the IP request current limiting module is used for limiting a large number of robbery requests in a single IP short time;
the inventory judgment module judges the inventory of the commodities from the cache of the server; the inventory judgment module is further implemented in the following manner: judging the inventory, reading the inventory of the goods from a redis cache of the server, if the inventory of the goods is insufficient, returning the inventory shortage of the user, and trying to detect the leakage later; if the user who successfully buys the order is not paid within the limited period, the stock is returned, and the user can continue to make the order; if the stock cached by the server redis is enough and does not represent certain successful robbery, whether the robbery is successful is determined after the stock is deducted by sequential execution, and the user has the temporarily pre-robbery state of the robbery.
The message queue creating module is used for adding the order in the pre-robbery state into a message queue;
the message queue processing module is used for asynchronously processing the message queue, sequentially executing deduction and updating the order; the message queue processing module is further specifically implemented as follows: starting a thread, asynchronously consuming orders in the message queue, reading real stock data from a database, deducting the stock one by one, modifying the order state into a successful purchase mode if the deduction is successful, and updating the redis stock; and if the inventory is insufficient, updating the orders in the remaining message queue to be in failure of the purchase.
The state query module periodically and circularly queries the order state through the front end of the commodity detail page and feeds back the robbery result to the user; the front end displays a 90 second payment countdown, where the user needs to make a payment within a time limit, and if the user does not pay for the time limit, the inventory is released.
The inventory updating module is used for enabling a user to pay an order which is successfully purchased; asynchronously detecting outstanding orders over time and returning inventory to the database. Starting a planning task, circularly detecting the pre-robbery status order, if the order does not change into a payment status within 90 seconds, the user does not pay overtime, modifying the order status into a cancelled status, returning the goods stock to the database, and updating the redis stock data.
The system comprises a page setting module, an interface current limiting module, a request discarding module and a display module, wherein the page setting module and the interface current limiting module also comprise the request discarding module, and the request discarding module randomly discards the emergency purchase requests according to probability, namely randomly discards requests in a certain proportion if the inventory of commodities only occupies 1% of the number of users according to the estimated access amount of emergency purchase activities; the proportion is set to 40-50%; since the popular goods are often subjected to non-manual shopping by using the program means, if all the goods are ordered according to the sequence, the shopping through the program means is faster than that of the normal user, and therefore, a certain proportion of requests are discarded randomly.
An order state display module is also arranged between the message queue creating module and the message queue processing module, and the order state display module firstly returns order information in a pre-preemptive purchase state to a commodity detail page to display a user preemptive purchase, so that the front end of the commodity detail page can poll and inquire a preemptive purchase result. The front end inquires the order state in a circulating mode at regular time of 1 second, if the order fails to be purchased, the user is prompted to fail to terminate the inquiry, and if the order state is successful to be purchased, the user is guided to pay.
In a word, the invention can support the highly concurrent second killing scene, can protect the stock from being overflowed and ensure the data to be correct.
The above description is only a preferred embodiment of the present invention, and all equivalent changes and modifications made in accordance with the claims of the present invention should be covered by the present invention.
Claims (10)
1. A high-performance bill-of-lading and rush-purchasing method is characterized in that: the method comprises the following steps:
step S1, setting the commodity detail page into a staticizing page;
step S2, setting a current limiting threshold value by adopting a token bucket current limiter algorithm, and limiting the current of the server interface;
step S3, limiting the flow of a large number of robbery requests in a single IP short time;
step S4, judging commodity stock from the cache of the server;
step S5, adding the order in the pre-robbery state into a message queue;
step S6, asynchronously processing the message queue, sequentially executing deduction and updating the order;
step S7, the front end of the commodity detail page periodically and circularly queries the order state and feeds back the result of the robbery to the user;
step S8, the user pays the order of successful purchase-robbing; asynchronously detecting outstanding orders over time and returning inventory to the database.
2. The high-performance bill-of-lading and rush-buying method as claimed in claim 1, characterized in that: a step S11 is further included between the step S1 and the step S2, the robbery request is randomly discarded according to the probability, namely according to the estimated access amount of the robbery activity, if the commodity inventory only occupies 1% of the number of users, the request with a certain proportion is randomly discarded, and the proportion is set to be 40% -50%; since the popular goods are often subjected to non-manual shopping by using the program means, if all the goods are ordered according to the sequence, the shopping through the program means is faster than that of the normal user, and therefore, a certain proportion of requests are discarded randomly.
3. The high-performance bill-of-lading and rush-buying method as claimed in claim 1, characterized in that: a step S51 is further included between the step S5 and the step S6, the order information of the pre-preemptive purchase status is returned to the commodity detail page first to display the user preemptive purchase, so that the front end of the commodity detail page can poll to inquire the preemptive purchase result.
4. The high-performance bill-of-lading and rush-buying method as claimed in claim 1, characterized in that: the step S4 further includes: judging the inventory, reading the inventory of the goods from a redis cache of the server, if the inventory of the goods is insufficient, returning the inventory shortage of the user, and trying to detect the leakage later; if the user who successfully buys the order is not paid within the limited period, the stock is returned, and the user can continue to make the order; if the stock cached by the server redis is enough and does not represent certain successful robbery, whether the robbery is successful is determined after the stock is deducted by sequential execution, and the user has the temporarily pre-robbery state of the robbery.
5. The high-performance bill-of-lading and rush-buying method as claimed in claim 1, characterized in that: the step S6 further includes: starting a thread, asynchronously consuming orders in the message queue, reading real stock data from a database, deducting the stock one by one, modifying the order state into a successful purchase mode if the deduction is successful, and updating the redis stock; and if the inventory is insufficient, updating the orders in the remaining message queue to be in failure of the purchase.
6. A high-performance bill of lading buys system which characterized in that: the system comprises a page setting module, an interface current limiting module, an IP request current limiting module, an inventory judging module, a message queue creating module, a message queue processing module, a state inquiring module and an inventory updating module;
the page setting module is used for setting the commodity detail page into a staticized page;
the interface current limiting module adopts a token bucket current limiter algorithm, sets a current limiting threshold value and limits the current of the server interface;
the IP request current limiting module is used for limiting a large number of robbery requests in a single IP short time;
the inventory judgment module judges the inventory of the commodities from the cache of the server;
the message queue creating module is used for adding the order in the pre-robbery state into a message queue;
the message queue processing module is used for asynchronously processing the message queue, sequentially executing deduction and updating the order;
the state query module periodically and circularly queries the order state through the front end of the commodity detail page and feeds back the robbery result to the user;
the inventory updating module is used for enabling a user to pay an order which is successfully purchased; asynchronously detecting outstanding orders over time and returning inventory to the database.
7. The high-performance bill of lading and robbery system as claimed in claim 6, wherein: the system comprises a page setting module, an interface current limiting module, a request discarding module and a display module, wherein the page setting module and the interface current limiting module further comprise the request discarding module, and the request discarding module randomly discards the emergency purchase requests according to probability, namely randomly discards requests in a certain proportion if the inventory of commodities only occupies 1% of the number of users according to the estimated access amount of the emergency purchase activities, and the proportion is set to be 40% -50%; since the popular goods are often subjected to non-manual shopping by using the program means, if all the goods are ordered according to the sequence, the shopping through the program means is faster than that of the normal user, and therefore, a certain proportion of requests are discarded randomly.
8. The high-performance bill of lading and robbery system as claimed in claim 6, wherein: an order state display module is also arranged between the message queue creating module and the message queue processing module, and the order state display module firstly returns order information in a pre-preemptive purchase state to a commodity detail page to display a user preemptive purchase, so that the front end of the commodity detail page can poll and inquire a preemptive purchase result.
9. The high-performance bill of lading and robbery system as claimed in claim 6, wherein: the inventory judgment module is further implemented in the following manner: judging the inventory, reading the inventory of the goods from a redis cache of the server, if the inventory of the goods is insufficient, returning the inventory shortage of the user, and trying to detect the leakage later; if the user who successfully buys the order is not paid within the limited period, the stock is returned, and the user can continue to make the order; if the stock cached by the server redis is enough and does not represent certain successful robbery, whether the robbery is successful is determined after the stock is deducted by sequential execution, and the user has the temporarily pre-robbery state of the robbery.
10. The high-performance bill of lading and robbery system as claimed in claim 6, wherein: the message queue processing module is further specifically implemented as follows: starting a thread, asynchronously consuming orders in the message queue, reading real stock data from a database, deducting the stock one by one, modifying the order state into a successful purchase mode if the deduction is successful, and updating the redis stock; and if the inventory is insufficient, updating the orders in the remaining message queue to be in failure of the purchase.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110543772.XA CN113129116A (en) | 2021-05-19 | 2021-05-19 | High-performance bill-of-lading and rush-purchasing method and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110543772.XA CN113129116A (en) | 2021-05-19 | 2021-05-19 | High-performance bill-of-lading and rush-purchasing method and system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113129116A true CN113129116A (en) | 2021-07-16 |
Family
ID=76782317
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110543772.XA Pending CN113129116A (en) | 2021-05-19 | 2021-05-19 | High-performance bill-of-lading and rush-purchasing method and system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113129116A (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113778697A (en) * | 2021-09-14 | 2021-12-10 | 福建天晴数码有限公司 | Method and system for realizing high availability of redis distribution lock |
| CN113887935A (en) * | 2021-09-29 | 2022-01-04 | 中通服科信信息技术有限公司 | High-concurrency service scene processing method, system and storage medium |
| CN114580903A (en) * | 2022-03-04 | 2022-06-03 | 长沙图灵教育科技有限公司 | E-commerce simulation training platform |
| CN114897473A (en) * | 2022-05-26 | 2022-08-12 | 深圳依时货拉拉科技有限公司 | Processing method and device for order to be preempted, computer equipment and storage medium |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006313393A (en) * | 2004-04-16 | 2006-11-16 | Mieko Tsuyusaki | Network system or discount negotiation system |
| US20110178950A1 (en) * | 2010-01-21 | 2011-07-21 | Parga Landa Jose Antonio | System and method of visual representation of stock exchange transactions |
| CN106411777A (en) * | 2016-09-27 | 2017-02-15 | 福建中金在线信息科技有限公司 | Method and system for processing high concurrent data |
| CN108418821A (en) * | 2018-03-06 | 2018-08-17 | 北京焦点新干线信息技术有限公司 | Redis and Kafka-based high-concurrency scene processing method and device for online shopping system |
| CN110148034A (en) * | 2019-04-24 | 2019-08-20 | 珠海市珠澳跨境工业区好易通科技有限公司 | A kind of excellent device and method of online shopping system architecture |
| CN112286693A (en) * | 2020-11-24 | 2021-01-29 | 上海浦东发展银行股份有限公司 | Refined current limiting processing method and device for emergency purchasing activities in high-concurrency scene |
-
2021
- 2021-05-19 CN CN202110543772.XA patent/CN113129116A/en active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006313393A (en) * | 2004-04-16 | 2006-11-16 | Mieko Tsuyusaki | Network system or discount negotiation system |
| US20110178950A1 (en) * | 2010-01-21 | 2011-07-21 | Parga Landa Jose Antonio | System and method of visual representation of stock exchange transactions |
| CN106411777A (en) * | 2016-09-27 | 2017-02-15 | 福建中金在线信息科技有限公司 | Method and system for processing high concurrent data |
| CN108418821A (en) * | 2018-03-06 | 2018-08-17 | 北京焦点新干线信息技术有限公司 | Redis and Kafka-based high-concurrency scene processing method and device for online shopping system |
| CN110148034A (en) * | 2019-04-24 | 2019-08-20 | 珠海市珠澳跨境工业区好易通科技有限公司 | A kind of excellent device and method of online shopping system architecture |
| CN112286693A (en) * | 2020-11-24 | 2021-01-29 | 上海浦东发展银行股份有限公司 | Refined current limiting processing method and device for emergency purchasing activities in high-concurrency scene |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113778697A (en) * | 2021-09-14 | 2021-12-10 | 福建天晴数码有限公司 | Method and system for realizing high availability of redis distribution lock |
| CN113887935A (en) * | 2021-09-29 | 2022-01-04 | 中通服科信信息技术有限公司 | High-concurrency service scene processing method, system and storage medium |
| CN114580903A (en) * | 2022-03-04 | 2022-06-03 | 长沙图灵教育科技有限公司 | E-commerce simulation training platform |
| CN114897473A (en) * | 2022-05-26 | 2022-08-12 | 深圳依时货拉拉科技有限公司 | Processing method and device for order to be preempted, computer equipment and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113129116A (en) | High-performance bill-of-lading and rush-purchasing method and system | |
| Ockenfels et al. | The timing of bids in internet auctions: Market design, bidder behavior, and artificial agents | |
| US9626210B2 (en) | Resource credit pools for replenishing instance resource credit balances of virtual compute instances | |
| KR102365689B1 (en) | Method for issuing and trading time-context data based non-fungible tokens to be used for supporting trading historical time slots, and server using the same | |
| US8078483B1 (en) | Systems and methods for queuing access to network resources | |
| US7580870B1 (en) | Method and system for providing auctions to win with a lowest bid | |
| JP2013501973A (en) | Account parallel processing method and system | |
| JPH06251022A (en) | Electronic dealing system | |
| US9563903B1 (en) | System and method for controlling real-time bidding for online advertisements | |
| KR20190110377A (en) | Method for managing token based on heterogeneous blockchains, and token management server using the same | |
| US10783562B2 (en) | Mitigation of failures in an online advertising network | |
| CN111930786A (en) | Resource acquisition request processing system, method and device | |
| US11960465B2 (en) | Database inventory isolation | |
| US11854048B1 (en) | System and method for controlling real-time bidding for online advertisements | |
| CN112101691B (en) | Dynamic risk level adjustment method, device and server | |
| CN115641180A (en) | Request processing method, related device and equipment | |
| CN106530084B (en) | Information processing method and server | |
| CN108416652A (en) | A kind of ticketing service distribution method, computer readable storage medium and server | |
| CN106296248A (en) | Information push method and device | |
| KR20190113162A (en) | Method for managing token based on heterogeneous blockchains, and token management server using the same | |
| WO2014153978A1 (en) | Methods and systems for managing suppliers and flow of goods on an ecommerce platform | |
| CN110009460B (en) | Auction delay method and system based on block chain | |
| CN113362127A (en) | Second-hand car bidding system with high availability | |
| JPWO2016157248A1 (en) | Information processing apparatus, control method, and program | |
| CN114339270B (en) | Control method and system for distributing articles in live broadcast, electronic equipment and storage medium |
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 | ||
| WD01 | Invention patent application deemed withdrawn after publication | ||
| WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20210716 |