redis

1. redis应用场景

2. redis的持久化方式

3. redis的集群

4. java 连接redis的服务器

1.reids 的应用场景

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分钟的一个时间 就可以，这个与定时任务的周期以及定时任务执行消耗时间相关。 
当然我们可以将这个特性运用于其他需要分布式锁的场景中，结合过期时间主要是防止死锁的出现。 

2. redis的持久化

持久化：将内存中的数据保存到磁盘中就是持久化防止数据丢失

持久化的方式：

1.第一种: RDB---快照模式---在一定时间间隔内，对当前redis内存中的数据进行拍照存储。
2.第二种: AOF---日志追加---每次执行的写命令，都会通过一个函数write记录到日志中。

RDB快照储存

1.什么时候触发：

三种方式: save（自动） bgsave（自动） 通过配置文件（手动）

默认保存的文件名称: dump.rdb

2.save和bgsave的区别

save模式：

该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止

执行完成时候如果存在老的RDB文件，就把新的替代掉旧的。我们的客户端可能都是几万或者是几十万，这种方式显然不可取。

bgsave模式 ：

执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体流程如下：

具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令

自动触发：

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

RDB数据恢复

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

AOF持久化

它会把每个写命令通过write函数记录到日志文件中。默认改持久化没有开启。需要修改配置文件来开启aof模式。

 RDB的优缺点：

优点：数据恢复速度快

缺点：数据完整性差(因为是隔段时间保存一次大量客户端访问时，一段时间的数据量大)

AOF的优缺点：

优点：数据完整性好(因为每次修改(写/修改/删除)都会保存，即使丢失也只丢失了最后一次修改命令)

缺点：数据恢复速度比较慢(因为它需要把日志文件中所有的命令执行一遍)

DRB和AOF可以同时开启，如果两则同时开启:

 默认恢复数据时采用的时AOF.

3. redis集群

为什么使用集群

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

三种集群方式：

1.主从模式

 配置主从模式---配从不配主。

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

(1)复制三个redis配置文件放入cluster-qy163目录

(2)修改三个文件的配置

bind 0.0.0.0 -::1
# 关闭保护模式
protected-mode no
port 6380 | 6381 | 6382
dbfilename dump6380.rdb | dump6381.rdb | dump6382.rdb
appendfilename "appendonly6380.aof"

(3)启动三台redis

(4)三台客户端访问redis相应的服务器

 (5)查看redis的角色

(6)配置主从关系---从节点

slaveof 主节点ip 主节点port

 (7) 往主节点添加数据(只有主节点可以修改数据，从节点只能读)

 

2.哨兵模式

 

 sentinel.conf文件

 1 代表 1个主节点

 开启哨兵服务

演示: 挂掉主节点 

哨兵就会投票选取一个当主节点这里是6381 当原节点回来之后就会成为新节点的从

3. 集群模式

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

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

 

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

 

 

当主添加数据时会根据key的值分配对应的槽