mirror of
https://github.com/Snailclimb/JavaGuide
synced 2025-06-20 22:17:09 +08:00
Merge branch 'Snailclimb:master' into master
This commit is contained in:
commit
7e7fb892c4
@ -595,7 +595,9 @@ save 60 10000 #在60秒(1分钟)之后,如果至少有10000个key发生
|
|||||||
appendonly yes
|
appendonly yes
|
||||||
```
|
```
|
||||||
|
|
||||||
开启 AOF 持久化后每执行一条会更改 Redis 中的数据的命令,Redis 就会将该命令写入硬盘中的 AOF 文件。AOF 文件的保存位置和 RDB 文件的位置相同,都是通过 dir 参数设置的,默认的文件名是 appendonly.aof。
|
开启 AOF 持久化后每执行一条会更改 Redis 中的数据的命令,Redis 就会将该命令写入到内存缓存 `server.aof_buf` 中,然后再根据 `appendfsync` 配置来决定何时将其同步到硬盘中的 AOF 文件。
|
||||||
|
|
||||||
|
AOF 文件的保存位置和 RDB 文件的位置相同,都是通过 dir 参数设置的,默认的文件名是 `appendonly.aof`。
|
||||||
|
|
||||||
在 Redis 的配置文件中存在三种不同的 AOF 持久化方式,它们分别是:
|
在 Redis 的配置文件中存在三种不同的 AOF 持久化方式,它们分别是:
|
||||||
|
|
||||||
@ -605,7 +607,7 @@ appendfsync everysec #每秒钟同步一次,显示地将多个写命令同步
|
|||||||
appendfsync no #让操作系统决定何时进行同步
|
appendfsync no #让操作系统决定何时进行同步
|
||||||
```
|
```
|
||||||
|
|
||||||
为了兼顾数据和写入性能,用户可以考虑 appendfsync everysec 选项 ,让 Redis 每秒同步一次 AOF 文件,Redis 性能几乎没受到任何影响。而且这样即使出现系统崩溃,用户最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操作的时候,Redis 还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。
|
为了兼顾数据和写入性能,用户可以考虑 `appendfsync everysec` 选项 ,让 Redis 每秒同步一次 AOF 文件,Redis 性能几乎没受到任何影响。而且这样即使出现系统崩溃,用户最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操作的时候,Redis 还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。
|
||||||
|
|
||||||
**相关 issue** :[783:Redis 的 AOF 方式](https://github.com/Snailclimb/JavaGuide/issues/783)
|
**相关 issue** :[783:Redis 的 AOF 方式](https://github.com/Snailclimb/JavaGuide/issues/783)
|
||||||
|
|
||||||
@ -615,6 +617,10 @@ Redis 4.0 开始支持 RDB 和 AOF 的混合持久化(默认关闭,可以通
|
|||||||
|
|
||||||
如果把混合持久化打开,AOF 重写的时候就直接把 RDB 的内容写到 AOF 文件开头。这样做的好处是可以结合 RDB 和 AOF 的优点, 快速加载同时避免丢失过多的数据。当然缺点也是有的, AOF 里面的 RDB 部分是压缩格式不再是 AOF 格式,可读性较差。
|
如果把混合持久化打开,AOF 重写的时候就直接把 RDB 的内容写到 AOF 文件开头。这样做的好处是可以结合 RDB 和 AOF 的优点, 快速加载同时避免丢失过多的数据。当然缺点也是有的, AOF 里面的 RDB 部分是压缩格式不再是 AOF 格式,可读性较差。
|
||||||
|
|
||||||
|
官方文档地址:https://redis.io/topics/persistence
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
**补充内容:AOF 重写**
|
**补充内容:AOF 重写**
|
||||||
|
|
||||||
AOF 重写可以产生一个新的 AOF 文件,这个新的 AOF 文件和原有的 AOF 文件所保存的数据库状态一样,但体积更小。
|
AOF 重写可以产生一个新的 AOF 文件,这个新的 AOF 文件和原有的 AOF 文件所保存的数据库状态一样,但体积更小。
|
||||||
|
@ -1,42 +1,26 @@
|
|||||||
<!-- TOC -->
|
|
||||||
|
|
||||||
- [回顾一下类加载过程](#回顾一下类加载过程)
|
|
||||||
- [类加载器总结](#类加载器总结)
|
|
||||||
- [双亲委派模型](#双亲委派模型)
|
|
||||||
- [双亲委派模型介绍](#双亲委派模型介绍)
|
|
||||||
- [双亲委派模型实现源码分析](#双亲委派模型实现源码分析)
|
|
||||||
- [双亲委派模型的好处](#双亲委派模型的好处)
|
|
||||||
- [如果我们不想要双亲委派模型怎么办?](#如果我们不想要双亲委派模型怎么办)
|
|
||||||
- [自定义类加载器](#自定义类加载器)
|
|
||||||
- [推荐](#推荐)
|
|
||||||
|
|
||||||
<!-- /TOC -->
|
|
||||||
|
|
||||||
> 公众号JavaGuide 后台回复关键字“1”,免费获取JavaGuide配套的Java工程师必备学习资源(文末有公众号二维码)。
|
|
||||||
|
|
||||||
## 回顾一下类加载过程
|
## 回顾一下类加载过程
|
||||||
|
|
||||||
类加载过程:**加载->连接->初始化**。连接过程又可分为三步:**验证->准备->解析**。
|
类加载过程:**加载->连接->初始化**。连接过程又可分为三步:**验证->准备->解析**。
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
一个非数组类的加载阶段(加载阶段获取类的二进制字节流的动作)是可控性最强的阶段,这一步我们可以去完成还可以自定义类加载器去控制字节流的获取方式(重写一个类加载器的 `loadClass()` 方法)。数组类型不通过类加载器创建,它由 Java 虚拟机直接创建。
|
一个非数组类的加载阶段(加载阶段获取类的二进制字节流的动作)是可控性最强的阶段,这一步我们可以去自定义类加载器去控制字节流的获取方式(重写一个类加载器的 `loadClass()` 方法)。数组类型不通过类加载器创建,它由 Java 虚拟机直接创建。
|
||||||
|
|
||||||
所有的类都由类加载器加载,加载的作用就是将 .class文件加载到内存。
|
所有的类都由类加载器加载,加载的作用就是将 `.class`文件加载到内存。
|
||||||
|
|
||||||
## 类加载器总结
|
## 类加载器总结
|
||||||
|
|
||||||
JVM 中内置了三个重要的 ClassLoader,除了 BootstrapClassLoader 其他类加载器均由 Java 实现且全部继承自`java.lang.ClassLoader`:
|
JVM 中内置了三个重要的 ClassLoader,除了 BootstrapClassLoader 其他类加载器均由 Java 实现且全部继承自`java.lang.ClassLoader`:
|
||||||
|
|
||||||
1. **BootstrapClassLoader(启动类加载器)** :最顶层的加载类,由C++实现,负责加载 `%JAVA_HOME%/lib`目录下的jar包和类或者或被 `-Xbootclasspath`参数指定的路径中的所有类。
|
1. **BootstrapClassLoader(启动类加载器)** :最顶层的加载类,由 C++实现,负责加载 `%JAVA_HOME%/lib`目录下的 jar 包和类或者被 `-Xbootclasspath`参数指定的路径中的所有类。
|
||||||
2. **ExtensionClassLoader(扩展类加载器)** :主要负责加载目录 `%JRE_HOME%/lib/ext` 目录下的jar包和类,或被 `java.ext.dirs` 系统变量所指定的路径下的jar包。
|
2. **ExtensionClassLoader(扩展类加载器)** :主要负责加载 `%JRE_HOME%/lib/ext` 目录下的 jar 包和类,或被 `java.ext.dirs` 系统变量所指定的路径下的 jar 包。
|
||||||
3. **AppClassLoader(应用程序类加载器)** :面向我们用户的加载器,负责加载当前应用 classpath 下的所有 jar 包和类。
|
3. **AppClassLoader(应用程序类加载器)** :面向我们用户的加载器,负责加载当前应用 classpath 下的所有 jar 包和类。
|
||||||
|
|
||||||
## 双亲委派模型
|
## 双亲委派模型
|
||||||
|
|
||||||
### 双亲委派模型介绍
|
### 双亲委派模型介绍
|
||||||
|
|
||||||
每一个类都有一个对应它的类加载器。系统中的 ClassLoder 在协同工作的时候会默认使用 **双亲委派模型** 。即在类加载的时候,系统会首先判断当前类是否被加载过。已经被加载的类会直接返回,否则才会尝试加载。加载的时候,首先会把该请求委派该父类加载器的 `loadClass()` 处理,因此所有的请求最终都应该传送到顶层的启动类加载器 `BootstrapClassLoader` 中。当父类加载器无法处理时,才由自己来处理。当父类加载器为null时,会使用启动类加载器 `BootstrapClassLoader` 作为父类加载器。
|
每一个类都有一个对应它的类加载器。系统中的 ClassLoader 在协同工作的时候会默认使用 **双亲委派模型** 。即在类加载的时候,系统会首先判断当前类是否被加载过。已经被加载的类会直接返回,否则才会尝试加载。加载的时候,首先会把该请求委派给父类加载器的 `loadClass()` 处理,因此所有的请求最终都应该传送到顶层的启动类加载器 `BootstrapClassLoader` 中。当父类加载器无法处理时,才由自己来处理。当父类加载器为 null 时,会使用启动类加载器 `BootstrapClassLoader` 作为父类加载器。
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
@ -129,6 +113,3 @@ protected Class<?> loadClass(String name, boolean resolve)
|
|||||||
- <https://blog.csdn.net/xyang81/article/details/7292380>
|
- <https://blog.csdn.net/xyang81/article/details/7292380>
|
||||||
- <https://juejin.im/post/5c04892351882516e70dcc9b>
|
- <https://juejin.im/post/5c04892351882516e70dcc9b>
|
||||||
- <http://gityuan.com/2016/01/24/java-classloader/>
|
- <http://gityuan.com/2016/01/24/java-classloader/>
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user