服务器模型

接触服务器也快一年多了，对它也有了一些认知，所以想梳理一下，加深印象。

我是误打误撞入了linux服务器一行，之前对服务器的概念停留在学校做的简单demo，创建socket,绑定，监听,接收远端请求，一条流程走下来，全包在main函数里，以为全世界的服务器都长这样，高效不高效的完全就没概念。

后来进公司实习的时候，第一接触到了非阻塞的概念，以前诸如监听、接受、发送等会让程序陷入睡眠的操作突然都可以马上返回了，虽然返回不一定有真实数据。其实我当初真不知道搞个非阻塞有什么用。。。现在想起来，其实是我使用的模型不能发挥非阻塞的性能。最初我采用的是一个连接对应于一个工作线程的模式，非阻塞的精髓就是让线程处理更多的连接，而一个线程里面一个连接，即使没在这个连接上陷入阻塞，也没有其他的连接等待线程去处理，造成了资源的浪费，还不如阻塞呢。

再后来引进了session的概念。每个连接都对应一个session，被一组一组统一打包管理，每个组呢都有跟cpu数相等的工作线程，每一个需要收发数据是session被打包推入工作线程里统一处理，在这种模型中，非阻塞的概念得到了发挥，线程不会被某个连接的收发操作给堵住，从而有更多的时间去处理其他连接，服务器资源得到了充分的利用。

进步总是伴随着问题而来的。随着连接数的上升，每次去轮询哪些连接需要收发数据一定是种折磨，事实上在同一时间并没有多少连接需要收发数据，这样的遍历轮询是十分不划算的，服务器的效率必然受到影响。不过不用着急，linux引入了epoll的概念，每个新来的连接都在epoll句柄那注册监听事件，入写事件、读事件，然后只要在连接需要读或写的时候被epoll唤醒，然后处理即可。这种事件机制避免了遍历带来的不必要损耗，进一步的提高了服务器性能。

在服务器的设计中，还有一个重要的概念----定时器。我们需要使用它判断各种超时情况，比如多久不收发数据服务器应该断开连接等等。首先想到的是使用状态机，先定义好各种可能的状态、相应动作以及转移条件，然后一遍又一遍的调用它就可以了，状态机随着session的遍历而被逐一执行，在线程里周而复始，似乎完美解决了超时情况。但不太对，随着session的每次遍历，每个session对应的状态机都被逐一执行了，就像一个拖着铁链的人，随着session数量的飙升，链子越来越长，每走一步也越来越难，显然，状态机的使用已成了服务器性能的一个瓶颈。我们需要改进，在此之前，先来分析下超时事件。在一根有刻度的时间线上，每个超时事件都对应时间线上一个触发的时间点刻度，从左到右，从小到大分布在这跟时间线上，当前时间可以被看做游标，一格一格在刻度上缓慢跳动。随着游标的每一格跳动，程序都能有机会去处理超时事件，也就是说，随着当前时刻的推进，至多只有最小超时事件需要处理，因此只要判读最小超时事件有没没超时就行了！！！而不要再的去遍历所有的状态机。针对这个想法，我们可以设计相应的定时器，以作改进，这里不再作详细说明。

服务器模型讲到这，其实也就差不多了。当然，双拳难敌四手，即使单台服务器性能再高，也禁不起无限的请求数，要想突破瓶颈，就要做构思更好的服务器架构，以应对越来越多的请求数，我在这方面也是新手，还得多交流学习才行啦。