缓存服务器

我也要谈谈大型网站架构之系列（3）——死了都要说的缓存 　　说到缓存，我想大家跟我一样都很兴奋，当我们遭遇网站性能瓶颈的时候，缓存是一剂强心针，也是一粒紧急妈富隆，从而在优化网站 性能方面冠上了第一定律的帽子，我们前年在做淘应用的时候，就遭遇了性能瓶颈，短时间内采用缓存紧急优化，给我们大优化之前争取了 宝贵的时间。 一：缓存的种类 要说缓存有多少种，太多了，比如浏览器缓存，文件缓存，片段缓存，数据库缓存等等，合理利用这些缓存则能大幅度的提高系统性能， 利用不好反而会偷鸡不成蚀把米，给服务器造成巨大的压力，所以这里就存在一个缓存的使用原则的问题。 二：合理的使用缓存 1. 读写小于10:1的情况下，不适合用缓存，我们用缓存的目的就是想分摊下数据库的压力以及利用内存来提速性能，如果读写差不多，或者 压根就没读过，这样的死数据就会造成内存资源的浪费。 2. 既然是缓存，就注定了它的资源是有限的，宝贵的，也就注定了我们必须合理利用它的内存空间，也就被迫的让我们清楚的认识到热点数据， 　 不易修改的应该放在缓存，反之不宜放。 3. 大公司在缓存方面做的好的地方就是在一个“控”字上，他们会为缓存专门做一套“缓存系统”，当系统预加载的时候，同时也充当内存数据库 使用，将这些元数据加载到缓存系统中，比如“县市区”，“分类信息”等等作为预热数据。 三：分布式缓存 一般情况下，会有两种形式

一、docker容器与传统虚拟机的区别 docker是在操作系统层面实现虚拟化，直接复用本地主机的操作系统，而传统虚拟机是在硬件层面实现虚拟化。 二、docker基于C/S架构 镜像是构建docker的基石，用户需要通过镜像来运行自己的容器。 Registry用来保存用户构建的镜像，分为公有和私有（https://hub.docker.com) 三、docker的安装 -sudo yum update -sudo yum install -y yum-utils device-mapper-persistent-data lvm2 -sudo yum install docker-ce -docker -v 查看一下docker版本 docker服务器的开启与关闭 镜像操作 -docker images 查看所有镜像 -docker pull 镜像名称 下载镜像 -docker rmi 镜像ID 删除镜像 容器相关命令 -docker ps 查看正在运行的容器 -docker ps –a - docker run -id --name=testscentos7 centos:7 启动容器 -docker exec -it 容器名称 (或者容器ID) /bin/bash 登录容器 -docker stop 容器名称（或者容器ID） -docker start 容器名称（或者容器ID）

1、什么是Redis？ Redis本质上是一个Key-Value类型的内存数据库，很像memcached，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过 10万次读写操作，是已知性能最快的Key-Value DB。 Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存多种数据结构，此外单个value的最大限制是1GB，不像 memcached只能保存1MB的数据，因此Redis可以用来实现很多有用的功能，比方说用他的List来做FIFO双向链表，实现一个轻量级的高性 能消息队列服务，用他的Set可以做高性能的tag系统等等。另外Redis也可以对存入的Key-Value设置expire时间，因此也可以被当作一 个功能加强版的memcached来用。 Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。 2、Redis相比memcached有哪些优势？ (1) memcached所有的值均是简单的字符串，redis作为其替代者， 支持更为丰富的数据类型 (2) redis的速度比memcached快很多 (3) redis可以持久化其数据 3、Redis支持哪几种数据类型

1、缓存穿透 缓存穿透是指查询一个一定不存在的数据，由于缓存中没有这个数据，所以会去查询数据库，但是数据库也没有这条数据，并且处于容错考虑，我们没有将这次查询的null写入缓存，这将导致每次请求这条数据都需要查询数据库，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。 解决： 空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。 2、缓存雪崩 缓存雪崩是缓存中的数据在同一时间过期(即我们设置了相同的过期时间)，导致缓存在某一时刻同时失效，恰好此时这条数据被超级多的请求访问，那么这些请求全部转发到DB，DB瞬时压力过重雪崩。 解决： 原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。 3、缓存击穿 假设在我们的缓存中存放着一条非常"热点"的数据，它被多个线程超级频繁的访问。但是在那么一个时间点，它过期了，那么会发生什么了？大量的请求打进了数据库，瞬间造成数据库压力过大，极有可能数据库就这样宕掉了。这种 单个热点 的数据失效，我们把它称为缓存击穿；而如果是 大面积 的数据失效，我们则称它为缓存雪崩。 解决： 分布式锁（这是个什么玩意？） 4、分布式锁 上面记录到：一条热点数据在被多个线程高频访问的时候失效了

转载;https://www.cnblogs.com/bill-shooting/archive/2018/07/21/9347441.html 1. 传统的HTTP浏览器缓存策略 在一个网页的生命周期中，开发者为了缩短用户打开页面的时间，通常会设置很多缓存。其中包括了： 浏览器缓存 代理服务器缓存（CDN缓存） 服务器缓存 数据库缓存 等各种缓存。这些缓存大多数和前端没什么关系，也不由前端开发者控制，其中和前端较为密切的是 浏览器缓存 ，但它本质上也是由服务器控制的。 在Service Worker还未问世之前，浏览器缓存主要是由HTTP缓存策略和浏览器内置的存储功能（cookie，Local Storage，Session Storage等）来提供。其中HTTP缓存由于是钦定的，根正苗红，浏览器支持的也很好，是最常用的浏览器缓存技术。而通过浏览器内置存储功能来实现缓存，相比之下就没那么高端大气上档次了。因为这种方式没个标准范式，虽说可以通过JS进行控制显得比HTTP缓存灵活，但效果嘛就只能依赖程序员的水平了，也没有个统一的轮子能用，所以这种方式也就是小打小闹，不成气候。 下面介绍一下HTTP缓存的一些用法： Expires头部 早在HTTP协议被设计的时候，协议的起草者们就想到了缓存的事情，自然也有相应的功能，那就是 Expires 这个头部。每当浏览器请求时

71，谈谈你对Struts的理解。 1. struts是一个按MVC模式设计的Web层框架，其实它就是一个Servlet，这个Servlet名为ActionServlet，或是ActionServlet的子类。我们可以在web.xml文件中将符合某种特征的所有请求交给这个Servlet处理，这个Servlet再参照一个配置文件将各个请求分别分配给不同的action去处理。 (struts的配置文件可以有多个，可以按模块配置各自的配置文件，这样可以防止配置文件的过度膨胀) 2.ActionServlet把请求交给action去处理之前，会将请求参数封装成一个formbean对象（就是一个java类，这个类中的每个属性对应一个请求参数）， 3.要说明的是， ActionServlet把formbean对象传递给action的execute方法之前，可能会调用formbean的validate方法进行校验，只有校验通过后才将这个formbean对象传递给action的execute方法，否则，它将返回一个错误页面，这个错误页面由input属性指定。 4.action执行完后要返回显示的结果视图，这个结果视图是用一个ActionForward对象来表示的，actionForward对象通过struts-config.xml配置文件中的配置关联到某个jsp页面

1、 什么是 redis? Redis 是一个基于内存的高性能key-value数据库。 2、 使用 redis的好处？ 速度快，因为数据存在内存，类似 hashmap，hashmap的优势就是查找和操作的时间复杂度都时O(1) 支持丰富的数据类型，支持 string\list\set\sorted set\hash 支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行 丰富的特性：可用于缓存，消息，按 key设置过期时间，过期后会自动删除 3、redis常见性能问题考核解决方案？ master最好不要做任何持久化工作，如rdb内存快照和AOF日志文件 如果数据比较重要，某个 slave开启aof备份数据，策略设置为每秒同步一次 为了主从复制的速度和连接的稳定性， Master和Slave最好在同一个局域网内 尽量避免在压力很大的主库上增加从库 主从复制不要用图状结构，用单向链表结构更为稳定，即： Master <- Slave1 <- Slave2 <- Slave3… 这样的结构方便解决单点故障问题，实现 Slave对Master的替换。如果Master挂了，可以立刻启用Slave1做Master，其他不变。 来源： https://www.cnblogs.com/lingboweifu/p/11912087.html

概述 互联网应用发展到今天，从单体应用架构到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

本文提供了URL重写模块的概述，并解释了该模块使用的配置概念。 功能概述 URL重写模块将请求URL重写为显示给用户或Web应用程序的简单，用户友好和搜索引擎友好的地址。URL重写使用定义的规则进行评估，然后将请求URL映射到规则中定义的地址，然后再由IIS Web服务器对其进行处理。您可以定义包括正则表达式和通配符的URL重写逻辑，并且可以基于请求URL，HTTP标头和服务器变量来应用规则。该模块的主要目的是将请求URL重写为更友好的URL，但是您也可以使用该模块来定义执行重定向，发送自定义响应或中止请求的规则。 重写规则概述 重写规则定义了将请求URL与之进行比较或匹配的逻辑，以及在比较成功后该怎么做的逻辑。 重写规则包括以下部分： 模式 –规则模式用于指定用于匹配URL字符串的正则表达式或通配符模式。 条件 –可选条件集合用于指定URL字符串与规则模式匹配时要执行的其他逻辑操作。在这些条件下，您可以检查HTTP标头或服务器变量的某些值，或验证请求的URL是否对应于物理文件系统上的文件或目录。 动作 –动作用于指定如果URL字符串与规则模式匹配且所有规则条件均得到满足，该怎么办。 重写规则范围 可以在两个不同的集合中定义重写规则： <globalRules>–此集合中的规则只能在服务器级别上定义。全局规则用于定义服务器范围的URL重写逻辑

本文首发于： https://mp.weixin.qq.com/s/WVUGWuNrGoyY_7aDf7NNmA 微信公众号：后端技术指南针 0.前言 通俗讲持久化就是将内存中的数据写入非易失介质中，比如机械磁盘和SSD。 在服务器发生宕机时，作为内存数据库Redis里的所有数据将会丢失， 因此Redis提供了持久化两大利器：RDB和AOF。 1 RDB:Redis Dump Binary #全量二进制导出 2 AOF: Append-Only File #增量文件追加 RDB 将数据库快照以二进制的方式保存到磁盘中。 AOF 以协议文本方式，将所有对数据库进行过写入的命令和参数记录到 AOF 文件，从而记录数据库状态。 1.RDB的配置 查看RDB配置 1 [redis@abc]$ cat /abc/redis/conf/redis.conf 2 save 900 1 3 save 300 10 4 save 60 10000 5 dbfilename "dump.rdb" 6 dir "/data/dbs/redis/rdbstro" 上图为Redis配置文件里默认的RDB设置： 前三行都是对触发RDB的一个条件， 如第一行表示每900秒钟有一条数据被修改则触发RDB，依次类推；只要一条满足就会进行RDB持久化；