前一篇文章《Golang并发模型:轻松入门流水线模型》,介绍了流水线模型的概念,这篇文章是流水线模型进阶,介绍FAN-IN和FAN-OUT,FAN模式可以让我们的流水线模型更好的利用Golang并发,提高软件性能。但FAN模式不一定是万能,不见得能提高程序的性能,甚至还不如普通的流水线。我们先介绍下FAN模式,再看看它怎么提升性能的,它是不是万能的。
Golang的并发模式灵感来自现实世界,这些模式是通用的,毫无例外,FAN模式也是对当前世界的模仿。以汽车组装为例,汽车生产线上有个阶段是给小汽车装4个轮子,可以把这个阶段任务交给4个人同时去做,这4个人把轮子都装完后,再把汽车移动到生产线下一个阶段。这个过程中,就有任务的分发,和任务结果的收集。其中任务分发是FAN-OUT,任务收集是FAN-IN。
fan-in和fan-out.png
我们这次试用FAN-OUT和FAN-IN,解决《Golang并发模型:轻松入门流水线模型》中提到的问题:计算一个整数切片中元素的平方值并把它打印出来。
producer()
保持不变,负责生产数据。squre()
也不变,负责计算平方值。main()
,启动3个square,这3个squre从producer生成的通道读数据,这是FAN-OUT。merge()
,入参是3个square各自写数据的通道,给这3个通道分别启动1个协程,把数据写入到自己创建的通道,并返回该通道,这是FAN-IN。FAN模式流水线示例:
1package main
2
3import (
4 "fmt"
5 "sync"
6)
7
8func producer(nums ...int) <-chan int {
9 out := make(chan int)
10 go func() {
11 defer close(out)
12 for _, n := range nums {
13 out <- i
14 }
15 }()
16 return out
17}
18
19func square(inCh <-chan int) <-chan int {
20 out := make(chan int)
21 go func() {
22 defer close(out)
23 for n := range inCh {
24 out <- n * n
25 }
26 }()
27
28 return out
29}
30
31func merge(cs ...<-chan int) <-chan int {
32 out := make(chan int)
33
34 var wg sync.WaitGroup
35
36 collect := func(in <-chan int) {
37 defer wg.Done()
38 for n := range in {
39 out <- n
40 }
41 }
42
43 wg.Add(len(cs))
44 // FAN-IN
45 for _, c := range cs {
46 go collect(c)
47 }
48
49 // 错误方式:直接等待是bug,死锁,因为merge写了out,main却没有读
50 // wg.Wait()
51 // close(out)
52
53 // 正确方式
54 go func() {
55 wg.Wait()
56 close(out)
57 }()
58
59 return out
60}
61
62func main() {
63 in := producer(1, 2, 3, 4)
64
65 // FAN-OUT
66 c1 := square(in)
67 c2 := square(in)
68 c3 := square(in)
69
70 // consumer
71 for ret := range merge(c1, c2, c3) {
72 fmt.Printf("%3d ", ret)
73 }
74 fmt.Println()
75}
3个squre协程并发运行,结果顺序是无法确定的,所以你得到的结果,不一定与下面的相同。
1➜ awesome git:(master) ✗ go run hi.go
2 1 4 16 9
相信你心里已经有了答案,可以的。我们还是使用老问题,对比一下简单的流水线和FAN模式的流水线,修改下代码,增加程序的执行时间:
produer()
使用参数生成指定数量的数据。square()
增加阻塞操作,睡眠1s,模拟阶段的运行时间。main()
关闭对结果数据的打印,降低结果处理时的IO对FAN模式的对比。普通流水线:
1// hi_simple.go
2
3package main
4
5import (
6 "fmt"
7)
8
9func producer(n int) <-chan int {
10 out := make(chan int)
11 go func() {
12 defer close(out)
13 for i := 0; i < n; i++ {
14 out <- i
15 }
16 }()
17 return out
18}
19
20func square(inCh <-chan int) <-chan int {
21 out := make(chan int)
22 go func() {
23 defer close(out)
24 for n := range inCh {
25 out <- n * n
26 // simulate
27 time.Sleep(time.Second)
28 }
29 }()
30
31 return out
32}
33
34func main() {
35 in := producer(10)
36 ch := square(in)
37
38 // consumer
39 for _ = range ch {
40 }
41}
使用FAN模式的流水线:
1// hi_fan.go
2package main
3
4import (
5 "sync"
6 "time"
7)
8
9func producer(n int) <-chan int {
10 out := make(chan int)
11 go func() {
12 defer close(out)
13 for i := 0; i < n; i++ {
14 out <- i
15 }
16 }()
17 return out
18}
19
20func square(inCh <-chan int) <-chan int {
21 out := make(chan int)
22 go func() {
23 defer close(out)
24 for n := range inCh {
25 out <- n * n
26 // simulate
27 time.Sleep(time.Second)
28 }
29 }()
30
31 return out
32}
33
34func merge(cs ...<-chan int) <-chan int {
35 out := make(chan int)
36
37 var wg sync.WaitGroup
38
39 collect := func(in <-chan int) {
40 defer wg.Done()
41 for n := range in {
42 out <- n
43 }
44 }
45
46 wg.Add(len(cs))
47 // FAN-IN
48 for _, c := range cs {
49 go collect(c)
50 }
51
52 // 错误方式:直接等待是bug,死锁,因为merge写了out,main却没有读
53 // wg.Wait()
54 // close(out)
55
56 // 正确方式
57 go func() {
58 wg.Wait()
59 close(out)
60 }()
61
62 return out
63}
64
65func main() {
66 in := producer(10)
67
68 // FAN-OUT
69 c1 := square(in)
70 c2 := square(in)
71 c3 := square(in)
72
73 // consumer
74 for _ = range merge(c1, c2, c3) {
75 }
76}
多次测试,每次结果近似,结果如下:
1➜ awesome git:(master) ✗ time go run hi_simple.go
2go run hi_simple.go 0.17s user 0.18s system 3% cpu 10.389 total
3➜ awesome git:(master) ✗
4➜ awesome git:(master) ✗ time go run hi_fan.go
5go run hi_fan.go 0.17s user 0.16s system 7% cpu 4.288 total
也可以使用Benchmark进行测试,看2个类型的执行时间,结论相同。为了节约篇幅,这里不再介绍,方法和结果贴在Gist了,想看的朋友瞄一眼,或自己动手搞搞。
FAN模式可以提高并发的性能,那我们是不是可以都使用FAN模式?
不行的,因为FAN模式不一定能提升性能。
依然使用之前的问题,再次修改下代码,其他不变:
squre()
去掉耗时。main()
增加producer()的入参,让producer生产10,000,000个数据。简单版流水线修改代码:
1// hi_simple.go
2
3func square(inCh <-chan int) <-chan int {
4 out := make(chan int)
5 go func() {
6 defer close(out)
7 for n := range inCh {
8 out <- n * n
9 }
10 }()
11
12 return out
13}
14
15func main() {
16 in := producer(10000000)
17 ch := square(in)
18
19 // consumer
20 for _ = range ch {
21 }
22}
FAN模式流水线修改代码:
1// hi_fan.go
2package main
3
4import (
5 "sync"
6)
7
8func square(inCh <-chan int) <-chan int {
9 out := make(chan int)
10 go func() {
11 defer close(out)
12 for n := range inCh {
13 out <- n * n
14 }
15 }()
16
17 return out
18}
19
20func main() {
21 in := producer(10000000)
22
23 // FAN-OUT
24 c1 := square(in)
25 c2 := square(in)
26 c3 := square(in)
27
28 // consumer
29 for _ = range merge(c1, c2, c3) {
30 }
31}
结果,可以跑多次,结果近似:
1➜ awesome git:(master) ✗ time go run hi_simple.go
2go run hi_simple.go 9.96s user 5.93s system 168% cpu 9.424 total
3➜ awesome git:(master) ✗ time go run hi_fan.go
4go run hi_fan.go 23.35s user 11.51s system 297% cpu 11.737 total
从这个结果,我们能看到2点。
既然FAN模式不一定能提高性能,如何优化?
不同的场景优化不同,要依具体的情况,解决程序的瓶颈。
我们当前程序的瓶颈在FAN-IN,squre函数很快就完成,merge函数它把3个数据写入到1个通道的时候出现了瓶颈,适当使用带缓冲通道可以提高程序性能,再修改下代码
merge()
中的out
修改为:1out := make(chan int, 100)
结果:
1➜ awesome git:(master) ✗ time go run hi_fan_buffered.go
2go run hi_fan_buffered.go 19.85s user 8.19s system 323% cpu 8.658 total
使用带缓存通道后,程序的性能有了较大提升,CPU利用率提高到323%,提升了8%,运行时间从11.7降低到8.6,降低了26%。
FAN模式的特点很简单,相信你已经掌握了,如果记不清了看这里,本文所有代码在该Github仓库,阅读原文可查看:
https://github.com/Shitaibin/golang_pipeline_step_by_step。
FAN模式很有意思,并且能提高Golang并发的性能,如果想以后运用自如,用到自己的项目中去,还是要写写自己的Demo,快去实践一把。
下一篇,写流水线中协程的“优雅退出”,欢迎关注。