epoll

Redis架构 1.1.问题 redis是单线程，单实例，为什么并发那么多，依旧很快呢？ 回答：因为调用了系统内核的epoll 1.2.Linux的早期版本 Linux有Linux kernal，我们的客户端，进行连接，首先到达的是Linux kernal，在Linux的早期版本，只有read和write进行文件读写。我们使用一个线程/进程 进行调用read和write函数，那么将会返回一个文件描述符fd(file description)。我们开启线程/进程去调用read进行读取。因为socket在这个时期是blocking（阻塞的），遇到高并发，就会阻塞，也就是bio时期。 1.3.内核的跃迁 Linux kernal在之后的发展，有了很大的变化，Linux到达率NIO时期。我们可以使用客户端进行轮询访问。但是，我们如果打进1000个线程访问，那么成本就会很大。我们出现了select函数，select函数和pselect函数，我们可以直接传1000个文件描述符，一旦有返回，那么再去调read函数。这个叫做多路复用的NIO。 紧接着，内核再次跃迁，我们出现了一个共享空间，通过mmap进行空间映射。（本质是红黑树+链表//红黑树是一种自平衡的二叉查找树）。我们将1000个文件描述符写进共享空间，如果我们的数据有返回，那么加入链表，我们从链表取出调用read进行读取

背景: 在实际的互联网使用过程中，大家熟知的是使用域名来直接访问一个服务，但随着互联网业务架构的不断优化，可能对用用户来说访问一个域名获取到相关的资源是很简单的一步，但其实对于互联网整个请求过程其实是做了很多次调用，那最开始的一步就是dns解析。当然在linux环境下，用来做dns解析的工具有很多，比如 dig 和 nslookup 之类的，但是通常对于复杂问题的排查直接去机器上去很显然是不太现实的，因此打算使用golang的接口来封装域名解析服务，来提供后期的操作. 1. net包的使用 和dns相关结构体方法 # nameserver结构体 type NS struct { Host string } # srv记录 指定该域名由哪个DNS服务器来进行解析 type SRV struct { Target string Port uint16 Priority uint16 Weight uint16 } # dns正向解析(域名解析到cname或者实际的ip地址) ## 仅返回指定域名name的cname地址 func LookupCNAME(name string) (cname string, err error) ## 直接返回域名解析到地址. func LookupHost(host string) (addrs []string, err error) ##

开发高性能网络程序时，windows开发者们言必称iocp，linux开发者们则言必称epoll。大家都明白epoll是一种IO多路复用技术，可以非常高效的处理数以百万计的socket句柄，比起以前的select和poll效率高大发了。我们用起epoll来都感觉挺爽，确实快，那么，它到底为什么可以高速处理这么多并发连接呢？ 先简单回顾下如何使用C库封装的3个epoll系统调用吧。 [cpp] view plain copy int epoll_create( int size); int epoll_ctl( int epfd, int op, int fd, struct epoll_event *event); int epoll_wait( int epfd, struct epoll_event *events, int maxevents, int timeout); 使用起来很清晰，首先要调用epoll_create建立一个epoll对象。参数size是内核保证能够正确处理的最大句柄数，多于这个最大数时内核可不保证效果。 epoll_ctl可以操作上面建立的epoll，例如，将刚建立的socket加入到epoll中让其监控，或者把 epoll正在监控的某个socket句柄移出epoll，不再监控它等等。 epoll_wait在调用时，在给定的timeout时间内

The following code essentially cats a file with select.select(): f = open('node.py') fd = f.fileno() while True: r, w, e = select.select([fd], [], []) print '>', repr(os.read(fd, 10)) time.sleep(1) When I try a similar thing with epoll I get an error: self._impl.register(fd, events | self.ERROR) IOError: [Errno 1] Operation not permitted I've also read that epoll does not support disk files -- or perhaps that it doesn't make sense. Epoll on regular files But why does select() support disk files then? I looked at the implementation in selectmodule.c and it seems to just be going through to the

io模型： 1.阻塞I/O模型 在linux中，默认情况下所有的socket都是blocking，一个典型的读操作流程大概是这样： 当用户进程调用了recvfrom这个系统调用，kernel就开始了IO的第一个阶段：准备数据。对于network io来说，很多时候数据在一开始还没有到达（比如，还没有收到一个完整的UDP包）， 这个时候kernel就要等待足够的数据到来。而在用户进程这边，整个进程会被阻塞。当kernel一直等到数据准备好了，它就会将数据从kernel中拷贝到用户内存，然后kernel返回结果，用户 进程才解除block的状态，重新运行起来。所以，blocking IO的特点就是在IO执行的两个阶段（等待数据和拷贝数据两个阶段）都被block了。 eg:老李去火车站买票，排队三天买到一张退票。 耗费：在车站吃喝拉撒睡 3天，其他事一件没干。 2.非阻塞I/O模型 Linux下，可以通过设置socket使其变为non-blocking。当对一个non-blocking socket执行读操作时，流程是这个样子： 从图中可以看出，当用户进程发出read操作时，如果kernel中的数据还没有准备好，那么它并不会block用户进程，而是立刻返回一个error。从用户进程角度讲 ，它发起一个read操作后，并不需要等待， 而是马上就得到了一个结果

Nginx： 1、轻量级，采用 C 进行编写，同样的 web 服务，会占用更少的内存及资源 2、抗并发，nginx 以 epoll and kqueue 作为开发模型，处理请求是异步非阻塞的，负载能力比 apache 高很多，而 apache 则是阻塞型的。在高并发下 nginx 能保持低资源低消耗高性能 ，而 apache 在 PHP 处理慢或者前端压力很大的情况下，很容易出现进程数飙升，从而拒绝服务的现象。 3、nginx 处理静态文件好，静态处理性能比 apache 高三倍以上 4、nginx 的设计高度模块化，编写模块相对简单 5、nginx 配置简洁，正则配置让很多事情变得简单，而且改完配置能使用 -t 测试配置有没有问题，apache 配置复杂 ，重启的时候发现配置出错了，会很崩溃 6、nginx 作为负载均衡服务器，支持 7 层负载均衡 7、nginx 本身就是一个反向代理服务器，而且可以作为非常优秀的邮件代理服务器 8、启动特别容易, 并且几乎可以做到 7*24 不间断运行，即使运行数个月也不需要重新启动，还能够不间断服务的情况下进行软件版本的升级 9、社区活跃，各种高性能模块出品迅速 Apache： 1、apache 的 rewrite 比 nginx 强大，在 rewrite 频繁的情况下，用 apache 2、apache 发展到现在，模块超多

什么是Nginx？ Nginx是一个高性能的HTTP和反向代理服务器，也是一个IMAP/POP3/SMTP服务器 Nginx是一款轻量级的Web服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器 目前使用的最多的web服务器或者代理服务器，像淘宝、新浪、网易、迅雷等都在使用 为什么要用Nginx？ 优点： 跨平台、配置简单 非阻塞、高并发连接：处理2-3万并发连接数，官方监测能支持5万并发 内存消耗小：开启10个nginx才占150M内存 成本低廉：开源 内置的健康检查功能：如果有一个服务器宕机，会做一个健康检查，再发送的请求就不会发送到宕机的服务器了。重新将请求提交到其他的节点上。 节省宽带：支持GZIP压缩，可以添加浏览器本地缓存 稳定性高：宕机的概率非常小 master/worker结构：一个master进程，生成一个或者多个worker进程 接收用户请求是异步的：浏览器将请求发送到nginx服务器，它先将用户请求全部接收下来，再一次性发送给后端web服务器，极大减轻了web服务器的压力 一边接收web服务器的返回数据，一边发送给浏览器客户端 网络依赖性比较低，只要ping通就可以负载均衡 可以有多台nginx服务器 事件驱动：通信机制采用epoll模型 为什么Nginx性能这么高？ 得益于它的事件处理机制： 异步非阻塞事件处理机制：运用了epoll模型

负载均衡通讯转发分发器（G5）源代码分析 （以版本v1.1.0为准） G5源代码文件只有.c(2400行)和.h(260行)两个源文件，行数虽然不多，但是技术密集度较高，分析源码主要从基于epoll(ET)事件处理应用层框架和转发会话结构管理两方面入手。 先来看数据结构。主要的数据结构有服务器环境大结构，里面包含了所有参数配置和运行时状态数据，是所有内部函数传递的第一个参数。 [code=c] /* 服务器环境大结构 */ struct ServerEnv { struct CommandParam cmd_para ; struct ForwardRule *forward_rule ; unsigned long forward_rule_count ; int event_env ; struct ForwardSession *forward_session ; unsigned long forward_session_maxcount ; unsigned long forward_session_count ; unsigned long forward_session_use_offsetpos ; struct ServerCache server_cache ; } ; [/code] 包含的众多成员中最应关注的是转发规则结构和转发会话结构 [code=c] /