To do a snapping feature how to consider concurrency

The company wants to do a snapping up function
How can I avoid the extra order of concurrent orders?
Because the database is MONGO can't lock like MySQL
Do not know what a good solution?

All I want to do is use Redis to force him to line up, but this is ridiculous.
Every time I create it, I check it out, but I'm afraid there's a concurrency.

Reply content:

The company wants to do a snapping up function
How can I avoid the extra order of concurrent orders?
Because the database is MONGO can't lock like MySQL
Do not know what a good solution?

All I want to do is use Redis to force him to line up, but this is ridiculous.
Every time I create it, I check it out, but I'm afraid there's a concurrency.

Use Message Queuing to solve this problem

First you have to have a design capacity. Your project is ready to accommodate how many people rob how many products. Then decide what technology to use.
If there's 10 people to rob, don't get tangled up, just find a relational database. A godless is finished.
A little more, you can press the pressure directly onto the MongoDB. By the way, MongoDB is not without locks, reasonable use as can be locked not much to sell, using the $inc operator. Like what:

db.product.update({sku: 'xxx', qty: {$gt: 0}}, {$inc: {qty: -1}})

If that's not enough for you, it's time to think about the queue.

Snapping up this demand involves financial functions, and the financial function definitely requires a lock function.

Therefore, if you are not so cool, write your own middleware, if you want to lazy, or use MySQL bar.

Independent of a table to do, it is dedicated to store this kind of snapping goods

Redis should be able to implement AH. Redis itself is single-threaded, and its operations are naturally serialized without worrying about concurrent access issues. Of course, using MySQL is a convenient option.

