IO模型基础

文件系统

  虚拟文件系统

     Linux VFS 虚拟文件系统
     每个目录可以挂载不同类型的文件系统
     linux的系统目录就是虚拟文件系统

     虚拟文件系统是实现docker文件目录隔离的机制
     chroot来实现子目录做为shell环境的根目录,相当于每个容器的执行环境

物理文件系统

      Windows 物理文件系统
      每个目录只能挂载同一类型的文件系统

PageCache

     设置数据从内核管理的pagecache写入的物理磁盘的模型就是文件IO模型

     可以没有PageCache,由应用程序直接调用磁盘驱动读写文件。但这样会导致程序读写文件延迟比较高,耗时较长

     IO的实现依赖PageCache方案
     只要内存空间够大,内核会优先把所有的内容PageCache缓存到内存

      

      

    1.cpu把文件内容从磁盘读取到寄存器然后再把内容从寄存器拷贝到内核的PageCache
    2.DMA协处理器
        cpu只需要发送读取指令
        文件内容直接从磁盘读取到内核的PageCache,不再经过CPU的寄存器

     服务器关机
          1.正常关机的话会给内核发送一个关机中断信号,内核收到信号后会立即把内存中所有的脏页同步到磁盘中,保证数据不会丢失
          2.服务器直接断电关机,内核无法及时的把脏页数据同步到磁盘,导致缓存在内存中的数据会全部丢失

     redis和mysql的三个持久化级别
         1.每一次写操作都要直接刷磁盘
         2.跟随内核写脏页的策略
         3.每隔一秒钟写一次磁盘

     bufferIO和普通IO
         bufferIO会缓存一部分内容后再调用系统调用
         普通IO每一次都要调用系统调用

     文件描述符
          描述的是打开对应文件的文件类型,读写模式,文件inode,读写指针偏移量

   重定向和管道
       重定向是一种机制,不是命令
       0标准输入  1标准输出    2标准错误
       <标准输入  >标准输出

   管道
       shell会分别为管道两边的命令启动单独的子进程来执行
       $$的优先级高于管道

    

    

 磁盘IO

         设置数据从内核管理的PageCache写入的物理磁盘的模型就是文件IO模型
         1.应用程序每次修改数据后立即把PageCache数据flush到磁盘保留的数据多,但效率低
         2.交给内核自己决定什么时候把脏页数据写入磁盘效率高,但是丢失的数据会比较多

      mmap直接内存映射

      

        mmap()系统调用使得进程之间通过映射同一个普通文件实现共享内存.普通文件被映射到进程地址空间后,进程可以像访问普通内存一样对文件进行访问,不必再调用read(),write()等操作
        mmap映射内存必须是页面大小的整数倍,面向流的设备不能进行mmap,mmap的实现和硬件有关

        mmap调用的一个进程和内核共享的内存区域，进程无需通过系统调用就可以直接访问到内核态的内存

         

网络IO

      tcpdump -nn  -i  eth0  port 9000
      lsof  -p  pid(进程id号,不是端口号)
      TCP是面向连接的,可靠的传输协议。只要在传输层成功建立三次握手,那么客户端和服务端就可以相互发送数据
      这些数据会缓存到内核的内存中,如果应用程序没有通过fd关联到此内核连接就暂时无法读取内存中的数据

      

    

     TCP keepalive
     Http keepalive
    负载均衡 keepalived

      

       文件描述符fd

         服务端socket调用accept函数的时候返回文件描述符对象
         文件描述符是属性某个进程下的,不同进程下的文件描述符可以重复
        每个进程下都有三个默认的文件描述符0标准输入 1标准输出 2标准错误

      应用程序关联文件描述符fd
        fd关联内核的socket
        socket关联内核的缓冲buffer,buffer满了后就会丢弃后面的数据

      端口号占用2个字节16个bit位(65535)

    tcp参数
       每个发送的包有多大 MTU 1.5KB
       每个发送的包的数据大小 MSS 1.46KB 去掉包头的数据包

   窗口大小
      根据两方协商的MSS大小,计算出当前内核buffer空间还能存储多少个MSS包
      客户端和服务端两端的buffer空间大小是不一样的
     当发送的数据比较多的时候,就可以不再一个包一个包的发送。而是按照对方的窗口大小,一次性发送多个数据包,减少了阻塞等待对方确认接收包的过程
     原来发送一个包后就需要等待对方发送确认接收包,再发送下一个数据包
     现在可以一次性发送多个包再等待对方发送确认接受包,提升发包效率