Shulou(Shulou.com)06/03 Report--

This article mainly introduces "how to solve big business problems". In daily operation, I believe many people have doubts about how to solve big business problems. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "how to solve big business problems"! Next, please follow the editor to study!

Problems caused by big affairs

Before sharing the solution, take a look at what problems may be caused by large transactions in the system.

From the figure above, we can see that if there are large transactions in the system, the problem is not small, so we should try our best to avoid large transactions in the actual project development. If we already have a big transaction problem in the system, how to solve it?

The solution is to use less @ Transactional annotations

In actual project development, we enable the transaction function in the business method with the @ Transactional annotation, which is a very common practice, which is called declarative transaction.

Some of the codes are as follows:

@ Transactional (rollbackFor=Exception.class)

Public void save (User user) {

DoSameThing...

}

However, the first thing I want to say is: use less @ Transactional annotations.

Why?

We know that the @ Transactional annotation works through spring's aop, but transaction functionality may fail if it is not used properly. If you happen to be inexperienced, this kind of problem is difficult to troubleshoot. As for the circumstances under which the transaction will fail, you can refer to the 10 kinds of pits of spring transactions that I wrote earlier, you may step on them if you are not careful! "this article. @ Transactional annotation is generally added to a business method, which will cause the entire business method to be in the same transaction. The granularity is too coarse and it is difficult to control the transaction scope, which is the most common cause of large transaction problems.

What should we do?

You can use programmatic transactions to manually execute transactions using objects of the TransactionTemplate class in a spring project.

Some of the codes are as follows:

@ Autowired

Private TransactionTemplate transactionTemplate

...

Public void save (final User user) {

TransactionTemplate.execute ((status) = > {

DoSameThing...

Return Boolean.TRUE

})

}

As you can see from the above code, using the programmatic transaction feature of TransactionTemplate to flexibly control the scope of the transaction is the preferred way to avoid large transaction problems.

Of course, when I say that we should use the @ Transactional annotation less to start a transaction, I don't mean that it must not be used. If some business logic in the project is relatively simple and does not change frequently, it does not hurt to use the @ Transactional annotation to open a transaction, because it is simpler and more efficient, but you must be careful about transaction failure.

Put the select method out of the transaction

If there is a large transaction, you can put the select method outside the transaction, which is also a more common practice, because in general, such methods do not require transactions.

For example, the following code appears:

@ Transactional (rollbackFor=Exception.class)

Public void save (User user) {

QueryData1 ()

QueryData2 ()

AddData1 ()

UpdateData2 ()

}

You can put the queryData1 and queryData2 query methods outside the transaction, and put the code that really needs transaction execution into the transaction, such as addData1 and updateData2 methods, which can effectively reduce the granularity of the transaction.

If you use TransactionTemplate programmatic transactions, it is very easy to modify here.

@ Autowired

Private TransactionTemplate transactionTemplate

...

Public void save (final User user) {

QueryData1 ()

QueryData2 ()

TransactionTemplate.execute ((status) = > {

AddData1 ()

UpdateData2 ()

Return Boolean.TRUE

})

}

But if you really want to use the @ Transactional annotation, how do you split it?

Public void save (User user) {

QueryData1 ()

QueryData2 ()

DoSave ()

}

@ Transactional (rollbackFor=Exception.class)

Public void doSave (User user) {

AddData1 ()

UpdateData2 ()

}

This example is a very classic mistake, this direct method call transaction will not take effect, a reminder to friends in the pit. Because the declarative transaction annotated by @ Transactional works through spring aop, and spring aop needs to generate a proxy object, the direct method call uses the original object, so the transaction does not take effect.

Is there any way to solve this problem?

1. Add a new Service method

This method is very simple, just add a new Service method, add the @ Transactional annotation to the new Service method, and move the code that needs to be executed by the transaction to the new method. The specific code is as follows:

@ Servcie

Public class ServiceA {

@ Autowired

Prvate ServiceB serviceB

Public void save (User user) {

QueryData1 ()

QueryData2 ()

ServiceB.doSave (user)

}

}

@ Servcie

Public class ServiceB {

@ Transactional (rollbackFor=Exception.class)

Public void doSave (User user) {

AddData1 ()

UpdateData2 ()

}

}

two。 Inject yourself into the Service class

If you don't want to add a new Service class, injecting yourself into that Service class is also an option. The specific code is as follows:

@ Servcie

Public class ServiceA {

@ Autowired

Prvate ServiceA serviceA

Public void save (User user) {

QueryData1 ()

QueryData2 ()

ServiceA.doSave (user)

}

@ Transactional (rollbackFor=Exception.class)

Public void doSave (User user) {

AddData1 ()

UpdateData2 ()

}

}

Some people may wonder: will this approach lead to the problem of circular dependency?

In fact, the three-level cache inside spring ioc ensures that it will not have circular dependency problems. If you want to learn more about circular dependencies, take a look at my previous article, "Why do you use three-level caching to solve circular dependencies with spring?" ".

3. Use AopContext.currentProxy () to get the proxy object in this Service class

Method 2 above does solve the problem, but the code doesn't look intuitive, and you can do the same by using AOPProxy to get the proxy object in the Service class. The specific code is as follows:

@ Servcie

Public class ServiceA {

Public void save (User user) {

QueryData1 ()

QueryData2 ()

((ServiceA) AopContext.currentProxy ()) .doSave (user)

}

@ Transactional (rollbackFor=Exception.class)

Public void doSave (User user) {

AddData1 ()

UpdateData2 ()

}

}

Avoid remote calls in transactions

It is inevitable for us to call the interface of other systems in the interface, because the network is unstable, the response time of this kind of remote call may be long, if the code of the remote call is placed in something, this thing may be a big transaction. Of course, remote invocation not only refers to calling the interface, but also includes sending MQ messages, or connecting to redis, mongodb to save data, and so on.

@ Transactional (rollbackFor=Exception.class)

Public void save (User user) {

CallRemoteApi ()

AddData1 ()

}

Code for remote calls can take a long time, so be sure to keep it outside the transaction.

@ Autowired

Private TransactionTemplate transactionTemplate

...

Public void save (final User user) {

CallRemoteApi ()

TransactionTemplate.execute ((status) = > {

AddData1 ()

Return Boolean.TRUE

})

}

Some friends may ask, how can data consistency be ensured if the code for remote calls is not placed in a transaction? This needs to establish: retry + compensation mechanism to achieve the final consistency of the data.

Avoid dealing with too much data at once in a transaction

If there is too much data to be processed in a transaction, it will also cause big transaction problems. For example, for ease of operation, you may update 1000 pieces of data in batches at a time, which can lead to a large number of data locks waiting, especially in systems with high concurrency.

The solution is paging, 1000 pieces of data, 50 pages, only 20 pieces of data at a time, which can greatly reduce the occurrence of large transactions.

Non-transactional execution

Before using a transaction, we should all think about whether all database operations need to be performed in a transaction.

@ Autowired

Private TransactionTemplate transactionTemplate

...

Public void save (final User user) {

TransactionTemplate.execute ((status) = > {

AddData ()

AddLog ()

UpdateCount ()

Return Boolean.TRUE

})

}

In the above example, it is not possible for addLog to add operation log method and updateCount update statistics method, because the business of operation log and statistics allows a small amount of data inconsistency.

@ Autowired

Private TransactionTemplate transactionTemplate

...

Public void save (final User user) {

TransactionTemplate.execute ((status) = > {

AddData ()

Return Boolean.TRUE

})

AddLog ()

UpdateCount ()

}

Of course, in large transactions, it is not so easy to identify which methods can be executed by non-transactions. you need to comb through the whole business in order to find the most reasonable answer.

Asynchronous processing

It is also important that all methods in a transaction need to be executed synchronously. As we all know, method synchronous execution needs to wait for the method to return. If there are too many synchronous execution methods in a transaction, the waiting time will be too long and big transaction problems will occur.

Take a look at the following list:

@ Autowired

Private TransactionTemplate transactionTemplate

...

Public void save (final User user) {

TransactionTemplate.execute ((status) = > {

Order ()

Delivery ()

Return Boolean.TRUE

})

}

The order method is used to place an order, and the delivery method is used to ship the goods. Do you have to ship the goods immediately after placing the order?

The answer is no.

The shipping function here can actually follow the mq asynchronous processing logic.

@ Autowired

Private TransactionTemplate transactionTemplate

...

Public void save (final User user) {

TransactionTemplate.execute ((status) = > {

Order ()

Return Boolean.TRUE

})

SendMq ()

}

At this point, the study of "how to solve big business problems" is over. I hope to be able to solve everyone's doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.