Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit c88edd7

Browse files
committed
add redis aof content to readme file
1 parent 3682442 commit c88edd7

File tree

1 file changed

+20
-0
lines changed

1 file changed

+20
-0
lines changed

springboot-jedis-sample/README.md

+20
Original file line numberDiff line numberDiff line change
@@ -81,6 +81,26 @@ Redis巧妙的运用了fork,当bgsave执行时,Redis主进程会判断当前
8181

8282
**copy on write机制:**
8383
子进程持久话的数据是在fork时的数据,也就是说主进程和子进程都是同一块内存空间,之后主进程又能继续提供服务,当遇到内存数据修改时,需要保证子进程对修改数据不可见的, 这个机制就是由copy on wirte完成的。
84+
8485
原理:主进程fork子进程后,内核把主进程中所有的内存页权限都设置为read-only,然后子进程的地址空间指向主进程。这也就是共享了主进程的内存,当其中主进程写内存时,CPU硬件会检测到内存页权限是read-only的,于是触发内存页中断(page-dault),陷入内核中断例程。中断例程中,内核会把触发的异常页复制一份(仅复制异常页,也就是修改的那个数据页,而不是全部数据页),于是父子进程都各自持有独立的一份数据(主进程是新的,子进程是老的)。
8586

87+
**RDB优点:**
88+
RDB文件是一个紧密的二进制压缩文件,是Redis在某个时间点的全部数据快照。所以使用RDB恢复数据比AOF快,非常适合备份、全量复制、灾难恢复等场景。
89+
90+
**RDB缺点:**
91+
每次进行bgsave操作都需要只想fork操作创建子进程,属于重量级操作,频繁执行成本较高,所以无法做到实时持久化,或者是秒级持久化。
92+
93+
##### 2、AOF
94+
AOF(Append Only File)持久化是把每次写的命令追加写入日志中,当需要数据时重新执行AOF文件中的命令就可以了。AOF解决了数据持久化的实时性。
95+
96+
**AOF持久化流程:**
97+
> - 命令追加(append):所有写命令都会被追加到AOF缓存区(aof_buf)中;
98+
> - 文件同步(sync):根据不同策略将AOF缓存区同步到AOF文件中;
99+
> - 文件重写(rewrite):定期对AOF文件进行重写,以达到压缩的目的;
100+
> - 数据加载(load):当需要恢复数据时,重新执行AOF文件中的命令;
101+
102+
**AOF同步策略**
103+
> - always:每次写入缓冲区都需要同步到AOF文件中,硬盘的操作比较慢,限制了Redis高并发;
104+
> - no:每次写入缓存区,不进行同步,同步到AOF文件的操作丢给操作系统负责,每次同步AOF文件周期不可控;
105+
> - eversec:每次写入缓存区都,由专门的线程每秒钟同步一次,做到了性能与数据安全的兼并;
86106

0 commit comments

Comments
 (0)