压榨机器,Hack,设计极限强度网络应用.docVIP

压榨机器,Hack,设计极限强度网络应用 压榨机器，Hack，设计极限强度的网络应用 在《对话网友 - TCP一万连接系统设计》文后回复中，短短的评论不足以说明问题，于是单独撰文解释。 对于一般的应用来说，操作系统足以对付，对于极限应用来说，操作系统往往就成了我们的障碍，这里的障碍有两个意义，第一个意义是，它出于某种考虑，而禁止了许多可以提高性能的机制，是不能也，另一个意义是，它限制了我们的思维，是不为也。 由于操作系统要考虑多种方面的应用，因此在设计时做了很多防御性的措施，而对于具体的应用来说，这些措施往往不是最佳的，必要时，我们需要针对自己的应用进行定制，就像Google修改Linux的文件系统一样，为了实现极限的网络应用，我们需要对操作系统进行Hack。对极限应用来说，传统的网络编程模型根本就是不够看的。 先列举几个应用场景： 场景1：SmartBit是个很NB的协议测试工具，但是它只能测试一些最基本的协议。如果要测试一些更广泛的协议或者自定义协议，只能自己编写测试工具了，但是自己编写的测试工具受操作系统限制，如果使用传统的编程模型，很难达到超高的性能。 场景2：有一些应用，这些应用的逻辑比较固定，而同时对性能要求又极高，比如说，各种专门的服务器，时间服务器啊，DNS服务器啊，大型的仿真系统啊，交换机啊，路由器啊，IDS啊等等，当然，这些都可以通过硬件来解决，但如果能用通用机器通用的软件来解决不更好吗？ 对于这些应用，就需要抛弃传统的网络应用概念了，什么Socket啊，IOCP啊，全见鬼去吧——都不够看。当然，如果常规开发就可以解决，比如《对话网友 - TCP一万连接系统设计》文中所提及的场景，自然就不需要采用专门的手段了。下面说的是常规方法解决不了时，当IOCP也只够塞牙缝时，应该怎么做的问题。 =========================== 大型应用为了提高性能，往往会放弃关系数据库，回归传统的key-value型数据库，为了极限化网络程序的性能，我们需要放弃传统的编程模型，回归最传统最原始的编程模型。 对于操作系统来说，影响网络应用性能主要有这些方面： (1) 进程：现在的OS都是多任务系统，而单任务系统的性能是最佳的。 (2) 内存：packet的复制问题。数据从到网卡，到内核，再到应用程序，要复制好几次，这些是无谓的。 (3) 系统调用：系统调用是非常耗费资源的，Socket访问啦，内存分配啊，获取机器时间啦……都是系统调用。 (4) 编程模型：IOCP模型不是最佳的。而传统的基于线程的编程模式，在对付大并发量时，完全不够看。比如 … 要跑1000万个线程 … 这时只能使用proto thread（或erlang所谓的轻量级线程）。假设更高呢？一亿个线程？这就要对线程进行消解了，采用完全的离散处理机制，把线程彻底的消解掉。 =========================== 下面，就以上四点来说，看看我们可以做哪些工作，把系统压榨到富士康的程度。 (1) 进程 为了这些，单独搞个操作系统不划算，就在现有的操作系统基础上看看可以怎样解决。很显然，我们不需要其它的应用来干扰我们的网络应用。因此需要给这个应用以最高的优先级。不Hack操作系统的情况下，最高的优先级也就是实时进程了。 (2) (3) 内存和系统调用 为了避免内存的复制，减少系统调用，需要和传统的Socket说ByeBye。最好的方式是自己实现一个协议栈。当然，不必实现一个完全的协议栈代码，只需实现我们需要的那部分即可，实质上，实现UDP协议只需要几百行代码，实现TCP也只需要三四千行代码，同时，又有很多开源的实现可以参考，这个工作看起来困难，实际上并不是很困难。还有个问题是内存的分配。操作系统内存的分配是低效的，因此，需要使用对象池，将内存重复使用。 (4) 编程模型 放弃线程，采用最原始的基于事件的离散处理模型。简单来说，我们把每一个需要做的工作分解成一个个的事件，然后放在队列中，应用程序呢，从队列中一个个取出事件并执行，执行的过程中，如果有其它后续操作，可以生成新事件，放入队列的尾部。 如果我们需要某些事件优先执行，简单的队列就不行了，需要优先队列。更进一步，我们如果需要引入时间模型，需要安排某个事件在某个时间执行，时间在前的事件优先执行？怎么办呢？以前普遍使用的是Heap，Heap的插入的复杂度是O(logn)，查找最大元素的复杂度是O(1)。Heap就是最优了吗？不是！还有比它更NB的数据结构——Calendar Queue，Calendar Queue插入的复杂度