响应内存大并发服务器之阵痛1---传输响应模式

近期笔者几篇文章介绍了改响应内存的文章. 关联文章的地址

    如果你在淘宝上买过衣服，你会发明，模特的图片一张张的加载起来实在是有点慢。有时候体验简直很糟糕。

    现在市面上各类服务器如nginx, apache对HTTP的传输响应现在都只有一种，即：请求----响应----请求-----响应，我们暂定为传统模式，在传统模式下，每一次请求都要在前次响应以后才能停止，实际上是拉长了整体的响应时间，在一些多内容的网页上，这特别明显。

    一些基于TCP的流媒体传输控制请求，是很须要并行处置的，可惜的是现在市面上的服务器都是阻塞式的，如live555， darwin ，只是这类问题还不是很明显，而且产品也不是很多，大家都是抱着能用就不错的心态，没有去认真的研讨进步效率。

    传统服务器对于事件的处置方式是多个连接对应一个进程，比如nginx,一个连接唯一对应一个进程，事件和内存是绑定在连接上的，优势在于事件和内存的管理上可以做得很简单，劣势也很明显，比如做不到 请求--请求--响应---响应。

    每日一道理
悲观的人，先被自己打败，然后才被生活打败；乐观的人，先战胜自己，然后才战胜生活。悲观的人，所受的痛苦有限，前途也有限；乐观的人，所受的磨难无量，前途也无量。在悲观的人眼里，原来可能的事也能变成不可能；在乐观的人眼里，原来不可能的事也能变成可能。悲观只能产生平庸，乐观才能造就卓绝。从卓绝的人那里，我们不难发明乐观的精神；从平庸的人那里，我们很容易找到阴郁的影子。

    这类新模式其实须要一个连接对应多个进程，每一个进程的传输内容用唯一的标识符标符。

    多进程间同享连接其实很费事，不过可以用线程来取代。结果事件模型就转为以下模式：

    

    

    内存和事件的管理不能简单的绑定在连接上了，除非加锁（效率很低，个人很排挤），应该在速度与空间折衷，例如可以在线程内部分配内存，在线程处置完事件时释放，这样做的不好是将线程的处置粒度扩展了，在一些须要流水处置的业务上，则须要将线程中分配的内存挂载到连接上，或者 预先为线程分配大块内存。

    客户端可以为每次讲求分配唯一的ID，服务器的响应中也包括相应的ID，可以避免客户端的响应凌乱。

    

文章结束给大家分享下程序员的一些笑话语录： 打赌
飞机上，一位工程师和一位程序员坐在一起。程序员问工程师是否乐意和他一起玩一种有趣的游戏。工程师想睡觉，于是他很有礼貌地拒绝了，转身要睡觉。程序员坚持要玩并解释说这是一个非常有趣的游戏："我问你一个问题，如果你不知道答案，我付你5美元。然后你问我一个问题，如果我答不上来，我付你5美元。"然而，工程师又很有礼貌地拒绝了，又要去睡觉。　　程序员这时有些着急了，他说："好吧，如果你不知道答案，你付5美元；如果我不知道答案，我付50美元。"果然，这的确起了作用，工程师答应了。程序员就问："从地球到月球有多远？"工程师一句话也没有说，给了程序员5美元。　　现在轮到工程师了，他问程序员："什么上山时有三条腿，下山却有四条腿？"程序员很吃惊地看着工程师，拿出他的便携式电脑，查找里面的资料，过了半个小时，他叫醒工程师并给了工程师50美元。工程师很礼貌地接过钱又要去睡觉。程序员有些恼怒，问："那么答案是什么呢？"工程师什么也没有说，掏出钱包，拿出5美元给程序员，转身就去睡觉了。