JAVA学习路线总结

JAVA学习路线总结的思维导图，本图汇总了JAVA学习路线总结、Kafka、MySQL、Redis、RabbitMQ的知识，有需要的小伙伴可下载自取。

JAVA学习路线总结

第一阶段：java 基础

集合

Iterator【迭代器】

fail-fast：遍历时发生修改，直接抛出异常

fail-safe：遍历时发生修改，牺牲一致性使遍历完成

HashMap

子主题

多线程

线程状态

新建

extends【继承】Thread

implements【实现】Runnable

implements【实现】Callable<Object>

ExecutorService【线程池】

就绪

Thread.start()【调用线程start方法】

ExecutorService.execute()【调用线程池execute方法】

运行

线程在就绪状态抢到CPU时间片

结束

线程执行完成

interrupt - 中断指定线程

阻塞

wait - 等待指定时间或调用notify方法【会释放锁】

sleep - 等待指定时间【不会释放锁】

join - 等待指定线程结束之后再继续执行当前线程

yield - 放弃CPU时间片，重新进入就绪状态

interrupt - 中断指定线程

线程池

核心参数

corePoolSize【核心线程数目】

maximumPoolSize【最大线程数目 = 核心线程 + 救急线程】

keepAliveTime【救急线程 - 生存时间】

unit【救急线程 - 时间单位】

workQueue【阻塞队列】

ArrayBlockingQueue【由数组结构组成的有界阻塞队列】

SynchronousQueue【不存储元素的阻塞队列】

LinkedBlockingDeque【双向队列实现的双端阻塞队列】

DelayQueue【优先级阻塞队列，通过延时从队列中提取任务，时间不到提取不到任务】

LinkedBlockingQueue【链表组成的有界阻塞队列】

PriorityBlockingQueue【支持优先级排序的无界阻塞队列】

threadFactory【线程工厂】

handler【拒绝策略】

一、抛出异常

二、由主线程运行

三、直接把任务丢弃

四、丢弃等待最久的线程，把任务加入线程池

Executors

Executors.newCachedThreadPool()

Executors.newWorkStealingPool()

Executors.newFixedThreadPool(2)

Executors.newSingleThreadExecutor()

Executors.newSingleThreadScheduledExecutor()

Executors.newScheduledThreadPool(2)

不建议直接使用上面的方法创建线程池

ThreadPoolExecutor

锁

锁类型

乐观锁

获取数据时不会上锁，只会在修改数据时判断原数据是否更新

由CAS实现【对比更新】，CAS是一条CPU的原子指令

悲观锁

每次读写数据都会上锁

公平锁

优先排队等待的线程，先到先得

非公平锁

所有线程竞争CPU时间片，谁抢到谁用

独占锁【互斥锁】

同一时间只能有一个线程持有锁

共享锁【读锁】

同一时间允许多线程持有锁，可以查看但无法修改和删除的一种数据锁

同步锁

重入锁

允许持有锁的线程重复加锁

读写锁

在读的地方使用读锁，在写的地方使用写锁

自旋锁

获取锁失败后不会直接进入阻塞状态，会自旋一定时间等待锁的释放

死锁

各线程都在等待其他线程占用的资源，而等待期间也占用着其他线程需要的资源

synchronized

Java关键字，源码在JVM中，用C++实现

竞争不激烈时做了很多优化，性能更好

Lock

Java接口，源码由JDK提供，用JAVA实现

竞争激烈时 Lock 提供了更多更全面的功能，性能更好

并发容器

CopyOnWriteArrayList

CopyOnWriteArraySet

ConcurrentHashMap

原子类

JUC并发工具类

IO流

第二阶段：java 进阶

数据结构与算法

数据结构

数组

链表

二叉树

堆、栈、队列

哈希

算法

查找

排序

贪心

分治

动态规划

回溯

设计模式

单例

工厂

代理

策略

模板方法

观察者

适配器

责任链

建造者

JVM 虚拟机

类加载

加载

将类的字节载入方法区，并创建 class 文件

如果此类的父类没有加载，先加载父类

加载是懒执行

链接

验证 - 验证类是否符合 Class 规范性、合法性、安全性

准备 - 为 static 变量分配空间，设置默认值

解析 - 将常量池的符号引用解析为直接引用

初始化

执行静态代码块与非 final 静态变量的赋值

初始化是懒执行

双亲委派

先由上级加载器进行加载

上级加载器无法找到的类由下级加载器进行加载

内存模型

方法区

堆

程序计数器

虚拟机栈

本地方法栈

GC垃圾回收

垃圾回收算法

标记清除

标记整理

标记复制

分代收集

GC要点

回收区域是堆内存

判断无用对象使用

三色标记法

可达性分析算法

GC具体实现【垃圾回收器】

Parallel GC

eden 内存不足发生 Minor GC，标记复制STW

old 内存不足发生 Full GC，标记整理STW

注重吞吐量

ConcurrentMarkSweep GC

old 并发标记，重新标记时需要STW，并发清除

Failback Full GC

注重响应时间

G1 GC

划分成多个区域，每个区域都可以充当 eden、survivor、old、humongous

新生代回收：eden 内存不足，标记复制STW

并发标记：old 并发标记，重新标记时需要STW

混合收集：并发标记完成，开始混合收集，

响应时间与吞吐量兼顾

GC大都采用【分代回收思想】

新生代【标记复制】

eden【伊甸园】：最初对象都分配到这

survivor【幸存区】：发生Minor GC垃圾回收后，幸存对象到这【from 和 to】

老年代

old：幸存区对象熬过几次【最多15次】回收之后到这

GC根据规模划分

Minor GC【新生代发生垃圾回收】

Mixed GC【新生代和部分老年代发生垃圾回收】

Full GC【新生代和老年代都发生垃圾加收】

程序中调用了System.gc()方法

内存溢出

OutOfMemoryError

堆内存耗尽 - 对象太多，并且无法被垃圾回收

方法区内存耗尽 - 运行期间产生新的类，并且加载的类越来越多

虚拟机栈内存耗尽 - 线程越来越多，并且长时间运行不销毁

StackOverflowError

虚拟机栈内存耗尽 - 内部方法调用次数过多【递归】

内存配置参数

-Xmx10240m【JVM最大内存10G】

-Xms10240m【JVM最小内存10G】

-Xmn5120m【新生代内存5G】

-XX:SurvivorRatio=3【新生代中eden与from占比，from与to占用空间一样】

eden【占三份】

from【占一份】

to【占一份】

-XX:MaxNewSize【设置新生代最大值】

-XX:NewSize【设置新生代最小值】

四种引用

强引用

软引用

虚引用

弱引用

第三阶段：java web

第四阶段：MySQL数据库

数据库四种语言

定义语言【DDL】

创建【create】

删除【drop】

修改【alter】

查询语言【DQL】

查询【select】

目标【from】

条件【where】

联合查询【join】

left join

即使左表没有匹配，右表返回所有行

right join

即使右表没有匹配，左表返回所有行

inner join

返回两个表可匹配的行

full join

只要其中某个表存在匹配就返回所有行

分组查询【group by】

分组过滤【having】

排序查询【order by】

操纵语言【DML】

插入【insert】

更新【update】

删除【delect】

控制语言【DCL】

提交【commit】

回滚【rollback】

授权【grant】

撤消权限【revoke】

数据库三范式

一、数据库表的每一列都具有原子性，不可再分割

二、主键以外的列必须完全依赖于主键

三、非主键列之间不能相关依赖

事务的基本特性【ACID】

【原子性】事务中所有操作都成功或都失败，不会执行一部分

【一致性】事务开始和结束以后，数据库的完整性没有被破坏

【隔离性】一个数据的事务不能被其他数据事务所干扰，多个并发事务要相互隔离

【持久性】事务提交会永久性修改数据和数据库

存储引擎

MyIASM【默认】

不支持外键和事务

表级锁定，数据在更新时锁定整个表

数据库在读写过程中相互阻塞，但单独读或写时速度快且占用资源少

InnoDB

提供外键约束和事务

支持表锁和行锁【默认】

MySQL优化

一、根据架构优化

数据库集群

主从集群

主主集群

读写分离

分库分表

缓存

二、根据设计优化

存储引擎

选择合适的字段类型

为搜索字段添加索引

三、根据SQL优化

四、MySQL程序配置优化

第五阶段：Spring 家族

Spring

IOC

AOP

Spring MVC

Spring Boot

相关注解

SpringBootApplication

SpringBootConfiguration

EnableAutoConfiguration

ComponentScan

自动装配、开箱即用

条件注解

ConditionalOnClass【存在指定类】

ConditionalOnMissingClass【不存在指定类】

ConditionalOnBean【存在指定bean】

ConditionalOnMissingBean【不存在指定bean】

ConditionalOnSingleCandidate【指定类型的bean只存在一个】

ConditionalOnProperty【配置文件存在指定指定属性】

ConditionalOnJava【Java版本符合条件】

ConditionalOnWebApplication【属于Web应用】

ConditionalOnWebNotApplication【不属于Web应用】

整合WEB

整合数据库

整合权限

整合各种中间件

Spring Cloud

详细见【微服务】

第六阶段：中间件

缓存

Redis

消息队列

RabbitMQ

Kafka

RPC

Dubbo

Netty

第七阶段：微服务

服务发现/注册

服务调用/负载均衡

网关

熔断/降级

配置中心

认证和鉴权

分布式事务

任务调度

链路追踪与监控

日志分析与监控

Kafka

简介

消息模型

JMS规范

队列-点对点

主题-发布订阅

Apache ActiveMQ

AMQP

AMQ模型

队列【queues】

信箱【exchanges】

绑定【bindings】

特点：支持事务，数据一致性高

Pivotal RabbitMQ

Spring AMQP 与 Spring JMS

基本概念

Broker【消息代理】

Topic【主题】

消息存储在主题中，主题可以拆成多个分区

Partition【分区】

分区是一个线性增长的不可变的提交日志

一个分区可以被多个消费者组里的消费者消费

一个分区不能被一个消费者组里的多个消费者消费

offset【偏移量】

用来记录消息存储在分区中的位置

存储在系统主题里面

Replication【副本】

分为一个【leader】和多个【follower】，消费者只会从【leadder】中读取消息

用来保存分区数据备份

ISR【正在同步的副本集】

Segment【段】

Producer【生产者】

Consumer【消费者】

通过保存 offset 来记录消费位置【保存在 broker 服务器系统主题里】

一个消费者可以消费多个分区

Consumer Group【消费者组】

一个消费者组内的消费者可以消费多个分区，但不能消费同一个分区

Record【消息】

以 Key - Value 形式存储，如果不指定 Key，默认为空。如果指定 Key，相同 Key 会被保存到相同分区

kafka消息模型

点对点

所有的消费者都属于同一消费者组

发布订阅

每个消费者都属于不同消费组

分区与消息顺序

同一生产者发送到同一分区的消息，先发送的offset一定比后发送的小

同一生产者发送到不同分区的消息，消息顺序无法保证

消费者按照消息在分区里的存放顺序进行消费

Kafka只能保证分区内的消息顺序，不能保证分区间的消息顺序

消息传输语义

至多一次

消息可能丢失，永远不重复发送

Consumer【消费者】先提交 offset【偏移量】，后消费Record【消息】

如果提交offset时失败，会再次读取到这个消息

最少一次

消息不会丢失，但是可能会重复

Consumer【消费者】先消费Record【消息】，后提交 offset【偏移量】

如果消费Record时失败，不会再消费这个消息

精确一次

保证消息被传输到服务端，并且在服务端不重复

生产者API

生产消息

异步

send()

Producer【生产者】 -》 buffer.memory【缓冲区】 -》 Broker【消息代理】

由后台IO线程从缓冲区把消息发送给消息代理

生产者会创建一个缓冲区，缓冲区会为每主题的每个分区创建一个内存用来存放消息，生产者将消息放入到对应分区的缓冲区中，放入之后立刻返回。缓冲区中的数据由后台IO线程发送给服务端

同步

通过调用 send() 方法返回的对象调用 get() 方法来完成阻塞

分区

合理控制分区的任务，可以实现负载均衡的效果

分区策略

指定分区

所有数据写入指定分区中

没有指定分区有Key

将 Key 的 hash 值与需要发送的主题的分区数进行取余，得到分区下标

没有指定分区没有Key

Kafka 采用 Sticky Partition【黏性分区器】随机选择一个分区，并尽可能使用该分区直到 batch【批量发送的容量】已满或已完成，Kafka再随机一个分区进行使用【与上一次分区不同】

参数

linger.ms

延迟时间，到时间时立刻发送

batch.size

每一次消息最大大小，达到最大值时立刻发送

批量发送，提高吞吐量

acks

消息通知模式

0

生产者发送数据到服务端，不等通知就认为已经成功

可能会导致数据的丢失

1

生产者发送数据到服务端， leader 收到消息后返回通知

当 leader 还未同步消息到 follower 但 leader 掉线时，会导致数据丢失

-1

生产者发送数据到服务端，不仅 leader 收到消息，并且 ISR 中所有副本都收到数据才返回通知

当 leader 收到数据并同步给所有 ISR 中副本后 leader 掉线，会导致数据重复

数据完全可靠条件

ACK级别 -1 + 分区副本大于等于 2 + ISR 里应答的最小副本数量大于等于 2

retries

当消息发送失败时，可以重试

至多一次【自动提交】

enable.auto.commit

ture 开启自动提交

auto.commit.interval.ms

每隔多长时间自动提交一次【只要 poll 请求到消息后并且时间耗尽】

ACK 级别 0

至少一次【手动提交】

enable.auto.commit

false 关闭自动提交

commitSync()

手动提交

ACK 级别 -1 + 分区副本大于等于 2 + ISR 里应答副本大于等于 2

精确一次

生产者

enable.idempotence

true 开启幂等【无论 Producer 向 Broker 发送多少重复数据，Broker 只会持久化一条】

重复数据的判断标准

PID

每次Kafka重启会分配一个新的

Partition

分区号

Sequence Number

单调自增

只能保持单分区单会话不重复

acts

-1 消息通知类型

消费者

在消息中加入【唯一ID】，在处理业务时判断【唯一ID】来防止重复处理

事务

开启事务，必须开启幂等性

使用事务之前必须要自定义一个 transaction.id

transaction.id 的 hashcode 取模 50【事务特殊主题默认50分区】 算出该事务由哪个分区负责

底层原理

1、生产者【Producer】向事务协调器【Transaction Coordinator】请求 Producer id

2、事务协调器【Transaction Coordinator】返回 Producer id

3、生产者【Producer】发送消息到分区【Partition】中

4、生产者发送 commit 请求到事务协调器

5、事务协调器向事务特殊分区发送 commit 请求

6、事务协调器向生产者返回成功

7、事务协调器向分区发送 commit 请求

8、分区返回成功信息给事务协调器

9、事务协调器向事务特殊主题发送 commit 请求结果

read_uncommitted

脏读，能够读取到没有标记为成功的数据

read_committed

读取成功提交的数据

数据乱序

1.X 版本前

connection=1【需要设置只缓存一个请求】

1.X 版本后

idempotence=false connection=1【未开启幂等性时，需要设置缓存一个请求】

idempotence=true connection=5【开启幂等性时，最多设置缓存五个请求】

只能保证五个请求的数据有序

Broker

ZK存储数据

ids【记录服务器】

leader

isr【可用服务器】

brokerid【辅助选举 Leader】

总体工作流程

1、broker 启动之后向在 ZK 中注册

2、controller 谁先注册谁

3、由选举出来的 controller 来监听 broker 节点变化

4、controller 决定 Leader 选举

ISR 必须存活，且排在 AR 靠前位置的优化

5、controller 将信息上传到 ZK

6、其他 controller 从 ZK 上同步信息

服役与退役

执行负载均衡操作

创建一个要均衡的主题

创建执行计划

创建副本存储计划

执行计划

分区副本

Leader

生产者只会把数据发往 Leader

follower

生产者发送完数据之后，follower 与 Leader 同步数据

AR

所有副本统称为 AR【 AR = ISR + OSR】

ISR

表示与 Leader 同步的 follower 集合

OSR

表示 follower 与 Leader 同步时，延迟过多的副本

故障处理

follower 掉线

Leader 掉线

只能保证数据一致性，不能保证数据不丢失或不重复

Leader 自动平衡

会自动把 Leader 均匀分散在各个机器上

如果某些 broker 宕机导致 Leader Partition 过于集中在其他机器上，导致读写压力过高

自动平衡配置是默认自动开启的，每个 broker 允许的不平衡 leader 比率超出配置【10%默认】，会自动触发 leader 的平衡

Kafka 文件存储机制

每个 partition 对应一个 log 文件，该文件存储的就是 producer 生产的数据

为了防止 log 文件过大，Kafka 采用了分片和索引机制，将每个 partition 分为多个 segment，每个 segment 包括 ".index" 文件、".log" 文件、".timeindex" 文件

log【数据存储文件】

以追加的形式添加数据

index【数据索引文件】

稀疏索引，log每存储4KB文件，会往index文件中写入一条索引

timeindex【时间戳索引文件】

文件清理策略

默认的日志文件保存时间为七天，可以通过参数修改

delete 日志删除，将过期数据删除

基于时间【默认开启】：以 segment 中记录中的最大时间戳作为该文件时间戳

基于大小【默认关闭】：超过设置的所有日志总大小，删除最小的 segment

compact 日志压缩

对于相同 Key 的不同 Value 值，只保留最后一个版本

高效读写数据

Kafka 本来就是分布式集群，可以采用分区技术，并行度高

读数据采用稀疏索引，可以快速定位要消费的数据

顺序写磁盘

页缓存和零拷贝

页缓存

Kafka 重度依赖操作系统底层提供的 PageCache 功能，当上层有写操作时，操作系统 只是将数据写入 PageCache，当发生读操作时，先从 PageCache 中查找，找不到再从磁盘读取

零拷贝

传统拷贝

磁盘数据 -》 系统内核【页缓存】 -》 用户缓存空间 -》 系统内核【Socket缓冲区】 -》 网卡

实现零拷贝

磁盘数据 -》 系统内核【页缓存】 -》 网卡

基于操作系统底层 sendfile 函数实现 省略了从系统内核复制数据到用户缓存空间，再从用户缓存空间复制到系统内核中

消费者

消费方式

Kafka中有一个主题专门用来保存消费者消费到哪个主题、哪个分区的哪个消费位置

pull【拉】模式

可以根据自己的消费速度拉取数据

consumer【消费者】从 broker【服务器】主动拉取数据

如果 Kafka 没有数据，消费者可能陷入循环中，一直返回空数据

push【推】模式

推送速度不确定，可能导致有的消费者消费之后出现空闲时间或消费不完数据的情况发生

消费者组

一个消费者可以消费多个分区消息

一个消费者组中的消费者不能同时消费同一分区中的消息

消费者组之间互不影响

每个消费者的 offset 由消费者提交到系统主题保存

自动提交

enable.auto.commit

是否开启自动提交功能【默认为true】

auto.commit.interval.ms

自动提交时间间隔【默认 5s】

手动提交

commitSync【同步提交】

阻塞当前线程一直到成功为止，并且会失败重试

commitAsync【异步提交】

没有失败重试机制，有可能提交失败

由 coordinator 来辅助实现消费者组的初始化和分区的分配

coordinator = groupid 的 hashCode 值 % 50【存储 offset 的分区数量】

每个消费者都会和 coordinator 保持心跳【3S】 一旦超时【45S】或者消费者处理时间过长【5分钟】就是触发再平衡【把工作分配给组内的其他消费者】

参数

Fetch.min.bytes【每批次最小抓取大小，默认1字节】

fetch.max.wait.ms【一批数据最小值未达到的超时时间】

Fetch.max.bytes【每批次最大抓取大小，默认50M】

Max.poll.records【一次拉取数据返回消息的最大条数，默认500条】

分区分配策略

Range

对同一个主题里的分区按照序号进行排序，并对消费者按照字母进行排序

通过 partitions / consumer 来决定消费者应该消费几个分区，如果除不尽那么前面的消费者将多消费一个分区

容易产生数据倾斜【主题特别多时，前面的消费者会多消费很多分区】

RoundRobin

针对集群中所有 Topic

把所有 Partition【分区】和所有 Consumer【消费者】都列出来，然后进行 hashCokde 排序

最后通过轮询算法来分配 partition 给到各个消费者

Sticky

会尽量均衡的旋转分区到消费者上面

在出现同一消费者组内消费者出现问题，会尽量保持均衡的分配下去

Spring for Kafka

序列化

序列化与反序列化

常用消息格式

CSV

适合简单的消息

JSON

可读性高

ElasticSearch支持好

占用空间大

序列化消息

Avro

Hadoop、Hive支持好

Protobuf

Avro 与 Schema

MySQL数据库

数据库四种语言

定义语言【DDL】

创建【create】

删除【drop】

修改【alter】

查询语言【DQL】

查询【select】

目标【from】

条件【where】

联合查询【join】

left join

即使左表没有匹配，右表返回所有行

right join

即使右表没有匹配，左表返回所有行

inner join

返回两个表可匹配的行

full join

只要其中某个表存在匹配就返回所有行

分组查询【group by】

分组过滤【having】

排序查询【order by】

操纵语言【DML】

插入【insert】

更新【update】

删除【delect】

控制语言【DCL】

提交【commit】

回滚【rollback】

授权【grant】

撤消权限【revoke】

数据库三范式

一、数据库表的每一列都具有原子性，不可再分割

二、主键以外的列必须完全依赖于主键

三、非主键列之间不能相关依赖

事务的基本特性【ACID】

【原子性】事务中所有操作都成功或都失败，不会执行一部分

【一致性】事务开始和结束以后，数据库的完整性没有被破坏

【隔离性】一个数据的事务不能被其他数据事务所干扰，多个并发事务要相互隔离

【持久性】事务提交会永久性修改数据和数据库

存储引擎

MyIASM【默认】

不支持外键和事务

表级锁定，数据在更新时锁定整个表

数据库在读写过程中相互阻塞，但单独读或写时速度快且占用资源少

InnoDB

提供外键约束和事务

支持表锁和行锁【默认】

MySQL优化

一、根据设计优化

存储引擎

选择合适的字段类型

为搜索字段添加索引

使用外键

尽量避免全表扫描

二、根据架构优化

数据库集群

主从复制

读写分离

负载均衡

三、根据SQL优化

Redis

数据类型

String

单个数据存储，最大512M

存储的是字符串，如果都是数据可以当数字使用，但是是字符串类型

Hash

一个存储空间保存多个键值对数据

底层使用哈希表结构实现数组存储

如果field（键）多则使用hashmap结构存储

List

存储多个数据，并对数据进入存储空间的顺序进行区分

底层使用双向链表存储结构实现

Set

存储多个数据，并提供高效查询

与hash存储结构完全相同，仅使用field（键），所有的value（值）设置nil

Sorted Set

存储多个数据，并关联一个double类型的分数对数据进行排序

在set的存储结构基础上添加一个double类型可排序字段

bitmaps

存储状态（非黑即白）

HyperLogLog

统计不重复数据数量

geo

地理位置

持久化

RDB【快照】

以某一时刻的状态以文件的形式进行全量备份到磁盘

save：会阻塞redis服务器，直到RDB文件创建完成

bgsave：后台调用fork函数生成子进程来完成

AOF【操作过程】

接受到会修改数据集的命令时，就会把命令追加到 AOF 文件里

always：每次写操作均同步到AOF文件中，数据零误差，性能低

everysec：每秒将缓存区中的写操作同步到AOF文件中，数据准确率较高，性能较高

no：由系统控制，整体过程不可控

RDB恢复数据比AOF快很多 RDB存储数据量大，效率低，数据量越大效率越低 RDB根据某个时间点数据快照进行备份，无法做到实时持久化，有较大可能性丢失数据 bgsave每次运行都要执行fork函数生成子进程，会牺牲掉一些性能 Redis从多版本中RDB文件格式格式未进行统一，可能各服务器版本数据无法兼容 AOP文件存储体积较大，恢复慢

删除策略

定时删除

创建一个定时器，当key设置有过期时间并且到达时，由定时器立即执行删除操作

节约内存，过期就删，但CPU压力大，会影响redis服务器响应时间及吞吐量

用CPU性能换存储空间（以时间换空间）

惰性删除

数据过期不做处理，下次访问时如果数据过期再删除

节约CPU性能，内存压力大，容易出现长期占用内存的数据

用存储空间换CPU性能（以空间换时间）

定期删除

周期性轮循redis库中的时效性数据，采用随机抽取的策略，利用过期数据占比的方式控制删除频度

CPU性能占用设置有峰值，检测频度可自定义设置

内在压力不是很大，长期占用内存的冷数据会被持续清理

周期性抽查存储空间（随机抽查、重点抽查）

逐出算法

检测易失数据

挑选最近最长时间没有被使用的数据淘汰

挑选最近使用次数最少的数据淘汰

挑选将要过期的数据淘汰

任意选择数据淘汰

检测全库数据

挑选最近最长时间没有被使用的数据淘汰

挑选最近使用次数最少的数据淘汰

任意选择数据淘汰

放弃数据驱逐

禁止驱逐数据【redis4.0默认策略】

Redis集群

子主题

经典企业级解决方案

缓存预热

【现象】redis服务器启动后快速宕机

【问题】redis重启后内部没有数据，所有的数据请求直接到达数据库给服务器带来压力，导致redis服务器宕机

【解决】服务器启动时自动缓存热数据或服务器启动之后手动加载热数据

缓存雪崩

【现象】数据库连接量激增，直接导致数据库崩溃

【问题】较短时间内大量缓存集中过期，在此期间请求访问过期数据未命中，redis向数据库获取数据

【解决】构建多级缓存、限流降级（短时间内限制一部份请求访问）、缓存过期时间分散设置、删除策略设置LFU（按命中次数删除）

缓存击穿

【现象】数据库连接量激增，直接导致数据库崩溃

【问题】redis某个key过期，该key访问量巨大，redis短时间向数据库发起对同一数据的访问导致数据库崩溃

【解决】超热数据设置永久（不过期）、构建多级缓存、加锁

缓存穿透

【现象】数据库连接量持续增加，数据库服务器压力激增，导致数据库崩溃

【问题】出现非正常URL访问，大量请求数据库不存在的数据，redis未命中后访问数据库，导致数据库崩溃

【解决】设置临时缓存null、白名单策略

RabbitMQ

主题

主题