Shulou(Shulou.com)05/31 Report--

This article introduces the knowledge of "how to solve the Mysql distributed transaction problem". Many people will encounter this dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Background

In April 2020, we began to try to implement Seata-Golang, a distributed transaction framework for the go language. As we all know, Seata AT mode is respected by the majority of developers because of its no business code intrusion. The Seata AT mode of Java version proxies the DataSource data source, intercepts and parses the sql during the execution of the sql statement, obtains a copy of the corresponding data in the database before and after the execution of the sql statement, serializes and saves it, and rolls back the corresponding data back and forth when the TC coordinates the rollback. When implementing the AT pattern of the go version of client, how to be more friendly to business developers and have less intrusion has become the primary consideration.

When using go to manipulate the database, we use database/sql, the official library of the go language, to get a data source operation object db through sql.Open ("mysql", ${dsn}). When you open a transaction, use db.Begin () or db.BeginTx (ctx, & sql.TxOptions {}) to get the transaction operator tx, execute a sql query, use tx.Query; to add, modify, delete sql, use tx.Exec; to finally use tx.Commit () to commit or use tx.Rollback () to roll back.

Database/sql, the official library of go language, provides a standard abstraction layer, which can operate on different databases by implementing a set of standard abstract API for different driver. To develop a Go version of the AT schema, it is necessary to be compatible with database/sql. By studying the api of database/sql and creating data source operation objects, the configuration related to the database must be passed through Data Source Name (DSN) abstraction. Here is the definition of DSN:

[username [: password] @] [protocol [(address)]] / dbname [? param1=value1&... mN=valueN]

Implementing the AT pattern to the data source agent needs to interact with the transaction coordinator TC. If the AT pattern is implemented in the driver layer, then some parameters of the interaction with TC must be passed to driver through DSN, which somewhat destroys its design. Therefore, finally, a compromise is adopted, which implements the AT pattern on top of the database/sql layer and proxies the data source operation objects created by database/sql. The data source proxy object implements the Tx interface defined by the database/sql library, and provides another method to open the transaction: Begin (). Although it is not fully compatible with database/sql 's api, the key interface is barely acceptable as it is defined. At this point, the development of the core functions of the Seata-Golang project has been completed.

Type Tx interface {Commit () error Rollback () error} turning point

After Seata-Golang is open source, it is gradually understood and contacted by some developers, and the community has also issued some feedback to Seata-Golang. Many developers are not used to writing native sql. They want to integrate Seata-Golang into the ORM framework, because the design at that time is not fully compatible with database/sql, which leads to some difficulties in integration. With the fervent call of the community and thanks to some previous studies on driver, thoughts are bound to reverberate. In March this year, there was a sudden burst of inspiration: why do parameters have to be transmitted through DSN? After the Seata-Golang Client is initialized, it can be directly obtained and used through API config.GetATConfig () on the Client side when needed.

So after work, it took two weeks to develop, and the first fully database/sql-compatible mysql driver integrated with Seata-Golang was developed.

Some details of driver

When using this driver for distributed transaction operations, you cannot set the interpolateParams parameter to true in dsn.

This involves two protocols of mysql: Text protocol and Binary protocol. Information on the differences between the two protocols can be found in the reference documentation at the end of the article. The implementation of the driver only deals with the binary protocol. Enabling interpolateParams will execute the sql using the text protocol.

Using this driver, when you need to join a global transaction group to interact with tc, you need to use the db.BeginTx (ctx context.Context, opts driver.TxOptions) method and add the value of the XID global transaction id to the ctx.

Ctx: = context.WithValue (context.Background (), mysql.XID, c.Request.Header.Get ("XID")) tx, err: = dao.BeginTx (ctx, & sql.TxOptions {Isolation: sql.LevelDefault, ReadOnly: false,})

The XID is passed to the driver layer and is saved in the & mysqlConn connection object, which is used when interacting with TC.

Seata-golang client and mysql driver need to be initialized before using the distributed transaction feature of the driver:

Config.InitConf (configPath) client.NewRpcClient () mysql.InitDataResourceManager () mysql.RegisterResource (config.GetATConfig () .DSN) "how to solve the Mysql distributed transaction problem" ends here. Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.