After querying the price of the order, the order is issued in batches, and the real time to deduct money is to receive the order, how to ensure that the account balance is sufficient?

1. You can find out how much money you can get for each order first. Note: you can"t inquire about it when you place an order. (the current consideration is to slow down the memory when querying, but if this order is checked, the order will not necessarily be placed, and the cache time is not easy to determine)
2. The money deduction is deducted when this order is accepted
3. If multithreaded or looped over a pile of orders, how to ensure that the account balance is greater than 0? The existence of the balance DB, the operation of the balance has been ensured through the reids that the balance update is safe.

the title is like the above, welcome to give us your advice!

Distributed-lock concurrent redis java

Mar.05,2021

throw a brick to attract jade:

Multi-threaded deduction of money must be safe, it must be in order at the time of deduction, and atomicity must be ensured;

think of two: 1 is to use redis balance, the redis operation itself is atomic; 2 is to use database optimistic lock, data plus version number, update data to check version number.

you can add a field of frozen amount to correspond to your concept of withholding money;

Previous: The picture generation of the "instruction manual" of NetEYun music

Next: Centos 7 vsftp sets passive mode and enables relevant port mapping, but still cannot use passive mode