高并发解决方案：方案汇总，集群概述，消息队列（一）

1、高并发解决方案汇总

一、对于被频繁调用，更新频率较低的页面，可以采用HTML静态化技术

二、图片服务器分离

三、数据库集群和库表散列

      mysql主从。m-m-s-s-s...(2个主，多个从。多个从使用负载均衡。主写入数据，从读取数据)

四、缓存。众多的缓存框架

五、负载均衡。nginx，lvs,F5

六、搜索用单独的服务器，搜索框架

七、使用MQ服务器

2.集群概述

1.什么是集群

集群是一组协同工作的服务实体，用以提供比单一服务实体更具扩展性与可用性的服务平台。在客户端看来，一个集群就象是一个服务实体，但 事实上集群由一组服务实体组成。

2.集群的特性 
与单一服务实体相比较，集群提供了以下两个关键特性： 
1.可扩展性－－集群的性能不限于单一的服务实体，新的服 务实体可以动态地加入到集群，从而增强集群的性能。 
2. 高可用性－－集群通过服务实体冗余使客户端免于轻易遇到out of service的警告。在集群中，同样的服务可以由多个服务实体提供。如果一个服务实体失败了，另一个服务实体会接管失败的服务实体。集群提供的从一个出 错的服务实体恢复到另一个服务实体的功能增强了应用的可用性。 
为了具有可扩展性和高可用性特点，集群的必须具备以下两大能力： 
（1） 负 载均衡－－负载均衡能把任务比较均衡地分布到集群环境下的计算和网络资源。 
（2） 错误恢复－－由于某种原因，执行某个任务的资源出现故障，另一服 务实体中执行同一任务的资源接着完成任务。这种由于一个实体中的资源不能工作，另一个实体中的资源透明的继续完成任务的过程叫错误恢复。 
负载均衡 和错误恢复都要求各服务实体中有执行同一任务的资源存在，而且对于同一任务的各个资源来说，执行任务所需的信息视图（信息上下文）必须是一样的。

3 集群的分类 
集群主要分成三大类：高可用集群(High Availability Cluster/HA)， 负载均衡集群(Load Balance Cluster)，高性能计算集群(High Performance Computing Cluster/HPC) 
（1） 高可用集群(High Availability Cluster/HA)：一般是指当集群中有某个节点失效的情况下，其上的任务会自动转移到其他正常的节点上。还指可以将集群中的某节点进行离线维护再上线，该过程并不影响整个集群的运行。常见的就是2个节点做 成的HA集群，有很多通俗的不科学的名称，比如"双机热备", "双机互备", "双机"，高可用集群解决的是保障用户的应用程序持续对外提供服 务的能力。 
（2） 负载均衡集群(Load Balance Cluster)：负载均衡集群运行时一般通过一个或者多个前端负载均衡器将工作负载分发到后端的一组服务器上，从而达到将工作负载分发。这样的计算机集群有时也被称为服务器群（Server Farm）。一般web服务器集群、数据库集群 和应用服务器集群都属于这种类型。这种集群可以在接到请求时，检查接受请求较少，不繁忙的服务器，并把请求转到这些服务器 上。从检查其他服务器状态这一点上 看，负载均衡和容错集群很接近，不同之处是数量上更多。 
（3） 高性能计算集群(High Performance Computing Cluster/HPC)：高性能计算集群采用将计算任务分配到集群的不同计算节点而提高计算能力，因而主要应用在科学计算领域。这类集群致力于提供单个计算机所不能提供的强大的计算能力

3、消息队列软件产品大比拼

转自：http://www.oschina.net/news/17973/message-queue-shootout

我花了一周的时间评估比较了一下各种消息队列产品，非常的有趣。我做这个事的动机是因为一个客户有一个很高性能需求。他们的消息信息突破了1百万个并发。目前他们使用的是SQL server，并不理想，我建议他们使用消息队列服务器。

为了对一些相似的候选产品获得一个全面的但是粗浅的性能上的了解，我们它们放在一起做了个测试。我让每个消息产品各发送和接受1百万千条1K的消 息。测试准备的有些仓促，我并没有修改任何的配置，只是快速的看了一下它们的安装文档，安装好每种软件，然后就让它们做这些最简单的收发信息的操作。所以 这是一次真正的“开箱即装即用”的性能表现。我完全理解，这对那些初始配置十分保守的消息队列产品将会是个惩罚。

候选产品有：

• MSMQ.
  这是微软的产品里唯一被认为有价值的东西。对我的客户来说，如果MSMQ能证明可以应对这种任务，他们将选择使用它。关键是这个东西并不复杂，除了接收和 发送，没有别的；它有一些硬性限制，比如最大消息体积是4MB。然而，通过和一些像MassTransit 或 NServiceBus这样的软件的连接，它完全可以解决这些问题。
• ActiveMQ.
  Java世界的中坚力量。它有很长的历史，而且被广泛的使用。它还是跨平台的，给那些非微软平台的产品提供了一个天然的集成接入点。然而，它只有跑过了MSMQ才有可能被考虑。
• RabbitMQ.
  我听说了很多关于这个用Erlang写成的消息中间件的优秀的特性。它支持开放的高级消息队列协议 (AMQP，Advanced Message Queuing Protocol)，从根本上避免了生产厂商的封闭，使用任何语言的各种客户都可以从中受益。这种协议提供了相当复杂的消息传输模式，所以基本上不需要 MassTransit 或 NServiceBus 的配合。它还具有“企业级”的适应性和稳定性。这些东西对我的客户来说十分的有吸引力。
• ZeroMQ.
  我在研究AMQP时从发现了这个产品。开发这个产品的公司是AMQP集团的一部分，并且还有一个叫做OpenAMQ的产品。然而，他们却戏剧性的从AMQP分离的出去，并抱怨说这这个产品迷失了方向、变的越来越复杂。你可以到这里阅 读Dear John的关于此事的文章。ZeroMQ具有一个独特的非中间件的模式，也就是说，跟其它几个接受测试的产品不同，你不需要安装和运行一个消息服务器，或 中间件。你只需要简单的引用ZeroMQ程序库，可以使用NuGet安装，然后你就可以愉快的在应用程序之间发送消息了。非常有趣的是，他们也同样使用这 方式在任何利用ZeroMQ进行强大的进程内通信的语言里创建Erlang风格的这种执行角色。

把这四个MQ产品装上、跑起来是一个很有趣的工作。当你需要安装一个非Windows平台的产品时，下一定的功夫那是必须的。ActiveMQ需要 在目标机器上安装Java，RabbitMQ需要Erlang环境。安装这两个产品都没有遇到麻烦，但我想这是否给系统的维护增加了一层任务。如果这个中 的一个被选中，我需要让系统维护的人去理解和维护他们以前不熟悉的运行库。ActiveMQ，
RabbitMQ 和 MSMQ 都需要启动服务进程，这些都可以监控和配置，另外一个就有问题了。

ZeroMQ，它没有中间件架构，不需要任何服务进程和运行时。事实上，你的应用程序端点扮演了这个服务角色。这让部署起来非常简单，但担心的是， 你没有地方可以观察它是否有问题出现。就目前我知道的，ZeroMQ仅提供非持久性的队列。你可以在需要的地方实现自己的审计和数据恢复功能。老实说，我 甚至不确信是否该把它列在此次测试中，它的运行原理和其它几种差别太大了。

我就不瞎扯了，下面是测试结果。显示的是发送和接受的每秒钟的消息数。整个过程共产生1百万条1K的消息。测试的执行是在一个Windows Vista上进行的。

就像你看到的，ZeroMQ和其它的不是一个级别。它的性能惊人的高。公平的说，ZeroMQ跟其它几个比起来像头巨兽，尽管这样，结论很清楚：如果你希望一个应用程序发送消息越快越好，你选择ZeroMQ。当你不太在意偶然会丢失某些消息的情况下更有价值。

老实讲，我更希望使用Rabbit。但这种事情是应该做更多的测试，你最终会有一个最爱，我所听到的、读到的各种关于Rabbit的事情让我觉得它应该是最佳选择。但使用这个测试结果，我很难说服他们不去使用MSMQ。

如果你想自己跑一下这些测试，我的测试代码都放在了GitHub上。我很感兴趣(但不是非常非常感兴趣)想知道如何优化这些测试，所以，如果你能做到一个更好的测试结果，请告诉我。谢谢。