并发：严格意义上来说并发分为内核态，和用户态。

内核态：单个CPU处理一个进程，多个CPU 同时处理多个进程

用户态：单个的CPU的情况下，用户通过编程，在一个进程中通过多尔线程来实现并发

Go 的并发属于 CSP 并发模型的一种实现，
CSP 并发模型的核心概念是：“不要通过共享内存来通信，而应该通 过通信来共享内存”。
这在 Go 语言中的实现就是 Goroutine 和 Channel。

实例解析一：

go实现一个线程池假定场景：

某平台的一个Restful 接口，该接口被调用后去处理一些事情，但是客户端需要快速得到响应，业务的处理过程将在后台继续进行。程序中我们可以开启一个协程去处理

对于一定量的负载，这种处理没问题，但是当大量请求时，程序会不断创建新的协程，进而导致程序崩溃所以有必要去控制创建goroutine 的数量。

实例解析二：

严格意义上来说上面处理并不是真正的并发处理。这种方法使用了缓冲队列一定程度上了提高了并发，但也是治标不治本，大规模并发只是推迟了问题的发生时间。当请求速度远大于队列的处理速度时，缓冲区很快被打满，后面的请求一样被堵塞了。

实例解析三：

真正意义上的并发处理请求

思想：领导 — > 工人 ---- > 任务

领导便是协程池，工人便是一个个协程，任务就是工人要做的事

通过一个二级通道实现 高并发控制

参考：
http://marcio.io/2015/07/handling-1-million-requests-per-minute-with-golang/

注意到：
我们提供了初始化并加入到池子的worker的最大数量。

因为这个工程我们利用了Amazon Elasticbeanstalk带有的docker化的Go环境，所以我们常常会遵守12-factor方法论来配置我们的生成环境中的系统，我们从环境变了读取这些值。

这种方式，我们控制worker的数量和JobQueue的大小，所以我们可以很快的改变这些值，而不需要重新部署集群。

结果:
我们部署了之后，立马看到了延时降到微乎其微的数值，并未我们处理请求的能力提升很大。Elastic Load Balancers完全启动后，我们看到ElasticBeanstalk 应用服务于每分钟1百万请求。

通常情况下在上午时间有几个小时，流量峰值超过每分钟一百万次。

我们一旦部署了新的代码，服务器的数量从100台大幅 下降到大约20台。

我们合理配置了我们的集群和自动均衡配置之后，我们可以把服务器的数量降至4x EC2 c4.Large实例，并且Elastic Auto-Scaling设置为如果CPU达到5分钟的90%利用率，我们就会产生新的实例。