首页  思维导图  详情

后端Java知识指北

2022-09-23 15:02:04   99  举报





AI智能生成

为你推荐

查看更多



java

很全面的知识汇总

java

游戏

web

面试

netty

作者其他创作

大纲/内容

意义屏蔽各个硬件平台和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的内存访问效果

mat

http://spotify.github.io/threaddump-analyzer/

jconsole

VisualVM

gcviewer

GChisto

Jstat

jmap

jstack

jhat

GC分析

arthas

工具

-Xss 设置每个线程可使用的内存大小，即栈的大小。在相同物理内存下，减小这个值能生成更多的线程，当然操作系统对一个进程内的线程数还是有限制的，不能无限生成。线程栈的大小是个双刃剑，如果设置过小，可能会出现栈溢出，特别是在该线程内有递归、大的循环时出现溢出的可能性更大，如果该值设置过大，就有影响到创建栈的数量，如果是多线程的应用，就会出现内存溢出的错误。

-Xms 初始堆大小

-Xmx 最大堆大小

-Xmn 新生代大小

-XX:NewRatio:设置新生代和老年代的比值。如：为3，表示年轻代与老年代比值为1：3

-XX:SurvivorRatio:新生代中Eden区与两个Survivor区的比值。注意Survivor区有两个。如：为3，表示Eden：Survivor=3：2，一个Survivor区占整个新生代的1/5

-XX:MaxTenuringThreshold:设置转入老年代的存活次数。如果是0，则直接跳过新生代进入老年代

-XX:PermSize、-XX:MaxPermSize:分别设置永久代最小大小与最大大小（Java8以前）

-XX:MetaspaceSize、-XX:MaxMetaspaceSize:分别设置元空间最小大小与最大大小（Java8以后）

-XX:+UseSerialGC:设置串行收集器

-XX:+UseParallelGC:设置并行收集器

-XX:+UseParalledlOldGC:设置并行老年代收集器

-XX:+UseConcMarkSweepGC:设置并发收集器

-XX:+PrintGC

-XX:+PrintGCDetails

-XX:+PrintGCTimeStamps

-Xloggc:filename

-XX:ParallelGCThreads=n:设置并行收集器收集时使用的CPU数。并行收集线程数。

-XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间

-XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)

-XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。

-XX:ParallelGCThreads=n:设置并发收集器新生代收集方式为并行收集时，使用的CPU数。并行收集线程数。

-XX:PermSize设置非堆内存初始值，默认是物理内存的1/64；

XX:MaxPermSize设置最大非堆内存的大小，默认是物理内存的1/4。

参数

默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制；空余堆内存大于70%时，JVM会减少堆直到 -Xms的最小限制。堆设置因此服务器一般设置-Xms、-Xmx相等以避免在每次GC 后调整堆的大小。对象的堆内存由称为垃圾回收器的自动内存管理系统回收。

垃圾回收统计信息

并行收集器设置

并发收集器设置

非堆内存分配

并行收集器

https://developer.ibm.com/zh/articles/j-lo-jvm-optimize-experience/

https://www.javazhiyin.com/51851.html

例子

实践

参数控制：-XX:+UseSerialGC 串行收集器

串行收集器单线程

新生代、老年代使用串行回收；

新生代复制算法、老年代标记-压缩

垃圾收集的过程中会Stop The World（服务暂停）

Serial

-XX:+UseParNewGC ParNew收集器

-XX:ParallelGCThreads 限制线程数量

Serial收集器的多线程版本，

控制参数、收集算法、回收策略等等和Serial收集器完全一样。

PraNew

参数控制：-XX:+UseParallelGC

-XX:+UseAdaptiveSizePolicy 这是一个开关参数，打开参数后，就不需要手工指定细节参数

类似ParNew收集器

Parallel收集器更关注系统的吞吐量。

可以通过参数来打开自适应调节策略，

也可以通过参数控制GC的时间不大于多少毫秒或者比例；

Parallel Scavenge

一个单线程的老年代版本收集器

一种是在JDK1.5及以前的版本中和Parallel Scavenge收集器搭配使用

Serial Old

参数控制： -XX:+UseParallelOldGC 使用Parallel收集器+ 老年代并行

Parallel Old是Parallel Scavenge收集器的老年代版本

使用多线程和“标记－整理”算法。

Parallel Old

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器，它非常符合那些集中在互联网站或者B/S系统的服务端上的Java应用，这些应用都非常重视服务的响应速度。从名字上（“Mark Sweep”）就可以看出它是基于“标记-清除”算法实现的。

针对老年代的回收

初始标记（CMS initial mark）：仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，需要“Stop The World”。

并发标记（CMS concurrent mark）：进行GC Roots Tracing的过程，在整个过程中耗时最长。

重新标记（CMS remark）：为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。此阶段也需要“Stop The World”。

并发清除（CMS concurrent sweep）

[

整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作

并发收集、低停顿，因此CMS收集器也被称为并发低停顿收集器（Concurrent Low Pause Collector）。

优点

对CPU资源非常敏感其实，面向并发设计的程序都对CPU资源比较敏感。在并发阶段，它虽然不会导致用户线程停顿，但会因为占用了一部分线程（或者说CPU资源）而导致应用程序变慢，总吞吐量会降低。CMS默认启动的回收线程数是（CPU数量+3）/4，也就是当CPU在4个以上时，并发回收时垃圾收集线程不少于25%的CPU资源，并且随着CPU数量的增加而下降。但是当CPU不足4个时（比如2个），CMS对用户程序的影响就可能变得很大，如果本来CPU负载就比较大，还要分出一半的运算能力去执行收集器线程，就可能导致用户程序的执行速度忽然降低了50%，其实也让人无法接受。

无法处理浮动垃圾（Floating Garbage）可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生。这一部分垃圾出现在标记过程之后，CMS无法再当次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾就被称为“浮动垃圾”。也是由于在垃圾收集阶段用户线程还需要运行，那也就还需要预留有足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。

标记-清除算法导致的空间碎片 CMS是一款基于“标记-清除”算法实现的收集器，这意味着收集结束时会有大量空间碎片产生。空间碎片过多时，将会给大对象分配带来很大麻烦，往往出现老年代空间剩余，但无法找到足够大连续空间来分配当前对象。

如果对象分配率高于CMS回收的效率，将导致在CMS完成之前老年代就被填满，这种状况成为“并发模式失败”，同样也会引起full GC。可以调节-XX:CMSInitiatingOccupancyFraction和新生代的堆大小。

缺点

-XX:+UseConcMarkSweepGC - 启用CMS，同时-XX:+UseParNewGC会被自动打开。

-XX:CMSInitiatingOccupancyFraction - 设置第一次启动CMS的阈值，默认是68%。

-XX:+UseCMSInitiatingOccupancyOnly - 只是用设定的回收阈值，如果不指定，JVM仅在第一次使用设定值，后续则自动调整。

-XX:+CMSPermGenSweepingEnabled - 回收perm区。

-XX:+CMSClassUnloadingEnabled - 相对于并行收集器，CMS收集器默认不会对永久代进行垃圾回收（在1.7中是默认关闭，但是在1.8中是默认打开的）。如果希望对永久代进行垃圾回收，则可以打开此标志，同时打开-XX:+CMSPermGenSweepingEnabled 92%默认值。

-XX:+CMSConcurrentMTEnabled - 并发的CMS阶段将会启动多个GC线程和其他线程并发工作，默认为true。

-XX:+UseCMSCompactAtFullCollection - 在full GC的时候进行整理(mark sweep compact)，默认为true。

-XX:+CMSFullGCsBeforeCompaction - 在上一次CMS并发GC执行过后，到底还要再执行多少次**full GC**（注意不是CMS GC）才会做压缩，默认是0。如果增大这个参数，会使full GC更少做压缩，但也就更容易使CMS的老年代受碎片化问题的困扰。本来这个参数就是用来配置降低full GC压缩的频率，以期减少某些full GC的暂停时间。CMS回退到full GC时用的算法是mark-sweep-compact，但compaction是可选的，不做的话碎片化会严重些但这次full GC的暂停时间会短些，这是个取舍。

-XX:+CMSParallelRemarkEnabled - 并行remark，以减少remark的等待时间。默认为true。

-XX:+CMSScavengeBeforeRemark - 强制remark之前开始一次minor GC，可以减少remark的等待时间，因为老生代的对象有的会依赖于新生代的对象，当增加了这个命令时会在remark之前执行一次minor GC的操作，从而可以减少老生代到新生代的可到达对象数。默认为false。

相关配置

Eureka安全机制

HA 高可用

4.Eureka服务注册与发现

SpringCloud系列五：Ribbon 负载均衡（Ribbon 基本使用、Ribbon 负载均衡、自定义 Ribbon 配置、禁用 Eureka 实现 Ribbon 调用）

Ribbon基本使用

负载均衡的实现

全局路由

单服务路由

提供方的信息获取

自定义Ribbon路由

脱离Eureka使用Ribbon

5.Ribbon负载均衡

SpringCloud系列六：Feign接口转换调用服务（Feign 基本使用、Feign 相关配置）

Feign基本使用

数据压缩

日志配置

6.Feign接口服务

SpringCloud系列七：Hystrix 熔断机制（Hystrix基本配置、服务降级、HystrixDashboard服务监控、Turbine聚合监控）

服务的雪崩

服务提供方熔断

服务消费方降级

HystrixDashboard

turbine

7.Hystrix 熔断机制

SpringCloud系列八：Zuul 路由访问（Zuul 的基本使用、Zuul 路由功能、zuul 过滤访问、Zuul 服务降级）

zuul基本使用

路由配置

过滤访问

安全访问

Feign集成

zuul降级

8.zuul路由

SpringCloud系列九：SpringCloudConfig 基础配置（SpringCloudConfig 的基本概念、配置 SpringCloudConfig 服务端、抓取配置文件信息、客户端使用 SpringCloudConfig 进行配置、单仓库目录匹配、应用仓库自动选择、仓库匹配模式）

架构流程

github账号

配置中心搭建

客户端读取配置

配置中心实战

config高可用

SpringCloudBus简介

基于SpringCloudBus实现自动刷新

自动刷新

9.Config 分布式配置中心

基本概念

RabbitMq集成

Stream的生产者

Stream的消费者

自定义通道

分组

RoutingKey设置

10.SpringCloudStream 消息驱动

SpringCloud系列十二：SpringCloudSleuth（SpringCloudSleuth 简介、SpringCloudSleuth 基本配置、数据采集）

跟踪服务

客户端配置

rabbitmq收集器

mysql存储器

数据持久化

11.SpringCloudSleuth 链路跟踪

Springboot实现发送邮箱

springCloud定时邮件发送

邮件发送

12.springCloud中常用技术

TestApplication.java

TestApplication上的注解

springcloud中常用的注解@

springcloud中常用注解

@Autowired和@Resource的区别

springCloud常用注解解释

Spring @Configuration注解

@Configuration的使用

@Configuration注解探索

实现动态添加到spring容器

environmentaware接口实现环境变量读取和属性对象的绑定

EnvironmentAware

DubboRegistryBeansDefinitionRegistryPostProcessor.java

Spring基础-BeanDefinitionRegistryPostProcessor实现动态添加到spring容器

BeanDefinitionRegistryPostProcessor探索

BeanDefinitionRegistryPostProcessor注册bean

注解下的其他技术

改变bean的定义(BeanFactoryPostProcessor接口)

BeanFactoryPostProcessor

@ConfigurationProperties和@EnableConfigurationProperties配合使用

在Spring Boot中使用 @ConfigurationProperties 注解 @EnableConfigurationProperties

@EnableConfigurationProperties注解探索

@EnableConfigurationProperties

ConditionalOnProperty

@ConditionalOnProperty注解探索

DubboProperties.java

@ConfigurationProperties注解实例文件

@ConfigurationProperties 注解

@ConfigurationProperties注解探索

@ConfigurationProperties

DubboAutoConfiguration.java

@ConditionalOnClass的使用探索

@ConditionalOnClass注解探索

@ConditionalOnMissingClass注解探索

@ConditionalOnMissingClass

spring @Primary-在spring中的使用

@Primary注解探索

@ConditionalOnMissingBean注解源码分析与示例

配置是否初始化Bean的方法

@ConditionalOnMissingBean注解探索

@ConditionalOnMissingBean

@ConditionalOnBean、@ConditionalOnMissingBean注解源码分析与示例

@ConditionalOnBean注解探索

@ConditionalOnBean

RestTemplateAutoConfiguration.java

@AutoConfigureAfter注解解析

@AutoConfigureAfter注解探索

@AutoConfigureAfter

@NestedConfigurationProperty

配置文件注解

Dubbo SPI 之 @Activate注解使用和实现解析

ActiveLimitForServerFilter.java

@Activate

过滤器注册

springCloud的各种注解

springCloud本身的注解

Java开发之@PostConstruct和@PreConstruct注解

@PostConstruct和@PreConstruct注解

java规范的注解

13.springCloud中注解探索

SpringBoot-事件监听的4种实现方式

14.springCloud监听器探索

15.springCloud过滤器探索

16.springCloud拦截器探索

第一种方法在多个文件中配置

第一种:在多个文件中配置

在一个文件中配置

第二种:在一个文件中配置

第三种:在pom文件中配置

springCloud切换环境

ServerApp.java

服务端主启动类

application.yml

yml文件配置

Server服务端源码

Police.java

PoliceController.java

PoliceServer.java

Client服务提供者源码

PersonServer.java

TestController.java

Client服务调用者源码

单体Eureka的整合

集群Eureka的整合

springCloud整合Eureka

springCloud整合Ribbon

springCloud整合Feign (服务调用)

springCloud整合Hystrix

springCloud整合Zuul

融合springCloud与dubbo无缝替换

Spring Cloud与Dubbo共存方案总结

Springboot dubbo的整合以及与springcloud fein的对比

springCloud整合dubbo教程

Spring Cloud Feign使用详解

springCloud整合Feign

项目源码(不理解)

利用SpringCloud Sleuth和Zipkin实现调用链跟踪（一）

Zipkin实现服务调用链跟踪

17.springCloud整合框架

分布式session一致性

分布式全局Id生产方案

分布式事务问题解决

分布式任务调度平台

分布式配置中心

分布式锁方案解决

分布式日志收集系统

网站跨域问题解决

分布式限流方案

手写微服务事务解决框架

分布式解决的问题

Dubbo的底层原理

Dubbo源代码实现一：切入Spring

Dubbo源代码实现二：服务调用的动态代理和负载均衡

dubbo的工作原理

Dubbo源码解析

Dubbo实现源码分析

深入理解dubbo之服务发布源码分析

深入理解dubbo之服务引用

Dubbo RPC源码解读

dubbo源码解析-服务暴露原理

dubbo服务端处理请求源码分析

dubbo的源码

dubbo源码探索

maven+springmvc+dubbo+zookeeper

dubbo与spring整合

Springboot 整合 Dubbo/ZooKeeper 详解

dubbo与springboot整合

dubbo的环境搭建

Dubbo学习小记

Dubbo的使用探索

spring cloud和dubbo的区别

cloud/dubbo对比

融合spring cloud与dubbo 无缝替换spring cloud微服务间调用协议

Spring Cloud+Dubbo对Feign进行RPC改造

dubbo与spring cloud

dubbo支持哪些序列化协议

hessian的数据结构

为什么PB的效率是最高的

dubbo四种负载均衡策略

dubbo负载均衡策略和高可用策略都有哪些？动态代理策略呢？

dubbo的spi思想是什么

如何基于dubbo进行服务治理、服务降级、失败重试以及超时重试

分布式服务接口的幂等性如何设计（比如不能重复扣款）

分布式服务接口请求的顺序性如何保证

如何自己设计一个类似dubbo的rpc框架

dubbo的面试探索

dubbo系统调用接口

常见轮子

SpringCloud

SpringBoot优化内嵌的Tomcat ---设置MaxConnections

Tomcat开启APR运行模式，优化并发性能

Springboot Tomcat APR模式详解和实践

springboot 内嵌tomcat APR 模式

springboot 2.X后内置tomcat自定义配置

Tomcat

Jetty

Serverlet容器

Shiro 认证流程分析

Shiro认证流程和授权流程

思路清晰易懂(推荐)

shiro登录认证过程讲解

认证流程解析

授权源码解析

授权流程解析

Shiro认证授权流程网络教程

shiro权限流程原理

配置记住我

统计在线人数

session管理

取消url上面的JSESSIONID

同一用户并发登录限制

登录失败次数限制

实现验证码认证

实现自己的登出

springboot整合shiro系列教程

github地址

管理shiro一些bean的生命周期

LifecycleBeanPostProcessor getLifecycleBeanPostProcessor()

配置ShiroDialect，用于thymeleaf和shiro标签配合使用

ShiroDialect shiroDialect()

AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token)

AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principalCollection)

void clearUserAuthByUserId(List<Integer> userIds)

MyShiroRealm extends AuthorizingRealm

MyShiroRealm myShiroRealm = new MyShiroRealm();

hashedCredentialsMatcher.setHashAlgorithmName("md5");//散列算法:这里使用MD5算法;

hashedCredentialsMatcher.setHashIterations(2);//散列的次数，比如散列两次，相当于 md5(md5(""));

HashedCredentialsMatcher hashedCredentialsMatcher()

myShiroRealm.setCredentialsMatcher(hashedCredentialsMatcher());

MyShiroRealm myShiroRealm()

securityManager.setRealm(myShiroRealm())

RedisManager redisManager()

redisCacheManager.setRedisManager(redisManager());

RedisCacheManager cacheManager()

securityManager.setCacheManager(cacheManager());

redisSessionDAO.setRedisManager(redisManager());

RedisSessionDAO redisSessionDAO()

sessionManager.setSessionDAO(redisSessionDAO());

DefaultWebSessionManager sessionManager()

securityManager.setSessionManager(sessionManager());

SecurityManager securityManager()

shiroFilterFactoryBean.setSecurityManager(securityManager);

shiroFilterFactoryBean.setLoginUrl("/login");

shiroFilterFactoryBean.setSuccessUrl("/usersPage");

shiroFilterFactoryBean.setUnauthorizedUrl("/403");

shiroFilterFactoryBean.setFilterChainDefinitionMap(filterChainDefinitionMap);

ShiroFilterFactoryBean shiroFilter(SecurityManager securityManager)

开启shiro aop注解支持

AuthorizationAttributeSourceAdvisor authorizationAttributeSourceAdvisor(SecurityManager securityManager)

@Configuration ShiroConfig

认证授权流程

SpringBoot整合mybatis、shiro、redis细粒度动态权限管理系统实例

权限管理(项目和源码)系列教程

springboot、shiro、redis整合

SpringBoot整合shiro+jwt+redis - 无状态token登录

SpringBoot集成JWT实现token验证

springboot+shiro+jwt+redis无状态token登录

shiro权限控制实例

1.使用shiro的session管理

2.使用缓存读取session

shiro的权限控制

session管理，单点登录

菜单按钮权限管理

xss攻击原理及防范

网络攻击-XSS攻击详解

xss攻击讲解

XSS及CSRF攻击防御

CSRF的攻击和防范

DDOS 攻击的防范教程

常见web攻击方法及防御手段总结

XSS过滤JAVA过滤器filter 防止常见SQL注入

shiro整合防止攻击

shiro权限验证管理

59k8dcbq9m5m0i15blqpsu570u.jpg

shiro外部架构.jpg

shiro外部架构

Subject：应用代码直接交互的对象是 Subject

SecurityManager：安全管理器；即所有与安全有关的操作都会与SecurityManager 交互

Realm：Shiro 从 Realm 获取安全数据（如用户、角色、权限）

Shiro外部来看

0c5983qgc0186lpr842s6c31l0.jpg

shiro内部架构.jpg

shiro内部架构

Subject：任何可以与应用交互的“用户”；

SecurityManager ：相当于SpringMVC 中的 DispatcherServlet；是 Shiro 的心脏；

Authenticator：负责 Subject 认证，是一个扩展点，可以自定义实现；

Authorizer：授权器、即访问控制器，用来决定主体是否有权限进行相应的操作；

Realm：可以有 1 个或多个 Realm，可以认为是安全实体数据源，即用于获取安全实体的；

SessionManager：管理 Session 生命周期的组件；

用于代替SessionManager执行Session相关的增删改查。

SessionDAO

CacheManager：缓存控制器，来管理如用户、角色、权限等的缓存的；

Cryptography：密码模块，Shiro 提高了一些常见的加密组件用于如密码加密/解密。

shiro的内外部架构

Authentication：身份认证/登录，验证用户是不是拥有相应的身份

Authorization：授权，即权限验证，验证某个已认证的用户是否拥有某个权限；

Session Manager：会话管理，即用户登录后就是一次会话，在没有退出之前，它的所有信息都在会话中；

Cryptography：加密，保护数据的安全性，如密码加密存储到数据库，而不是明文存储；

Web Support：Web 支持，可以非常容易的集成到Web 环境；

Caching：缓存，比如用户登录后，其用户信息、拥有的角色/权限不必每次去查，这样可以提高效率；

Concurrency：Shiro 支持多线程应用的并发验证，即如在一个线程中开启另一个线程，能把权限自动传播过去；

Testing：提供测试支持；

Run As：允许一个用户假装为另一个用户（如果他们允许）的身份进行访问；

Remember Me：记住我，这个是非常常见的功能，即一次登录后，下次再来的话不用登录了

shiro框架功能简介

shiro

https://blog.viakiba.cn/2020/07/14/protobuf-%E6%8E%A2%E7%9F%A5(%E4%B8%8A)/

https://blog.viakiba.cn/2020/07/14/protobuf-%E6%8E%A2%E7%9F%A5(%E4%B8%8B)/

Protobuf

大O表示法（渐进时间复杂度）：把程序的相对执行时间函数T(n)简化为一个数量级，这个数量级可以是n、n^2、logN等。推导时间复杂度的几个原则：如果运行时间是常数量级，则用常数1表示。只保留时间函数中的最高阶项。如果最高阶项存在，则省去最高项前面的系数。时间复杂度对比：O(1) > O(logn) > O(n) > O(nlogn) > O(n^2)。

计算方式

时间复杂度：运行时间长短。

常量空间 O(1)：存储空间大小固定，和输入规模没有直接的关系。线性空间 O(n)：分配的空间是一个线性的集合，并且集合大小和输入规模n成正比。二维空间 O(n^2)：分配的空间是一个二维数组集合，并且集合的长度和宽度都与输入规模n成正比。递归空间 O(logn)：递归是一个比较特殊的场景。虽然递归代码中并没有显式的声明变量或集合，但是计算机在执行程序时，会专门分配一块内存空间，用来存储“方法调用栈”。执行递归操作所需要的内存空间和递归的深度成正比。

空间复杂度：占用内存大小。

复杂度概念

kmp算法

字符串：暴力匹配、BM、KMP、Trie等。

查找：二分查找、遍历查找等。

排序：冒泡排序、快排、计数排序、堆排序等。

搜索：TFIDF、PageRank等。

聚类分析：期望最大化、k-meanings、k-数位等。

深度学习：深度信念网络、深度卷积神经网络、生成式对抗等。

异常检测：k最近邻、局部异常因子等。

hash算法及常用的hash算法

。。。。。。。

常见算法

读取O(1)、更新O(1)、插入O(n)、删除O(n)、扩容O(n)。

读取O(n)、更新O(1)、插入O(1)、删除O(1)。

链表

入栈O(1)、出栈O(1)。

栈

入队 O(1)、出队 O(1)。

队列

写入：O(1)、读取：O(1)、扩容O(n)。

不同的key通过哈希函数获得的下标有可能是相同的。

解决方式开放寻址法：例子Threadlocal。链表法：例子Hashmap。

哈希冲突

哈希表

树（tree）是n（n≥0）个节点的有限集。当n=0时，称为空树。在任意一个非空树中，有如下特点：有且仅有一个特定的称为根的节点。当n>1时，其余节点可分为m（m>0）个互不相交的有限集，每一个集合本身又是一个树，并称为根的子树。

定义

前序：根节点、左子树、右子树。

中序：左子树、根节点、右子树。

后序：左子树、右子树、根节点。

深度优先

层序：一层一层遍历。

广度优先

树的遍历

二叉树（binary tree）是树的一种特殊形式。二叉，顾名思义，这种树的每个节点最多有2个孩子节点。注意，这里是最多有2个，也可能只有1个，或者没有孩子节点。

一个二叉树的所有非叶子节点都存在左右孩子，并且所有叶子节点都在同一层级上，那么这个树就是满二叉树。

对一个有n个节点的二叉树，按层级顺序编号，则所有节点的编号为从1到n。如果这个树所有节点和同样深度的满二叉树的编号为从1到n的节点位置相同，则这个二叉树为完全二叉树。

二叉树

二叉查找树在二叉树的基础上增加了以下几个条件：如果左子树不为空，则左子树上所有节点的值均小于根节点的值。如果右子树不为空，则右子树上所有节点的值均大于根节点的值。左、右子树也都是二叉查找树。

作用查找==》二分查找。排序==》中序遍历。

实现方式链表。数组：对于稀疏二叉树来说，数组表示法是非常浪费空间的。

二叉查找树

二叉堆

B树、B-树、B+树、B*树

树

数据结构

https://www.cnblogs.com/onepixel/p/7674659.html

排序算法

算法与数据结构

定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。

可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；提高类的可读性，提高系统的可维护性；变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响

单一职责原则

所有引用基类的地方必须能透明地使用其子类的对象。

问题由来：有一功能P1，由类A完成。现需要将功能P1进行扩展，扩展后的功能为P，其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成，则子类B在完成新功能P2的同时，有可能会导致原有功能P1发生故障。解决方案：当使用继承时，遵循里氏替换原则。类B继承类A时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。

里氏替换原则

高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。

问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。

依赖倒置原则

客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。问题由来：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。

接口隔离原则

一个对象应该对其他对象保持最少的了解。

问题由来：类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。解决方案：尽量降低类与类之间的耦合。

迪米特法则

一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。

问题由来：在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。解决方案：当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

开闭原则

六大原则

频繁创建对象、管理对象是一件耗费资源的事，如果我们可以使用一个对象就可以完成功能了，那就使用单例模式吧！

使用静态类.doSomething()体现的是基于对象

 使用单例设计模式体现的是面向对象。

静态.doSomething和单例的区别

简单理解

构造函数私有化

在类的内部创建实例

提供方法获取该实例

编写单例模式步骤

直接在成员变量上new出实例，提供方法返回

饿汉式

等到调用方法的时候再创建对象，该方法需要加Synchronized锁

普通懒汉式

基于普通懒汉式的提升，普通懒汉式的效率太低了

1.使用volatile修饰我们的对象引用

2.外部if判断对象是否为null，为null往下执行，不为null直接返回对象

3.使用syn同步进入代码块，使用if判断对象是否为null，为null就创建对象

4.使用volatile修饰成员变量的原因就是防止重排序的问题--->变量还未完全初始化就被线程B返回了

双重检测机制(DCL)懒汉式

创建一个内部类，在内部类直接创建对象

外部类提供方法来获取内部类创建的对象

这种方式是非常方便和友好的，在外部调用的时候，内部类才会创建对象

 静态内部类懒汉式

省事，安全(枚举能够有效防止多次实例化的问题)

枚举

单例模式五种写法

单例模式

工厂模式就是让创建对象变得简单而且修改对象时能很方便

另一个方便就是体现在解耦

简单工厂模式

抽象工厂模式

工厂模式延伸了三类

1. 一个抽象工厂类

2. 多个实现工厂类

3. 外部通过工厂拿到对象

优缺点

工厂方法模式编写

1. 就一个实现工厂类，所有的对象交由该工厂类创建

2. 外部通过这个工厂类获取对象

就一个具体的工厂来创建对象，代码量少。

增加了对象就需要修改代码，麻烦

简单工厂模式编写

 在工厂方法模式下又多了一层抽象，减少了工厂的数量

衍生出了产品族和产品等级(无非就是将公有的功能抽象出来了)

减少了工厂的数据

难以扩展产品族，会修改非常多的类

 将每个算法都封装起来，并且使他们之间可以互换

上下文角色(Context)只是为了简化客户端调用，解耦

一个通用算法接口

多个实现类

一个上下文角色(Context)

策略模式要素

策略模式

 当前对象不愿意干的，没法干的东西委托给别的对象来做，我只要做好本分的东西就好了

在代理中内部直接new出被代理对象。此时使用代理对象对外界来说是透明的

透明代理

 代理对象拥有目标对象相同的方法【因为参数二指定了对象的接口，代理对象会实现接口的所有方法】用户调用代理对象的什么方法，都是在调用处理器的invoke方法。【被拦截】使用JDK动态代理必须要有接口【参数二需要接口】

所有通过动态代理实现的方法全部通过invoke()调用

使用JDK的API实现动态代理

如果没有接口的情况下，这种形式可以通过类来实现动态代理，生成的是子类代理

使用CGLib实现动态代理

动态代理 

需要自己实现接口下的所有方法

静态代理需要自己写代理类-->代理类需要实现与目标对象相同的接口

代理对象的生成，是利用JDKAPI，动态地在内存中构建代理对象(需要我们指定创建代理对象/目标对象实现的接口的类型)，并且会默认实现接口的全部方法。

动态代理和静态代理的区别

增强request对象实现中文过滤器

应用

代理模式

门面模式提供一个高层次的接口，使得子系统更易于使用

子系统就相当于电脑、冰箱、电视。统一的对象就相当于我们的电闸

一个高层次的接口

门面模式要素

门面模式

继承

包装模式

增强对象有三种方式

前提：继承的方式不容易扩展(写死)，如果类中带有信息也是不能用继承的方式的

于是我们就有包装设计模式给我们很方便的扩展

前提：拥有一个接口，一个默认实现类

动工：编写一个装饰器(抽象类)->实现接口->以组合的方式来接收默认实现类

使用：要扩展的时候，就继承上面编写的装饰器，定义自己想要扩展的功能

说白了就多了一层抽象，基于这层抽象来方便扩展

包装模式使用

IO流用得就很多了：BufferedReader bf = new BufferedReader(new FileReader(new File("aa.txt")));

定义一个操作中的算法框架，而将一些步骤延迟到子类中。

使子类可以不改变一个算法的结构即可重定义该算法的某些步骤

 定义了一个框架，实现对基本方法的调用，完成固定的逻辑。

抽象方法

在子类实现，并且在模板方法中被调用

基本方法

模板方法术语

一个抽象方法，供对外使用

多个基本方法(由子类实现)

模板方法要素

模板方法模式

常见模式

mysql -u用户名 -p密码

连接数据库

CREATE DATABASE [IF NOT EXISTS] 库名[DEFAULT] CHARACTER SET 字符名 | [DEFAULT] COLLATE 校对规则

创建库

SHOW DATABASES

SHOW CREATE DATABASE 库名【查看数据库创建时的详细信息】

查看库

DROP DATABASE [IF EXISTS] 库名

删除库

ALTER DATABASE [IF NOT EXISTS] 库名[DEFAULT] CHARACTER SET 字符名 | [DEFAULT] COLLATE 校对规则

修改库

mysqldump -u 用户名 -p 数据库名 > 文件名.sql【window命令】

Source 文件名.sql【在库下执行】

mysql -uroot -p mydb1> c:\\test.sql (window命令)

备份库中的数据和

对库的操作

CREATE TABLE 表名( 列名类型 )

增加表

ALTER TABLE 表名 ADD ( 列名数据类型 );

ALTER TABLE 表名 MODIFY( 列名数据类型 );

修改表

SHOW TABLES

SHOW CREATE TABLE 表名【查看表的创建细节】

DESC 表名【查看表的结构】

查看表

ALTER TABLE表名DROP(列名);

删除表

对表的操作

INSERT INTO 表名 ( 列名..)VALUES (数据..);

增加

修改

DELETE FROM 表名 WHERE=条件

TRUNCATE TABLE【先摧毁整张表，再创建表结构】

删除

查看

对表中数据操作

1.FROM

2.WHERE

3.GROUP BY

4. HAVING

5.SELECT

6.ORDER BY

SELECT子句执行顺序

AVG()

MAX()

MIN()

COUNT()

SUM()

聚集函数

%通配符，匹配0个或多个

_通配符，匹配单个字符

用LIKE操作符进行过滤

通配符检索数据

按位置、列名排序

按多个列排序

DESC降序

ASC升序【默认】

使用ORDER BY 排序数据

排序检索数据

使用HAVING过滤分组

WHERE过滤的是行数据

使用GROUP BY分组

分组数据

内连接(等值连接)【INNER JOIN】，使用ON子句消除笛卡尔积

FROM字句后边不止一个表，就叫联结

FROM子句跟着是两个相同的表叫自连接

联结表

创建CREATE [UNIQUE] INDEX indexName ON mytable(columnname(length));

更改ALTER mytable ADD [UNIQUE] INDEX [indexName] ON(columnname(length));

删除DROP INDEX [indexName] ON mytable;

查看一个表的索引信息show index from [tableName];

索引

触发器

/* 存储过程 */ ------------------存储过程是一段可执行性代码的集合。相比函数，更偏向于业务逻辑。调用：CALL 过程名-- 注意- 没有返回值。- 只能单独调用，不可夹杂在其他语句中-- 参数IN|OUT|INOUT 参数名数据类型IN 输入：在调用过程中，将数据输入到过程体内部的参数OUT 输出：在调用过程中，将过程体处理完的结果返回到客户端INOUT 输入输出：既可输入，也可输出-- 语法CREATE PROCEDURE 过程名 (参数列表)BEGIN 过程体END

存储过程

/* 用户和权限管理 */ -------------------- root密码重置1. 停止MySQL服务2. [Linux] /usr/local/mysql/bin/safe_mysqld --skip-grant-tables & [Windows] mysqld --skip-grant-tables3. use mysql;4. UPDATE `user` SET PASSWORD=PASSWORD(\"密码\") WHERE `user` = \"root\

用户和权限管理

三个范式

/* 备份与还原 */ ------------------备份，将数据的结构与表内数据保存起来。利用 mysqldump 指令完成。-- 导出mysqldump [options] db_name [tables]mysqldump [options] ---database DB1 [DB2 DB3...]mysqldump [options] --all--database1. 导出一张表　　mysqldump -u用户名 -p密码库名表名 > 文件名(D:/a.sql)2. 导出多张表　　mysqldump -u用户名 -p密码库名表1 表2 表3 > 文件名(D:/a.sql)3. 导出所有表　　mysqldump -u用户名 -p密码库名 > 文件名(D:/a.sql)4. 导出一个库　　mysqldump -u用户名 -p密码 --lock-all-tables --database 库名 > 文件名(D:/a.sql)可以-w携带WHERE条件-- 导入1. 在登录mysql的情况下：　　source 备份文件2. 在不登录的情况下　　mysql -u用户名 -p密码库名 < 备份文件

备份与还原

基本语法

在mysql中myisam不支持事务

事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用；

原子性

执行事务前后，数据保持一致，例如转账业务中，无论事务是否成功，转账者和收款人的总额应该是不变的；

一致性

并发访问数据库时，一个用户的事务不被其他事务所干扰，各并发事务之间数据库是独立的；

隔离性

一个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。

持久性

事务四大特性(ACID)

当一个事务正在访问数据并且对数据进行了修改，而这种修改还没有提交到数据库中，这时另外一个事务也访问了这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是“脏数据”，依据“脏数据”所做的操作可能是不正确的。

一个事务读取了另一个事务未提交的数据

脏读

指在一个事务内多次读同一数据。在这个事务还没有结束时，另一个事务也访问该数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改导致第一个事务两次读取的数据可能不太一样。这就发生了在一个事务内两次读到的数据是不一样的情况，因此称为不可重复读。

一个事务两次读取同一个数据，两次读取的数据不一致

不可重复读

幻读与不可重复读类似。它发生在一个事务（T1）读取了几行数据，接着另一个并发事务（T2）插入了一些数据时。在随后的查询中，第一个事务（T1）就会发现多了一些原本不存在的记录，就好像发生了幻觉一样，所以称为幻读。

一个事务两次读取一个范围的记录，两次读取的记录数不一致。

幻读

指在一个事务读取一个数据时，另外一个事务也访问了该数据，那么在第一个事务中修改了这个数据后，第二个事务也修改了这个数据。这样第一个事务内的修改结果就被丢失，因此称为丢失修改。例如：事务1读取某表中的数据A=20，事务2也读取A=20，事务1修改A=A-1，事务2也修改A=A-1，最终结果A=19，事务1的修改被丢失。

一个事务的更新覆盖了另一个事务的更新，解决办法使用乐观锁或者使用排它锁

更新丢失

事务带来的问题

读未提交：read uncommitted

Oracle默认隔离级别

读已提交：read committed

MySQL默认级别

可重复读：repeatable read

串行化：serializable

对号表示没解决

MySQL InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ（可重读）。我们可以通过SELECT @@tx_isolation;

InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ（可重读），但是可以通过应用加锁读（例如 select * from table for update 语句）来保证不会产生幻读，而这个加锁度使用到的机制就是 Next-Key Lock 锁算法。从而达到了 SQL 标准的 SERIALIZABLE(可串行化) 隔离级别。

设置隔离级别SET [SESSION|GLOBAL] TRANSACTION ISOLATION LEVEL [READ UNCOMMITTED|READ COMMITTED|REPEATABLE READ|SERIALIZABLE]

START TARNSACTION |BEGIN：显式地开启一个事务。COMMIT：提交事务，使得对数据库做的所有修改成为永久性。ROLLBACK：回滚会结束用户的事务，并撤销正在进行的所有未提交的修改。

不可重复读的重点是修改，幻读的重点在于新增或者删除。

事务隔离级别

事务

顺序查找 O(n)

二分查找有序 O(logn)

若它的左子树不空，则左子树上所有结点的值均小于它的根结点的值；若它的右子树不空，则右子树上所有结点的值均大于它的根结点的值；它的左、右子树也分别为二叉排序树。

若b是空树，则搜索失败，否则;若x等于b的根节点的数据域之值，则查找成功；否则：若x小于b的根节点的数据域之值，则搜索左子树；否则：查找右子树

O(log2N)

二叉排序树查找

d为大于1的一个正整数，称为B-Tree的度。h为一个正整数，称为B-Tree的高度。每个非叶子节点由n-1个key和n个指针组成，其中d<=n<=2d。每个叶子节点最少包含一个key和两个指针，最多包含2d-1个key和2d个指针，叶节点的指针均为null 。所有叶节点具有相同的深度，等于树高h。key和指针互相间隔，节点两端是指针。一个节点中的key从左到右非递减排列。所有节点组成树结构。每个指针要么为null，要么指向另外一个节点。如果某个指针在节点node最左边且不为null，则其指向节点的所有key小于v(key1)，其中v(key1)为node的第一个key的值。如果某个指针在节点node最右边且不为null，则其指向节点的所有key大于v(keym)，其中v(keym)为node的最后一个key的值。如果某个指针在节点node的左右相邻key分别是keyi和keyi+1且不为null，则其指向节点的所有key小于v(keyi+1)且大于v(keyi)。

结构特征

例如一个度为d的B-Tree，设其索引N个key，则其树高h的上限为logd((N+1)/2)，检索一个key，其查找节点个数的渐进复杂度为O(logdN)。

由于插入删除新的数据记录会破坏B-Tree的性质，因此在插入删除时，需要对树进行一个分裂、合并、转移等操作以保持B-Tree性质，这也是索引会降低增删改数据性能的原因。

B树

每个节点的指针上限为2d而不是2d+1。

所有的叶子结点中包含了全部关键字的信息，及指向含有这些关键字记录的指针，且叶子结点本身依关键字的大小自小而大的顺序链接。 (而 B 树的叶子节点并没有包括全部需要查找的信息)

内节点不存储data，只存储key；叶子节点不存储指针。所有的内节点点可以看成是索引部分，结点中仅含有其子树根结点中最大（或最小）关键字。 (而B 树的内节点也包含需要查找的有效信息)

数据库索引实际上用的是带有顺序的B+Tree。在经典B+Tree的基础上进行了优化，增加了顺序访问指针。

B+树

红黑树

先从B-Tree分析，根据B-Tree的定义，可知检索一次最多需要访问h个节点。数据库系统的设计者巧妙利用了磁盘预读原理，将一个节点的大小设为等于一个页，这样每个节点只需要一次I/O就可以完全载入。为了达到这个目的，在实际实现B-Tree还需要使用如下技巧：每次新建节点时，直接申请一个页的空间，这样就保证一个节点物理上也存储在一个页里，加之计算机存储分配都是按页对齐的，就实现了一个node只需一次I/O。B-Tree中一次检索最多需要h-1次I/O（根节点常驻内存），渐进复杂度为O(h)=O(logdN)。一般实际应用中，出度d是非常大的数字，通常超过100，因此h非常小（通常不超过3）。综上所述，用B-Tree作为索引结构效率是非常高的。而红黑树这种结构，h明显要深的多。由于逻辑上很近的节点（父子）物理上可能很远，无法利用局部性，所以红黑树的I/O渐进复杂度也为O(h)，效率明显比B-Tree差很多。

B+Tree/B-Tree的性能会比采用红黑树好

多叉平衡查找树

查询算法

http://blog.csdn.net/kennyrose/article/details/7532032

http://www.xuebuyuan.com/2216918.html

为什么MYSQL使用B+树作为索引数据结构？

索引列的值必须唯一，但允许有空值

唯一索引

即一个索引只包含单个列，一个表可以有多个单列索引（建议一张表索引不要超过5个优先考虑复合索引）

普通索引

即一个索引包含多个列

查询的时候如果两个条件都用上了，但是顺序不同，如 city= xx and name ＝xx，那么现在的查询引擎会自动优化为匹配联合索引的顺序，这样是能够命中索引的。

最左前缀原则，在创建联合索引时，索引字段的顺序需要考虑字段值去重之后的个数，较多的放前面。ORDER BY子句也遵循此规则。

最左前缀原则

复合索引(联合索引)

加速查询+列值唯一+表中只有一个（不可以有 null）

将数据存储与索引放到了一块，找到索引也就找到了数据

聚簇索引具有唯一性

主键

聚簇索引

因为MYSQL每次查询只能使用一个索引，如果我们sql语句查询条件包含两个字段，那么使用单值索引需要查询两次，但是复合索引只需要一次即可，有时候覆盖索引完全覆盖可以不回表查询

回表即普通索引查询方式，则需要先搜索name索引树，得到id的值为3，再到id聚簇索引树搜索一次。这个过程称为回表

为什么推荐尽量使用复合索引而不是使用唯一索引呢？

如果一个索引包含（或者说覆盖）所有需要查询的字段的值，我们就称之为“覆盖索引”。

覆盖索引

主键索引

全文索引

MyISAM: B+Tree叶节点的data域存放的是数据记录的地址。在索引检索的时候，首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，则取出其 data 域的值，然后以 data 域的值为地址读取相应的数据记录。这被称为“非聚簇索引”。

InnoDB: 其数据文件本身就是索引文件。相比MyISAM，索引文件和数据文件是分离的，其表数据文件本身就是按B+Tree组织的一个索引结构，树的叶节点data域保存了完整的数据记录。这个索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引。这被称为“聚簇索引（或聚集索引）”。而其余的索引都作为辅助索引，辅助索引的data域存储相应记录主键的值而不是地址，这也是和MyISAM不同的地方。在根据主索引搜索时，直接找到key所在的节点即可取出数据；在根据辅助索引查找时，则需要先取出主键的值，再走一遍主索引。因此，在设计表的时候，不建议使用过长的字段作为主键，也不建议使用非单调的字段作为主键，这样会造成主索引频繁分裂。

B+Tree 索引

hash 索引

Hash索引指的就是Hash表，最大的优点就是能够在很短的时间内，根据Hash函数定位到数据所在的位置，这是B+树所不能比的。

Hash索引定位快

知道HashMap或HashTable的同学，相信都知道它们最大的缺点就是Hash冲突了。不过对于数据库来说这还不算最大的缺点。

Hash冲突问题

Hash索引不支持顺序和范围查询(Hash索引不支持顺序和范围查询是它最大的缺点。B+树是有序的，在这种范围查询中，优势非常大

二者区别

索引的数据结构

B树的所有节点既存放键(key) 也存放数据(data);而B+树只有叶子节点存放 key 和 data，其他内节点只存放key。

B树的叶子节点都是独立的;B+树的叶子节点有一条引用链指向与它相邻的叶子节点。

B树的检索的过程相当于对范围内的每个节点的关键字做二分查找，可能还没有到达叶子节点，检索就结束了。而B+树的检索效率就很稳定了，任何查找都是从根节点到叶子节点的过程，叶子节点的顺序检索很明显。

B树和B+树区别

索引的分类

提高数据检索效率，降低数据库IO成本，将随机IO变为顺序IO

通过索引列对数据排序，降低数据排序成本，降低CPU的消耗

可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。

索引只是提高效率的一个因素，如果你的MySQL有大数据量的表，就需要花时间研究建立优秀的索引，或优化查询语句

http://www.cnblogs.com/mxmbk/articles/5226344.htmlhttp://www.cnblogs.com/simplefrog/archive/2012/07/15/2592527.htmlhttp://www.open-open.com/lib/view/open1418476492792.htmlhttp://blog.csdn.net/colin_liu2009/article/details/7301089http://www.cnblogs.com/hongfei/archive/2012/10/20/2732589.html

索引的优缺点

什么是回表？

表的读取顺序

数据读取操作的操作类型

哪些索引可以使用

哪些索引被实际使用

表之间的引用

每张表有多少行被优化器查询

查询序号，id相同从上往下，id不同id越大优先级越高

表示示查询中每个select子句的类型

select_type

显示这一步所访问数据库中表名称（显示这一行的数据是关于哪张表的），有时不是真实的表名字，可能是简称，例如上面的e，d，也可能是第几步执行的结果的简称

table(重要)

代表分区表中的命中情况，非分区表，该项为null

partitions

对表访问方式，表示MySQL在表中找到所需行的方式，又称“访问类型”。

ALL、index、range、 ref、eq_ref、const、system、NULL（从左到右，性能从差到好）

type(重要)

指出MySQL能使用哪个索引在表中找到记录，查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询使用（该查询可以利用的索引，如果没有任何索引显示 null）

possible_keys

key列显示MySQL实际决定使用的键（索引），必然包含在possible_keys中

Key（重要）

表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度（key_len显示的值为索引字段的最大可能长度，并非实际使用长度，即key_len是根据表定义计算而得，不是通过表内检索出的）

key_len

列与索引的比较，表示上述表的连接匹配条件，即哪些列或常量被用于查找索引列上的值

ref

表示MySQL估计未来找到所需要的行而要读取的行数

rows（重要）

这一列包含的是不适合在其他列显示的额为信息

Extra(重要)

字段

Explain(查询语句执行计划)

什么是复合索引的最左匹配原则?

如果查询条件用or，必须or条件中的每个列都加上索引，否则无效。（尽量使用union代替）

复合索引未用左列字段;

like以%开头;

需要类型转换;

where中索引列有运算;

where中索引列使用了函数;

如果mysql觉得全表扫描更快时（数据少）

索引失效的情况

保证被驱动表的join字段有索引

left join时，选择小表为驱动表，大表为被驱动表，因为驱动表一定要做全表扫描。

inner join时，mysql会自己帮你把小结果集的表选为驱动表

子查询尽量不要放在被驱动表。因为子查询会生成虚拟表导致有可能使用不到索引

能够直接关联查询，尽量不用子查询。

关联查询

数据量不同，查询条件不同，sql使用的索引可能是不一样的，要构造多种查询条件去测试。

避免所有字段都返回，尽量使用覆盖索引，解决慢sql问题，终归是与库的磁盘IO、CPU做抗争。

避免隐式转换造成的索引无法使用问题。

制好事务粒度，大事务不仅会严重影响数据库的吞吐量，CPU（死锁检测），也会造成主从的延迟，危害极大。

合理的设置数据库连接池的参数，设置sql语句的timeout，查询量大的地方，需要有降级开关。

新增功能，每一条sql语句，都要进行explain

所谓的慢sql，有些sql并不慢，而是坏sql，调用量低，数据量少的情况，并不慢，慢日志无法捕获。这个时候，需要对功能进行压测，压测需要注意两个问题：a) 压测脚本的选择，如果使用固定的查询条件，会造成mysql命中缓存，或使用固定索引，压测效果不明显b) 压测数据库的操作，要逐渐放量，避免将库CPU打满，既要盯UMP的性能曲线，又要关注数据库CPU的使用率。

使用读写分离的方式，降低数据库的压力，读写分离能有效降低库的压力

主从延迟问题。读写分离后，无可避免的会有延迟问题，所以需要甄别好，哪些业务是对延迟敏感的，这类业务，需要继续查询主库。为尽量避免延迟问题，需注意以下几点：a) 从库的压力，不能过大，如果资源允许，尽量主从的硬件资源相同。b) 避免使用大事务。c) 尽量避免大批量的删除、更新操作，尤其是无法使用索引的情况。

业务隔离，不同业务使用不同从库。识别出业务的黄金流程。重点业务与其他非重点业务使用不同的从库进行隔离。

读写分离

脱库改造，增加缓存。a) 对于数据要求实时性不高的场景，并且为了快速的减少系统问题，可采取缓存read-through的方式，该方式系统改造量低，简单。但是要注意，避免不存在的key缓存穿透（不存在key设置特殊值、bloomfilter）。缓存雪崩问题。b) 数据异构，将依赖的底层数据通过binlake或双写等等方式，异构到jimdbc) 数据异构，将列表类或多条件复杂查询数据，异构到ES。查询需注意深分页及一次查询的数据量过多问题。

复杂的统计类功能，使用离线计算的方式，避免实时通过库函数进行计算统计

浏览记录、日志类或其他不重要功能，可通过mq，同步写转异步写

架构调整，服务化改造，应用拆分

底层资源进行拆分，按业务维度，不同业务拆分为不同应用，使用不同的资源。

数据库垂直拆分，业务隔离

1.库水平拆分会出现很多问题，无法join，无法聚合查询，可采用异构数据到ES等方式解决。2、将无用的历史数据进行归档。

数据库水平拆分，分库分表

针对问题1，对于复杂、模糊查询等，更适合使用ES搜索引擎去处理。a) 如果对数据的实时性要求不高，建议通过binlake或mq的方式，异步构建ES索引。b) 如果对数据实时性要求很高，可通过双写的方式处理，失败可以采用异步补偿的方式。另外ES本身段刷新有1秒的延迟，1s后数据才可搜索。如果不可接受并且数据修改频率低，可通过setRefresh方法强制刷新，立刻即可搜索到。写入量大的时候慎用。

复杂、多字段、模糊查询

建议使用nosql库，hbase、es等存储

超大文本的存储（text类型）。大文本查询，会耗费mysql大量的内存空间，造成热数据被置换出去，查询效率降低

日志类大数量的存储

简单查询，jimdb是非常好选择。如果有业务需要复杂查询，更建议使用ES多集群方式处理。

超高并发的查询

不适合使用Mysql场景

慢查询

查询优化

索引优化

MyISAM：不支持事务，但是每次查询都是原子的；支持表级锁，即每次操作是对整个表加锁；存储表的总行数；一个MYISAM表有三个文件：索引文件、表结构文件、数据文件；采用菲聚集索引，索引文件的数据域存储指向数据文件的指针。辅索引与主索引基本一致，但是辅索引不用保证唯一性。InnoDb：支持ACID的事务，支持事务的四种隔离级别；支持行级锁及外键约束：因此可以支持写并发；不存储总行数；一个InnoDb引擎存储在一个文件空间（共享表空间，表大小不受操作系统控制，一个表可能分布在多个文件里），也有可能为多个（设置为独立表空，表大小受操作系统文件大小限制，一般为2G），受操作系统文件大小的限制；主键索引采用聚集索引（索引的数据域存储数据文件本身），辅索引的数据域存储主键的值；因此从辅索引查找数据，需要先通过辅索引找到主键值，再访问辅索引；最好使用自增主键，防止插入数据时，为维持B+树结构，文件的大调整。

简述在MySQL数据库中MyISAM和InnoDB的区别

通常我们都会首选 Timestamp

DateTime 类型保存的时间都是当前会话所设置的时区对应的时间。

Timestamp 类型字段的值会随着服务器时区的变化而变化，自动换算成相应的时间，说简单点就是在不同时区，查询到同一个条记录此字段的值会不一样。

# 查看当前会话时区SELECT @@session.time_zone;# 设置当前会话时区SET time_zone = 'Europe/Helsinki';SET time_zone = \"+00:00\";# 数据库全局时区设置SELECT @@global.time_zone;# 设置全局时区SET GLOBAL time_zone = '+8:00';SET GLOBAL time_zone = 'Europe/Helsinki';

时区

DateTime ：1000-01-01 000000 ~ 9999-12-31 235959

DateTime 需要耗费 8 个字节的存储空间

Timestamp： 1970-01-01 000001 ~ 2037-12-31 235959

Timestamp 只需要使用 4 个字节的存储空间，

存储空间与时间范围

其实用long型数值表示程序做转换也可！

Datetime 和 Timestamp 区别

在经常需要搜索的列上，可以加快搜索的速度；

在经常使用在WHERE子句中的列上面创建索引，加快条件的判断速度。

在经常需要排序的列上创建索引，因为索引已经排序，这样查询可以利用索引的排序，加快排序查询时间；B+Tree

对于中到大型表索引都是非常有效的，但是特大型表的话维护开销会很大，不适合建索引

在经常用在连接的列上，这些列主要是一些外键，可以加快连接的速度；

避免 where 子句中对宇段施加函数，这会造成无法命中索引。

在使用InnoDB时使用与业务无关的自增主键作为主键，即使用逻辑主键，而不要使用业务主键。

将某一列设置为default null，where 是可以走索引，另外索引列是否设置 null 是不影响性能的。但是，还是不建议列上允许为空。最好限制not null，因为null需要更多的存储空间并且null值无法参与某些运算。

删除长期未使用的索引，不用的索引的存在会造成不必要的性能损耗 MySQL 5.7 可以通过查询 sys 库的 chema_unused_indexes 视图来查询哪些索引从未被使用

在使用 limit offset 查询缓慢时，可以借助索引来提高性能

被频繁更新的字段应该慎重建立索引

尽可能的考虑建立联合索引而不是单列索引

使用索引的注意事项

为什么索引能提高查询速度

身份认证和权限相关(登录 MySQL 的时候)。

连接器

执行查询语句的时候，会先查询缓存（MySQL 8.0 版本后移除，因为这个功能不太实用）。

查询缓存

第一步，词法分析，一条 SQL 语句有多个字符串组成，首先要提取关键字，比如 select，提出查询的表，提出字段名，提出查询条件等等。做完这些操作后，就会进入第二步。

第二步，语法分析，主要就是判断你输入的 sql 是否正确，是否符合 MySQL 的语法。

没有命中缓存的话，SQL 语句就会经过分析器，分析器说白了就是要先看你的 SQL 语句要干嘛，再检查你的 SQL 语句语法是否正确。

分析器

按照 MySQL 认为最优的方案去执行。

优化器

执行语句，然后从存储引擎返回数据。

执行器

MySql基础组件

frm文件：存储表的定义数据

MYD文件：存放表具体记录的数据

MYI文件：存储索引

文件

特点索引存放的是数据具体存放在磁盘上的地址

MyISAM

一张表最多有16个索引，每个索引的最大长度是255个字节

事务型数据库的首选引擎，支持事务安全表（ACID），支持行锁定和外键，上图也看到了，InnoDB是默认的MySQL引擎。

InnoDB

ISAM

CSV.....

存储引擎

MyISAM表共享锁

InnoDb行共享锁

共享锁(读锁)

排它锁又称：写锁

当一个事务对某几个上写锁时，不允许其他事务写，但允许读

更不允许其他事务给这几行上任何锁。包括写锁。

两个事务不能锁同一个索引

insert ，delete ， update在事务中都会自动默认加上排它锁

行锁必须有索引才能实现，否则会自动锁全表，那么就不是行锁了

InnoDB排它锁（写锁）

按照锁机制分类

使用表级锁定的主要是MyISAM，MEMORY，CSV等一些非事务性存储引擎。

表锁(偏读)

使用行级锁定的主要是InnoDB存储引擎。

事务中显式加锁：SELECT * FROM table_name WHERE ... FOR UPDATE

排他锁： X锁

事务中显式加锁：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE

共享锁：S锁

意向排他锁：IX锁

意向共享锁：IS锁

行锁(偏写)

意向锁是InnoDB自动加的，不需用户干预。

页锁(DBD引擎采用)

表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如OLAP系统

行级锁则更适合于有大量按索引条件并发更新少量不同数据，同时又有并发查询的应用，如一些在线事务处理（OLTP）系统

表级锁和行级锁的区别

按照锁的粒度分类

InnoDB行锁是通过给索引上的索引项加锁来实现的，只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁

Record lock：单个行记录上的锁

（1）防止幻读，以满足相关隔离级别的要求。对于上面的例子，要是不使用间隙锁，如果其他事务插入了empid大于100的任何记录，那么本事务如果再次执行上述语句，就会发生幻读；

（2）为了满足其恢复和复制的需要。

Gap lock：间隙锁，锁定一个范围，不包括记录本身

Next-key lock：record+gap 锁定一个范围，包含记录本身

innodb对于行的查询使用next-key lock

Next-locking keying为了解决Phantom Problem幻读问题

当查询的索引含有唯一属性时，将next-key lock降级为record key

Gap锁设计的目的是为了阻止多个事务将记录插入到同一范围内，而这会导致幻读问题的产生

有两种方式显式关闭gap锁：（除了外键约束和唯一性检查外，其余情况仅使用record lock） A. 将事务隔离级别设置为RC B. 将参数innodb_locks_unsafe_for_binlog设置为1

InnoDB存储引擎行锁的实现方式

innoDB使用的是行锁myisam使用的是表锁

更新的时候没有索引或者索引失效时，InnoDB 的行锁变表锁

行锁退化到表锁

间隙锁（Gap Lock）是Innodb在可重复读提交下为了解决幻读问题时引入的锁机制，

间隙锁

行锁是行级别的，粒度比较小，好，那我要你在拿行锁之前，必须先拿一个假的表锁，表示你想去锁住表里的某一行或者多行记录。这样，Mysql 在判断表里有没有记录被锁定，就不需要遍历整张表了，它只需要看看，有没有人拿了这个假的表锁。

意向锁

锁表

首先创建一个和你要执行的alter操作的表一样的空的表结构

执行我们赋予的表结构的修改，然后copy原表中的数据到新表里面。

在原表上创建一个触发器在数据copy的过程中，将原表的更新数据的操作全部更新到新的表中来

copy完成之后，用rename table 新表代替原表，默认删除原表

系统升级，加字段正确方法

pt-online-schema-change

用插件解决加字段问题

逻辑结构修改

对于普通SELECT语句，InnoDB不会加任何锁；

对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁（X)；

开启事务加锁

MyISAM在执行查询语句（SELECT）前，会自动给涉及的所有表加读锁，在执行更新操作（UPDATE、DELETE、INSERT等）前，会自动给涉及的表加写锁，这个过程并不需要用户干预，因此，用户一般不需要直接用LOCK TABLE命令给MyISAM表显式加锁

表锁

如何给数据库加锁

（1）在应用中，如果不同的程序会并发存取多个表，应尽量约定以相同的顺序来访问表，这样可以大大降低产生死锁的机会。

（2）在程序以批量方式处理数据的时候，如果事先对数据排序，保证每个线程按固定的顺序来处理记录，也可以大大降低出现死锁的可能。

（3）在事务中，如果要更新记录，应该直接申请足够级别的锁，即排他锁，而不应先申请共享锁，更新时再申请排他锁，因为当用户申请排他锁时，其他事务可能又已经获得了相同记录的共享锁，从而造成锁冲突，甚至死锁。

（4）在REPEATABLE-READ隔离级别下，如果两个线程同时对相同条件记录用SELECT...FOR UPDATE加排他锁，在没有符合该条件记录情况下，两个线程都会加锁成功。程序发现记录尚不存在，就试图插入一条新记录，如果两个线程都这么做，就会出现死锁。这种情况下，将隔离级别改成READ COMMITTED，就可避免问题。

（5）当隔离级别为READ COMMITTED时，如果两个线程都先执行SELECT...FOR UPDATE，判断是否存在符合条件的记录，如果没有，就插入记录。此时，只有一个线程能插入成功，另一个线程会出现锁等待，当第1个线程提交后，第2个线程会因主键重出错，但虽然这个线程出错了，却会获得一个排他锁。这时如果有第3个线程又来申请排他锁，也会出现死锁。对于这种情况，可以直接做插入操作，然后再捕获主键重异常，或者在遇到主键重错误时，总是执行ROLLBACK释放获得的排他锁。

InnoDB_row_lock_current_waits：当前正在等待锁定的数量；InnoDB_row_lock_time：从系统启动到现在锁定总时间长度；InnoDB_row_lock_time_avg：每次等待所花平均时间；InnoDB_row_lock_time_max：从系统启动到现在等待最常的一次所花的时间；InnoDB_row_lock_waits：系统启动后到现在总共等待的次数；

通过检查InnoDB_row_lock状态变量来分析系统上的行锁的争夺情况：

这个参数并不是只用来解决死锁问题，在并发访问比较高的情况下，如果大量事务因无法立即获得所需的锁而挂起，会占用大量计算机资源，造成严重性能问题，甚至拖跨数据库。我们通过设置合适的锁等待超时阈值，可以避免这种情况发生。

MySQL官方手册中也提到了这个问题，实际上在InnoDB发现死锁之后，会计算出两个事务各自插入、更新或者删除的数据量来判定两个事务的大小。也就是说哪个事务所改变的记录条数越多，在死锁中就越不会被回滚掉。但是有一点需要注意的就是，当产生死锁的场景中涉及到不止InnoDB存储引擎的时候，InnoDB是没办法检测到该死锁的，这时候就只能通过锁定超时限制参数InnoDB_lock_wait_timeout来解决。

在InnoDB的事务管理和锁定机制中，有专门检测死锁的机制，会在系统中产生死锁之后的很短时间内就检测到该死锁的存在。当InnoDB检测到系统中产生了死锁之后，InnoDB会通过相应的判断来选这产生死锁的两个事务中较小的事务来回滚，而让另外一个较大的事务成功完成。

Innodb死锁检测

当事务开始执行时会先获得一个时间戳，数据库程序会根据事务的时间戳决定事务应该等待还是回滚，在这时也有两种机制

当执行事务的时间戳小于另一事务时，即事务 A 先于 B 开始，那么它就会等待另一个事务释放对应资源的锁，否则就会保持当前的时间戳并回滚。

wait-die 机制

当前事务如果先于另一事务执行并请求了另一事务的资源，那么另一事务会立刻回滚，将资源让给先执行的事务，否则就会等待其他事务释放资源

wound-wait

抢占加事务回滚的方式

常规思路

死锁检测

如何避免死锁

https://draveness.me/database-concurrency-control/

MySQL 中实现的多版本两阶段锁协议（Multiversion 2PL）将 MVCC 和 2PL 的优点结合了起来，

每一个版本的数据行都具有一个唯一的时间戳，当有读事务请求时，数据库程序会直接从多个版本的数据项中具有最大时间戳的返回。

更新操作就稍微有些复杂了，事务会先读取最新版本的数据计算出数据更新后的结果，然后创建一个新版本的数据，新数据的时间戳是目前数据行的最大版本＋1：

数据版本的删除也是根据时间戳来选择的，MySQL 会将版本最低的数据定时从数据库中清除以保证不会出现大量的遗留内容。

MySQL 与 MVCC

PostgreSQL 中都是使用乐观并发控制的，这也就导致了 MVCC 在于乐观锁结合时的实现上有一些不同，最终实现的叫做多版本时间戳排序协议（Multiversion Timestamp Ordering），在这个协议中，所有的事务在执行之前都会被分配一个唯一的时间戳，每一个数据项都有读写两个时间戳

当 PostgreSQL 的事务发出了一个读请求，数据库直接将最新版本的数据返回，不会被任何操作阻塞，而写操作在执行时，事务的时间戳一定要大或者等于数据行的读时间戳，否则就会被回滚。

这种 MVCC 的实现保证了读事务永远都不会失败并且不需要等待锁的释放，对于读请求远远多于写请求的应用程序，乐观锁加 MVCC 对数据库的性能有着非常大的提升；虽然这种协议能够针对一些实际情况做出一些明显的性能提升，但是也会导致两个问题，一个是每一次读操作都会更新读时间戳造成两次的磁盘写入，第二是事务之间的冲突是通过回滚解决的，所以如果冲突的可能性非常高或者回滚代价巨大，数据库的读写性能还不如使用传统的锁等待方式。

PostgreSQL 与 MVCC

MVCC (多版本并发控制)

【强制】页面搜索严禁左模糊或者全模糊，如果需要请走搜索引擎来解决说明:索引文件具有 B-Tree 的最左前缀匹配特性，如果左边的值未确定，那么无法使用此索引。

模糊查询

【强制】不得使用外键与级联，一切外键概念必须在应用层解决。说明:以学生和成绩的关系为例，学生表中的 student_id 是主键，那么成绩表中的 student_id 则为外键。如果更新学生表中的 student_id，同时触发成绩表中的 student_id 更新，即为级联更新。外键与级联更新适用于单机低并发，不适合分布式、高并发集群;级联更新是强阻塞，存在数据库更新风暴的风险;外键影响数据库的插入速度

增加了复杂性

增加了额外工作

外键还会因为需要请求对其他表内部加锁而容易出现死锁情况；

对分库分表不友好

级联操作方便，减轻了程序代码量；

保证了数据库数据的一致性和完整性；

使用外键带来的问题

外键和级联

@Transactional事务不要滥用。事务会影响数据库的QPS，另外使用事务的地方需要考虑各方面的回滚方案，包括缓存回滚、搜索引擎回滚、消息补偿、统计修正等。

1. 限定数据的范围

2. 读/写分离

垂直拆分的优点：可以使得列数据变小，在查询时减少读取的Block数，减少I/O次数。此外，垂直分区可以简化表的结构，易于维护。

垂直拆分的缺点：主键会出现冗余，需要管理冗余列，并会引起Join操作，可以通过在应用层进行Join来解决。此外，垂直分区会让事务变得更加复杂；

3. 垂直分区

客户端代理：分片逻辑在应用端，封装在jar包中，通过修改或者封装JDBC层来实现。当当网的 Sharding-JDBC 、阿里的TDDL是两种比较常用的实现

中间件代理：在应用和数据中间加了一个代理层。分片逻辑统一维护在中间件服务中。我们现在谈的 Mycat 、360的Atlas、网易的DDB等等都是这种架构的实现。

4. 水平分区

大表优化

在连接池中，创建连接后，将其放置在池中，并再次使用它，因此不必建立新的连接。如果使用了所有连接，则会建立一个新连接并将其添加到池中。

连接池还减少了用户必须等待建立与数据库的连接的时间。

连接池带来的池化思想

UUID：不适合作为主键，因为太长了，并且无序不可读，查询效率低。比较适合用于生成唯一的名字的标示比如文件的名字。

数据库自增 id : 两台数据库分别设置不同步长，生成不重复ID的策略来实现高可用。这种方式生成的 id 有序，但是需要独立部署数据库实例，成本高，还会有性能瓶颈。

利用 redis 生成 id : 性能比较好，灵活方便，不依赖于数据库。但是，引入了新的组件造成系统更加复杂，可用性降低，编码更加复杂，增加了系统成本。

Twitter的snowflake算法：Github 地址：https://github.com/twitter-archive/snowflake。

美团的Leaf分布式ID生成系统：Leaf 是美团开源的分布式ID生成器，能保证全局唯一性、趋势递增、单调递增、信息安全，里面也提到了几种分布式方案的对比，但也需要依赖关系数据库、Zookeeper等中间件。感觉还不错。美团技术团队的一篇文章：

redolog写满了

内存不够用了

MySQL 认为系统“空闲”的时候

MySQL 正常关闭的时候

刷脏页有下面4种场景

数据库在刷新脏页（flush）当我们要往数据库插入一条数据、或者要更新一条数据的时候，我们知道数据库会在内存中把对应字段的数据更新了，但是更新之后，这些更新的字段并不会马上同步持久化到磁盘中去，而是把这些更新的记录写入到 redo log 日记中去，等到空闲的时候，在通过 redo log 里的日记把最新的数据同步到磁盘中去。当内存数据页跟磁盘数据页内容不一致的时候，我们称这个内存页为“脏页”。内存数据写入到磁盘后，内存和磁盘上的数据页的内容就一致了，称为“干净页”。

拿不到锁show processlist

大多数情况是正常的，只是偶尔会出现很慢的情况。

字段没有索引

函数操作导致没有用上索引

字段有索引，但却没有用索引

数据库自己选错索引

没用到索引

在数据量不变的情况下，这条SQL语句一直以来都执行的很慢。

一条SQL语句执行得很慢的原因有哪些？

MySQL高性能优化规范建议

最佳SQL实践

符合1NF的关系中的每个属性都不可再分

1NF

二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。

2Nf

在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。

3NF

数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符BCNF范式。

BCNF

设计范式

MySql

.........

关系数据库

Redis 是一个开源，高级的键值存储和一个适用的解决方案，用于构建高性能，可扩展的 Web 应用程序。Redis 也被作者戏称为数据结构服务器，这意味着使用者可以通过一些命令，基于带有 TCP 套接字的简单服务器-客户端协议来访问一组可变数据结构。(

介绍

异常快 - Redis 非常快，每秒可执行大约 110000 次的设置(SET)操作，每秒大约可执行 81000 次的读取/获取(GET)操作。

支持丰富的数据类型 - Redis 支持开发人员常用的大多数数据类型，例如列表，集合，排序集和散列等等。这使得 Redis 很容易被用来解决各种问题，因为我们知道哪些问题可以更好使用地哪些数据类型来处理解决。

操作具有原子性 - 所有 Redis 操作都是原子操作，这确保如果两个客户端并发访问，Redis 服务器能接收更新的值。

多实用工具 - Redis 是一个多实用工具，可用于多种用例，如：缓存，消息队列(Redis 本地支持发布/订阅)，应用程序中的任何短期数据，例如，web应用程序中的会话，网页命中计数等。

string 是最常用的一种数据类型，普通的key/value存储都可以归结为string类型，value不仅是string，也可以是数字。其他几种数据类型的构成元素也都是字符串，注意Redis规定字符串的长度不能超过512M

int编码保存的是可以用long类型表示的整数值

raw编码保存长度大于44字节的字符串

embstr编码保存长度小于44字节的字符串

编码字符串对象的编码可以是int raw embstr

Redis中对于浮点型也是作为字符串保存的，在需要时再将其转换成浮点数类型

字符串 String

hash对象的编码可以是zipmap或者hashtable当使用zipmap，也就是压缩列表作为底层实现时，新增的键值是保存到压缩列表的表尾。hashtable 编码的hash表对象底层使用字典数据结构，哈希对象中的每个键值对都使用一个字典键值对。Redis中的字典相当于Java里面的HashMap，内部实现也差不多类似，都是通过“数组+链表”的链地址法来解决哈希冲突的，这样的结构吸收了两种不同数据结构的优点。

编码

当同时满足下面两个条件使用ziplist编码，否则使用hashtable编码列表保存元素个数小于512个每个元素长度小于64字节

编码转换

hash是一个String类型的field和value之间的映射表

Hash特别适合存储对象

hset hashname hashkey hashvalue

hget hashname hashkey

hset/hget

hmset hashname hashkey1hashvalue1 hashkey2 hashvalue2 hashkey3 hashvalue3

hget hashname hashkey1 hashkey2 hashkey3

hmset/hmget

hsetnx/hgetnx

hincrby/hdecrby

Hash命令详解

渐进式 rehash 会在 rehash 的同时，保留新旧两个 hash 结构，查询时会同时查询两个 hash 结构，然后在后续的定时任务以及 hash 操作指令中，循序渐进的把旧字典的内容迁移到新字典中。当搬迁完成了，就会使用新的 hash 结构取而代之。

正常情况下，当 hash 表中元素的个数等于第一维数组的长度时，就会开始扩容，扩容的新数组是原数组大小的 2 倍。不过如果 Redis 正在做 bgsave(持久化命令)，为了减少内存也得过多分离，Redis 尽量不去扩容，但是如果 hash 表非常满了，达到了第一维数组长度的 5 倍了，这个时候就会强制扩容。

hash 表因为元素逐渐被删除变得越来越稀疏时，Redis 会对 hash 表进行缩容来减少 hash 表的第一维数组空间占用。所用的条件是元素个数低于数组长度的 10%，缩容不会考虑 Redis 是否在做 bgsave。

渐进式扩容

对于 hash 数据类型，value 存放的是键值对，比如可以做单点登录存放用户信息。

存放商品信息，实现购物车

同类数据归类整合存储，方便数据管理，比如单个用户的所有商品都放在一个hash表里面。

相比string操作消耗内存cpu更小

hash结构的存储消耗要高于单个字符串

过期功能不能使用在field上，只能用在key上

redis集群架构不适合大规模使用

优点 / 缺点

哈希表 Hash

编码列表对象的编码可以是ziplist（压缩列表）和linkedlist（双端链表）。编码转换同时满足下面两个条件时使用压缩列表：列表保存元素个数小于512个每个元素长度小于64字节不能满足上面两个条件使用linkedlist（双端列表）编码

LPUSH 和 RPUSH 分别可以向 list 的左边（头部）和右边（尾部）添加一个新元素；

LRANGE 命令可以从 list 中取出一定范围的元素；

LINDEX 命令可以从 list 中取出指定下表的元素，相当于 Java 链表操作中的 get(int index) 操作；

常用命令

Stack（栈）LPUSH+LPOP

Queue（队列）LPUSH + RPOP

Blocking MQ（阻塞队列）LPUSH+BRPOP

实现数据结构

列表（链表实现）List

集合对象set是string类型（整数也会转成string类型进行存储）的无序集合。注意集合和列表的区别：集合中的元素是无序的，因此不能通过索引来操作元素；集合中的元素不能有重复。

编码集合对象的编码可以是intset或者hashtableintset编码的集合对象使用整数集合作为底层实现，集合对象包含的所有元素都被保存在整数集合中。hashtable编码的集合对象使用字典作为底层实现，字典的每个键都是一个字符串对象，这里的每个字符串对象就是一个集合中的元素，而字典的值全部设置为null。当使用HT编码时，Redis中的集合SET相当于Java中的HashSet，内部的键值对是无序的，唯一的。内部实现相当于一个特殊的字典，字典中所有value都是NULL。编码转换当集合满足下列两个条件时，使用intset编码：集合对象中的所有元素都是整数集合对象所有元素数量不超过512

sadd：向集合中添加元素（set不允许元素重复）smembers：查看集合中的元素srem：删除集合元素spop：随机返回删除的keysdiff ：返回两个集合的不同元素（哪个集合在前就以哪个集合为标准）

应用场景对于 set 数据类型，由于底层是字典实现的，查找元素特别快，另外set 数据类型不允许重复，利用这两个特性我们可以进行全局去重，比如在用户注册模块，判断用户名是否注册；微信点赞，微信抽奖小程序另外就是利用交集、并集、差集等操作，可以计算共同喜好，全部的喜好，自己独有的喜好，可能认识的人等功能。

集合 set

和集合对象相比，有序集合对象是有序的。与列表使用索引下表作为排序依据不同，有序集合为每一个元素设置一个分数（score）作为排序依据。

当有序结合对象同时满足以下两个条件时，对象使用ziplist编码，否则使用skiplist编码保存的元素数量小于128保存的所有元素长度都小于64字节

ziplist编码的有序集合对象使用压缩列表作为底层实现，每个集合元素使用两个紧挨在一起的压缩列表节点来保存，第一个节点保存元素的成员，第二个节点保存元素的分值。并且压缩列表内的集合元素按分值从小到大的顺序进行排列，小的放置在靠近表头的位置，大的放置在靠近表尾的位置。

因为 zset 要支持随机的插入和删除，所以它不宜使用数组来实现，关于排序问题，我们也很容易就想到红黑树/ 平衡树这样的树形结构，为什么 Redis 不使用这样一些结构呢？

性能考虑：在高并发的情况下，树形结构需要执行一些类似于 rebalance 这样的可能涉及整棵树的操作，相对来说跳跃表的变化只涉及局部

实现考虑：在复杂度与红黑树相同的情况下，跳跃表实现起来更简单，看起来也更加直观；

使用原因

https://mp.weixin.qq.com/s?__biz=MzA4NTg1MjM0Mg==&mid=2657261425&idx=1&sn=d840079ea35875a8c8e02d9b3e44cf95&scene=21#wechat_redirect

实现思路

O(log n)

平均时间复杂度

跳跃列表 (SkipList)

skiplist编码的依序集合对象使用zset结构作为底层实现，一个zset结构同时包含一个字典和一个跳跃表

zrem：删除集合中名称为key的元素member

zincrby：以指定值去自动递增

zcard：查看元素集合的个数

zcount：返回score在给定区间中的数量

zrangebyscore：找到指定区间范围的数据进行返回

zremrangebyrank zset from to：删除索引

zremrangebyscore zset from to：删除指定序号

zrank：返回排序索引（升序之后再找索引）zrevrank：返回排序索引（降序之后再找索引）

应用场景对于 zset 数据类型，有序的集合，可以做范围查找，排行榜应用，取 TOP N 操作等。

编码有序集合的编码可以使ziplist或者skiplist

有序集合 sort set

基本数据结构

GeoHash 算法将二维的经纬度数据映射到一维的整数，这样所有的元素都将在挂载到一条线上，距离靠近的二维坐标映射到一维后的点之间距离也会很接近。当我们想要计算「附近的人时」，首先将目标位置映射到这条线上，然后在这个一维的线上获取附近的点就行了。

它的核心思想就是把整个地球看成是一个二维的平面，然后把这个平面不断地等分成一个一个小的方格，每一个坐标元素都位于其中的唯一一个方格中，等分之后的方格越小，那么坐标也就越精确

geoadd company 116.48105 39.996794 juejin

增加 geoadd

geodist company juejin ireader km

距离 geodist

geopos company juejin

获取元素位置 geopos

geohash company ireader

获取元素的 hash 值 geohash

georadiusbymember company ireader 20 km count 3 asc

附近的东西 georadiusbymember 、 georadius

常见命令

地理位置(GeoHash )

关于基数统计通常是用来统计一个集合中不重复的元素个数。

B 树最大的优势就是插入和查找效率很高，如果用 B 树存储要统计的数据，可以快速判断新来的数据是否存在，并快速将元素插入 B 树。要计算基础值，只需要计算 B 树的节点个数就行了。不过将 B 树结构维护到内存中，能够解决统计和计算的问题，但是并没有节省内存。

B 树

bitmap 可以理解为通过一个 bit 数组来存储特定数据的一种数据结构，每一个 bit 位都能独立包含信息，bit 是数据的最小存储单位，因此能大量节省空间，也可以将整个 bit 数据一次性 load 到内存计算。

bitmap 还有一个明显的优势是可以轻松合并多个统计结果，只需要对多个结果求异或就可以了，也可以大大减少存储内存。

Java 的 bitSet 实现了该数据结构

1)已知某个文件内包含一些电话号码，每个号码为8位数字，统计不同号码的个数8位最多99 999 999，大概需要99m个bit，大概10几m字节的内存即可。可以理解为从0-99 999 999的数字，每个数字对应一个Bit位，所以只需要99M个Bit==1.2MBytes，这样，就用了小小的1.2M左右的内存表示了所有的8位数的电话。

2)2.5亿个整数中找出不重复的整数的个数，内存空间不足以容纳这2.5亿个整数将bit-map扩展一下，用2bit表示一个数即可：0表示未出现；1表示出现一次；2表示出现2次及以上，即重复，在遍历这些数的时候，如果对应位置的值是0，则将其置为1；如果是1，将其置为2；如果是2，则保持不变。或者我们不用2bit来进行表示，我们用两个bit-map即可模拟实现这个2bit-map，都是一样的道理。

给40亿个不重复的unsigned int的整数，没排过序的，然后再给一个数，如何快速判断这个数是否在那40亿个数当中？解法一：可以用位图/Bitmap的方法，申请512M的内存，一个bit位代表一个unsigned int值。读入40亿个数，设置相应的bit位，读入要查询的数，查看相应bit位是否为1，为1表示存在，为0表示不存在。

bitmap

实现方案

PFADD

PFCOUNT

PFMEGER

使用

00xxxxxx：前缀两个零表示接下来的 6bit 整数值加 1 就是零值计数器的数量，注意这里要加 1 是因为数量如果为零是没有意义的。比如 00010101 表示连续 22 个零值计数器。

01xxxxxx yyyyyyyy：6bit 最多只能表示连续 64 个零值计数器，这样扩展出的 14bit 可以表示最多连续 16384 个零值计数器。这意味着 HyperLogLog 数据结构中 16384 个桶的初始状态，所有的计数器都是零值，可以直接使用 2 个字节来表示。

1vvvvvxx：中间 5bit 表示计数值，尾部 2bit 表示连续几个桶。它的意思是连续 (xx +1) 个计数值都是 (vvvvv + 1)。比如 10101011 表示连续 4 个计数值都是 11。

上面第三种方式的计数值最大只能表示到 32，而 HyperLogLog 的密集存储单个计数值用 6bit 表示，最大可以表示到 63。当稀疏存储的某个计数值需要调整到大于 32 时，Redis 就会立即转换 HyperLogLog 的存储结构，将稀疏存储转换成密集存储。

稀疏存储方式多个连续桶的计数值都是零

16384 个 6 bit 连续串成

一个字节是由 8 个 bit 组成的，这样 6 bit 排列的结构就会导致，有一些桶会跨越字节边界，我们需要对这一个或者两个字节进行适当的移位拼接才可以得到具体的计数值。

密集存储

存储

HyperLogLog

SETBITGETBITBITCOUNTBITPOSBITOPBITFIELD

指令

使用场景

位图 bitmap

布隆过滤器(Bloom Filter) 就是这样一种专门用来解决去重问题的高级数据结构。

大数据判断是否存在：这就可以实现出上述的去重功能，如果你的服务器内存足够大的话，那么使用 HashMap 可能是一个不错的解决方案，理论上时间复杂度可以达到 O(1 的级别，但是当数据量起来之后，还是只能考虑布隆过滤器。

解决缓存穿透：我们经常会把一些热点数据放在 Redis 中当作缓存，例如产品详情。通常一个请求过来之后我们会先查询缓存，而不用直接读取数据库，这是提升性能最简单也是最普遍的做法，但是如果一直请求一个不存在的缓存，那么此时一定不存在缓存，那就会有大量请求直接打到数据库上，造成缓存穿透，布隆过滤器也可以用来解决此类问题。

爬虫/ 邮箱等系统的过滤：平时不知道你有没有注意到有一些正常的邮件也会被放进垃圾邮件目录中，这就是使用布隆过滤器误判导致的。

布隆过滤器原理

Redis 4.0

bf.add 添加元素

bf.madd 添加多个元素

bf.exists 查询元素是否存在

bf.mexists

key

error_rate 越低，需要的空间越大

error_rate

表示预计放入的元素数量

initial_size

bf.reserve 显式创建过滤器

布隆过滤器的使用

Java的 Guava带有布隆过滤器实现

布隆过滤器

内存回收因为c语言不具备自动内存回收功能，当将redisObject对象作为数据库的键或值而不是作为参数存储时其生命周期是非常长的，为了解决这个问题，Redis自己构建了一个内存回收机制，通过redisobject结构中的refcount实现.这个属性会随着对象的使用状态而不断变化。创建一个新对象，属性初始化为1对象被一个新程序使用，属性refcount加1对象不再被一个程序使用，属性refcount减1当对象的引用计数值变为0时，对象所占用的内存就会被释放

内存回收和内存共享

时间轴、队列应用场景设计

购物车开发与设计实战

Redis与Lua模拟抢红包实战

网站投票设计与开发实战

redis的使用场景

RESP协议

能谈下Redis的底层协议吗

基于TCP的应用层协议RESP

RESP底层使用的是TCP的连接方式，通过tcp进行数据传输，然后根据解析规则解析相应信息，完成交互

RESP是什么，在Redis怎么体现

redis的底层协议

基本知识

RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发

save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用

bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短

手动触发分别对应save和bgsave命令

使用save相关配置，如“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave。

执行debug reload命令重新加载Redis时，也会自动触发save操作。

默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则自动执行bgsave。

如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点，

自动触发RDB的持久

触发机制

执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进程，如RDB/AOF子进程，如果存在bgsave命令直接返回。

父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞，通过info stats命令查看latest_fork_usec选项，可以获取最近一个fork操作的耗时，单位为微秒

父进程fork完成后，bgsave命令返回“Background saving started”信息并不再阻塞父进程，可以继续响应其他命令。

子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。执行lastsave命令可以获取最后一次生成RDB的时间，对应info统计的rdb_last_save_time选项。

进程发送信号给父进程表示完成，父进程更新统计信息，具体见 info Persistence下的rdb_*相关选项。

执行流程

RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据快照。非常适用于备份，全量复制等场景。比如每6小时执行bgsave备份，并把RDB文件拷贝到远程机器或者文件系统中（如hdfs），用于灾难恢复。

Redis加载RDB恢复数据远远快于AOF的方式。

RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。

DB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题。

RDB

配置：appendonly yes，默认不开启

AOF文件名通过appendfilename配置设置，默认文件名是appendonly.aof

开启方式

追加到aof_buf（缓冲区）中

命令写入（append）

Redis使用单线程响应命令，如果每次写AOF文件命令都直接追加到硬盘，那么性能完全取决于当前硬盘负载。先写入缓冲区aof_buf中，还有另一个好处，Redis可以提供多种缓冲区同步硬盘的策略，在性能和安全性方面做出平衡

文件同步（sync）

进程内已经超时的数据不再写入文件。

旧的AOF文件含有无效命令，如del key1、hdel key2、srem keys、set a111、set a222等。重写使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令。

多条写命令可以合并为一个，如：lpush list a、lpush list b、lpush list c可以转化为：lpush list a b c。为了防止单条命令过大造成客户端缓冲区溢出，对于list、set、hash、zset等类型操作，以64个元素为界拆分为多条。

AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的

更小的AOF 文件可以更快地被Redis加载

·手动触发：直接调用bgrewriteaof命令。

·auto-aof-rewrite-min-size：表示运行AOF重写时文件最小体积，默认为64MB。

auto-aof-rewrite-percentage：代表当前AOF文件空间（aof_current_size）和上一次重写后AOF文件空间（aof_base_size）的比值。

自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机

自动触发时机=aof_current_size>auto-aof-rewrite-minsize&&（aof_current_size-aof_base_size）/aof_base_size>=auto-aof-rewritepercentage

触发

文件重写（rewrite）

AOF持久化开启且存在AOF文件时，优先加载AOF文件，

AOF关闭或者AOF文件不存在时，加载RDB文件，

加载AOF/RDB文件成功后，Redis启动成功。

AOF/RDB文件存在错误时，Redis启动失败并打印错误信息。

重启加载（load）

AOF

aof-use-rdb-preamble yes

如果开启了混合持久化，aof在重写时，不再是单纯将内存数据转换为RESP命令写入aof文件，而是将重写这一刻之前的内存做rdb快照处理，并且将rdb快照内容和增量的aof修改内存数据的命令存在一起，都写入新的aof文件，新的aof文件一开始不叫appendonly.aof，等到重写完成后，新的aof文件才会进行改名，原子的覆盖原有的aof文件，完成新旧两个aof文件的替换。于是在redis重启的时候，可以先加载rdb文件，然后再重放增量的aof日志就可以完全替代之前的aof全量文件重放，因此重启效率大幅得到提高。

Redis 4.0混合持久化

持久化

EVAL script numkeys key [key ...] arg [arg ...]

SCRIPT LOAD script

EVALSHA sha1 numkeys key [key ...] arg [arg ...]

SCRIPT EXISTS script [script ...]

SCRIPT FLUSH

SCRIPT KILL

基本用法

减少网络开销：多个请求通过脚本一次发送，减少网络延迟

原子操作：将脚本作为一个整体执行，中间不会插入其他命令，无需使用事务

复用：客户端发送的脚本永久存在redis中，其他客户端可以复用脚本

可嵌入性：可嵌入JAVA，C#等多种编程语言，支持不同操作系统跨平台交互

主要优势

Lua脚本

Publisher 往 channel 中发布消息时，关注了指定 channel 的 Consumer 就能够同时受到消息。

思路

关注方式（模式订阅）

# 订阅频道：SUBSCRIBE channel [channel ....] # 订阅给定的一个或多个频道的信息PSUBSCRIBE pattern [pattern ....] # 订阅一个或多个符合给定模式的频道# 发布频道：PUBLISH channel message # 将消息发送到指定的频道# 退订频道：UNSUBSCRIBE [channel [channel ....]] # 退订指定的频道PUNSUBSCRIBE [pattern [pattern ....]] #退订所有给定模式的频道

命令

不持久化消息：如果 Redis 停机重启，PubSub 的消息是不会持久化的，毕竟 Redis 宕机就相当于一个消费者都没有，所有的消息都会被直接丢弃。

没有 Ack 机制，也不保证数据的连续： PubSub 的生产者传递过来一个消息，Redis 会直接找到相应的消费者传递过去。如果没有一个消费者，那么消息会被直接丢弃。如果开始有三个消费者，其中一个突然挂掉了，过了一会儿等它再重连时，那么重连期间的消息对于这个消费者来说就彻底丢失了。

Redis 5.0 新增了 Stream 数据结构，这个功能给 Redis 带来了持久化消息队列

Redis Stream 从概念上来说，就像是一个仅追加内容的消息链表，把所有加入的消息都一个一个串起来，每个消息都有一个唯一的 ID 和内容，这很简单，让它复杂的是从 Kafka 借鉴的另一种概念：消费者组(Consumer Group) (思路一致，实现不同)

Consumer Group：消费者组，可以简单看成记录流状态的一种数据结构。消费者既可以选择使用 XREAD 命令进行独立消费，也可以多个消费者同时加入一个消费者组进行组内消费。同一个消费者组内的消费者共享所有的 Stream 信息，同一条消息只会有一个消费者消费到，这样就可以应用在分布式的应用场景中来保证消息的唯一性。

last_delivered_id：用来表示消费者组消费在 Stream 上消费位置的游标信息。每个消费者组都有一个 Stream 内唯一的名称，消费者组不会自动创建，需要使用 XGROUP CREATE 指令来显式创建，并且需要指定从哪一个消息 ID 开始消费，用来初始化 last_delivered_id 这个变量。

pending_ids：每个消费者内部都有的一个状态变量，用来表示已经被客户端获取，但是还没有 ack 的消息。记录的目的是为了保证客户端至少消费了消息一次，而不会在网络传输的中途丢失而没有对消息进行处理。如果客户端没有 ack，那么这个变量里面的消息 ID 就会越来越多，一旦某个消息被 ack，它就会对应开始减少。这个变量也被 Redis 官方称为 PEL (Pending Entries List)。

消息 ID 如果是由 XADD 命令返回自动创建的话，那么它的格式会像这样：timestampInMillis-sequence (毫秒时间戳-序列号)，例如 1527846880585-5，它表示当前的消息是在毫秒时间戳 1527846880585 时产生的，并且是该毫秒内产生的第 5 条消息。

这些 ID 的格式看起来有一些奇怪，为什么要使用时间来当做 ID 的一部分呢？一方面，我们要满足 ID 自增的属性，另一方面，也是为了支持范围查找的功能。由于 ID 和生成消息的时间有关，这样就使得在根据时间范围内查找时基本上是没有额外损耗的。

当然消息 ID 也可以由客户端自定义，但是形式必须是 \"整数-整数\"，而且后面加入的消息的 ID 必须要大于前面的消息 ID。

消息 ID

消息内容就是普通的键值对，形如 hash 结构的键值对。

消息内容

消息

xadd：追加消息

xdel：删除消息，这里的删除仅仅是设置了标志位，不影响消息总长度

xrange：获取消息列表，会自动过滤已经删除的消息

xlen：消息长度

del：删除Stream

增删改查示例

# 从Stream头部读取两条消息127.0.0.1:6379> xread count 2 streams codehole 0-01) 1) \"codehole\" 2) 1) 1) 1527851486781-0 2) 1) \"name\" 2) \"laoqian\" 3) \"age\" 4) \"30\" 2) 1) 1527851493405-0 2) 1) \"name\" 2) \"yurui\" 3) \"age\" 4) \"29\"# 从Stream尾部读取一条消息，毫无疑问，这里不会返回任何消息127.0.0.1:6379> xread count 1 streams codehole $(nil)# 从尾部阻塞等待新消息到来，下面的指令会堵住，直到新消息到来127.0.0.1:6379> xread block 0 count 1 streams codehole $# 我们从新打开一个窗口，在这个窗口往Stream里塞消息127.0.0.1:6379> xadd codehole * name youming age 601527852774092-0# 再切换到前面的窗口，我们可以看到阻塞解除了，返回了新的消息内容# 而且还显示了一个等待时间，这里我们等待了93s127.0.0.1:6379> xread block 0 count 1 streams codehole $1) 1) \"codehole\" 2) 1) 1) 1527852774092-0 2) 1) \"name\" 2) \"youming\" 3) \"age\" 4) \"60\"(93.11s)

独立消费示例

127.0.0.1:6379> xgroup create codehole cg1 0-0 # 表示从头开始消费OK# $表示从尾部开始消费，只接受新消息，当前Stream消息会全部忽略127.0.0.1:6379> xgroup create codehole cg2 $OK127.0.0.1:6379> xinfo codehole # 获取Stream信息 1) length 2) (integer) 3 # 共3个消息 3) radix-tree-keys 4) (integer) 1 5) radix-tree-nodes 6) (integer) 2 7) groups 8) (integer) 2 # 两个消费组 9) first-entry # 第一个消息10) 1) 1527851486781-0 2) 1) \"name\" 2) \"laoqian\" 3) \"age\" 4) \"30\"11) last-entry # 最后一个消息12) 1) 1527851498956-0 2) 1) \"name\" 2) \"xiaoqian\" 3) \"age\" 4) \"1\"127.0.0.1:6379> xinfo groups codehole # 获取Stream的消费组信息1) 1) name 2) \"cg1\" 3) consumers 4) (integer) 0 # 该消费组还没有消费者 5) pending 6) (integer) 0 # 该消费组没有正在处理的消息2) 1) name 2) \"cg2\" 3) consumers # 该消费组还没有消费者 4) (integer) 0 5) pending 6) (integer) 0 # 该消费组没有正在处理的消息

创建消费者示例

# >号表示从当前消费组的last_delivered_id后面开始读# 每当消费者读取一条消息，last_delivered_id变量就会前进127.0.0.1:6379> xreadgroup GROUP cg1 c1 count 1 streams codehole >1) 1) \"codehole\" 2) 1) 1) 1527851486781-0 2) 1) \"name\" 2) \"laoqian\" 3) \"age\" 4) \"30\"127.0.0.1:6379> xreadgroup GROUP cg1 c1 count 1 streams codehole >1) 1) \"codehole\" 2) 1) 1) 1527851493405-0 2) 1) \"name\" 2) \"yurui\" 3) \"age\" 4) \"29\"127.0.0.1:6379> xreadgroup GROUP cg1 c1 count 2 streams codehole >1) 1) \"codehole\" 2) 1) 1) 1527851498956-0 2) 1) \"name\" 2) \"xiaoqian\" 3) \"age\" 4) \"1\" 2) 1) 1527852774092-0 2) 1) \"name\" 2) \"youming\" 3) \"age\" 4) \"60\"# 再继续读取，就没有新消息了127.0.0.1:6379> xreadgroup GROUP cg1 c1 count 1 streams codehole >(nil)# 那就阻塞等待吧127.0.0.1:6379> xreadgroup GROUP cg1 c1 block 0 count 1 streams codehole ># 开启另一个窗口，往里塞消息127.0.0.1:6379> xadd codehole * name lanying age 611527854062442-0# 回到前一个窗口，发现阻塞解除，收到新消息了127.0.0.1:6379> xreadgroup GROUP cg1 c1 block 0 count 1 streams codehole >1) 1) \"codehole\" 2) 1) 1) 1527854062442-0 2) 1) \"name\" 2) \"lanying\" 3) \"age\" 4) \"61\"(36.54s)127.0.0.1:6379> xinfo groups codehole # 观察消费组信息1) 1) name 2) \"cg1\" 3) consumers 4) (integer) 1 # 一个消费者 5) pending 6) (integer) 5 # 共5条正在处理的信息还有没有ack2) 1) name 2) \"cg2\" 3) consumers 4) (integer) 0 # 消费组cg2没有任何变化，因为前面我们一直在操纵cg1 5) pending 6) (integer) 0# 如果同一个消费组有多个消费者，我们可以通过xinfo consumers指令观察每个消费者的状态127.0.0.1:6379> xinfo consumers codehole cg1 # 目前还有1个消费者1) 1) name 2) \"c1\" 3) pending 4) (integer) 5 # 共5条待处理消息 5) idle 6) (integer) 418715 # 空闲了多长时间ms没有读取消息了# 接下来我们ack一条消息127.0.0.1:6379> xack codehole cg1 1527851486781-0(integer) 1127.0.0.1:6379> xinfo consumers codehole cg11) 1) name 2) \"c1\" 3) pending 4) (integer) 4 # 变成了5条 5) idle 6) (integer) 668504# 下面ack所有消息127.0.0.1:6379> xack codehole cg1 1527851493405-0 1527851498956-0 1527852774092-0 1527854062442-0(integer) 4127.0.0.1:6379> xinfo consumers codehole cg11) 1) name 2) \"c1\" 3) pending 4) (integer) 0 # pel空了 5) idle 6) (integer) 745505

组内消费示例

定长 Stream 功能。在 xadd 的指令提供一个定长长度 maxlen，就可以将老的消息干掉，确保最多不超过指定长度，

Stream 消息太多怎么办？ | Stream 的上限

在客户端消费者读取 Stream 消息时，Redis 服务器将消息回复给客户端的过程中，客户端突然断开了连接，消息就丢失了。但是 PEL 里已经保存了发出去的消息 ID，待客户端重新连上之后，可以再次收到 PEL 中的消息 ID 列表。不过此时 xreadgroup 的起始消息 ID 不能为参数 > ，而必须是任意有效的消息 ID，一般将参数设为 0-0，表示读取所有的 PEL 消息以及自 last_delivered_id 之后的新消息。

PEL 是如何避免消息丢失的？

Redis 基于内存存储，这意味着它会比基于磁盘的 Kafka 快上一些，也意味着使用 Redis 我们不能长时间存储大量数据。不过如果您想以最小延迟实时处理消息的话，您可以考虑 Redis，但是如果消息很大并且应该重用数据的话，则应该首先考虑使用 Kafka。

另外从某些角度来说，Redis Stream 也更适用于小型、廉价的应用程序，因为 Kafka 相对来说更难配置一些。

Redis Stream Vs Kafka

Stream

发布订阅

Redis 可以通过 MULTI，EXEC，DISCARD 和 WATCH 等命令来实现事务(transaction)功能。

> MULTIOK> INCR fooQUEUED> INCR barQUEUED> EXEC1) (integer) 12) (integer) 1

使用 MULTI命令后可以输入多个命令。Redis不会立即执行这些命令，而是将它们放到队列，当调用了EXEC命令将执行所有命令。

Redis 是不支持 roll back 的，因而不满足原子性的（而且不满足持久性）。

Redis事务提供了一种将多个命令请求打包的功能。然后，再按顺序执行打包的所有命令，并且不会被中途打断。

jedis

Lettuce

Redission

Spring Data Redis

Java库

我们在系统中修改已有数据时，需要先读取，然后进行修改保存，此时很容易遇到并发问题。由于修改和保存不是原子操作，在并发场景下，部分对数据的操作可能会丢失。在单服务器系统我们常用本地锁来避免并发带来的问题，然而，当服务采用集群方式部署时，本地锁无法在多个服务器之间生效，这时候保证数据的一致性就需要分布式锁来实现。

为什么引入分布式锁

加锁命令：SETNX key value，当键不存在时，对键进行设置操作并返回成功，否则返回失败。KEY 是锁的唯一标识，一般按业务来决定命名。

解锁命令：DEL key，通过删除键值对释放锁，以便其他线程可以通过 SETNX 命令来获取锁。

Redis 锁主要利用 Redis 的 setnx 命令。

加锁解锁伪代码

如果 SETNX 成功，在设置锁超时时间后，服务器挂掉、重启或网络问题等，导致 EXPIRE 命令没有执行，锁没有设置超时时间变成死锁。

使用 lua 脚本

解决这个问题

SETNX 和 EXPIRE 非原子性

如果线程 A 成功获取到了锁，并且设置了过期时间 30 秒，但线程 A 执行时间超过了 30 秒，锁过期自动释放，此时线程 B 获取到了锁；随后 A 执行完成，线程 A 使用 DEL 命令来释放锁，但此时线程 B 加的锁还没有执行完成，线程 A 实际释放的线程 B 加的锁。

通过在 value 中设置当前线程加锁的标识，在删除之前验证 key 对应的 value 判断锁是否是当前线程持有。可生成一个 UUID 标识当前线程，使用 lua 脚本做验证标识和解锁操作。

// 加锁String uuid = UUID.randomUUID().toString().replaceAll(\"-\

锁误解除

如果线程 A 成功获取锁并设置过期时间 30 秒，但线程 A 执行时间超过了 30 秒，锁过期自动释放，此时线程 B 获取到了锁，线程 A 和线程 B 并发执行。

将过期时间设置足够长，确保代码逻辑在锁释放之前能够执行完成。

为获取锁的线程增加守护线程，为将要过期但未释放的锁增加有效时间。

A、B 两个线程发生并发显然是不被允许的，一般有两种方式解决该问题

超时解锁导致并发

当线程在持有锁的情况下再次请求加锁，如果一个锁支持一个线程多次加锁，那么这个锁就是可重入的。如果一个不可重入锁被再次加锁，由于该锁已经被持有，再次加锁会失败。

Redis 可通过对锁进行重入计数，加锁时加 1，解锁时减 1，当计数归 0 时释放锁。

本地记录重入次数虽然高效，但如果考虑到过期时间和本地、Redis 一致性的问题，就会增加代码的复杂性。另一种方式是 Redis Map 数据结构来实现分布式锁，既存锁的标识也对重入次数进行计数。

不可重入

上述命令执行都是立即返回的，如果客户端不可以等待锁释放就无法使用。

可以通过客户端轮询的方式解决该问题，当未获取到锁时，等待一段时间重新获取锁，直到成功获取锁或等待超时。这种方式比较消耗服务器资源，当并发量比较大时，会影响服务器的效率。

另一种方式是使用 Redis 的发布订阅功能，当获取锁失败时，订阅锁释放消息，获取锁成功后释放时，发送锁释放消息。

解决思路

无法等待锁释放

为了保证 Redis 的可用性，一般采用主从方式部署。主从数据同步有异步和同步两种方式，Redis 将指令记录在本地内存 buffer 中，然后异步将 buffer 中的指令同步到从节点，从节点一边执行同步的指令流来达到和主节点一致的状态，一边向主节点反馈同步情况。

在包含主从模式的集群部署方式中，当主节点挂掉时，从节点会取而代之，但客户端无明显感知。当客户端 A 成功加锁，指令还未同步，此时主节点挂掉，从节点提升为主节点，新的主节点没有锁的数据，当客户端 B 加锁时就会成功。

主备切换

集群脑裂指因为网络问题，导致 Redis master 节点跟 slave 节点和 sentinel 集群处于不同的网络分区，因为 sentinel 集群无法感知到 master 的存在，所以将 slave 节点提升为 master 节点，此时存在两个不同的 master 节点。Redis Cluster 集群部署方式同理。

当不同的客户端连接不同的 master 节点时，两个客户端可以同时拥有同一把锁。

集群脑裂

存在的问题

Redis 以其高性能著称，但使用其实现分布式锁来解决并发仍存在一些困难。Redis 分布式锁只能作为一种缓解并发的手段，如果要完全解决并发问题，仍需要数据库的防并发手段。

分布式锁与实现（二）—基于ZooKeeper实现

分布式锁与实现(一) —基于Redis实现

zookeeper分布式锁

Redis 分布式锁

slave启动后，向master发送SYNC命令，master接收到SYNC命令后通过bgsave保存快照（即上文所介绍的RDB持久化），并使用缓冲区记录保存快照这段时间内执行的写命令

master将保存的快照文件发送给slave，并继续记录执行的写命令

slave接收到快照文件后，加载快照文件，载入数据

master快照发送完后开始向slave发送缓冲区的写命令，slave接收命令并执行，完成复制初始化

此后master每次执行一个写命令都会同步发送给slave，保持master与slave之间数据的一致性

工作机制

master能自动将数据同步到slave，可以进行读写分离，分担master的读压力

master、slave之间的同步是以非阻塞的方式进行的，同步期间，客户端仍然可以提交查询或更新请求

不具备自动容错与恢复功能，master或slave的宕机都可能导致客户端请求失败，需要等待机器重启或手动切换客户端IP才能恢复

master宕机，如果宕机前数据没有同步完，则切换IP后会存在数据不一致的问题

难以支持在线扩容，Redis的容量受限于单机配置

redis的主从模式搭建及注意事项

主从复制模式

哨兵模式基于主从复制模式，只是引入了哨兵来监控与自动处理故障。

基本原理

监控master、slave是否正常运行

当master出现故障时，能自动将一个slave转换为master（大哥挂了，选一个小弟上位）

多个哨兵可以监控同一个Redis，哨兵之间也会自动监控

功能

定期（一般10s一次，当master被标记为主观下线时，改为1s一次）向master和slave发送INFO命令

定期向master和slave的_sentinel_:hello频道发送自己的信息

定期（1s一次）向master、slave和其他哨兵发送PING命令

一条连接用来订阅master的_sentinel_:hello频道与获取其他监控该master的哨兵节点信息

另一条连接定期向master发送INFO等命令获取master本身的信息

在配置文件中通过 sentinel monitor <master-name> <ip> <redis-port> <quorum> 来定位master的IP、端口，一个哨兵可以监控多个master数据库，只需要提供多个该配置项即可。

通过INFO命令，哨兵可以获取主从数据库的最新信息，并进行相应的操作，比如角色变更等。

获取到slave信息后，哨兵也会与slave建立两条连接执行监控。

选举采用Raft算法

发现master下线的哨兵节点（我们称他为A）向每个哨兵发送命令，要求对方选自己为领头哨兵

如果目标哨兵节点没有选过其他人，则会同意选举A为领头哨兵

如果有超过一半的哨兵同意选举A为领头，则A当选

如果有多个哨兵节点同时参选领头，此时有可能存在一轮投票无竞选者胜出，此时每个参选的节点等待一个随机时间后再次发起参选请求，进行下一轮投票竞选，直至选举出领头哨兵

所有在线的slave中选择优先级最高的，优先级可以通过slave-priority配置

如果有多个最高优先级的slave，则选取复制偏移量最大（即复制越完整）的当选

如果以上条件都一样，选取id最小的slave

选出领头哨兵后，领头者开始对系统进行故障恢复，从出现故障的master的从数据库中挑选一个来当选新的master

哨兵模式基于主从复制模式，所以主从复制模式有的优点，哨兵模式也有

哨兵模式下，master挂掉可以自动进行切换，系统可用性更高

样也继承了主从模式难以在线扩容的缺点，Redis的容量受限于单机配置

需要额外的资源来启动sentinel进程，实现相对复杂一点，同时slave节点作为备份节点不提供服务

Sentinel 模式

Cluster模式实现了Redis的分布式存储，即每台节点存储不同的内容，来解决在线扩容的问题。

节点的fail是通过集群中超过半数的节点检测失效时才生效

无中心结构

在Redis的每个节点上，都有一个插槽（slot），取值范围为0-16383

当我们存取key的时候，Redis会根据CRC16的算法得出一个结果，然后把结果对16384求余数，这样每个key都会对应一个编号在0-16383之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作

为了保证高可用，Cluster模式也引入主从复制模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点

当其它主节点ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点都宕机了，那么该集群就无法再提供服务了

Cluster模式集群节点最小配置6个节点(3主3从，因为需要半数以上)，其中主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用。

无中心架构，数据按照slot分布在多个节点。

集群中的每个节点都是平等的关系，每个节点都保存各自的数据和整个集群的状态。每个节点都和其他所有节点连接，而且这些连接保持活跃，这样就保证了我们只需要连接集群中的任意一个节点，就可以获取到其他节点的数据。

可线性扩展到1000多个节点，节点可动态添加或删除

能够实现自动故障转移，节点之间通过gossip协议交换状态信息，用投票机制完成slave到master的角色转换

客户端实现复杂，驱动要求实现Smart Client，缓存slots mapping信息并及时更新，提高了开发难度。目前仅JedisCluster相对成熟，异常处理还不完善，比如常见的“max redirect exception”

节点会因为某些原因发生阻塞（阻塞时间大于 cluster-node-timeout）被判断下线，这种failover是没有必要的

数据通过异步复制，不保证数据的强一致性

slave充当“冷备”，不能缓解读压力

批量操作限制，目前只支持具有相同slot值的key执行批量操作，对mset、mget、sunion等操作支持不友好

key事务操作支持有线，只支持多key在同一节点的事务操作，多key分布不同节点时无法使用事务功能

不支持多数据库空间，单机redis可以支持16个db，集群模式下只能使用一个，即db 0

Cluster 模式

基于客户端分片

Twemproxy

Codis

企业部署方案

简单来说 Redis 就是一个使用 C 语言开发的数据库，不过与传统数据库不同的是 Redis 的数据是存在内存中的，也就是它是内存数据库，所以读写速度非常快，因此 Redis 被广泛应用于缓存方向。

另外，Redis 除了做缓存之外，Redis 也经常用来做分布式锁，甚至是消息队列。

Redis 提供了多种数据类型来支持不同的业务场景。Redis 还支持事务、持久化、Lua 脚本、多种集群方案。

简单介绍一下 Redis 呗!

分布式缓存的话，使用的比较多的主要是 Memcached 和 Redis。不过，现在基本没有看过还有项目使用 Memcached 来做缓存，都是直接用 Redis。

Memcached 是分布式缓存最开始兴起的那会，比较常用的。后来，随着 Redis 的发展，大家慢慢都转而使用更加强大的 Redis 了。

分布式缓存主要解决的是单机缓存的容量受服务器限制并且无法保存通用的信息。因为，本地缓存只在当前服务里有效，比如如果你部署了两个相同的服务，他们两者之间的缓存数据是无法共同的。

分布式缓存常见的技术选型方案有哪些？

都是基于内存的数据库，一般都用来当做缓存使用。

都有过期策略。

两者的性能都非常高。

共同点

Redis 支持更丰富的数据类型（支持更复杂的应用场景）。Redis 不仅仅支持简单的 k/v 类型的数据，同时还提供 list，set，zset，hash 等数据结构的存储。Memcached 只支持最简单的 k/v 数据类型。

Redis 有灾难恢复机制。因为可以把缓存中的数据持久化到磁盘上。

Redis 在服务器内存使用完之后，可以将不用的数据放到磁盘上。但是，Memcached 在服务器内存使用完之后，就会直接报异常。

Memcached 没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据；但是 Redis 目前是原生支持 cluster 模式的.

Memcached 是多线程，非阻塞 IO 复用的网络模型；Redis 使用单线程的多路 IO 复用模型。（Redis 6.0 引入了多线程 IO ）

Redis 支持发布订阅模型、Lua 脚本、事务等功能，而 Memcached 不支持。并且，Redis 支持更多的编程语言。

Memcached过期数据的删除策略只用了惰性删除，而 Redis 同时使用了惰性删除与定期删除。

区别

说一下 Redis 和 Memcached 的区别和共同点

操作缓存就是直接操作内存，所以速度相当快。

一般像 MySQL 这类的数据库的 QPS 大概都在 1w 左右（4 核 8g），但是使用 Redis 缓存之后很容易达到 10w+，甚至最高能达到 30w+（就单机 redis 的情况，redis 集群的话会更高）。

直接操作缓存能够承受的数据库请求数量是远远大于直接访问数据库的，所以我们可以考虑把数据库中的部分数据转移到缓存中去，这样用户的一部分请求会直接到缓存这里而不用经过数据库。进而，我们也就提高的系统整体的并发。

为什么要用 Redis/为什么要用缓存？

这套事件处理模型对应的是 Redis 中的文件事件处理器（file event handler）。由于文件事件处理器（file event handler）是单线程方式运行的，所以我们一般都说 Redis 是单线程模型。

Redis 基于 Reactor 模式来设计开发了自己的一套高效的事件处理模型

I/O 多路复用技术的使用让 Redis 不需要额外创建多余的线程来监听客户端的大量连接，降低了资源的消耗（和 NIO 中的 Selector 组件很像）。

Redis 通过IO 多路复用程序来监听来自客户端的大量连接（或者说是监听多个 socket），它会将感兴趣的事件及类型(读、写）注册到内核中并监听每个事件是否发生。

Redis 单线程模型

Redis 4.0 增加的多线程主要是针对一些大键值对的删除操作的命令，使用这些命令就会使用主处理之外的其他线程来“异步处理”。

虽然说 Redis 是单线程模型，但是，实际上，Redis 在 4.0 之后的版本中就已经加入了对多线程的支持。

单线程编程容易并且更容易维护；

Redis 的性能瓶颈不再 CPU ，主要在内存和网络；

多线程就会存在死锁、线程上下文切换等问题，甚至会影响性能。

为什么不使用多线程

Redis 没有使用多线程？为什么不使用多线程？

Redis6.0 引入多线程主要是为了提高网络 IO 读写性能

虽然，Redis6.0 引入了多线程，但是 Redis 的多线程只是在网络数据的读写这类耗时操作上使用了，执行命令仍然是单线程顺序执行。

io-threads-do-reads yes

io-threads 4 #官网建议4核的机器建议设置为2或3个线程，8核的建议设置为6个线程

Redis6.0 的多线程默认是禁用的，只使用主线程。

Redis6.0 之后为何引入了多线程？

因为内存是有限的，如果缓存中的所有数据都是一直保存的话，分分钟直接Out of memory。

比如我们的短信验证码可能只在1分钟内有效，用户登录的 token 可能只在 1 天内有效

Redis 给缓存数据设置过期时间有啥用？

Redis 通过一个叫做过期字典（可以看作是hash表）来保存数据过期的时间。过期字典的键指向Redis数据库中的某个key(键)，过期字典的值是一个long long类型的整数，这个整数保存了key所指向的数据库键的过期时间（毫秒精度的UNIX时间戳）。

Redis是如何判断数据是否过期的呢？

惰性删除：只会在取出key的时候才对数据进行过期检查。这样对CPU最友好，但是可能会造成太多过期 key 没有被删除。

定期删除：每隔一段时间抽取一批 key 执行删除过期key操作。并且，Redis 底层会并通过限制删除操作执行的时长和频率来减少删除操作对CPU时间的影响。

扩展仅仅通过给 key 设置过期时间还是有问题的。因为还是可能存在定期删除和惰性删除漏掉了很多过期 key 的情况。这样就导致大量过期 key 堆积在内存里，然后就Out of memory了。怎么解决这个问题呢？答案就是： Redis 内存淘汰机制。

过期的数据的删除策略了解么？

volatile-lru（least frequently used）：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰

volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰

volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰

allkeys-lru（least recently used）：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 key（这个是最常用的）

allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰

no-eviction：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。这个应该没人使用吧！

4.0 版本后增加volatile-lfu：从已设置过期时间的数据集(server.db[i].expires)中挑选最不经常使用的数据淘汰

4.0 版本后增加allkeys-lfu：当内存不足以容纳新写入数据时，在键空间中，移除最不经常使用的 key

Redis 内存淘汰机制了解么？

见数据库 -> NoSql -> Redis -> 持久化

Redis 持久化机制

跟计算机性能有关10万

redis的并发量是多少

redis 实际上是个单线程工作模型

redis的线程模型是什么

Redis五种数据类型及应用场景

string

hash

list

set

zset

五种数据类型

redis的数据类型有哪些

expire key time(以秒为单位)--这是最常用的方式

设置过期时间

定时删除

惰性删除为redis服务器内置策略

惰性删除

第一、配置redis.conf 的hz选项，默认为10 （即1秒执行10次，100ms一次，值越大说明刷新频率越快，最Redis性能损耗也越大）

第二、配置redis.conf的maxmemory最大值，当已用内存超过maxmemory限定时，就会触发主动清理策略

定期删除

三种过期策略

redis使用的过期策略：惰性删除+定期删除

redis的过期策略详解

redis的过期策略

多个 socket

IO 多路复用程序

文件事件分派器

事件处理器（连接应答处理器、命令请求处理器、命令回复处理器）

文件事件处理器是单线程的

1.纯内存操作

2.核心是基于非阻塞的 IO 多路复用机制

3.单线程反而避免了多线程的频繁上下文切换问题

为啥 redis 单线程模型也能效率这么高

为什么redis是单线程的但是还可以支撑高并发

redis 实现高并发主要依靠主从架构，一主多从

高并发的同时，容纳大量的数据，需要redis集群

redis 高可用，如果是做主从架构部署，那么加上哨兵就可以了

怎么保证redis是高并发以及高可用的

Redis数据备份和重启恢复

怎么保证redis挂掉之后再重启数据可以进行恢复

聊聊redis cluster集群模式的原理

事前：redis高可用，主从+哨兵，redis cluster，避免全盘崩溃

事中：本地ehcache缓存 + hystrix限流&降级，避免MySQL被打死

事后：redis持久化，快速恢复缓存数据

解决缓存雪崩的方案

每次系统A从数据库只要没有查到，就写一个空值到缓存里去

缓存穿透现象以及解决方案

一般如何应对缓存雪崩以及穿透问题吗

如何保证缓存与数据库双写时的数据一致性

什么是Redis的并发竞争问题

redis的并发竞争问题该如何解决

生产环境的redis集群的部署架构是什么样的

常见分布式缓存问题

使用分布式缓存的时候存在问题

redis的工作原理

分布式系统常见的几个问题和解决办法

分布式session问题

分布式跨域问题

分步式事务

分布式任务调度

分布式锁

分布式幂等性

更新数据时，是先删除缓存再更新DB，还是先更新DB再删除缓存？

分布式缓存

分布式系统的问题

完善_Redis高性能缓存数据库

redis高性能数据库

java中常用的几种缓存类型

页面缓存

浏览器缓存

App客户端缓存

客户端缓存

代理缓存

CDN缓存

网络缓存

数据库缓存

平台缓存级缓存

服务器缓存

计算机缓存的分类

FIFO：First In First Out，先进先出。

LRU：Least Recently Used，最近最少使用

LFU：Least Frequently Used，最不经常使用

Ehcache缓存过期策略

@Cacheable(value = "myToken")

SpringBoot2.0整合Ehcache缓存技术

springboot整合Ehcache网络教程

Ehcache缓存使用

本地缓存Ehcache

Spring+ehcache+redis两级缓存--缓存实战篇（1）

Ehcache与redis整合网络教程

Ehcache与redis整合

深度解析SpringBoot2.x整合Spring-Data-Redis

SpringBoot整合Redis，RedisTemplate和注解两种方式的使用

spring + redis + spring-data-redis2.0.10 整合-单机版

spring + redis + spring-data-redis2.0.10 整合-redis Cluster版

springboot之使用redistemplate优雅地操作redis

文档教程

spring整合redis缓存

更新DB缓存网络教程

如果删了缓存，还没有来得及写库，另一个线程就来读取，发现缓存为空，则去数据库中读取数据写入缓存，此时缓存中为脏数据

如果先写了库，再删除缓存前，写库后没有删除掉缓存，则也会出现数据不一致情况

如果是redis集群，或者主从模式，写主读从，由于redis复制存在一定的时间延迟，也有可能导致数据不一致

出现不同步的情况

缓存与DB不同步解决网络教程

采用延时双删策略（双淘汰策略）

设置缓存过期时间

异步更新缓存(基于订阅binlog的同步机制)

缓存与DB不同步解决

缓存与DB存在不同步

REDIS 缓存的穿透，雪崩和热点key

Redis缓存雪崩、缓存穿透、热点Key解决方案和分析

缓存穿透、缓存击穿、缓存雪崩区别和解决方案

缓存三大问题及解决方案

缓存击穿、穿透、雪崩

缓存击穿

缓存穿透

缓存雪崩

redis缓存引发问题

redis高速缓存系统

Session 是客户端与服务器通讯会话技术，比如浏览器登陆、记录整个浏览会话信息

服务器session作用

session是存放在服务器上，客户端会使用同一个Sessionid在多个不同的服务器上获取对应的Session，从而会导致Session不一致问题

分布式session不一致

没有负载均衡

使同一个ip的请求发到同一台服务器

用Nginx 做的负载均衡可以添加ip_hash这个配置

用haproxy做的负载均衡可以用 balance source这个配置

基于令牌（Token）方式实现Session解决方案，因为Session本身就是分布式共享连接

分布式session之token解决方案实现

使用Session集群令牌存放Redis

把session值缓存到redis中

SpringBoot+SpringSession+Redis分布式Session解决方案

springboot2.1入门系列四 Spring Session实现session共享

spring-session-data-redis框架步骤教程

spring-session-data-redis框架整合

分布式Session一致性解决方案

redis分布式session

解决同一业务数据并发处理方案

出现分布式锁的原因

Spring-data-redis + redis 分布式锁（一）

Spring-data-redis + redis 分布式锁（二）

redis系列：基于redis的分布式锁

大牛技术系列教程

spring redis锁实例

Docker安装Zookeeper并进行操作

zookeeper网络教程

zookeeper基本操作

注册中心

配置中心

消息中间件

分布式事务

选举策略

负载均衡

zookeeper应用场景

redis分布式线程锁

Java并发：分布式应用限流 Redis + Lua 实践

接口限流算法：漏桶算法&令牌桶算法

redis令牌桶限流器

【Redis使用系列】使用Redis做防止重复提交

redis防止重复提交

redis的网站计数器

redis列表消息队列

springboot+shiro+redis项目整合

shiro整合redis使用

redis整合主要框架

redis应用

Redis

Mongodb

Neo4j

Hbase

MemcacheDB

NoSQL数据库

InfluxDB

ElasticSearch

Prometheus

········

时序数据库

空间换时间

CPU Cache 缓存的是内存数据用于解决 CPU 处理速度和内存不匹配的问题，内存缓存的是硬盘数据用于解决硬盘访问速度过慢的问题。再比如操作系统在页表方案基础之上引入了快表来加速虚拟地址到物理地址的转换。我们可以把块表理解为一种特殊的高速缓冲存储器（Cache）。

我们为了避免用户在请求数据的时候获取速度过于缓慢，所以我们在数据库之上增加了缓存这一层来弥补。

为什么引入缓存

系统复杂性增加：引入缓存之后，你要维护缓存和数据库的数据一致性、维护热点缓存等等。

系统开发成本往往会增加：引入缓存意味着系统需要一个单独的缓存服务，这是需要花费相应的成本的，并且这个成本还是很贵的，毕竟耗费的是宝贵的内存。但是，如果你只是简单的使用一下本地缓存存储一下简单的数据，并且数据量不大的话，那么就不需要单独去弄一个缓存服务。

缓存带来的问题

HashMap 和 ConcurrentHashMap

Ehcache 、 Guava Cache 、 Spring Cache、Caffeine

本地缓存

本地缓存容量受服务部署所在的机器限制明显。如果当前系统服务所耗费的内存多，那么本地缓存可用的容量就很少。

本地缓存对分布式架构支持不友好，比如同一个相同的服务部署在多台机器上的时候，各个服务之间的缓存是无法共享的，因为本地缓存只在当前机器上有。

写：更新 DB，然后直接删除 cache 。读：从 cache 中读取数据，读取到就直接返回，读取不到的话，就从 DB 中取数据返回，然后再把数据放到 cache 中。Cache Aside Pattern 中服务端需要同时维系 DB 和 cache，并且是以 DB 的结果为准。另外，Cache Aside Pattern 有首次请求数据一定不在 cache 的问题，对于热点数据可以提前放入缓存中。Cache Aside Pattern 是我们平时使用比较多的一个缓存读写模式，比较适合读请求比较多的场景。

缓存失效时间变短（不推荐，治标不治本）：我们让缓存数据的过期时间变短，这样的话缓存就会从数据库中加载数据。另外，这种解决办法对于先操作缓存后操作数据库的场景不适用。

增加cache更新重试机制（常用）：如果 cache 服务当前不可用导致缓存删除失败的话，我们就隔一段时间进行重试，重试次数可以自己定。如果多次重试还是失败的话，我们可以把当前更新失败的 key 存入队列中，等缓存服务可用之后，再将缓存中对应的 key 删除即可。

如果更新数据库成功，而删除缓存这一步失败的情况的话，简单说两个解决方案

Cache Aside Pattern（旁路缓存模式）

Read/Write Through 套路是：服务端把 cache 视为主要数据存储，从中读取数据并将数据写入其中。cache 服务负责将此数据读取和写入 DB，从而减轻了应用程序的职责。写（Write Through）：先查 cache，cache 中不存在，直接更新 DB。 cache 中存在，则先更新 cache，然后 cache 服务自己更新 DB（同步更新 cache 和 DB）。读(Read Through)：从 cache 中读取数据，读取到就直接返回。读取不到的话，先从 DB 加载，写入到 cache 后返回响应。Read-Through Pattern 实际只是在 Cache-Aside Pattern 之上进行了封装。在 Cache-Aside Pattern 下，发生读请求的时候，如果 cache 中不存在对应的数据，是由客户端自己负责把数据写入 cache，而 Read Through Pattern 则是 cache 服务自己来写入缓存的，这对客户端是透明的。和 Cache Aside Pattern 一样， Read-Through Pattern 也有首次请求数据一定不再 cache 的问题，对于热点数据可以提前放入缓存中。

Read/Write Through Pattern（读写穿透）

Write Behind Pattern 和 Read/Write Through Pattern 很相似，两者都是由 cache 服务来负责 cache 和 DB 的读写。但是，两个又有很大的不同：Read/Write Through 是同步更新 cache 和 DB，而 Write Behind Caching 则是只更新缓存，不直接更新 DB，而是改为异步批量的方式来更新 DB。Write Behind Pattern 下 DB 的写性能非常高，尤其适合一些数据经常变化的业务场景比如说一篇文章的点赞数量、阅读数量。往常一篇文章被点赞 500 次的话，需要重复修改 500 次 DB，但是在 Write Behind Pattern 下可能只需要修改一次 DB 就可以了。但是，这种模式同样也给 DB 和 Cache 一致性带来了新的考验，很多时候如果数据还没异步更新到 DB 的话，Cache 服务宕机就 gg 了。

Write Behind Pattern（异步缓存写入）

缓存读写模式/更新策略

缓存穿透说简单点就是大量请求的 key 根本不存在于缓存中，导致请求直接到了数据库上，根本没有经过缓存这一层。举个例子：某个黑客故意制造我们缓存中不存在的 key 发起大量请求，导致大量请求落到数据库。

最基本的就是首先做好参数校验，一些不合法的参数请求直接抛出异常信息返回给客户端。比如查询的数据库 id 不能小于 0、传入的邮箱格式不对的时候直接返回错误消息给客户端等等。

缓存无效 key

解决办法

缓存在同一时间大面积的失效，后面的请求都直接落到了数据库上，造成数据库短时间内承受大量请求。

采用 Redis 集群，避免单机出现问题整个缓存服务都没办法使用。

限流，避免同时处理大量的请求。

针对 Redis 服务不可用的情况

设置不同的失效时间比如随机设置缓存的失效时间。

缓存永不失效。

针对热点缓存失效的情况

见数据库 -> 缓存 -> 缓存读写模式（更新策略）

如何保证缓存和数据库数据的一致性

数据库

HTTP协议就是客户端和服务器交互的一种通迅的格式

GET

PUT

HEAD

DELETE

POST

OPTIONS

HTTP提供了好几种方法给我们使用

总的来说：我们现在盛行的RESTful风格就是充分利用了这些方法

告知服务器意图

在HTTP1.0的时候，每一次进行HTTP通信就会断开一次连接

在HTTP1.1版本，就是持久连接了。一次HTTP连接能够处理多个请求

持久连接为“管线化”方式发送成为了可能：在一次HTTP连接里面，不需要等待服务器响应请求，就能够继续发送第二次请求

持久连接

200 正常处理

204 成功处理，但服务器没有新数据返回，显示页面不更新

206 对服务器进行范围请求，只返回一部分数据

 2XX--一般表示为成功处理

301 请求的资源已分配了新的URI中，URL地址改变了。【永久重定向】

302 请求的资源临时分配了新的URI中，URL地址没变【转发】

303 与302相同的功能，但明确客户端应该采用GET方式来获取资源

304 发送了附带请求，但不符合条件【返回未过期的缓存数据】

307 与302相同，但不会把POST请求变成GET

 3XX--一般表示为重定向

400 请求报文语法错误了

401 需要认证身份

403 没有权限访问

404 服务器没有这个资源

4XX--客户端出错

500 内部资源出错了

503 服务器正忙

5XX--服务器出错

常用状态码

HTTPS就是披着SSL的HTTP

HTTP在建立通信线路的时候使用公开私有密钥，当建立完连接后，随后就使用共享密钥进行加密和解密了

HTTPS是基于第三方的认证机构来获取认受认可的证书

用户向web服务器发起一个安全连接的请求服务器返回经过CA认证的数字证书，证书里面包含了服务器的public key(公钥)用户拿到数字证书，用自己浏览器内置的CA证书解密得到服务器的public key用户用服务器的public key加密一个用于接下来的对称加密算法的密钥，传给web服务器4.1因为只有服务器有private key可以解密，所以不用担心中间人拦截这个加密的密钥服务器拿到这个加密的密钥，解密获取密钥，再使用对称加密算法，和用户完成接下来的网络通信

过程

HTTPS简述

DNS：负责解析域名

 HTTP：产生请求报文数据

TCP协议：分割HTTP数据，保证数据运输

IP协议：传输数据包，找到通信目的地地址。

网站通信粗略过程

HTTP是无状态的，也就是说，它是不对通信状态进行保存的。它并不知道之前通信的对方是谁

由于我们很多时候都是需要知道对方是谁，于是我们就有了Cookie来解决

HTTP是不保存状态的协议

使用压缩技术把实体主体压小，在客户端再把数据解析

这种技术可以实现断点续传

使用分块传输编码，将实体主体分块传输，当浏览器解析到实体主体就能够显示了。

提升传输效率

代理

 能够提供非HTTP请求的操作，访问数据库什么的

网关

建立一条安全的通信路径，可以使用SSL等加密手段进行通信。

隧道

服务器与客户端之间的应用程序

a、请求行：包含请求方法、URI、HTTP版本信息b、请求首部字段c、请求内容实体d、空行

请求报文

A：一个状态行【用于描述服务器对请求的处理结果。】B：首部字段【用于描述服务器的基本信息，以及数据的描述，服务器通过这些数据的描述信息，可以通知客户端如何处理等一会儿它回送的数据】C：一个空行D：实体内容【服务器向客户端回送的数据】

响应报文

HTTP请求和响应报文组成

a、默认持久连接节省通信量，只要客户端服务端任意一端没有明确提出断开TCP连接，就一直保持连接，可以发送多次HTTP请求

b、管线化，客户端可以同时发出多个HTTP请求，而不用一个个等待响应（理论->未实践）

c、断点续传：实际上就是利用HTTP消息头使用分块传输编码，将实体主体分块传输。

HTTP1.1版本新特性

HTTP2与HTTP1.1最重要的区别就是解决了线头阻塞的问题！其中最重要的改动是：多路复用 (Multiplexing)

HTTP2所有性能增强的核心在于新的二进制分帧层(不再以文本格式来传输了)

使用HPACK对HTTP/2头部压缩

服务器推送

流量控制(针对传输中的流进行控制(TCP默认的粒度是针对连接))

流优先级（Stream Priority）它被用来告诉对端哪个流更重要。

其他重要改动

HTTP2

HTTP

OSI（Open System Interconnection）参考模型是国际标准化组织（ISO）制定的一个用于计算机或通信系统间互联的标准体系，一般称为OSI参考模型或七层模型。

只要遵循这个七层协议就可以实现计算机互联

所有与网络有关的

定义物理设备标准

物理层

将物理层接收的数据进行MAC（媒体访问控制）地址的封装和解封装，也可以简单的理解为物理寻址

网卡，交换机

STP

数据链路层

控制子网的运行，如逻辑编址，分组传输，路由

网络层

定义一些传输数据的协议和端口。

TCP

UDP

传输层

负责在网络中的两节点建立，维持和终止通信

会话层

确保一个系统的应用层发送的消息可以被另一个系统的应用层读取

Telnet

表示层

文件传输，文件管理，电子邮件的信息处理

应用层

OSI七层模型及各层作用

OSI七层模型

TCP 是面向连接的、可靠的流协议，通过三次握手建立连接，通讯完成时要拆除连接。

UDP是面向无连接的通讯协议，UDP通讯时不需要接收方确认，属于不可靠的传输，可能会出现丢包现象。

TCP 和 UDP

通俗易懂地讲解TCP建立连接的三次握手和释放连接的四次挥手

理解TCP/IP三次握手与四次挥手的正确姿势

ACK ： TCP协议规定，只有ACK=1时有效，也规定连接建立后所有发送的报文的ACK必须为1

FIN （finis）即完，终结的意思，用来释放一个连接。当 FIN = 1 时，表明此报文段的发送方的数据已经发送完毕，并要求释放连接。

名词解释

第一次握手：客户端将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给服务器端，客户端进入SYN_SENT状态，等待服务器端确认。

第二次握手：服务器端收到数据包后由标志位SYN=1知道客户端请求建立连接，服务器端将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给客户端以确认连接请求，服务器端进入SYN_RCVD状态。

第三次握手：客户端收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给服务器端，服务器端检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，客户端和服务器端进入ESTABLISHED状态，完成三次握手，随后客户端与服务器端之间可以开始传输数据了。

三次握手

第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。

第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。

第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。

第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。

四次挥手

三次握手和四次挥手

TCP/IP中的数据包

TCP 中通过序列号与确认应答提高可靠性

TCP/IP协议

网络编程基础（网络基本知识）

Socket其实就是一个门面模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面

主机 A 的应用程序要能和主机 B 的应用程序通信，必须通过 Socket 建立连接，而建立 Socket 连接必须需要底层TCP/IP 协议来建立 TCP 连接。

建立 TCP 连接需要底层 IP 协议来寻址网络中的主机。

Socket套接字

HTTP是无状态的，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接

短连接是指SOCKET连接后发送后接收完数据后马上断开连接

连接->传输数据->关闭连接

WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源

短连接

长连接指建立SOCKET连接后不管是否使用都保持连接，但安全性较差。

连接->传输数据->保持连接 -> 传输数据-> 。。。 ->关闭连接

数据库的连接用长连接，如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费

长连接

网络编程常见术语

网络

awkhttps://blog.viakiba.cn/2020/07/17/Linux%E5%91%BD%E4%BB%A4%E4%B9%8BAWK/

grephttps://blog.viakiba.cn/2020/07/17/Linux%E5%91%BD%E4%BB%A4%E4%B9%8BGREP/

sedhttps://blog.viakiba.cn/2020/07/17/Linux%E5%91%BD%E4%BB%A4%E4%B9%8BSED/

screen

lsof

rsync

scp

..........

ifconfig：查看网络接口信息

ifup/ifdown：开启或关闭接口

网络接口相关

route命令：可以临时地设置内核路由表

hostname命令：可以临时地修改主机名

sysctl命令：可以临时地开启内核的包转发

 ifconfig命令：可以临时地设置网络接口的IP参数

临时配置相关

ifconfig 检测网络接口配置route 检测路由配置ping 检测网络连通性netstat 查看网络状态lsof 查看指定IP 和/或端口的进程的当前运行情况host/dig/nslookup 检测DNS解析traceroute 检测到目的主机所经过的路由器tcpdump 显示本机网络流量的状态

网络检测的常用工具：

yum

rpm

wget

安装软件

网络管理

添加用户

useradd

修改用户

usermod

删除用户

userdel

用户管理

添加组

groupadd

修改组

groupmod

删除组

groupdel

组管理

成批添加/更新一组账户：newusers

成批更新用户的口令：chpasswd

 批量管理用户：

向标准组中添加用户gpasswd -a <用户账号名> <组账号名>usermod -G <组账号名> <用户账号名>从标准组中删除用户gpasswd -d <用户账号名> <组账号名>

组成员管理：

修改 /etc/login.defs 的相关配置参数

 口令时效设置：

passwd

 口令维护(禁用、恢复和删除用户口令)：

change

设置已存在用户的口令时效：

口令管理

sudo

切换用户

id：显示用户当前的uid、gid和用户所属的组列表

groups：显示指定用户所属的组列表

whoami：显示当前用户的名称

w/who：显示登录用户及相关信息

newgrp：用于转换用户的当前组到指定的组账号，用户必须属于该组才可以正确执行该命令

用户相关的命令：

管理用户

查看文本文件内容

cat

可以分页看

不仅可以分页，还可以方便地搜索，回翻等操作

less

查看文件的尾部的10行

tail -10

查看文件的头部20行

head -20

查看文件

显示文件和目录列表

切换目录

显示当前工作目录

pwd

创建目录

mkdir

删除空目录

rmdir

生成一个空文件或更改文件的时间

touch

复制文件或目录

删除文件或目录

建立链接文件

查找文件

find

查看文件类型或文件属性信息

file/stat

把内容重定向到指定的文件中，有则打开，无则创建

echo

将前面的结果给后面的命令，例如：`ls -la | wc `，将ls的结果加油wc命令来统计字数

管道命令 |

重定向 > 是覆盖模式，>> 是追加模式

文件和目录的操作

ps：查找出进程的信息

nice和renice：调整进程的优先级

kill：杀死进程

 free：查看内存使用状况

 top ：查看实时刷新的系统进程信息

jobs：列举作业号码和名称

bg： 在后台恢复运行

fg：在前台恢复运行

ctrl+z：暂时停止某个进程

作业管理

cron

自动化任务

chkconfig

service

 ntsysv

管理守护进程

进程管理

gzip filename

bzip2 filename

tar -czvf filename

压缩

gzip -d filename.gz

bzip2 -d filename.bz2

tar -xzvf filename.tar.gz

解压

打包和压缩文件

在文件 myfile 中查找包含字符串 mystr的行

grep -n mystr myfile

显示 myfile 中第一个字符为字母的所有行

grep '^[a-zA-Z]' myfile

grep+正则表达式

G 用于直接跳转到文件尾

ZZ 用于存盘退出Vi

ZQ 用于不存盘退出Vi

/和？ 用于查找字符串

n 继续查找下一个

yy 复制一行

p 粘帖在下一行，P粘贴在前一行

dd 删除一行文本

u 取消上一次编辑操作（undo）

普通模式

使用i或a或o进去插入模式

使用esc返回普通模式

插入模式

w  保存当前编辑文件，但并不退出

w   newfile 存为另外一个名为 “newfile” 的文件

wq   用于存盘退出Vi

q!   用于不存盘退出Vi

q   用于直接退出Vi （未做修改)

命令行模式

set noautoindent 取消缩进

set number 在编辑文件时显示行号

set tabstop=value 设置显示制表符的空格字符个数

set 显示设置的所有选项

设置Vi环境

vim常用命令总结

Vi编辑器

改变文件或目录的权限：chmod

改变文件或目录的属主（所有者）：chown

改变文件或目录所属的组：chgrp

设置文件的缺省生成掩码：umask

显示扩展属性：lsattr [-adR] [文件|目录]修改扩展属性：chattr [-R] [[-+=][属性]] <文件|目录>

文件扩展属性

权限管理

查看linux内核版本

查看GCC版本gcc -v

查看glibc版本ldd --version

查看发行版信息cat /etc/redhat-release

查看linux环境

Linux命令速查

Linux命令大全

Linux关闭开启防火墙

详细汇总

Linux

Https配置

正向代理类似一个跳板机，代理访问外部资源

客户端必须设置正向代理服务器，当然前提是要知道正向代理服务器的IP地址，还有代理程序的端口。

举例说明

正向代理是一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)

然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端必须要进行一些特别的设置才能使用正向代理。

正向代理总结

（1）访问原来无法访问的资源，如google

（2）可以做缓存，加速访问资源

（3）对客户端访问授权，上网进行认证

（4）代理可以记录用户访问记录（上网行为管理），对外隐藏用户信息

正向代理的用途

什么是正向代理

初次接触方向代理的感觉是，客户端是无感知代理的存在的，反向代理对外都是透明的，

访问者者并不知道自己访问的是一个代理。因为客户端不需要任何配置就可以访问。

反向代理总结

反向代理（Reverse Proxy）实际运行方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器

从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。

反向代理过程

（1）保证内网的安全，可以使用反向代理提供WAF功能，阻止web攻击

（2）负载均衡，通过反向代理服务器来优化网站的负载

反向代理作用

什么是反向代理

正反向代理的区别

Nginx教程(7) 正向代理与反向代理【总结】

常用服务器介绍

nginx安装及常见问题

配置文件

Conf

网页文件

Html

日志文件

Logs

二进制程序

Sbin

目录结构

linux nginx启动重启关闭命令

ps aux|grep nginx 和ps -ef|grep nginx一样

关闭nginx (./sbin/nginx -s stop)

nginx开启关闭和状态

如果不指定，默认为NGINX_HOME/conf/nginx.conf

./nginx -c nginx.conf

停止

./nginx -s stop

退出

./nginx -s quit

重新加载nginx.conf

./nginx -s reload

启动停止命令

安全停止

kill -QUIT 进程号

立即停止

kill -TERM 进程号

发送信号的方式

使用nginx+tomcat实现集群

Windows下Nginx的启动、停止等命令

window版nginx部署实践

windows下的nginx

卸载与安装jdk1.8

安装mysql数据库

安装tomcat服务器

安装java的环境

Nginx Linux详细安装部署教程

编译安装nginx 1.8.1 及配置

nginx的安装与配置

nginx安装与命令

模型及基本概念

nginx的信号量

发送信号方式

nginx进程的模型

配置文件结构

配置文件图结构

配置文件教程

conf配置文件结构

#主模块命令，指定Nginx的worker进程运行用户以及用户组，默认由nobody账号运行

#user nobody

指定Nginx要开启的进程数。

worker_processes 1;

#错误日志存放目录

#error_log logs/error.log;

logs/nginx.pid;

#pid

worker进程的最大打开文件数限制

worker_rlimit_nofile 100000;

cpu亲和力配置，让不同的进程使用不同的cpu

worker_cpu_affinity 0001 0010 0100 1000 0001 00100100 1000;

main全局配置

设定nginx的工作模式及连接数上限

use用来指定nginx的工作模式

use epoll;

设置nginx每个进程最大的连接数，默认是1024

worker_connections 1024;

event配置

文件扩展名与文件类型映射表

include mime.types;

默认文件类型，当文件类型未定义时候就使用这类设置的。

default_type application/octet-stream;

设置日志模式

log_format access '$remote_addr - $remote_user [$time_local] "$request" '

server_names_hash_bucket_size 128;client_header_buffer_size 512k;large_client_header_buffers 4 512k;client_max_body_size 100m;

设定请求缓存

隐藏响应header和错误通知中的版本号

server_tokens off;

激活tcp_nopush参数可以允许把httpresponse header和文件的开始放在一个文件里发布，积极的作用是减少网络报文段的数量

tcp_nopush on;

激活tcp_nodelay，内核会等待将更多的字节组成一个数据包，从而提高I/O性能

tcp_nodelay on;

开启高效传输模式

sendfile on

长连接超时时间，单位是秒

keepalive_timeout 65;

upstream表示负载服务器池，定义名字为backend_server的服务器池

upstream webhost {server 192.168.0.5:6666 ;server 192.168.0.7:6666 ;}

轮询

upstream webhost {server 192.168.0.5:6666 weight=2;server 192.168.0.7:6666 weight=3;}

权重

upstream webhost {ip_hash;server 192.168.0.5:6666 ;server 192.168.0.7:6666 ;}

ip_hash

upstream webhost {server 192.168.0.5:6666 ;server 192.168.0.7:6666 ;hash $request_uri;}

url_hash

upstream backend_server {server 10.254.244.20:81 weight=1 max_fails=2 fail_timeout=30s;}

设置一个虚拟机主机，可以包含自己的全局快，同时也可以包含多个locating模块。

server的全局配置，配置监听的端口

listen 80;

本server的名称，当访问此名称的时候nginx会调用当前serevr内部的配置进程匹配。

server_name localhost;

首页排序

index index.html index.htm index.php;

root /data0/abc;

错误页面

error_page 500 502 404 /templates/kumi/phpcms/404.html;

伪静态将www.abc.com/list....html的文件转发到index.php。。。

rewrite ^/list-([0-9]+)-([0-9]+)\\.html$ /index.php?m=content

定义本虚拟主机的访问日志

access_log /var/log/nginx/access.log access;

location 标签，根目录下的.svn目录禁止访问

location ~ /.svn/ { deny all;}

location其实是server的一个指令，为nginx服务器提供比较多而且灵活的指令，都是在location中提现的

相当于默认页面的目录名称，默认是相对路径，可以使用绝对路径配置。

root html;

index index.html index.htm;

location /

#错误页面的文件名称

error_page 500 502 503 504 /50x.html;

location处理对应的不同错误码的页面定义到/50x.html，这个跟对应其server中定义的目录下。

定义默认页面所在的目录

root html;

location = /50x.html

server虚拟主机

http服务器

nginx的配置结构

根据用户请求的网站URL进行匹配，匹配成功即进行相关的操作

location的作用

nginx location 配置正则表达式实例详解

正则表达式实例教程

“~”大小写敏感

“~*”大小写忽略

“^~”只匹配以 uri 开头

“@”nginx内部跳转

默认是大小写敏感，前缀匹配，相当于加了“~”与“^~”

不加任何规则

location的正则

匹配优先级

Location解析过程

if指令

return指令

内置变量

location配置语法

Nginx日志格式

Nginx日志分隔

crontab设置作业

日志的配置及切割

DNS将域名解析为真实ip地址和端口号

查找浏览器DNS缓存

查找本地host文件(ip与域名的关系)

访问nginx服务器地址

从网络运营商获取对应的IP地址

DNS域名解析过程

反向代理的好处

反向代理的配置

在做微信开发或者是对接第三方支付接口时，回调接口可能需要外网访问。

外网映射的作用

natapp、ngrok

外网映射的工具

外网映射工具

02h431qnkfdsnqdbdd677fo2bs.png

蚂蚁课堂架构.png

公网服务器

局域网服务器

反向代理架构

抓包分析反向代理跳转地址

反向代理跳转地址

反向代理

基础用法

负载均衡、故障转移、失败重试、容错、健康检查

当上游服务器(真实业务逻辑访问的服务器)发生故障时，可以转移到其他上游服务器

服务器故障转移

负载均衡的作用

服务集群的问题

upstream和location配置

负载均衡的配置

负载均衡的方式

nginx与后端服务器连接的超时时间_发起握手等候响应超时时间

proxy_connect_timeout 1s;

nginx发送给上游服务器(真实访问的服务器)超时时间

proxy_send_timeout 1s;

nginx接受上游服务器(真实访问的服务器)超时时间

proxy_read_timeout 1s;

负载均衡的故障转移配置

负载均衡故障转移

反向代理负载均衡

Nginx是一个HTTP服务器，可以将服务器上的静态文件（如HTML、图片）通过HTTP协议展现给客户端

静态网页的服务器

使用正则匹配请求的url，根据定义的规则进行重写和改变，需ngx_http_rewrite_module模块来支持url重写功能

可重写变量和含义

可重写的功能

判断IP地址来源

不允许谷歌浏览器访问如果是谷歌浏览器返回500

限制浏览器访问

重写的语法

URL重写场景

rewrite语法格式

regex 常用正则表达式

rewrite过程

URL的重写与配置

【Nginx】实现动静分离

动静分离教程

mvvm模式的交互

动静分离的两种方式

伪静态

动静分离实例

nginx的动静分离

将一台服务器，拆封多个网站部署

nginx虚拟主机作用

nginx 配置虚拟主机的三种方法

基于域名的虚拟主机

基于端口的虚拟主机

nginx虚拟主机配置

虚拟主机配置应用

跨域属于浏览器的问题，不是服务器的问题

跨域的由来

不支持post请求，代码书写比较复杂

1.使用jsonp解决网站跨域

2.使用HttpClient内部转发

3.使用设置响应头允许跨域

原理：保证域名和端口号是相同的，根据不同项目名称使用nginx转发到真实服务器地址

4.基于Nginx搭建企业级API接口网关

5.使用Zuul搭建微服务API接口网关

跨域的解决方案

cors方案用法

简单请求与复杂请求

跨域问题网关配置

Nginx缓存原理及配置

nginx的缓存配置教程

静态资源缓存配置

资源压缩配置

缓存及Gzip的配置

nginx使用ssl模块配置支持HTTPS访问

https配置加强信息传输安全

信息传输安全概念

HTTPS简介

openssl生成证书

Nginx.conf配置证书

nginx的https配置

nginx高可用概述

安装Keepalived

配置抢占式模式

keepalived的配置

Nginx

前提知识+课程定位

问题：为什么会有docker出现

docker理念

解决了运行环境和配置问题软件容器，方便做持续集成并有助于整体发布的容器虚拟化技术。

一句话

是什么

之前的虚拟机技术

容器虚拟化技术

更快速的应用交付和部署

更便捷的升级和扩缩容

更简单的系统运维

更高效的计算资源利用

一次构建、随处运行

开发/运维（DevOps）

新浪

美团

蘑菇街

企业级

能干嘛

docker官网：http://www.docker.com

docker中文网站：https://www.docker-cn.com/

官网

Docker Hub官网: https://hub.docker.com/

仓库

去哪下

Docker简介

前提说明

镜像（image）

容器（container）

仓库（repository）

小总结

Docker的基本组成

yum install -y epel-release

yum install -y docker-io

安装后的配置文件：/etc/sysconfig/docker

启动Docker后台服务：service docker start

docker version验证

CentOS6.8安装Docker

https://docs.docker.com/install/linux/docker-ce/centos/

https://docs.docker-cn.com/engine/installation/linux/docker-ce/centos/#prerequisites

官网中文安装参考手册

cat /etc/redhat-release

确定你是CentOS7及以上版本

分支主题

CentOS7能上外网

yum -y install gcc

yum -y install gcc-c++

yum安装gcc相关

yum -y remove docker docker-common docker-selinux docker-engine

2018.3官网版本

卸载旧版本

yum install -y yum-utils device-mapper-persistent-data lvm2

安装需要的软件包

yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

大坑

yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo