Distributed transaction Senta (I)

One 、 Introduction to distributed transactions

（ One ） Characteristics of the transaction

Friends who have used relational databases must know , thing ACID Characteristics ：

• A（Atomic）： Atomicity , Transaction is the smallest unit , Or all , Or none at all .
• C（Consistency）： Before and after the transaction , The state of the database is consistent . For example, Zhang San transferred to Li Si 200 element , Zhang San is less 200 element , There should be more Li Si 200 element .
• I（Isolation）： Isolation, , The execution of two concurrent transactions does not interfere with each other , One transaction cannot see the intermediate state of other transaction running processes .
• D（Durability）： persistence , After the transaction completes , Changes to the data will be persisted to the database , And will not be rolled back .

（ Two ） Classification of transactions

1. Local transactions

Generally, it refers to that databases and services are deployed on the same machine , If a request is executed , Using the transaction attributes of the database can achieve successful transaction execution / The effect of transaction execution failure and rollback .

2. Distributed transactions

Distributed transaction refers to the distributed deployment of a service on multiple machines , The database is not on the same machine , therefore , Transaction cannot be supported by using the transaction attribute of the database , To maintain data consistency between services , Some ways are needed to ensure that all tasks succeed or fail .

3. Sketch Map

（ 3、 ... and ） Two theoretical bases of distributed transaction

1.CAP The laws of

The content of this theorem means that in a distributed system 、Consistency（ Uniformity ）、 Availability（ Usability ）、Partition tolerance（ Partition tolerance ）, You can't have all three . need C You have to sacrifice A, need A You have to sacrifice P.

• C：Consistency（ Uniformity ）
  All data in the distributed system can access the same value at the same time , That is, all nodes access the latest data .
• A：Availability（ Usability ）
  Even if some nodes are unavailable , Still able to respond within the specified time
• P：Partition tolerance（ Partition tolerance ）
  This attribute exists objectively , There is no guarantee of successful remote calls between partitions , Because as long as RPC, There is the possibility of network instability . This attribute refers to , Even if there are errors between partitions , Not callable , The system will not crash .

2.BASE theory

BASE The theory is right CAP The result of the trade-off between consistency and availability ,BASE The core idea of the theory is ： Even if you can't do strong consistency , But each application can be based on its own business characteristics , Take appropriate measures to achieve the final consistency of the system .

1. Basically Available（ Basic available ）
   When an unpredictable failure occurs in a distributed system , Partial loss of availability is allowed , For example, delayed response time , Service degradation, etc
2. Soft state（ Soft state ）
   Intermediate states are allowed between services , Allow data synchronization delay , Services that are in the process of synchronization become soft
3. Eventually consistent（ Final consistency ）
   Do not pursue strong consistency , After several soft States , Agreement between microservices .

Examples are as follows ：

（ Four ） Distributed transaction solutions ——2PC agreement

Two phase submission agreement ,P Represents the preparation stage ,C Represents the submission stage ,

• Preparation stage ： The event manager will send Prepare news , Transaction participants execute transactions , And keep a log ;
• Submission phase ： If all the participants are ready , The transaction manager sends “ Submit ” news , If some transaction participants fail to prepare , The transaction manager will send a rollback command , Other databases will also be rolled back .

There are two kinds of logs ：

• Undo Log is to record the data before modification , For database rollback
• Redo Log is to record the modified data , Used to write data files after committing transactions

Flow diagram ：

Two 、Seata

（ One ）Seata brief introduction

Seata It is an open source distributed solution , Solve a series of problems of distributed transactions for users .
Seata Official website

（ Two ）Seata Related terms

Key concepts ：

• TC (Transaction Coordinator) - A business coordinator

  Maintain the state of global and branch transactions .

• TM (Transaction Manager) - Transaction manager （ The initiator , It's also RM A kind of ）

  Start global transaction 、 Commit or roll back global transactions .

• RM (Resource Manager) - Explorer （ Every micro service involved in the transaction ）

  Transaction participants , Micro services .

Seata Schematic diagram of working mechanism ：

（ 3、 ... and ） build Seata-Server

1. download

download 1.4.2 Stable version is enough Download address

2. Modify the configuration （ Support nacos edition ）

Open file registry.conf（Seata Configuration file for ）, take register{} Medium type It is amended as follows nacos,config{} Of type It is also revised to nacos.

registry {
	  #  Support  nacos 、eureka、redis、zk、consul、etcd3、sofa Such as middleware 
	  type = "nacos"
	  nacos{
	     #  Set to nacos Configuration of 
		  application = "seata-server"
		  serverAddr = "127.0.0.1:8848"
		  group = "SEATA_GROUP"
		  namespace = ""
		  cluster = "default"
		  username = ""
		  password = ""
	  }
	  ...
}

...

config {
  type = "nacos"
  ...
}

Open file file.conf（Seata Storage configuration ）, take store{} Of mode It is amended as follows db, take db{} All configurations of ,url,user,password Change it to your computer address .

store {
	mode="db"
	# Database related configuration 
	  db {
    		datasource = "druid"
    		dbType = "mysql"
   		 	driverClassName = "com.mysql.cj.jdbc.Driver"
    		url = "jdbc:mysql://127.0.0.1:3306/seata?useUnicode=true&characterEncoding=UTF-8"
   	 		user = "root"
    		password = "root"
		    minConn = 5
		    maxConn = 100
		    globalTable = "global_table"
		    branchTable = "branch_table"
		    lockTable = "lock_table"
		    queryLimit = 100
		    maxWait = 5000
  }
}

then , Start... First nacos, Restart seater-server,

cd seata/seata-server-1.4.2/bin
sh seata-server.sh

stay nacos The console can see the service , Indicating successful startup .

3. Database setup

Server Storage mode ：

1. file： standalone mode , Read and write global transaction session information in memory and persist local files root.data, Higher performance （ Default ）
2. DB： High availability mode , Global transaction session information through DB share , Relatively poor performance
3. redis：Seata-Server1.3 And above support , Higher performance , There is a risk of loss of transaction information , It needs to be used with the actual scene .

The reason for choosing db Pattern , Because in real applications , Cluster deployment seata when ,db Is the most available .
Official website sql sentence

First establish seata The database of , Then run the above sql Sentence can be used .

（ Four ）Seata-server Integrate Nacos build

The specific configuration process is clearly described on the official website .Seata Deploy to Nacos operation
Seata-server Register as a micro service Nacos in , Solve the problem of distributed transactions for other business microservices , also ,Seata-Server Use the database to store the data when the transaction runs . The working diagram is as follows ：

1. Registry configuration

modify registry.config The configuration file , Among them
registry{} Indicates the configuration of the registry , Modify user name, password and other parameters .

registry { 
	  type = "nacos"
	  nacos {
	    application = "seata-server"
	    serverAddr = "127.0.0.1:8848"
	    group = "SEATA_GROUP"
	    namespace = ""
	    cluster = "default"
	    username = "nacos"
	    password = "nacos"
	  }
 }

2. Modify the configuration center

modify seata-server Configuration file for

config{} The tag indicates the configuration of the registry

config{
	nacos {
		# nacos The service is running ip Address and port number 
	    serverAddr = "127.0.0.1:8848"
	    #  Namespace 
	    namespace = ""
	    #  grouping 
	    group = "SEATA_GROUP"
	    username = "nacos"
	    password = "nacos"
	    #  The name of the corresponding configuration file 
	    dataId = "seataServer.properties"
	 }
}

Seata-Server The database and transaction grouping configuration of are uploaded to Nacos

take Seata-Server The configuration is uploaded to Nacos There are two ways , One is scripting , One is to use config{} In the label dataId Files for use , Personally, I think the way of uploading scripts is more complicated , So I used it directly dataId How to profile .
Get into https://github.com/seata/seata/tree/develop/script/config-center download config.txt Modify according to the actual situation , What needs to be revised is ：
Transaction grouping ：

service.vgroupMapping.mygroup=default #  Transaction grouping 
service.default.grouplist=127.0.0.1:8091

Storage mode

store.mode=db 

Database configuration

store.db.datasource=druid
store.db.dbType=mysql
store.db.driverClassName=com.mysql.cj.jdbc.Driver
store.db.url=jdbc:mysql://127.0.0.1:3306/seata?useUnicode=true&rewriteBatchedStatements=true
store.db.user=root
store.db.password=root

Uploaded to the nacos The console can

After successful startup , You can view the running in the service list seata service .

Be careful ： Because of microservices （ Transaction participants ） and TC（ Business coordinator ） Need to work together , therefore , Its configuration file needs to be in the same namespace （Namspace） And a group （Group） in , In order to maintain the consistency of grouping .