redis的持久化以及redis的集群模式

1. redis应用场景

1、热点数据的缓存 ----
由于redis访问速度块、支持的数据类型比较丰富，所以redis很适合用来存储热点数据，另外结合 
expire，我们可以设置过期时间然后再进行缓存更新操作，这个功能最为常见。 
2、限时业务的运用
redis中可以使用expire命令设置一个键的生存时间，到时间后redis会删除它。利用这一特性可以运用在限时的优惠活动信息、手机验证码等业务场景。 
3、计数器相关问题
什么是计数器，如电商网站商品的浏览量、视频网站视频的播放数等。为了保证数据实时效，每次浏览都得给+1，并发量高时如果每次都请求数据库操作无疑是种挑战和压力。Redis提供的incr命令来实现计数器功能，内存操作，性能非常好，非常适用于这些计数场景 。 
4、排行榜相关问题
关系型数据库在排行榜方面查询速度普遍偏慢，所以可以借助redis的SortedSet进行热点数据的排序。 在奶茶活动中，我们需要展示各个部门的点赞排行榜， 所以我针对每个部门做了一个SortedSet,然后以用户的openid作为上面的username,以用户的点赞数作为上面的score, 然后针对每个用户做一个hash, 通过zrangebyscore就可以按照点赞数获取排行榜，然后再根据username获取用户的hash信息，这个当时在实际运用中性能体验也蛮不错的。 
5、分布式锁 --Sys---本地锁
在很多互联网公司中都使用了分布式技术，分布式技术带来的技术挑战是对同一个资源的并发访问，如全局ID、减库存、秒杀等场景，并发量不大的场景可以使用数据库的悲观锁、乐观锁来实现，但在并发量高的场合中，利用数据库锁来控制资源的并发访问是不太理想的，大大影响了数据库的性能。可以利用Redis的setnx功能来编写分布式的锁，如果设置返回1说明获取锁成功，否则获取锁失败，实际应用中要考虑的细节要更多。 
这个主要利用redis的setnx命令进行，setnx："set if not exists"就是如果不存在则成功设置缓存同时返回1，否则返回0 ，这个特性在俞你奔远方的后台中有所运用，因为我们服务器是集群的，定时任务可能在两台机器上都会运行，所以在定时任务中首先 通过setnx设置一个lock，如果成功设置则执行，如果没有成功设置，则表明该定时任务已执行。 当然结合具体业务，我们可以给这个 
lock加一个过期时间，比如说30分钟执行一次的定时任务，那么这个过期时间设置为小于30分钟的一个时间 就可以，这个与定时任务的周期以及定时任务执行消耗时间相关。 
当然我们可以将这个特性运用于其他需要分布式锁的场景中，结合过期时间主要是防止死锁的出现。 
6、延时操作---延迟队列
比如在订单生产后我们占用了库存，10分钟后去检验用户是够真正购买，如果没有购买将该单据设置无效，同时还原库存。 由于redis自2.8.0之后版本提供Keyspace Notififications功能，允许客户订阅Pub/Sub频道，以便以某种方式接收影响Redis数据集的事件。 所以我们对于上面的需求就可以用以下解决方案，我们在订单生产时，设置一个key，同时设置10分钟后过期， 我们在后台实现一个监听器，监听key的实效，监听到key失效时将后续逻辑加上。 当然我们也可以利用rabbitmq、activemq等消息中间件的延迟队列服务实现该需求。 
7、分页、模糊搜索 
redis的set集合中提供了一个zrangebylex方法，语法如下： 
ZRANGEBYLEX key min max [LIMIT offffset count] 
通过ZRANGEBYLEX zset - + LIMIT 0 10 可以进行分页数据查询，其中- +表示获取全部数据 
zrangebylex key min max 这个就可以返回字典区间的数据，利用这个特性可以进行模糊查询功能，这个也是目前我在redis中发现的唯一一个支持对存储内容进行模糊查询的特性。 
前几天我通过这个特性，对学校数据进行了模拟测试，学校数据60万左右，响应时间在700ms左右，比mysql的like查询稍微快一点，但是由于它可以避免大量的数据库io操作，所以总体还是比直接mysql查询更利于系统的性能保障。 
8、点赞、好友等相互关系的存储
点赞、踩、关注/被关注、共同好友等是社交网站的基本功能，社交网站的访问量通常来说比较大，而且传统的关系数据库类型不适合存储这种类型的数据，Redis提供的哈希、集合等数据结构能很方便的的实现这些功能Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的。 又或者在微博应用中，每个用户关注的人存在一个集合中，就很容易实现求两个人的共同好友功能。 
这个在奶茶活动中有运用，就是利用set存储用户之间的点赞关联的，另外在点赞前判断是否点赞过就利用了sismember方法，当时这个接口的响应时间控制在10毫秒内，十分高效。 
9、队列 
由于redis有list push和list pop这样的命令，所以能够很方便的执行队列操作。 
Redis列表结构，LPUSH可以在列表头部插入一个内容ID作为关键字，LTRIM可用来限制列表的数量，这样列表永远为N个ID，无需查询最新的列表，直接根据ID去到对应的内容页即可。
 

总结:

1.热点数据得缓存

2.限时任务

3.计算器--incr decr

4.分布式锁。==setnx

5.排行榜---sort set

2.redis的持久化

2.1什么是redis的持久化

redis是基于内存的数据库。

优点是cpu读取内存速度快，一秒钟可以进行数十万次，可以直接和cpu速度相近，读取极快。
缺点是基于内存，存在断电数据丢失的情况。

为了防止其数据断电丢失，就需要将数据存入硬盘中，这样在断电后也可以访问到数据库当中的数据。

这个将内存的数据写入到磁盘中，防止服务器宕机内存数据丢失，就是redis的持久化。

redis提供两种持久化机制：RDB和AOF

redis的默认持久化方式是RDB。

1、RDB（快照）
RDB：是Redis DataBase缩写。

按照一定的时间将内存的数据以快照的形式保存到硬盘中，对应产生的数据文件为dump.rdb。

（1）生成快照的方式：

①客户端方式：BGSAVE 和 SAVE指令
②服务端方式：服务器配置自动触发 和 shutdown

客户端方式：

BGSAVE：客户端可以使用BGSAVE命令来创建一个快照，当接收到客户端的BGSAVE命令时，redis会创建一个子进程，子进程负责将快照写入磁盘中，而父进程继续处理命令请求。（在子进程创建之初，父子进程共享相同内存，知道父进程或子进程对内存进行了写之后，对于被写入的内存的共享就会结束服务）

SAVE：客户端使用SAVE命令创建一个快照，接收到SAVE命令的redis服务器在快照创建完毕之前将不再响应任何其他的命令。

服务端方式：

服务器通过配置方式来满足自动触发快照进行持久化，管理员需要在redis.conf中设置save配置选项，redis会在save选项条件满足之后自动触发一次BGSAVE命令，如果管理员设置了多个save配置选项，当任意save条件被满足，redis都会触发一次BGSAVE命令。

自动触发

需要指定配置文件---一般不建议改---采用默认值----底层自动执行bgsave命令

rdb数据恢复

只需要把dump.rbd文件放入按照目录，当redis服务启动时，会读取dump.rdb文件 并加载到内存中。

shutdown指令：当redis通过shutdown指令接受到关闭服务器的请求时，会触发一次SAVE命令，阻塞所有的客户端，不再执行客户端发送的任何命令，在SAVE命令执行完毕后关闭服务器。
（2）优缺点
优点：

只有一个dump.rdb文件，方便持久化
容灾性好，一个文件可以保存到安全的磁盘中。
性能最大化，子进程来完成写操作，主进程可以继续处理命令，实现IO最大化（使用单独的子进程来进行持久化，主进程不会进行任何IO操作，保证了redis的高性能）。
相对于数据集大时，比AOF的启动效率更高。

 缺点：

数据安全性第。RDB是间隔一段时间进行持久化，如果持久化之间redis发生故障，会发生数据丢失。
dump.rdb文件是一个redis中特制的二进制文件，涉及到不同的redis版本，可能会发生版本不兼容问题。

2、AOF（追加日志文件）
AOF：是Append Only File的缩写。

是指，将redis执行的所有写命令记录到日志文件中，将被执行的写命令写到AOF的文件末尾，当redis重启时，redis会从头到尾执行一次AOF文件所包含的所有写命令，以此回复AOF文件的记录的数据集。

（1）开启AOF持久化
redis默认配置中AOF持久化机制是不开启的，需要在配置中开启。

① 修改 appendonly yes 开启持久化
② 修改 appendfilename “appendonly.aof” 指定生成文件名称

 

（2）设置日志追加频率
追加频率选项：

① always【谨慎使用】
说明：每个redis写命令都要同步写入硬盘，严重降低redis速度
解释：如果用户使用了always选项，会将发生系统崩溃时出现的数据丢失减到最少，但因为这种同步策略需要对硬盘进行大量的写入操作，所以redis处理命令的速度会受到硬盘性能的限制。
注意：使用固态硬盘（SSD）时需谨慎使用always选项，这种模式不断写入少量数据，可能会引发严重的写入放大问题，导致固态硬盘的寿命从原来的几年降低为几个月。

② everysec【推荐】
说明：每秒执行一次的同步显示，将多个写命令同步到磁盘
解释：同时保障了数据安全和写入性能，redis每秒一次对AOF文件进行同步，此时AOF文件性能和不使用任何持久化特性时的性能基本相同；通过每秒同步一次AOF文件，redis可以保证，即使系统崩溃，最多丢失一秒之内产生的数据。

③ no【不推荐】
说明：由操作系统决定何时同步
解释：这个选项不好对redis性能带来影响，但是当系统宕机时，丢失的数据量具有不确定性；另外，如果用户硬盘处理写入操作不够快，当缓冲区被等待写入硬盘数据填满时，redis会处于阻塞状态，导致redis的处理命令请求速度变慢。

修改同步频率：

修改appendfsync everysec | always | no

 

（3）AOF重写
AOF文件是以追加的方式记录接收到的写命令的，不断的追加会导致AOF文件过大。
文件过大导致的问题：

① 文件系统的限制：文件系统本身对文件的大小有限制，无法保存过大文件，如果超出限制，会导致 redis 宕机，redis 执行命令速度会降低。
② 追加效率降低：AOF文件采用追加的方式写入文件，每次要遍历寻找到文件尾部，如果文件过大，追加效率会大幅度降低。
③ 执行效率降低：如果服务器发生宕机，AOF文件命令要逐一执行，文件过大导致执行内容过多，影响效率。

AOF重写：用来一定程度上减小AOF文件的体积，解决文件过大的问题。

触发重写方式

1、客户端方式触发重写

执行BGREWRITEAOF命令 不会阻塞redis服务

2、服务器配置方式自动触发

配置 redis.conf 中的 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 选项
auto-aof-rewrite-min-size 64mb 表示AOF写入文件大小大于64m才能触发重写操作。
auto-aof-rewrite-percentage 100 中的100表示百分比，表示AOF文件的体积比上一次重写之后体积至少大了 “100%” 时会自动触发。

重写原理

重写AOF的时候，创建一个重写子进程，然后读取旧的AOF文件，压缩并写入到一个临时AOF。

在此期间，主进程一边将接收到的指令累计到一个缓冲区中，一边将指令写入到旧的AOF。

（这样的好处，保证AOF文件的可用性，避免写过程时出意外）

子进程写完后，向主进程发送一个信号量，主进程就将缓冲区中的指令追加到新AOF。

用新的AOF替换旧的AOF，之后的新指令就追加到新的AOF。

（4）优缺点
优点：

数据安全，AOF持久化可以通过配置appendfsync属性，设置其记录频率。
通过append模式写文件，即使服务器宕机，也可以通过redis-check-aof工具解决数据一致问题。
更加灵活。AOF机制的 rewrite 模式，AOF文件没被rewrite之前（文件过大时回对命令进行合并重写），可以删除其中的某些命令。

缺点：

AOF文件比RDB文件更大，且回复速度更慢。
数据集大时，AOF比RDB启动效率低。

 当RDB和AOF同时开启时，redis数据恢复会优先选中AOF恢复。

3redis的集群

3.1什么是 Cluster 集群

Redis 集群是一种分布式数据库方案，集群通过分片（sharding）来进行数据管理（「分治思想」的一种实践），并提供复制和故障转移功能。

将数据划分为 16384 的 slots，每个节点负责一部分槽位。槽位的信息存储于每个节点中。

它是去中心化的，如图所示，该集群有三个 Redis 节点组成，每个节点负责整个集群的一部分数据，每个节点负责的数据多少可能不一样。

三个节点相互连接组成一个对等的集群，它们之间通过 Gossip协议相互交互集群信息，最后每个节点都保存着其他节点的 slots 分配情况。

3.2 为什么要使用redis集群

可以减少单机的压力，解决单机故障问题。

3.3第一种集群方式--主从模式配置主从模式---配从不配主。

模拟: 一台linux系统，启动三台redis服务.依靠端口号：6379主节点 6380从节点 6381从节点

3.3.1复制三个redis配置文件放入master-slave目录

 3.3.2修改三个文件的配置

开放远程连接允许任意IP连接

bind 0.0.0.0 -::1  
# 关闭保护模式
protected-mode no

分别修改三个文件的端口号
port 6379 | 6380 | 6381

修改配置文件中相应的文件名
dbfilename dump6379.rdb | dump6380.rdb | dump6381.rdb

分别修改三个日志文件名称
appendfilename "appendonly6379.aof"

3.3.3启动三台redis

 查看redis进程

3.3.4 三台客户端访问redis相应的服务器

redis-cli -p 6379

redis-cli -p 6380

redis-cli -p 6381

 3.3.5查看redis的角色

info replication

 发现都是主节点，原因是还没有配置主从关系

3.3.6配置主从关系--从节点

slaveof 主节点ip 主节点port

 

 再次查看主从关系

 3.3.7 往主节点添加数据

思考：在主节点添加的数据会在从节点同步吗？

 由实践可知，主节点添加的数据会在从节点同步。

思考：

如果主节点挂掉--从节点是否会转变成主节点？---不会。

如果新增一个从节点，该从节点是否可以把之前的数据同步过来?可以

从节点是否可以进行写操作？只负责读操作不能负责写操作

主节点是否可以进行写操作和读操作？可以负责读写操作。

缺点:----如果主节点宕机后，从节点无法上位，该redis服务就无法执行写操作了。  

3.4第二种集群模式---哨兵模式

3.4.1哨兵模式概述

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

这里的哨兵有两个作用

• 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。

• 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

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

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

3.4.2更改sentinel.conf文件

3.4.3 开启哨兵服务

 redis-sentinel sentinel.conf

 3.4.5演示: 挂掉主节点

 6379客户端 shutdown

 如果原来的主节点回来，它将作为当前主节点的从节点。

缺点: 它只有一个主节点---如果现在写操作并发高，那么还会导致主节点压力过大。  

3.5 第三种模式---集群模式

去中心化

准备: 6台redis服务。---6个服务中不能有数据。

7001

7002

7003=============主节点

7004

7005

7006=====从节点

 3.5.1修改配置文件

修改配置文件: 都需要改

bind 0.0.0.0 69行

port 7001

关闭保护模式

protected-mode no

daemonize yes

# 打开aof 持久化

appendonly yes

# 开启集群

cluster-enabled yes

# 集群的配置文件,该文件自动生成

cluster-config-file nodes-7001.conf 841行

# 集群的超时时间

cluster-node-timeout 5000 847行

3.5.2 开启上面6台redis服务器

 3.5.3为6台redis配置槽以及主从关系

redis-cli --cluster create --cluster-replicas 1 192.168.154.201:7001 192.168.154.201:7002 192.168.154.201:7003 192.168.154.201:7004 192.168.154.201:7005 192.168.154.201:7006

-- --cluster-replicas 1： 从节点的个数

 验证:

redis-cli -c -h 127.0.0.1 -p 7001