从两个方面将redis剖析

前言

为什么要使用redis？

剖析：一般主要是从两个角度出发---性能和并发。（虽然它还可以做分布式锁的功能，但博主这里主要方面是从性能和并发角度来分析，分布式锁的话暂时不做讲解）

性能：在我们调用某个方法时，如果这个方法的SQL耗时比较久，并且对应的结果不会频繁的变动，这时我们将运行的结果放入redis中，再去请求这个方法，直接从redis中获取，使得请求能够迅速响应。

这时就有人问我，什么是迅速响应，多长时间才叫迅速响应？

这里我只能用书中的话来回答他：在理想状态下，我们的页面跳转需要在瞬间解决，对于页内操作则需要在刹那间解决。另外，超过一弹指的耗时操作要有进度提示，并且可以随时终止或取消，这样才能给用户最好的体验。根据《摩诃僧祗律》记载：“

一刹那者为一念，二十念为一瞬，二十瞬为一弹指，二十弹指为一罗预，二十罗预为一须臾，一日一夜有三十须臾。

”。经过周密的计算，一瞬间为0.36 秒,一刹那有 0.018 秒.一弹指长达 7.2 秒。

并发：在大并发的情况下，所有的请求直接访问数据库，数据库会出现连接异常。这个时候，就需要使用redis做一个缓冲操作，让请求先访问到redis，而不是直接访问数据库。

 

性能剖析之redis持久化机制

我们经常会碰到服务挂了、突然断电等一系列情况，由于redis是将数据存在了内存，所有这时数据就会丢失。

持久化：将内存中的数据写入到硬盘中。

Redis 的一种持久化方式叫快照(snapshotting，RDB)，另一种方式是只追加文件(append-only file，AOF)。

快照（Snapshot）

特点：将某一时刻的所有数据都写入硬盘中，同时这也是redis的默认开启持久化方式，保存的文件是以.rdb形式结尾的文件因此这种方式也称之为RDB方式。

快照生成方式：

• 客户端方式：BGSAVE和SAVE指令
• 服务器配置自动触发

1. BGSAVE：客户端可以使用BGSAVE命令来创建一个快照，当接收到客户端的BGSAVE命令时，redis会调用fork来创建一个子进程，然后子进程负责将快照写入磁盘中，而父进程则继续处理命令请求。

名词解释：fork当一个进程创建子进程的时候，底层的操作系统会创建该进程的一个副本，在类unix系统创建子进程的操作会进行优化：在刚开始的时候，父子进程共享相同的内存，直到父进程或子进程对内存进行类写之后，对被写入的内存的共享才会结束服务

2. SAVE：客户端还可以使用SAVE命令来创建一个快照，接收到SAVE命令的redis服务器在创建完毕之前将不再响应任何其他命令

注意：SAVE命令并不常用，使用SAVE命令在快照创建完毕之前，redis处于阻塞状态，无法对外服务

3. 服务器配置方式之满足配置自动触发

如果用户在redis.conf中设置了save配置选项，redis会在save选项条件满足之后自动触发一次BGSAVE命令，如果设置多个save配置选项，当任意一个save配置选项条件满足，redis也会被触发一次BGSAVE命令

4.服务器接收客户端shutdown指令

当redis通过shutdown指令接收到关闭服务器的请求时，会执行一个save命令，阻塞所有的客户端，不再执行客户端执行发送的任何命令，并且在save命令执行完毕之后关闭服务器

AOF只追加日志文件

特点：这种方式可以将所有客户端执行的写命令记录到日志文件中，AOF持久化会将被执行的写命令写到AOF的文件末尾，以此来记录数据发生的变化，因此只要redis从头到尾执行一次AOF文件所包含的所有写命令，就可以恢复AOF文件的记录的数据集

开启AOF持久化

在redis的默认配置中AOF持久化机制是没有开启的，需要在配置中开启

• 修改 appendonly yes 开启持久化
• 修改 appendfilename "appendonly,aof" 指定生成文件命名

AOF重写

用来一定程度上减小AOF文件的体积

触发重写方式

1.客户端方式触发重写

下hi行BGREWRITEAOF命令 不会阻塞redis的服务

2.服务器配置方式自动触发

配置redis.conf中的auto-aof-rewrite-percentage选项

如果设置auto-aof-rewrite-percentage值为100和auto-aof-rewrite-min-size 64mb,并且启用的AOF持久化时，那么当AOF文件体积大于64M,并且AOF文件的体积比上一次重写之后体积大了至少一倍时，会自动触发，如果重写过于频繁，用户可以考虑将auto-aof-rewrite-percentage设置为更大

重写原理

注意：重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，替换原有的文件这点和快照有点类似

重写流程：

1. redis调用fork，现在有父子两个进程 子进程根据内存中的数据库快照，往临时文件中写入重建数据库装填的命令
2. 父进程继续处理client请求，除了把命令写入到原来的aof文件中，同时把收到的写命令缓存起来，这样就能保证如果子进程重写失败的话并不会出问题
3. 当子进程把快照内容写入已命令方式写到临时文件中后，子进程发信号通知父进程，然后父进程把缓存的写命令也写入到临时文件
4. 现在父进程可以使用临时文件替换老的aof文件，并重命名，后面收到的写命令也开始往新的aof文件中追加。

持久化总结

两种持久化方案既可以同时使用aof，又可以单独使用，在某种情况下也可以都不使用，具体使用那种持久化方案取决于用户的数据和应用决定。无论使用aof还是快照机制持久化，将数据持久化到硬盘都是有必要的，除了持久化外，用户还应该对持久化的文件进行备份