大型网站服务器租用需要考虑的有哪些？

既然说了大型，首先要考虑的就是高用户并发的情况。这就需要结合你实际用户端应用场景，视频都双向传输和简单的低通量的文本交互一定不是一个概念。做大型的系统，还要考虑平时的情况和突发的高占用率情况。

首先我们先对应用做一个分类：

1高带宽消耗累应用

这个方面的代表就是直播相关或网络教学领域。直播系统的大体原理，主播手机采集音视频、编码，然后推送一个视频流给服务器（实际上是一个做了负载均衡的视频服务器矩阵组）。然后负责实时流媒体数据流接收的服务器，会将流媒体数据流推送给分发服务器（现在有现成的CDN,这样开发难度就小了很多。）然后观众申请观看的时候，分发服务器就会将所申请的时时流媒体推荐给客户。

这么粗糙的应用就可能包换用户端权限管理服务器组，业务调度服务器组，不同区域IDC建立的接入服务器组，不同区域IDC建立的分发服务器组，分等级的数据存储服务器组，ai内容审核服务器组（基于分流实时分析，预设内容审核规则），归档视频存储服务器组，短视频评级推荐服务器组，应用兴趣行为分析服务器组。客户在请求交互的时候可能还会有一些缓冲的队列呀，nosql之类的（redis，memcache）。各组服务器的规格和数量都是根据同时并发的情况定的，在程序开发好的时间可以通过自动化的方式模拟高并发，再通过查看分析瓶颈，而对前期的规划做出合适的调整。

有些时间还要实现不经过分发，交互直通以降低延时。pk的连线的时候，太高延时是接受不了的。这个就不继续展开了。

还有网盘类应用也也很多类似，只是延时要求没那么高。传统的视频网站也是基本相同原理。

传统的微博也是类似的分发机制。

2低延时需求型

这方面一般是以网络游戏为主。对于一些点电子竞技类的应用，做到80ms以下的低延时是必须。服务器的核心响应速度和带宽的低延时是重点。这种服务器最好可以独享一条专线，或者在虚拟网络系统中设置一个更高的优先级，数据线优先同行也会尽可能的降低延时。至于服务器组之间的vpc也应该有一个更高的通过优先级，以保证服务器之间的访问延时极地。这种应用服务器，最好要支持核心运算，不过这个要开发的架构支持。

再就是后期用户量大的时候，做更新包下载的时候会采用分发服务器（CDN）。

3高突发的缓冲

这种都是电商网站，平时就是讲全段应用服务器做彼此依赖，后端选择一个大吞吐，大并发的后端框架（京东使用的go语言对高并发和数据挖掘就有很多优势，我也刚开始学习）。这种系统网元架构就简单很多，传统的负载均衡后挂着不同模块的应用服务器组，然后经过缓冲服务器组，之后到达数据服务器组和APIGateway。

日常的应用都是没啥问题，都是因为一些节日或促销，或爆款等发生临时性数据 *** 作的拥堵。解决这种缓冲都方式有很多，比如临时快速读写缓存，消息队列等。甚至开发总线通信队列等待机制，很多解决方案。

现在系统本身的规划和后期都优化都有许多解决方案，现在的瓶颈往往是系统间的交互通信。

服务器种类各云服务商都称呼也不一致，总体说分为轻量应用服务器，负载均衡服务器，超算服务器（CPU和GPU两个方向,后者也常常被成为图形处理服务器。）数据服务器（常见的版本都有），文件服务器（nas和oss），分发服务器，缓冲服务器，数据分析服务器。我项目中使用大大类就这些了，也许有些我没用过和不知道的，希望大家在讨论区补充纠正。

希望对你认知有所拓展。

一、主从服务器

1、两台服务器。主服务器Master复制数据的更新、插入、删除等 *** 作； 从服务器Slave负责查询（读写分离，减缓服务器压力）

2、主服务器更新数据的同时更新从服务器的数据（数据备份）

3、当主服务器出现文件时，可用从服务器代替主服务器，保证网站的正常运行，同时检测主服务器存在的问题。注意：从服务器仍然只有查询功能，如银行系统更新时只能查询余额，不能存取款。（服务器可用性）

4、当把从服务器真正设置为主服务器时（即主从服务器设置调换），拥有更新数据的功能。

5、MyISAM不支持事务，但查询性能比InnoDB强；InnoDB支持事务，更新 *** 作性能比MyISAM强。因此，主服务器可以设置成MyISAM存储引擎，从服务器可以设置成InnoDB存储引擎（灵活设置存储引擎）

二、负载均衡

1、多台服务器。一个域名映射到多台服务器IP。

2、用户发出请求，提交到负载均衡服务器，由负载均衡服务器发送请求到不同的服务器。

3、负载均衡服务器选取服务器方法（负载均衡算法）：

1、轮询：每台服务器轮换

2、加权轮询：为了应对某些服务器性能好，可以让他们的权重高一点，被选中的几率大一些。

3、最少连接：哪台服务器处理的连接少，就发给哪台服务器。

4、随机

4、存在的问题：客户端存在缓存，如果服务器出现故障，客户端报错。

5、分类：DNS负载均衡、>kafka是个日志处理缓冲组件，在大数据信息处理中使用。和传统的消息队列相比较简化了队列结构和功能，以流形式处理存储（持久化）消息（主要是日志）。日志数据量巨大，处理组件一般会处理不过来，所以作为缓冲层的kafka，支持巨大吞吐量。为了防止信息丢失，其消息被调用后不直接丢弃，要多存储一段时间，等过期时间过了才丢弃。这是mq和redis不能具备的。主要特点如下:巨型存储量: 支持TB甚至PB级别数据。高吞吐，高IO：一般配置的服务器能实现单机每秒100K以上消息的传输。消息分区，分布式消费：能保消息顺序传输。 支持离线数据处理和实时数据处理。Scale out：支持在线水平扩展，以支持更大数据处理量

redis只是提供一个高性能的、原子 *** 作内存键值对，具有高速访问能力，可用做消息队列的存储，但是不具备消息队列的任何功能和逻辑，要作为消息队列来实现的话，功能和逻辑要通过上层应用自己实现。

我们以RabbitMQ为例介绍。它是用Erlang语言开发的开源的消息队列，支持多种协议，包括AMQP，XMPP, SMTP, STOMP。适合于企业级的开发。
MQ支持Broker构架，消息发送给客户端时需要在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。

还有ActiveMq，ZeroMq等。功能基本上大同小异。并发吞吐TPS比较，ZeroMq 最好，RabbitMq 次之， ActiveMq 最差。

原文：

众所周知，服务器是整个网络系统和计算平台的核心，许多重要的数据都保存在服务器上，很多网络服务都在服务器上运行，因此服务器性能的好坏决定了整个应用系统的性能。

现在市面上不同品牌、不同种类的服务器有很多种，用户在选购时，怎样从纷繁的型号中选择出所需要的，适合于自己应用的服务器产品，仅仅从配置上判别是不够的，能够通过实际测试来筛选。而各种的评测软件有很多种，你应该选择哪个软件测试？下面就介绍一些较典型的测试工具：

（一）服务器整机系统性能测试工具

一台服务器系统的性能可以按照处理器、内存、存储、网络几部分来划分，而针对不同的应用，可能会对某些部分的性能要求高一些。

Iometer（>