使用URLs时要确保一致性。浏览器基于URL来缓存资源。当URL改变后，浏览器从源服务器获该资源的新的版本。查询字符串参数的改变也被视为URL的改变。例如，"/default.aspx" 被缓存到浏览器，如果你请求了"/default.aspx?123"，浏览器将从服务器获取新的版本。对于这个新URL的响应，如果你返回的是正确的缓存报头，它仍然会被缓存。这样的话，再把查询字符串改成类似于"/default.aspx?456&，那么服务器将又返回一个新的版本。因此，当你想响应得到缓存时，就要确保你在各处使用了一致性的URL。在主页里，如果你请求了一个URL为"/welcome.gif"的文件，那么确保在其他页面里在请求该文件时也使用相同的URL。常见的一个错误是，有时会从URL中省略"www"子域。www.nowamagic.net/default.aspx与nowamagic.net/default.aspx是不同的，两者会被分别的缓存。
静态内容会被缓存得更久。静态内容可以被缓存得更久，例如一个月。& 如果你正考虑应该只缓存几天，以便当你修改文件后，用户可以很快获取到新的版本，那么你错了。如果一个文件是通过设置过期报头（expires header）来缓存的，当你更新它时，新的用户可以立即获取到最新的版本，而老的用户只能看到旧的内容直到它在浏览器端过期。因此，只要你正在使用过期报头来缓存静态文件，把值设的越大越好。 例如，你已经通过设置过期报头值为3天来缓存一个文件，一个用户将在今天获取到该文件，并且保存在缓存区里直到三天过后；另一个用户将在明天获取到该文件，并缓存起来直到明天之后的三天。如果你后天改变该文件，第一个用户将在第四天看到它，第二个用户将在第五天看到它。因此，不同的用户将看到该文件的不同版本。结果是，设置一个低值对于保证所有用户在最短时间内得到最新的版本是没有帮助的。你将不得不通过修改文件的URL来确保所有人立即获得完全相同的一个文件。 你可以使用IIS管理器来为静态文件设置过期报头，后面的内容将会介绍如何设置。
使用缓存友好的文件夹结构。把要缓存的内容存储在一个共同的文件夹内。例如，把你网站的所有图片存储在"/static"文件夹内，而不是把图片分别地存储在不同的子文件夹下。这将有助于你在整个网站范围内使用一致性的URL，因为从任何地方你都可以使用"/static/images/ somefile.gif"。稍后，我们将学到，当把静态缓存文件放在一个共同的根文件夹内后，转移到一个内容传送网络将很容易。
重用相同的图形文件。有时我们把相同的图形文件存储于几个不同的虚拟目录下，以便可以书写很短的路径。例如，你有一个indicator.gif文件在根目录，一些子目录和CSS目录里。这样做是因为你不必担心从不同地方访问的路径问题，你只需要使用文件名作为相对URL。这却对缓存没有帮助。文件的每个拷贝都分别地缓存在浏览器端。因此，你应该把工程中所有的图像文件汇集到根目录下的"static"文件夹下，除去重复的，在所有页面和CSS文件里使用相同的URL。
改变文件名来使缓存过期。当你更改一个静态文件的时候，不要仅仅只是更新文件本身，因为它已经在客户端的浏览器缓存了。你需要更改文件名，并且更新所有各处的引用，这样浏览器才会获取到新的版本。你也可以把文件名存储在数据库或者配置文件中，通过数据绑定来动态的生成URL。以这种方式，你可以在一处来改变URL，而使整个站点立即得到更新。
使用版本号来访问静态文件。如果你不想因为要保存同样的文件的不同拷贝而使静态文件夹变得混乱，你可以使用查询字符串来区分同一文件的各个版本。例如，一个GIF文件可以和一个虚拟的查询字符串组合来访问，如"/static/images/indicator.gif?v=1"。当你更改了indicator.gif，你可以覆盖掉原来的文件，然后把所有到这个文件的引用更新为"/static/images/indicator.gif?v=2"。这样你可以重复修改同一文件，然后用新的版本号来更新所有到这个文件的引用。
把可缓存的文件存储在不同的域中。把静态内容存储在不同的域中，总是不失为一个好的办法。首先浏览器可以打开另外的并发连接来下载静态文件。另一个好处是你不需要发送cookies到静态文件。如果你把静态文件和你的web应用放在同一域中，浏览器会发送你的web应用产生的所有ASP.NET cookies和所有的其他cookies。这使得请求报头不必要的变大，浪费带宽。访问静态文件时你并不需要发送这些cookies。因此，如果你把静态文件放在不同的域中，那些cookies将不会被发送。例如，把静态文件放在域，而在域运行你的网站。不同的域并意味着必须是完全不同的网站。它可能仅仅是个别名，而物理上和web应用共享同一路径。
安全套接字(SSL)不会缓存，尽量少用。任何经过SSL处理的内容都不会被缓存。因此，你需要把静态内容置于SSL之外。此外，你应该尽量将SSL应用于一些安全页面，如登录页面或者支付页面。其余的应该使用常规的HTTP而不是SSL。SSL加密请求和响应，因而增加了服务器的额外负担。加密后的内容也比原始内容要大，因而占据更多带宽。
HTTP POST请求从不被缓存。缓存只相对于HTTP GET请求。HTTP POST请求从来不被缓存。因此，任何形式的AJAX调用，如果想被缓存，需要以HTTP GET的形式调用。
生成内容长度响应报头（content-length reponse header）。当你通过web services调用或者HTTP handlers动态地提供内容时，请确保生成了Content-Length报头。浏览器通过查看响应的Content-Lenght报头会知道有多少内容要被下载，这样它会有多种优化方案来提高下载速度。如果有这个报头信息，浏览器会更有效的利用持续连接。这将避免浏览器为每个请求新开一个连接。在没有Content-Lenght报头信息的状况下，浏览器不知道要从服务器接收多少内容，因而只要它从服务器端获取到字节流，就会保持连接为打开状态直到连接关闭。因此，你失去了持续连接带来的好处，它可以极大的缩短一些小文件的下载时间，如css、javascripts、以及图片文件。
如何在IIS中配置静态内容的缓存。在IIS管理器中，网站属性对话框有个&HTTP Headers&页，在那里你可以对所有IIS处理的请求定义过期报头。在那你可以定义内容立即过期，或是几天后过期，或者在某个特定日期过期。第二个选项（Expires after）使用的是相对过期，不是绝对过期。这个非常有用，因为它对每个请求都起作用。无论谁请求了一个静态文件，IIS会基于Expire after选项天/月的数字来计算过期日期。&对于由ASP.NET来处理的动态页面，一个handler可以修改过期报头的值来覆盖IIS的默认设置。
阅读(...) 评论()web项目发布 客户端 js css文件缓存的解决办法有哪些，如何做更合理呢？
我常用的办法是：1、给修改过的js和css文件手动加?version=XX的参数2、写后端代码，给全部js,css文件统一加上时间戳参数（这样每次发布，客户端都要重新加载一遍全部的引用文件，没有修改过的也会被重新加载，影响效率）==========求教各位知乎大神有没有什么好的前端库或者用js方式，能够实现只给修改过的文件添加时间戳呢，有没有更合理的做法？requirejs seajs等类似的工具是否也存在缓存的问题？
按时间排序
用gulp插件：gulp-rev gulp-rev-collector，这里有一款工具，
你需要webpack。一步到位。推荐另一个答案
将第二种方法的时间戳参数改成文件修改时间参数
你需要的是一些自动化工具，比如 grunt, gulp, FIS。主要的步骤有三步：1. 压缩合并2. 生成映射文件 map.json：压缩合并后的文件映射到原文件3. 资源名用带hash值的文件名替换例子，FIS 生成的 map.json：{
"js/main.wap.js": {
"uri": "/js/main.wap_e5e3136.js",
"type": "js",
"pkg": "p0"
"js/main.web.js": {
"uri": "/js/main.web_cdfaac8.js",
"type": "js",
"pkg": "p1"
"library/jquery-1.11.1.min.js": {
"uri": "/library/jquery-1.11.1.min_7e57d31.js",
"type": "js",
"pkg": "p1"
"library/spin.js": {
"uri": "/library/spin_2d1cf66.js",
"type": "js",
"pkg": "p0"
"library/zepto.min.js": {
"uri": "/library/zepto.min_a52cd15.js",
"type": "js",
"pkg": "p0"
"uri": "/js/wap_77fa6ae.js",
"type": "js",
"has": ["library/zepto.min.js", "library/spin.js", "js/main.wap.js"]
"uri": "/js/web_4ad0985.js",
"type": "js",
"has": ["library/jquery-1.11.1.min.js", "js/main.web.js"]
使用FIS可以最快的搭建出你想要的模型，具体方式参考这里：grunt 使用到的插件，请看这个
的答案。另外，我的个人博客使用 grunt 来管理这个自动化的过程，可以参考我当时写的配置：gulp 使用到的插件，请看
之前看过一篇文章。留个坑。据说可以参考facebook界面的做法。
用fi s压缩时变md5戳比较吊，现在很多大牛用webpack打包，可结合试用效果极佳
为了回答这个问题，简单写了个class和例子，用的是php，我php不好，今天刚学的，哪写的不好，那你来打我吖。用法在readme里，基本原理就是，如果静态文件在本地，可以用test脚本里的md.php 生成版本号hash的json文件，如果静态文件和php程序不在一起，则读取远程的json文件，获得版本号，再在模板里输出即可。生成这种hash的工具很多，grunt和gulp插件都有不少。。还有一种方法，就是前端控制加载方法，前端来load这个version文件，再去加载js文件，道理差不多，只是把请求移动到了前端。
看看知乎的 css js 你就有思路了，比加后缀更有效的办法，是直接用新的文件名。
如果是页面文件是html静态页面，链接文件+MD5值，这个上面各路大神已经说的比较全面了。另外如果页面文件是后端语言，如php，jsp等，并这些资源我们往往不容易接触到的话，需要跟后台配合，刷新CDN的时候更新页面文件链接的MD5值。
fis，自动管理你的静态文件md5戳
自己写了个基于 node 的构建工具，打包压缩之后计算每个静态文件的 MD5 值，直接更新到文件地址上（xxx.js?abcdefgh）和 seajs 的配置文件上（我们用 seajs）
服务端维护一个针对每个静态文件的时间戳键值map，模版渲染的时候自动加时间戳，然后发布的时候更新时间戳map，目前我们的时间戳都是如此管理的
加一个随机数参数
你所谓的时间戳等于引用文件的MD5值就可以；写个小工具、小插件，每次发布前，遍历下引用的文件，修改相应链接的MD5即可；github上类似的工具一大堆，gulp、grunt的插件也不少，自己找，不推荐；
用svn，然后每次更新时触发自己写的程序，更新某文件或某数据库数据，在程序中，调用js时查出版本号填入。
已有帐号？
无法登录？
社交帐号登录续上篇《》。
Web开发基本准则-55实录-缓存策略
郑昀 创建于2013年2月
郑昀 最后更新于日
存储介质连接池
并发请求的处理
会话串号，Cache-Control头域，缓存穿透，缓存集体失效，缓存重建，缓存雪崩，缓存永不过期，缓存计数器，
二，缓存策略
& 这里的&缓存&概念不只限于服务器端的&缓存&。
2.1.防会话串号
& 如果你收到一个投诉，说访问&我的个人中心&页面时进入其他人的帐号，至少订单列表上显示的不是自己的。此时，技术支持人员可以提三个问题，第一，对页面上显示的信息是否有操作权限，如取消订单；第二，浏览器地址栏上给URL增加访问参数，如追加一个&111之类的字符串，看看页面是否还是显示别人的信息；第三，投诉者上网接入方式是什么，如铁通光纤宽带，如通过某款代理软件上网。
& 如果既无操作权限，追加URL参数后又能看到自己的帐号信息或页面提示处于未登录状态，那么说明是URL已被各级 HTTP Proxies 缓存：
& 即在服务器端收到 Request 之前，网络链路上的某一级代理已返回缓存数据。
2.1.1.简单办法，如利用Expiration Model
& 第一种：如果页面 Response 里设置了正确的 Last-modified 和 Expires 头域，那么&&已经能正常运转了，因此，头域里的 Cache-Control:private 声明就已经够了，HTTP Caches 和 User Agent 都会根据这两个字段检查缓存网页是否陈旧。
& 第二种：重要页面的URL上加时间戳参数。
& 第三种：像淘宝博文[注1]所描述的：&cookie 里增加一个值，用来记录通过关键 cookie 计算出来的签名，这个签名的算法非常简单。每次请求到服务端的时候 session 框架代码里会对此签名进行匹配，如果和服务端获取的数据签名出来的值是一致的，则认为合法，否则清空 session 信息和 cookie 信息，让用户重新登录。&
2.1.2.需要有更多背景知识的办法：利用&Cache-Control 头域控制
&&Web开发工程师都需要了解 Cache-control 头域背后的 HTTP 1.1缓存控制机制和缓存重验证机制。
& 先说处理办法是：含个人敏感信息的网页响应头里，声明&Cache-Control:must-revalidate,proxy-revalidate,no-store,private,no-cache 即可。
& 下面简单地介绍一下背景知识，详细信息请阅读&&和&，或找到 HTTP 1.1协议中文版阅读。
& HTTP1.1协议定义，Response 是可以被各种 HTTP caches 缓存的。
&&除非有 Cache-Control 控制指令的特殊约定，否则从浏览器端到源服务器（origin server）端之间链路上所存在的各种 Caching System 都完全有可能缓存一个成功的 response：
& 如果这个 cache entry 是 fresh 的，可能不会（去源服务器端）校验直接返回；也可能会做一个校验再返回。
& 一个状态码是200, 203, 206, 300, 301, 410的 response，可能会被缓存。
2.2.缓存穿透
防止访问（短期内）必然不存在的数据导致请求穿透缓存直接打到 DB。
可能是数据真的不存在，但也可能是第三方恶意构造大量不存在的 id 来冲击 DB。
多种手段结合
『存储EMPTY』思路：存储一个 EMPTY 对象到缓存对应键值，设置一个较短的过期时间。这样在缓存失效后，还能继续查询数据是否存在。
必须认真对待（不同业务不同端口的）缓存命中率（get_hits/cmd_get * 100）定期监控的结果，认真审视那些命中率低的缓存端口，找到命中率低的原因，提出优化方案。
『先行校验』思想：采用算法，将所有可能存在的数据（如所有有效商品的id）哈希到一个足够大的 bitmap 里，那么一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对底层存储系统的查询压力。（）
2.3.&半缓存&策略
& 缓存命中率低，其中一个原因是，你缓存的数据被人访问间隔长、几率低，于是在下次访问到来之前缓存早已失效。命中率低，为我们指出了优化方向。
& 如，用户在查询一个列表页时，我们可以把前6页的数据缓存起来，再往后的页码，访问频次很低，也许就不需要缓存了。（）
2.4.缓存集体失效
& 以下原因都会导致缓存集体失效，从而引发系统&抖动&甚至&雪崩&：
系统预热数据的缓存过期时间过于整齐划一；
缓存系统宕机或重启；
访问高峰期间种下了一大批缓存，过期时间非常接近。
& 处理手段：
缓存过期时间散列开：在过期时间基础上增加一个随机值，如1秒～120秒随机，将大家的过期时间尽量打散。
防范缓存节点暂不可用的缓存双写策略：
memcache双写：向 memcahce 的 Master Ring 和 Backup Ring 双写，如下图1所示：
&图1 memcache 双写 原图出自点评技术PPT
Redis备份写：向 memcache 写入的同时，写一份到备份缓存 Redis 里，键值的缓存过期时间非常大，如原键值在 memcache 过期时间5分钟，在 Redis 里则8小时过期。当 memcache 集群节点暂不可用时，Web工程就切换读取备用缓存 Redis。这种思路是保证基本可用性，所以必要时刻可以给用户返回脏数据。
对于不同的业务场景，缓存的使用策略也不同：
当系统面临缓存异常的危险时，有些系统可以采用备份方案继续支撑服务。有些系统则会优雅降级，将某些依赖缓存的功能直接去除，保证主服务的正确性。所以这两种策略的选择需要根据实际的业务场景考虑并实施。（）
2.5.分级缓存
& 有些业务场景里，应该把 DB 当成仅是一个存储而已，靠分级缓存策略来层层抵挡缓存失效，不让请求打到 DB。
由远及近分层建立缓存，越靠近前端，缓存片段越大（或存储粒度越大）。
上一层的缓存失效，可以靠下一级的缓存迅速重建。
避免系统产生抖动。
减少缓存雪崩，防止 DB 连接数暴涨、响应变慢，连累前端应用连接数持续高涨、最后宕机。
图2 缓存控制体系（图出自&&）
2.6.缓存重建
& 既然有缓存过期，自然有缓存重建。
& 热点数据的缓存重建，无论是本地缓存还是远端缓存，都有必要加锁来确保进程内同一时刻只有一个 Worker 负责重建，甚至利用保证集群环境下只有一个重建者，避免缓存雪崩时的 Race Condition。TimYang 早在2010年在《》中描述过如下风险：&在大并发的场合，当cache失效时，大量并发同时取不到cache，会同一瞬间去访问db并回设cache，可能会给系统带来潜在的超负荷风险。我们曾经在线上系统出现过类似故障。&孙立将这种场景称为 cache key mutex 问题[注7]。
图3 cache key mutex 问题的解决（图出自 /sunli/archive//cache_key_mutex.html）
&&简而言之，缓存重建时，当多个 Client 对同一个缓存数据发起请求时，会在客户端采用加锁等待的方式，对同一个 CacheKey 的重建需要获取到相应的排他锁才行，只有拿到锁的&Client&才能访问数据库重建缓存，其他的 Client&都需要等待这个拿到锁的 Client&重建好缓存后直接读缓存。这样，对同一个缓存数据，只有一次数据库重建访问。但是如果访问分散比较严重，还是会瞬间对数据库造成非常大的压力。
& 当然也可以不加（悲观）锁，那么多线程并发读写同一个 cache key 可能会带来&ABA问题&。
& 解决方法很简单：memcached 1.2.5以及更高版本提供了 gets 和 cas 命令。如果使用 gets 命令查询某个键值，memcached 会返回该键值的唯一标识 casUnique。如果覆写了这个键值并想把它写回到 memcached 中，可以通过 cas 命令把那个 casUnique 一起发送给 memcached。如果该键值存放在 memcached 中的 casUnique 与提供的一致，写操作将会成功。如果另一个进程在这期间也修改了这个键值，那么该键值存放在 memcached 中的 casUnique 将会改变，写操作就会失败。
2.7.缓存永不过期
& 因为担心缓存失效带来的系统抖动，所以有些业务场景会让缓存永不过期，数据变化时，由后端负责维护缓存数据一致性。
2.8.电商场景里的缓存计数器：秒杀和超卖
& 我们在秒杀和防超卖场景里的实现逻辑类似于淘宝这篇博客[注3]所提及的&分布式缓存计数器&，所以我就直接照搬过来了：
& & 分布式缓存的另一个应用场景是缓存计数器。
& & 对于多服务器的系统，分布式缓存提供了统一的存储和原子操作，便于集群环境下的使用。库存计数器是分布式缓存的一个典型应用场景， 对于集群中的每一台机器，库存都应该是一个统一的值，因此使用本地缓存记录库存，数据肯定是不准确的（下面会陈述例外情况）。因此，统一的存储空间是必要 的条件。
& &&由于库存数据被多台机器共享，因此，必须使用锁机制控制多个请求的并行并发问题。基于这样的机制就可以实行库存技术器的作用，防止货物超卖。最近的积分商城超值兑换就是使用的这种机制。
& &&这种机制下，需要注意操作的逻辑顺序，错误的顺序会导致意想不到的结果。积分兑换的业务流程为，用户看到要抢兑的商品，如果库存大于0，则用户可以点击抢兑操作，这时用户会获得兑换该商品的权限，从而优惠购买，这时库存商品应该减一。
& & 如果完全按照这个业务流程，我们会完成下面这三步操作：
验证库存是否大于0；
给用户打标，使其获得优惠购买资格；
获得资格后，原子减库存，记录用户购买记录。
& & 乍一看这样的逻辑是很正常的，但是考虑一下异常情况，就会发现它防不住超卖。如果库存只有一件，那么多个用户并发验证库存时，都大于0。这样并发的多个用户都会获得优惠资格，产生了超卖。
& & 正确的逻辑为：
验证库存是否大于0，小于0直接返回；
原子减库存，返回的结果如果小于0说明已经没有库存，直接返回；
如果返回的当前库存大于等于0，为用户打标，如果打标成功，记录用户购买记录；如果打标失败，回补原子库存。
& & 这样的方法，无法保证缓存中的值一定大于等于0，因为并发的发生会把缓存减为负数，但是，真正能够优惠购买的用户一定是小于等于库存数的。因为，每次原子减操作后，只有返回的库存值大于等于零的用户才能够获得购买资格。无论并发量有多大，原子操作都会成功的防止超卖的发生。
& & 对于上述的逻辑，可以应对绝大多数的情况。
& & 但是随着量的增加，这种方式也有风险。当用户量极大、货物的库存极少时，就变成了秒杀。这个时候，大量的用户涌入分布式缓存减库存，对分布式缓存有极大冲击，一旦分布式缓存挂掉，秒杀活动也就宣告失败。使用分布式缓存，目的是为了让用户准确的看到剩余库存数 目，秒杀活动非常快，用户还没有看清楚库存，活动就结束了。其实用户只关心有没有秒到商品，并不关心库存的剩余数量，因此，库存减得准不准确并不是主要矛盾，这时就可以放弃分布式缓存的设计，转而使用本地缓存存储库存数，这也就是本地缓存使用的第二个场景。
& & 比如，一共有10件商品，2台机器，可以设置每台机器的本地内存中库存等于10，那么对于外网的千万个用户，就可以有20个人抢到商品，剩下的人都 被挡在库存之外。当这20个人抢到后，就可以实现另一个处理逻辑，从20个人中选出10个真正中标的人，获得10个商品的购买权限。这个选择的逻辑非常灵活，可随意定制。但是从20选10的操作，无论如何也比从千千万万个人中选10要好的多，这样可以确保秒杀的安全完成。
& & 如果秒杀的人继续增多，那么也可以通过客户端（即javascript）设置格挡率的方法，使少量的用户可以发出请求到服务器，绝大多数的用户都被挡在浏览器上。（注：一些技术人士在2013年吐槽小米网站抢购小米手机时，浏览器模拟排队等待其实没有发出任何网络请求，这就是客户端格挡率生效的结果。）
-未完待续-
备注参考资源：
1，2013，淘宝中间件团队，；
2，2012，腾讯Alloy团队，；
3，2013，淘宝搜索技术，；
4，2013，范凯，；
5，2012，kenny，&（注：只看他的故障现象即可）；
6，2010，timyang，；
7，2010，孙立，；
延伸阅读：
赠图几枚：
Lindsey Stirling的小提琴专辑
Owl City专辑
阅读(...) 评论()当前位置： →
→ 怎么设置iis6缓存
怎么设置iis6缓存
& 作者：佚名 & 来源： 互联网 & 热度：
&收藏到→_→：
摘要: 如何设置iis6 缓存iis6 虽然有自带的缓存设置，且可以每个文件夹独立设置缓存过期时间但在运用上还是不便，比如我网站的图片文...
"怎么设置iis6缓存"：：
如何设置iis6 缓存iis6 虽然有自带的缓存设置，且可以每个文件夹独立设置缓存过期时间但在运用上还是不便，比如我网站的图片文件夹设置缓存后 图片更改就不能及时查看到能不能设置成 自动检查缓存文件有没有更新，更新的话就下载没更新就不用下载呢例如我图片文件夹的缓存时间是一个月，有图片a.jpg
我是昨天上传的，如果今天没更改图片网友浏览时就不用再次下载了 如果现在更新了 网友也能看到最新的图片------解决方案--------------------
养成个好习惯，资源文件改变了以后名字也改一下。即使你解决了你的缓存的问题，很多浏览器也还是有问题——相同名字的资源下载一次就不会再下载了。 此文来自: 马开东博客
转载请注明出处 网址：
搜索此文相关文章：此文来自: 马开东博客
网址: 站长QQ
上一篇：没有了
怎么设置iis6缓存_高性能WEB开发相关文章
高性能WEB开发_总排行榜
高性能WEB开发_最新
高性能WEB开发_月排行榜
高性能WEB开发_周排行榜
高性能WEB开发_日排行榜【图文】缓存技术浅谈_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
评价文档：
缓存技术浅谈
上传于||暂无简介
大小：473.50KB
登录百度文库，专享文档复制特权，财富值每天免费拿！
你可能喜欢}