redis 非关系型数据库的持久化和缓存原理

Redis，通常我们认为它是一个类似缓存的一个内存数据库，经常使用它来缓存我们的数据，为什么需要使用它呢？我们的数据通常存储在数据库中，当数据访问的并发量大的时候，或者是经常使用的通用数据，经常的访问会对数据库造成很大的压力，此时使用Redis来缓存，可以减轻访问数据库的压力。

一：redis使用的环境

首先作为一个nosql的key—value组成的数据库，它们能存储的数据结构必须是简单的，因为有关系的数据即使存储进去之后查询也是很困难的，并且对于海量的数据存储还是关系型数据库比较合适。

- 二,redis中数据结构

• redis中存储的数据是以key-value的形式存在的.其中value支持5种数据类型
  字符串(String) (重点)
  哈希(hash) (重点)——>map类型的数据
  字符串列表(list)
  字符串集合(set)
  有序的字符串集合(sortedset或者叫zset)

  • key不要太长(不能>1024个字节), 也不要太短 。
    
    • key在项目里面最好统一写法, key的常用的写法:
      项目名子模块key名称; store_user_pwd

  Redis列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）

  Redis的列表的顺序是从左到右的顺序!

一个列表最多可以包含 2的32 次方- 1 个元素 (4294967295, 每个列表超过40亿个元素)。 特点:有序

三、持久化

   为什么需要持久化呢？对于每一个公司来讲，数据库中的数据是最重要的， 数据库中的数据多而且重要，这么重要的数据都存储在内存中，如果异常断电，将会对公司造成很大的影响，于是就有了数据的持久化机制，这个其实就是把内存中的数据存储到硬盘中，方便数据的持续存在，也可以减少断电等突发异常造成的损失。

 那么我们怎么持久化数据呢？多长时间进行一次持久化呢？

redis 支持两种持久化方式，一种是 Snapshotting（快照）也是默认方式，另一种是 Append-only file（仅读写文件：缩写 aof）的方式。下面分别介绍：

 一)、Snapshotting（快照）

     快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。可以通过配置设置自动做快照持久化的方式。我们可以配置 redis在 n 秒内如果超过 m 个 key 被修改就自动做快照，下面是默认的快照保存配置：

save 200 10 #200 秒内如果超过 10 个 key 被修改，则发起快照保存
save 400 20 #400 秒内容如超过 20 个 key 被修改，则发起快照保存
save 60 10000

下面介绍详细的快照保存过程：
我们知道通过fork()系统调用我们可以创建一个和当前进程印象一样的新进程.我们通常将新进程称为子进程,而当前进程称为父进程.而子进程继承了父进程的整个地址空间,其中包括了进程上下文,堆栈地址,内存信息进程控制块(PCB)等.

1.redis 调用 fork,现在有了子进程和父进程。（不是vfork，vfork是共享父进程的片段资源，而fork是复制父进程的资源）

2.当客户有新的请求的时候，（parent）父进程继续处理 客户client 请求，子进程负责将内存内容写入到临时文件。由于 os 的实时复制机制（ copy on write)父子进程会共享相同的物理页面，当父进程处理写请求时 os 会为父进程要修改的页面创建副本，而不是写共享的页面（与vfork机制不同）。所以子进程地址空间内的数据是 fork时刻整个数据库的一个快照。

3.当子进程将快照写入临时文件完毕后，临时文件将会替换原快照文件，然后子进程就退出。client 也可以使用 save 或者 bgsave 命令通知 redis 做一次快照持久化。 save 操作是在主线程中保存快照的，由于 redis 是用一个主线程来处理所有client 的请求，这种方式会阻塞所有client 请求。所以不推荐使用。另一点需要注意的是，每次快照持久化都是将内存数据完整写入到磁盘一次，并不是增量的只同步变更数据，即内容可以覆盖。如果需要操作的数据量很大，且读写操作比较多，必然会引起大量的磁盘 io 操作，可能会严重影响性能。

   二)、AOF方式

    由于快照方式存值有时间间隔，所以如果 redis 意外 down 掉的话，就会丢失最后一次快照后的所有修改。如果应用要求不能丢失任何修改的话，可以采用 aof 持久化方式。下面介绍 Append-only file:aof 比快照方式有更好的持久化性，是由于在使用 aof 持久化方式时,redis 会将每一个收到的写命令都通过 write 函数追加到文件中(默认是 appendonly.aof)。当 redis 重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。当然由于 os 会在内核中缓存 write 做的修改，所以可能不是立即写到磁盘上。这样 aof 方式的持久化也还是有可能会丢失部分修改。不过我们可以通过配置文件告诉 redis 我们想要通过 fsync 函数强制 os 写入到磁盘的时机。