新架构第2天

Q1、几种IO模型的原理

• 阻塞IO模型

  应用程序接收到用户一个请求，应用程序发起系统调用内核完成工作，内核从网络或者硬盘上得到数据，发往应用程序的用户空间中，此时应用程序一直处于等待状态，不能做任何事

• 同步非阻塞IO模型

  应用程序接收到用户一个请求，应用程序发起系统调用内核完成工作，应用程序发起调用后处于空闲状态，不用等待系统回应，所以应用程序会不断询问系统处理结果。当系统处理完毕后就会回应并发往应用程序的用户空间

• I/O多路复用模型

  多个app发起请求，select进程接受请求，select进程发往内核处理，如果内核已把数据准备好了，发信息给app(在此之前app处于阻塞状态)，此时app参与了复制过程，内核把数据复制到用户空间并返回了成功结果，app就可以进行通讯了

• 信号驱动IO模型

  app进程发起系统调用后，有异步行为，内核准备数据发到内核发送数据到用户空间期间不阻塞(app可以做其他事)

  优点：线程并没有在等待数据时被阻塞，可以提高资源的利用率

  缺点：信号 I/O 在大量 IO 操作时可能会因为信号队列溢出导致没法通知

• 异步IO模型

  app进程发起系统调用后，由内核完成，内核在处理过程中app全都不阻塞

  优点：异步 I/O 能够充分利用 DMA 特性，让 I/O 操作与计算重叠

  缺点：要实现真正的异步 I/O，操作系统需要做大量的工作。目前 Windows 下通过 IOCP 实现了真正的异步 I/O，在 Linux 系统下，Linux 2.6才引入，目前AIO 并不完善，因此在 Linux 下实现高并发网络编程时以 IO 复用模型模式+多线程任务的架构基本可以满足需求

  这五种 I/O 模型中，越往后，阻塞越少，理论上效率也是最优前四种属于同步I/O，因为其中真正的 I/O 操作(recvfrom)将阻塞进程/线程，只有异步 I/O 模型才与 POSIX 定义的异步 I/O 相匹配

Q2、实现基于域名PC端和移动端

[root@Centos7 ~]# cd /apps/nginx/conf.d/
[root@Centos7 conf.d]# vim /apps/nginx/conf/nginx.conf
...
http {
    ...
    include "/apps/nginx/conf.d/*.conf";
    ...
}
...
[root@Centos7 conf.d]# vim web.conf
server_tokens off;

server {
        listen 192.168.37.87:80;
        server_name pc.magedu.net;
        root /data/site3;
        index index.html;
        access_log logs/pc.magedu.net.access.log;
}

server {
        listen 172.16.0.87:80;
        server_name m.magedu.net;
        root /data/site4;
        index index.html;
        access_log logs/m.magedu.net.access.log;
}
[root@Centos7 conf.d]# mkdir /data/site{3,4}
[root@Centos7 conf.d]# echo PC_test > /data/site3/index.html
[root@Centos7 conf.d]# echo Mobile_test > /data/site4/index.html
[root@Centos7 conf.d]# chown -R nginx:nginx /data/site{3,4}
[root@Centos7 conf.d]# nginx -t
nginx: the configuration file /apps/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /apps/nginx/conf/nginx.conf test is successful
[root@Centos7 conf.d]# nginx

#测试结果
[root@centos6 ~]$ curl pc.magedu.net
PC_test
[root@centos6 ~]$ curl m.magedu.net
Mobile_test