linux中安装redis
下载地址：http://redis.io/download
安装步骤：Linux安装Redis.docx

一、事务、连接

1.1 redis中的事务

Redis也支持事务，但是它的事务不支持原子性，如果一个事务中存在多个操作指令，但是不保证所有的指令都能操作成功
原子性：一个事务中多条SQL那么同时成功要么同时失败
常见指令：

• multi 开启事务
• exec 执行事务

举例：

multi
set name zhangsan
set age 10
incr age
incr name
set gender man
exec

其中，incr name会执行失败，其他执行成功

1.2 redis连接基础命令

下表列出了 redis 连接的基本命令：

二、持久化

2.1 RDB（快照）

直接将内存中的数据(二进制)以快照的方式写入到磁盘上的文件中

2.1.1 rdb的触发时机

• 按照配置文件中的策略进行持久化，只要达到一定的条件就会自动持久化
• 程序员可以手动进行持久化
  • save 在连接上redis之后输入save，可以让redis进行持久化操作，但是通过redis主线程实现持久，就会造成在持久化的时间内无法进行读写操作
  • bgsave 会开启一个子线程进行持久化的操作，主线程依旧提供执行命令的操作，不影响数据读写
• 当执行shutdown触发持久化

2.1.2 查看并修改配置文件中rdb策略

vi /usr/local/redis/redis.conf

2.1.3 RDB的持久化配置

时间策略（默认）
save 900 1
save 300 10
save 60 10000

文件名称dbfilename dump.rdb
文件保存路径 redis.conf所在目录下dir ./
导入时是否检查rdbchecksum yes

配置解释
·save 900 1 表示900s内如果有1条是写入命令，就触发产生一次快照，可以理解为就进行一次备份
·save 300 10 表示300s内有10条写入，就产生快照
下面的类似，那么为什么需要配置这么多条规则呢？因为Redis每个时段的读写请求肯定不是均衡的，为了平衡性能与数据安全，我们可以自由定制什么情况下触发备份。所以这里就是根据自身Redis写入情况来进行合理配置。

2.1.4 RDB文件备份，快速恢复数据案例

一般在生产环境我们除了用RDB文件对redis中的数据进行备份以外，还会对RDB进行备份，以防止不小心删除RDB文件时数据丢失
·将dump.rdb文件拷贝一份到备份位置
cp dump.rdb abc.rdb
·shutdown关闭redis（在关闭时redis会自动备份数据到RDB文件中）
127.0.0.1:6379>shutdown
·删除dump.rdb文件
rm -f dump.rdb
·启动redis，输入keys 查看redis中所有的key，可以看到现在是没有任何数据的
redis-server redis.conf
redis-cli
127.0.0.1:6379>keys
·shutdown关闭redis
127.0.0.1:6379>shutdown
·将备份的RDB文件拷贝到当前位置，名字还是叫做dump.rdb
cp abc.rdb dump.rdb
·redis-server redis.conf重启redis，再次输入keys ，可以看到数据已经恢复
redis-server redis.conf
redis-cli
127.0.0.1:6379>keys

2.1.5 RDB原理

在Redis中RDB持久化的触发分为两种：自己手动触发与Redis定时触发。
针对RDB方式的持久化，手动输入以下命令完成手动持久化：
·save：会阻塞当前Redis服务器，直到持久化完成，线上应该禁止使用。
·bgsave：该触发方式会fork一个子进程，由子进程负责持久化过程，因此阻塞只会发生在fork子进程的时候。
而自动触发的场景主要是有以下几点：
·根据我们的 save m n 配置规则自动触发；
·从节点全量复制时，主节点发送rdb文件给从节点完成复制操作，主节点会触发 bgsave；
·执行 debug reload 时；
·执行 shutdown时，如果没有开启aof，也会触发。
由于 save 基本不会被使用到，我们重点看看 bgsave 这个命令是如何完成RDB的持久化的。

这里注意的是 fork 操作会阻塞，导致Redis读写性能下降。我们可以控制单个Redis实例的最大内存，来尽可能降低Redis在fork时的事件消耗。

2.2 AOF（append only file 默认没开启）

记录每一次的写操作：set del incr等修改数据的操作
AOF是redis的一种持久化方式，用来记录所有的写操作，但是随着时间增加，aof文件会越来越大，所以需要进行重写，将内存中的数据重新以命令的方式写入aof文件。
在重写的过程中，由于redis还会有新的写入，为了避免数据丢失，会开辟一块内存用于存放重写期间产生的写入操作，等到重写完毕后会将这块内存中的操作再追加到aof文件中。

2.2.1 开启AOF

打开redis配置文件
vi /usr/local/redis/redis.conf
将第699行 no 修改成yes

2.2.2 AOF持久化策略（一般采用everysec）

• always 只要执行一次修改操作就立即进行记录
• everysec 每隔一秒持久化一次（默认）
• no 不持久化，交给操作系统来决定，例如系统关闭进行持久化操作

2.2.3 利用appendonly.aof文件恢复数据

·关闭redis
·重启redis
·连接redis，输入keys *查看数据
可以看到数据只有appendonly.aof中保存的数据，redis启动时会先检查AOF文件是否存在，如果不存在就尝试加载RDB。那么为什么会优先加载AOF呢？因为AOF保存的数据更完整，通过上面的分析我们知道AOF基本上最多损失1s的数据。

redis在重启时会自动去恢复数据，如果RDB与AOF里面保存的数据不一致，以AOF为准，因为AOF丢失数据相对来说较少

2.2.4 AOF原理

1、记录是所有的写操作，都是以追加的方式记录，但是在某种程度上来说记录的数据中会在垃圾数据，例如：

set name zhangsan
del name
set age
del age

以上指令记录下来之后，结果数据是无效的数据，而且在利用AOF进行数据恢复，redis就会去执行AOF中每一条指令，为了避免垃圾数据过多，需要对AOF文件进行重写（排除垃圾数据）

2、重写AOF文件（去掉垃圾数据）
触发重写时机：在redis.conf配置文件有配置

当文件大小第一次达到64MB时触发重写，重写得到两种情况：重写之后数据还是64MB，那么下一次重写触发时机是128MB；重写之后数据小于64MB，下一次重写时达到64MB时

2.3 RDB与AOF区别（面试）

• RDB为快照方式，文件存储的就是内存中的二进制数据，而AOF记录是所有的写操作
• RDB文件不可能出现垃圾数据，而AOF大概率存在垃圾数据
• AOF会通过重写机制淘汰垃圾数据，而RDB不会进行任何重写
• 从数据恢复速度来说，RDB要比AOF快，因为RDB存储就是二进制文件直接读取到内存中就行，而AOF需要一条一条的执行这些写操作
• 从数据完整性来说，AOF要高于RDB，从默认配置来说AOF最多丢失1秒钟的数据，而RDB至少丢失60秒的数据

redis是不是必须进行持久化才能保证数据安全？
答案：不是

三、Redis主从复制

如果想要提高数据的安全性、redis性能除了可以通过数据持久化保证数据安全之外，还可以通过主从复制来实现数据安全及性能提升
主：主机
从：从机
读写分离：主机提供写操作，而从机提供读操作

在同一个虚拟机上实现运行三个redis服务器

1、将redis.conf文件拷贝三份
2、修改新文件的以下内容

修改端口号         92行
修改进程文件       158行
修改日志文件       171行
修改rdb文件名      253行
关闭AOF或者修改AOF文件名    可选项   699或者703

3、开启三个xshell窗口，分别启动三个redis
redis-server redis6379.conf
redis-server redis6380.conf
redis-server redis6381.conf
redis-cli -p 6379
redis-cli -p 6380
redis-cli -p 6381
4、通过info replication查看当前redis的身份
5、在从机上输入：slaveof 127.0.0.1 6379 实现主从复制结构
6、在主机上设置key，在从机上获取key 能成功表明主从复制成功

四、哨兵模式

当主机在停机期间怎么实现功能能正常使用呢？使用哨兵机制（哨兵模式）
主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。
哨兵模式概述
哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

3.1 单哨兵模式

这里的哨兵有两个作用
·通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
·当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

3.1.1 创建哨兵的配置文件,编写以下信息

protected-mode no  
port 8000
sentinel monitor custom_master 192.168.74.146 6379 1

protected-mode 保护模式 需要关闭
port 哨兵运行时端口
monitor 监控
custom_master 主机名，程序员自定义
192.168.74.146 6379 主机的ip及端口
1(最后那个) 有多少个哨兵监控到主机挂掉就开始选举新的主机

3.1.2 启动哨兵

redis-sentinel xxx.conf

3.1.3 关闭主机，观察哨兵控制台信息、

3.2 哨兵进行故障切换的原理

监控：哨兵每隔10秒钟向主机发送一次确认消息，主机收到之后会自动给哨兵返回一个消息，表示主机正在正常工作（心跳检测），当哨兵连续3次收不到主机的响应，它就认为主机挂掉，就开进行选举，从从机中随机选择一个作为新的主机，将另外的从机的主机信息改为新的主机。

3.3 多哨兵模式

一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

3.3.1 故障切换（failover）

假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，一切都是透明的。

3.3.2 原理

当认为主机下线的哨兵达到一定数量时，会由其中的一个哨兵随机选取一个从机，然后进行投票，如果所有哨兵都投票给该从机，则该从机被选举为新的主机，然后进行故障切换。