Skip to content

0x9e3779b9/golang_lab

Repository files navigation

golang_lab

golang_test lab

golang学习使用笔记

=====备忘录=====

最简模型

while(1) { accept(); recv(); do(); send(); } 这是服务端程序的最简模型: 来一个连接,读取数据(请求),干活(处理),返回数据(应答)。 同一时间只为一个客户端服务。

#事件驱动 要考虑支持多个客户端,就有了选择,有了选择就叫设计。 我们有两个选择:

  1. 采用select或poll(epoll)多路复用技术,同时监听多个连接以及listen socket的事件。这个叫事件驱动。
  2. 采用多线程(进程)技术,主线程accept一个连接,就创建或者从线程池中分配一个线程,一个线程处理一个连接。这个叫线程驱动。

两者其实没有本质区别,都是中断驱动。

第一个增加了编程的难度,我们需要把所有可能的阻塞点,都放入监听队列,避免一个连接阻塞掉所有连接。 第二个增加了线程调度和CPU状态切换开销,却大大降低了编程难度,你不用管是否阻塞,你干不下去的时候,内核会帮你把CPU让给其他线程,一个线程只有一个连接,可以像串一串糖葫芦那样写代码。

coroutine

线程驱动是对事件驱动的一种封装,降低了编程难度,内核帮你干了!不过你可能不满意。 如果追求最大性能,就需要更大的技术难度,自己做内核帮你做的事情。 这个方向做到极致就是用户态线程,还是按照一个连接一个线程的串行模式编写代码,只不过这些线程不由内核调度,开销很低。这些线程叫做协程(coroutine)或者说纤程,或者其他古怪的名号。总之就是一样,对事件驱动的封装,对低效内核调度的替代。为什么比内核调度快?因为一直工作在用户态,没有CPU状态的切换。

Swapcontext

swapcontext 可以帮助我们完成用户态的上下文切换;swapcontext 特别像内核的schedule(switch_to)函数。你可以man它。 完美的协程库需要处理所有可能导致阻塞的系统调用,或者preload动态库,或者符号重定义,或者让用户使用封装函数。

无知的小白:写下如下代码 Coroutine.run(func1); Coroutine.run(func2); func1 使用read从网络连接中读取数据,并打印;网络上尚无数据到来。 func2 从内存中读取数据,并打印

结果func2瞬间完成数据打印,并不被func1阻塞。 5s后,网络来了数据,read返回,func1也打印出数据。

协程库做什么? 协程库有一个主循环(上下文),主循环内扫描就绪协程列表,按照策略比如简单的FIFO,选择一个执行

上述例子中,先选择了func1,并swapcontext到func1的入口;func1调用了read,read被协程库重写了,fd被设置为非阻塞,并把它的读事件放入epoll的监听队列,设置协程为等待状态,从协程列表删除,然后swapcontext进入主循环,主循环继续扫描协程列表,发现了func2,同样swapcontext到func2,读取内存,打印数据,没有协程库重定义的函数调用,func2完毕后,返回主循环,继续扫描协程列表;这时队列中没有就绪协程了,进入epoll_wait等待,5s后,网络有数据,epoll_wait返回,根据事件信息,func1被重新设置为就绪,进入协程列表,得以继续执行。

相比内核态的线程,协程轻如鸿毛,几万甚至几十万的不是事儿。

golang

沿着这个思路继续走下去,就是一个语言了,比如像go语言这种,提供了goroutine,也是用户态轻量级线程。 golang太适合后端服务器程序开发了,简洁明快,活波可爱,找小三就找这种。 程序员怎么可以没有小三,抱着java和C++过一辈子? ——开玩笑了,工具而已,语言多学几门没有坏处,可以帮助我们建立更统一和深刻的技术理解。

多核

多核多CPU的情况下,世界有点不同了,任务可以并行了。 ——并发是多少事件同时发生,并行是多少事件同时执行。在任务这个层次,单CPU只有并发问题,没有并行问题。(流水线导致的指令并发对程序员不可见)

你有10个CPU,10个线程可以同时跑互不干扰;如果你只有10个连接的并发,那么其用线程驱动也很美妙和极速。 真的吗?怎么可能!这世界上最可恶的就是多核,它把我们带入并行的深渊;但并行度并不足以应对我们面对的并发容量,动辄上万甚至更高的高并发场景下,你还是要事件驱动,同时还需要充分利用多核,处理好并行。

多线程(进程)事件驱动

每个核上都运行一个线程,每一个线程都有一个事件驱动循环,这叫做多线程(进程)事件驱动。我们可以多个线程同时accept同一个fd。

惊群

如今的内核早就没那么傻了,accept不会惊群,内核使用exclusive放入等待队列,一次只唤醒一个线程,并且是按照FIFO顺序来的。也就说你有多个线程同时accept,内核会采用轮转的方式均匀的分配新连接。

不过你用select或者poll就不行了。select和poll没有使用exclusive方式进入等待队列,唤醒的时候,同时唤醒,但只有一个可以accept成功——典型的惊了群,不过这才符合自然现象,地震了谁都知道,第一个跑出去的只有一个。

epoll所有的等待都是exclusive方式(eventfd可能会有麻烦),但必须所有的线程(进程)使用同一个epoll实例(由epoll_create创建)。

NUMA

如果并发量非常大,accept队列经常都是满的,这时候不会等待,并发执行accept的线程非常多,但accept首先申请一个锁:lock_sock(sk); 这个锁是mutex,高并发的场景可能导致饥饿问题,尤其是在NUMA场景下,CPU访问内存的速度是不同的,有些线程可能连续几次都抢不到这个锁,accept就不均衡了。我曾经写过一简单的测试程序测试两个线程,绑定到同一个物理CPU上的两个核,accept到连接的比例是1:1,但如果是绑定到两个不同物理CPU就变成4:3了。如果竞争更加激烈比例可能会更不均衡。

SO_REUSEPORT

针对accept多线程负载不均衡的问题,google的大神们,提交了一个补丁 http://lwn.net/Articles/542629/ 新增了一个socket选项——SO_REUSEPORT ,有了这个选项后,多个线程同时accept一个listen fd时,内核会根据新连接的ip地址和端口的hash值来选择线程。在客户端大量和hash算法均匀的情况下,负载会均匀。 不过我觉得,只需要让lock_sock用排队锁,就可以解决不均衡的问题了。

免锁算法

多核并行时代,锁是最大的敌人。大家开始关注和研究免锁算法,大多数免锁算法的设计和实现非常复杂,很难用于项目实践。 单消费者单生产者的环形队列最成熟最有效的一种,很多其他的基于cas+busywait的免锁队列,本质就是自旋锁而已,却远远不如直接使用封装好的自旋锁简洁,只是有助于炫技罢了。

多核时代高性能的心法是不要想什么免锁算法,而是想办法减少或消除共享,让线程独立而自由的飞翔。

线程独立

有些场景,连接之间共享资源很少,每一个线程独立accept独立事件循环,可以很happy,天然的免锁。 有些场景,就很悲催,比如一个用户,一个IP,但是可以有多个连接,而业务逻辑又是以用户作为基本处理单元,而不是一个连接。这个场景,靠内核给你分配连接,就无法保证同一个用户的连接只到一个线程内。 你需要自己分配。如果google那个补丁可以选择参与hash的元素,岂不是很美妙,比如只按客户端地址hash,同一个用户自然只会跑到同一个线程了。 ——还好,内核是开源的,你或许可以自己修改它。

1:N 和 M:N

如果不修改内核,就需要一个分配线程,只做accept和连接分配这一件事情,其他多个工作线程负责处理。分配策略就按用户IP hash分配。

这是一个典型的1:N场景,有什么特殊意义呢,这意味着分配线程把新连接(或其他通信内容)发给工作线程可以使用环形队列,每个工作线程一个队列,都是单生产者单消费1:1的队列,可以完全免锁。

如果并发连接太多,一个分配线程搞不定,就很悲催,M:N 无法简单的化为1:1的通信模型。

内存池

在线程独立,减少共享这个设计思想前提下,内存池应该是线程私有的;每一个线程的内存池都是独立的,没有并发请求,这样的内存池会非常简单和高效。

每个内存池管理的内存块,设计成固定大小,相比支持各种大小的通用的系统malloc,实现大大简化,性能会大幅度提高。

预先申请好内存,按照分配大小切分成内存块;只需要一个简单的队列(链表)维护空闲的内存块即可;申请释放就是入队和出队,当然这个队列应该是后进先出(LIFO)的,这样可以增加cache命中。

可以在内存块前端或尾部埋入cookie,做一些可靠性设计,异常时及时coredump,C或C++最怕内存越界,越早挂掉,越接近犯罪现场越好分析。

About

golang_test lab

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published