第20周作业：
1、搭建一个 LNMP 架构请写出它的底层原理，当用户访问的是静态资源、和动态资源这两种类型的资源是，其中各个 service 之间做了什么操作。请分别一 一写出
LNMP: L-Linux, N-Nginx, M-Mysql, P-可以是php, perl或者python
Nginx负责处理静态资源的请求, 以及将动态页面的请求转发到后面的php服务器. 如果涉及到数据查看, php会调用mysql数据库, 拿到数据后返还给Nginx, 然后再返还给客户端.
访问过程:
1. 用户通过浏览器发送http requet请求, 通过DNS解析以及三次握手与Nginx服务器建立连接.
2. 如果请求的是静态资源, Nginx可以直接处理并通过http reponse返还给客户端
3. 如果处理的是动态资源, Nginx会将请求转发到php-fpm, 有php-fpm去处理动态资源的请求, 包括调用Mysql. 处理完会将结果返回给Nginx, 再由Nginx返还给客户端
4. 浏览器收到回复后, 进行解析,渲染后呈现给用户.
2、AOF 和 RDB 的两者之间的区别以及优缺点
RDB模式优点:
1. RDB快照保存了某个时间点的数据, 可以通过脚本执行redis指令bgsave(非阻塞, 后台执行)或者save(会阻塞写操作, 不推荐使用)命令自定义时间点备份, 可以保留多个备份, 当出现问题可以恢复到不同时间点的版本, 很适合备份, 并且此文件格式也支持有不少第三方工具可以进行后续的数据分析
比如: 可以在最近的24小时内, 每小时备份一次RDB文件, 并且在每个月的第一天, 也备份一个RDB文件. 这样的话, 即使遇上问题, 也可以随时将数据集还原到不同的版本
2. RDB可以最大化Redis的性能, 父进程在保存RDB文件时唯一要做的就是fork出一个子进程, 然后这个子进程就会处理接下来的所有保存公共, 父进程无需执行任何磁盘I/O操作
3. RDB对大量数据, 比如几个G的数据, 恢复的速度比AOF的快
RDB模式缺点:
1. 不能实时保存数据, 可能会丢失自上一次执行RDB备份到当前的内存数据. 如果需要尽量避免在服务器故障时丢失数据, 那么RDB并不合适. 虽然Redis允许设置不同的保存到(save point)来控制保存RDB文件的频率, 但是,因为RDB文件需要保存整个数据集的状态, 所有它不是一个轻松的操作. 因此可能至少5分钟才保存一次RDB文件. 在这种情况下, 一旦发生故障停机, 就可能丢失几分钟的数据.
2. 当数据量非常大的时候, 从父进程fork子进程进行保存至RDB文件时需要一点时间, 可能是毫秒或者秒, 取决于磁盘I/O性能
在数据级比较庞大时, fork()可能会非常耗时, 造成服务器在一定时间内停止处理客户端: 如果数据集非常巨大, 并且CPU时间非常紧张的话, 那么这种停止时间甚至可能会长达整整一秒或者更久. 虽然AOF重写也需要执行fork(), 但无论AOF重写的执行间隔有多长, 数据的持久性都不会有任何损失.
AOF模式优点:
1. 数据安全性相对较高, 根据所使用的的sync策略(fsync是同步内存中Redis所有已经修改的文件到存储设备), 默认是appenfsync 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包含一个格式清晰, 易于理解的日志文件用于记录所有的操作修改. 事实上, 也可以通过该文件完成数据的重建.
5. AOF文件有序地保存了对数据库执行的所有写入操作, 这些写入操作以Redis协议的格式保存, 因此AOF文件的内容非常容易被人读懂, 对文件进行分析(parse)也很轻松. 导出(export)AOF文件也非常简单: 举个例子, 如果你不小心执行了FLUSHALL命令, 但只要AOF文件未被重写,那么只要停止服务器, 移除AOF文件末尾的FLUSHALL命令, 并重启Redis, 就可以将数据集恢复到FLUSHALL执行之前的状态.
AOF模式缺点:
1. 即使有些操作是重复的也会全部记录, AOF的文件大小要大于RDB格式的文件
2. AOF在恢复大数据集时的速度比RDB的恢复速度要慢
3. 根据fsync策略不同, AOF速度可能会慢于RDB
4. bug出现的可能性更多
3、请问 Redis 持久化如何实现。
Redis持久化有两种模式, 一种是RDB, 一种是AOF. RDB会保存Redis某一个时间点的数据状态. 而AOF保存的是自从开启AOF功能后Redis所有的数据写操作.
具体根据业务需求不同, 持久化实现的方式也不同
如果主要充当缓存功能, 或者可以承受数分钟数据的丢失, 通常生成环境一般只需要启用RDB即可, 这也是默认值
如果数据需要持久保存, 一点不能丢失, 可以选择同时开启RDB和AOF, 一般不建议只开启AOF
4、通过脚本实现自动化 RDB 备份
```
#!/bin/bash
. /etc/init.d/functions
BACKUP=/backup/redis-rdb
DIR=/data/redis
FILE=dump_6379.rdb
PASS=redis
redis-cli -h 127.0.0.1 -a $PASS --no-auth-warning bgsave
result=`redis-cli -a redis --no-auth-warning info Persistence | greo rdb_bgsave_in_progress | sed -rn 's/.*:([0-9]+).*/1/p'`
until [ $result -eq 0 ]; do
sleep 1
result=`redis-cli -a redis --no-auth-warning info Persistence | greo rdb_bgsave_in_progress | sed -rn 's/.*:([0-9]+).*/1/p'`
done
DATE=`date +%F_%T`
[ -e $BACKUP ] || { mkdir -p $BACKUP ; chown -R redis.redis $BACKUP; }
mv $DIR/$FILE $BACKUP/dump_6379_${DATE}.rdb
action "Backup redis RDB"
```