缓存服务器

服务器两次被入侵，导致我一切推倒重来，在重新配置的过程，总结下安装经验 如果需要安装包，可以留言，这次重新安装配置后都有存下来 数据库的配置 tomcat及JDK的配置 zookeeper的配置及dubbo可视化界面（未更新） fastDfs分布式文件系统服务器（用于上传配置） 在Storage上安装nginx配置图片服务虚拟主机(用于下载) redis缓存服务器安装及jedis集成使用（未更新） solr搜索应用服务器安装配置及集成使用（未更新） 来源： CSDN 作者： 陈晨* 链接： https://blog.csdn.net/weixin_41998993/article/details/104626212

Redis做为单机缓存使用建议 前言 由于原来项目使用的缓存中间件无法在国产麒麟操作系统里面使用，准备在项目中引入redis做为单机缓存。 配置优化建议 配置redis服务以守护进程启动 Redis默认不是以守护进程的方式运行，可以通过将配置项daemonize修改为yes，这样启动redis-server后会自动在后台运行。 安全配置 将bind配置为127.0.0.1可以避免redis受外部攻击。另外使用requirepass配置项，可以设置访问redis服务器数据时先要输入密码。 一个小遗憾是redis只支持在配置文件中使用明文保存访问密码，这里提供一个动态生成配置文件的思路增加安全性： 首先将redis.conf备份成redis.conf.tml，在里面的requirepass配置好密码密文。 在启动redis服务前使用其它程序读取redis.conf.tml的requirepass配置项，把密文解密，替换requirepass值生成redis配置文件redis.conf.，启动redis服务后把redis.conf删除，这样就达到保密效果。 设置最大内存及内存淘汰策略 为避免redis占用内存无限膨胀，导致把系统内存耗尽，建议将maxmemory设置为1024mb。（实际用ps命令查看，会发现redis-server最多会使用比maxmemory多一些的内存）

＃================================================= ================== ＃COMMON SPRING BOOT PROPERTIES ＃============================================== ===================== ＃---------------------------------------- ＃核心属性 ＃----- ----------------------------------- debug = false ＃启用调试日志。 trace = false ＃启用跟踪日志。 ＃LOGGING logging.config = ＃日志配置文件的位置。例如，Logback的`classpath：logback.xml`。 logging.exception-conversion-word =％wEx ＃记录异常时使用的转换字。 logging.file = ＃日志文件名（例如`myapp.log`）。名称可以是确切的位置或相对于当前目录。 logging.file.max-history = 0 ＃要保留的归档日志文件的最大数量。仅支持默认的登录设置。 logging.file.max-size = 10MB ＃最大日志文件大小。仅支持默认的登录设置。

一、什么是HTTP？ Hypertext Transfer Protocol（HTTP）协议（RFC7230） 一种无状态的、应用层、以请求/应答方式运行的协议，它使用可扩展的语义和自描述消息格式，与基于网络的超文本信息系统灵活的互动。 二、HTTP请求行与响应行 请求行格式（ABNF方式描述） Request-line = method SP request-target SP HTTP-version CRLF HTTP常见方法（RFC7231） GET：主要的获取信息方法，大量的性能优化都针对该方法，幂等方法 HEAD：类似GET方法，但服务器不发送BODY，用以获取HEAD元数据，幂等方法 POST：常用于提交HTML FORM表单、新增资源等 PUT：更新资源，带条件时是幂等方法 DELETE：删除资源，幂等方法 CONNECT：建立tunnel隧道 OPTIONS：显示服务器对访问资源支持的方法，幂等方法 TRACE：回显服务器收到的请求，用于定位问题。有安全风险 Request-target origin-form：后端请求资源的路径，为空时传递/ absolute-form：用于正向代理 authority-form：用于CONNECT方法 asterisk-form：用于OPTIONS方法 HTTP-version 版本号发展历史 HTTP/0.9：只支持GET

1 问题引入： a) 域名劫持： dns过程中某个环节被攻击/篡改，导致dns结果为劫持者的服务器。例如竞争对手将你方的app下载地址篡改为他方的app下载地址。 b) 对现网用户进行监控时，发现个别用户请求时间为几十秒，而客户端设置的connectTimeout时间为二十秒。 原因：初步判断为dns解析时间耗时过长导致整个接口请求时间远远超过了10s。 解决办法： 自定义dns，设置超时时间。 （使用的的是OkHttp，支持自定义dns） c) 测试环境dns几十秒，现网正常 原因： 旧的代码里面对url解析为host有bug，当传入一个测试环境地址，例如 10.10.10.10:6026/path,最终解析出来的host为10.10.10.10:6026， 当调用系统的InetAddress.getAllByName("10.10.10.10:6026")，耗时非常长（几十秒） 分析： 首先10.10.10.10:6026不是一个host地址也不是一个ip地址，所以dns是无法解析的。 方法内部会把它当成一个host在到不同的dns服务器上去查找它的ip，最后返回失败。 解决办法： 使用InetAddress中提供的方法来获取host，拒绝自己实现一套 d) no route to host 2 dns过程介绍 2.1 什么是dns DNS （Domain Name

剧情介绍 在传统的信息系统（比如小规模的ERP\MES系统），往往只是进行简单的应用服务器和数据库服务器的分布式部署，以此来提高应用系统的负载能力，而伴随着访问的增大，应用服务器层面除了做硬件和网络的扩容，很难应对【套路式开头】。 当然现在开源技术很多，不就是分布式么，应用服务器分布式、数据库读写分离、缓存服务器、认证服务器。的确方法很多。 那么不买关子了，今天就应用服务器层面的负载均衡讲讲，可以动手练练的技术： Nginx ，当然也包括缓存技术： redis 。 初步的设想是这样的：通过nginx对局域网内多个相同应用服务器进行进行负载均衡，并且各个相同应用共享一个缓存服务器【表达的就是这么简单】。拉个效果图： 开始搭建【折腾】 1、操作系统准备 linux一台，当然一般为虚拟机，这里我安装了centos7,配置ip地址为：192.168.110.100，机器名就叫：centos。 可以运行asp.net mvc站点windows一台，比如windows10+iis8，配置ip地址为：192.168.110.1，机器名无所谓。 配置两台机器的hosts: windows：C:\Windows\system32\drivers\etc\hosts 192.168.110.100　　cluster.com centos: vim /etc/hosts 192.168.110.100　

每一次网络请求都是一个Request，Request是对url,method,header,body的封装，也是对Http协议中请求行,请求头,实体内容的封装 1 public final class Request { 2 private final HttpUrl url; 3 private final String method; 4 private final Headers headers; 5 private final RequestBody body; 6 private final Object tag; 7 8 private volatile CacheControl cacheControl; // Lazily initialized. 1.HttpUrl HttpUrl主要用来规范普通的url连接，并且解析url的组成部分 现通过下面的例子来示例httpUrl的使用 https://www.google.com/search?q=maplejaw ①使用parse解析url字符串： HttpUrl url = HttpUrl.parse("https://www.google.com/search?q=maplejaw"); ②通过构造者模式来常见: 1 HttpUrl url = new HttpUrl.Builder() 2 .scheme(

单独拎出来的缓存问题，http的缓存 前后端的http交互中，使用缓存能很大程度上的提升效率，而且基本上对性能有要求的前端项目都是必用缓存的。 强缓存与弱缓存 缓存可以简单的划分成两种类型： 强缓存 （ 200 from cache ）与 协商缓存 （ 304 ）。 区别简述如下： 强缓存（ 200 from cache ）时，浏览器如果判断本地缓存未过期，就直接使用，无需发起http请求 协商缓存（ 304 ）时，浏览器会向服务端发起http请求，然后服务端告诉浏览器文件未改变，让浏览器使用本地缓存 对于协商缓存，使用 Ctrl + F5 强制刷新可以使得缓存无效。但是对于强缓存，在未过期时，必须更新资源路径才能发起新的请求（更改了路径相当于是另一个资源了，这也是前端工程化中常用到的技巧）。 缓存头部简述 上述提到了强缓存和协商缓存，那它们是怎么区分的呢？答案是通过不同的http头部控制。 先看下这几个头部： If - None - Match / E - tag 、 If - Modified - Since / Last - Modified 、 Cache - Control / Max - Age 、 Pragma / Expires 这些就是缓存中常用到的头部，这里不展开。仅列举下大致使用。 属于强缓存控制的： （ http1 . 1 ） Cache - Control

HTTP缓存是个大公司面试几乎必考的问题，写篇随笔说一下HTTP缓存。 1. HTTP报文首部中有关缓存的字段 在HTTP报文中，与缓存相关的信息都存在首部里，简单说一下首部。 首部 HTTP首部字段向请求报文和相应报文中添加了一些附加信息。本质上来说，它们只是一些键值对的列表。比如，下面的首部行会向Content-Length首部字段赋值19: Content-Length: 19 HTTP规范定义了几中首部字段。应用程序也可以随意发明自己所用的首部。HTTP首部可以分为以下几类： 通用首部 既可以出现在请求报文中，也可以出现在响应报文中。 请求首部 提供更多有关请求的信息。 响应首部 提供更多有关响应的信息。 实体首部 描述主体的长度和内容，或资源本身。 扩展首部 规范中没有定义的新首部。 想了解更多有关HTTP首部或报文的信息，个人推荐《HTTP权威指南》。 首部中与缓存有关的字段 通用首部字段 请求首部字段 响应首部字段 实体首部字段 2. 缓存的处理步骤 除了一些微小的细节，Web缓存的工作原理基本很简单，对一条HTTP GET报文的基本缓存处理过程包括7个步骤。 接收——缓存从网络中读取抵达的请求报文。 解析——缓存对报文解析，提取出URL和各种首部。 查询——缓存查看是否有本地副本可用，如果没有就向服务器获取一份副本，并将其保存在本地。 新鲜度检测—

背景: 在使用redis中,经常会遇到批量删除缓存的情况,但是对于在客户端中,如果一个一个的删除key,则需要较长时间及相对麻烦,可以使用以下命令,批量删除缓存. 本地批量删除KEY: ./redis-cli keys "被删除的KEY的前缀*" | xargs ./redis-cli del 示例代码: 批量删除KEY: 批量删除: ./redis-cli keys a2* | xargs ./redis-cli del 删除之后,只剩下a1的key,所有a2的数据都已经删除了. 远程删除KEY: 先登录其他缓存服务器: ./redis-cli -h 10.27.207.40 -p 6379 设置测试数据的缓存: 批量远程删除: ./redis-cli -h redis所在服务器ip -p 端口 keys "course-*" |xargs ./redis-cli -h redis所在服务器ip -p 端口 del 删除操作:删除成功,删除了9个数据 ./redis-cli -h 10.27.207.40 -p 6379 keys "test10*" |xargs ./redis-cli -h redis-cli -h 10.27.207.40 -p 6379 del 来源： https://www.cnblogs.com/lewisat/p/11155610.html