对于防火墙的选择:
  http://blog.sina.com.cn/s/blog_92dc41ea0101j5l1.html

  http://www.lupaworld.com/article-218506-1.html

2,创建索引和键的限制：

(1),在列上创建索引长度超过3072bytes会成功，但是只能使用索引的前3072bytes。并且会显示警告信息"specified key was too long,max key lenght is 3072 keys"

不支持的特征

1，在NDB创建create table时，一定要指定tablespace.

For NDB tables, beginning with MySQL Cluster NDB 6.2.5 and MySQL Cluster NDB 6.3.2, it is also possible to specify whether the column is stored on disk or in memory by using a STORAGE clause. STORAGE DISK causes the column to be stored on disk, and STORAGE MEMORY causes in-memory storage to be used. The CREATE TABLE statement used must still include a TABLESPACE clause:

mysql> CREATE TABLE t1 (
    ->     c1 INT STORAGE DISK,
    ->     c2 INT STORAGE MEMORY
    -> ) ENGINE NDB;
ERROR 1005 (HY000): Can't create table 'c.t1' (errno: 140)

mysql> CREATE TABLE t1 (
    ->     c1 INT STORAGE DISK,
    ->     c2 INT STORAGE MEMORY
    -> ) TABLESPACE ts_1 ENGINE NDB;
Query OK, 0 rows affected (1.06 sec)

//NDB参数解释  ---from 《mysql性能调优和架构设计》

1) [NDBD DEFAULT]中的配置项：
NoOfReplicas：定义在Cluster 环境中相同数据的分数，通俗一点来说就是每一份数据存放NoOfReplicas 份。如果希望能够冗余，那么至少设置为2（一般情况来说此参数值设置为2 就够了），最大只能设置为4。另外，NoOfReplicas 值得大小，实际上也就是nodegroup 大小的定义。NoOfReplicas 参数没有系统默认值，所以必须设定，而且只能设置在[NDBD DEFAULT]中，因为此数值在整个Cluster 集群中一个node group 中所有的NDBD 节点都需要一样。另外NoOfReplicas 的数目对整个Cluster 环境中NDB 节点数量有较大的影响，因为NDB 节点总数量是NoOfReplicas * 2 * node_group_num；DataDir：指定本地的pid 文件，trace 文件，日志文件以及错误日志子等存放的路径，无系统默认地址，所以必须设定；

DataMemory：设定用于存放数据和主键索引的内存段的大小。这个大小限制了能存放的数据的大小，因为ndb 存储引擎需属于内存数据库引擎，需要将所有的数据（包括索引）都load 到内存中。这个参数并不是一定需要设定的，但是默认值非常小（80M），只也就是说如果使用默认值，将只能存放很小的数据。参数设置需要带上单位，如512M，2G 等。另外，DataMemory 里面还会存放UNDO 相关的信息,所以，事务的大小和事务并发量也决定了DataMemory 的使用量，建议尽量使用小事务；

IndexMemory：设定用于存放索引（非主键）数据的内存段大小。和DataMemory类似，这个参数值的大小同样也会限制该节点能存放的数据的大小，因为索引的大小是随着数据量增长而增长的。参数设置也如DataMemory 一样需要单位。IndexMemory 默认大小为18M；实际上，一个NDB 节点能存放的数据量是会受到DataMemory 和IndexMemory 两个参数设置的约束，两者任何一个达到限制数量后，都无法再增加能存储的数据量。如果继续存入数据系统会报错“table is full”。

FileSystemPath：指定redo 日志，undo 日志，数据文件以及meta 数据等的存放位置，默认位置为DataDir 的设置，并且在ndbd 初始化的时候，参数所设定的文件夹必须存在。在第一次启动的时候，ndbd 进程会在所设定的文件夹下建立一个子文件夹叫ndb_id_fs，这里的id 为节点的ID 值，如节点id 为3 则文件夹名称为ndb_3_fs。当然，这个参数也不一定非得设置在[NDBD DEFAULT]参数组里面让所有节点的设置都一样（不过建议这样设置），还可以设置在[NDBD]参数组下为每一个节点单独设置自己的FileSystemPath值；

BackupDataDir：设置备份目录路径，默认为FileSystemPath/BACKUP。接下来的几个参数也是非常重要的，主要都是与并行事务数和其他一些并行限制有关的参数设置。
MaxNoOfConcurrentTransactions：设置在一个节点上面的最大并行事务数目，默认为4096，一般情况下来说是足够了的。这个参数值所有节点必须设置一样，所以一般都是设置在[NDBD DEFAULT]参数组下面；

MaxNoOfConcurrentOperations：设置同时能够被更新（或者锁定）的记录数量。一般来说可以设置为在整个集群中相同时间内可能被更新（或者锁定）的总记录数，除以NDB节点数，所得到的值。

MaxNoOfLocalOperations：此参数默认是MaxNoOfConcurrentOperations * 1.1的大小，也就是说，每个节点一般可以处理超过平均值的10%的操作记录数量。但是一般来说，MySQL 建议单独设置此参数而不要使用默认值，并且将此参数设置得更较大一些；

以下的三个参数主要是在一个事务中执行一条query 的时候临时用到存储（或者内存）的情况下所使用到的，所使用的存储信息会在事务结束（commit 或者rollback）的时候释放资源；

MaxNoOfConcurrentIndexOperations：这个参数和MaxNoOfConcurrentOperations参数比较类似，只不过所针对的是Index 的record 而已。其默认值为8192，对伊一般的系统来说都已经足够了，只有在事务并发非常非常大的系统上才有需要增加这个参数的设置。当然，此参数越大，系统运行时候为此而消耗的内存也会越大；

MaxNoOfFiredTriggers：触发唯一索引（hash index）操作的最大的操作数，这个操作数是影响索引的操作条目数，而不是操作的次数。系统默认值为4000，一般系统来说够用了。当然，如果系统并发事务非常高，而且涉及到索引的操作也非常多，自然也就需要提高这个参数值的设置了；

TransactionBufferMemory：这个buffer 值得设置主要是指定用于跟踪索引操作而使用的。主要是用来存储索引操作中涉及到的索引key 值和column 的实际信息。这这个参数的值一般来说也很少需要调整，因为实际系统中需要的这部分buffer 量非常小，虽然默认值只是1M，但是对于一般应用也已经足够了；

下面要介绍到的参数主要是在系统处理中做table scan 或者range scan 的时候使用的一些buffer 的相关设置，设置的恰当可以既节省内存又达到足够的性能要求。

MaxNoOfConcurrentScans：这个参数主要控制在Cluster 环境中并发的table scan和range scan 的总数量平均分配到每一个节点后的平均值。一般来说，每一个scan 都是通过并行的扫描所有的partition 来完成的，每一个partition 的扫描都会在该partition所在的节点上面使用一个scan record。所以，这个参数值得大小应该是“scan record”数目* 节点数目。参数默认大小为256，最大只能设置为500；


MaxNoOfLocalScans：和上面的这个参数相对应，只不过设置的是在本节点上面的并发table scan 和range scan 数量。如果在系统中有大量的并发而且一般都不使用并行的话，需要注意此参数的设置。默认为MaxNoOfConcurrentScans * node 数目；


BatchSizePerLocalScan：该参用于计算在Localscan（并发）过程中被锁住的记录数，文档上说明默认为64；

LongMessageBuffer：这个参数定义的是消息传递时候的buffer 大小，而这里的消息传递主要是内部信息传递以及节点与节点之间的信息传递。这个参数一般很少需要调整，默认大小为1MB 大小；

下面介绍一下与LOG 相关的参数配置说明，包括LOG level。这里的LOG level 有多种，从0 到15，也就是共16 种。如果设定为0，则表示不记录任何LOG。如果设置为最高level，也就是15，则表示所有的信息都会通过标准输出来记录LOG.由于这里的所有信息实际上都会传递到管理节点的cluster LOG 中，所以，一般来说，除了启动时候的LOG级别需要设置为1 之外，其他所有的LOG level 都只需要设置为0 就可以了。

NoOfFragmentLogFiles：这个参数实际上和Oracle 的redo LOG 的group 一样的。其实就是ndb 的redo LOG group 数目，这些redo LOG 用于存放ndb 引擎所做的所有需要变更数据的事情，以及各种checkpoint 信息等。默认值为8；


MaxNoOfSavedMessages：这个参数设定了可以保留的trace 文件（在节点crash的时候参数）的最大个数，文档上面说此参数默认值为25。

LogLevelStartup：设定启动ndb 节点时候需要记录的信息的级别（不同级别所记录的信息的详细程度不一样），默认级别为1；

LogLevelShutdown：设定关闭ndb 节点时候记录日志的信息的级别，默认为0；

LogLevelStatistic：这个参数是针对于统计相关的日志的，就像更新数量，插入数量，buffer 使用情况，主键数量等等统计信息。默认日志级别为0；

LogLevelCheckpoint：checkpoint 日志记录级别（包括local 和global 的），默认为0；

LogLevelNodeRestart：ndb 节点重启过程日志级别，默认为0；

LogLevelConnection：各节点之间连接相关日志记录的级别，默认0；

LogLevelError：在整个Cluster 中错误或者警告信息的日志记录级别，默认0；

LogLevelInfo：普通信息的日志记录级别，默认为0。这里再介绍几个用来作为LOG 记录时候需要用到的Buffer 相关参数，这些参数对于性能都有一定的影响。当然，如果节点运行在无盘模式下的话，则影响不大。


UndoIndexBuffer：undo index buffer 主要是用于存储主键hash 索引在变更之后产生的undo 信息的缓冲区。默认值为2M 大小，最小可以设置为1M，对于大多数应用来说，2M 的默认值是够的.当然，在更新非常频繁的应用里面，适当的调大此参数值对性能还是有一定帮助的。如果此参数太小，会报出677 错误：Index UNDO buffers overloaded；


UndoDataBuffer：和undo index buffer 类似，undo data buffer 主要是在数据发生变更的时候所需要的undo 信息的缓冲区。默认大小为16M，最小同样为1M。当这个参数值太小的时候，系统会报出如下的错误：Data UNDO buffers overloaded，错误号为891；



RedoBuffer：Redo buffer 是用redo LOG 信息的缓冲区，默认大小为8M，最小为1M。如果此buffer 太小，会报1221 错误：REDO LOG buffers overloaded.


此外，NDB 节点还有一些和metadata 以及内部控制相关的参数，但大部分参数都基本上不需要任何调整，所以就不做进一步介绍。如果有兴趣希望详细了解，可以根据MySQL官方的相关参考手册，手册上面都有较为详细的介绍。

3、SQL 节点相关配置说明
1) 和其他节点一样，先介绍一些适用于所有节点的[MySQLD DEFAULT]参数ArbitrationRank：这个参数在介绍管理节点的参数时候已经介绍过了，用于设定节点级别（主要是在多个节点在处理相关操作时候出现分歧时候设定裁定者）的。一般来说，所有的SQL 节点都应该设定为2；

ArbitrationDelay：默认为0，裁定者在开始裁定之前需要被delay 多久，单位为毫秒。一般不需要更改默认值。

BatchByteSize：在做全表扫描或者索引范围扫描的时候，每一次fatch 的数据量，默认为32KB；

BatchSize：类似BatchByteSize 参数，只不过BatchSize 所设定的是每一次fetch的record 数量，而不是物理总量，默认为64，最大为992（暂时还不知道这个值是基于什么理论而设定的）。在实际运行query 的过程中，fetch 的量受到BatchByteSize 和BatchSize两个参数的共同制约，二者取最小值；


MaxScanBatchSize：在Cluster 环境中，进行并行处理的情况下，所有节点的BatchSize 总和的最大值。默认值为256KB，最大值为16MB。

2) 每个节点独有的[MySQLD]参数组，仅有id 和hostname 参数需要配置，在之前各类节点均有介绍了，这里就不再累述。


转自http://www.cnblogs.com/alang85/archive/2011/11/18/2253900.html

• 一、循环插入数据时出现
    table is full

  二、在mgm>all report memoryusage 查看

  Node 2: Data usage is 22%(2305 32K pages of total 10240)

  使用率到最后98%以上这时出现啦table is full

  基于以上两种情况，其实是一种情况的我的解决方法是:

  根据硬件配置必须根据硬件配置修改my.cnf文件和config.ini文件

  1.config.ini
  [ndbd default]
  NoOfReplicas=2 
  MaxNoOfConcurrentOperations=10000
  DataMemory=320M
  IndexMemory=96M
  TimeBetweenWatchDogCheck=30000
  MaxNoOfOrderedIndexes=512

  2.my.cnf
  [mysqld]
  ndbcluster
  ndb-connectstring=124.95.137.12
  optimizer_switch=engine_condition_pushdown=off

  问题得以解决
  来源：http://www.greensoftcode.net/
  

什么东西可以监控OpenStack呢？OpenStack对监控的需求起码有以下这些：

• 不仅要能监控物理机，也能监控虚机
• 监控信息也必须是tenant隔离的
• 监控项的收集应该是自动地
• 监控工具应该一般化以监控任何设备
• 监控工具必须提供API

下面是监控工具的一般架构：

网上搜索了一下，现在主流的监控工具有：Nagios, cacti, Zabbix, Muni, Zenoss。我不是做运维的对这些工具都不熟，以前不熟，现在也不熟。下面是一些理解，不一定准。

Nagios，最老牌了，比较通用的监控工具。特大的特点是报警。图形化功能一般般。一般要安装Agent，配置起来看网上的说法是比较复杂的，没用过，没实际发言权。

cacti，图形化功能不错，所以Nagios一般结合它来使用。

Zabbix，监控和图形化功能都还可以了，尤其有一本电子书 zabbix 1.8 network monitoring

Zenoss, 监控新贵，它使用无Agent的通用技术如SNMP和SSL来监控，部署起来会比较方便。尤其是Zenoss公司有人现在也加入OpenStack社区了，专门开发了一个OpenStack特有的扩展（

https://github.com/zenoss/ZenPacks.zenoss.OpenStack）不幸的是，目前只支持Nova API 1.1，且它只能收集单个tenant的数据，不利于rating和billing。

OpenStack Ceilometer工程主要监控的是tenant下虚机的数据，用来做billing的，物理机的监控支持不大好。

比较来比较去，如果是我，可能会做如下选型决定，不一定正确 ：

Nagios 或者 Zenoss (视情况）

下面内容来自：http://docs.openstack.org/developer/ceilometer/， 我们看一下Ceilometer工程的现状, 架构如下：

运行OpenStack各组件的节点上一般有Agent来收集信息，收集后发给MQ，Ceilometer的Collector进程监控到数据之后存储到DB之中。从http://docs.openstack.org/developer/ceilometer/measurements.html 这页显示的监控项来看，目前Ceilometer监控来的数据主要来只是用来做billing的。

文章来源：http://blog.csdn.net/quqi99/article/details/9400747
文章作者：张华 http://blog.csdn.net/quqi99

Using HAProxy to make SSH and SSL available on the same port

Certain places firewall TCP ports other than the most common ports. There are many techniques for bypassing such restrictions. One simple approach is to run a SSH daemon on port 443, however a downside of this is you need to dedicate an IP address to this SSH service.

There is quite a neat technique for making SSH and SSL share a port; in the SSL protocol clients should write first, whereas in SSH the server should write first; therefore by waiting to see if the client writes data it is possible to make a guess as to if the client is an SSL client or a SSH client.

I'm not the first person to think this up, Net::Proxy has a script called sslh and confusingly there is also a C implementation also called sslh.

I recently switched my web server to use HAProxy to allow me some more flexiblity in how I configure things (especially now the development version has keepalive support). While reading the (incredibly detailed) documentation I noticed it should be able to do the sslh technique.

Doing this needs the (currently) in development HAProxy 1.4 (support was added for content switching TCP as well as HTTP in this commit -- thanks to Cyril Bonté on the mailing list for confirming that).

The configuration looks something like the following (global section omitted, you'll want to run it as a user other than root and chroot it if you actually use this).

defaults

  timeout connect 5s

  timeout client 50s

  timeout server 20s

listen ssl :443

  tcp-request inspect-delay 2s

  acl is_ssl req_ssl_ver 2:3.1

  tcp-request content accept if is_ssl

  use_backend ssh if !is_ssl

  server www-ssl :444

  timeout client 2h

backend ssh

  mode tcp

  server ssh :22

  timeout server 2h

This listens on port 443, forwards it to port 444 (where the actual SSL web server is listening) unless it is not SSLv2, SSLv3 or TLSv1 traffic, in which case it forwards it to the ssh backend listening on port 22.

Obviously as I said earlier this is only a guess that is subject to network conditions such as packet loss. I'm not recommending you use this technique on a production site, but for a low traffic machine where you want to run both protocols it is very useful. (By increasing the timeout for SSH you increase the chances of a correct result, but also add a potentially annoying delay).

Sometimes layer 7 filtering techniques are in use and just listening on port 443 is not enough. In this case you can use SSH inside SSL.

现在网站发展的趋势对网络负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术：

一种是通过硬件来进行进行，常见的硬件有比较昂贵的NetScaler、F5、Radware和Array等商用的负载均衡器，它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大，所以对于规模较小的网络服务来说暂时还没有需要使用；另外一种就是类似于LVS/HAProxy、Nginx的基于Linux的开源免费的负载均衡软件策略,这些都是通过软件级别来实现，所以费用非常低廉，所以我个也比较推荐大家采用第二种方案来实施自己网站的负载均衡需求。

近期朋友刘鑫(紫雨荷雪)的项目成功上线了，PV达到了亿级/日的访问量，最前端用的是HAProxy+Keepalived双机作的负载均衡器 /反向代理，整个网站非常稳定；这让我更坚定了以前跟老男孩前辈聊的关于网站架构比较合理设计的架构方案：即Nginx /HAProxy+Keepalived作Web最前端的负载均衡器，后端的MySQL数据库架构采用一主多从，读写分离的方式，采用LVS+Keepalived的方式。

在这里我也有一点要跟大家申明下：很多朋友担心软件级别的负载均衡在高并发流量冲击下的稳定情况，事实是我们通过成功上线的许多网站发现，它们的稳 定性也是非常好的，宕机的可能性微乎其微，所以我现在做的项目，基本上没考虑服务级别的高可用了。相信大家对这些软件级别的负载均衡软件都已经有了很深的 的认识，下面我就它们的特点和适用场合分别说明下。

LVS：使用集群技术和Linux操作系统实现一个高性能、高可用的服务器，它具有很好的可伸缩性（Scalability)、可靠性（Reliability)和可管理性（Manageability)，感谢章文嵩博士为我们提供如此强大实用的开源软件。

LVS的特点是：

1. 抗负载能力强、是工作在网络4层之上仅作分发之用，没有流量的产生，这个特点也决定了它在负载均衡软件里的性能最强的；
2. 配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率；
3. 工作稳定，自身有完整的双机热备方案，如LVS+Keepalived和LVS+Heartbeat，不过我们在项目实施中用得最多的还是LVS/DR+Keepalived；
4. 无流量，保证了均衡器IO的性能不会收到大流量的影响；
5. 应用范围比较广，可以对所有应用做负载均衡；
6. 软件本身不支持正则处理，不能做动静分离，这个就比较遗憾了；其实现在许多网站在这方面都有较强的需求，这个是Nginx/HAProxy+Keepalived的优势所在。
7. 如果是网站应用比较庞大的话，实施LVS/DR+Keepalived起来就比较复杂了，特别后面有Windows Server应用的机器的话，如果实施及配置还有维护过程就比较复杂了，相对而言，Nginx/HAProxy+Keepalived就简单多了。站长教学网 eduyo.com

Nginx的特点是：

1. 工作在网络的7层之上，可以针对http应用做一些分流的策略，比如针对域名、目录结构，它的正则规则比HAProxy更为强大和灵活，这也是许多朋友喜欢它的原因之一；
2. Nginx对网络的依赖非常小，理论上能ping通就就能进行负载功能，这个也是它的优势所在；
3. Nginx安装和配置比较简单，测试起来比较方便；
4. 也可以承担高的负载压力且稳定，一般能支撑超过几万次的并发量；
5. Nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测；
6. Nginx仅能支持http和Email，这样就在适用范围上面小很多，这个它的弱势；
7. Nginx不仅仅是一款优秀的负载均衡器/反向代理软件，它同时也是功能强大的Web应用服务器。LNMP现在也是非常流行的web架构，大有和以前最流行的LAMP架构分庭抗争之势，在高流量的环境中也有很好的效果。
8. Nginx现在作为Web反向加速缓存越来越成熟了，很多朋友都已在生产环境下投入生产了，而且反映效果不错，速度比传统的Squid服务器更快，有兴趣的朋友可以考虑用其作为反向代理加速器。

HAProxy的特点是：

1. HAProxy是支持虚拟主机的，以前有朋友说这个不支持虚拟主机，我这里特此更正一下。
2. 能够补充Nginx的一些缺点比如Session的保持，Cookie的引导等工作
3. 支持url检测后端的服务器出问题的检测会有很好的帮助。
4. 它跟LVS一样，本身仅仅就只是一款负载均衡软件；单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx的。
5. HAProxy可以对Mysql读进行负载均衡，对后端的MySQL节点进行检测和负载均衡，不过在后端的MySQL slaves数量超过10台时性能不如LVS，所以我向大家推荐LVS+Keepalived。
6. HAProxy的算法现在也越来越多了，具体有如下8种：
   ① roundrobin，表示简单的轮询，这个不多说，这个是负载均衡基本都具备的；
   ② static-rr，表示根据权重，建议关注；
   ③ leastconn，表示最少连接者先处理，建议关注；
   ④ source，表示根据请求源IP，这个跟Nginx的IP_hash机制类似，我们用其作为解决session问题的一种方法，建议关注；
   ⑤ ri，表示根据请求的URI；
   ⑥ rl_param，表示根据请求的URl参数'balance url_param' requires an URL parameter name；
   ⑦ hdr(name)，表示根据HTTP请求头来锁定每一次HTTP请求；
   ⑧ rdp-cookie(name)，表示根据据cookie(name)来锁定并哈希每一次TCP请求。

Nginx和LVS作对比的结果

1、Nginx工作在网络的7层，所以它可以针对http应用本身来做分流策略，比如针对域名、目录结构等，相比之下LVS并不具备这样的功能，所 以 Nginx单凭这点可利用的场合就远多于LVS了；但Nginx有用的这些功能使其可调整度要高于LVS，所以经常要去触碰触碰，由LVS的第2条优点 看，触碰多了，人为出问题的几率也就会大。
2、Nginx对网络的依赖较小，理论上只要ping得通，网页访问正常，Nginx就能连得通，Nginx同时还能区分内外网，如果是同时拥有内外网的 节点，就相当于单机拥有了备份线路；LVS就比较依赖于网络环境，目前来看服务器在同一网段内并且LVS使用direct方式分流，效果较能得到保证。另 外注意，LVS需要向托管商至少申请多一个ip来做Visual IP，貌似是不能用本身的IP来做VIP的。要做好LVS管理员，确实得跟进学习很多有关网络通信方面的知识，就不再是一个HTTP那么简单了。站长教学网 eduyo.com
3、Nginx安装和配置比较简单，测试起来也很方便，因为它基本能把错误用日志打印出来。LVS的安装和配置、测试就要花比较长的时间了，因为同上所述，LVS对网络依赖比较大，很多时候不能配置成功都是因为网络问题而不是配置问题，出了问题要解决也相应的会麻烦得多。
4、Nginx也同样能承受很高负载且稳定，但负载度和稳定度差LVS还有几个等级：Nginx处理所有流量所以受限于机器IO和配置；本身的bug也还是难以避免的；Nginx没有现成的双机热备方案，所以跑在单机上还是风险较大，单机上的事情全都很难说。
5、Nginx可以检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点。目前LVS中 ldirectd也能支持针对服务器内部的情况来监控，但LVS的原理使其不能重发请求。重发请求这点，譬如用户正在上传一个文件，而处理该上传的节点刚 好在上传过程中出现故障，Nginx会把上传切到另一台服务器重新处理，而LVS就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能 会因此而恼火。
6、Nginx对请求的异步处理可以帮助节点服务器减轻负载，假如使用apache直接对外服务，那么出现很多的窄带链接时apache服务器将会占用大 量内存而不能释放，使用多一个Nginx做apache代理的话，这些窄带链接会被Nginx挡住，apache上就不会堆积过多的请求，这样就减少了相 当多的内存占用。这点使用squid也有相同的作用，即使squid本身配置为不缓存，对apache还是有很大帮助的。LVS没有这些功能，也就无法能 比较。
7、Nginx能支持http和email（email的功能估计比较少人用），LVS所支持的应用在这点上会比Nginx更多。在使用上，一般最前端所 采取的策略应是LVS，也就是DNS的指向应为LVS均衡器，LVS的优点令它非常适合做这个任务。重要的ip地址，最好交由LVS托管，比如数据库的 ip、webservice服务器的ip等等，这些ip地址随着时间推移，使用面会越来越大，如果更换ip则故障会接踵而至。所以将这些重要ip交给 LVS托管是最为稳妥的，这样做的唯一缺点是需要的VIP数量会比较多。Nginx可作为LVS节点机器使用，一是可以利用Nginx的功能，二是可以利 用Nginx的性能。当然这一层面也可以直接使用squid，squid的功能方面就比Nginx弱不少了，性能上也有所逊色于Nginx。Nginx也 可作为中层代理使用，这一层面Nginx基本上无对手，唯一可以撼动Nginx的就只有lighttpd了，不过lighttpd目前还没有能做到 Nginx完全的功能，配置也不那么清晰易读。另外，中层代理的IP也是重要的，所以中层代理也拥有一个VIP和LVS是最完美的方案了。具体的应用还得 具体分析，如果是比较小的网站（日PV<1000万），用Nginx就完全可以了，如果机器也不少，可以用DNS轮询，LVS所耗费的机器还是比较 多的；大型网站或者重要的服务，机器不发愁的时候，要多多考虑利用LVS