redis 02

1. redis应用场景

一：缓存—热数据

        热点数据（经常会被查询，但是不经常被修改或者删除的数据），首选是使用redis缓存，毕竟强大到冒泡的QPS和极强的稳定性不是所有类似工具都有的，而且相比于memcached还提供了丰富的数据类型可以使用，另外，内存中的数据也提供了AOF和RDB等持久化机制可以选择，要冷、热的还是忽冷忽热的都可选。

二：计数器

        诸如统计点击数等应用。由于单线程，可以避免并发问题，保证不会出错，而且100%毫秒级性能；

命令：INCRBY

三：队列

        相当于消息系统，ActiveMQ，RocketMQ等工具类似，如果对于数据一致性要求高的话还是用RocketMQ等专业系统。

        由于redis把数据添加到队列是返回添加元素在队列的第几位，所以可以做判断用户是第几个访问这种业务；队列不仅可以把并发请求变成串行，并且还可以做队列或者栈使用。

四：位操作（大数据处理）

        用于数据量上亿的场景下，例如几亿用户系统的签到，去重登录次数统计，某用户是否在线状态等等。

想想一下腾讯10亿用户，要几个毫秒内查询到某个用户是否在线，你能怎么做？这里要用到位操作——使用setbit、getbit、bitcount命令。

原理是：

        redis内构建一个足够长的数组，每个数组元素只能是0和1两个值，然后这个数组的下标index用来表示我们上面例子里面的用户id（必须是数字哈），那么很显然，这个几亿长的大数组就能通过下标和元素值（0和1）来构建一个记忆系统，上面我说的几个场景也就能够实现。用到的命令是：setbit、getbit、bitcount。

五：分布式锁与单线程机制

        验证前端的重复请求（可以自由扩展类似情况），可以通过redis进行过滤：每次请求将request ip、参数、接口等hash作为key存储redis(幂等性请求)，设置多长时间有效期，然后下次请求过来的时候先在redis中检索有没有这个key，进而验证是不是一定时间内过来的重复提交秒杀系统，基于redis是单线程特征，防止出现数据库’爆破’全局增量ID生成，类似’秒杀’。

六：最新列表

        例如新闻列表页面最新的新闻列表，如果总数量很大的情况下，尽量不要使用select a from A limit 10这种low货，尝试redis的 LPUSH命令构建List，一个个顺序都塞进去就可以啦。不过万一内存清掉了咋办？也简单，查询不到存储key的话，用mysql查询并且初始化一个List到redis中就好了。

七：排行榜

谁得分高谁排名往上。命令：ZADD（有续集，sorted set）

八: 适用场景：

数据高并发的读写；

海量数据的读写；

对扩展性要求高的数据。

概 述 常 见 的 有 ：

• 缓存
• 数据共享分布式
• 分布式锁
• 全局ID
• 计数器
• 限流
• 位统计
• 购物车
• 用户消息时间线timeline
• 消息队列
• 抽奖
• 点赞、签到、打卡
• 商品标签
• 商品筛选
• 用户关注、推荐模型
• 排行榜

2. redis的持久化

2.1 什么是redis 持久化

edis是基于内存的数据库。

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

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

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

2.2  redis持久化的方式

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

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

2.3   RDB（快照）

RDB：是Redis DataBase缩写。

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

（1）生成快照的方式：

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

客户端方式：

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

演示图示：

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

 

演示图示： 

 
服务端方式：

1.  服务器通过配置方式来满足自动触发快照进行持久化，管理员需要在redis.conf中设置save配置选项，redis会在save选项条件满足之后自动触发一次BGSAVE命令，如果管理员设置了多个save配置选项，当任意save条件被满足，redis都会触发一次BGSAVE命令。
2.  shutdown指令：当redis通过shutdown指令接受到关闭服务器的请求时，会触发一次SAVE命令，阻塞所有的客户端，不再执行客户端发送的任何命令，在SAVE命令执行完毕后关闭服务器。

（2）优缺点
优点：

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

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

2.4 rdb数据恢复

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

2.5  AOF持久化

AOF：是Append Only File的缩写。

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

（1）开启AOF持久化

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

测 试： 

（4）优缺点

优点：

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

缺点：

1. AOF文件比RDB文件更大，且回复速度更慢。
2. 数据集大时，AOF比RDB启动效率低。
当RDB和AOF同时开启时，redis数据恢复会优先选中AOF恢复。
 

3. redis 集群

3.1 什么是redis 集群

Redis 集群是一个可以在多个 Redis 节点之间进行数据共享的设施（installation）。

Redis 集群不支持那些需要同时处理多个键的 Redis 命令， 因为执行这些命令需要在多个 Redis 节点之间移动数据， 并且在高负载的情况下， 这些命令将降低 Redis 集群的性能， 并导致不可预测的错误。

Redis 集群通过分区（partition）来提供一定程度的可用性（availability）： 即使集群中有一部分节点失效或者无法进行通讯， 集群也可以继续处理命令请求。

3.2 为什么要使用redis集群

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

性能

Redis 本身的QPS 已经很高了，但是如果在一些并发量非常高的情况下，性能还是会受到影响。这个时候我们希望有更多的Redis 服务来完成工作。

扩展

第二个是出于存储的考虑。因为Redis 所有的数据都放在内存中，如果数据量大，很容易受到硬件的限制。升级硬件收效和成本比太低，所以我们需要有一种横向扩展的方法。

可用性

第三个是可用性和安全的问题。如果只有一个Redis 服务，一旦服务宕机，那么所有的客户端都无法访问，会对业务造成很大的影响。另一个，如果硬件发生故障，而单机的数据无法恢复的话，带来的影响也是灾难性的。
 

Redis 支持三种集群方案

• 主从复制模式
• Sentinel（ 哨 兵 ）模式
• Cluster （ 集 群 ）模式

3.3 第一种集群方式--主从模式

        主从复制模式中包含一个主数据库实例（master）与一个或多个从数据库实例（slave），客户端可对主数据库进行读写操作，对从数据库进行读操作，主数据库写入的数据会实时自动同步给从数据库。

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

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

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

 

 

 2.     bind 0.0.0.0 -::1
        # 关闭保护模式
        protected-mode no
        port   6381
        dbfilename dump6381.rdb 
        appendfilename "appendonly6381.aof"

3.     bind 0.0.0.0 -::1
        # 关闭保护模式
        protected-mode no
        port   6382 
        dbfilename dump6382.rdb 
        appendfilename "appendonly6382.aof"

 

 （3） 启动三台 redis 

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

redis-cli -p 6380

redis-cli -p 6381

redis-cli -p 6382

(5) 查看redis的角色

info replication

 看出他们之间没有主从关系

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

slaveof 主节点ip 主节点port

 (7) 往主节点添加数据   从节点取出

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

上面的主从模式的缺点:----如果主节点宕机后，从节点无法上位，该redis服务就无法执行写操作了。---- 引出哨兵模式。

哨兵是Redis集群架构中非常重要的一个组件，哨兵的出现主要是解决了主从复制出现故障时需要人为干预的问题。 （1）集群监控 ：负责监控Redis master和slave进程是否正常工作 （2）消息通知 ：如果某个Redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员 （3）故障转移 ：如果master node挂掉了，会自动转移到slave node上 （4）配置中心 ：如果故障转移发生了，通知client客户端新的master地址 原理：当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。

 （1）修改  sentinel.conf文件  

（2） redis-sentinel sentinel.conf   开启哨兵服务

（3） 往主节点添加数据

演示: 挂掉主节点   6380客户端 shutdown

 

如果原来的主节点回来---它需要跟在现在的主节点混。

3.5 第三种集群方式--哨兵模式

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

Redis Cluster是一种服务器 Sharding 技术，3.0版本开始正式提供。

Redis 的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台 Redis 服务器都存储相同的数据，很浪费内存，所以在 redis3.0上加入了 Cluster 集群模式，实现了 Redis 的分布式存储，也就是说每台 Redis 节点上存储不同的内容。

集群的特点

• 所有的 redis 节点彼此互联(PING-PONG机制)，内部使用二进制协议优化传输速度和带宽。
• 节点的 fail 是通过集群中超过半数的节点检测失效时才生效。
• 客户端与 Redis 节点直连，不需要中间代理层.客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可。

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

7001

7002

7003   

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

7004

7005

7006 

=============从节点

修改配置文件: 都需要改

bind 0.0.0.0 

port 7001

daemonize yes

# 打开aof 持久化

appendonly yes

# 开启集群

cluster-enabled yes

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

cluster-config-file nodes-7001.conf 

# 集群的超时时间

cluster-node-timeout 5000 

开启上面6台redis服务器

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

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

 

验证: