推荐一个零声学院免费公开课程，个人觉得老师讲得不错，分享给大家：Linux，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK等技术内容，立即学习

首先，所有的服务器底层都是用的epoll。

• strace ./server `查看epoll系统调用
  select()函数并发量较低，epoll模型让linux的占有率持续增高。

  用户态协议栈如何实现epoll？

  key-value的结构，用何种数据结构存储呢？以下是考虑的过程：

  对于所有的fd总集

  • hash：开始创建内存消耗非常大，成本比较高。fd数量不确定贸然使用也不是明智之举，空间浪费比较多。fd数量大的时候性能非常好。
  • 数组：线性表查找速度慢的像蜗牛，空间不好扩展且查找速度慢，更像蜗牛了。
  • 红黑树：优于avl树，适合内存查找。
  • B树/B+树：主要是用于磁盘上面，mysql，层高比较低，查找效率对比次数不会比红黑树小。

为什么选择了红黑树？
因为红黑树在查找效率和空间利用率上面比hash要高，比较中庸所以最后选择了红黑树。

就绪

考虑这件事的时候，就绪的事件都需要处理没有优先级处理，类属于轻重缓急中的重。推荐选择使用线性的数据结构，队列和栈。
为什么选择队列？
栈是先进后出，担心有点的时候最先的数据从来被处理。

感觉知其然，还要知其所以然的呀。笔者写到这里突然意识到一个问题，以前听说的思维和处理问题方法感觉是个虚无缥缈的东西，今天终于明白了。思维和处理问题的方式其实就是每天的的焦虑和考虑，以后也要加倍关注如何考虑问题，只要这样才能学到精髓。

如何当io准备就绪，怎么知道socket有数据来了？

看到这张图，让我突然联想到像不像婚后生活。epoll是我本人作为桥梁，左面是深爱的妻子，右面是养育自己的母亲。在这里，恩师举了个例子，加入到新公司肯定是站在前人的肩膀上进行改造，epoll是不断的迭代出的产品，想要成就千秋伟业绝不是一蹴而就的事。

相比较poll，没有这些大开大合，调用poll时候会将所有的fd保存到内核协议栈中，有一次copy进一次copy出，有精力就要来回折腾这样不太好吧。一万个IO，数量是很少很少的，实在话比较奢靡浪费，这也不少我个人的风格。而epoll就显得勤俭持家很多啦。

恩师在考虑这个问题的时候，首先考虑到事情的现状是协议栈已经准备好了，如何能挑选出最简单，最方便，而且不容易出错，后人更好接手的方法。

协议栈与epoll通信的时机？

应用程序，epoll，协议栈三者之间有没有耦合？异步的，没有耦合。

epoll是不是线程安全的？

epoll对红黑树加锁，一种是锁住整树，一种是锁住子树。锁子树是很麻烦的事，不允许其他的老操作。
红黑树节点比较多，使用互斥锁。
就绪队列就像一个生产者消费者一样，生产者是协议栈回调函数，epoll_wait()是消费。队列是自旋锁。对于队列添加时，几条指令比较简单。互斥锁没有竞争到资源会让出cpu，而自旋锁不会。自旋锁并不会让出cpu，因为让出cpu的成本更高。

et和lt易出错问题？为什么会有水平触发和边沿触发。

绝对不是故意设计出来的，这是一个水到渠成的。高低电平如果一直是0或者一直是1，就是水平触发。如果0到1这个过程就是边沿触发。et接收数据，就要触发一次回调函数。而lt接收数据，会一直触发回调函数。