Distributed transaction and distributed lock

CAP

Our CAP theory can only satisfy two at the same time .
Insert picture description here
Our Dubbo satisfies cp but not a! !
For example, our Zookeeper is a cluster composed of multiple servers, one leader and multiple followers. If our leader fails, this is to ensure the partition fault tolerance, and we will quickly select a leader from the follower (not in the election process) Provide external services). But this is an error if a request comes in (so there is no guarantee of availability). When dubbo modifies data, the master node and slave node data need to be modified at the same time.

Our Springcloud satisfies ap but not c.
Springcloud guarantees its availability through the fuse mechanism hystrix.

Distributed transaction

  1. The XA two-stage commit (strongly consistent) Insert picture description heretransaction manager informs the two local transactions that they are ready to execute, transaction 1 tells the transaction manager if the execution succeeds, transaction 2 tells the transaction manager if the execution succeeds, and the transaction manager informs them that the two transactions are committed.
  2. Three paragraphs submitted to 3PC (strong agreement)Insert picture description hereInsert picture description here
  3. TCC compensation mechanismInsert picture description hereInsert picture description here
  4. Local message table (MQ+Table) (finally consistent)
  5. Transaction message (RocketMq) (finally consistent) Insert picture description hereSend pre-message (will not be consumed by consumers)—>Execute your own business logic—>confirm message (let the consumption sent before can be seen by consumers)—>Consumers execute themselves Business logic —> If the consumption is successful, send a message to rocketMQ to delete the queue message.
  6. Seata ba alibaba)

Distributed lock

In essence, the goal of distributed locks is to occupy a "pit" in Redis. When other processes also want to occupy it, they find that someone is already squatting there, so they have to give up or try again later.
The pit is usually occupied by the setnx (set if not exists) command. Only one client is allowed to occupy the pit. The pit is occupied first, and when it is used up, the del command is called to release the pit.

set  test ture  ex 5 nx
del  test

Guess you like

Origin blog.csdn.net/qq_36905956/article/details/106019285