redis介绍及NIO原理介绍（三）之NIO

Reids作为单进程单线程模型，所有的操作都是线性执行的，但是读写等待用户操作都是阻塞的，这可能会出现某一文件的阻塞导致这个进程无法在继续为后面的操作服务了。这个问题的解决需要从系统IO这个方向入手。
在这之前，先说明下几个概念，阻塞，非阻塞，同步，非同步的区别。

1.同步和异步
如果一个任务需要等待其他任务的结果才能继续，那么这就是同步的概念
如果一个任务不需要等待依赖任务的完成，只是触发依赖任务，且任务本身自己也能够走完流程，那么这就是非同步。
2.阻塞和非阻塞
如果一个线程在等待任务返回结果，同时无法继续处理其他事务被挂起了，这就是阻塞
如果一个线程在等待任务返回结果，同时又还可以处理其他事务，那么这是非阻塞。

1.1同步阻塞

在linux系统中，当有socket建立时，socket会返回一个文件描述符fd，fd会通过read()去接受内容，当没有获取到内容时就阻塞在那里，直到有数据返回。

很明显socket阻塞会使得cpu的使用率降低，cpu需要花大量的时间用于等待获取数据。如果此时成百上千个线程在处理请求，频繁的切换线程也是会增加cpu开销的。此时就引入了非阻塞socket。

1.2非阻塞同步

非阻塞socket带来的变化显而易见，就是不用因为等待数据而阻塞在那里，这样可以在用户态中使用循环遍历。

1.3 系统调用select

在上一个场景中，如果每次都都轮训1000次的话，其实也还是很占用cpu资源，而且没法即时相应。内核中的select系统调用可以很好的解决这个问题。
我们可以通过man来查看select系统调用做了什么，通过命令

man 2 select

根据描述可以知道，select系统调用可以监控多个文件描述符，当监测到文件描述符为“ready”状态即开始I/O操作。

那么select是如何解决我们在用户空间循环1000次的动作呢！通过把1000个文件描述符都扔到内核，由内核来监控。内核把监控到状态为“ready”的文件描述符返回到用户端，然后在通过read去读取数据。这其实也就是多路复用。这个过程可以参考一下画图。

1.4共享空间

通过select解决了一直轮询读取fd的问题，但是又带来了新的问题，就是文件描述符fd相关数据来回拷贝的问题。先从用户看空间把文件描述符传递到内核，之后内核又需要将文件描述符返回。如果有一个公共空间用来存放文件描述符，那么就避免了这些文件描述符来回传递的问题。