浏览器缓存

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

一、关于高并发 高并发是指在同一个时间点，有很多用户同时访问URL地址，比如：淘宝的双11、双12，就会产生高并发。又如贴吧的爆吧，就是恶意的高并发请求，也就是DDOS攻击，再屌丝点的说法就像玩LOL被ADC暴击了一样，那伤害你懂的。 来源：SFLYQ的博客 原文：http://blog.thankbabe.com/2016/09/14/high-concurrency-scheme/ 1、 高并发会来带的后果 服务端： 导致站点服务器/DB服务器资源被占满崩溃，数据的存储和更新结果和理想的设计是不一样的，比如：出现重复的数据记录，多次添加了用户积分等。 用户角度： 尼玛，这么卡，老子来参加活动的，刷新了还是这样，垃圾网站，再也不来了！ 我的经历： 在做公司产品网站的过程中，经常会有这样的需求，比如搞个活动专题、抽奖、签到、积分竞拍等等，如果没有考虑到高并发下的数据处理，那就Game Over了，很容易导致抽奖被多抽走，签到发现一个用户有多条记录等等，各种超出正常逻辑的现象，这就是做产品网站必须考虑的问题，因为这些都是面向大量用户的，而不是像做ERP管理系统、OA系统那样，只是面向员工。 下面我进行实例分析，简单粗暴，动态分析，纯属本人经验分享，如有说错或者更好的建议，请留言，大家一起成长。 2、 并发下的数据处理 通过表设计，如：记录表添加唯一约束

一、问题： 数据库表数据量极大（千万条），要求让服务器更加快速地响应用户的需求。 二、解决方案： 1.通过高速服务器Cache缓存数据库数据 2.内存数据库 （这里仅从数据缓存方面考虑，当然，后期可以采用Hadoop+HBase+Hive等分布式存储分析平台） 三、主流解Cache和数据库对比： 上述技术基本上代表了当今在数据存储方面所有的实现方案，其中主要涉及到了普通关系型数据库（MySQL/PostgreSQL），NoSQL数据库(MongoDB)，内存数据库（Redis），内存Cache（Memcached），我们现在需要的是对大数据表仍保持高效的查询速度，普通关系型数据库是无法满足的。而MongoDB其实只是一种非关系型数据库，其优势在于可以存储海量数据，具备强大的查询功能，因此不宜用于缓存数据的场景。 从以上各数据可知，对于我们产品最可行的技术方案有两种： 1.Memcached 内存Key-Value Cache 2.Redis 内存数据库 四、下面重点分析Memcached和Redis两种方案： 4.1 Memcached介绍 Memcached 是一个高性能的分布式内存对象缓存系统，用于动态Web应用以减轻数据库负载。它通过在内存中缓存数据和对象来减少读取数据库的次数，从而提供动态、数据库驱动网站的速度，现在已被LiveJournal、hatena、Facebook

一、问题： 数据库表数据量极大（千万条），要求让服务器更加快速地响应用户的需求。 二、解决方案： 1.通过高速服务器Cache缓存数据库数据 2.内存数据库 （这里仅从数据缓存方面考虑，当然，后期可以采用Hadoop+HBase+Hive等分布式存储分析平台） 三、主流解Cache和数据库对比： 上述技术基本上代表了当今在数据存储方面所有的实现方案，其中主要涉及到了普通关系型数据库（MySQL/PostgreSQL），NoSQL数据库(MongoDB)，内存数据库（Redis），内存Cache（Memcached），我们现在需要的是对大数据表仍保持高效的查询速度，普通关系型数据库是无法满足的。而MongoDB其实只是一种非关系型数据库，其优势在于可以存储海量数据，具备强大的查询功能，因此不宜用于缓存数据的场景。 从以上各数据可知，对于我们产品最可行的技术方案有两种： 1.Memcached 内存Key-Value Cache 2.Redis 内存数据库 四、下面重点分析Memcached和Redis两种方案： 4.1 Memcached介绍 Memcached 是一个高性能的分布式内存对象缓存系统，用于动态Web应用以减轻数据库负载。它通过在内存中缓存数据和对象来减少读取数据库的次数，从而提供动态、数据库驱动网站的速度，现在已被LiveJournal、hatena、Facebook

一、问题： 数据库表数据量极大（千万条），要求让服务器更加快速地响应用户的需求。 二、解决方案： 1.通过高速服务器Cache缓存数据库数据 2.内存数据库 （这里仅从数据缓存方面考虑，当然，后期可以采用Hadoop+HBase+Hive等分布式存储分析平台） 三、主流解Cache和数据库对比： 上述技术基本上代表了当今在数据存储方面所有的实现方案，其中主要涉及到了普通关系型数据库（MySQL/PostgreSQL），NoSQL数据库(MongoDB)，内存数据库（Redis），内存Cache（Memcached），我们现在需要的是对大数据表仍保持高效的查询速度，普通关系型数据库是无法满足的。而MongoDB其实只是一种非关系型数据库，其优势在于可以存储海量数据，具备强大的查询功能，因此不宜用于缓存数据的场景。 从以上各数据可知，对于我们产品最可行的技术方案有两种： 1.Memcached 内存Key-Value Cache 2.Redis 内存数据库 四、下面重点分析Memcached和Redis两种方案： 4.1 Memcached介绍 Memcached 是一个高性能的分布式内存对象缓存系统，用于动态Web应用以减轻数据库负载。它通过在内存中缓存数据和对象来减少读取数据库的次数，从而提供动态、数据库驱动网站的速度，现在已被LiveJournal、hatena、Facebook

前言 题目有点大，所以不可能说得非常具体，笔者也不能驾驭全部。 前面介绍过 网站发展过程中架构的演化过程 ,本文主要针对网站架构各个方面的建设进行简单介绍。 架构模式 先来说说模式： 每一个模式描述了一个在我们周围不断重复发生的问题及该问题解决方案的核心。这样，你就能一次又一次地用该方案而不必做重复工作 。 先来说说常见的网站架构模式。这里没有涉及具体实现过程，只是简单介绍其思想和原理，方便日后有用到再深入了解。 分层 分层是企业应用系统中最常见的一种架构模式，将系统在 横向维度 上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后 通过上层对下层的依赖和调用 组成一个完整的系统。 分层 功能 应用层 负责具体业务和视图展示，如网站首页以及搜索输入和结果展示 服务层 为应用层提供服务支持，如用户管理服务，购物车服务 数据层 提供数据存储访问服务，如数据库、缓存、文件、搜索引擎等 分层架构 还可以细分下去 ，比如说应用层可以细分为视图层和业务逻辑层。服务层可以细分为数据接口层和逻辑处理层。 分层结构对网站支持高并发向分布式发展至关重要，所以 在网站规模很小的时候就应该采用分层的架构，这样将来网站做大时才能有更好地应对 。 所以说我们在设计一个新项目的架构时，就需要考虑到分层。不能等到日后项目做大了，再重构就耗时耗力了。 分割 上面的分层是将软件在横向方面进行切分，而分割是在

HTTP 1.0 在HTTP1.0中，可以在服务端设置 Expires 的HTTP头来告诉客户端在多久之后重新请求服务，可以通过 if-modified-since 的条件请求来使用缓存，其中发送时间是文件最初被下载的时间，而不是过期时间。如果文件没有改变，服务器可以响应 304-Not Modified 表示文件未改变，客户端可以继续使用缓存的文件。 HTTP1.0中服务器在返回时，可以通过在响应头中添加 Last-Modified 的方式表示资源上一次更改时间。请求时传递的 if-modified-since 值就是 Last-Modified 的值。但是这个时间仅仅只能代表编辑时间，如果文件内容没有变化，一样会修改这个时间，所以再次请求还是会重新加载资源，而不会使用缓存。 HTTP 1.1 引入了文件标签 e-tag ，e-tag 是文件或对象的唯一标识，也就是一个MD5值， e-tag 通过Response Heasers 返回。 e-tag 在使用时会结合 If-None-Match 搭配使用，当缓存过期时，浏览器会在请求头中设置 If-None-Match ,值服务端返回的e-tag值（MD5）,当文件未发生变化时，MD5值是不变的，此时服务端可以响应 304 状态码，浏览器继续使用本地缓存，如果返回200，则服务器返回新的文件和新的 e-tag 值。 HTTP1

计算机网络基础（前端相关） 一、基础概念 1.URI 2.请求和相应报文 2.1 请求报文 2.2 响应报文 二、HTTP方法 1. GET（获取资源） 2. HEAD（获取报文首部） 3. POST（传输实体主体） 4. PUT（上传文件） 5. PATCH（对资源进行部分修改） 6. DELETE（删除文件） 7. OPTIONS（查询支持的方法） 8. CONNECT（要求在于代理服务器通信时建立隧道） 9. TRACE（追踪路径） 三、HTTP状态码 四、 HTTP首部 五、具体应用 连接管理 1. 短链接与长连接 2. 流水线 Cookie 1. 用途 2. 创建过程 3. 分类 4. 作用域 5. JavaScript 6. HttpOnly 7. Secure 8. Session 9. 浏览器禁用Cookie 10. Cookie与Session选择 缓存 1.优点 2. 实现方法 3. Cache-Control 3.1 禁止进行缓存 3.2 强制确认缓存 3.3 私有缓存和公共缓存 3.4 缓存过期机制 4. 缓存验证 内容协商 1. 类型 1.1 服务端驱动型 1.2 代理驱动型 2. Vary 内容编码 范围请求 1. Range 2. Accept-Ranges 3.响应状态码 分块传输编码 多部分对象集合 虚拟主机 通信数据转发 1. 代理 2. 网关

状态码 含义 100 客户端应当继续发送请求。这个临时响应是用来通知客户端它的部分请求已经被服务器接收，且仍未被拒绝。客户端应当继续发送请求的剩余部分，或者如果请求已经完成，忽略这个响应。服务器必须在请求完成后向客户端发送一个最终响应。 101 服务器已经理解了客户端的请求，并将通过Upgrade 消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后，服务器将会切换到在Upgrade 消息头中定义的那些协议。 　　只有在切换新的协议更有好处的时候才应该采取类似措施。例如，切换到新的HTTP 版本比旧版本更有优势，或者切换到一个实时且同步的协议以传送利用此类特性的资源。 102 由WebDAV（RFC 2518）扩展的状态码，代表处理将被继续执行。 200 请求已成功，请求所希望的响应头或数据体将随此响应返回。 201 请求已经被实现，而且有一个新的资源已经依据请求的需要而建立，且其 URI 已经随Location 头信息返回。假如需要的资源无法及时建立的话，应当返回 '202 Accepted'。 202 服务器已接受请求，但尚未处理。正如它可能被拒绝一样，最终该请求可能会也可能不会被执行。在异步操作的场合下，没有比发送这个状态码更方便的做法了。 　　返回202状态码的响应的目的是允许服务器接受其他过程的请求（例如某个每天只执行一次的基于批处理的操作）

转自CSDN ouyang-web之路 原文链接： https://blog.csdn.net/cangqiong_xiamen/article/details/90405555 一.浏览器的缓存 status 为 200 Size为 from cache 200 from cache: 直接从本地缓存中获取响应,最快速,最省流量, 因为根本没有向服务器发送请求 304 Not Modified:协商缓存,浏览器在本地没有生命中的情况下请求头中发送一定的效验数据到服务端,如果服务端数据没有改变浏览器从本地缓存响应,返回304 快速,发送的数据很少,只返回一些基本的响应头信息,数据量很小,不发送实际响应体 浏览器向服务器缓存是否更新了,是否还能继续用 200 OK： 以上两种缓存全都失败,服务器返回完整响应。没有用到缓存,相对最慢。 浏览器认为本地缓存可以使用,是不会去请求服务端的 二.获取请求头 Curl -I 参数I为只获取请求头信息 [root@localhost ~]# curl -I www.baidu.com HTTP/1.1 200 OK Accept-Ranges: bytes Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform Connection: Keep