缓存服务器

强缓存 强缓存是利用Expires或者Cache-Control这两个http response header实现的，它们都用来表示资源在客户端缓存的有效期。 Expires是http1.0提出的一个表示资源过期时间的header，它描述的是一个绝对时间，由服务器返回，用GMT格式的字符串表示，如：Expires:Thu, 31 Dec 2037 23:55:55 GMT，它的缓存原理是： 1）浏览器第一次跟服务器请求一个资源，服务器在返回这个资源的同时，在respone的header加上Expires的header 2）浏览器在接收到这个资源后，会把这个资源连同所有response header一起缓存下来（所以缓存命中的请求返回的header并不是来自服务器，而是来自之前缓存的header）； 3）浏览器再请求这个资源时，先从缓存中寻找，找到这个资源后，拿出它的Expires跟当前的请求时间比较，如果请求时间在Expires指定的时间之前，就能命中缓存，否则就不行。 4）如果缓存没有命中，浏览器直接从服务器加载资源时，Expires Header在重新加载的时候会被更新。 Expires是较老的强缓存管理header，由于它是服务器返回的一个绝对时间，在服务器时间与客户端时间相差较大时，缓存管理容易出现问题，比如随意修改下客户端时间，就能影响缓存命中的结果。 所以在http1

HTTP协议中，关于一些头域的解释很模糊，网上的解释有些甚至是打架的，例如cache-control:no-cache，为了搞清这个头，google了不少资料，但很多都是各有各说法，甚至相互矛盾。http header中cache-control无疑是非常重要的一个头，往往涉及到性能问题，缓存，缓存代理等等都无法避免跟cache-control打交道。当然还有其他一些头域如last-modified，但它们含义都非常明确，至少没有cache-control那么含糊。 就连浏览器之间，对cache-control也有不同的理解，导致了对这个头的不同的表现。 网上很多关于cache-control的资料写得很模糊，我觉得很多都没有，或者可能是忽略了几个地方，使得我们看着这些资料的时候，似懂非懂。或者作者觉得某些地方足够容易理解，所以根本不觉得需要强调，但正是这些被忽略掉的“前提条件”令我们即使看完资料，也很难弄懂问题。那些对cache-control进行解释的资料通常会忽略的一些"前提条件"有这几个： 1.cache-control是出现在response还是request中。很多资料在解释cache-control时候，都没有指明是response中的cache-control（也就是由服务器应答时发送的cache-control）还是request中的cache-control

缓存是一种将数据保存在本地，在下一次需要使用它时，无需从数据的源头而是直接本地读取的一种技术。在http中，缓存是非常重要的组成部分。 意义 http 是一种 请求->响应 的半双工通讯协议，网页的 html 文档以及内部的每一张图片、javascript 脚本文本、css 样式文件等资源都需要向服务器发出请求，然后得到所需资源的响应。 如果没有浏览器缓存 从向服务器发起 TCP 连接请求，到服务器磁盘 IO，计算到响应传输整个过程，对网络带宽，服务器性能都是不小的考验。而一个页面往往会有少则十几，多则几十上百的请求，如果每一个资源都从服务端获取，在并发的情况下会给服务器带来很大的压力。 加入缓存后，如果客户端没有资源，会从服务端获取，取得资源后同时存在本地。下一次请求时如果有有效缓存则取缓存，由于不会向服务器发起请求，可以减少服务器的压力，同时从本地读取，不会占用网络带宽，速度也是极快的。 那么 HTTP 协议是怎么控制缓存的呢？ 缓存前提 资源标志 浏览器会把请求的类型 Method （通常来说我们只缓存 get 的请求）和 URI 完整地址作为一个资源的标志。 例如下面这些浏览器都会认为是不同资源，后者并不会匹配前者的缓存。 https://xxxx/a.js 和 http://xxxx/a.js http://xxxx/a.js 和 http://yyyy/a.js

缓存是搭建高性能高并发系统的必备手段之一，通常用来解决性能瓶颈，是程序员的必备知识点，也是面试必备考点。 尽管，产品经理大概率不会关注系统性能，但程序员在实现需求的时候必须思考系统承载的并发量和用户量。缓存主要用来解决性能瓶颈的问题，一旦错误使用反而会令系统崩溃。今天，我们就通过4W的方式系统化地总结缓存相关的理论知识。 随着互联网业务的快速迭代以及用户量激增，应用架构需要不断调整甚至重构以适应这种业务的快速发展。当数据量迅速增长，业务逻辑越复杂，服务链路不断增加等等一系列问题，会导致RT过长，服务性能需要逐渐提升以满足更优的用户体验。在优化系统架构时通常的所用的两种方式scale up以及scale out，scale out就是通常所说的水平扩展，将应用服务设计成无状态性，可以方便水平扩展通过增加硬件的方式分解访问压力。而scale up则是将单个服务链路性能提升，以提升QPS以及系统的吞吐量。在追求更优的性能时，大多数业务场景是读多写少的情况，一般会通过引入缓存的方式解决。 What——什么是缓存? 关于缓存的定义，在wiki中为： a collection of data duplicating original values stored elsewhere on a computer, usually for easier access.

1. 先下载库 django-redis 2.在setting中添加缓存设置 CACHES = { 'default': { 'BACKEND': 'django_redis.cache.RedisCache', 'LOCATION': 'redis://127.0.0.1:6379', "OPTIONS": { "CLIENT_CLASS": "django_redis.client.DefaultClient", "PASSWORD": "密码", }, }, } 3.视图函数 from django.core.cache import cache # 引入缓存模块 def detail(request, pk): if cache.has_key(pk): print('有cach') post = cache.get(pk) print(post) else: print('没cach') post = get_object_or_404(Post, pk=pk) time.sleep(3) cache.set(pk, post, 10) # 写入key为key，值为value的缓存，有效期30分钟 return render(request, 'blog/detail.html', context={'post': post}) 4.redis 里就能看到有数据了

一 磁盘物理结构 (1) 盘片：硬盘的盘体由多个盘片叠在一起构成。 在硬盘出厂时，由硬盘生产商完成了低级格式化(物理格式化)，作用是将空白的盘片(Platter)划分为一个个同圆心、不同半径的磁道(Track)，还将磁道划分为若干个扇区(Sector)，每个扇区可存储128×2的N次方（N=0.1.2.3）字节信息，默认每个扇区的大小为512字节。通常使用者无需再进行低级格式化操作。 (2) 磁头：每张盘片的正反两面各有一个磁头。 (3) 主轴：所有盘片都由主轴电机带动旋转。 (4) 控制集成电路板：复杂！上面还有ROM（内有软件系统）、Cache等。 二 磁盘如何完成单次IO操作 (1) 寻道 当控制器对磁盘发出一个IO操作命令的时候，磁盘的驱动臂(Actuator Arm)带动磁头(Head)离开着陆区(Landing Zone，位于内圈没有数据的区域)，移动到要操作的初始数据块所在的磁道(Track)的正上方，这个过程被称为寻道(Seeking)，对应消耗的时间被称为寻道时间(Seek Time)； (2) 旋转延迟 找到对应磁道还不能马上读取数据，这时候磁头要等到磁盘盘片(Platter)旋转到初始数据块所在的扇区(Sector)落在读写磁头正下方之后才能开始读取数据，在这个等待盘片旋转到可操作扇区的过程中消耗的时间称为旋转延时(Rotational Latency)；

Memcached（一个高性能的分布式的内存对象缓存系统） 　　可用来分担数据库的压力。通过在内存里维护一个统一的巨大的hash表，memcached能存储各种各样的数据，包括图像、视频、文件、以及数据库检索的结果等。简单的说就是将数据调用到内存中，然后从内存中读取，从而大大提高读取速度。 适用：存储验证码（图形验证码、短信验证码）、登录session等所有不是至关重要的数据。 安全性： 使用 -l 参数设置为只有本地可以连接：这种方式，就只能通过本机才能连接，别的机器都不能访问，可以达到最好的安全性。 使用防火墙，关闭11211端口，外面也不能访问。 django中使用需在 settings.py 中配置好缓存； 添加 KEY_FUNCTION 参数：django在存储数据到memcached中的时候，可自定义前缀。 1 # 配置memcached缓存； 2 CACHES = { 3 'default': { 4 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache', 5 # 可指定多个连接：['172.19.26.240:11211','172.19.26.242:11211',] 6 'LOCATION': '127.0.0.1:11211', 7 'KEY_FUNCTION': lambda key

1. 概述 本文以淘宝作为例子，介绍从一百个到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，文章最后汇总了一些架构设计的原则。 特别说明：本文以淘宝为例仅仅是为了便于说明演进过程可能遇到的问题，并非是淘宝真正的技术演进路径 2. 基本概念 在介绍架构之前，为了避免部分读者对架构设计中的一些概念不了解，下面对几个最基础的概念进行介绍： 分布式 系统中的多个模块在不同服务器上部署，即可称为分布式系统，如Tomcat和数据库分别部署在不同的服务器上，或两个相同功能的Tomcat分别部署在不同服务器上 高可用 系统中部分节点失效时，其他节点能够接替它继续提供服务，则可认为系统具有高可用性 集群 一个特定领域的软件部署在多台服务器上并作为一个整体提供一类服务，这个整体称为集群。如Zookeeper中的Master和Slave分别部署在多台服务器上，共同组成一个整体提供集中配置服务。在常见的集群中，客户端往往能够连接任意一个节点获得服务，并且当集群中一个节点掉线时，其他节点往往能够自动的接替它继续提供服务，这时候说明集群具有高可用性 负载均衡 请求发送到系统时，通过某些方式把请求均匀分发到多个节点上，使系统中每个节点能够均匀的处理请求负载，则可认为系统是负载均衡的 正向代理和反向代理 系统内部要访问外部网络时

——以下内容如有各种问题，烦请指出，谢谢各位^_^—— 最基本的Java程序员面试题都有这个题 ——http get和post的区别？ 不少人大学还没毕业就知道，就算不知道也会去搜，我记得我快毕业那会，简单搜出来，排在前面的大概就这么几个区别： 1、get用于获取数据，post用于提交数据 2、get提交参数追加在url后面，post参数可以通过http body提交 3、get的url会有长度上的限制，则post的数据则可以非常大 4、get提交信息明文显示在url上，不够安全，post提交的信息不会在url上显示 5、get提交可以被浏览器缓存，post不会被浏览器缓存 现在回头总结下，发现自己快毕业哪会自己真是什么都不知道啊，当时网上搜出来的这份东西就是有误的啊，国内也是各种传来传去，错误的到处 看得到，都快成标准答案了。今年5月用netty http 些服务端程序时，调接口无意发现了原来get也可以使用http body提交数据，抽空弄了下tomcat，发现也可以啊。今天整理笔记看到了这里，觉得有必要在博客上记录一下，避免后来人继续犯错。 一点一点的说 第1点：rfc2616说get方法用于获取指定uri所代表的资源，应该设计成幂等的（其他情况不变时，多次请求返回同样的结果，差不多算是只读），不过在很长一段时间内，get方法都有“写”功能，最简单的例子就是/delete

对于提交的订单，为了防止浏览器回退重新提交，我们可以使用Cache-Control之no-store绝对禁止缓存，即便浏览器回退依然请求的是服务器，进而判断订单的状态给出相应的提示信息！ 附网上解释： Cache-Control Http1.1 中的标准，可以看成是 expires 的补充。使用的是相对时间的概念。 简单介绍下Cache-Control的属性设置。 1）max-age: 设置缓存的最大的有效时间，单位为秒（s）。max-age会覆盖掉Expires 2) s-maxage: 只用于共享缓存，比如CDN缓存（s -> share）。与max-age 的区别是：max-age用于普通缓存， 而s-maxage用于代理缓存。如果存在s-maxage,则会覆盖max-age 和 Expires. 3) public：响应会被缓存，并且在多用户间共享。默认是public。 4) private: 响应只作为私有的缓存，不能在用户间共享。如果要求HTTP认证，响应会自动设置为private。 5）no-cache: 指定不缓存响应，表明资源不进行缓存。但是设置了no-cache之后并不代表浏览器不缓存，而是在缓存前要向服务器确认资源是否被更改。因此有的时候只设置no-cache防止缓存还是不够保险，还可以加上private指令，将过期时间设为过去的时间。 6）no-store: