如何集成varnish到已有的网站架构

在我们现有的架构中通常是已经成熟稳定的架构,如何将高性能的缓存服务器部署在已有的环境上呢,同时部署容易,如何始终让用户看到的是最新的内容,即便是缓存命中的状态?

因此,我们直接解决上面两个问题!

如何将高性能的缓存服务器部署在已有的环境上呢?

通过实际使用情况,将varnish部署上线通常有两种拓扑图:

1、user---->web--->varnish--->application_server
这种情况更适合网站已经使用了cdn的情况,varnish主要充当缓存网页页面的功能。

or

2、user---->varnish--->web--->application_server
这种情况适合通常性的小网站,并没有富裕的资金,或者说为了充分的节约开支,毕竟如果效果理想,这部分的资源完全可以作为程序员薪水的部分(wan quan bu ke neng!)

对于如何安装varnish,请参考官方文档或者之前的blog。两种方式无外乎在于如何调度网站流量,以及配置源server而已。

如何始终让用户看到的是最新的内容,即便是缓存命中的状态?

有了上面的两种结构,我们来说如何更新缓存的问题,这也是基本所有问题的所在。

举个实际例子,通常作为一个cms站点,都会有访问域名(www)和管理域名(console),这里我们简称前台(客服妹子)和后台(diaosi chengxuyuan),并且使用上面的第二种架构。 那么我们的架构就是这样的:

前台用户通过internet访问您的网站,首先经过varnish的处理,如果cache中hit,ok,返给用户,访问结束,如果miss,进行和之前没有使用varnish的访问流程。(注:此处只画出必要的部分。当然像redis缓存等其他组件这些东西包含在上面的架构也是没有任何问题的。)

后台编辑用户,通过后台发布更新,操作数据,并且更新到数据库中。

现在问题来了(wa jue ji shu na jia qiang?!):

在没有使用缓存时,用户每次都通过应用服务器获取到最新的内容。后台修改也是直接更新到数据库。

对比

使用缓存后,实际某篇文章被缓存后,并且在有效期内,用户的请求是不会到达web服务器,更别说应用服务器。这就是说即便你的编辑在后台更新了十万次该文章,如果文章仍然在缓存期内,前台用户是不会有任何变化。

解决这个问题通常有两种方式:

1、对缓存对象设置一个较小的缓存失效时间。(被动更新)
2、通过varnish的接口对已经缓存的对象进行操作。(主动更新)

可以衡量二者的优劣,

被动更新简单维护量小会存在用户得到非最新资源的情况;
主动更新效果显著维护量较被动更新更大,不过向笔者这种大神级别高端玩家(da gao wan)来说,被动更新显然是不能忍受的额。

实际例子

实际上我们通过后台管理系统可以向varnish发送更新某资源的请求即可,如下图:

具体到配置:我们的前后台web服务器均使用openresty,具体就不多介绍了,引用一句话"春哥是我见过开源精神最强的人"

首先对于我们需要修改的文章都是有对应的文章id,在后台编辑更新都会发起post请求,或者get请求。通过后台openresty在收到更新文章请求时,发送一个同步的非阻塞的子请求到前台varnish,并在varnish中配置用于接收该请求,执行varnish的ban操作。

我们来看配置文件。

后台的openresty:

server {
    listen 80;
    server_name console.example.com;

    location ~ /articles/(\d+)/[change_status|edit] {
        error_log   logs/error.log debug;

        proxy_set_header X-Real-IP $http_x_forwarded_for;
        proxy_set_header X-Forwarded-For $http_x_forwarded_for;
        proxy_set_header Host $host;
        set $article_id $1;
        rewrite_by_lua ‘
            ngx.location.capture("/console.example.com/foo/"..ngx.var.article_id, { args = { cmd = "update" } })
        ‘;
        proxy_pass http://127.0.0.1:9090;
    }

当然这只是最核心能说明问题的代码,不了解的可以查阅ngx.location.capture ,通过在该location中加入rewritebylua,具体它和proxy_pass的执行顺序是rewrite在前。笔者在实际测试中发现,nginx的第三方模块echo也提供发起了子请求的功能,但实际始终在proxy_pass之后,并不能实现需要的功能。

前台的varnish,同样取核心部分:

    sub vcl_recv {
        if (req.method == "GET" && client.ip ~ "192.168.11.11" && req.url ~ "/console.example.com/foo/\d+"  ) {
        set req.http.purge-url = regsub(req.url,"/console.example.com/foo/(\d+).*","\1.html");
        ban("req.url ~ " + req.http.purge-url);
        set req.backend_hint = default;
        return(pass);
    }
}

这里主语clint.ip当然你可以设置为一个集群,这个参考官方文档。

acl ban {
    "localhost";
    "192.168.11.168";
}

这样后端更新时会通知varnish更新相关的资源,主动更新功能实现。 由于设置了return(pass),在前端的web中最好配置一段location来匹配该请求,可以简单的return 200即可。

前端web:

server{
    ...
    location = /console.example.com/foo/\d+ {
        return 200;
    }
}

对于有需要更新图片等静态资源的情况。可以编写一个通用的ban或者purge接口。具体可参考官方文章。

后续

配置文件基于varnish4,建议需要上生成环境的,多阅读官方文档。当然也可以瞅瞅我的部分博客,总之,多测试!!word is cheap ,show me your code。

时间: 2024-10-21 08:59:47

如何集成varnish到已有的网站架构的相关文章

大型网站架构演变

1.简介 大型网站架构的演进最开始都是由小及大慢慢演变过来的,任何一个好的架构都不是设计出来了,是经过业务发展迭代而来的,这个观点我是赞同的.对于网站架构技术非常有兴趣,一直持续关注学习架构技术,本次想通过大型网站技术发展历程,剖析大型网站技术架构模式,深入分析大型互联网架构设计.这篇文章我们只关注架构的演变历程.通过电商业务为例,该系统的功能有用户模块[用户注册和管理].商品模块[商品展示和管理].交易模块[创建交易和管理].通过图例分析一个最初从单台LAMP怎么发展到庞大的分布架构体系. 线

大型网站架构系列:消息队列(二)

本文是大型网站架构系列:消息队列(二),主要分享JMS消息服务,常用消息中间件(Active MQ,Rabbit MQ,Zero MQ,Kafka).[第二篇的内容大部分为网络资源的整理和汇总,供大家学习总结使用,最后有文章来源] 本次分享大纲 消息队列概述(见第一篇:大型网站架构系列:分布式消息队列(一)) 消息队列应用场景(见第一篇:大型网站架构系列:分布式消息队列(一)) 消息中间件示例(见第一篇:大型网站架构系列:分布式消息队列(一)) JMS消息服务 常用消息队列 参考(推荐)资料 本

中小型网站架构分析及优化

先看网站架构图: 以上网站架构广泛运用中大型网站中,本文从架构每一层分析所用主流技术和解决手段,有助于初入网站运维朋友们,进一步对网站架构认识,从而自己形成一套架构概念. 第一层:CDN 国内网络分布主要南电信北联通,造成跨地区访问延迟大问题,对于有一定访问量网站来说,增加CDN(内容分发网络)层可有效改善此现象,也是网站加速的最好选择.CDN把网站页面缓存到全国分布的节点上,用户访问时从最近的机房获取数据,这样大大减少网络访问的路径.如果想自己搭建CDN,不建议这么做,因为什么呢?其实说白了,

优酷、YouTube、Twitter及JustinTV视频网站架构设计

优酷视频网站架构 一.网站基本数据概览 据2010年统计,优酷网日均独立访问人数(uv)达到了8900万,日均访问量(pv)更是达到了17亿,优酷凭借这一数据成为google榜单中国内视频网站排名最高的厂商.     硬件方面,优酷网引进的戴尔服务器主要以 PowerEdge 1950与PowerEdge 860为主,存储阵列以戴尔MD1000为主,2007的数据表明,优酷网已有1000多台服务器遍布在全国各大省市,现在应该更多了吧. 二.网站前端框架 从一开始,优酷网就自建了一套CMS来解决前

网站架构化

转载网站架构之架构演化 网站从构建之初的很少有人问津,用户数量较少,并发量较低,到之后的拥有千万上亿用户,数万量级的高并发,之间经历了怎样的过程,小型网站架构是怎样逐步演化的,本文简单探讨下这方面的内容,主要参考<大型网站架构设计>,这本书知识点总结的还是比较全面的. 1. 初始阶段 网站开始是没有太多访问量的,只需一台服务器就绰绰有余了,应用程序,数据库,静态资源等全部都在一台服务器上,一般使用LAMP/LNMP(Linux+Apache/Nginx+MySQL+PHP/Python等)就可

网站架构转帖

http://oldboy.blog.51cto.com/2561410/736710  高并发访问的核心原则其实就一句话"把所有的用户访问请求都尽量往前推". 如果把来访用户比作来犯的"敌人",我们一定要把他们挡在800里地以外,即不能让他们的请求一下打到我们的指挥部(指挥部就是数据库及分布式存储). 如:能缓存在用户电脑本地的,就不要让他去访问CDN. 能缓存CDN服务器上的,就不要让CDN去访问源(静态服务器)了.能访问静态服务器的,就不要去访问动态服务器.以

千万级PV规模高性能高并发网站架构

防伪码:好久不见,你会不会突然的出现. 客户端:缓存(expires).deflate压缩 缓存服务器:CDN/cache缓存静态内容如:html.jpg.gif.js等 静态web服务器:Apache/nginx静态服务器提供html页面内容 php/java服务器:PHP/JAVA动态内容 数据库缓存服务器:数据库缓存memcache/redis 数据库服务器:MYSQL数据库 数据存储:NFS/HADOOP等 高并发访问的核心原则其实就一句话"把所有的用户访问请求都尽量往前推".

大型网站架构系列:消息队列(二) (转)

本文是大型网站架构系列:消息队列(二),主要分享JMS消息服务,常用消息中间件(Active MQ,Rabbit MQ,Zero MQ,Kafka).[第二篇的内容大部分为网络资源的整理和汇总,供大家学习总结使用,最后有文章来源] 本次分享大纲 消息队列概述(见第一篇:大型网站架构系列:分布式消息队列(一)) 消息队列应用场景(见第一篇:大型网站架构系列:分布式消息队列(一)) 消息中间件示例(见第一篇:大型网站架构系列:分布式消息队列(一)) JMS消息服务 常用消息队列 参考(推荐)资料 本

浅谈千万级PV/IP规模高性能高并发网站架构

高并发访问的核心原则其实就一句话“把所有的用户访问请求都尽量往前推”. 如果把来访用户比作来犯的"敌人",我们一定要把他们挡在800里地以外,即不能让他们的请求一下打到我们的指挥部(指挥部就是数据库及分布式存储). 如:能缓存在用户电脑本地的,就不要让他去访问CDN. 能缓存CDN服务器上的,就不要让CDN去访问源(静态服务器)了.能访问静态服务器的,就不要去 访问动态服务器.以此类推:能不访问数据库和存储就一定不要去访问数据库和存储. 说起来很轻松,实际做起来却不容易,但只要稍加努力