1.1、主从复制

使用一台服务器进行模拟Redis的主从复制

1.1.1、概念

一般来说，要将Redis运用于工程项目中，只使用一台Redis是万万不能的，原因如下：
从结构上，单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大；
从容量上，单个Redis服务器内存容量有限，就算一台Redis服务器内容容量为256G，也不能将所有内容用作Redis存储内存，一般来说，单台Redis最大使用内存不应该超过20G。

考虑如下一种场景：电子商务网站上的商品，一般都是一次上传，无数次浏览的，说专业点也就是”多读少写”。

对于这种场景，我们可以使如下这种架构：

如图所示，将一台Redis服务器作主库(Matser)，其他三台作为从库(Slave)，主库只负责写数据，每次有数据更新都将更新的数据同步到它所有的从库，而从库只负责读数据。
这样一来，就有了两个好处：
读写分离，不仅可以提高服务器的负载能力并且可以根据读请求的规模自由增加或者减少从库的数量棒极了；
数据被复制成了了好几份，就算有一台机器出现故障，也可以使用其他机器的数据快速恢复。
需要注意的是：在Redis主从模式中，一台主库可以拥有多个从库，但是一个从库只能隶属于一个主库。

1.1.2、redis主从复制特点

1、Master可以拥有多个Slave；
2、多个salve可以连接同一个Master，还可以链接到其他的slave
3、主从复制不会阻塞Master，在同步数据时，master可以继续处理client请求
4、提供系统的伸缩性。

1.1.3、redis主从复制配置

在Redis中，要实现主从复制架构非常简单，只需要在从数据库的配置文件中加上如下命令即可：
slaveof 主数据库地址 主数据库端口
主数据库不需要任何配置。

配置步骤：

1、重新安装一份redis,作为从库，拷贝redis.conf 并修改

端口号为6380
设置slaveof 主库ip地址 端口号
设置masterauth 主库密码

2、启动从库

/usr/local/redisslave1/bin/redis-server /usr/local/redisslave1/bin/redis.conf

3、分别使用2个客户端连接主库和从库

拷贝连接会话，并重命名slave，打开客户端连接从库

在主库和从库的连接客户端中输入：

info replication

4、测试数据的主从复制

如果主库宕机，那么

如果主库宕机，那么就无法再继续写入数据

1.2、哨兵模式

1.2.1、概念

Redis-Sentinel（哨兵模式）是官方推荐的高可用解决方案，当redis在做master-slave的高可用方案时，假如master宕机了，redis本身（以及其很多客户端）都没有实现自动进行主备切换，而redis-sentinel本身也是独立运行的进程，可以部署在其他与redis集群可通讯的机器中监控redis集群。

有了主从复制的实现之后，我们如果想从服务器进行监控，那么在redis2.6以后提供了一个”哨兵“机制，并在2.8版本以后功能稳定起来。
哨兵：顾名思义，就是监控Redis系统的运行状况

哨兵模式的特点：

1、不时地监控redis是否按照预期良好地运行;
2、如果发现某个redis节点运行出现状况，能够通知另外一个进程(例如它的客户端);
3、能够进行自动切换。当一个master节点不可用时，能够选举出master的多个slave(如果有超过一个slave的话)中的一个来作为新的master,其它的slave节点会将它所追随的master的地址改为被提升为master的slave的新地址。
4、哨兵为客户端提供服务发现，客户端链接哨兵，哨兵提供当前master的地址然后提供服务，如果出现切换，也就是master挂了，哨兵会提供客户端一个新地址。

哨兵（sentinel）本身也是支持集群的
很显然，单个哨兵会存在自己挂掉而无法监控整个集群的问题，所以哨兵也是支持集群的，通常用三台哨兵机器来监控一组redis集群。

1.2.2、配置

配置哨兵模式主要是防止主库宕机，所以本文档就在从库中进行配置哨兵模式

拷贝配置文件，并修改

命令：

cp /usr/local/redis-3.2.11/sentinel.conf /usr/local/redisslave1/bin/ 拷贝哨兵的配置
vim /usr/local/redisslave1/bin/sentinel.conf 修改哨兵模式的配置文件

配置解释

dir： 日志路径，根据自己的要求保存。
sentinel monitor mymaster 10.0.31.144 6379 1 解释：#名称 #ip #端口号 # 投票选举次数（即有多少篇就被选举为主，这里节点少，就配置为1）。
sentinel down-after-millisecond mymaster 5000 解释：哨兵程序多久去监控一次集群，#默认 30s 检查一次，这里配置超时30000毫秒为宕机。
sentinel parallel-syncs mymaster 1 解释：有多少个从节点
sentinel failover-timeout mymaster 600000 解释：若哨兵在该配置值内未完成failover操作(即发生故障时，m/s切换)，本次failover失败
sentinel parallel-syncs mymaster 1 解释：有多少个从节点

1.2.3 启动

/usr/local/redisslave1/bin/redis-server /usr/local/redisslave1/bin/sentinel.conf --sentinel
启动哨兵模式
/usr/local/redis/bin/redis-cli -h 10.211.55.12 -p 26379 info sentinel

1.3、持久化

Redis持久化存储支持两种方式：RDB和AOF。

RDB一定时间取存储文件，AOF默认每秒去存储历史命令，官方建议两种方式同时使用
没有持久化的redis和memcache一样，相当于一个纯内存的数据库

Redis是支持持久化的内存数据库，也就是说redis需要经常将内存中的数据同步到硬盘来保证持久化。

1.3.1、RDB

RDB(snapshotting快照)是将数据写入一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，达到数据恢复。
优点：使用单独子进程来进行持久化，主进程不会进行任何IO操作，保证了redis的高性能
缺点：RDB是间隔一段时间进行持久化，如果持久化之间redis发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候

默认方式，将内存中以快照的方式写入到二进制文件中，默认为dump.rdb，可以通过配置设置自动做快照持久化的方式。我们可以配置redis在n秒内如果m个key修改，就自动做快照

vim /usr/local/redis/conf/redis.conf 修改配置文件
RDB默认开启，redis.conf中的具体配置参数如下:
save 900 1 #900秒内，超过1个key被修改，则发起快照保存
save 300 10 #300秒内，超过10个key被修改，则发起快照保存
save 60 10000 #60秒内，超过10000个key被修改，则发起快照保存
dbfilename dump.rdb 持久化数据存储在本地的文件
dir ./ 持久化数据存储在本地的路径，如果是在/redis/redis-3.0.6/src下启动的redis-cli，则数据会存储在当前src目录下

持久化过程：

当满足save的条件时，比如更改了1个key，900s后会将数据写入临时文件，持久化完成后将临时文件替换旧的dump.rdb。（存储数据的节点是到触发时间时的的节点）
使用RDB恢复数据：
自动的持久化数据存储到dump.rdb后。实际只要重启redis服务即可完成（启动redis的server时会从dump.rdb中先同步数据）
使用命令进行持久化save存储：
./redis-cli -h ip -p port save
./redis-cli -h ip -p port bgsave
一个是在前台进行存储，一个是在后台进行存储。

1.3.2、AOF

AOF(append-only file)是将执行过的指令记录下来，数据恢复时按照从前到后的顺序再将指令执行一遍，实现数据恢复
优点：可以保持更高的数据完整性，如果设置追加file的时间是1s，如果redis发生故障，最多会丢失1s的数据；且如果日志写入不完整支持redis-check-aof来进行日志修复；AOF文件没被rewrite之前（文件过大时会对命令进行合并重写），可以删除其中的某些命令（比如误操作的flushall）。
缺点：AOF文件比RDB文件大，且恢复速度慢。

类似于mysql日志，由于快照方式是在一定时间间隔做一次，所以可能发生redis意外宕机的情况就会丢失最后一次快照后的所有被修改的数据，aof比快照方式有更好的持久化型，是由于redis在使用aof时，redis会将每一个收到的写命令都通过write函数追加到命令中，在redis重新启动时会重新执行文件中保存的写命令在内存中重建这个数据库的内容，这个文件在redis/bin目录下，appendonly.aof。aof不是立即写到硬盘上，可以通过配置文件修改强制写到硬盘中。

修改配置

appendonly yes //启动aof持久化 ,持久化有三种方式：
#appendfsync always //收到写命令就立即写入到磁盘，效率最慢，但是保证完整的持久化（最常用）
#appendfsync everysec //每秒写一次硬盘，在性能和持久化方面做了很好的这种
#appendfsync no //完全依赖os，性能最好，持久化没保证。

重启redis发现bin/目录下多了一个appendonly.aof

提示：开启aof后之前的rdb模式就失效了，且之前的数据会被清空。