电脑和服务器X86架构和X64架构的区别是什么?

电脑和服务器X86架构和X64架构的区别是什么?,第1张

实际上X86架构是基础架构,X64架构是基于X86的,也可称为X86-64架构。具体介绍如下:\x0d\x0ax86或80x86是英特尔Intel首先开发制造的一种微处理器体系结构的泛称。该系列较早期的处理器名称是以数字来表示,并以“86”作为结尾,包括Intel 8086、80186、80286、80386以及80486,因此其架构被称为“x86”。x86架构于1978年推出的Intel 8086中央处理器中首度出现,它是从Intel 8008处理器中发展而来的,而8008则是发展自Intel 4004的。8086在三年后为IBM PC所选用,之后x86便成为了个人计算机的标准平台,成为了历来最成功的CPU架构,如Pentium、Athlon。现在,Intel把x86-32称为IA-32,全名为“Intel Architecture, 32-bit”。\x0d\x0ax86-64架构诞生颇有时代意义。当时处理器的发展遇到了瓶颈,内存寻址空间由于受到32位CPU的限制而只能最大到约4G。AMD主动把32位x86(或称为IA-32)扩充为64位。它以一个称为AMD64的架构出现(在重命名前也称为x86-64),且以这个技术为基础的第一个产品是单内核的Opteron和Athlon 64处理器家族。由于AMD的64位处理器产品线首先进入市场,且微软也不愿意为Intel和AMD开发两套不同的64位操作系统,Intel也被迫采纳AMD64指令集且增加某些新的扩充到他们自己的产品,命名为EM64T架构(显然他们不想承认这些指令集是来自它的主要对手),EM64T后来被Intel正式更名为Intel 64。这两者被统称为x86-64或x64,开创了x86的64位时代。\x0d\x0a关于32位系统与64位系统的比较,速度并不是唯一的考量因素。也不能因为数字上的变化,简单地认为64位CPU的性能是32位CPU的两倍。实际在目前阶段64位的应用程序并不多,即便有,很多也只是因为其32位的版本无法在64位操作系统上运行而产生的。而没有真正做过64位优化的程序,性能上并不会带来太大的提升。相反,在32位的应用上 ,跑32位的CPU性能甚至会更强。另一方面,由于32位的Windows系统最大只支持3.25G的内存,而64位的Windows系统则可以最大支持128G的内存。所以,当电脑内存大于4G时,就要果断采用64位系统了。

所谓服务器架构,也就是如何将服务器各部分合理地安排,以实现最初的功能需求。所以,架构本无所谓正确与错误;当然,优秀的架构更有助于系统的搭建,对系统的可扩展性及可维护性也有更大的帮助。 

服务器架构优化

1、一台“全能”的服务器

把应用系统网站、数据库、文件系统等都在一台服务器下,这样形成了最初级的服务器,一般是非常简单的应用,使用的用户量相当有限。一些企业的门户网站或刚上线使用的系统会采用这样的方式进行部署。

2、系统网站、数据库和文件系统不同的服务器进行部署

这个有先考虑的是把数据库和系统网站分离出来部署到不同的服务器。很多的系统网站很长一段时间都是把系统网站和文件服务器放在一起,把数据库分离出去后发现网站的性能没有多大的提升时,才考虑把文件系统从系统站点分离出去,减少读取文件带来了网络开销和IO读取。在配置服务是需要根据服务器所承载的职责用途分配不同性能的硬件设备,如文件服务器更需要考虑的是硬盘。

模块化结构的思想是一个很久的概念,但也正是成熟的思想造就了Nginx的巨大优越性。

我们知道Nginx从总体上来讲是有许多个模块构成的。习惯将Nginx分为5大模块分别为:核心模块,标准HTTP模块,可选HTTP模块,邮件服务模块和第三方模块。

这5个模块由上到下重要性一次递减。

(1)核心模块;

核心模块是Nginx服务器正常运行必不可少的模块,如同操作系统的内核。它提供了Nginx最基本的核心服务。像进程管理、权限控制、错误日志记录等;

(2)标准HTTP模块;

标准HTTP模块支持标准的HTTP的功能;

(3)可选HTTP模块;

可选HTTP模块主要用于扩展标准的HTTP功能,让Nginx能处理一些特殊的服务;

(4)邮件服务模块;

邮件服务模块主要用于支持Nginx的邮件服务;

(5)第三方模块;

第三方模块是为了扩展Nginx服务器应用,完成开发者想要的功能;

*******Nginx中的模块命名有自己的习惯*********

一般以Ngx_作为前缀,——module作为后缀,中间使用一个或者多个英文单词描述模块的工能,例如Ngx_core_module表示该模块提供Nginx的核心功能等;

具体各个模块中包含哪些模块可以自己去源码中查询,这里略过;

从架构设计上说,Nginx服务器是与众不同的。其一在于它的模块化设计;其二也是更重要的一点在于它对与客户端请求的处理机制上;

web服务器和客户端是一对多的关系,Web服务器必须有能力同时为多个客户端提供服务。一般来说完成并行处理请求工作有三种方式:

1.多进程方式;

2.多线程方式;

3.异步方式;

这里简单说明一下这三种方式:

(1)多进程方式

多进程方式指,服务器每当收到一个客户端时。就有服务器主进程生成一个子进程出来和客户端建立连接进行交互。指导连接断开。该子进程就结束了。

多进程方式的优点是设计简单,各个子进程相对独立,处理客户端请求时彼此不受干扰;缺点是操作系统生成一个子进程需要进行内存复制等操作,在资源和时间上会产生一定的开销;当有大量请求时,会导致系统性能下降;

(2)多线程方式

多线程方式指每当服务器接收到一个请求后,会由服务器主进程派生出一个线程出来和客户端进行交互。由于操作系统产生出一个线程的开销远远小于一个进程的开销。故多线程方式在很大程度上减轻了Web服务器对系统资源的要求。但同时由于多个线程位于一个进程内,可以访问同样的内存空间。所以需要开发者自己对内存进程管理,增大了难度。

(3)异步方式

异步方式适合多进程和多线程完全不同的一种处理客户端请求的方式。这里有几个概念我们需要熟悉一下: 同步,异步,阻塞,非阻塞

在网络通信中同步和异步是描述通信模式的概念。

同步:发送方发送完请求后,需要等待接收到接收方发回的响应,才能发送下一个请求;所有请求在服务端得到同步,发送方和接收方的步调是一致的;

异步 :和同步机制相反,在异步机制中,发送方发出一个请求后,不等接收方响应这个请求,就继续发送下一个请求;所有来自发送方的请求形成一个队列,接收方处理完成后通知发送方;

在进程处理调度方式上用阻塞与非阻塞。在网络通信中主要指套接字socket的阻塞和非阻塞,而socket的实质就是IO操作。

阻塞 :调用结果返回之前,当前线程从运行状态被挂起,一直等到调用结果返回之后,才进入就绪状态,获取CPU后继续执行。

非阻塞 :和阻塞方式正好相反,如果调用结果不能马上返回,当前线程也不会马上返回,而是立即返回执行下一个调用。

因此就衍生出4中方式:同步阻塞,同步非阻塞,异步阻塞,异步非阻塞

这里简单解释一下异步非阻塞:发送方向接收方发送请求后,不用等待响应,可以继续其他工作;接收方处理请求时进行的IO操作如果不能马上得到结果,也不必等待,而是马上返回去去做其他事情。当IO操作完成以后,将完成状态和结果通知接收方,接收方再响应发送方。

与此同时Nginx服务器处理请求是怎样的呢???

Nginx服务器的一个显著的优势就是能够同时处理大量的并发请求。它结合多进程机制和异步机制。异步机制使用的是异步非阻塞方式。(Master-Worker)。

每个工作进程使用异步非阻塞方式,可以处理多个客户端请求。当某个工作进程接收到客户端的请求以后,调用IO进行处理,如果不能立即得到结果,就去处理其他的请求;而客户端在此期间也无需等待响应,可以去处理其他事情;当IO返回时,就会通知此工作进程;该进程得到通知,暂时挂起当前处理的失误去响应客户端请求。

也就是:

Nginx采用异步非阻塞方式来处理请求,处理请求具体到系统底层就是读写事件(所谓阻塞调用方式即请求事件还没准备好,线程只能一直去等,等事件准备好了再处理;而非阻塞即事件没准备好,马上返回ENGAIN,告诉你事件还没准准备好,而在这期间可以先去做其他事,再回头看看事件准备好了吗,时不时会看,需要的开销也是不小的)

异步可以理解为循环处理多个准备好的事件,不会导致无谓的资源浪费,当有更多的并发数只会占用更多的内存而已

从上面我们可以知道,Nginx服务器的工作进程调用IO后,就取进行其他工作了;当IO调用返回后,会通知工作进程。 但IO调用时如何把自己的状态通知给工作进程的呢??

一般解决这个问题有两种方法:

(1)让工作进程在进行其他工作的过程中间隔一段时间就去检查一下IO的状态,如果完成就响应客户端,如果未完成,继续工作。

(2)IO调用在完成后能主动通知工作进程。

当然最好的就是用第二种方法了;像select/poll/epoll等这样的系统调用就是用来支持第二种解决方案的。这些系统调用也常被称为事件驱动模型。他们提供了一种机制就只让进程同时处理多个并发请求,不用关心IO调用的具体状态。IO调用完全由事件驱动模型来管理。

Nginx中的事件驱动模型

就是用事件驱动处理库(多路IO复用),最常用的就是select模型,poll模型,epoll模型。

关于这三个模型的详解在这里可以看到:https://segmentfault.com/a/1190000003063859

通过这个上面的简单讲解,再加上服务器的架构的了解,可以对Nginx有一个简单的了解,希望对之后的源码剖析有帮助。

大致上Nginx的架构就是这样:

1.Nginx启动后,会产生一个主进程,主进程执行一系列的工作后会产生一个或者多个工作进程;

2.在客户端请求动态站点的过程中,Nginx服务器还涉及和后端服务器的通信。Nginx将接收到的Web请求通过代理转发到后端服务器,由后端服务器进行数据处理和组织;

3.Nginx为了提高对请求的响应效率,降低网络压力,采用了缓存机制,将 历史 应答数据缓存到本地。保障对缓存文件的快速访问;

##工作进程##

工作进程的主要工作有以下几项:

接收客户端请求;

将请求一次送入各个功能模块进行过滤处理;

IO调用,获取响应数据;

与后端服务器通信,接收后端服务器处理结果;

数据缓存

响应客户端请求;

##进程交互##

Nginx服务器在使用Master-Worker模型时,会涉及到主进程和工作进程的交互和工作进程之间的交互。这两类交互都依赖于管道机制。

1.Master-Worker交互

这条管道与普通的管道不同,它是由主进程指向工作进程的单向管道,包含主进程向工作进程发出的指令,工作进程ID等;同时主进程与外界通过信号通信;

2.worker-worker交互

这种交互是和Master-Worker交互是基本一致的。但是会通过主进程。工作进程之间是相互隔离的,所以当工作进程W1需要向工作进程W2发指令时,首先找到W2的进程ID,然后将正确的指令写入指向W2的通道。W2收到信号采取相应的措施。


欢迎分享,转载请注明来源:夏雨云

原文地址:https://www.xiayuyun.com/zonghe/610.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-01-29
下一篇2023-01-29

发表评论

登录后才能评论

评论列表(0条)

    保存