Redis实战 学习笔记

数据安全与性能保障

1. 持久化选项

1. 提供了两种持久化的方案：
   1. 快照：将存在于某个时刻的数据都写到硬盘中。 使用快照来持久化时，当服务器崩溃的时候，用户将丢失最近一次生成快照之后，修改的所有数据
      1. 若在新的快照创建完毕之前，Redis、系统、硬件这三者中任一个崩溃了，那么redis将丢失最近一次创建快照之后写入的所有数据。
      2. redis在收到shutdown的时候，会执行一个save命令，阻塞所有客户端，不再执行客户端发送的任何命令，并在save完成之后关闭服务器。
   2. 只追加文件(AOF)：持久化的是，执行写操作的命令持久化到硬盘中。
      1. appendfsync<同步频率>
         1. always：每个命令都同步到硬盘中。
            若是使用固态硬盘(SSD)来加速存储命令的方式，但是每次只会存储一条执行命令。有可能会导致严重的“写入放大”问题，导致SSD的使用寿命降低。
         2. everysec：每秒执行一次同步。
         3. no: OS决定何时进行同步。
      2. 使用过程中问题
         1. AOF文件体积过大：Redis不断执行命令，aof不断存命令，导致aof文件大小不断增加，导致文件体积过大。
            解决方案：
            1. 可以使用BGREWRITEAOF命令来移除aof文件中，重复命令，减小文件的体积。可以通过设计压缩频率来，自动压缩aof文件。 auto-aof-rewrite-percentage（此次aof文件比上次文件体积大了一倍(100%)）， auto-aof-rewrite-min-size （体积大于此数值，进行压缩）
         2. 数据恢复速度过慢：因为AOF文件过大，Redis重启的时候，会去加载aof文件，恢复数据的时间会很久。

2. 复制

1. Redis不支持主主复制, 若是设置两个redis为master，互相引用对方，会导致占用大量的处理资源并且不断的尝试与对方通信。
2. slave服务器与master服务器进行初始化链接时，会清除slave数据库中的数据，替换为master的数据
3. 主从链：master服务器可以有很多的slave服务器，slave服务器也可以有自己的slave服务器，行程主从链。
4. 检验数据是否写入硬盘：可以根据aof_pending_bio_fsync的属性值是否为0来判断。

3. 处理系统故障

1. 当系统故障的时候，可以使用redis-check-aof和redis-check-dump检查aof和快照文件的状态，并在有需要的情况下对文件进行修复。

   1. 使用redis-check-aof --fix对aof文件修复。修复方法：就寻找不正确或是不完整的命令，当发现第一个出错的命令的时候，程序就会删除出错的命令以及出错命令之后的所有命令。
   2. 无法修复快照，因为快照文件被压缩，删除错误位置的命令，可能导致快照无法被读出。最好保存多个备份文件，进行数据恢复的时候，通过计算快照文件的SHA1和SHA256散列值来对内容进行验证。

2. 更换Redis master服务器

   1. 让slave服务器使用save命令，生成快照文件。
   2. 启动新的redis服务器，加载快照文件。

4. 事务

1. 流水线：一次性发送多个命令，然后等待所有的回复出现。减少与服务器的通信次数。