大家都看到过在支付宝架构图里面一个分布式数据分发中心（Gara系统），这个分布中心为了完成每天的数据抽取和向多个Oracle Rac集群和Greenplum集群分布数据的心脏，数据仓库系统是一切系统数据来源。其中功能是为了完成异构数据抽取和装载。

为了使Gara实现高效性和线性扩展能力，现在alipay dw是用4台高性能PC Dell R900（4*4core，128GB memory）来实现，但是Gara原来开发的程序不能实现分布式，只能通过调度系统来控制，灵活性不够强。

最近发现一个开源软件 Keepalived，能很好来实现Gara高效性和线性扩展能力，很多人用来 Keepalived网站的负载均衡，Keepalived还有一个重要的特性就是实现高可用性，就利用这个特性来实现Gara分布式管理

Keepalived可以提供IP层的高可用性, 一旦某一台机器的网络出现问题, 另一台服务器会立即(几秒或者更少的时间)使用出故障的服务器的IP进行工作。

keepalived体系架构图：

keepalived体系架构很清晰，都模块化的，跟我们目前开发的调度系统架构非常相像，大家可以去仔细研究一下

keepalived工作原理：keepalived是一个类似于IP/TCP协议栈3, 4 & 5层交换机制的软件，也就是我们说的第3层、第4层和第5层交换

1.Keepalived使用Layer3的方式工作式时，Keepalived会定期向服务器群中的服务器。也就是说发送一个ICMP的数据包（类似用的Ping程序）,如果发现某台服务的IP地址没有激活，Keepalived便报告这台服务器失效，并将它从服务器群中剔除。

2.Keepalived使用Layer4的方式工作式时，要以TCP端口的状态来决定服务器工作正常与否。如server的服务端口一般是20000，如果Keepalived检测到20000端口没有启动，则Keepalived将把这台服务器从服务器群中剔除。

3.Keepalived使用Layer5的方式工作式时，工作在具体的应用层，如何我们Gara系统故障，就将应用切换其他机器

先介绍一下绍一些流行的分布式key/value存贮系统，并做一些简单的比较。

词汇与背景阅读：

Distributed Hash Table (DHT) and algorithms such as Chord or Kadmelia

Amazon’s Dynamo Paper, and this ReadWriteWeb article about Dynamo which explains why such a system is invaluable

Amazon’s SimpleDB Service, and some commentary

Google’s BigTable paper

The Paxos Algorithm – read this page in order to appreciate that knocking up a Paxos implementation isn’t something you’d want to do whilst hungover on a Saturday morning.

现有比较流行的key/value存储系统：

以下评论来源于源码天堂

我所寻找的系统是一个低延迟，自动复制，分布式的key/value存贮系统，扩展简单，维护方便，api也非常简单，只是简单hash维护，set,get,delete等等，因而，以上列表中有5个并不能达到要求，但是他们还是值得一提的：

1、Hbase 在hadoop中有重要的应用，然而因为延迟现象严重，所以并不适合我们的需要

每次需要关闭系统时，Win2003系统总是“多此一举”，要你选择关机原因，一次两次还能忍受，可是时间长了，真是讨厌它，现在决定将它删除 掉：

1.打开开始菜单中的运行对话框，输入组策略编辑命令“gpedit.msc”，打开组策略编辑窗口；

2.在该窗口中，依次展开“计算机配置”、“管理模板” 、“系统”目录，在对应的右边子窗口中，双击“关闭事件跟踪程序”选项；

3.在随后打开的设置界面中，将“已禁用”选项选中就可以了。

调度器的实现技术中,IP负载均衡技术是效率最高的,IP虚拟服务器软件(IPVS)是在linux内核中实现的｡

LVS负载均衡模式—1.NAT模式

NAT用法本来是因为网络IP地址不足而把内部保留IP地址通过映射转换成公网地址的一种上网方式(原地址NAT)｡如果把NAT的过程稍微变化,就可以成为负载均衡的一种方式｡原理其实就是把从客户端发来的IP包的IP头目的地址在DR上换成其中一台REALSERVER的IP地址并发至此REALSERVER,而REALSERVER则在处理完成后把数据经过DR主机发回给客户端,DR在这个时候再把数据包的原IP地址改为DR接口上的IP地址即可｡期间,无论是进来的流量,还是出去的流量,都必须经过DR｡

**LVS负载均衡模式—2.IP隧道模式 ** 隧道模式则类似于VPN的方式,使用网络分层的原理,在从客户端发来的数据包的基础上,封装一个新的IP头标记(不完整的IP头,只有目的IP部)发给REALSERVER,REALSERVER收到后,先把DR发过来的数据包的头给解开,还原其数据包原样,处理后,直接返回给客户端,而不需要再经过DR｡需要注意的是,由于REALSERVER需要对DR发过来的数据包进行还原,也就是说必须支持IPTUNNEL协议｡所以,在REALSERVER的内核中,必须编译支持IPTUNNEL这个选项｡IPTUNNEL也在Net working options里面｡

LVS负载均衡模式—3.直接路由模式

直接路由模式比较特别,很难说和什么方面相似,前2种模式基本上都是工作在网络层上(三层),而直接路由模式则应该是工作在数据链路层上(二层)｡其原理为,DR和REALSERVER都使用同一个IP对外服务｡但只有DR对ARP请求进行响应,所有REALSERVER对本身这个IP的ARP请求保持静默｡也就是说,网关会把对这个服务IP的请求全部定向给DR,而DR收到数据包后根据调度算法,找出对应的REALSERVER,把目的MAC地址改为REALSERVER的MAC并发给这台REALSERVER｡这时REALSERVER收到这个数据包,则等于直接从客户端收到这个数据包无异,处理后直接返回给客户端｡由于DR要对二层包头进行改换,所以DR和REALSERVER之间必须在一个广播域,也可以简单的理解为在同一台交换机上｡

**LVS负载均衡的八种调度算法 ** LVS已实现了以下八种调度算法:

LVS负载均衡算法—1.轮叫调度(Round-RobinScheduling)

调度器通过”轮叫”调度算法将外部请求按顺序轮流分配到集群中的真实服务器上,它均等地对待每一台服务器,而不管服务器上实际的连接数和系统负载｡

**LVS负载均衡算法—2.加权轮叫调度(WeightedRound-RobinScheduling) ** 调度器通过”加权轮叫”调度算法根据真实服务器的不同处理能力来调度访问请求｡这样可以保证处理能力强的服务器处理更多的访问流量｡调度器可以自动问询真实服务器的负载情况,并动态地调整其权值｡

LVS负载均衡算法—3.最小连接调度(Least-ConnectionScheduling)

调度器通过”最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上｡如果集群系统的真实服务器具有相近的系统性能,采用”最小连接”调度算法可以较好地均衡负载｡

LVS负载均衡算法—4.加权最小连接调度(WeightedLeast-ConnectionScheduling)

在集群系统中的服务器性能差异较大的情况下,调度器采用”加权最少链接”调度算法优化负载均衡性能,具有较高权值的服务器将承受较大比例的活动连接负载｡调度器可以自动问询真实服务器的负载情况,并动态地调整其权值

LVS负载均衡算法—5.基于局部性的最少链接(Locality-BasedLeastConnectionsScheduling)

基于局部性的最少链接”调度算法是针对目标IP地址的负载均衡,目前主要用于Cache集群系统｡该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器,若该服务器是可用的且没有超载,将请求发送到该服务器;若服务器不存在,或者该服务器超载且有服务器处于一半的工作负载,则用”最少链接”的原则选出一个可用的服务器,将请求发送到该服务器｡

LVS负载均衡算法—6.带复制的基于局部性最少链接(Locality-BasedLeastConnectionswithReplicationScheduling)

带复制的基于局部性最少链接”调度算法也是针对目标IP地址的负载均衡,目前主要用于Cache集群系统｡它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射,而LBLC算法维护从一个目标IP地址到一台服务器的映射｡该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组,按”最小连接”原则从服务器组中选出一台服务器,若服务器没有超载,将请求发送到该服务器,若服务器超载;则按”最小连接”原则从这个集群中选出一台服务器,将该服务器加入到服务器组中,将请求发送到该服务器｡同时,当该服务器组有一段时间没有被修改,将最忙的服务器从服务器组中删除,以降低复制的程度

LVS负载均衡算法—7.目标地址散列调度(DestinationHashingScheduling)

目标地址散列”调度算法根据请求的目标IP地址,作为散列键(HashKey)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空

LVS负载均衡算法—8.源地址散列调度(SourceHashingScheduling)

源地址散列”调度算法根据请求的源IP地址,作为散列键(HashKey)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空｡

由于nginx的url hash功能可以很好的提升squid的性能，所以我把squid前端的负载均衡器更换为nginx，但是一台nginx就形成了单点，现在使用keepalived来解决这个问题，keepalived的故障转移时间很短，而且配置简单，这也是选择keepalived的一个主要原因，建议日PV值小的中小型企业web均可采用如下方案实行，下面直接上安装步骤：

一、环境：

centos5.3、nginx-0.7.51、keepalived-1.1.19

主nginx负载均衡器：192.168.0.154

辅nginx负载均衡器：192.168.9.155

vip：192.168.0.188

二、安装keepalived

#tar zxvf keepalived-1.1.19.tar.gz

#cd keepalived-1.1.19

#./configure –prefix=/usr/local/keepalived

#make

#make install

#cp /usr/local/keepalived/sbin/keepalived /usr/sbin/

#cp /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/

#cp /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/

#mkdir /etc/keepalived

#cd /etc/keepalived/

vim keepalived.conf

! Configuration File for keepalived

global_defs {

notification_email {

[email protected]

}

notification_email_from [email protected]

smtp_server 127.0.0.1

smtp_connect_timeout 30

router_id LVS_DEVEL

}

vrrp_instance VI_1 {

state MASTER

interface eth0

virtual_router_id 51

mcast_src_ip 192.168.0.154    <==主nginx的IP地址

priority 100

advert_int 1

authentication {

auth_type PASS

auth_pass chtopnet

}

virtual_ipaddress {

一**、安装coreseek**

A、安装环境配置,为安装coreseek做准备

#pkg_add -r autoconf262 automake110 libtool mysql50-client libxml2 expat

B、下载整个安装包(内含mmseg,coreseek)：

#fetch http://www.coreseek.cn/uploads/csft/3.2/coreseek-3.2.13.tar.gz

#tar xzvf coreseek-3.2.13.tar.gz

#cd coreseek-3.2.13

======================================

C 、 安装coreseek开发的mmseg，为coreseek提供中文分词功能

#cd mmseg-3.2.13

#./bootstrap

#./configure –prefix=/usr/local/mmseg3

#make

#make install

至此,mmseg已经安装完成,下面进入csft-3.2.13目录里进行安装coreseek

======================================

D、安装coreseek

#cd ../ #cd csft-3.2.13 #./configure –prefix=/usr/local/coreseek –without-python –without-mysql –with-mmseg –with-mmseg-includes=/usr/local/mmseg3/include/mmseg/ –with-mmseg-libs=/usr/local/mmseg3/lib/ #make #make install

配置测试，测试是否可以正确运行

#/usr/local/coreseek/bin/indexer -c /usr/local/coreseek/etc/sphinx-min.conf.dist

以下为正常测试时的提示信息：

Coreseek Fulltext 3.2 [ Sphinx 0.9.9-release (r2117)]

Copyright (c) 2007-2010,

开始用php写后台服务一段时间了.也是在这样的驱动下,不断的学习php语法,体验这一原来一直以为神秘且敬而远之的神奇语言的魅力.最初看php多线程的资料是为了提高程序的处理能力,充分发挥linux多任务的优势.不曾想多线程没用成反到是带来了一系列的意外收获.让之后的许多问题迎刃而解,不敢独享特一一道来. 本文所讲的东西是源自php的pcntl_fork函数.因为这个函数依赖操作系统fork的实现,所以本文所讲的东西只适用于linux/unix.ok,那么先看看这个函数的用法吧. php手册 上是这么说的:

$pid = pcntl_fork();

if ($pid == -1) {

die(‘could not fork’);

} else if ($pid) {

// we are the parent

pcntl_wait($status); //Protect against Zombie children

} else {

// we are the child

}

?>

通过pcntl_fork创建一个子进程,如果返回值是-1的话,那么说明子进程创建失败.创建成功的进程id会返回给父进程,0返回给子进程.不好理解吧,费了很常时间明白以后,笔者习惯这样写:

$pid = pcntl_fork();

if($pid == -1){

//创建失败咱就退出呗,没啥好说的

die(‘could not fork’);

}

else{

if($pid){

//从这里开始写的代码是父进程的,因为写的是系统程序,记得退出的时候给个返回值

exit(0);

}

else{

//从这里开始写的代码都是在新的进程里执行的,同样正常退出的话,最好也给一个返回值

exit(0);

}

}

?>

这样一改好理解多了,如果你父进程希望知道子进程正常退出的话,可以加上前面的pcntl_wait. 函数的用法是整明白了,在实际的工作中有什么用处呢? 1.后台程序 命令行程序好写,服务程序也好写,笔者觉得这服务程序最难写.想想原来想在windows下写个服务啥的,又是要注册服务又是要这样那样的老费劲了.现在专职管理linux想让个命令行程序在后台运行,直接在命令后面加个&就搞定了.但是这样总觉得土.有了pcntl_fork突然发现世界是那么的美好.当主进程成功创建子进程并获得子进程的id以后,自己在临死前还不忘说一句:”我已成功运行,我的id是:xxxx(子进程的id)”,完了还给系统返回个0(正常退出),哈哈,死都死的那么有尊严. 前面说的是程序常驻内存的情况,当然了这时候要注意内存的释放以及向日志文件打印信息,而不是往屏幕上(一打印信息程序就退出的哟).还有一种情况是:程序被其它脚本调用,其它脚本只关心程序是不是正常运行,如果程序要运行很长时间才能运行完的话,最好不让脚本等待.这样的话pcntl_fork又派上用场了:) 2.延时处理. 有的时候,我们程序退出的时候要清理自身产生的东西,比如说要删除自己(当然了linux下面是可以删除正在运行的文件的,只是举个例子),这个时候就可以另起动一个进程,然后自己结束了,把事情交给另一个进程来做.当我们写服务程序的时候,我们肯定是写日志文件记录程序的运行情况(要不谁知道程序是不是在那睡大觉的:0).程序正常退出的时候我们可以写一条日志说程序退出了,但是当程序收到linux下伟大的kill -9的时候,怎么记录自己的退出行为呢?额…..这个和php的进程信号有关好像和这个没多大关系. 另一种情况:一个完善的程序一般都支持start,stop,restart这样的参数.start好说,stop也好说,既然start和stop都好说了,这个restart就先stop然后再start就可以了啊.额…好像又和pcntl_fork没多大关系,当你收到重启的信号总不能还是kill然后再start吧,是不是太黄太暴力了?还是温柔一点,让当前进程退出,让另外的进程再把它拉起来吧.在windows下想实现这一点似乎很困难呢,比如程序更新的时候,一般都是单写更新程序,或者程序退出的时候另起动一个批处理启动自己:) 3.不死进程 其实就是传说中的双进程了.早些年的时候万象网管为了达到不被恶意结束的目的用的就是这招了.虽然咱不用担心程序被人恶意停止,但是也保不齐主程序因为任务太重抗不住自己先挂了(这种情况也不是不会发生).所以…… 说了这么多,只是对写程序的一些思考,对一个函数用法的延伸.我想到了这么多,你呢?

一、修改IP地址

修改对应网卡的IP地址的配置文件

[root@centos]# vi /etc/sysconfig/network-scripts/ifcfg-eth0

修改以下内容

DEVICE=eth0(描述网卡对应的设备别名，例如ifcfg-eth0的文件中它为eth0)

BOOTPROTO=static(设置网卡获得ip地址的方式，可能的选项为static，dhcp或bootp，分别对应静态指定的ip地址，通过dhcp协议获得的ip地址，通过bootp协议获得的ip地址)

BROADCAST=192.168.0.255(对应的子网广播地址)

HWADDR=00:07:E9:05:E8:B4 (对应的网卡物理地址)

IPADDR=192.168.1.2(如果设置网卡获得ip地址的方式为静态指定，此字段就指定了网卡对应的ip地址)

IPV6INIT=no

IPV6_AUTOCONF=no

NETMASK=255.255.255.0(网卡对应的网络掩码)

NETWORK=192.168.1.0(网卡对应的网络地址)

ONBOOT=yes(系统启动时是否设置此网络接口，设置为yes时，系统启动时激活此设备)

GATEWAY=192.168.1.1

如果对设置多个ip的话,请参考:

二、修改网关

修改对应网卡的网关的配置文件

[root@centos]# vi /etc/sysconfig/network

修改以下内容

NETWORKING=yes(表示系统是否使用网络，一般设置为yes。如果设为no，则不能使用网络，而且很多系统服务程序将无法启动)

HOSTNAME=centos(设置本机的主机名，这里设置的主机名要和/etc/hosts中设置的主机名对应)

GATEWAY=192.168.1.1(设置本机连接的网关的IP地址。例如，网关为10.0.0.2)

三、修改DNS

修改对应网卡的DNS的配置文件

[root@centos]# vi /etc/resolv.conf

修改以下内容

nameserver 202.101.224.68 #(域名服务器)

nameserver 202.101.224.69 #(域名服务器)

四、重新启动网络配置

[root@centos]# service network restart

或

[root@centos]# /etc/init.d/network restart

修改ip地址

即时生效:

[root@centos]# ifconfig eth0 192.168.0.2 netmask 255.255.255.0

启动生效:

修改/etc/sysconfig/network-scripts/ifcfg-eth0 修改网关default gateway

即时生效:

[root@centos]# route add default gw 192.168.0.1 dev eth0

1、先把光盘挂上

#monut /dev/cdrom /mnt/cdrom 光盘将挂载到/mnt/cdrom   现在我们来检查光盘是否挂载成功（如果没有此目录，先创建）

#ls /mnt/cdrom    有内容则表示挂载成功。

2、理解个道理

CentOS有两个yum源，它们在/etc/yum.repos.d/下面有两个文件：CentOS-Base.repo和CentOS-Media.repo。但这两个源不是同时使用的，默认使用的是采用互联网升级的CentOS-Base.repo源（这文件里都是网址，你可以自己看看），除非我们手动修改让系统使用Media源，而Media源就是指计算机本地的源，就包含我们方才挂上的本地光盘。

3、开始操作

首先，把CentOS-Base.repo文件改名，让系统找不到该文件，从而不能使用互联网的更新方式：

#mv CentOS-Base.repo CentOS-Base.repo.bak

然后，vi CentOS-Media.repo

把以下三行的后两行删除

baseurl=file:///media/CentOS/
file:///media/cdrom/
file:///media/cdrecorder/

第一行修改为挂载光盘的路径，如下：

baseurl=file:///mnt/cdrom/

然后，找到这个属性，将值改成1，这样就打开了本地源文件的使能开关。 enabled=0

改成 enabled=1

保存即可。

然后可以通过yum check-update 或者yum install * 来测试源是否成功和生效。

==========================================================

这里有一个比较偷懒的办法。

进入 /etc/yum.repo.d/ 文件夹

vi Centos-Media.repo

将文件中的 file 位置修改为dvd的位置 /media/dvd，并打开本地源，如下：

[c5-media]
name=CentOS-$releasever – Media
baseurl=file:///media/dvd/
gpgcheck=0
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

保存推出后就可以使用本地的dvd作为yum源了，当然，你要记得把光盘放进去哦

一，下载

cd /usr/local/src

wget http://downloads.zend.com/optimizer/3.3.3/ZendOptimizer-3.3.3-linux-glibc23-i386.tar.gz

tar -xzvf ZendOptimizer-3.3.3-linux-glibc23-i386.tar.gz

./ZendOptimizer-3.3.3-linux-glibc23-i386/install.sh

二，安装 1，php.ini配置文件目录是：/etc 2，注意Host5156_Vps使用的是lighttpd，而非apache。

三，配置域名目录下php.ini文件 1，/etc/php.ini是总的配置文件。还有一个具体的配置文件位于：/home/httpd/domain.com/php.ini，这个文件也要设置下。 2，把php.ini文件下的[zend]段落复制下来，再添加到/home/httpd/domain.com/php.ini文件中。

[Zend]
zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-3.3.3
zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/Optimizer_TS-3.3.3
zend_optimizer.version=3.3.3
zend_extension=/usr/local/Zend/lib/ZendExtensionManager.so
zend_extension_ts=/usr/local/Zend/lib/ZendExtensionManager_TS.so

3，重启Apache

/etc/init.d/httpd restart

在虚拟机的CENTOS装好APACHE不能用,郁闷,解决方法如下

/sbin/iptables -I INPUT -p tcp –dport 80 -j ACCEPT /sbin/iptables -I INPUT -p tcp –dport 22 -j ACCEPT

然后保存：

/etc/rc.d/init.d/iptables save

这样重启计算机后,防火墙默认已经开放了80和22端口

这里应该也可以不重启计算机：

/etc/init.d/iptables restart

防火墙的关闭，关闭其服务即可：

查看防火墙信息：

/etc/init.d/iptables status

关闭防火墙服务：

/etc/init.d/iptables stop

永久关闭？不知道怎么个永久法：

chkconfig –level 35 iptables off

手册：

用iptables -ADC 来指定链的规则，-A添加 -D删除 -C 修改

iptables – [RI] chain rule num rule-specification[option] 用iptables – RI 通过规则的顺序指定

iptables -D chain rule num[option] 删除指定规则

iptables -[LFZ] [chain][option] 用iptables -LFZ 链名 [选项]

iptables -[NX] chain 用 -NX 指定链

iptables -P chain target[options] 指定链的默认目标

iptables -E old-chain-name new-chain-name -E 旧的链名 新的链名

用新的链名取代旧的链名

说明

Iptalbes 是用来设置、维护和检查Linux内核的IP包过滤规则的。

可以定义不同的表，每个表都包含几个内部的链，也能包含用户定义的链。每个链都是一个规则列表，对对应的包进行匹配：每条规则指定应当如何处理与之相匹配的包。这被称作’target’（目标），也可以跳向同一个表内的用户定义的链。

TARGETS

防火墙的规则指定所检查包的特征，和目标。如果包不匹配，将送往该链中下一条规则检查；如果匹配,那么下一条规则由目标值确定.该目标值可以是用户定义的链名,或是某个专用值,如ACCEPT[通过], DROP[删除], QUEUE[排队], 或者 RETURN[返回]。

ACCEPT 表示让这个包通过。DROP表示将这个包丢弃。QUEUE表示把这个包传递到用户空间。RETURN表示停止这条链的匹配，到前一个链的规则重新开始。如果到达了一个内建的链(的末端)，或者遇到内建链的规则是RETURN，包的命运将由链准则指定的目标决定。

TABLES

当前有三个表（哪个表是当前表取决于内核配置选项和当前模块)。

-t table

这个选项指定命令要操作的匹配包的表。如果内核被配置为自动加载模块，这时若模块没有加载，(系统)将尝试(为该表)加载适合的模块。这些表如下：filter,这是默认的表，包含了内建的链INPUT（处理进入的包）、FORWORD（处理通过的包）和OUTPUT（处理本地生成的包）。nat,这个表被查询时表示遇到了产生新的连接的包,由三个内建的链构成：PREROUTING (修改到来的包)、OUTPUT（修改路由之前本地的包）、POSTROUTING（修改准备出去的包）。mangle 这个表用来对指定的包进行修改。它有两个内建规则：PREROUTING（修改路由之前进入的包）和OUTPUT（修改路由之前本地的包）。

OPTIONS

按住 win键+r键 跳出cmd窗口,将下面的代码粘贴到该窗口, @for /l %i in (1,1,255) do @ping -n 1 -w 40 192.168.1.%i & if errorlevel 1 (echo 192.168.1.%i»na.txt) else (echo 192.168.1.%i»act.txt) 回车,将自动探测192.168.1.X网段的ip响应情况. 现在是假设你的电脑属于192.168.1.X网段某一部. 存活的保存在 act.txt，不通的在 na.txt； 根据实际改改 -n 1 -w 40 的参数，以达到精准。 还有个高级应用: @for /l %i in (1,1,65535) do @ping -n 1 -w 40 192.168.%i & if errorlevel 1 (echo 192.168.%i»na.txt) else (echo 192.168.%i»act.txt)

上周初步接触linux下的这2个反向缓存软件，都实验了一下，貌似squid还是比较顺利的，varnish则碰到了一些问题

从varnish的文档看，性能比squid强很多，而且不是一点点，下面国外某在线媒体的12台squid换成3台varnish前后访问响应延时比较，据说有人也测试过的确如此，

[][1]

但我就不那么顺利了。先说squid，安装很顺利，网上的中文文档也很多，在这次尝试中，被缓存的网站的静态内容并不多，主要还是以PHP为主，所以反向cache的效果并不是很好，缓存命中率在60到70%之间，缓存的主要对象是图片。由于安装调试都很顺利，所以在“试玩”了一天后，直接就上线用上了，几天下来，正常。由于做反向缓存的服务器内存不大，只有1G，所以缓存大小只设置了384M，使用了shm，保证了速度，但应该是没有充分发挥出缓存的效能，后期准备增加1G的内存，把缓存扩大到1G，这样的话，缓存对象的大小还能再设置大一些，也许有些mp3之类的也可以缓存起来，这样命中率也许会更高些。

但即便缓存的命中不是很高，但对后面WEB服务器的压力确实是大大减少了，下面是web服务器上并发连接的图示，一处有个跌落，是架squid的时候，二处应该是个异常，上线3天来，WEB服务上的并发连接数明显少于以前。

[][2]

再说varnish，安装应该还是顺利的，但文档少，跑起来以后发现缓存了比不缓存还要慢很多，一开始以为测试用的Linux内核比较低（要求是freebsd或者linux2.6内核，虽然我的测试环境也满足要求，但还只是2.6的比较早的版本），但后来发现在EL4U5上也一样慢，后来又怀疑自己安装的方式不对，于是折腾了找了比较新的autoconf和automake，但还是老样子。上网查到也有人和我碰到一样的问题，但没有解决方法，毕竟是个新东东，用的人很少。看E文的文档，也没有太大的收获。

最近身体有些问题，状态很不好，我又是个破罐子破摔的，晚上索性就往里面钻了一把：在被varnish缓存的网站和IE客户端都抓包分析，看到底为什么慢。抓包分析也不是轻松的事情，但最终在我眼花缭乱的时候，发现了问题所在：如果WEB服务器返回给缓存服务器的是not modified，那varnish就抓瞎了，既不去取，也不告诉IE什么。可能是程序的问题，也可能是我的配置问题，但还没有时间去研究，日后再说。今天上午只是简单地禁用了WEB服务端上的过期设置，varnish就基本正常了。

Varnish_cache_原理篇: [http://docs.haohtml.com/download/cdn/Varnish_cache_%d4%ad%c0%ed%c6%aa.pdf 

基于LVS可伸缩Web和媒体服务的体系结构如图2.2所示：在前端是一个负载调度器，一般采用IP负载均衡技术来获得整个系统的高吞吐率；在第二层是服务器池，Web服务和媒体服务分别运行在每个结点上；第三层是数据存储，通过分布式文件系统使得每个服务器结点共享相同的数据。集群中结点间是通过高速网络相连的。

2.2：基于LVS的可伸缩Web和媒体集群

分布式文件系统提供统一的存储空间，这使得系统的维护工作比较方便，且系统运行比较高效。当所有服务器结点超载时，管理员可以很快地加入新的结点来处理请求，而无需将Web文档等复制到结点的本地硬盘上。Webmaster可以看到统一的文档存储空间，维护和更新页面比较方便，对分布式文件系统中页面的修改对所有的服务器都有效。大的媒体文件（如视频文件）分段存储在分布式文件系统的多个结点上，可以提高文件系统的性能和文件服务器间的负载均衡。

IP负载调度器（即VS/DR方法，将在下一章详细叙述）可以分别将Web服务和媒体服务负载均衡地分发到各个服务器上，服务器将响应数据直接返回给客户，这样可以极大地提高系统的吞吐率。

Real公司以其高压缩比的音频视频格式和音频视频播放器RealPlayer而闻名。Real公司正在使用以上结构将由20台服务器组成的LVS可伸缩Web和媒体集群，为其全球用户提供Web和音频视频服务。Real公司的高级技术主管声称LVS击败所有他们尝试的商品化负载均衡产品。

基于LVS可伸缩Web和媒体服务的体系结构如图2.2所示：在前端是一个负载调度器，一般采用IP负载均衡技术来获得整个系统的高吞吐率；在第二层是服务器池，Web服务和媒体服务分别运行在每个结点上；第三层是数据存储，通过分布式文件系统使得每个服务器结点共享相同的数据。集群中结点间是通过高速网络相连的。

图2.2：基于LVS的可伸缩Web和媒体集群分布式文件系统提供统一的存储空间，这使得系统的维护工作比较方便，且系统运行比较高效。当所有服务器结点超载时，管理员可以很快地加入新的结点来处理请求，而无需将Web文档等复制到结点的本地硬盘上。Webmaster可以看到统一的文档存储空间，维护和更新页面比较方便，对分布式文件系统中页面的修改对所有的服务器都有效。大的媒体文件（如视频文件）分段存储在分布式文件系统的多个结点上，可以提高文件系统的性能和文件服务器间的负载均衡。

IP负载调度器（即VS/DR方法，将在下一章详细叙述）可以分别将Web服务和媒体服务负载均衡地分发到各个服务器上，服务器将响应数据直接返回给客户，这样可以极大地提高系统的吞吐率。

Real公司以其高压缩比的音频视频格式和音频视频播放器RealPlayer而闻名。Real公司正在使用以上结构将由20台服务器组成的LVS可伸缩Web和媒体集群，为其全球用户提供Web和音频视频服务。Real公司的高级技术主管声称LVS击败所有他们尝试的商品化负载均衡产品。

来源： http://zh.linuxvirtualserver.org/node/16