前一篇文章《Golang并发模型：轻松入门流水线模型》，介绍了流水线模型的概念，这篇文章是流水线模型进阶，介绍FAN-IN和FAN-OUT，FAN模式可以让我们的流水线模型更好的利用Golang并发，提高软件性能。但FAN模式不一定是万能，不见得能提高程序的性能，甚至还不如普通的流水线。我们先介绍下FAN模式，再看看它怎么提升性能的，它是不是万能的。

FAN-IN和FAN-OUT模式

Golang的并发模式灵感来自现实世界，这些模式是通用的，毫无例外，FAN模式也是对当前世界的模仿。以汽车组装为例，汽车生产线上有个阶段是给小汽车装4个轮子，可以把这个阶段任务交给4个人同时去做，这4个人把轮子都装完后，再把汽车移动到生产线下一个阶段。这个过程中，就有任务的分发，和任务结果的收集。其中任务分发是FAN-OUT，任务收集是FAN-IN。

Golang中我们使用Channel或者sync.Mutex等锁保护数据，有没有一种机制可以检测代码中的数据竞争呢？

背景知识

数据竞争是并发情况下，存在多线程/协程读写相同数据的情况，必须存在至少一方写。另外，全是读的情况下是不存在数据竞争的。

使用race检测数据竞争

go build有个标记race可以帮助检测代码中的数据竞争。

1
2
3
4
5

➜  awesome git:(master) ✗ go help build
//.... omit
-race
		enable data race detection.
		Supported only on linux/amd64, freebsd/amd64, darwin/amd64 and windows/amd64.

网上写govendor的博文不少，但从安装到介绍，总看上去有些沉重，下面奉上一篇简单的教程，3分钟入门。

第1部分 简明教程

2步走，3分钟轻松搞定Go项目的依赖。

第1步 安装

1

go get -u github.com/kardianos/govendor

Golang作为一个实用主义的编程语言，非常注重性能，在语言特性上天然支持并发，它有多种并发模型，通过流水线模型系列文章，你会更好的使用Golang并发特性，提高你的程序性能。

这篇文章主要介绍流水线模型的流水线概念，后面文章介绍流水线模型的FAN-IN和FAN-OUT，最后介绍下如何合理的关闭流水线的协程。

Golang的并发核心思路

Golang并发核心思路是关注数据流动。数据流动的过程交给channel，数据处理的每个环节都交给goroutine，把这些流程画起来，有始有终形成一条线，那就能构成流水线模型。

但我们先从简单的入手。

你是不是觉得defer很简单、很好用，但也许你掉坑里了都不知道！

这篇文章不介绍defer的常用功能，而是介绍你在用defer时，也许会踩的坑。

defer允许我们进行一些函数执行完成后的收尾工作，并且代码更加简洁，例如：

1. 关闭文件流：

   1 2	// open a file defer file.Close()

网上已搜索golang pprof，资料不少，简明高效的一个没看到，这篇文章5步教你用会pprof获取cpu和内存prof。

第1步：安装易用的pprof

golang自带的prof包是runtime/pprof，这个是低级别的，需要你手动做一些设置等等周边工作，不利于我们快速上手，利用pprof帮助我们解决实际的问题。这里推荐davecheney封装的pprof，它可以1行代码，让你用上pprof，专心解决自己的代码问题，下载：

1

go get github.com/pkg/profile

无论是无缓冲通道，还是有缓冲通道，都存在阻塞的情况，教你一招再也不遇到channel阻塞的问题。

这篇文章会介绍，哪些情况会存在阻塞，以及如何使用select解决阻塞。

阻塞场景

阻塞场景共4个，有缓存和无缓冲各2个。

无缓冲通道的特点是，发送的数据需要被读取后，发送才会完成，它阻塞场景：

1. 通道中无数据，但执行读通道。
2. 通道中无数据，向通道写数据，但无协程读取。

sync.WaitGroup是并发环境中，一个相当常用的数据结构，用来等待所有协程的结束，在写代码的时候都是按着例子的样子写的，也没用深究过它的使用。前几日想着能不能在协程中执行Add()函数，答案是不能，这里介绍下。

陷阱在WaitGroup的3个函数的调用顺序上。先回顾下3个函数的功能：

1. Add(delta int)：给计数器增加delta，比如启动1个协程就增加1。
2. Done()：协程退出前执行，把计数器减1。
3. Wait()：阻塞等待计数器为0。

在看《Go入门指南》的一种用闭包处理错误的模式时，里面提到了一种错误的优雅处理方式，减少我们重复写if err:=f(); err != nil{}式的代码，感觉很心动，做了下测试，结论如下：

1. 能减少if err式的代码，代码可以变清新整洁。
2. 使用存在限制：只有当错误需要结束调用时才可以使用这种方法，如果被调用函数返回错误，但调用者函数需处理错误后，向下继续执行，则不能采用这种方法。

过去在学Actor模型的时候，就认为异步消息是相当的重要，在华为的时候，也深扒了一下当时产品用的消息模型，简单实用，支撑起了很多模块和业务，但也有一个缺点是和其他的框架有耦合，最近看到以太坊的事件框架，同样简单简洁，理念很适合初步接触事件框架的同学，写文介绍一下。

以太坊的事件框架是一个单独的基础模块，存在于目录go-ethereum/event中，它有2中独立的事件框架实现，老点的叫TypeMux，已经基本弃用，新的叫Feed，当前正在广泛使用。

TypeMux和Feed还只是简单的事件框架，与Kafka、RocketMQ等消息系统相比，是非常的传统和简单，但是TypeMux和Feed的简单简洁，已经很好的支撑以太坊的上层模块，这是当下最好的选择。

TypeMux和Feed各有优劣，最优秀的共同特点是，他们只依赖于Golang原始的包，完全与以太坊的其他模块隔离开来，也就是说，你完全可以把这两个事件框架用在自己的项目中。

TypeMux的特点是，你把所有的订阅塞给它就好，事件来了它自会通知你，但有可能会阻塞，通知你不是那么及时，甚至过了一段挺长的时间。

Feed的特点是，它通常不存在阻塞的情况，会及时的把事件通知给你，但需要你为每类事件都建立一个Feed，然后不同的事件去不同的Feed上订阅和发送，这其实挺烦人的，如果你用错了Feed，会导致panic。

接下来，介绍下这种简单事件框架的抽象模型，然后再回归到以太坊，介绍下TypeMux和Feed。