【Redis专栏】深入学习Redis

一、Redis安装以及生产环境配置

1. 安装

推荐使用 OneinStack 的自动安装，不仅可以一键安装 Redis，还支持数据库、Nginx等。
链接：https://oneinstack.com/auto/
使用：在网页中选择好所需的配置后，直接复制安装命令，在 Linux 中执行即可。

2. 配置

这个自动安装，我没有找到 Redis 的 redis_init_script 脚本，所以我在网上去找了一个脚本，如下，这个脚本需要放在 /etc/init.d 目录中，文件名使用 redis_6379

#!/bin/sh
#
# Simple Redis init.d script conceived to work on Linux systems
# as it does use of the /proc filesystem.

# chkconfig: 2345 90 10

# description: Redis is a persistent key-value database

#redis服务器监听的端口
REDISPORT=6379
#服务端所处位置
EXEC=/usr/local/redis/bin/redis-server
#客户端位置
CLIEXEC=/usr/local/redis/bin/redis-cli

#redis的PID文件位置，需要修改
PIDFILE=/var/run/redis/redis.pid

#redis的配置文件位置，需将${REDISPORT}修改为文件名
CONF="/usr/local/redis/etc/${REDISPORT}.conf"

case "$1" in
    start)
        if [ -f $PIDFILE ]
        then
                echo "$PIDFILE exists, process is already running or crashed"
        else
                echo "Starting Redis server..."
                $EXEC $CONF
        fi
        ;;
    stop)
        if [ ! -f $PIDFILE ]
        then
                echo "$PIDFILE does not exist, process is not running"
        else
                PID=$(cat $PIDFILE)
                echo "Stopping ..."
                $CLIEXEC -p $REDISPORT shutdown
                while [ -x /proc/${PID} ]
                do
                    echo "Waiting for Redis to shutdown ..."
                    sleep 1
                done
                echo "Redis stopped"
        fi
        ;;
    *)
        echo "Please use start or stop as first argument"
        ;;
esac

1、脚本需要修改的地方：

1. 监听端口：此处默认 6379 ，和 redis.conf 中的端口一致；
2. 服务端所在位置：redis-server 文件的实际位置；
3. 客户端所在位置：redis-cli 文件的实际位置；
4. PID： redis.conf 中 pidfile 的配置；
5. CONF：配置文件 redis.conf 的位置，由于此处使用的是端口作为文件名，因此要将 redis.conf 更改为 6379.conf。

2、redis.conf （6379.conf）配置文件需要修改的地方：

1. 文件名：和脚本中相对应，改为 6379.conf；
2. daemonize 配置：改为 yes（将 redis 以守护线程方式启动，保证其一直运行）；
3. pidfile：设置 redis 的 pid 文件位置；
4. port：端口号，默认6379；
5. dir：设置持久化文件的存储位置；

启动 Redis ：先给脚本配置权限 chmod 777 redis_6379，然后使用脚本启动 ./redis_6379 start

我遇到的错误：在启动时会报错：“/bin/sh^M: bad interpreter: No such file or directory”，因为配置文件是直接从 Windows 系统复制到 Linux 系统的，编码格式是 dos，Linux 下必须是 unix，需要更改一下

# 查看编码格式
：set ff
# 更改编码格式为unix
：set ff=unix

最后执行：chkconfig redis_6379 on ，让redis随系统启动

二、Redis的持久化

1. 持久化的目的

Redis 持久化的目的是为了能够进行数据恢复，因为数据是存储在内存中，一旦redis挂了，那其中的数据也就没有了，即使重启 redis，里面的数据也无法恢复了，如果此时再有大量的请求过来，在 redis 中无法命中数据的话，那么这些大量的请求就会去访问数据库，导致缓存雪崩，使数据库压力瞬间增加，进而引起数据库的崩溃。
所以 redis 的持久化是必须的，Redis 有两种持久化机制：RDB 和 AOF。

2. RDB —— 存储完整数据快照

RDB：每隔一定时间将 redis 内存中的数据生成一个完整的数据集的快照，即 RDB 文件，这是 redis 默认开启的一种持久化机制。

3. AOF —— 生成写操作命令日志

AOF：将数据写入 redis 后，redis 会将这个操作写入 os cache 中，然后操作系统再每隔一定时间执行 fsync 操作，将 os cache 中的数据刷入磁盘，生成一个 AOF 文件（即 AOF 是存放“写”命令的文件）。

Redis 的内存是有限的，redis会根据缓存淘汰策略，自动将一部分数据从内存中删除，但是 AOF 文件是记录所有“写”命令的，而且 redis 只会生成一个 AOF 文件，因此这个 AOF 文件会变得越来越大，当 AOF 文件大到一定时候，redis 会进行一个 rewrite 操作。

Redis 的 rewrite 操作：基于当前 redis 中的数据，重新构造一个更小的 AOF 文件，然后将原来的大 AOF 文件删除。

4. RDB 和 AOF 的优缺点

1. RDB 的优点

1. RDB 可以生成多个数据文件（多个备份配置，同一个备份配置只生成一个 .rdb 文件），每个 .rdb 文件都代表着不同时刻的完整的数据的快照，很适合用来做冷备
   RDB 和 AOF 都可以用来做冷备，但是 RDB 是由 redis 去控制固定时长生成快照这件事，方便，而 AOF 需要人工操作，去写一些脚本去控制备份
2. 效率高，性能影响低，可以让 redis 保持高性能，redis 会分一个子进程，让子进程来执行磁盘 IO 操作，进行 RDB 持久化
3. 相对于 AOF 来说，使用 RDB 来恢复数据速度更快
   RDB 是存储的数据的快照，恢复的时候直接加载到内存即可，而 AOF 存储的是指令日志，恢复的时候需要从头开始执行记录的所有操作。

2. RDB 的缺点

1. 在 redis 故障时，RDB 可能丢失的数据会比较多，因为它是每隔一段时间生成一次快照，在下一次快照生成之前发生故障的话，如果 redis 发生故障，那么上一次快照之后到现在的所有数据都会丢失。
2. Redis 每次 fork 子进程来执行 RDB 快照数据文件生成的时候，如果文件过大，会导致对客户端的服务暂停数毫秒，甚至数秒。因此不能使快照生成的时间间隔太长。

3. AOF 的优点

1. AOF 会更好的保护数据不会丢失，一般 AOF 会每隔1秒，通过一个后台线程执行 fsync 操作，保证 os cache 中的数据写入磁盘，最多丢失1秒钟的数据
2. AOF 日志文件是以 append-only 模式写入的，没有磁盘寻址开销，写入性能高，文件不容易出现破损，即使出现文件破损的情况，也很容易修复。
3. AOF 文件过大的时候，会在后台另一个线程进行 rewrite 操作，对 redis 读写 以及客户端性能没有什么影响。
4. AOF 记录的是一条条的日志，是可读的，如果 redis 被不小心用 flushall 清空了所有的数据，只要后台还没进行 rewrite 操作，可以将 AOF 文件里面最后一条 flushall 命令删除，再通过恢复机制，就能自动恢复所有数据。

4. AOF 的缺点

1. 对于同一份数据而已，AOF 日志文件通常都比 RDB 数据快照文件更大。
2. 开启 AOF 的话，支持的写 QPS 会比 RDB 支持的写 QPS 低，因为一般 AOF 会配置成每秒 fsync 一次日志文件
3. AOF 曾发生过 bug，通过日志进行数据恢复，恢复出来的数据和原来的数据并不是一模一样的，所以相比于 RDB ，AOF 会更容易出现 bug。不过为了避免 rewrite 过程因为合并 AOF 文件会导致的 bug，每次 rewrite 并不是基于旧的 AOF 文件日志进行 merge 的，而是基于当前 redis 中的数据重新构建指令日志。
4. 相对于 RDB 而言，数据恢复速度比较慢，做冷备不方便

5. 如何选择两种持久化机制

建议同时使用 RDB 和 AOF 两种持久化机制，AOF 保证数据更少的丢失，RDB 做冷备，在 AOF 文件损坏或丢失的时候用了进行快速数据恢复。
不过同时使用 RDB 和 AOF 两种持久化机制的话，在 redis 重启的时候，redis 会使用 AOF 来重新构建数据，因为 AOF 中的数据更加完整。

5. RDB 和 AOF 持久化配置

1. 如何配置 RDB 持久化？
   在 redis的 .conf 配置文件中修改，redis 默认开启的 RDB 机制，在文件中可以找到如图所示配置
   
   第一个数字表示间隔的时间（秒），第二个数字表示发生变化的数据的个数。
   默认配置：每分钟有10000个数据改变则存储一次快照，每5分钟有10个数据改变则存储一次快照，每15分钟有1个数据改变则存储一次快照。

2. RDB 持久化工作流程
   (1) redis 根据配置自动生成 rdb 快照文件
   (2) fork 一个子进程
   (3) 子进程将数据 dump 到 rdb 快照文件中
   (4) 完成 rdb 快照文件的生成之后，替换旧的快照文件（只会替换该配置下的 rdb 文件，不替换其它配置的 rdb 文件）

3. 如何配置 AOF 持久化
   依然是在 redis的 .conf 配置文件中修改，默认是关闭了 AOF 的，如图所示
   
   开启 AOF 持久化需先将 “no” 更改为 “yes” ，然后在下面还能找到 AOF 的几种策略，如下图所示：
   
   其中：
   （1）always：每写入一条数据就立即将数据对应的写日志从 os cache 中 fsync 到磁盘，性能极差，吞吐量低（如果一条数据都不能丢，可以使用这个）；
   （2）everysec（最常用的）：每秒将 os cache 中的数据 fsync 到磁盘----最常用，生产环境一般如此配置，性能高，QPS 可上万（有可能会丢失1秒钟的数据）；
   （3）no：redis将数据写入 os cache 中就不管了，后面 os 会根据自己的策略不时的将数据刷入磁盘，不可控。

4. AOF 的持久化工作流程
   Redis 每隔一定时间将数据的“写”操作命令以 append-only 的形式记录到 OS cache 中，再从 os cache 中 fsync 到磁盘。
   由于 AOF 文件只有一个，因此会因为不停的操作数据而变得膨胀，所以 redis 中会根据配置对 AOF 文件进行 rewrite 操作。

5. Rewrite 机制
   在 redis 配置文件中，有图示两句触发 rewrite 的配置
   
   （1）auto-aof-rewrite-percentage 100：本次增长比例大于上次的 100%（此处指的是 .aof 文件的大小）；
   （2）auto-aof-rewrite-min-size 64mb：本次 AOF 日志的大小大于 64mb。
   只有同时满足上面两个条件时，才会触发 rewrite 机制。

6. Rewrite 过程
   图解：
   

三、如何通过读写分离承载10万＋QPS

未完待续。。。。。。。。。。。。。