Several high concurrency optimization points were mentioned earlier, as well as distributed sharing of sessions through a plug-in. This time mainly about the second kill order needs to pay attention to what.

Points to pay attention to when placing orders (1)

  1. Login Whether the session exists.
  2. Whether to fill in the shipping address
  3. Whether the goods exist
  4. Is the inventory sufficient?
  5. Validity judgment
  6. Inventory data modification redis, must use redis atomic operation, do not use SET, use DECR. Make concurrency linear, make it a queue to do things.

Distributed Transactions (2)

First of all, the distributed transaction is a very complex problem, but there are many solutions, can not be distributed as far as possible, if the concurrency is not so large.

1. The origin of distribution

For example, dubbo service invocations, multiple Dubbo services that are not in the same JVM or on the same machine, are distributed transactions.

2. The safe way

This is done through table row locking, or compensation mechanisms in messaging middleware. Multiple services read the same table and perform distributed transactions with the same caliber.

Message-oriented middleware has only one JVM consumption, such a caliber consumption.

3. Two-phase commit

Companies such as Alipay and Taobao have their own middleware. Programmers who move bricks at all do not need to consider the problem of distributed transactions during the development process. Distributed transactions are handed over to the intermediate price team, and the principle is two-stage submission. System A has A transaction TXA, system B also has its own transaction TXB, system A method is long, it needs to call B method in the middle, system B method content is short. A method call is completed after B method is completed to go to their remaining methods. B is after the end of his method is presented, but the end of the transaction to transaction middleware coordinator B, but B the end of the submission is not really committed to the database, it’s just submitted a level, and no real in the database level to submit (phase 2 transaction commit), if there is no distributed middleware is B end, B’s transaction is committed, but A’s method is not finished executing. The method execution that waits for A also performs A 2-phase commit, but A doesn’t actually commit to the database either. That is, method A is executed, method B is executed, and then the distributed transaction coordinator together to commit to the database.

Although the two transactions started separately, they eventually converged into distributed middleware, which turned them into one transaction. This is actually very complicated, and I only know the principle.

PS: The real shaomao needs constant optimization. When 12306 did not have verification code, many people submitted orders to buy tickets through Jmeter. Understand the principle of seckill, next time talk about how to control the large flow of seckill.