Apache
Apache HTTP服务器是 Robert McCool 在1995年写成，并在1999年开始在Apache软件基金会的 框架下进行开发。由于Apache HTTP服务器是基金会最开始的一个项目也是最为有名的一个项目， 所以通常大家提到Apache这个词都是说的Apache HTTP Server。
Apache web服务器从1996年开始就是互联网上最为流行的HTTP服务器。Apache之所以这么流行 很大程度上是由于相比其他的软件项目，在Apache基金会的精心维护下他的文档十分的详尽还有 集成的支持服务。
Apache由于其可变性、高性能和广泛的支持，经常是系统管理员的首选。他可以通过一系列 的语言相关的扩展模块支持很多解释型语言的后端，而不需要连接一个独立的后端程序。
Apache软件基金会也是利用开源软件盈利的一个范本。时至今日，Apache软件基金会 已经枝繁叶茂，在基金会名下的开源项目我们耳熟能详的有：
-
Apache HTTP Server
-
Ant（Java的编译工具）
-
ActiveMQ（MQ集群）
-
Cassandra（强一致的分布式KV数据库）
-
CloudStack（OpenStack的劲敌）
-
CouchDB（KV数据库）
-
Flume（日志收集工具）
-
Hadoop、Hbase、Hive
-
Kafka（流式计算）
-
Lucene（开源搜索引擎）
-
Maven（Java编译&依赖管理工具）
-
Mesos（分布式协调）
-
OpenNLP（开源自然语言处理库）
-
OpenOffice（开源的类Office工具）
-
Perl（Perl语言）
-
Spark（分布式计算集群）
-
Storm（流式计算）
-
Structs（Java SSH框架的第二个S）
-
Subversion（SVN，你懂的）
-
Tcl（Tcl语言）
-
Thrift（Java网络框架）
-
Tomcat（大名鼎鼎的Java容器）
-
ZooKeeper（分布式协调集群）
完整的Apache基金会的项目列表参见：Welcome to The Apache Software Foundation!
（https://link.zhihu.com/?target=http%3A//apache.org/index.html%23projects-list）
Nginx
2002年，一个叫Igor Sysoev的俄罗斯哥们儿（貌似俄罗斯叫Igor的人挺多的） 写出了一个叫Nginx（和Engine X谐音，取引擎之义）。 那时候有一个时代背景，当时C10K（Concurrency 10K，1万并发）问题还是困扰绝大多数 web服务器的一个难题。Nginx利用异步事件驱动的架构写成，是C10K问题的一个很好的答卷。 Nginx的第一个公开发行版是在2004年发布的，之前都是作为俄罗斯访问量第二的网站Rambler 的内部使用。
Nginx的主要优势在于“轻、快、活”：
轻
很低的资源占用，甚至能在很多嵌入式设备上运行。
快
响应速度超快，几乎不会由于高并发影响响应速度。
活
配置灵活，广泛的模块支持。
网上关于Apache和Nginx性能比较的文章非常多，基本上有如下的定论：
-
Nginx在并发性能上比Apache强很多，如果是纯静态资源（图片、JS、CSS）那么Nginx是不二之选。
-
Apache有mod_php、在PHP类的应用场景下比Nginx部署起来简单很多。一些老的PHP项目用Apache 来配置运行非常的简单，例如Wordpress。
-
对于初学者来说Apache配置起来非常复杂冗长的类XML语法，甚至支持在子目录放置.htaccess 文件来配置子目录的属性。Nginx的配置文件相对简单一点。
-
Nginx的模块比较容易写，可以通过写C的mod实现接口性质的服务，并且拥有惊人的性能。 分支OpenResty，可以配合lua来实现很多自定义功能，兼顾扩展性和性能。
这里我们要着重讨论的是：为什么Nginx在并发性能上比Apache要好很多？
想要了解这个问题，不得不先做一些铺垫，讲讲并发网络编程的一些历史：
壹 ——最原始
最原始的网络编程的伪代码大致是这样：
贰—— 每个连接开一个进程
后来，大家想到了办法：
用子进程来处理连接，父进程继续等待连接进来。但这种方式有如下两个明显的缺陷：
-
fork()调用比较费时，需要对进程进行内存拷贝。即使现在的Linux普遍 引入了COW（Copy On Write）技术（fork的时候不做内存拷贝，只有其中一个 副本发生了write的时候才进行copy）加速了fork的效率，但fork依旧是个 比较“重”的系统调用。
-
较多的内存占用，也是由于上述的内存复制造成的。
叁——引入线程
得益于之前提过的Linux对于线程的引入，上面例子的开进程，被换成了开线程， 这样，上一小节说的两个缺陷都大大的被缓解了。
肆—— 进程/线程池
计算机领域有很多算法或者是方法都会用到一种智慧：“空间换时间”。 即用使用更多内存的方式换取更快的运行速度：事先创建出很多进程/线程 ，就像一个池子，这样虽然会浪费一部分的内存，但连接过来的时候就省去了 开启进程/线程的时间。
但这种方式会有一个比较显著的缺陷：当并发数大于进程/线程池的大小的时候 性能就会发生很大的下滑，退化成“贰”的情况。
**伍 **——非阻塞&事件驱动
那么，是不是想要达到高性能就一定要付出高系统资源占用呢？ 答案是否定的，如果我们注意观察生活中的一个细节，肯德基和麦当劳的不同 服务方式：
-
肯德基
服务员在前台问：“先生/小姐，有什么可以帮你？”
顾客，思考一下点什么比较好：“我要，xxxxx”
服务员去后台配餐、取餐，3分钟过去了：“您的餐齐了，下一位”
- 麦当劳
服务员在前台问：“先生/小姐，有什么可以帮你？”
顾客：“我要，xxxxx”。如果顾客思考超过5秒：“后面的顾客请先点”； 点完餐，前台服务员继续为下一位顾客点餐。后台有别的服务员完成配餐。
可以思考一下，这两种运作方式那种比较好：
-
在肯德基，如果遇到需要纠结半天吃什么的客户。服务员和后面的顾客 都会陷入较长时间的等候。原因就是如果最前面的客户先让后面的顾客点餐 ，他想好了还需要较长时间的等候。相比之下，麦当劳就更胜一筹。
-
在麦当劳，后面配餐的服务员如果发现有两个订单都要了可乐。他可以 智能地把两个订单的可乐一次性灌好，这样会大大的提高效率。各个岗位上 的服务员可以灵活的采用各种方式优化自己的工作效率。
这里，肯德基的服务方式就是古老的进程/线程池；麦当劳的服务方式 就是一个简单的非阻塞&事件驱动。
那么，非阻塞&事件驱动这么好，为什么大家没有一开始就采用这种方式呢？ 原因有二：
-
非阻塞&事件驱动需要系统的支持，提供non-blocking版的整套 系统调用。
-
非阻塞&事件驱动编程难度较大，需要很高的抽象思维能力， 把整个任务拆解；采用有限状态机编程才能实现。
招生课程：
Python 实战班第 18 期
自动化运维课程第 7 期
golang 课程第 3 期
架构师班第 7 期
网友评论