第20周作业：

1、搭建一个 LNMP 架构请写出它的底层原理，当用户访问的是静态资源、和动态资源这两种类型的资源是，其中各个 service 之间做了什么操作。请分别一 一写出

1)当访问静态资源时,浏览器发送http request请求到服务器（Nginx）直接交由nginx处理并返回给客户端
2)当访问动态资源时,nginx通过第三方fastCGI协议，将客户端请求转发给PHP-FPM（进程管理程序），PHP-FPM会新建新的进程处理用户的请求，如果这个动态资源需要读取数据库数据，那么php就会继续向后请求mysql数据库，读取需要的数据，并最终通过nginx服务器把获取的数据返回给用户。

2、AOF 和 RDB 的两者之间的区别以及优缺点

RDB模式优点：
    1.RDB快照保存了某个时间点的数据，可以通过脚本执行redis指令bgsave(非阻塞，后台执行)或者
    save(会阻塞写操作,不推荐)命令自定义时间点备份，可以保留多个备份，当出现问题可以恢复到不
    同时间点的版本,很适合备份,并且此文件格式也支持有不少第三方工具可以进行后续的数据分析
    2.RDB可以最大化Redis的性能，父进程在保存 RDB文件时唯一要做的就是fork出一个子进程，然后
    这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘工/0操作
    3.RDB在大量数据,比如几个G的数据，恢复的速度比AOF的快
RDB模式缺点：
    1.不能实时保存数据，可能会丢失自上一次执行RDB备份到当前的内存数据
    如果你需要尽量避免在服务器故障时丢失数据，那么RDB不适合你。虽然Redis允许你设置不同的
    保存点（save point）来控制保存RDB文件的频率，但是，因为ROB文件需要保存整个数据集的状
    态，所以它并不是一个轻松的操作。因此你可能会至少5分钟才保存一次RDB文件。在这种情况
    下，一旦发生故障停机，你就可能会丢失好几分钟的数据。
    2.当数据量非常大的时候，从父进程fork子进程进行保存至RDB文件时需要一点时间，可能是毫秒或
    者秒，取决于磁盘IO性能
    在数据集比较庞大时，fork()可能会非常耗时，造成服务器在一定时间内停止处理客户端﹔如果数
    据集非常巨大，并且CPU时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒或更久。
    虽然 AOF重写也需要进行fork()，但无论AOF重写的执行间隔有多长，数据的持久性都不会有任何
    损失。

AOF模式优点：
    1.数据安全性相对较高，根据所使用的fsync策略(fsync是同步内存中redis所有已经修改的文件到存
    储设备)，默认是appendfsync everysec，即每秒执行一次 fsync,在这种配置下，Redis 仍然可以
    保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据( fsync会在后台线程执
    行，所以主线程可以继续努力地处理命令请求)
    2.由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中不需要seek, 即使出
    现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果本次操作只是写入了一半数据就出
    现了系统崩溃问题，不用担心，在Redis下一次启动之前，可以通过 redis-check-aof 工具来解决
    数据一致性的问题
    3.Redis可以在 AOF文件体积变得过大时，自动地在后台对AOF进行重写:重写后的新AOF文件包含了
    恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的，因为Redis在创建新 AOF文件
    的过程中，append模式不断的将修改数据追加到现有的 AOF文件里面，即使重写过程中发生停
    机，现有的 AOF文件也不会丢失。而一旦新AOF文件创建完毕，Redis就会从旧AOF文件切换到新
    AOF文件，并开始对新AOF文件进行追加操作。
    4.AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，也可以通过该文
    件完成数据的重建
    AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以Redis协议的格式保存，因
    此 AOF文件的内容非常容易被人读懂，对文件进行分析(parse)也很轻松。导出（export)AOF文件
    也非常简单:举个例子，如果你不小心执行了FLUSHALL.命令，但只要AOF文件未被重写，那么只
    要停止服务器，移除 AOF文件末尾的FLUSHAL命令，并重启Redis ,就可以将数据集恢复到
    FLUSHALL执行之前的状态。
        
 AOF模式缺点：
     即使有些操作是重复的也会全部记录，AOF 的文件大小要大于 RDB 格式的文件
    AOF 在恢复大数据集时的速度比 RDB 的恢复速度要慢
    根据fsync策略不同,AOF速度可能会慢于RDB
    bug 出现的可能性更多

3、请问 Redis 持久化如何实现。

redis持久化方案有以下两种：
    1.实现RDB
       1）redis根据配置去尝试生成一个.rdb快照。
       2）redis-server会frok一个子进程。
       3）子进程将数据库dump到一个临时的.rdb文件。
       4）然后通过临时文件来覆盖替换之前的持久化文件，并且每一次生成一个新的临时文件都会做替换
    2.实现AOF
        1）redis-server先fork一个子进程。
        2）子进程基于当前的内存数据，构建日志，开始往新的临时AOF文件中写入日志
        3）redis主进程接到客户端的写操作时，继续往旧的AOF日志中追加数据，此时redis中有两个日志文件，一个是子进程创建的临时日志，一个是主进程的AOF日志。
        4）子进程写完创建完临时AOF日志后，将redis主进程新追加的日志写入到临时日志中
        5）用临时日志覆盖主进程的旧AOF日志。
        AOF持久化配置:
        1）连接到redis服务器，手动临时开启AOF功能(会自动把.rdb文件的内容同步到.aof文件)

 

4、通过脚本实现自动化 RDB 备份

#!/bin/bash

　　DATE=`date +%F_%T`
　　redis-cli -h 127.0.0.1 -p 6379 -a 123456 bgsave &> /dev/null
　　mkdir /redis_rdb_backup
　　cp -a /var/lib/redis/dump.rdb /redis_rdb_backup/dump${DATE}.rdb