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

分享一下我老师大神的人工智能教程！零基础，通俗易懂！http://blog.csdn.net/jiangjunshow

也欢迎大家转载本篇文章。分享知识，造福人民，实现我们中华民族伟大复兴！

               

典型的两个现实案例：

 

我们先看两个用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 的服务器. 这既得益于软件的进步, 也得益于硬件性能的提高，现在应该扩展讨论的是应该是C10M问题了。

 

参考资料：

 

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

 

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

 

不论线程还是进程，都不可能一个连接创建一个，相应的成本太大，多进程和多线程都有资源耗费比较大的问题，所以在高并发量的服务器端使用并不多。解决方案是一个线程或者进程处理多个连接，更具体的现在比较主流的是：Coroutine模型 和 非阻塞/异步IO(callback)，在分析这两个之前，我们先看看多进程和多线程的情况。

 

多进程

 

这种模型在linux下面的服务程序广泛采用，比如大名鼎鼎的apache。

 

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