序
主要记录了Redis的持久化&备份的一些命令
持久化
-
redis提供了两种持久化的方式，分别是RDB（Redis DataBase）和AOF（Append Only File）
-
RDB，简而言之，就是在不同的时间点，将redis存储的数据生成快照并存储到磁盘等介质上
-
AOF，则是换了一个角度来实现持久化，那就是将redis执行过的所有写指令记录下来，在下次redis重新启动时，只要把这些写指令从前到后再重复执行一遍就可以
-
RDB和AOF两种方式也可以同时使用，优先采用AOF方式来进行数据恢复，这是因为AOF方式的数据恢复完整度更高
-
如果没有数据持久化的需求，也完全可以关闭RDB和AOF方式，这样的话，redis将变成一个纯内存数据库
-
-
RDB:
-
redis在进行数据持久化的过程中，会先将数据写入到一个临时文件中，待持久化过程都结束了，才会用这个临时文件替换上次持久化好的文件
-
redis会单独创建（fork）一个子进程来进行持久化，而主进程是不会进行任何IO操作的，这样就确保了redis极高的性能
-
如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效
-
如果对数据的完整性非常敏感，那么RDB方式就不太适合
-
-
AOF:
-
AOF方式是将执行过的写指令记录下来，在数据恢复时按照从前到后的顺序再将指令都执行一遍
-
默认的AOF持久化策略是每秒钟fsync一次（fsync是指把缓存中的写指令记录到磁盘中），这种情况下，redis仍然可以保持很好的处理性能， 即使redis故障，也只会丢失最近1秒钟的数据。
-
redis提供了redis-check-aof工具，可以用来进行日志修复
-
redis提供了AOF文件重写（rewrite）机制
-
在同样数据规模的情况下，AOF文件要比RDB文件的体积大。而且，AOF方式的恢复速度也要慢于RDB方式
-
在重写即将开始之际，redis会创建（fork）一个“重写子进程”，这个子进程会首先读取现有的AOF文件， 并将其包含的指令进行分析压缩并写入到一个临时文件中。 与此同时，主工作进程会将新接收到的写指令一边累积到内存缓冲区中， 一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。 当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中。 当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中了。
-
备份
-
特点：
-
redis是支持主从同步的，而且也支持一主多从以及多级从结构
-
主从结构，一是为了纯粹的冗余备份，二是为了提升读性能，比如很消耗性能的SORT就可以由从服务器来承担
-
redis的主从同步是异步进行的，这意味着主从同步不会影响主逻辑，也不会降低redis的处理性能
-
主从架构中，可以考虑关闭主服务器的数据持久化功能，只让从服务器进行持久化，这样可以提高主服务器的处理性能
-
在主从架构中，从服务器通常被设置为只读模式，这样可以避免从服务器的数据被误修改
-
但是从服务器仍然可以接受CONFIG等指令，所以还是不应该将从服务器直接暴露到不安全的网络环境中。如果必须如此，那可以考虑给重要指令进行重命名，来避免命令被外人误执行
-
-
同步原理：
- 从启动，向主发送sync命令，主在后台保存rdb，并将期间接受的命令缓存起来，当快照完成，将快照和缓存的命令发给从，从收到 会加载快照并执行缓存的命令，不支持断电续传
安全
-
bind 参数 只能绑定一个地址
-
密码要复杂 因为redis无主动延迟 可以暴力破解
-
重命名命令：rename-command name newname