最后
小编利用空余时间整理了一份《MySQL性能调优手册》,初衷也很简单,就是希望能够帮助到大家,减轻大家的负担和节省时间。
关于这个,给大家看一份学习大纲(PDF)文件,每一个分支里面会有详细的介绍。
这里都是以图片形式展示介绍,如要下载原文件以及更多的性能调优笔记(MySQL+Tomcat+JVM)!
- RDB快照过程中Redis是否会停止对外提供服务
- 如果没有停止服务,如何处理新的请求
针对上述问题我们先看一下RDB的持久化执行流程
根据上图我们可以看到主线程主要是fork一个子线程来进行持久化操作,同时父子线程会共享一个数据区域,而且该区域设置为read-only方式,该方式下读的时候没有问题,但是写的时候会触发copyonwrite机制来进行,接下来我们看看什么是 COW(Copy On Write) 机制 。
COW(Copy On Write) 机制
COW(Copy On Write) 机制属于操作系统处理多进程下的一种机制,Redis在持久化的时候会调用glibc函数fork一个子进程。父子进程会共享内存里面的代码段和数据段。
所以持久化的时候是完全交给子进程,而父进程继续处理客户端请求,所以在持久化的时候操作系统采用COW机制进程数据段页面的分离。数据段是由很多操作系统的页面组合而成,当父进程对其中一个页面进行数据修改的时候,先将被父子线程共享的这一个页面复制并分离出来,然后直接对复制的页面进程修改,而此时子进程对应的页面是没有修改的。
Redis采用该机制的简单流程如下。Lunix在fork之后,操作系统会将父进程的所有内存也权限设置为read-only,然后子进程的地址空间指向父进程。当父进程只读时没有问题,当有写内存时,CPU硬件检测到内存也是read-only,于是会触发页异常中断(page-fault),陷入到操作系统的一个中断例程。中断例程中,操作系统采用cow机制会触发异常的也复制一份,于是父子进程各自持有独立的一份,如果这个时候又大量写入操作,会产生大量的分页错误(页异常中断page-fault),从而触发cow机制。
之所以称之为快照也就是说在子进程创建的那一时刻开始。内存的数据就固定下来了,不会发生变化。
RDB的优缺点
优点:
- 性能最大化,fork子进程来完成写操作,让主进程继续处理命令,保证了redis的高性能
- 重启恢复数据的时候。数据量比较大时候,Redis直接解析RDB二进制文件,生成对应的数据存储在内存中,比AOF的启动效率更高
缺点
- 数据安全性低,因为是间隔一段时间进行持久化,如果在持久化之间发生了故障,会丢失数据,这也就决定了该方式更适合在数据要求不严谨的时候采用
- 系统性能耗费,根据上文提到的Redis执行cow机制时,可以看到大量的分页错误会耗费不少性能在复制上。
AOF(Append Only File - 仅追加文件)
根据上文,快照在某些情况下不是可行的选择,所以AOF很好的支持了。
AOF 原理
该方式非常简单:也就是修改内存的操作命令都会记录下来,加入AOF日志记录都是Redis实例创建以来的所有修改性指令序列,所以恢复也就是顺序执行所有执行。
Redis使用单线程相应命令,如果每次写AOF文件命令都追加到硬盘,会极大地影响处理性能,所以Redis会先写入到aof缓冲区,根据用户配置的同步硬盘策略写入到aof文件中,这个策略可以通过appendfsync参数配置,
- always:每一次写操作都会调用一次fsync,这时数据是最安全的,当然,由于每次都会执行fsync,所以其性能也会受到影响
- no:Redis不会主动调用fsync去将AOF日志内容同步到磁盘,所以这一切就完全依赖于操作系统的调试了。对大多数Linux操作系统,是每30秒进行一次fsync,将缓冲区中的数据写到磁盘上。
- everysec:Redis会默认每隔一秒进行一次fsync调用,将缓冲区中的数据写到磁盘。但是当这一次的fsync调用时长超过1秒时。Redis会采取延迟fsync的策略,再等一秒钟。也就是在两秒后再进行fsync,这一次的fsync就不管会执行多长时间都会进行。这时候由于在fsync时文件描述符会被阻塞,所以当前的写操作就会阻塞。
注意,这也是影响Redis性能的参数之一,建议采用 appendfsync everysec(缺省方式)
AOF重写
所谓重写,Redis在长期运行过程中日志会越来越大,在恢复的时候会非常好使,所以我们的目的就是对日志做瘦身
会从以下几点做瘦身:
- 无效命令可以删除,比如del key1、hdel key2、srem keys、set a111、set a222等,直接用最终的数据生成命令保存下来就行
- 多条命令可以删除,如:lpush list a、lpush list b、lpush list c可以转化为:lpush list a b c
- 等等,就不列举了
Redis使用bgrewriteaof指令做瘦身,主要也是开辟一个子进程对内存遍历转化为一系列指令,并序列化到新的文件中,接下来再将操作期间的增量AOF日志追加到新的日志文件中,最终替换了旧的。
AOF重写机制两种方式触发
- 手动触发:bgrewriteaof指令
- 自动触发:根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机
- auto-aof-rewrite-min-size:表示运行AOF重写时文件最小体积,默认为64MB。
- auto-aof-rewrite-percentage:代表当前AOF文件空间 (aof_current_size)和上一次重写后AOF文件空间(aof_base_size)的比值。
auto-aof-rewrite-min-size 100auto-aof-rewrite-percentage 64mb复制代码
如上代表AOF文件的大小小于64mb(默认值),且当前AOF文件大小比基准大小增长了100%时会触发。
AOF优缺点
优点
数据安全,aof持久化配置appendfsync属性,有always,每执行一次命令操作就记录到aof文件一次
缺点
数据集大的时候,比如RDB启动效率低
混合持久化(Redis 4.0版本)
最后
本人也收藏了一份Java面试核心知识点来应付面试,借着这次机会可以送给我的读者朋友们
目录:
Java面试核心知识点
一共有30个专题,足够读者朋友们应付面试啦,也节省朋友们去到处搜刮资料自己整理的时间!
Java面试核心知识点
已经有读者朋友靠着这一份Java面试知识点指导拿到不错的offer了
核心总结学习笔记+最新讲解视频+实战项目源码】](https://bbs.csdn.net/forums/4f45ff00ff254613a03fab5e56a57acb)收录**