Redies实现持久化

Redis:

是一个开源的，使用C语言编写的，支持网络互联的，可以基于内存可以持久化的Key——value的数据库（非关系型数据库）

NoSQL 是一个概率，泛指非关系型数据库。

“Not noly SQL":不仅仅是SQL，键值存储的数据库、文档型数据库、搜索引擎数据库、图形数据库

Redis的事务:

原子性：

事务具备的原子性是指，在数据库中将事务中的多个操作当做一个整体执行，服务要么都执行，要么都不执行。

Redis 具备一定的原子性但是不支持回滚

Redis运行是把redis的指令 set key value 放在一个队列中执行，可以保证原子性

redis是操作完之后才会进行AOF日志记录，AOF日志记录只是记录操作的指令记录

一致性：

事务的一致性是指，如果数据库在执行事务之前是一致的，在执行完事务之后，成功与否，数据也

应该是一致的，仅从redis而言，不谈实现业务，是满足一致性的

因为Redis 不具备回滚的，不具备传统意义上的原子性，所以redis也就应该不具备传统的一致性

不具备一致性的概念（在Redis设计是就无视这个点）

隔离性:

Redis是单线线程操作，所以在隔离性上有天生的隔离机制，当Redis执行事务时，

Redis的服务区会保证所在执行事务的期间不会有其他对事务的中断，所以Redis

的事务时可以串行的方式运行，事务时具备隔离性的

持久性:

Redis 是否具备持久化取决于对Redis的持久模式

纯内存运行：不具备持久化，一旦服务器停机，所有的数据丢失

RDB 模式：取决于RDB策略，只有在满足策略的情况下执行持久化

AOF 模式：程序会在执行指令时将指令保存在磁盘上

Redis的持久化：

　什么是持久化？简单来讲就是将数据放到断电后数据不会丢失的设备中，也就是我们通常理解的硬盘上。

数据库在进行写操作时，主要有下面五个过程：

客户端向服务端发送写操作（数据在客户端的内存中）
数据库服务端接收到写请求的数据（数据在服务端的内存中）
服务端调用write这个系统调用，将数据往磁盘上写（数据在系统内存的缓冲区中）
操作系统将缓冲区中的数据转移到磁盘控制器上（数据在磁盘缓存中）
磁盘控制器将数据写到磁盘的物理介质中（数据真正落到磁盘上）

Redis提供了RDB持久化和AOF持久化：

RDB模式：

在指定的时间间隔能对数据进行快照存储，恢复时会将快照文件直接读取到内存中。

Redis会单独创建一个（fork）子线程进行持久化操作，将数据写入到一个临时文件夹中，等待持

久化操作结束时将这个临时文件夹替换上次的临时文件夹，这个过程不执行io操作，能够确保极高

的性能。

如果需要大批量的数据恢复，而且对数据恢复的完整性不是非常敏感的话，那么ROB模式会比AOF模式更加高效。

什么情况下会触发rdb规则？

save 满足规则的情况下会触发rdb规则（save 60 5：六十秒内 5次操作）
在执行flushall 命令时会触发rdb 规则
退出redis是触发rdb规则

如何恢复？

只需要将rdb文件放在redis启动目录中在redis启动时会检测是否存在rdb文件，如果存在就恢复数据。

优点：

适合大规模的数据
对数据要求不高
一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。
对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。
性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。
相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

缺点：

需要一定时间间隔进行操作，如果redis意外宕机后最后一次的修改就没有了（最后一次持久化后的数据可能会丢失）
fork 会占用一定的空间
由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

AOF模式：

记录每次对服务器写操作，当服务器重启时会重新执行这些命令恢复原来的数据。

将我们写入全部记录，恢复时将文件再执行一次，AOF 保存文件名为appdendonly.aof

以日志形式记录写入操作（读不记录）只允许文件不允许写文件

大数据的情况下需要很久

AOF持久化配置：
默认是不开启的

appendonly yes 开启aof模式

appendfsync always 每次都修改消耗性能

appendfsync everysec 每秒修改可能会丢失1秒的数据

appendfsync no 不开启

优点：

该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。
由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。
如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。
AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。

缺点：

对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。