Varnish+Nginx实现单双Web服务器缓存_服务器应用_Linux公社-Linux系统门户网站
你好，游客
Varnish+Nginx实现单双Web服务器缓存
来源：Linux社区&
作者：aolens
实验目的：
varnish利用实现对后端单双静态web服务器的缓存
varnish包的下载路径： 可以下载到varnish的rpm包
需要下载的有：
varnish-3.0.5-1.el6.x86_64
varnish-docs-3.0.5-1.el6.x86_64
varnish-libs-3.0.5-1.el6.x86_64
varnish的官网地址：
实验环境：
web1:172.16.18.3& & & & & & Nginx
web2:172.16.17.12& & & & & Nginx
varnish:172.16.18.1& & & & Varnish
实验内容：
一，安装varnish包，配置web服务器
[root@node1~]# rpm -ql varnish& &
/etc/rc.d/init.d/varnish& & & & & & & #varnish的启动程序& &
/etc/rc.d/init.d/varnishlog& & & & & #日志& &
/etc/rc.d/init.d/varnishncsa& & & & & #日志& &
/etc/sysconfig/varnish& & & & & & & & #配置文件，varnish定义自身属性& &
/etc/varnish& & & & & & & & & & & & & #配置文件目录& &
/etc/varnish/default.vcl& & & & & & & #默认配置文件，定义后端节点的& &
/usr/bin/varnish_reload_vcl& & & & & #加载vcl，& &
/usr/bin/varnishadm& & & & & & & & & #客户端程序& &
/usr/bin/varnishstat& & & & & & & & & #状态监控
二，编辑配置文件
[root@node1 ~]# vim /etc/sysconfig/varnish
NFILES=131072
MEMLOCK=82000
NPROCS="unlimited"
RELOAD_VCL=1& & & & & & & & & & & & & & & & & & & & & & & & & & & & #是否重载VCL文件
## Alternative 3, Advanced configuration
VARNISH_VCL_CONF=/etc/varnish/default.vcl& & & & & & & #vcl文件路径
VARNISH_LISTEN_PORT=80& & & & & & & & & & & & & & & & & & #varnish自己工作于那个端口。默认是6081
VARNISH_ADMIN_LISTEN_ADDRESS=127.0.0.1& & & #管理接口
VARNISH_ADMIN_LISTEN_PORT=6082& & & & & & & & & & #管理接口监听端口
VARNISH_SECRET_FILE=/etc/varnish/secret& & & & & & & & #密钥文件
VARNISH_MIN_THREADS=50& & & & & & & & & & & & & & & & & & #最少空闲线程
VARNISH_MAX_THREADS=1000& & & & & & & & & & & & & & & & #最多启动线程
VARNISH_THREAD_TIMEOUT=120& & & & & & & & & & & & & & #work超时时长
#VARNISH_STORAGE_FILE=/var/lib/varnish/varnish_storage.bin& & & & #存储文件
VARNISH_STORAGE_SIZE=64M& & & & & & & & & & & & & & & & & & & & & & & & & & #存储文件文件大小
#VARNISH_STORAGE="file,${VARNISH_STORAGE_FILE},${VARNISH_STORAGE_SIZE}"& & #存储方式file
VARNISH_STORAGE="malloc,${VARNISH_STORAGE_SIZE}"& & #基于内存方式
VARNISH_TTL=120
DAEMON_OPTS="-a ${VARNISH_LISTEN_ADDRESS}:${VARNISH_LISTEN_PORT} \
& & & & & & -f ${VARNISH_VCL_CONF} \
& & & & & & -T ${VARNISH_ADMIN_LISTEN_ADDRESS}:${VARNISH_ADMIN_LISTEN_PORT} \
& & & & & & -t ${VARNISH_TTL} \
& & & & & & -w ${VARNISH_MIN_THREADS},${VARNISH_MAX_THREADS},${VARNISH_THREAD_TIMEOUT} \
& & & & & & -u varnish -g varnish \
& & & & & & -S ${VARNISH_SECRET_FILE} \
& & & & & & -s ${VARNISH_STORAGE}"
[root@node1 ~]# vim /etc/varnish/default.vcl
backend default {
& .host = "172.16.18.3";
& .port = "80";
此时varnish就已经可以启动了。下来就是最重要的编写vcl文件。
------------------------------------------------------------
Varnish Cache 的架构笔记
5.8下Varnish-2.1.5的安装配置
脚本改用CentOS源更新安装Nginx、PHP 5.3、Varnish
利用Varnish构建Cache服务器笔记
缓存服务Varnish安装配置
Varnish 编译安装所需准备
Linux下Varnish缓存的配置优化
Varnish基础概念详解
-----------------------------------------------------------------------------------
那么我们就应该熟悉这张表，每一个状态引擎所对应的变量
简单介绍一下vcl的语法
VCL的设计参考了C和Perl语言，因此，对有着C或Perl编程经验者来说，其非常易于理解。其基本语法说明如下：
(1)//、#或/* comment */用于注释
(2)sub $name 定义函数
(3)不支持循环，有内置变量
(4)使用终止语句，没有返回值
(6)操作符：=(赋值)、==(等值比较)、~(模式匹配)、!(取反)、&&(逻辑与)、||(逻辑或)
编译vcl文件中状态引擎的顺序我们按照默认配置文件的顺序来，此顺序也符合请求处理的基本顺序，当然，为了配合实验也会有些改动。我们来看一张图，可以明确的明白请求的过程：
1，首先我们来编写vcl_recv段，
vcl_recv作为进入varnish对请求报文解码后第一个子例程，可以在此处做访问控制，是否查询缓存，以及无法识别的数据的判定。
首先对default.vcl文件复制一份重新改名为test1.vcl
acl purgers {& & & & & & & & & & & & & & & & & & & & #定义一个acl
"127.0.0.1";
"172.16.0.0"/16;
sub vcl_recv {
& & if (req.url ~ "^/test.html$") {& & & & & & #请求首部的url匹配到test.html，
& & & & & & & & return(pass);& & & & & & & & & & & #跳过缓存
& & if (req.request != "GET" &&& & & & & & #请求方法不是已知的这7中则发到pipe上去
& & & req.request != "HEAD" &&
& & & req.request != "PUT" &&
& & & req.request != "POST" &&
& & & req.request != "TRACE" &&
& & & req.request != "OPTIONS" &&
& & & req.request != "DELETE") {
& & & return (pipe);
& & if (req.request != "GET" && req.request != "HEAD") {& & & & #不是获取资源的全部跳过缓存，减少无用缓存查询
& & & return (pass);
& & if (req.request == "PURGE") {& & & & & & &
& & & & if (!client.ip ~ purgers) {& & & & & & & & & & & & & & & & & & & & & & & & & #请求IP不在ACL中定义，则发挥405错误页。
& & & & & & error 405 "Method not allowed";
& & & & & }
& & & & return (lookup);
& & return (lookup);
那么此时如何加载这个test1让他生效呢？
第一修改配置文件。
第二，利用varnishadm客户端工具。
varnishadm
[root@node1 ~]# varnishadm -S /etc/varnish/secret -T 127.0.0.1:6082& & & & #进入到管理工具& & 200& & & -----------------------------& & Varnish Cache CLI 1.0& & -----------------------------& & Linux,2.6.32-431.el6.x86_64,x86_64,-sfile,-smalloc,-hcritbit& & varnish-3.0.5 revision 1a89b1f& & Type 'help' for command list.& & Type 'quit' to close CLI session.& & varnish& vcl.load test1 test1.vcl& & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & #加载vcl文件
VCL compiled.
varnish& vcl.list
active 2 boot
available 0 test1
varnish& vcl.use test1
varnish& vcl.list
available 2 boot
active 0 test1
这样就设定成功了。
为了显示效果我们来配置一下deliver段，给客户端返回时候匹配到缓存信息，以便我我们来查看实验结果。
sub vcl_deliver {
& & & & if (obj.hits & 0) {& & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & #判断条件缓存匹配次数大于0
& & & & & & & & set resp.http.X-Cache = "HIT via" + " " + server.& & #添加HIT via
& & & & } else {
& & & & & & & & set resp.http.X-Cache = "MISS via" + " " + server.& #没有匹配到则添加MISS via
访问缓存172.16.18.1.第一次是miss via 之后的访问在缓存有效期内都是HIT via
当访问test.html是会被vcl_recv定义的pass匹配到，直接跳过缓存，所以X-cache状态一直是MISS via
2，编辑vcl_hash，自定义hash生成时的数据来源。
sub vcl_hash {
& hash_data(req.url);& & & & & & & & & #依据req.url来匹配
if (req.http.host) {
& hash_data(req.http.host);& & & & & #请求首部的host来缓存
& } else {
& hash_data(server.ip);
& return (hash);
更多详情见请继续阅读下一页的精彩内容：
相关资讯 & & &
& (10/11/:44)
& (07/07/:44)
& (昨 20:12)
& (08/18/:54)
& (05/31/:20)
图片资讯 & & &
　　　同意评论声明
　　　发表
尊重网上道德，遵守中华人民共和国的各项有关法律法规
承担一切因您的行为而直接或间接导致的民事或刑事法律责任
本站管理人员有权保留或删除其管辖留言中的任意内容
本站有权在网站内转载或引用您的评论
参与本评论即表明您已经阅读并接受上述条款欢迎光临！请记住我的域名：
Posts - 37,
Articles - 3,
Comments - 11
记录和总结web开发技术的点点滴滴...
06:53 by wish123, ... 阅读,
作为拥有世界上最多的互联网用户群体国家,尤其是移动互联网的大热，做到一个百万级的应用几乎是分分钟的事情。相应对技术的压力，和要求也是非常高的。
要应付这种大并发需要高性能系统的开发，先从常用的MySQL数据库碰到的性能瓶颈，来做分析。因为通常一个小项目刚开始一般都会只用mysql做为数据存储，当用户量增加的时候，就会出现数据库负载过高的问题，也就是所谓的慢查询。解决慢查询的问题一般来说，解决方案是优化SQL查询，读写分离和主从数据库，不断地切库分表。
1.SQL优化，最常见的方式是，优化联表查询，以及优化索引。这里面包括，尽量使用left join 替代 where联表；当碰到，频繁查询字段A和字段B，以及AB联合查询的情况时，对AB做联合索引，能够有效的降低索引存储空间，提升查询效率。在复杂联表的情况下，可以考虑使用 Memory中间表。
2.主从数据库和读写分离，主从分库是用来应对访问量增加，带来频繁读写导致数据库的访问和操作性能下降的问题。对数据库的操作，为了保证数据的完整性，通常涉及到锁的机制的问题。MySQL的InnoDB引擎支持行级锁，而MyIsAM只支持表锁定。这样的话，如果读写集中在一个表中的情况下，当访问量增加，就会造成明显的性能下降。因此，通过主从数据库的方式可以实现读写分离。一般来说，使用InnoDB来作为写库，使用MyISAM作为读库。这种方式是缺点当然是，数据库的维护难度增加，但是通常都会有专门的DBA这个职位来负责。而且几乎是必须的解决方案，算是基础设施了。
3.数据库分库和分表.有的时候会出现，某个表变得越来越庞大，比如存放message信息表，这样会造成读取性能的增加。这种情况下，你可以通过分表的方式来解决。将一个大表切分成若干个表。
一种简单算法是：
&&&&& 设定表的大小为M，用户访问记录的ID和表的实际ID有差异，这个时候就需要做下换算，表的id = 用户访问的id 对M 进行求余;这种算法简单实现容易，单向扩展简单，但是缺点很明显，他是按照数量进行分配,但是往往实际情况会出现，访问量会集中在某几个表，而其他表访问不大，这样这种算法实际上实际上没太大的效果。而且重新调整的话，就比较困难。
类似分表的算法，还有很多，具体可以参考百度。
4.使用存储过程.将一些操作，直接通过存储过程的方式，预先设置在MySQL，客户端只需要调用存储过程就可以操作数据。在日常实践中，经常会出现，DBA在备份和恢复数据库的时候，遗忘了存储过程的情况。其次，业务调整的过程时，要对线上的存储过程进行调整，容易出现意想不到的问题，增加运维的成本。因此很多的团队不太愿意使用存储过程.
访问压力增大之后，最容易想到的解决方案就是，使用缓存了。实际上现实中，最常用的缓存无处不在。但是缓存细细说来其实还是比较复杂。
首先分为前端缓存，和后端缓存，两种技术解决方案。
先说前端页面的缓存，又可以分为PC端页面和移动客户端的缓存技术方案。
对PC端来说，对静态资源进行缓存，包括JS，CSS，图片等资源文件的缓存。
1. 一般来说，资源文件的缓存都是通过专门的CDN缓存加速，由于国内线路不通访问速度也不同，所以有专门的服务商提供专门的静态资源加速缓存服务保证不同的线路，以及用户可以就近快速访问。
2.对动态页面进行缓存，比如网站首页，内容页等这种改动不会太大的页面或者几乎不太会改变的页面，有两种方式：1）直接生成静态html页面，需要更新时通过后台成生成新页面进行覆盖。然后可以把静态页存放到本地硬盘或者同步到CDN上。2)使用vanish服务器作为方向代理，对php生成的动态页面进行缓存，由于vanish可以使用内存作为缓存，因此访问速度更快，且对生成页面的php代码不需要做任何的修改，就可以实现静态页面缓存。所以可以很好地解决因为一直遗留下来的问题导致代码修改成本高的情况。缺点也是，提升了运维成本。
对页面上某些内容经常变化的页面，比如用户中心页，其实也可以使用Ajax的方式来处理，将页面的基本内容缓存成静态页，使用ajax动态加载服务器端的动态数据。
浏览器缓存
通过Cache-Control,以及Last-Modified等控制缓存头的设置来告诉浏览器缓存页面。这样不必每次，都从服务器端重复请求新文件，也可以防止用户频繁刷新页面。
在过去带宽有限的情况，下浏览器缓存非常的重要，但是目前来说，由于带宽的提升，服务器性能提升，相对来说，这方面的浏览器的缓存要求相对下降了。使用浏览器缓存有的时候反而使得业务变得更加复杂，因此很多情况下，不少业务干脆不用浏览器缓存。
1.代码缓存：使用的各种PHP框架，本身会生成各种代码缓存，比如使用模板的视图文件，配置文件，都会解析成相应的php代码。通过这些方式，提升框架的运行效率。
2.数据缓存：这一类缓存实际上是最为复杂的一类的，也是经常会碰到，需要根据业务进行不断地调整一类的缓存。通常，我们常见的是对原先存储在MySQL数据的数据进行缓存加速。这也是前面涉及到的数据库性能瓶颈的通常解决方案之一。一般来说，过去常用的缓存服务器是memcached，但是随着Redis的出现之后，很多的创业公司，和项目，直接绕开memecached使用Redis做为缓存服务器，而且Redis不只是缓存服务，还有更多的高级特性。这里放在专门的段落来讨论，使用NoSQL替代MySQL的话题。
使用缓存最大的问题，是出现当缓存失效之后，如何解决惊群效应带来的服务器突然压力上升问题。当某个缓存失效之后，一般的做法是，再从后端的数据库中查找新的数据然后再重建缓存，但是在这个过程中，如果这个缓存内容同时有很多并发请求，就会出现，在重建新的缓存的时间段内，大量涌向后端数据库的访问，引起慢查询，导致数据库崩溃。一般来说，我们采取的方案是，主动更新缓存内容，同时延长缓存的时间，实际失效时间会比告知客户端的约定失效时间要长一些。比如实际失效时间是30s，约定失效时间是20s，后端的worker会对缓存进行主动更新，一般会使用两个key1,key2的方式进行轮流缓存和访问，比如，客户端访问的时候，先访问key1如果key1不存在则访问key2，缓存更新时，先生成key2，然后再删除key1。反之，亦然。
&&&&&&& 再来说说所谓惊群效应，来源于一个很有意思的场景，在广场上，有一大群的鸽子，游人过来抛洒食物的时候，原本平静的广场，突然一大群鸽子都拥过来争抢游客手中的食物，当食物被吃完之后，又恢复了之前的平静。等到下一次食物到来的时候，又出现相同的情景。这种现象，我们叫做惊群效应,其实在生活中这种现象随处可见，比如：商场大促销，可以看见一大堆的人早已等候在门外，等商场开门的时候，大量的人如潮水一般涌入。还有线上的一些电商促销活动，比如淘宝双十一，各种秒杀活动等。都是常见的&惊群效应&现象。
&&&&&&& 在技术开发中，我们经常也要考虑惊群效应出现的场景。
&&&&&&& 我们最熟悉的一个业务场景就是，线上的秒杀促销活动的业务开发，在这个业务中就可以看到惊群效应的影响。我们可以假定一个业务场景，比如小米手机开放抢购。只有一万台手机，实际上参与秒杀的人，超过100万，假定时间是上午12点开始抢购，但是实际上真正的秒杀过程就是1两秒钟最多了，肯定被抢完了。
&&&&& 惊群效应会导致，大量的服务器资源浪费，在服务器访问压力图表中，看到大多数情况下服务器是处于闲置状态的，一旦压力增加之后，服务器资源迅速被消耗殆尽，甚至导致崩溃，整个系统瘫痪。
&&&&&& 高并发状态下，惊群效应是经常出现，尤其是在基于社交的移动互联网产品中，几乎是家常便饭。我们经常处理的技术解决方案是，使用队列来进行处理，这也是NoSQL数据库常被用到的地方。将用户所有的请求，写入到队列中，然后通过后端的worker对队列的请求进行处理，这是一个生产者-消费者模型的经典使用场景。当处理完获取到规定数量级的结果之后，通知请求代理服务器，关闭请求通道，并重定向到别的页面，告知用户服务已经完结。比如，秒杀的时候，前端代理服务器负责将用户的请求发送到Redis队列服务器，然后后端的worker进程，消费队列的数据，当发现，秒杀的产品数量已经被抢光之后，则通知前端代理服务器，关闭秒杀请求的通道，重定向用户到一个静态提示页面，告知用户秒杀结束。这样可以保证，不会出现库存和订单不一致的情况，出现用户多抢的情况。包括抽奖也是一样，在高并发的情况下经常出现，用户抢到超出库存设定的相同商品。
&&&&& 这里谈谈使用NoSQL在大型项目中的使用。
&&&&& 这里说说我们常用的NoSQL开源项目，Redis，MongoDB，CounchBase等等，包括甚至一些新的语言，如，Node.JS等，这些新的技术产品，很多生来就是为，移动互联网大数据服务的。过去我们很多人都认为，所谓高并发，大数据，等名词都出现在BAT等少数公司里。但是随着移动互联网时代的到来，其实很多的新兴的移动互联网创业公司，很容易的，就能出现一夜间到上千万甚至过亿的用户，比如，之前在朋友圈风靡的，疯狂猜图，神经猫，这类小应用。所以在这些新兴的移动互联网产品中，NoSQL的使用几乎是基础服务。尤其是在社交类的应用中，对Feed数据的处理，消息推送，基于社交关系链的维护，用户社交行为的统计，都使得对代码的质量，数据的优化存储，业务的架构的设计等等都会有更高的要求。
NoSQL具体业务应用场景有以下几个方面：
1）队列服务。前面所提到的秒杀，抽奖，各种道具的交易等都会用到队列服务。其次是，消息推送，粉丝关注列表，等，都会用到队列服务。消息队列开源软件有很多，类似RabbitMQ，ZeroMQ,Redis等等，但是常用的还是Redis比较多。
对Feed的处理，是队列常用到的场景。比如微博的fee的消息，通常都是采用push和pull的策略，对活跃用户，一般通过缓存算法，LRC，LRF等进行计算，系统维护一个活跃用户的缓存池。然后为每一个活跃用户，生成他所关注的对象列表的消息队列，当用户上线的时候，主动推送这些消息队列。对不常活跃的用户，只有当他登录的时候，才会从后端的数据库去查询数据，生成结果。
这种方式可以有效的提升性能，同时节约存储空间。
2）计数器和限速器。移动社交应用中，用户的点赞行为非常常见，为了保存用户的点赞数据，我们经常会用到计数器服务，用被点赞的记录id作为key，对应的结果值为点赞次数。redis的incr,incrby等命令就经常被使用到，还可以通过expire来配合使用，在指定时间里面记录用户的数据。另外为了防止用户频繁访问API接口，尤其是恶意访问服务器数据服务，导致服务器过载，可以对用户的访问进行限速。
3）Top Rank，尤其是在游戏中经常会出现排名榜，电商网站也会有对商品的购买量进行排行，或者是会员等级排名等等。redis的ZSet经常被使用到，可以把记录的id存入zeset，设置对应的score为排名的依据的值，然后使用zRank来读取用户的排名，也可以使用zRange命令来获取到前指定位数的用户排行榜信息。
4）消息订阅。redis的pub/sub服务，可以实现消息订阅的功能，通常是用在用户的消息推送中，向指定用户推送相应的消息。其次是，任务分发，将用户产生的行为或者请求，发送到后端，在后端服务器中由后台worker进行处理，这样好处是，降低前端服务器的处理请求的压力，减少用户等待时间，同时减轻带宽的压力，也大大的降低服务器带宽成本，节约资金。
5）存储session。普通的网站使用file文件的方式存储session，使用redis作为session进行用户登录存储，好处很明显，一方面是访问性能提升，另外，redis使用set来存储在线用户的uid数据，这样可以很方便的使用sCard命令统计当前在线用户数，防止用户重登录。其次是避免，分布式环境下，带来用户登录访问不一致的问题。因为用户session信息，统一存储在独立的NoSQL数据库中一般来都是，使用redis服务器，这样，除了提升性能之外，也降低了代码处理的复杂度，甚至避免了过早使用大型的SSO系统，导致开发成本增加。
6）地理信息位置。MySQL其实也有存储地理位置信息，但是不如MongoDB，CounchBase等新兴数据库功能强大。基于地理位置的社交服务，用户会带着手机客户端，不断移动位置，所以用户的位置会不断地上报到服务器，然后根据服务器实时的地理信息位置，快速计算出附近附近的人，这对服务器的访问压力要求比较高。
通过代码，和各种软件的使用，来提升性能之外，整个系统架构的设计就提上日程了，最重要也是最通用的方式，自然是，堆服务器了，换个高大上的叫法，也就是所谓的分布式，系统集成。在高大上一点，就是所谓的云服务，各种所谓的云。
1）反向代理模式。所谓反向代理模式，用户所有的请求都统一发送到反向代理服务器，而反向代理服务器本身并不处理具体的请求，他只负责将请求发送到后端，获得结果之后，再传递给用户。这样的方式，能够加快整个系统的服务器响应，即使后端某个系统的崩溃，也不影响整个服务系统的奔溃。另外，这种反向代理服务器，一般来是应用服务器，本身也是分布式的，用户访问请求是被分发到不同的服务器上，这样能够支撑更大的并发请求。后端服务器，并不需要接入到互联网中，这样就不需要占用宝贵的带宽，只需要在本地网络使用本地线路进行连接，专注各种数据的运算服务，这样能够大大的降低成本，提高系统的安全性，同时提升整个系统的性能。
2）过滤器中间件。很多的请求并非都是立即被执行，或者是都会被请求。并非所有的客户的无理要求都必须满足一样，有的餐厅就并不一定提供住宿服务一样。当用户请求，被传递到中间层中，会有各种中间件会对用户的请求进行过滤，比如秒杀或者抽奖时，用户的频繁刷新请求，会被过滤器进行过滤，合并或者拒绝用户的请求。这样真正传递到后端的请求就会减少很多，有效地降低了后端服务器的压力。
3）数据视图。用户的很多重要数据都最终存在数据库中，但是用户的每次请求，并不需要一次性访问所有的数据。比如，判定用户是否登录，只需要访问用户的是否登陆的标记。这些数据可以存在redis的key中，并不需要通过数据库去保存。再有，一些信息页的数据，由于变动不会太大，由后台编辑生成，而并非是用户生成的信息数据，往往是树状结构，每次通过数据库查询，需要大量重复的join或者多次的sql查询才能读取。一方面增加了，代码的逻辑设计和维护的成本，另外一方面，运行成本也大大提升，即使通过缓存的方式，也会有惊群效应的问题需要解决。所以不如通过主动视图的方式来解决，这一类的数据，可以通过使用后台使用mysql进行存储和编辑，而面向用户的前台数据，使用MongoDB等高性能的NoSQL的数据库存储，相当于，MongoDB作为MySQL的视图。
4）缓存策略。
对于用户产生的UGC内容，它的特点是，有的用户行为读写频繁，其次是往往出现不可预测，突然一下子并发提升。比如，用户的内容分享，转发，收藏，点赞。有的帖子，会突然出现被病毒式传播的现象，大量的用户分享，转发。可能这篇文章的访问量，就会突然增加，相应的访问压力也提升，对数据库的读取压力也增加。
然而并非所有的帖子都是热门帖子，都会被访问，往往在一个系统中，大部分的帖子都处于冷门或者无人问津的状态下，只有少部分的帖子汇出现热门的状态。
因此并非所有的内容都应该被缓存，提供统一的，缓存策略服务就显得很有必要。缓存策略服务器系统，使用不同的算法策略，维持一个缓存数据的池，并非是简单地缓存数据。使用有效地缓存策略，对低访问压力的请求直接穿透缓存使用后端访问，高访问压力使用缓存服务。
缓存策略的算法有很多种，常见的有：
Least Frequently Used（LFU）
Least Recently User（LRU）
Least Recently Used 2（LRU2）
Two Queues（2Q）
具体还可以百度查询，翻阅更多的详细介绍。
5）任务系统。将很多的耗费性能的服务，集成为一个专门的服务系统，比如，定时任务服务，图像处理，分布式文件同步等等。
以上在高并发，高访问量的应用中，一些技术问题的解决方案的汇总。缓存说明及varnish说明配置
什么是缓存,为什么要缓存在客户端和原始服务器端之间存在一个可以自己构建响应报文的服务器,这个服务器通常就是缓存服务器.为什么要缓存服务器?在互联网上传输数
什么是缓存,为什么要缓存 
    在客户端和原始端之间存在一个可以自己构建响应报文的,这个服务器通常就是缓存服务器.为什么要缓存服务器?在互联网上传输数据(这里指web浏览),数据传输通常有三个阶段:第一阶段:原始服务器到互联网;第二阶段:网络间的层层路由;第三阶段:网络到请求数据的客户端.为了提高用户体验,加速用户访问原始服务器,可以把热点数据放在缓存服务器上,缓存服务器通常放在离用户比较近的地方,如:cdn机房等,在同一个网域内客户端请求相同的数据可以直接从缓存服务器中取得,减少数据冗余,用户请求数据不用去原始服务器了,减少网络间的路由时间和服务器的压力.用户请求的数据有多少是可以从缓存服务器上取得的,取决于缓存的命中率;命中率通常又分为文档命中率和字节命中率(对于中等规模的web来说,40%左右的命中率就可以了);缓存类型又分为:私有缓存和公共缓存;用户访问互联网的过程--&检查私有缓存,有就返回数据,没有就去请求二级代理,二级代理有就返回数据,没有就请求一级代理,最后请求原始服务器;如果有多个二级代理或一级代理,并且多个二级代理可以互相查找数据(需配置)还可以向一级代理(父代理)查找数据,这个方式叫做内容路由,内容路由需要通过ICP(缓存路由协议)通信;
缓存处理的具体步骤:
    接受请求--&解析请求(代理功能)--&查询缓存--&缓存内容的新鲜程度(非必须)--&构建响应报文(缓存服务器有数据)--&发送响应记录日志
缓存内容的过期检查方式
    响应首部:文档过期机制:HTTP/1.0 Expires(过期时间: 19:00:00过期);HTTP/1.1 Cache-Control(max-age = 300s 300s过期)
    请求首部:条件式请求机制:根据时间戳:比较缓存服务器和原始服务器的数据时间戳是否一致(mtime:If-Modified-Since); 根据扩展标记:(If-None-Match):比较缓存服务器和原始服务器的数据扩展标记是否一致
    结合机制:文档过期机制+条件式请求机制
原始服务器或缓存服务器控制缓存的首部(响应首部)
    max-age 控制私有缓存的过期时间  如:max-age=3600
    s-maxage 控制公共缓存,同上
    no-store :控制位,表示不能缓存,只要后端服务器的报文首部有no-store首部,缓存服务器就不能缓存,这是遵循了缓存协议的控制规定
    no-cache:能缓存,不能直接使用此缓存对象,意思是缓存对象在使用之前必须做新鲜度验证
    must-revalidate:必须进行新鲜度验证.同上
    private : 用户的私有数据
    public: 用户的公开数据
vanish  
   varnish是一个轻量级的web的缓存服务器,他对nginx或apache做缓存,单个varnish的连接请求并发量大致在5000个左右,所以在大规模的站点中,可能还是有squie主导.在中小企业的规模中做代理缓存时,varnish比较常见,varnish不支持使用过大的内存.
    varnish主要运行两个进程：Management进程和Child进程(也叫Cache进程)。
Management进程主要实现应用新的配置、编译VCL、监控varnish、初始化varnish以及提供一个命令行接口等。Management进程会每隔几秒钟探测一下Child进程以判断其是否正常运行，如果在指定的时长内未得到Child进程的回应，Management将会重启此Child进程。
    Child进程包含多种类型的线程，常见的如：
Acceptor线程：接收新的连接请求并响应；
Worker线程：child进程会为每个会话启动一个worker线程，因此，在高并发的场景中可能会出现数百个worker线程甚至更多；
Expiry线程：从缓存中清理过期内容；
Varnish依赖“工作区(workspace)”以降低线程在申请或修改内存时出现竞争的可能性。在varnish内部有多种不同的工作区，其中最关键的当属用于管理会话数据的session工作区。
   Management功能
   Command line 提供命令行接口
   Chile process mgmt 管理子进程
   Initialisation  配置应用初始化
    Child/cache
    Command line 命令行接口
    Storage/hashing 存储hash功能
    Log/stats 日志
    Accept 接受并处理用户请求
    Backend communication 如果本地没有缓存请求的内容,就自己构建请求报文至原始服务器
    Worker threads 负责处理用户请求
    Object expiry  清楚过期缓存对象
   varnish管理接口
    CLI interface  命令行接口
    Telnet interface  telnet接口,为了安全,目前都禁用了
    Web interface  基于web界面的监控
    Log file 默认情况下varnish的日志是存在内存中的,想要存在磁盘中,需要自己配置
    vamishlog  日志格式
vamishstat 获取当前状态信息
vamishhist 历史性信息
vamishtop  监控服务状态的
vamishncsa 日志格式
    VCL complier VCL编译器
Varnish Configuration Language (VCL)是varnish配置缓存策略的工具，它是一种基于“域”(domain specific)的简单编程语言，它支持有限的算术运算和逻辑运算操作、允许使用正则表达式进行字符串匹配、允许用户使用set自定义变量、支持if判断语句，也有内置的函数和变量等。使用VCL编写的缓存策略通常保存至.vcl文件中，其需要编译成二进制的格式后才能由varnish调用。事实上，整个缓存策略就是由几个特定的子例程如vcl_recv、vcl_fetch等组成，它们分别在不同的位置(或时间)执行，如果没有事先为某个位置自定义子例程，varnish将会执行默认的定义。
你最喜欢的}