大白话解释互联网后台为什么常用异步server?

        最近写了一个异步server, 所以来聊聊异步server:

        互联网的后台开发就是一堆的server, 我们先来看看同步server的情况：

 

          如上图， A是用户的请求， B是后台的某一个Server, C是数据库存储。

          

        先来说一下同步server.   A在第0s发起请求， B收到请求后去读数据库C,  假设读写数据库需要1s时间.   很显然， 如果有10000个A并发地发起请求， 处理完这10000个任务， 至少需要10000s, 等到花儿也谢了.   同步server耗时的关键点在于： B必须等待C返回后， 才能把信息传给A, 才能响应A的下一个请求。 B的绝大部分时间耗在无聊地等待， 实际上， B的利用率很低。 无聊等待， 浪费生命。

        我们看一下解决方法： 

        1. 在B的server中开10000个进程， 每个进程处理1个请求， 这样能保证值需要1s就能处理完所有的10000个请求。 但是， linux开启的进程数是有限制的， 进程太多后， 很耗费资源。 所以， 单纯依赖于堆积进程数是行不通的。

        2. 花钱买10000台机器， 每个机器对应1个server, 这样能保证值需要1s就能处理完所有的10000个请求。 我要说， 你好有钱。

        3. 折中1和2的方案， 花钱买100台机器， 每台机器开100个进程， 这样能保证值需要1s就能处理完所有的10000个请求。 如果觉得划算， 你可以这么搞。

 

         如上三种方法都没有触及问题的本质， 问题的本质在于： server花费太多时间再等待C，  最根本的办法是用异步server------B不需要等待C的响应， 就可以继续是接受A的下一个请求， 也就是说， B每时每刻都处在接客中。 这样， 1s接10000次客， 棒棒哒。

        然而， 互联网的海量特性决定了仅仅依靠异步是不行的， 每秒10万---100万的请求怎么办？可以这么搞： 异步server + 每个机器多开一些进程 + 花钱买机器 。

 

        OK, 大致就是这样， 不多扯。