写在前面的话
最近学习比较多流行的大数据框架和完成两个大数据项目后，又突然学起了Redis。之所以之前的框架不学习记录呢，是因为之前的学习都是为了完成参加服创比赛的项目所以时间较紧，现在基本架构和编码测试完成，就开始学习新的知识并且尝试优化服创项目。当然我也不愿意复制老师的PPT写成自己的博客：），这里记录的是我在学习过程中自己的一些思考和之前大数据框架（AOF、RDB与HDFS中的SecondaryNode）的对比（大数据人绝不CV🤡。
PS：服创项目是我从0开始的项目，等服创比赛结束后再来复盘！
Redis
Redis，REmote DIctionary Server(远程字典服务器)，作为内存数据库， 同时作为NoSQL的一员，与传统的RDBMS区别还是挺大的（我最大的感觉就是简单和快速。
（读到这里那一定会有读者问了：）作为数据库，那么一定能存储数据，但是又是运行在内存中的，那怎么才能保证数据不丢失呢！（即持久化）
那便是持久化！并且有两种方式可以进行持久化，分别是RDB(Redis DataBase)和AOF(Append Only File)。笔者在学习过程中，总是脑海中不断与HDFS的SecondaryNode的备份方式进行比较，故此文作为记录！
下图是Namenode和SecondaryNode的工作流程图：
RDB -Redis DataBase
RDB持久化
Redis运行过程中，达到了一定时间点或者其他限制（比如手动刷写），启动一个子进程fork整个主进程，在子进程中将redis中的数据写入到一个临时文件中，等这个持久化过程结束后，将这个临时文件替换上次持久化的文件。
笔者在初次接触到这个理念的时候，立马就觉得这个很有可能会丢失最近一次的持久化，这不就是冷备份嘛！那secondaryNode不也是冷备份嘛。重点就在于RDB保存的是数据文件（默认为dump.rdb）,就像是secondary保存的FsImage.checkpoint一样，类似于数据库中的物理备份。
下图是RDB的流程图：
配置
Redis的配置文件中就可以配置出发RDB的工作的条件：
| 名称 | 内容 |
|---|---|
| save | 配置快照出发的条件，例如save 120 2，表示在两分钟内修改了2次触发RDB，save “”表示关闭RDB。 |
| stop-writes-on-bgsave-error | 如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制 |
| rdbcompression | 是否对于存储的数据文件进行压缩，当然这需要消耗额外的CPU资源 |
| rdbchecksum | 是否对于存储的文件使用CRC64算法进行校验 |
| dbfilename | 存储的RDB数据文件名称，默认为dump.rdb |
| dir | 工作路径 |
优劣势
优势：适合大规模的数据恢复；对数据完整性和一致性要求不高
劣势：在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改；fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑；同时子进程写入的时候是不可以主进程不能进行任何的IO操作
AOF-Append Only File
AOF持久化
相比于RDB的持久化，AOF采取就是将每次写入操作写入日志，在每次恢复的时候重新执行一次日志文件中的写入操作就可以了。
这里是不是很容易就联想到NameNode的edit日志，NameNode如果不走SecondaryNode的话，执行的也是将操作保存在文件中，而不是数据文件，这里就类似于数据库的逻辑备份。
下图是AOF持久化的流程图：
配置
| 名称 | 内容 |
|---|---|
| appendfsync | 同步的机制，Always表示实时同步，everysec表示每秒同步，no表示不同步 |
| no-appendfsync-on-rewrite | 重写时是否可以运用Appendfsync，用默认no即可，保证数据安全性。 |
| auto-aof-rewrite-min-size | 设置重写的基准值 |
| auto-aof-rewrite-percentage | 设置重写的基准值百分比 |
优劣势
优势：相比于RDB，一致性较好。
劣势：相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb；aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同
总结
这么对比下来，HDFS中采用的方法归根结底还是冷备份。如果HDFS只用RDB的方式，NN的压力太大，如果只用AOF的方式，效率太低，所以两者结合才是最好的方式，而这种方式对于Redis来说又过于重量级了。HDFS还将将备份文件放置在了另一台机器上，当然，Redis也可以做到，毕竟Redis是分布式数据库，存在主从复制。
这篇博客，没有涉及到Redis的具体操作，只是用来记录Redis的持久化机制，并且和HDFS的备份方式进行对比从而方便更好的理解和记忆。
