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

Today, I will talk to you about how to elegantly implement concurrent scheduling tasks in web development, which may not be well understood by many people. In order to make you understand better, the editor has summarized the following for you. I hope you can get something according to this article.

Business scenario

When doing task development, you are bound to encounter the following scenarios:

Scenario 1: when calling a third-party interface, you need to call a different interface to assemble the data.

Scenario 2: the home page of an application may rely on many services. That involves interfaces that need to request multiple services at the same time when the page is loaded. This step is often called by the backend to uniformly call the assembly data and return it to the front end, which is the so-called BFF (Backend For Frontend) layer.

In view of the above two scenarios, assuming that serial calls are selected without strong dependencies, the total time consuming is:

Time=s1+s2+....sn

According to the promising young people who have reached millions per second, they have greeted your ancestors for such a long time.

For the sake of great KPI, we often choose to call these dependent interfaces concurrently. Then the total time spent is:

Time=max (s1 ~ 2 ~ 2 ~ 3 ~ 3 ~ n)

Of course, when you start to pile up business, you can serialize it first, and when the people above are in a hurry, you can show your best trick.

In this way, PPT can add a heavy flow account at the end of the year: improving XXX performance for an interface of the business, indirectly generating XXX value.

Of course, the premise of all this is that the boss does not understand the technology, and the technology "understands" you.

To get to the point, if you change it to concurrent calls, you might write this.

Package main import ("fmt"sync"time") func main () {var wg sync.WaitGroup wg.Add (2) var userInfo * User var productList [] Product go func () {defer wg.Done () userInfo, _ = getUser ()} () go func () {defer wg.Done () productList _ = getProductList ()} () wg.Wait () fmt.Printf ("user information:% + v\ n", userInfo) fmt.Printf ("commodity information:% + v\ n", productList)} / * user service * / type User struct {Name string Age uint8} func getUser () (* User Error) {time.Sleep (500 * time.Millisecond) var u User u.Name = "wuqinqiang" u.Age = 18 return & u, nil} / * goods and Services * / type Product struct {Title string Price uint32} func getProductList () ([] Product, error) {time.Sleep (400 * time.Millisecond) var list [] Product list = append (list) Product {Title: "SHib", Price: 10,}) return list, nil}

In terms of implementation, how many services are needed and how many gigabytes will be opened, making use of the features of sync.WaitGroup

Achieve the effect of concurrent scheduling tasks.

It doesn't seem to be a big problem.

But with the increase of code 996 business scenarios, you will find that many modules have similar functions, but the corresponding business scenarios are different.

So can we abstract a set of tools for this business scenario and hand over the specific business implementation to the business side?

Use

In line with the principle of not repeating the wheel, I searched the open source project and finally took a fancy to mapreduce, a tool in go-zero.

You can Google the term yourself.

It's easy to use. Let's modify the above code through it:

Package main import ("fmt"github.com/tal-tech/go-zero/core/mr"time") func main () {var userInfo * User var productList [] Product _ = mr.Finish (func () (err error) {userInfo, err = getUser () return err}, func () (err error) {productList Err = getProductList () return err}) fmt.Printf ("user Information:% + v\ n", userInfo) fmt.Printf ("Commodity Information:% + v\ n", productList)} / / print user Information: & {Name:wuqinqiang Age:18} Product Information: [{Title:SHib Price:10}]

Isn't it much more comfortable.

But it is also important to note here that if one of the services you invoke is wrong and your return err corresponds to the error, then the other invoked services will be cancelled.

For example, we modify getProductList to respond directly to errors.

Func getProductList () ([] Product, error) {return nil, errors.New ("test error")} / / print / / user information: / / Product information: []

Then the final printing time even the user information will be empty, because a service error occurred, the user service request was cancelled.

In general, we have a guaranteed operation when requesting a service error, and one service error cannot affect the results of other requests.

So the specific processing when using it depends on the business scenario.

Source code

Now that you've used it, let's catch up with the source code.

Func Finish (fns... func () error) error {if len (fns) = = 0 {return nil} return MapReduceVoid (func (source chan)

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.