浏览器缓存

概述 互联网应用发展到今天，从单体应用架构到SOA以及今天的微服务，随着微服务化的不断升级进化，服务和服务之间的稳定性变得越来越重要，分布式系统之所以复杂，主要原因是分布式系统需要考虑到网络的延时和不可靠，微服务很重要的一个特质就是需要保证服务幂等，保证幂等性很重要的前提需要分布式锁控制并发，同时缓存、降级和限流是保护微服务系统运行稳定性的三大利器。 随着业务不断的发展，按业务域的划分子系统越来越多，每个业务系统都需要缓存、限流、分布式锁、幂等工具组件，distributed-tools组件(暂未开源)正式包含了上述分布式系统所需要的基础功能组件。 distributed-tools组件基于tair、redis分别提供了2个springboot starter，使用起来非常简单。 以使用缓存使用redis为例，application.properties添加如下配置 redis.extend.hostName=127.0.0.1 redis.extend.port=6379 redis.extend.password=pwdcode redis.extend.timeout=10000 redis.idempotent.enabled=true 接下来的篇幅，重点会介绍一下缓存、限流、分布式锁、幂等的使用方式。 缓存 缓存的使用可以说无处不在，从应用请求的访问路径来看，用户user

一、前言 　　我们在 优化Web服务 的时候，对于 静态的资源文件 ，通常都是通过 客户端缓存 、 服务器缓存 、 CDN缓存 ，这三种方式来缓解客户端对于Web服务器的连接请求压力的。 　　本文指在这三个方面，在ASP.NET Core中静态文件的实现过程和使用方法进行阐述。当然也可以考虑使用反向代理的方式(例如IIS或Nginx)，这些不是本文讨论的内容。 　　本文重点展示如何通过 StaticFileMiddleware 中间件，提高网站的性能。虽然这不是唯一缓存文件的方式，我们还可以通过 ResponseCacheAttribute 特性为ASP.NET Core Mvc的Controller和Action进行缓存的设置。 二、StaticFileMiddleware 　　1.文件服务与默认缓存规则 　　当创建一个ASP.NET Core的项目时，查看Startup.Configure方法，就会看到默认模板生成的添加 StaticFileMiddleware 中间件的方法。 public void Configure(IApplicationBuilder app) { // looging and exception handler removed for clarity app.UseStaticFiles(); app.UseMvc(routes => {

概述 缓存已经成了项目中是必不可少的一部分，它是提高性能最好的方式，例如减少网络I/O、减少磁盘I/O 等，使项目加载速度变的更快。 缓存可以是CPU缓存、内存缓存、硬盘缓存，不同的缓存查询速度也不一样（CPU缓存 优于 内存缓存 优于 硬盘缓存）。 接下来，给大家逐一进行介绍。 浏览器缓存 浏览器将请求过的页面存储在客户端缓存中，当访问者再次访问这个页面时，浏览器就可以直接从客户端缓存中读取数据，减少了对服务器的访问，加快了网页的加载速度。 强缓存 用户发送的请求，直接从客户端缓存中获取，不请求服务器。 根据 Expires 和 Cache-Control 判断是否命中强缓存。 代码如下： header('Expires: '. gmdate('D, d M Y H:i:s', time() + 3600). ' GMT'); header("Cache-Control: max-age=3600"); //有效期3600秒 Cache-Control 还可以设置以下参数： public：可以被所有的用户缓存（终端用户的浏览器/CDN服务器） private：只能被终端用户的浏览器缓存 no-cache：不使用本地缓存 no-store：禁止缓存数据 协商缓存 用户发送的请求，发送给服务器，由服务器判定是否使用客户端缓存。 代码如下： $last_modify =

/*--> */ /*--> */ 前言：“学习提升往往是打破思维壁垒的过程”，缓存策略是一个封闭的既成事实？还是只是一个约定规则？客户度的事被浏览器做了多少？服务端也是如此么 ? 还是只是被框架阻拦了思维，只是框架替你做了，如果进入底层，一些要自己写，那这些只是规则？是否也能被改写？ （阅读文章前，先理解观点 1，带着观点看文章） 【观点 1】：缓存规则是一个客观事实么？不，对于服务端而言，它可以只是一个主观设置的规则。 一、缓存原理 ======================= 1、通过地址栏的链接访问不会使用缓存（也就是入口文件必定访问服务器），入口文件中引入的文件资源才会被缓存。 2、缓存是浏览器和服务器端的游戏，判断条件只有 【两点】 : 1、 【当前缓存是否过期？】 不管过没过期（过期了继续使用），如文件没有改变，返回 304，启用缓存； 2、 【服务器中的文件是否有改动？】 即便没过期，但是改动了，也会返回 200，并送上新文件与新修改日期 二、如何实现缓存 ======================== 1、【缓存期限】：请求头中携带期限字段，有两种字段方式（以前还有一种pragma，优先级最高，不过慢慢抛弃了） 【 Expires】 :直接标明过期时间，绝对时间； 【Cache-Control （max-age ）】:max-age 存放是一个时间段，相对时间

1. Redis 简介 Redis 是目前业界使用最广泛的内存数据存储。相比 Memcached，Redis 支持更丰富的数据结构，例如 hashes, lists, sets 等，同时支持数据持久化。除此之外，Redis 还提供一些类数据库的特性，比如事务，HA，主从库。可以说 Redis 兼具了缓存系统和数据库的一些特性，因此有着丰富的应用场景。本文介绍 Redis 在 Spring Boot 中两个典型的应用场景。 2. Lettuce 简介 如果在 Java 应用中使用过 Redis 缓存，那么对 Jedis 一定不陌生， Lettuce 和 Jedis 一样，都是连接 Redis Server 的客户端程序。 Jedis 在实现上是直连 Redis Server ，多线程环境下非线程安全，除非使用连接池，为每个 Jedis 实例增加物理连接。 Lettuce 基于 Netty 的连接实例（StatefulRedisConnection），可以在多个线程间并发访问，且线程安全，满足多线程环境下的并发访问，同时它是可伸缩的设计，一个连接实例不够的情况也可以按需增加连接实例。 3. Spring Boot 应用中使用方式 直接通过 RedisTemplate 来使用 使用 Spring Cache 集成 Redis 通过 Spring Session 做 Session 共享

##2.1 网站架构模式## 为了解决大型网站面临的高并发访问，海量数据处理，高可靠运行等一系列问题与挑战，大型互联网公司在实践中提出了许多解决方案，以实现网站高性能，高可用，易伸缩，可扩展，安全等各种技术架构目标。这些解决方案又被更多网站重复使用，从而逐渐形成大型网站架构模式。 ###2.1.1 分层### 分层是企业应用系统中最常见的一种架构模式，将系统在 横向维度 上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后通过上层对下层的依赖和调用组成一个完整的系统。 分层结构在计算机世界中无处不在， 网络的7层通信协议 是一种分层结构；计算机硬件，操作系统，应用软件也可以看作是一种分层结构。在大型网站中也采用分层结构，将网站软件系统分为 应用层 ， 服务层 ， 数据层 ，如下： 应用层 ：负责具体业务和视图展示，如网站首页及搜索输入和结果展示； 服务层 ：为应用层提供服务支持，如用户管理服务，购物车服务等； 数据层 ：提供数据存储访问服务，如数据库，缓存，文件，搜索引擎等； 通过分层，可以更好地将一个庞大的软件系统切分成不同的部分，便于分工合作开发和维护；各层之间具有一定的独立性，只要维持调用接口不变，各层可以根据具体问题独立演化发展而不需要其他层必须做出相应调整。 但是分层架构也有一些挑战，就是 必须合理规划层次边界和接口 ，在开发过程中，严格遵循分层架构的约束

一张图看懂DNS域名解析全过程 DNS域名解析是互联网上非常重要的一项服务，上网冲浪（还有人在用这个词吗？）伴随着大量DNS服务来支撑，而对于网站运营来说，DNS域名解析的稳定可靠，意味着更多用户的喜欢，更好的SEO效果和更大的访问流量。我们先了解一下什么是DNS： DNS，就是Domain Name System的缩写，翻译过来就是域名系统，是互联网上作为域名和IP地址相互映射的一个分布式数据库。DNS能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。通过域名，最终得到该域名对应的IP地址的过程叫做域名解析（或主机名解析）。 下面这张图，详细说明了一个DNS域名解析的全过程： 下面来详细解释DNS域名解析的过程： 网络客户端就是我们平常使用的电脑，打开浏览器，输入一个域名。比如输入www.163.com，这时，你使用的电脑会发出一个DNS请求到本地DNS服务器。本地DNS服务器一般都是你的网络接入服务器商提供，比如中国电信，中国移动。 查询www.163.com的DNS请求到达本地DNS服务器之后，本地DNS服务器会首先查询它的缓存记录，如果缓存中有此条记录，就可以直接返回结果。如果没有，本地DNS服务器还要向DNS根服务器进行查询。 根DNS服务器没有记录具体的域名和IP地址的对应关系，而是告诉本地DNS服务器，你可以到域服务器上去继续查询

React写前端缓存： 设置缓存数据：localStorage.setItem('OLDPROJID', oldprojid); 获取换成数据：let dataUser = localStorage.getItem('user_claims'); 清除缓存数据： localStorage.removeItem('OLDPROJID', oldprojid); Vue写前端缓存： 获取缓存数据：let expendKeys = window.localStorage.getItem('expendKeys'); 设置缓存数据：window.localStorage.setItem('expendKeys', JSON.stringify(this.defaultExpandRowKeys)); 清除缓存数据：window.localStorage.removeItem('expendKeys'); 设置cookie： 1、手工设置 到浏览器控制台找到Application->Cookies->路径，name -> （设置cookie名，比如设为login）, value ->（设置cookie值，比如设为true） 2、js设置cookie <script> export default { methods: { handleClick () { const expires =

.NET Core针对缓存提供了很好的支持 ，我们不仅可以选择将数据缓存在应用进程自身的内存中，还可以采用分布式的形式将缓存数据存储在一个“中心数据库”中。对于分布式缓存，.NET Core提供了针对Redis和SQL Server的原生支持。除了这个独立的缓存系统之外，ASP.NET Core还借助一个中间件实现了“响应缓存”，它会按照HTTP缓存规范对整个响应实施缓存。不过按照惯例，在对缓存进行系统介绍之前，我们还是先通过一些简单的实例演示感知一下如果在一个ASP.NET Core应用中如何使用缓存。 目录 一、将数据缓存在内存中 二、基于Redis的分布式缓存 三、基于SQL Server的分布式缓存 四、缓存整个HTTP响应 一、将数据缓存在内存中 与针对数据库和远程服务调用这种IO操作来说，应用针对内存的访问性能将提供不止一个数量级的提升，所以将数据直接缓存在应用进程的内容中自然具有最佳的性能优势。与基于内存的缓存相关的应用编程接口定义在NuGet包“Microsoft.Extensions.Caching.Memory”中，具体的缓存实现在一个名为MemoryCache的服务对象中，后者是我们对所有实现了IMemoryCache接口的所有类型以及对应对象的统称。由于是将缓存对象直接置于内存之中，中间并不涉及持久化存储的问题，自然也就无需考虑针对缓存对象的序列化问题

installability( 可安装性 )，可被添加自主屏与全屏运行。 app shell: 第一次渲染个壳，等异步数据来了在填充。 offline( 离线能力 )：离线和弱网环境也能秒开，server worker 给了 web 一个可以跑后台的线程，它可以搭配非常靠谱的 cache Api 做缓存、可以拦截所有 Http 请求并使用 Fetch API 进行 response ，一个非常完备哦的 proxy 就这么诞生了 re-engageable：推送通知的能力，依赖 service Worker 与 http push，不过默认支持的可是 GCM 推送是指服务器向服务工作线程提供信息的操作 通知是指服务工作线程或网页脚本向用户信息的操作。 service Worker 有以下功能和特性 一个独立的 worker 线程，独立于当前网页进程，有自己独立的 worker context。 一旦被 install，就永远存在，除非被 uninstall 需要的时候可以直接唤醒，不需要的时候自动睡眠（有效利用资源，此处有坑） 可编程拦截代理请求和返回，缓存文件，缓存的文件可以被网页进程取到（包括网络离线状态） 离线内容开发者可控 能向客户端推送消息 不能直接操作 DOM 出于安全的考虑，必须在 HTTPS 环境下才能工作 异步实现，内部大都是通过 Promise 实现