浏览器缓存

多级缓存的分层架构 前言 在互联网高速发展的今天，缓存技术被广泛地应用。无论业内还是业外，只要是提到性能问题，大家都会脱口而出“用缓存解决”。 这种说法带有片面性，甚至是一知半解，但是作为专业人士的我们，需要对缓存有更深、更广的了解。 缓存技术存在于应用场景的方方面面。从浏览器请求，到反向代理服务器，从进程内缓存到分布式缓存。其中缓存策略，算法也是层出不穷，今天就带大家走进缓存。 正文 缓存对于每个开发者来说是相当熟悉了，为了提高程序的性能我们会去加缓存，但是在什么地方加缓存，如何加缓存呢？ 假设一个网站，需要提高性能，缓存可以放在浏览器，可以放在反向代理服务器，还可以放在应用程序进程内，同时可以放在分布式缓存系统中。 从用户请求数据到数据返回，数据经过了浏览器，CDN，代理服务器，应用服务器，以及数据库各个环节。每个环节都可以运用缓存技术。 从浏览器/客户端开始请求数据，通过 HTTP 配合 CDN 获取数据的变更情况，到达代理服务器（Nginx）可以通过反向代理获取静态资源。 再往下来到应用服务器可以通过进程内（堆内）缓存，分布式缓存等递进的方式获取数据。如果以上所有缓存都没有命中数据，才会回源到数据库。 缓存的请求顺序是：用户请求 → HTTP 缓存 → CDN 缓存 → 代理服务器缓存 → 进程内缓存 → 分布式缓存 → 数据库。 看来在技术的架构每个环节都可以加入缓存

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 本文链接：https://blog.csdn.net/sanyaoxu_2/article/details/78992113 1.应用和静态资源分离 刚开始的时候应用和静态资源是保存在一起的，当并发量达到一定程度的时候就需要将静态资源保存到专门的服务器中，静态资源主要包括图片、视频、js、css和一些资源文件等，这些文件因为没有状态所以分离比较简单，直接存放到响应的服务器就可以了，一般会使用专门的域名去访问。 通过不同的域名可以让浏览器直接访问资源服务器而不需要再访问应用服务器了。架构图如下： 2.页面缓存 页面缓存是将应用生成的页面缓存起来，这样就不需要每次都生成页面了，从而可以节省大量的CPU资源，如果将缓存的页面放到内存中速度就更快了。如果使用Nginx服务器就可以使用它自带的缓存功能，当然也可以使用专门的Squid 服务器。页面缓存的默认失效机制一班都是按缓存时间处理的，当然也可以在修改数据之后手动让相应的缓存失效。 页面缓存主要是使用在数据很少发生变化的页面，但是很多页面是大部分数据都很少发生变化，而其中很少一部分数据变化频率却非常高，比如说一个显示文章的页面，正常来说完全可以静态化，但是如果文章后面有“顶”和“踩”的功能而且显示的有响应的数量

一、Cache 缓存简介 我们知道绝大多数的网站/系统，最先遇到的一个 性能瓶颈就是数据库 ，使用 缓存做数据库的前置缓存 ，可以非常有效地降低数据库的压力，从而提升整个系统的响应效率和并发量。 以往使用缓存时， 通常创建好缓存工具类，使用时将对应的工具类注入，操作工具类在前端处理缓存的逻辑 。其实这种方式是 低效的 ，大部分使用缓存的场景是基于数据库的缓存，这类缓存场景的逻辑往往是：如果缓存中存在数据，就从缓存中读取，如果缓存中不存在数据或者数据失效，就再从数据库中读取。 为了实现这样的逻辑，往往需要在业务代码中写很多的逻辑判断，那么有没有通用的代码来实现这样的逻辑呢？其实有，按照这个逻辑我们可以写一个工具类来实现，每次需要这样判断逻辑时调用工具类中的方法即可，还有没有更优雅的使用方式呢？答案是肯定的，如果我们把这种固定的逻辑使用 Java 注解来实现，每次需要使用时只需要在对应的方法或者类上写上注解即可。 Spring 也看到了这样的使用场景，于是有了 注释驱动的 Spring Cache 。它的原理是 Spring Cache 利用了 Spring AOP 的动态代理技术 ，在项目启动的时候动态生成它的代理类，在代理类中实现了对应的逻辑。 Spring Cache 是在 Spring 3.1 中引入的基于注释（Annotation）的缓存（Cache）技术

一、什么是高可用 高可用HA （ High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指， 通过设计减少系统不能提供服务的时间 。 假设系统一直能够提供服务，我们说系统的可用性是100%。 如果系统每运行100个时间单位，会有1个时间单位无法提供服务，我们说系统的可用性是99%。 很多公司的高可用目标是4个9，也就是99.99%，这就意味着，系统的年停机时间为8.76个小时。 百度的搜索首页，是业内公认高可用保障非常出色的系统，甚至人们会通过www.baidu.com 能不能访问来判断“网络的连通性”，百度高可用的服务让人留下啦“网络通畅，百度就能访问”，“百度打不开，应该是网络连不上”的印象，这其实是对百度HA最高的褒奖。 二、如何保障系统的高可用 我们都知道，单点是系统高可用的大敌，单点往往是系统高可用最大的风险和敌人，应该尽量在系统设计的过程中避免单点。 方法论上，高可用保证的原则是“集群化”，或者叫“冗余” ：只有一个单点，挂了服务会受影响；如果有冗余备份，挂了还有其他backup能够顶上。 保证系统高可用，架构设计的核心准则是：冗余。 有了冗余之后，还不够，每次出现故障需要人工介入恢复势必会增加系统的不可服务实践。所以，又往往是 通过“自动故障转移”来实现系统的高可用 。 接下来我们看下典型互联网架构中，如何通过 冗余+自动故障转移

原创 2016-12-05 58沈剑 架构师之路 一、什么是高可用 高可用HA （ High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。 假设系统一直能够提供服务，我们说系统的可用性是100%。 如果系统每运行100个时间单位，会有1个时间单位无法提供服务，我们说系统的可用性是99%。 很多公司的高可用目标是4个9，也就是99.99%，这就意味着，系统的年停机时间为8.76个小时。 百度的搜索首页，是业内公认高可用保障非常出色的系统，甚至人们会通过www.baidu.com 能不能访问来判断“网络的连通性”，百度高可用的服务让人留下啦“网络通畅，百度就能访问”，“百度打不开，应该是网络连不上”的印象，这其实是对百度HA最高的褒奖。 二、如何保障系统的高可用 我们都知道，单点是系统高可用的大敌，单点往往是系统高可用最大的风险和敌人，应该尽量在系统设计的过程中避免单点。方法论上，高可用保证的原则是“集群化”，或者叫“冗余”：只有一个单点，挂了服务会受影响；如果有冗余备份，挂了还有其他backup能够顶上。 保证系统高可用，架构设计的核心准则是：冗余。 有了冗余之后，还不够，每次出现故障需要人工介入恢复势必会增加系统的不可服务实践。所以，又往往是通过“自动故障转移”来实现系统的高可用。

本文参考： charles 禁用缓存 No caching Settings/无缓存工具的用法 弹窗面板上一句话概括了他的工作原理：通过修改请求和响应头来防止缓存; 无缓存工具 无缓存工具阻止客户端应用程序（如Web浏览器）缓存任何资源。因此，请求总是发送到远程站点，并且您始终看到最新版本。 适用范围 该工具可以作用于每个请求（选中 Enable No Caching 即可），也可以仅对你配置的HOST启用（启用的nocaching同时，请选中 only for selected locations）; 当用于”only for selected locations”时，可以将no caching的效果限制在你所配置的主机上； 当然location配置也非常灵活； 我比较喜欢用全部禁止，选中 Enable No Caching，并且下面的only选项不要选，就可以了； 不过这样做也有一个不好的地方，就是你访问的时候，同样的资源，在视图中，每调用一次，就会出现一次； 关于WEB缓存 WWW是互联网上最受欢迎的应用之一，其快速增长造成网络拥塞和服务器超载，导致客户访问延迟增大，WWW服务质量日益显现出来。缓存技术被认为是减轻服务器负载、降低网络拥塞、增强WWW可扩展性的有效途径之一，其基本思想是利用客户访问的时间局部性（Temproral Locality）原理

一、Spring Boot 和 Redis 常用操作 Redis 是目前使用最广泛的缓存中间件，相比 Memcached，Redis 支持更多的数据结构和更丰富的数据操作 ，另外 Redis 有着丰富的集群方案和使用场景，这一课我们一起学习 Redis 的常用操作。 1、Redis 介绍 Redis 是一个速度非常快的非关系数据库（Non-Relational Database），它可以存储键（Key）与 5 种不同类型的值（Value）之间的映射（Mapping），可以将存储在内存的键值对数据持久化到硬盘，可以使用复制特性来扩展读性能，还可以使用客户端分片来扩展写性能。 为了满足高性能，Redis 采用内存（in-memory）数据集（Dataset），根据使用场景，可以通过每隔一段时间转储数据集到磁盘，或者追加每条命令到日志来持久化。持久化也可以被禁用，如果你只是需要一个功能丰富、网络化的内存缓存。 数据模型 Redis 数据模型不仅与关系数据库管理系统（RDBMS）不同，也不同于任何简单的 NoSQL 键-值数据存储。Redis 数据类型类似于编程语言的基础数据类型，因此开发人员感觉很自然，每个数据类型都支持适用于其类型的操作，受支持的数据类型包括： String（字符串） Hash（哈希） List（列表） Set（集合） Zset（Sorted Set：有序集合）

PHP header 的几种用法 PHP header 的几种用法，你知道几种？ 1. 跳转页面 header('Location:'.$url); //Location和":"之间无空格。 2. 声明content-type header('content-type:text/html;charset=utf-8'); 3. 返回response状态码 header('HTTP/1.1 404 Not Found'); 4. 在某个时间后执行跳转 header('Refresh: 10; url=http://www.baidu.com/'); //10s后跳转。 5. 控制浏览器缓存 header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");header("Last-Modified: " . gmdate("D, d M Y H:i:s") . "GMT");header("Cache-Control: no-cache, must-revalidate");header("Pragma: no-cache"); 6. 执行http验证 header('HTTP/1.1 401 Unauthorized');header('WWW-Authenticate: Basic realm="Top Secret"'); 7. 执行下载操作

1 秒杀业务分析# 正常电子商务流程 （1）查询商品； （2）创建订单； （3）扣减库存； （4）更新订单； （5）付款； （6）卖家发货； 秒杀业务的特性 （1）低廉价格； （2）大幅推广； （3）瞬时售空； （4）一般是定时上架； （5）时间短、瞬时并发量高； 2 秒杀技术挑战# 假设某网站秒杀活动只推出一件商品，预计会吸引1万人参加活动，也就说最大并发请求数是10000，秒杀系统需要面对的技术挑战有： 对现有网站业务造成冲击 秒杀活动只是网站营销的一个附加活动，这个活动具有时间短，并发访问量大的特点，如果和网站原有应用部署在一起，必然会对现有业务造成冲击，稍有不慎可能导致整个网站瘫痪。 解决方案 ：将秒杀系统独立部署，甚至 使用独立域名，使其与网站完全隔离 。 高并发下的应用、数据库负载 用户在秒杀开始前，通过不停刷新浏览器页面以保证不会错过秒杀，这些请求如果按照一般的网站应用架构，访问应用服务器、连接数据库，会对应用服务器和数据库服务器造成负载压力。 解决方案 ：重新设计秒杀商品页面，不使用网站原来的商品详细页面， 页面内容静态化，用户请求不需要经过应用服务 。 突然增加的网络及服务器带宽 假设商品页面大小200K（主要是商品图片大小），那么需要的网络和服务器带宽是2G（200K×10000），这些网络带宽是因为秒杀活动新增的，超过网站平时使用的带宽。 解决方案

1. 了解数据包区域的字段含义 转载： https://www.cnblogs.com/victorm/p/9119482.html #：顺序号，按照抓包的顺序从1递增 Result：HTTP状态码　　　　　　 Protocol：请求使用的协议，如HTTP/HTTPS/FTP等 HOST：请求地址的主机名或域名 URL：请求资源的位置 Body：请求大小 Caching：请求的缓存过期时间或者缓存控制值 Content-Type：请求响应的类型 Process：发送此请求的进程ID Comments：备注 Custom：自定义值 2. 查看数据包的具体内容 双击击具体的一条数据包可以在右侧菜单点击Insepector查看详细内容。分为请求（即客户端发出的数据）和响应（服务器返回的数据）两部分。 3. Request Header 下面是对Request Header区域各个item做介绍 请求方式 ：GET 协议 ： HTTP/1.1 1. Cache 头域 　　if-Modified-since：缓存 　　if-None-Match：可提高性能（在Response中添加ETag信息，客户端再次请求资源，Request中加入if-None-Match（ETag的值），服务器验证ETag，若没改变返回状态码304，有改变，返回状态码200） 　　Pragma：防止页面被缓存