varnish和squid相比最大的优势就是简单快速，简单是安装和配置都简单，快速是运行速度比squid更快，当然，快的前提是varnish比squid占用更多的内存，估计当年设计squid的时候内存还是很贵的东西，所以更多的侧重硬盘，使用内存多，当然还有一个很显而易见的弱点是机器冷启动时候恢复缓存的时间相比squid要长。
wget http://downloads.sourceforge.net/project/varnish/varnish/2.0.6/varnish-2.0.6.tar.gz?use_mirror=ncu
tar zxvf varnish-2.0.6.tar.gz
cd varnish-2.0.6
./configure –prefix=/srv/varnish
make
make install
启动命令：
/srv/varnish/sbin/varnishd -a :8088 -b localhost:8080
由于我指定了安装目录，所以加上了路径,-a参数表示varnish的监听端口，正常情况下应该监听是80端口，也就是web服务端口，我测试机上被使用掉了，所以用了8088端口， -b 是表示后端（backend）的地址，如果backend在这里指定，那么只能指定一个后端，如果使用的配置文件可以指定多个backend，我的配置文件位置位于/srv/varnish/etc/varnish。
在web服务器的目录中创建一个index.html文件，然后通过varnish进行代理访问.
第一次访问结果如下：
第二次访问结果如下：
根据请求头，我们看到的确是通过vanish来代理访问后端的，第一次访问age 为0 ，第二次访问age为71，说明这个文件已经在varnish中缓存了，此时可以通过/srv/varnish/bin/varnishstat 来查看一些参数，其中Hitrate 一行应该为1，因为命中了一次。
varnish 配置文件还是很有搞头的一个东西，有点类似与Nginx的语法，虽然不是很像，比如对正则的支持，可以绑定和去除head、Cookie等等功能，有时间的话，翻译一下varnish的introduction
error: C++ compiler cannot create executables….
安装相关开发包：
yum install gcc gcc-c++ gcc-g77 autoconf automake flex bison bzip2-devel zlib-devel ncurses-devel libjpeg-devel libpng-devel libtiff-devel freetype-devel pam-devel
Debian：
apt-get install gcc g++ build-essential
VPS为了保证效率和最小化安装，很多东西都没有所以出现上面的错误，有个偷懒的方法就是：
yum groupinstall ‘Development Tools’
这样和我们本地安装时勾选development tools的效果是一样的，什么编辑器啊，make，automake之类的都有了。
configure: error: *** libmcrypt was not found
安装libmcypt时，用默认的./configure && make && make install后，在下一步安装mcrypt会出现上面的错误，并不是libmcypt 没有安装好，而是没有加到默认的path中，做个软连接即可：
ln -s /usr/local/bin/libmcrypt-config /usr/bin/libmcrypt-config
编译PHP带上–with-xmlpr参数时出现：configure: error: XML configuration could not [...]
Linux进程创建很特别。许多其他的操作系统都提供了产生（spawn）进程的机制，首先在新的地址空间里创建进程，读入可执行文件，最后开始执行。Linux通常采用了与众不同的实现方式，他把上述步骤分解到两个单独的函数（步骤）中去执行：fork()和exec()。
首先fork()通过拷贝当前进程创建一个子进程。子进程与父进程的区别仅仅是多了一个PPID（父进程的进程号，子进程将其设定为被拷贝进程的PID），当然PID也是不同的，不过每个进程的PID都是不同的，要不然操作系统就没法识别和调度了。
exec()函数负责读取可执行文件并将其再如地址空间开始运行。把这两个函数组合起来使用效果和其他系统使用的单一函数效果相似。
fork()是通过简单的资源拷贝来实现创建子进程，尽管子进程有那么点和父进程的区别，这种通过简单拷贝实现的进程创建是非常低效率和耗资源的，因此人们想着去怎么提高这个效率，最后采用了一种类似与程序设计中的延迟绑定的措施，也就是“写时拷贝”。所谓写时拷贝就是内核在创建进程时不复制整个进程的地址空间，而是让父进程和子进程共享同一个拷贝。只有在需要写入的时候数据才会被复制到新的地址空间中，从而是个进程拥有各自的拷贝，也就是说在此之前都是以只读方式实现共享，何种技术使地址空间上的页拷贝被推迟到实际发生写入的时候。在页根本不会被写入的情况下，就无需再复制了。
废话了这么多，实际上也就是说Linux进程的创建是通过拷贝来实现的，然后对这个拷贝方式和时间进行了优化，出现了写时拷贝这么个东西。
这个标题有点吓人，又是负载均衡又是缓存，随便哪个都能写好几本书了，这里浅谈一二，适合新手，老鸟请绕道，个人的一些浅薄观点。
很多大公司在七层上做负载均衡大多基于硬件，比如F5，假如流量真的大到不行了，或者是钱多的烧包，那么买一个这种设备肯定是不二的选择，省去多少事情啊，不用搭建环境，不用搞很多测试，只要照着说明文档或者去厂方培训几天就可以了。
七层设备出了F5还有很多，在七层上做负载均衡的软件业很多，比如大名鼎鼎的HaProxy，比如配上第三方工具的LVS，甚至因为负载均衡的重要性，很多具有前瞻性的Web服务器开始提供这样的功能，比如nginx，比如light httpd，nginx的七层负载均衡实际上还是很不完善的，当后端代理一台机器死掉后，nginx还会发送请求给这个机器，这个机器不处理，那么nginx就会一直等待超时，在超时后再将请求分配给其他的机器，在流量大时会很影响性能，造成一定程度的连接堆积甚至堵塞，nginx的负载均衡算法也相对少很多，没有haproxy和LVS多，当然后者是专业负载均衡软件。
静态文件缓存也有很多，比如不朽的squid，比如最近两年很火的varnish，甚至号称比squid更快速更精准的nginx的模块ncache,varnish使用的Visual Page Cache技术能够显著降低内存和磁盘的交换次数，使系统利用率更高，我没有在百万级以上环境检测过varnish，很多人说varnish不是足够的稳定，我测试的时候没有发生什么问题。
静态文件缓存一般都不止一台，我一直推崇使用七层负载均衡来设计静态缓存架构，因为可以降低重复率，降低重复率自然是提高利用率。URL HASH能够很好的解决缓存浪费的情况，比如用户头像放在一台机器上，模板中的小文件放在另外一台机器上，利用七层负载均衡就很容易让头像的请求命中头像服务器，模板请求命中模板缓存服务器，避免了三层或者四层负载均衡重复缓存导致的硬件利用率低下问题。而且服务单一，新切换的缓存机器，很容易重新缓存满。
七层负载均衡和四层负载均衡相比，最大的缺点就是没有四层的负载能力高，Haproxy据说能跑到40万并发，LVS有几百万，这些都是理论上的数据，真的跑到40万的时候，服务器网卡早就挂了
进程是操作系统最基本抽象之一。一个进程就是处于执行器的程序（目标码粗放在某种介质上）。但进程不仅仅局限于一段可执行程序代码（Unix称之为text section），通常进程还包括其他资源，如打开的文件、挂起的信号、内核内部的数据、处理器状态、地址空间及一个和多个执行线程、当然还包括用来存放全局变量的数据段等，实际上，进程就是正在执行的程序代码的活标本。
1）进程描述符及任务结构
在很多介绍Linux进程描述的文章中，有些将内核的进程存放称之为task array，在阅读linux/sched.h头文件中代码可知，实际上进程存放是以链表的形式存放的，单个数据结构是一个task_struct的结构，因此叫做task list更准确一些。task_struct相对比较大，在32位机器上，大约1.7k。Linux通过slab分配器来分配task_struct，用这个来分配的好处是能达到对象复用和cache coloring（翻译成“缓存着色”太别扭了，也很难理解），实际上就是一个预分配的过程，这样可以减少动态创建和销毁带来的系列开销。
2）进程描述存放
内核通过唯一的进程标示值来存放和标示每个进程（PID）。PID默认的最大值为32768，是int类型，可以增加到类型允许的最大值，对于普通的桌面系统或者server来说默认最大值已经足够，对于大型服务器可能需要更多的进程数，只需要修改/proc/sys/kernel/pid_max来提高上限。
3）进程状态
TASK_RUNNING，进程正在执行，用户空间的唯一状态
TASK_INTERRUPTIBLE，被阻塞，等待恢复的状态。
TASK_UNINTERUPTIBLE ，除了不因为接收到信号而唤醒之外，和上面的一个相同
TASK_ZOMBIE 僵死。
TASK_STOPPED进程停止运行，没有运行，也不能投入运行。