A: buy, spike is now a very common scenario, the main problem to be solved is twofold:
1 high pressure concurrent database created
under the state how to solve 2 competition proper inventory reduction ( "oversold" issue)
For the first question, it is very easy to think of using cache to handle buying, avoid direct operation of the database, such as using Redis. The second question, we can use redis queue to complete, the commodity spike to put into the queue, because pop operation is atomic, even though many users arrive simultaneously, also followed by the implementation, file locking and transaction under high concurrency performance drops quickly, of course, but also consider other aspects of things, such as buying a static page made by ajax call interface, which may also occur in the case of a user robbed several times, this time paired with a queuing and queue buying and inventory results queue queue. High concurrency, the user will enter the queue queues, with a thread loop processing line taken from a user queue, the user determines whether the result queue in buying, if, they have been snapped, or not to buy, stock minus 1, write to the database, the result queue into user.