您的位置： >>
　　事件驱动为广大的程序员所熟悉，其最为人津津乐道的是在图形化界面编程中的应用；事实上，在网络编程中事件驱动也被广泛使用，并大规模部署在高连接数高吞吐量的服务器程序中，如 http 服务器程序、ftp 服务器程序等。相比于传统的网络编程方式，事件驱动能够极大的降低资源占用，增大服务接待能力，并提高网络传输效率。
　　关于本文提及的服务器模型，搜索网络可以查阅到很多的实现代码，所以，本文将不拘泥于源代码的陈列与分析，而侧重模型的介绍和比较。使用 libev 事件驱动库的服务器模型将给出实现代码。
　　本文涉及到线程/时间图例，只为表明线程在各个 IO 上确实存在阻塞时延，但并不保证时延比例的正确性和 IO 执行先后的正确性；另外，本文所提及到的接口也只是笔者熟悉的 Unix/Linux 接口，并未推荐 Windows 接口，读者可以自行查阅对应的 Windows 接口。
　　阻塞型的网络编程接口
　　几乎所有的程序员第一次接触到的网络编程都是从 listen()、send()、recv() 等接口开始的。使用这些接口可以很方便的构建服务器/客户机的模型。
　　我们假设希望建立一个简单的服务器程序，实现向单个客户机提供类似于&一问一答&的内容服务。
　　图 1. 简单的一问一答的服务器/客户机模型
　　我们注意到，大部分的 socket 接口都是阻塞型的。所谓阻塞型接口是指系统调用（一般是 IO 接口）不返回调用结果并让当前线程一直阻塞，只有当该系统调用获得结果或者超时出错时才返回。
　　实际上，除非特别指定，几乎所有的 IO 接口(包括 socket 接口)都是阻塞型的。这给网络编程带来了一个很大的问题，如在调用 send() 的同时，线程将被阻塞，在此期间，线程将无法执行任何运算或响应任何的网络请求。这给多客户机、多业务逻辑的网络编程带来了挑战。这时，很多程序员可能会选择多线程的方式来解决这个问题。
　　多线程服务器程序
　　应对多客户机的网络应用，最简单的解决方式是在服务器端使用多线程（或多进程）。多线程（或多进程）的目的是让每个连接都拥有独立的线程（或进程），这样任何一个连接的阻塞都不会影响其他的连接。
　　具体使用多进程还是多线程，并没有一个特定的模式。传统意义上，进程的开销要远远大于线程，所以，如果需要同时为较多的客户机提供服务，则不推荐使用多进程；如果单个服务执行体需要消耗较多的 CPU 资源，譬如需要进行大规模或长时间的数据运算或文件访问，则进程较为安全。通常，使用 pthread_create () 创建新线程，fork() 创建新进程。
　　我们假设对上述的服务器/客户机模型，提出更高的要求，即让服务器同时为多个客户机提供一问一答的服务。于是有了如下的模型。
　　图 2. 多线程服务器模型&
　　在上述的线程 / 时间图例中，主线程持续等待客户端的连接请求，如果有连接，则创建新线程，并在新线程中提供为前例同样的问答服务。
　　很多初学者可能不明白为何一个 socket 可以 accept 多次。实际上，socket 的设计者可能特意为多客户机的情况留下了伏笔，让 accept() 能够返回一个新的 socket。下面是 accept 接口的原型：
int accept(int s, struct sockaddr *addr, socklen_t *addrlen);
　　输入参数 s 是从 socket()，bind() 和 listen() 中沿用下来的 socket 句柄值。执行完 bind() 和 listen() 后，操作系统已经开始在指定的端口处***所有的连接请求，如果有请求，则将该连接请求加入请求队列。调用 accept() 接口正是从 socket s 的请求队列抽取第一个连接信息，创建一个与 s 同类的新的 socket 返回句柄。新的 socket 句柄即是后续 read() 和 recv() 的输入参数。如果请求队列当前没有请求，则 accept() 将进入阻塞状态直到有请求进入队列。
　　上述多线程的服务器模型似乎完美的解决了为多个客户机提供问答服务的要求，但其实并不尽然。如果要同时响应成百上千路的连接请求，则无论多线程还是多进程都会严重占据系统资源，降低系统对外界响应效率，而线程与进程本身也更容易进入假死状态。
　　很多程序员可能会考虑使用&线程池&或&连接池&。&线程池&旨在减少创建和销毁线程的频率，其维持一定合理数量的线程，并让空闲的线程重新承担新的执行任务。&连接池&维持连接的缓存池，尽量重用已有的连接、减少创建和关闭连接的频率。这两种技术都可以很好的降低系统开销，都被广泛应用很多大型系统，如 websphere、tomcat 和各种数据库等。
　　但是，&线程池&和&连接池&技术也只是在一定程度上缓解了频繁调用 IO 接口带来的资源占用。而且，所谓&池&始终有其上限，当请求大大超过上限时，&池&构成的系统对外界的响应并不比没有池的时候效果好多少。所以使用&池&必须考虑其面临的响应规模，并根据响应规模调整&池&的大小。
　　对应上例中的所面临的可能同时出现的上千甚至上万次的客户端请求，&线程池&或&连接池&或许可以缓解部分压力，但是不能解决所有问题。
　　总之，多线程模型可以方便高效的解决小规模的服务请求，但面对大规模的服务请求，多线程模型并不是最佳方案。下一章我们将讨论用非阻塞接口来尝试解决这个问题。
　　使用 select() 接口的基于事件驱动的服务器模型
　　大部分 Unix/Linux 都支持 select 函数，该函数用于探测多个文件句柄的状态变化。下面给出 select 接口的原型：
FD_ZERO(int fd, fd_set* fds)
FD_SET(int fd, fd_set* fds)
FD_ISSET(int fd, fd_set* fds)
FD_CLR(int fd, fd_set* fds)
int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
struct timeval *timeout)
　　这里，fd_set 类型可以简单的理解为按 bit 位标记句柄的队列，例如要在某 fd_set 中标记一个值为 16 的句柄，则该 fd_set 的第 16 个 bit 位被标记为 1。具体的置位、验证可使用 FD_SET、FD_ISSET 等宏实现。在 select() 函数中，readfds、writefds 和 exceptfds 同时作为输入参数和输出参数。如果输入的 readfds 标记了 16 号句柄，则 select() 将检测 16 号句柄是否可读。在 select() 返回后，可以通过检查 readfds 有否标记 16 号句柄，来判断该&可读&事件是否发生。另外，用户可以设置 timeout 时间。
　　下面将重新模拟上例中从多个客户端接收数据的模型。
　　图4. 使用 select() 的接收数据模型&
　　上述模型只是描述了使用 select() 接口同时从多个客户端接收数据的过程；由于 select() 接口可以同时对多个句柄进行读状态、写状态和错误状态的探测，所以可以很容易构建为多个客户端提供独立问答服务的服务器系统。　　图5. 使用select()接口的基于事件驱动的服务器模型
　　这里需要指出的是，客户端的一个 connect() 操作，将在服务器端激发一个&可读事件&，所以 select() 也能探测来自客户端的 connect() 行为。
　　上述模型中，最关键的地方是如何动态维护 select() 的三个参数 readfds、writefds 和 exceptfds。作为输入参数，readfds 应该标记所有的需要探测的&可读事件&的句柄，其中永远包括那个探测 connect() 的那个&母&句柄；同时，writefds 和 exceptfds 应该标记所有需要探测的&可写事件&和&错误事件&的句柄 (使用 FD_SET() 标记)。
　　作为输出参数，readfds、writefds 和 exceptfds 中的保存了 select() 捕捉到的所有事件的句柄值。程序员需要检查的所有的标记位 (使用 FD_ISSET() 检查)，以确定到底哪些句柄发生了事件。
　　上述模型主要模拟的是&一问一答&的服务流程，所以，如果 select() 发现某句柄捕捉到了&可读事件&，服务器程序应及时做 recv() 操作，并根据接收到的数据准备好待发送数据，并将对应的句柄值加入 writefds，准备下一次的&可写事件&的 select() 探测。同样，如果 select() 发现某句柄捕捉到&可写事件&，则程序应及时做 send() 操作，并准备好下一次的&可读事件&探测准备。下图描述的是上述模型中的一个执行周期。
　　图6. 一个执行周期
　　这种模型的特征在于每一个执行周期都会探测一次或一组事件，一个特定的事件会触发某个特定的响应。我们可以将这种模型归类为&事件驱动模型&。
　　相比其他模型，使用 select() 的事件驱动模型只用单线程（进程）执行，占用资源少，不消耗太多 CPU，同时能够为多客户端提供服务。如果试图建立一个简单的事件驱动的服务器程序，这个模型有一定的参考价值。
　　但这个模型依旧有着很多问题。
　　首先，select() 接口并不是实现&事件驱动&的最好选择。因为当需要探测的句柄值较大时，select() 接口本身需要消耗大量时间去轮询各个句柄。很多操作系统提供了更为高效的接口，如 linux 提供了 epoll，BSD 提供了 kqueue，Solaris 提供了 /dev/poll &。如果需要实现更高效的服务器程序，类似 epoll 这样的接口更被推荐。遗憾的是不同的操作系统特供的 epoll 接口有很大差异，所以使用类似于 epoll 的接口实现具有较好跨平台能力的服务器会比较困难。
　　其次，该模型将事件探测和事件响应夹杂在一起，一旦事件响应的执行体庞大，则对整个模型是灾难性的。如下例，庞大的执行体 1 的将直接导致响应事件 2 的执行体迟迟得不到执行，并在很大程度上降低了事件探测的及时性。
　　图7. 庞大的执行体对使用 select() 的事件驱动模型的影响&
　　幸运的是，有很多高效的事件驱动库可以屏蔽上述的困难，常见的事件驱动库有 libevent 库，还有作为 libevent 替代者的 libev 库。这些库会根据操作系统的特点选择最合适的事件探测接口，并且加入了信号 (signal) 等技术以支持异步响应，这使得这些库成为构建事件驱动模型的不二选择。下章将介绍如何使用 libev 库替换 select 或 epoll 接口，实现高效稳定的服务器模型。
　　使用事件驱动库libev的服务器模型
　　Libev 是一种高性能事件循环/事件驱动库。作为 libevent 的替代作品，其第一个版本发布与 2007 年 11 月。Libev 的设计者声称 libev 拥有更快的速度，更小的体积，更多功能等优势，这些优势在很多测评中得到了证明。正因为其良好的性能，很多系统开始使用 libev 库。本章将介绍如何使用 Libev 实现提供问答服务的服务器。
　　（事实上，现存的事件循环/事件驱动库有很多，作者也无意推荐读者一定使用 libev 库，而只是为了说明事件驱动模型给网络服务器编程带来的便利和好处。大部分的事件驱动库都有着与 libev 库相类似的接口，只要明白大致的原理，即可灵活挑选合适的库。）
　　与前章的模型类似，libev 同样需要循环探测事件是否产生。Libev 的循环体用 ev_loop 结构来表达，并用 ev_loop( ) 来启动。
void ev_loop( ev_loop* loop, int flags )
　　Libev 支持八种事件类型，其中包括 IO 事件。一个 IO 事件用 ev_io 来表征，并用 ev_io_init() 函数来初始化：
void ev_io_init(ev_io *io, callback, int fd, int events)
　　初始化内容包括回调函数 callback，被探测的句柄 fd 和需要探测的事件，EV_READ 表&可读事件&，EV_WRITE 表&可写事件&。
　　现在，用户需要做的仅仅是在合适的时候，将某些 ev_io 从 ev_loop 加入或剔除。一旦加入，下个循环即会检查 ev_io 所指定的事件有否发生；如果该事件被探测到，则 ev_loop 会自动执行 ev_io 的回调函数 callback()；如果 ev_io 被注销，则不再检测对应事件。
　　无论某 ev_loop 启动与否，都可以对其添加或删除一个或多个 ev_io，添加删除的接口是 ev_io_start() 和 ev_io_stop()。
void ev_io_start( ev_loop *loop, ev_io* io )
void ev_io_stop( EV_A_* )
　　由此，我们可以容易得出如下的&一问一答&的服务器模型。由于没有考虑服务器端主动终止连接机制，所以各个连接可以维持任意时间，客户端可以自由选择退出时机。
　　图8. 使用libev库的服务器模型&
　　上述模型可以接受任意多个连接，且为各个连接提供完全独立的问答服务。借助 libev 提供的事件循环/事件驱动接口，上述模型有机会具备其他模型不能提供的高效率、低资源占用、稳定性好和编写简单等特点。
　　由于传统的 web 服务器，ftp 服务器及其他网络应用程序都具有&一问一答&的通讯逻辑，所以上述使用 libev 库的&一问一答&模型对构建类似的服务器程序具有参考价值；另外，对于需要实现远程监视或远程遥控的应用程序，上述模型同样提供了一个可行的实现方案。
　　本文围绕如何构建一个提供&一问一答&的服务器程序，先后讨论了用阻塞型的 socket 接口实现的模型，使用多线程的模型，使用 select() 接口的基于事件驱动的服务器模型，直到使用 libev 事件驱动库的服务器模型。文章对各种模型的优缺点都做了比较，从比较中得出结论，即使用&事件驱动模型&可以的实现更为高效稳定的服务器程序。文中描述的多种模型可以为读者的网络编程提供参考价值。
编程基础热门文章
编程基础最新文章查看: 5990|回复: 7
服务器用什么系统比较好
UID: 536334
论坛新人, 积分 0, 距离下一级还需 50 积分
服务器用什么系统比较好，不知道用哪个系统了 ，自己下了这个 ，不知道怎么用，高手指点下
UID: 536355
论坛新人, 积分 0, 距离下一级还需 50 积分
当然用windows2003啦
UID: 445852
铂金高级, 积分 11311, 距离下一级还需 3689 积分
windouws server 2003不错，
但是要安全性高的话，可以使用Linux，但是要会使用命令
UID: 385830
还下2000的？
windows用2003或者2008服务器系统。
UID: 503223
高级会员, 积分 2742, 距离下一级还需 258 积分
LINUX安全性，稳定性最好
server 2003 或 server 2008&&
UID: 537877
论坛新人, 积分 0, 距离下一级还需 50 积分
windows 2008&&现在都用这个了
UID: 218554
一般服务器有，可以选择用03版的。
Powered by游戏服务器与普通服务器有什么区别?
相比于我们常见的数据中心的普通web服务器，游戏服务器（如英雄联盟，魔兽世界）有什么特别的地方?
一般的网站应用程序，是典型的Request-Response模式，通过tcp和服务器建立一次链接，而请求数据和影响数据通过http协议进行组装，当完成一次交互的时候，服务器端和客户端tcp链接就会释放，把服务器端socket资源留给新的客户端。通常web程序是比较好扩展的，通过硬件负载均衡和添加web服务器来实现，这一套方案业界都已经比较成熟了。网游比较特殊，最大的特点在于客户端和服务器端是要进行长连接的，客户端和服务器端基本上一直要保持连接，不是典型的Request-Response模式，Client会主动给Server发送数据，Server也可能主动往Client发送数据，生命周期比较长，一次发送的数据量比较小，但是数据交互发送比较频繁。由于要进行长连接，服务器端的socket就不能进行复用，单台服务器处理请求是会有限。用web的方案解决扩展问题，也不太适用。在web程序中，客户端之间的数据是没有交互的，所有的数据都是通过web服务器响应给客户端，但是网游服务器中，每个客户端的数据的变化，都要通过服务器端广播给其他客户端。所以客户端会有上限，这也就是为什么服务器要进行分区，一个区里面同时在线人数会有限制。
实名赞同 的回答补充一个资料：　MMORPG不同于其它的局域网的网络游戏，它是一个面向整个Internet的连接人数过万的网络游戏，因此他的服务器端设计则极为重要服务器的基本设置　　在大型网络游戏里，通常设计为C/S结构，客户端不再对数据进行逻辑处理，而只是一个收发装置，从玩家那里接受到操作信息，然后反馈给服务器，再由服务器进行处理后发回客户端，经客户端通过图形化处理，给玩家呈现出一个缤纷的游戏世界。　　登陆服务器　　在这里也可以称之为连接服务器，网络游戏的客户端一般是连接到这里，然后再由该连接服务器根据不同的需要，把游戏消息转发给其它相应的服务器（逻辑和地图服务器）也因为它是客户端直接连接的对象，它同时也负担了验证客户身份的工作。　　地图服务器　　在这里也可以称之为连续事件服务器。在这个服务器里要处理的对象（玩家）所做的动作都是一个连续事件。例如玩家从A点移动到B点，这样一个动作，需要一定的时间进行移动，因此说移动是一个连续事件。　　逻辑服务器　　在这里可以称之为瞬时事件服务器，在这个服务器里，处理对象（玩家）所做的动作均可以在非常断时间内完成完成。例如玩家从商店购买一瓶药书，当玩家确认购买后，服务器先扣除玩家的游戏币，然后再把相应的药水瓶加入玩家的背包里。这2个操作对于服务器来说，只是2个数字的加减，计算完这两个数字的加减，这个事件就可以结束了。因此，我们可以说这个事件是一个瞬时事件服务器组的改进　　不过在实际应用的过程中，游戏服务器的结构要比上面所说的3种服务结构要复杂些，不过也都是在这3种最基本的服务器架构下进行扩充，扩充的主要是其它辅助功能。在实际应用里可能增加的2种服务器，数据库服务器，计费服务器，由逻辑服务器独立出来的聊天服务器。　　数据库服务器　　数据库服务器其实就是专门利用一台服务器进行数据库的读写操作。这点特别是在大型的网络游戏里尤为重要。因为在大型网络游戏里，要处理玩家的数据量非常大，如果不利用专门的服务器进行处理，很有可能会拖累这个服务器组。　　计费服务器　　通常在商业的网络游戏里出现，用于记录玩家在线的时间，给收费提供依据，同时也是整个服务器组里最重要的部分，一旦出现问题，运营商就不用赚钱了。　　聊天服务器　　在游戏里的聊天功能是属于一种瞬时动作，理论上是放在逻辑服务器里进行处理。不过在大型网络游戏里，因为这个部分功能与游戏里的其它部分联系并不紧密，因此可以独立出来做一个功能服务器。服务器的集群设置　　在大型游戏的应用过程中，实际需要处理的玩家数量可能过万，一台普通的服务器是无法完成所要完成的工作，因此，在实际应用的时候，通常是由一组多台服务器共同完成一个功能。　　例如地图服务器，可以根据需要，把游戏里所有的地域进行划分，划分为N个区域，然后让这一个区域里发生的事件都用一个特定的服务器进行处理。这样做的目的是减少一个服务器所承担的计算量，把整个系统组成一个分布式的网络。　　不过这样做的同时会造成一个麻烦：当一位玩家从区域1，移动到区域2。这个时候，就必须先在服务器1里把玩家删除，然后再在区域2里加入玩家。同时需要由服务器1向服务器2转移玩家的数据信息（因为服务器组在工作的时候，玩家的信息只能保存在当前所在区域的服务器里），也就是说一旦玩家发生服务器间区域移动，服务器端就不可避免的造成数据通讯。因为这种移动并不是有规律的，玩家所在的服务器都有可能到达其它服务器。这样，如果服务器组里有N台地图服务器，那么，每个服务器都可能向其它N－1台服务器产生连接，总共就可能产生N×N个连接。如此数量连接如果只是使用普通的socket设计，就很有可能会给服务器通讯间的各种问题所困扰，为此，在商业网络游戏的服务器之间，通常都使用成熟的第三方的通讯中间件，如ACE，ICE等作为网络连接的传输层。
做过游戏服务器的开发,也做过一般的互联网服务器的开发,在我看来两者的区别主要有两点.1)游戏服务器比一般的服务器要保存更多的状态:玩家的属性这些自不必说,一般的IM服务也会有,还有一些马上就会变化的数据,比如某个玩家的生命值,发技能前后的法力值等等,这些值区别于一般的属性值如名字,ID这些的差异在于,会经常性的变化,还会参与到逻辑的计算中,比如你一个多少等级的玩家吃了什么东西之后战力值变化为多少,打在一个多少属性的玩家身上会不会被他闪避,会不会产生暴击....游戏逻辑中的战斗技能计算是很大的一个点,我不太熟悉这块就不展开多说了.可以看到,游戏逻辑的CPU计算是非常多的.2)游戏服务中,每个玩家不是独立存在的,而是很有可能会与其他玩家发生状态的交互,一般的服务器比如HTTP什么的,你一个请求过来查你的数据,和别人的请求是独立的,并没有什么交互.客户端之间会有交互这一点,举最简单的例子,一个人在一个场景里面说了一句话,那么同一个屏幕的玩家也需要能够看到他说的这句话.此时游戏服务器就需要判断,多远的距离以内的玩家,会认定为是"同屏幕"的玩家,需要向这些玩家广播这个玩家说的这句话.这个广播就比较麻烦了.首先,计算哪些玩家在"同屏幕",就是我们在第一点提到的玩家身上某些经常变化的属性需要做的运算,在这里需要根据玩家的坐标,找出来跟在同屏幕的玩家,用到的是AOI的概念,感兴趣的可以看看 .另外,找到了这些需要接收这个消息的玩家之后,将消息转发给它们又是一个IO密集的操作,假如场景中有10个人,那么一句话就需要同时广播给另外9个人,假如有100人,1000人呢,量就更大了.所以同样的一个硬件配置的服务器,可能跑Nginx可以同时处理上万的链接,但是对于一个游戏服务器就只有1,2千了,就是因为游戏服务器是一个CPU密集而且IO密集的服务器类型.
最大的区别是，web服务器每个client都是独立的，游戏服务器不同client是有交互有状态，会实时地互相影响。这导致很多设计上的差异。并发架构的影响在高并发下，对client请求进行负载均衡并不如web那么简单，因为client状态会互相影响，并且可能共享写数据甚至有时序依赖。大型mmorpg通常是长连接，并发服务数通常要远小于web服务器 。根源就是实时性和强交互性的限制，两者要求越低的游戏，并发就可以做得越高。web服务运算较少，io密集，读多写少。游戏服计算和io都密集，读写都频繁对代码风格的影响比如开发web服务，基于nginx的openresty就很好用，利用了Lua的协程和异步io，写起来很流畅而不失性能。但用来做游戏服务器，协程却可能是个坑，因为游戏依赖很多上下文环境，当协程被唤醒时，上下文环境改变，协程的代码风格很容易用了旧变量导致逻辑错误。
web服务器基本是无状态的. 游戏服务器是强状态的, 耦合自己不说, 还要耦合别人, 别的大区...
没有本质区别 只是在开发原则上和开发难度上有点差异。而且两者还是可以相互平衡的先说开发原则的问题，如果偷懒，或者水平有限，或者历史包袱沉重，那游戏服务器要考虑较多的稳定性和效率的问题，毕竟最偷懒的做法还是所有的状态在进程内存空间里，如果宕了就没了，而这样玩，你能折腾的cpu也没几个，没几下就到计算上限了当然了，如果你足够牛，上面的问题都不是问题，但绝大部分人不得不面对一个和开发通用软件不同的地方，你没多少现成的轮子可以用，无论是理论层面的还是工具层面的，毕竟来源的网游大作好像真不多其他的，好像真没什么区别
主要看游戏类型了 一些弱联网的游戏 比如早期卡牌手游 服务端其实和web没多大区别 但是像wow lol或者moba手游等这样强联网的游戏 就是长链接的服务端 一般经过登陆服务器选择游戏服以后 就和服务端建起一个长链接进行通讯
视情况而定，弱联网、短连接，即采用HTTP方式通讯和普通Web服务器基本没有区别；强联网、长连接，即采用Socket方式通讯更注重同步性。其次从连接状态来看，普通Web服务器是有求必应，各个客户端即浏览器间是没有消息传递的，都是由服务器来返回数据，而游戏服务器特别是MMORPG这类游戏每个状态的变化都需要服务器广播给所有客户端，高并发、高同步是主要特点。
强交互的游戏服务器会产生大量的广播包，web服务器不存在这个问题
硬件上都是普通PC服务器，无区别。web与网络游戏应用在软件架构上天差地别，网络游戏尤其是MMORPG是集世界上最尖端的计算机技术之大成为一体！
已有帐号？
无法登录？
社交帐号登录四大厂商八路服务器横向对比 谁是王者?
　作者: 于泽　编辑:
&&&&【IT168&专稿】谈到八路x86服务器，其实并不算陌生，早在2007年，IBM就推出了可扩展至八路服务器的四路服务器IBM x3850 M2。八路服务器主要针对大型数据库、商业智能、虚拟化整合等关键应用，然而当时这片市场还被小型机牢牢地控制着。究其原因，当然是x86服务器在RAS(可靠性，可用性、可用性)方面不尽如人意，无法满足关键业务的需求，但是这几年随着Intel、AMD在RAS特性上的改进，x86服务器渐渐开始被人们看好，也越来越多的被应用于企业关键应用。　　本文将会对市面上常见的八路x86服务器做一个横向对比，对比机型有：HP DL785 G6，HP DL980 G7，IBM x3850 x5，浪潮TS850，曙光A950r-F，曙光I950r-G，首先通过表格对各个服务器有个整体的了解。　　从表中不难发现一个总体的情况，在八路x86服务器市场，英特尔处理器平台占据着大壁江山;而另一方面国内国外平分秋色。在此有必要说明一点，据目前查找到的资料，各大厂商的AMD平台的八路服务器并没有更新到最新的马尼库尔12核芯处理器，而Intel平台的八路服务器则都已更新到最新的至强E7系列处理器。所以在此我们对于Intel平台和AMD平台之间的差别不做过多的比较，而将它们分开对比。　　Intel平台　　处理器：目前各大厂商的八路服务器均支持最新的Intel至强E7处理器，按八路来计算，最高支持80个内核。　　支持的最大处理器数量：在讨论的四款Intel平台的八路服务器中，只有IBM x3850 x5算不上真正的八路服务器，而它实现八路服务器是通过两台x3850 x5级联而实现的，同时它还支持向上扩展至12路，16路;而其它的服务器虽然可以降级用作四路服务器，但最高也就扩展至8路。综合对比处理器数量的扩展性，IBM x3850 x5胜出。　　内存类型：基于Intel平台的八路服务器目前支持的都是DDR3内存。　　最大内存支持：基于英特尔平台的八路服务器，最大内存支持大多都是2TB，而这其中IBM x3850 x5由于使用EX5架构中的MAX5内存技术，使IBM x3850 x5在内存的支持上脱颖而出，扩展至8路时，最大内存可支持到3TB，具体查看EX5架构的五大创新奠基IBM x3850 X5一文，因此最大内存支持方面，IBM x3850 x5胜出。　　I/O扩展槽数量：冠军：HP DL980 G7，拥有16个PCI I/O扩展槽。　　存储冠军：浪潮TS850，最大支持18个硬盘槽位。　　高密度集成冠军：曙光I950r-G，5U的高度可以说曙光在高密度集成方面下了不少功夫。　　AMD平台　　相比HP DL785 G6和曙光A950r-F，三点区别比较大，第一，最大内存支持，惠普DL785 G6最大内存支持为512GB，为A950r-F的两倍;第二，I/O扩展槽数量，HP DL785 G6标配达11个扩展槽，远高于A950r-F的5个;第三，外观高度，虽然HP DL785 G6支持的内存大，I/O扩展槽也多，但是其付出的代价也不小，体型大，高度达7U，而曙光A950r-F仅5U。　　
第1页：第2页：
大学生分期购物销量榜
已有条评论
IT168企业级