Redis初识-2

一、持久化

RDB

RDB其实就是把数据以快照的形式保存在磁盘上。什么是快照呢，你可以理解成把当前时刻的数据拍成一张照片保存下来。
图片说明
触发机制

save命令该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。基本废弃了这个命令，不常用
bgsave命令，下面会开一个子线程来执行。执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。
默认的配置。自动触发。达到设定要求，就触发，比如900s内修改1次。
- 表示900 秒内如果至少有 1 个 key 的值变化，则保存save 900 1
- 表示300 秒内如果至少有 10 个 key 的值变化，则保存save 300 10
- 表示60 秒内如果至少有 10000 个 key 的值变化，则保存save 60 10000

缺点：
耗时，耗性能

AOF

就是日志记录。将所有的命令都记录下来。
过程是先写到缓存中，然后在刷新到磁盘上。
策略

always 每条都写入
everysec 每秒刷新一次进磁盘在系统突然宕机的情况下丢失1秒内的数据，因为这1s的更新只记录在内存中，没有刷到磁盘中。
no os来决定什么时候刷

图片说明

AOF重写

AOF 持久化是通过保存被执行的写命令来记录数据库状态的，所以AOF文件的大小随着时间的流逝一定会越来越大；影响：对于Redis服务器，计算机的存储压力；AOF还原出数据库状态的时间增加；

为了解决AOF文件体积膨胀的问题，Redis提供了AOF重写功能：Redis服务器可以创建一个新的AOF文件来替代现有的AOF文件，可以认为是压缩了的。

图片说明
说明：左侧的是正常的AOF，比如前3句，而最终生效后形成的结果只有1句，因此重写的AOF中只记录1句就好了。

实现方式：

bgrewriteaof命令：AOF重写程序放到子进程（后台）里执行。这样处理的最大好处是：
- 子进程进行AOF重写期间，主进程可以继续处理命令请求；
- 子进程带有主进程的数据副本，使用子进程而不是线程，可以避免在锁的情况下，保证数据的安全性。
自动触发
- 参数1：AOF重写的需要的尺寸，超过大小就重写
- 参数2：AOF文件增长率。下次变大多少时，就重写
- 触发机制，当前AOF文件大小要大于server.aof_rewrite_min_size（默认为1MB），或者在redis.conf配置了auto-aof-rewrite-min-size大小；当前AOF文件大小和最后一次重写后的大小之间的比率等于或者等于指定的增长百分比（在配置文件设置了auto-aof-rewrite-percentage参数，不设置默认为100%）

二、如何选取持久化方式

图片说明
说明：RDB是二进制文件，并且压缩了，因此体积小，对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积，与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些。因为快照是照某个时间点的，因此后序的修改数据会全部丢失。这里的轻重是指，RDB每次都是新来一个，而AOF是追加的操作。

如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.

你也可以同时开启两种持久化方式, 在这种情况下, 当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

三、主从复制

做数据的热备，作为后备数据库，主数据库服务器故障后，可切换到从数据库继续工作，避免数据丢失。
架构的扩展。业务量越来越大，I/O访问频率过高，单机无法满足，此时做多库的存储，降低磁盘I/O访问的频率，提高单个机器的I/O性能。
读写分离，使数据库能支撑更大的并发。在报表中尤其重要。由于部分报表sql语句非常的慢，导致锁表，影响前台服务。如果前台使用master，报表使用slave，那么报表sql将不会造成前台锁，保证了前台速度。

全量复制和部分复制

全量复制过程：master要把数据同步到slave（RDB的形式），并且同步过程中的变化也要记录下来，这里用的一个缓冲区记录，然后再同步到slave。
部分复制：主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。
也就是可以理解成：主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。
redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。

出现宕机时：
主库master出问题：让某个slave成为新的master。
从库slave出问题：让客户端去其他的slave去读。

注意点：
如果出现宕机，需要重启的时候，比如slave宕机，因为只要Slave启动，就会发送sync请求和主机全量同步，当多个同时出现的时候，可能会导致Master IO剧增宕机。这也被称为复制风暴。

四、集群

数据怎么分给下面的集群，主要是哈希分布和顺序分布。
哈希分布
节点取余：3个集群，每个Key对3取余。可以保证分布均匀。建议多倍扩容，比如用6取余，那么从3扩容到6时，只用移动一半的数据。（一般的可能有60-70要移动）
一致性哈希
适用于节点比较多，比如在3和5中间新插入一个节点4，则只用将3和5的部分数据移动到4。只影响邻近的节点。但是无法保证负载均衡。负载均衡还是用多倍扩容比较合适。