[转]Golang适合高并发场景的原因分析

来源：http://blog.csdn.net/ghj1976/article/details/27996095

作者：蝈蝈俊

典型的两个现实案例：

我们先看两个用Go做消息推送的案例实际处理能力。

360消息推送的数据：

16台机器，标配：24个硬件线程。64GB内存 
Linux Kernel 2.6.32 x86_64 
单机80万并发连接，load 0.2~0.4，CPU 总使用率 7%~10%，内存占用20GB (res) 
眼下接入的产品约1280万在线用户 
2分钟一次GC。停顿2秒 (1.0.3 的 GC 不给力，直接升级到 tip，再次吃螃蟹) 
15亿个心跳包/天，占大多数。

 

京东云消息推送系统

(团队人数:4) 
单机并发tcp连接数峰值118w 
内存占用23G(Res) 
Load 0.7左右 
心跳包 4k/s 
gc时间2-3.x s

C10K问题

为什么能够支撑这么高并发的请求呢？我们先从C10K问题说起：2001年左右的时候，有一个叫Dan Kegel的人在网上提出：如今的硬件应该能够让一台机器支持10000个并发的client。

然后他讨论了用不同的方式实现大规模并发服务的技术。

http://www.kegel.com/c10k.html （英文版）

http://www.oschina.net/translate/c10k （中文翻译版） 
http://www.cnblogs.com/fll/archive/2008/05/17/1201540.html

当然， 如今C10K 已经不是问题了, 不论什么一个普通的程序猿, 都能利用手边的语言和库, 轻松地写出 C10K 的server. 这既得益于软件的进步, 也得益于硬件性能的提高。如今应该扩展讨论的是应该是C10M问题了。

參考资料：

千万级并发实现的秘密：内核不是解决方式，而是问题所在。 
http://www.csdn.net/article/2013-05-16/2815317-The-Secret-to-10M-Concurrent-Connections

Coroutine模型 和 非堵塞/异步IO(callback)

不论线程还是进程，都不可能一个连接创建一个。对应的成本太大。多进程和多线程都有资源耗费比較大的问题。所以在高并发量的server端使用并不多。

解决方式是一个线程或者进程处理多个连接，更详细的如今比較主流的是：Coroutine模型 和 非堵塞/异步IO(callback)，在分析这两个之前，我们先看看多进程和多线程的情况。

多进程

这样的模型在linux以下的服务程序广泛採用。比方大名鼎鼎的apache。

下图说明了Apache的生命周期（prefork模式）。主进程负责监听和管理连接。而详细的业务处理都会交给子进程来处理。

这样的架构的最大的优点是隔离性，子进程万一crash并不会影响到父进程。缺点就是对系统的负担过重，想像一下假设有上万的连接。会须要多少进程来处理。

所以这样的模型比較合适那种不须要太多并发量的server程序。

另外，进程间的通讯效率也是一个瓶颈之中的一个。大部分会採用share memory等技术来减低通讯开销。

apache的处理能力。以下有几篇文章：

2008年时的数据：http://www.blogjava.net/daniel-tu/archive/2008/12/29/248883.html

http://wenku.baidu.com/view/c527582a453610661ed9f40f.html

Apache的问题

Apache的问题在于server的性能会随着连接数的增多而变差 
关键点：性能和可扩展性并非一回事。当人们谈论规模时，他们往往是在谈论性能，可是规模和性能是不同的，比方Apache。 
持续几秒的短期连接，比方快速事务。假设每秒处理1000个事务，仅仅有约1000个并发连接到server。 
事务延长到10秒，要维持每秒1000个事务，必须打开1万个并发连接。这样的情况下：虽然你不顾DoS攻击。Apache也会性能陡降；同一时候大量的下载操作也会使Apache崩溃。 
假设每秒处理的连接从5千添加到1万，你会怎么做？比方说。你升级硬件并且提高处理器速度到原来的2倍。

发生了什么？你得到两倍的性能。但你没有得到两倍的处理规模。每秒处理的连接可能仅仅达到了6000。你继续提快速度，情况也没有改善。

甚至16倍的性能时，仍然不能处理1万个并发连接。所以说性能和可扩展性是不一样的。 
问题在于Apache会创建一个CGI进程，然后关闭，这个步骤并没有扩展。 
为什么呢？内核使用的O(N^2)算法使server无法处理1万个并发连接。 
内核中的两个基本问题： 
连接数=线程数/进程数。当一个数据包进来。内核会遍历其全部进程以决定由哪个进程来处理这个数据包。

 
连接数=选择数/轮询次数（单线程）。

相同的可扩展性问题，每一个包都要走一遭列表上全部的socket。

 
解决方法：改进内核使其在常数时间内查找。 
使线程切换时间与线程数量无关。 
使用一个新的可扩展epoll()/IOCompletionPort常数时间去做socket查询。

參考:http://www.csdn.net/article/2013-05-16/2815317-The-Secret-to-10M-Concurrent-Connections

 

多线程

这样的模型在windows以下比較常见。它使用一个线程来处理一个client。他的优点是编程简单，最重要的是你会有一个清晰连续顺序的work flow。

简单意味着不easy出错。

这样的模型的问题就是太多的线程会减低软件的运行效率。

 

线程和进程的成本

普通的线程，须要消耗1M的堆栈 
http://www.cnblogs.com/PurpleTide/archive/2010/11/12/1875763.html

多进程和多线程的优缺点...  
http://blog.163.com/ymguan@yeah/blog/static/140072872201147832740/

我们知道。操作系统的最小调度单元是“线程”，要运行不论什么一段代码，都必须落实到“线程”上。可惜线程太重，资源占用太高，频繁创建销毁会带来比較严重的性能问题，于是又诞生出线程池之类的常见使用模式。也是相似的原因。“堵塞”一个线程往往不是一个好主意。由于线程虽然暂停了。可是它所占用的资源还在。线程的暂停和继续对于调度器都会带来压力，并且线程越多，调度时的开销便越大。这当中的平衡非常难把握。

针对这个问题，有两类架构解决它：基于callback和coroutine的架构。

 

Callback- 非堵塞/异步IO

这样的架构的特点是使用非堵塞的IO，这样server就能够持续运转，而不须要等待，能够使用非常少的线程，即使仅仅有一个也能够。须要定期的任务能够採取定时器来触发。把这样的架构发挥到极致的就是node.js,一个用javascript来写server端程序的框架。

在node.js中，全部的io都是non-block的，能够设置回调。

举个样例来说明一下。 
传统的写法:

 var file = open(‘my.txt’);
 var data = file.read(); //block
 sleep(1);
 print(data); //block

node.js的写法:

 fs.open(‘my.txt’,function(err,data){
    setTimeout(1000,function(){
       console.log(data);
    }
 }); //non-block

这样的架构的优点是performance会比較好，缺点是编程复杂。把曾经连续的流程切成了非常多片段。

另外也不能充分发挥多核的能力。

 

Coroutine-协程

coroutine本质上是一种轻量级的thread，它的开销会比使用thread少非常多。多个coroutine能够依照次序在一个thread里面运行。一个coroutine假设处于block状态，能够交出运行权。让其它的coroutine继续运行。

非堵塞I/O模型协程(Coroutines)使得开发人员能够採用堵塞式的开发风格,却能够实现非堵塞I/O的效果隐式事件调度,

简单来说：协程十分轻量，能够在一个进程中运行有数以十万计的协程。依然保持高性能。

进程、线程、协程的关系和差别：

• 进程拥有自己独立的堆和栈，既不共享堆，亦不共享栈，进程由操作系统调度。

• 线程拥有自己独立的栈和共享的堆，共享堆，不共享栈。线程亦由操作系统调度(标准线程是的)。
• 协程和线程一样共享堆，不共享栈，协程由程序猿在协程的代码里显示调度。

堆和栈的差别请參看：http://www.cnblogs.com/ghj1976/p/3623037.html

协程和线程的差别是：协程避免了无意义的调度。由此能够提高性能，但也因此，程序猿必须自己承担调度的责任。

运行协程仅仅须要极少的栈内存（大概是4～5KB），默认情况下。线程栈的大小为1MB。

goroutine就是一段代码。一个函数入口。以及在堆上为其分配的一个堆栈。所以它非常便宜，我们能够非常轻松的创建上万个goroutine。但它们并非被操作系统所调度运行。

Google go语言对coroutine使用了语言级别的支持。使用keywordgo来启动一个coroutine(从这个keyword能够看出Go语言对coroutine的重视),结合chan(相似于message queue的概念)来实现coroutine的通讯，实现了Go的理念 ”Do not communicate by sharing memory; instead, share memory by communicating.”。

 

http://my.oschina.net/Obahua/blog/144549

goroutine 的一个主要特性就是它们的消耗；创建它们的初始内存成本非常低廉（与须要 1 至 8MB 内存的传统 POSIX 线程形成鲜明对照）以及依据须要动态增长和缩减占用的资源。这使得 goroutine 会从 4096 字节的初始栈内存占用開始按需增长或缩减内存占用，而无需操心资源的耗尽。

为了实现这个目标。链接器（5l、6l 和 8l）会在每一个函数前插入一个序文。这个序文会在函数被调用之前检查推断当前的资源是否满足调用该函数的需求（备注 1）。假设不满足，则调用 runtime.morestack 来分配新的栈页面（备注 2），从函数的调用者那里拷贝函数的參数。然后将控制权返回给调用者。此时，已经能够安全地调用该函数了。当函数运行完成，事情并没有就此结束。函数的返回參数又被拷贝至调用者的栈结构中，然后释放没用的栈空间。

通过这个过程，有效地实现了栈内存的无限使用。假设你并非不断地在两个栈之间往返，通俗地讲叫栈切割，则代价是十分低廉的。

 

简单来说:Go语言通过系统的线程来多路派遣这些函数的运行，使得每一个用gokeyword运行的函数能够运行成为一个单位协程。当一个协程堵塞的时候。调度器就会自己主动把其它协程安排到另外的线程中去运行，从而实现了程序无等待并行化运行。并且调度的开销非常小，一颗CPU调度的规模不下于每秒百万次。这使得我们能够创建大量的goroutine，从而能够非常轻松地编写高并发程序，达到我们想要的目的。

 

Coroutine模型 和 非堵塞/异步IO(callback)性能对照

从性能角度来说，callback的典型node.js和golang的性能測试结果，两者几乎相同，參考以下測试数据：

http://www.cnblogs.com/QLeelulu/archive/2012/08/12/2635261.html

只是从代码可读性角度来说。callback确实有点不太好。

 

 

 

參考资料： 
风格之争：Coroutine模型 vs 非堵塞/异步IO(callback) 
http://blog.csdn.net/kjfcpua/article/details/15809703

Goroutine（协程）为何能处理大并发？
http://www.cnblogs.com/ghj1976/p/3642513.html

python Eventlet 
http://www.360doc.com/content/14/0522/00/8504707_379786818.shtml

为什么我觉得goroutine和channel是把别的平台上类库的功能内置在语言里
http://blog.zhaojie.me/2013/04/why-channel-and-goroutine-in-golang-are-buildin-libraries-for-other-platforms.html

Go-简洁的并发
http://www.yankay.com/go-clear-concurreny/

GOROUTINE性能測试
http://www.kankanews.com/ICkengine/archives/115285.shtml

Golang特性介绍
http://mryufeng.iteye.com/blog/576968/

并发编程
http://book.2cto.com/201301/14436.html

转载于:https://www.cnblogs.com/ljbguanli/p/6772444.html