消息队列原理及选型

消息队列（Message Queue）是一种进程间通信或同一进程的不同线程间的通信方式。

Broker（消息服务器）
Broker的概念来自与Apache ActiveMQ，通俗的讲就是MQ的服务器。

Producer（生产者）
业务的发起方，负责生产消息传输给broker

Consumer（消费者）
业务的处理方，负责从broker获取消息并进行业务逻辑处理

Topic（主题）
发布订阅模式下的消息统一汇集地，不同生产者向topic发送消息，由MQ服务器分发到不同的订阅 者，实现消息的广播

Queue（队列）
PTP模式下，特定生产者向特定queue发送消息，消费者订阅特定的queue完成指定消息的接收。

Message（消息体）
根据不同通信协议定义的固定格式进行编码的数据包，来封装业务数据，实现消息的传输

点对点模型用于消息生产者和消息消费者之间点到点的通信。

点对点模式包含三个角色：

每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，可以放在内存 中也可以持久化，直到他们被消费或超时。

特点：

发布订阅模型包含三个角色：

多个发布者将消息发送到Topic，系统将这些消息传递给多个订阅者。

特点：

AMQP即Advanced Message Queuing Protocol，是应用层协议的一个开放标准，为面向消息的中间件设计。消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，反之亦然。AMQP 的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。

优点：可靠、通用

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和致动器（比如通过Twitter让房屋联网）的通信协议。

优点：格式简洁、占用带宽小、移动端通信、PUSH、嵌入式系统

STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息协议，是一种为MOM(Message Oriented Middleware，面向消息的中间件)设计的简单文本协议。STOMP提供一个可互 *** 作的连接格式，允许客户端与任意STOMP消息代理（Broker）进行交互。

优点：命令模式（非topic\queue模式）

XMPP（可扩展消息处理现场协议，Extensible Messaging and Presence Protocol）是基于可扩展标记语言（XML）的协议，多用于即时消息（IM）以及在线现场探测。适用于服务器之间的准即时 *** 作。核心是基于XML流传输，这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息，即使其 *** 作系统和浏览器不同。

优点：通用公开、兼容性强、可扩展、安全性高，但XML编码格式占用带宽大

RabbitMQ 是实现 AMQP（高级消息队列协议）的消息中间件的一种，最初起源于金融系统，用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。 RabbitMQ 主要是为了实现系统之间的双向解耦而实现的。当生产者大量产生数据时，消费者无法快速消费，那么需要一个中间层。保存这个数据。

RabbitMQ 是一个开源的 AMQP 实现，服务器端用Erlang语言编写，支持多种客户端，如：Python、Ruby、NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP 等，支持 AJAX。用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。

Channel（通道）
道是两个管理器之间的一种单向点对点的的通信连接，如果需要双向交流，可以建立一对通道。

Exchange（消息交换机）
Exchange类似于数据通信网络中的交换机，提供消息路由策略。

RabbitMq中，producer不是通过信道直接将消息发送给queue，而是先发送给Exchange。一个Exchange可以和多个Queue进行绑定，producer在传递消息的时候，会传递一个ROUTING_KEY，Exchange会根据这个ROUTING_KEY按照特定的路由算法，将消息路由给指定的queue。和Queue一样，Exchange也可设置为持久化，临时或者自动删除。

Exchange有4种类型：direct(默认)，fanout， topic， 和headers。
不同类型的Exchange转发消息的策略有所区别：

Binding（绑定）
所谓绑定就是将一个特定的 Exchange 和一个特定的 Queue 绑定起来。Exchange 和Queue的绑定可以是多对多的关系。

Routing Key（路由关键字）
exchange根据这个关键字进行消息投递。

vhost（虚拟主机）
在RabbitMq server上可以创建多个虚拟的message broker，又叫做virtual hosts (vhosts)。每一个vhost本质上是一个mini-rabbitmq server，分别管理各自的exchange，和bindings。vhost相当于物理的server，可以为不同app提供边界隔离，使得应用安全的运行在不同的vhost实例上，相互之间不会干扰。producer和consumer连接rabbit server需要指定一个vhost。

假设P1和C1注册了相同的Broker，Exchange和Queue。P1发送的消息最终会被C1消费。
基本的通信流程大概如下所示：

Consumer收到消息时需要显式的向rabbit broker发送basic。ack消息或者consumer订阅消息时设置auto_ack参数为true。

在通信过程中，队列对ACK的处理有以下几种情况：

即消息的Ackownledge确认机制，为了保证消息不丢失，消息队列提供了消息Acknowledge机制，即ACK机制，当Consumer确认消息已经被消费处理，发送一个ACK给消息队列，此时消息队列便可以删除这个消息了。如果Consumer宕机/关闭，没有发送ACK，消息队列将认为这个消息没有被处理，会将这个消息重新发送给其他的Consumer重新消费处理。

消息的收发处理支持事务，例如：在任务中心场景中，一次处理可能涉及多个消息的接收、处理，这应该处于同一个事务范围内，如果一个消息处理失败，事务回滚，消息重新回到队列中。

消息的持久化，对于一些关键的核心业务来说是非常重要的，启用消息持久化后，消息队列宕机重启后，消息可以从持久化存储恢复，消息不丢失，可以继续消费处理。

fanout 模式
模式特点：

direct 模式
任何发送到Direct Exchange的消息都会被转发到routing_key中指定的Queue。

如果一个exchange 声明为direct，并且bind中指定了routing_key，那么发送消息时需要同时指明该exchange和routing_key。

简而言之就是：生产者生成消息发送给Exchange， Exchange根据Exchange类型和basic_publish中的routing_key进行消息发送 消费者：订阅Exchange并根据Exchange类型和binding key(bindings 中的routing key) ，如果生产者和订阅者的routing_key相同，Exchange就会路由到那个队列。

topic 模式
前面讲到direct类型的Exchange路由规则是完全匹配binding key与routing key，但这种严格的匹配方式在很多情况下不能满足实际业务需求。

topic类型的Exchange在匹配规则上进行了扩展，它与direct类型的Exchage相似，也是将消息路由到binding key与routing key相匹配的Queue中，但这里的匹配规则有些不同。
它约定：

以上图中的配置为例，routingKey=”quickorangerabbit”的消息会同时路由到Q1与Q2，routingKey=”lazyorangefox”的消息会路由到Q1，routingKey=”lazybrownfox”的消息会路由到Q2，routingKey=”lazypinkrabbit”的消息会路由到Q2（只会投递给Q2一次，虽然这个routingKey与Q2的两个bindingKey都匹配）；routingKey=”quickbrownfox”、routingKey=”orange”、routingKey=”quickorangemalerabbit”的消息将会被丢弃，因为它们没有匹配任何bindingKey。

RabbitMQ，部署分三种模式：单机模式，普通集群模式，镜像集群模式。

普通集群模式
多台机器部署，每个机器放一个rabbitmq实例，但是创建的queue只会放在一个rabbitmq实例上，每个实例同步queue的元数据。

如果消费时连的是其他实例，那个实例会从queue所在实例拉取数据。这就会导致拉取数据的开销，如果那个放queue的实例宕机了，那么其他实例就无法从那个实例拉取，即便开启了消息持久化，让rabbitmq落地存储消息的话，消息不一定会丢，但得等这个实例恢复了，然后才可以继续从这个queue拉取数据， 这就没什么高可用可言，主要是提供吞吐量 ，让集群中多个节点来服务某个queue的读写 *** 作。

镜像集群模式

queue的元数据和消息都会存放在多个实例，每次写消息就自动同步到多个queue实例里。这样任何一个机器宕机，其他机器都可以顶上，但是性能开销太大，消息同步导致网络带宽压力和消耗很重，另外，没有扩展性可言，如果queue负载很重，加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展你的queue。此时，需要开启镜像集群模式，在rabbitmq管理控制台新增一个策略，将数据同步到指定数量的节点，然后你再次创建queue的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。

Kafka 是 Apache 的子项目，是一个高性能跨语言的分布式发布/订阅消息队列系统（没有严格实现 JMS 规范的点对点模型，但可以实现其效果），在企业开发中有广泛的应用。高性能是其最大优势，劣势是消息的可靠性（丢失或重复），这个劣势是为了换取高性能，开发者可以以稍降低性能，来换取消息的可靠性。

一个Topic可以认为是一类消息，每个topic将被分成多个partition(区)，每个partition在存储层面是append log文件。任何发布到此partition的消息都会被直接追加到log文件的尾部，每条消息在文件中的位置称为offset（偏移量），offset为一个long型数字，它是唯一标记一条消息。它唯一的标记一条消息。kafka并没有提供其他额外的索引机制来存储offset，因为在kafka中几乎不允许对消息进行“随机读写”。

Kafka和JMS（Java Message Service）实现(activeMQ)不同的是:即使消息被消费，消息仍然不会被立即删除。日志文件将会根据broker中的配置要求，保留一定的时间之后删除；比如log文件保留2天，那么两天后，文件会被清除，无论其中的消息是否被消费。kafka通过这种简单的手段，来释放磁盘空间，以及减少消息消费之后对文件内容改动的磁盘IO开支。

对于consumer而言，它需要保存消费消息的offset，对于offset的保存和使用，有consumer来控制；当consumer正常消费消息时，offset将会"线性"的向前驱动，即消息将依次顺序被消费。事实上consumer可以使用任意顺序消费消息，它只需要将offset重置为任意值。(offset将会保存在zookeeper中，参见下文)

kafka集群几乎不需要维护任何consumer和producer状态信息，这些信息有zookeeper保存；因此producer和consumer的客户端实现非常轻量级，它们可以随意离开，而不会对集群造成额外的影响。

partitions的设计目的有多个。最根本原因是kafka基于文件存储。通过分区，可以将日志内容分散到多个server上，来避免文件尺寸达到单机磁盘的上限，每个partiton都会被当前server(kafka实例)保存；可以将一个topic切分多任意多个partitions，来消息保存/消费的效率。此外越多的partitions意味着可以容纳更多的consumer，有效提升并发消费的能力。(具体原理参见下文)。

一个Topic的多个partitions，被分布在kafka集群中的多个server上；每个server(kafka实例)负责partitions中消息的读写 *** 作；此外kafka还可以配置partitions需要备份的个数(replicas)，每个partition将会被备份到多台机器上，以提高可用性。

基于replicated方案，那么就意味着需要对多个备份进行调度；每个partition都有一个server为"leader"；leader负责所有的读写 *** 作，如果leader失效，那么将会有其他follower来接管(成为新的leader)；follower只是单调的和leader跟进，同步消息即可。由此可见作为leader的server承载了全部的请求压力，因此从集群的整体考虑，有多少个partitions就意味着有多少个"leader"，kafka会将"leader"均衡的分散在每个实例上，来确保整体的性能稳定。

Producers
Producer将消息发布到指定的Topic中，同时Producer也能决定将此消息归属于哪个partition；比如基于"round-robin"方式或者通过其他的一些算法等。

Consumers
本质上kafka只支持Topic。每个consumer属于一个consumer group；反过来说，每个group中可以有多个consumer。发送到Topic的消息，只会被订阅此Topic的每个group中的一个consumer消费。

如果所有的consumer都具有相同的group，这种情况和queue模式很像；消息将会在consumers之间负载均衡。

如果所有的consumer都具有不同的group，那这就是"发布-订阅"；消息将会广播给所有的消费者。

在kafka中，一个partition中的消息只会被group中的一个consumer消费；每个group中consumer消息消费互相独立；我们可以认为一个group是一个"订阅"者，一个Topic中的每个partions，只会被一个"订阅者"中的一个consumer消费，不过一个consumer可以消费多个partitions中的消息。kafka只能保证一个partition中的消息被某个consumer消费时，消息是顺序的。事实上，从Topic角度来说，消息仍不是有序的。

Kafka的设计原理决定，对于一个topic，同一个group中不能有多于partitions个数的consumer同时消费，否则将意味着某些consumer将无法得到消息。

Guarantees

Kafka就比较适合高吞吐量并且允许少量数据丢失的场景，如果非要保证“消息可靠传输”，可以使用JMS。

Kafka Producer 消息发送有两种方式(配置参数 producertype)：

对于同步方式(producertype=sync)？Kafka Producer 消息发送有三种确认方式(配置参数 acks)：

kafka的设计初衷是希望作为一个统一的信息收集平台，能够实时的收集反馈信息，并需要能够支撑较大的数据量，且具备良好的容错能力。

持久性
kafka使用文件存储消息，这就直接决定kafka在性能上严重依赖文件系统的本身特性。且无论任何OS下，对文件系统本身的优化几乎没有可能。文件缓存/直接内存映射等是常用的手段。因为kafka是对日志文件进行append *** 作，因此磁盘检索的开支是较小的；同时为了减少磁盘写入的次数，broker会将消息暂时buffer起来，当消息的个数(或尺寸)达到一定阀值时，再flush到磁盘，这样减少了磁盘IO调用的次数。

性能
需要考虑的影响性能点很多，除磁盘IO之外，我们还需要考虑网络IO，这直接关系到kafka的吞吐量问题。kafka并没有提供太多高超的技巧；对于producer端，可以将消息buffer起来，当消息的条数达到一定阀值时，批量发送给broker；对于consumer端也是一样，批量fetch多条消息。不过消息量的大小可以通过配置文件来指定。对于kafka broker端，似乎有个sendfile系统调用可以潜在的提升网络IO的性能:将文件的数据映射到系统内存中，socket直接读取相应的内存区域即可，而无需进程再次copy和交换。 其实对于producer/consumer/broker三者而言，CPU的开支应该都不大，因此启用消息压缩机制是一个良好的策略；压缩需要消耗少量的CPU资源，不过对于kafka而言，网络IO更应该需要考虑。可以将任何在网络上传输的消息都经过压缩。kafka支持gzip/snappy等多种压缩方式。

生产者
负载均衡: producer将会和Topic下所有partition leader保持socket连接；消息由producer直接通过socket发送到broker，中间不会经过任何“路由层“。事实上，消息被路由到哪个partition上，有producer客户端决定。比如可以采用“random““key-hash““轮询“等，如果一个topic中有多个partitions，那么在producer端实现“消息均衡分发“是必要的。

其中partition leader的位置(host:port)注册在zookeeper中，producer作为zookeeper client，已经注册了watch用来监听partition leader的变更事件。
异步发送：将多条消息暂且在客户端buffer起来，并将他们批量的发送到broker，小数据IO太多，会拖慢整体的网络延迟，批量延迟发送事实上提升了网络效率。不过这也有一定的隐患，比如说当producer失效时，那些尚未发送的消息将会丢失。

消费者
consumer端向broker发送“fetch”请求，并告知其获取消息的offset；此后consumer将会获得一定条数的消息；consumer端也可以重置offset来重新消费消息。

在JMS实现中，Topic模型基于push方式，即broker将消息推送给consumer端。不过在kafka中，采用了pull方式，即consumer在和broker建立连接之后，主动去pull(或者说fetch)消息；这中模式有些优点，首先consumer端可以根据自己的消费能力适时的去fetch消息并处理，且可以控制消息消费的进度(offset)；此外，消费者可以良好的控制消息消费的数量，batch fetch。

其他JMS实现，消息消费的位置是有prodiver保留，以便避免重复发送消息或者将没有消费成功的消息重发等，同时还要控制消息的状态。这就要求JMS broker需要太多额外的工作。在kafka中，partition中的消息只有一个consumer在消费，且不存在消息状态的控制，也没有复杂的消息确认机制，可见kafka broker端是相当轻量级的。当消息被consumer接收之后，consumer可以在本地保存最后消息的offset，并间歇性的向zookeeper注册offset。由此可见，consumer客户端也很轻量级。

对于JMS实现，消息传输担保非常直接:有且只有一次(exactly once)。
在kafka中稍有不同:

at most once: 消费者fetch消息，然后保存offset，然后处理消息；当client保存offset之后，但是在消息处理过程中出现了异常，导致部分消息未能继续处理。那么此后"未处理"的消息将不能被fetch到，这就是"at most once"。

at least once: 消费者fetch消息，然后处理消息，然后保存offset。如果消息处理成功之后，但是在保存offset阶段zookeeper异常导致保存 *** 作未能执行成功，这就导致接下来再次fetch时可能获得上次已经处理过的消息，这就是"at least once"，原因offset没有及时的提交给zookeeper，zookeeper恢复正常还是之前offset状态。

exactly once: kafka中并没有严格的去实现(基于2阶段提交，事务)，我们认为这种策略在kafka中是没有必要的。

通常情况下“at-least-once”是我们首选。(相比at most once而言，重复接收数据总比丢失数据要好)。

kafka高可用由多个broker组成，每个broker是一个节点；

创建一个topic，这个topic会划分为多个partition，每个partition存在于不同的broker上，每个partition就放一部分数据。

kafka是一个分布式消息队列，就是说一个topic的数据，是分散放在不同的机器上，每个机器就放一部分数据。

在08版本以前，是没有HA机制的，就是任何一个broker宕机了，那个broker上的partition就废了，没法写也没法读，没有什么高可用性可言。

08版本以后，才提供了HA机制，也就是就是replica副本机制。每个partition的数据都会同步到其他的机器上，形成自己的多个replica副本。然后所有replica会选举一个leader出来，那么生产和消费都跟这个leader打交道，然后其他replica就是follower。

写的时候，leader会负责把数据同步到所有follower上去，读的时候就直接读leader上数据即可。

kafka会均匀的将一个partition的所有replica分布在不同的机器上，从而提高容错性。

如果某个broker宕机了也没事，它上面的partition在其他机器上都有副本的，如果这上面有某个partition的leader，那么此时会重新选举一个新的leader出来，大家继续读写那个新的leader即可。这就有所谓的高可用性了。

写数据的时候，生产者就写leader，然后leader将数据落地写本地磁盘，接着其他follower自己主动从leader来pull数据。一旦所有follower同步好数据了，就会发送ack给leader，leader收到所有follower的ack之后，就会返回写成功的消息给生产者。

消息丢失会出现在三个环节，分别是生产者、mq中间件、消费者：

RabbitMQ

Kafka
大体和RabbitMQ相同。

Rabbitmq
需要保证顺序的消息投递到同一个queue中，这个queue只能有一个consumer，如果需要提升性能，可以用内存队列做排队，然后分发给底层不同的worker来处理。

Kafka
写入一个partition中的数据一定是有序的。生产者在写的时候 ，可以指定一个key，比如指定订单id作为key，这个订单相关数据一定会被分发到一个partition中去。消费者从partition中取出数据的时候也一定是有序的，把每个数据放入对应的一个内存队列，一个partition中有几条相关数据就用几个内存队列，消费者开启多个线程，每个线程处理一个内存队列。

500个？测试环境是wndows吧？
socket连接是有连接上限的，主要限制在于cpu与内存
所以都要考虑服务器的负载能力去设置上限
比如说 浩方的房间都是200个，而不是无限。
那如果好增加这个最大连接数该怎么做呢？
这个问题问的好
微软为了解决这个问题，推出了号称最复杂的io的完成端口
单台服务器能带2万个连接都没问题。如果你要做大型的服务，那就必须考虑完成端口
否则只能限制连接数

当然，java运行在linux下或许会好一些，以为linux是进程模拟的线程。

一，我们先来了解下云主机和VPS的详细区别

1、虚拟主机、VPS和云主机

共享主机也称虚拟主机,从互联网诞生至今,大部分站长都是从”共享主机”(shared hosting)开始学习建站的。所谓”共享主机”,就是一台服务器上有许多网站,大家共享这台服务器的硬件和带宽。如果它发生故障,那么上面的所有网站都无法访问。

VPS主机(Virtual Private Server 虚拟专用服务器),将一部服务器分割成多个虚拟专享服务器的优质服务。每个VPS都可分配独立公网IP地址、独立 *** 作系统、独立超大空间、独立内存、独立CPU资源、独立执行程序和独立系统配置等。用户除了可以分配多个虚拟主机及无限企业邮箱外,更具有独立服务器功能,可自行安装程序,单独重启服务器。

”云主机”(Cloud hosting)可以看成是新一代的共享主机。

首先,主机公司将它的硬件和网络线路,做成一朵”云”,然后提供一些通向这朵”云”的网络接口API,供客户使用。这时,每个客户共享的不再是某一台特定的服务器,而是云里的所有服务器。

比如,假设你要把本机的文件备份到网上,你可以使用共享主机,把文件传到某一台服务器上;也可以使用云主机,通过某种形式的接口,把它们传到云里。也就是说,共享主机用户直接面对特定的服务器,而云主机用户直接面对网络接口,看不到服务器内部。

一个通俗的比喻是,你可以向银行租一个编号为”8888″的保险箱(共享主机),也可以把贵重物品直接交给保管公司,听任他们保管。

诸如Gmail、FaceBook、Twitter、Flickr这样的产品,都可以看作是基于”云主机”的服务。

云主机能真正获得root权限,用户可以重装和升级 *** 作系统,而VPS主机用户没有root权限,无法重装和升级 *** 作系统。

2、虚拟主机、VPS、云主机的区别

(1)供应和部署时间

虚拟主机——数天至数周

VPS———即时,无需安装 *** 作系统

云主机——即时,几分钟即可完成,可一键部署、也可自主安装 *** 作系统

(2)安全可靠性

虚拟主机——一般:租用白牌服务器故障率高、基本无ARP、木马和DDOS防范能力、基本无备机和数据备份服务

VPS———差:同一台物理服务器上其他VPS上安装的程序缺陷、ARP欺骗、病毒、资源挤占等会严重影响到自身;基本无ARP、木马和DDOS防范能力

云主机——高:内置ARP防范,规模化提升DDOS防攻击能力;分享品牌企业级服务器和硬件虚拟化的性能和可靠性,内置HA;提供备机、快照、数据备份等多种快速恢复措施

(3)性能及保障

虚拟主机——好且有保障

VPS———差:性能一般,只适用于小规模并发访问;性能无保障,易遭受同一台物理服务器上其他VPS的挤压

云主机——好且有保障:同物理服务器

(4)d性和扩展性

虚拟主机——扩容需要重新租用新服务器、还需为原有租用资源付费

VPS———扩容快,受制于单台服务器配置

云主机——即时供应、按需扩展 ,无需为原有租用资源付费

(5)拥有成本

虚拟主机——季付年付成本高、需要为服务商转嫁CapEx支出支付押金;需要自己维护租用的服务器导致Opex较高

VPS———低配置的VPS租用价格最低;但低安全可靠性和无保障的性能导致服务质量无保障,运营成本难控制且偏高

云主机——综合成本最低:月付无押金、按需使用按需付费、基本零维护 ,还可分享规模化、绿色节能、最佳IT实践带来的成本优势

(6)易用、易管理性

虚拟主机——需要远程控制卡且只有租用品牌机才有可能,无法实现集中统一管理

VPS———提供单一的单机管理界面,无root或超级管理员 *** 作系统权限,管理灵活性受制于管理界面

云主机——内置KVM、客户通过自服务系统可以集中统一管理分布在各地的云主机;完全拥有root或超级管理员 *** 作系统权限

3、云主机的优点

云主机主要有三大优点。

(1)便宜。

因为服务可以分散到多台服务器,因此能够充分利用资源,这样就降低了硬件、电力和维护成本。而且,云主机是根据使用量计费的,多用多付,少用少付,所以对小网站特别有利。

(2)可靠。

因为服务分布在多台服务器、甚至多个机房,所以不容易彻底宕机,抗灾容错能力强,可以保证长时间在线。

(3)可扩展性好(scalability)。

云主机的基本特点就是分布式架构,所以可以轻而易举地增加服务器,成倍扩展服务能力。

四、云主机的缺点

一些客户担心云主机的安全问题,感到对服务缺乏控制。

因为云主机只是提供网络接口,所以客户的数据必然全部服从云服务公司的安排,完全在后者控制之下。数据是否安全保密,取决于后者的职业道德和保护能力。

二，云主机和VPS的区别三

不同企业和云主机性能会有所差别, 因为这里不能一概而论。下面的数据是来之佛山数据中心，并不代表所有云主机都拥有这样性能。

综合比较     阿里云             腾讯云                  高防独立服务器  

开通交付     在线开通,3-10分钟       服务商人工,1小时      服务商人工,1工作日及以上  

成本比较      综合成本低,           成本低,安全无保障               成本高

管理功能    在线开机重启，1分钟      服务商人工,15-30分钟    服务商人工,15-30分钟  

升级拓展    在线升级cpu,1分钟       服务商人工,1小时     服务商人工,1工作日及以上

修改密码     在线,1分钟        服务商人工,有风险,数小时     服务商人工,破解很麻烦、有 风险,数小时

重装、换系统     在线自助,3分钟       服务商人工,1小时            服务商人工,数小时  

故障恢复     存储系统可保证数据安全  数据彻底损失服务器损失,    数据彻底损失

数据备份      业内领先快照技术,一键在线备份系统和 数据,十几秒    服务商人工,不能备份系统状态,时间较长

网络安全    IP与MAC绑定,万兆网络,NP-10000防火墙防护    无MAC绑定,千兆网络    无MAC绑定,千兆网络  

以上是云服务器VPS主机的系统性能差别。

比如重做系统，云主机只需要三分钟。 当然不同的公司会有所区别，像阿里云这样大云一般1分钟内可以完成，小的公司也可以在15分钟内完速度比VPS快很多。

所以云服务器还是值得购买的。但是云主机的技术门槛高，真有实力提供真真云主机商家屈指可数，建议如果是网站的日PV很高的这种，做多机负载比较好 ，当然要考虑防御跟安全这块，还有就是稳定性能，DDOS，CC，这种防御建议还是用独立服务器比较好，像目前防御比较好点的机房佛山机房就是不错的。

谈到DDoS防御，首先就是要知道到底遭受了多大的攻击。这个问题看似简单，实际上却有很多不为人知的细节在里面。

以SYN Flood为例，为了提高发送效率在服务端产生更多的SYN等待队列，攻击程序在填充包头时，IP首部和TCP首部都不填充可选的字段，因此IP首部长度恰好是20字节，TCP首部也是20字节，共40字节。

对于以太网来说，最小的包长度数据段必须达到46字节，而攻击报文只有40字节，因此，网卡在发送时，会做一些处理，在TCP首部的末尾，填充6个0来满足最小包的长度要求。这个时候，整个数据包的长度为14字节的以太网头，20字节的IP头，20字节的TCP头，再加上因为最小包长度要求而填充的6个字节的0，一共是60字节。

但这还没有结束。以太网在传输数据时，还有CRC检验的要求。网卡会在发送数据之前对数据包进行CRC检验，将4字节的CRC值附加到包头的最后面。这个时候，数据包长度已不再是40字节，而是变成64字节了，这就是常说的SYN小包攻击，数据包结构如下：

|14字节以太网头部|20字节IP头部|20字节TCP|6字节填充|4字节检验|

|目的MAC|源MAC|协议类型| IP头 |TCP头|以太网填充 | CRC检验 |

到64字节时，SYN数据包已经填充完成，准备开始传输了。攻击数据包很小，远远不够最大传输单元（MTU）的1500字节，因此不会被分片。那么这些数据包就像生产流水线上的罐头一样，一个包连着一个包紧密地挤在一起传输吗？事实上不是这样的。

以太网在传输时，还有前导码（preamble）和帧间距（inter-frame gap）。其中前导码占8字节（byte），即64比特位。前导码前面的7字节都是10101010，1和0间隔而成。但第八个字节就变成了10101011，当主机监测到连续的两个1时，就知道后面开始是数据了。在网络传输时，数据的结构如下：

|8字节前导码|6字节目的MAC地址|6字节源MAC地址|2字节上层协议类型|20字节IP头|20字节TCP头|6字节以太网填充|4字节CRC检验|12字节帧间距|

也就是说，一个本来只有40字节的SYN包，在网络上传输时占的带宽，其实是84字节。

有了上面的基础，现在可以开始计算攻击流量和网络设备的线速问题了。当只填充IP头和TCP头的最小SYN包跑在以太网络上时，100Mbit的网络，能支持的最大PPS（Packet Per Second）是100×106 / (8 (64+8+12)) = 148809，1000Mbit的网络，能支持的最大PPS是1488090。

为了保证游戏质量有一定的保证才限制在游戏里的人数具体多少人需要排队不知道。是在游戏服务器接近饱和时新区都会排队的。人多，呵呵
出现服务器繁忙，请稍后重试的 好象跟以前挤新区排队的性质差不多，是网易网络繁忙造成的，多试几次就好了。
排队系统学WOW的，是为了叫大家在挤不进去的时候有个先后顺序进游戏吧。以前新区有时候秒进，多数时候都提示：服务器繁忙，请稍后重试，对吧。
网易又不想花钱买更大的服务器来满足更多的玩家一起在线，又想让所有的人都能进去游戏，就有了排队的事，挤个半小时进不去我是不挤了，就玩别的了
根据你的补充，现在应该是秀月峰比2008在线的人多导致的

确定Web服务器正在或者曾经遭受CC攻击，那如何进行有效的防范呢壹基比小喻依据个人经验，提供如下防御措施。
(1)取消域名绑定
一般cc攻击都是针对网站的域名进行攻击，比如网站域名是，那么攻击者就在攻击工具中设定攻击对象为该域名然后实施攻击。
对于这样的攻击我们的措施是在IIS上取消这个域名的绑定，让CC攻击失去目标。具体 *** 作步骤是：打开“IIS管理器”定位到具体站点右键“属性”打开该站点的属性面板，点击IP地址右侧的“高级”按钮，选择该域名项进行编辑，将“主机头值”删除或者改为其它的值(域名)。
笔者实例模拟测试，取消域名绑定后Web服务器的CPU马上恢复正常状态，通过IP进行访问连接一切正常。但是不足之处也很明显，取消或者更改域名对于别人的访问带来了不变，另外，对于针对IP的CC攻击它是无效的，就算更换域名攻击者发现之后，他也会对新域名实施攻击。
(2)域名欺骗解析
如果发现针对域名的CC攻击，我们可以把被攻击的域名解析到这个地址上。我们知道是本地回环IP是用来进行网络测试的，如果把被攻击的域名解析到这个IP上，就可以实现攻击者自己攻击自己的目的，这样他再多的肉鸡或者代理也会宕机，让其自作自受。
另外，当我们的Web服务器遭受CC攻击时把被攻击的域名解析到国家有权威的政府网站或者是网警的网站，让其网警来收拾他们。
现在一般的Web站点都是利用类似“新网”这样的服务商提供的动态域名解析服务，大家可以登录进去之后进行设置。
(3)更改Web端口
一般情况下Web服务器通过80端口对外提供服务，因此攻击者实施攻击就以默认的80端口进行攻击，所以，我们可以修改Web端口达到防CC攻击的目的。运行IIS管理器，定位到相应站点，打开站点“属性”面板，在“网站标识”下有个TCP端口默认为80，我们修改为其他的端口就可以了。
(4)IIS屏蔽IP
我们通过命令或在查看日志发现了CC攻击的源IP，就可以在IIS中设置屏蔽该IP对Web站点的访问，从而达到防范IIS攻击的目的。在相应站点的“属性”面板中，点击“目录安全性”选项卡，点击“IP地址和域名现在”下的“编辑”按钮打开设置对话框。在此窗口中我们可以设置“授权访问”也就是“白名单”，也可以设置“拒绝访问”即“黑名单”。比如我们可以将攻击者的IP添加到“拒绝访问”列表中，就屏蔽了该IP对于Web的访问。
(5)IPSec封锁
IPSec是优秀的系统防火墙，在排除其他还有别的类型的DDOS攻击时，针对CC攻击可以用设置IP策略来对付攻击。以这个IP为例子，笔者实际 *** 作对该IP的访问封锁。
第一步：“开始→管理工具”，打开“本地安全设置”，右键点击“IP安全策略，在本地机器”选择“创建IP安全策略”，然后点击“下一步”，输入策略“名称”和“描述”。然后默认一路“下一步”创建了一个名为“封CC攻击”的IPSec策略。
第二步：右键点击“IP安全策略，在本地机器”选择“管理IP筛选器表和筛选器 *** 作”，在打开的窗口中点“添加”，在“IP 筛选器列表”窗口添人同第一步的名称和描述信息。取消“使用添加向导”的勾选，然后点击“添加”。在“IP 筛选器 属性”窗口的“地址”选项下设置“源地址”为“19216816”，目标地址为“我的IP地址”，取消对“镜像”的勾选;点击“协议”选项卡，设置“协议类型”为“TCP”，设置“协议端口”为“从任意端口”到“此端口80”最后确定退出。
第三步：在“新规则 属性”窗口中点选刚才创建的“封CC攻击”规则，点击“筛选器 *** 作”选项卡下的“添加”，点选“安全措施”下的“阻止”，在“常规”选项卡下为该筛选器命名为“阻止CC攻击”然后确定退出。
第四步：点选刚才创建的“阻止CC攻击”筛选器，一路“确定”退出IP策略编辑器，可以看到在组策略窗口的中创建成功一个名为“封CC攻击”的策略，然后右键点击该策略选择“指派”。这样就实现了对该IP的封锁。

---