随笔记——Redis

概览

1 基础知识点

1.1 Redis数据类型及使用场景

• String 常规的set和get操作value可以是Stirng也可以是数字。value是数字的时候一般是做一些计数功能。
• list 可以做简单的消息队列、还可以用lrange命令做基于redis的分页功能、做排队功能先进先出。
• hash value存放的是结构化的对象可以方便的操作其中的某个字段
• set 存放无重复值得集合可以做全局得去重功能
• zset 相比set具有权重参数score集合中得元素能够按照score进行排列作为排行榜进行使用取TopN

1.2 使用Redis的好处及适用场景

好处

• 速度快数据存在内存中
• 丰富的数据类型String、list、hash、set、zset
• 支持事务操作都是原子性的
• 丰富的特性可用于缓存、消息、按key设置过期时间超时自动删除

适用场景
Redis数据类型及使用场景

1.3 Redis为什么是单进程单线程

Redis是单进程单线程的利用队列技术将并发访问变为串行访问消除了传统数据库串行的开销

1.4 Redis的好处及适用场景为什么这么快

1. 完全基于内存
2. 数据结构简单且数据操作也简单
3. 采用单线程避免了线程上线文切换
4. 使用了多路I/O复用模型

1.5 Redis的过期策略以及淘汰策略

过期策略

• 定时过期一key一定时期
• 惰性过期在使用key时判断key是否过期过期则清除
• 定期过期定时过期和惰性过期折中

淘汰策略

• voltile-lru从已设置过期时间的数据中挑选最近最少使用的数据淘汰
• voltile-ttl从已设置过期时间的数据中挑选将要过期的数据淘汰
• voltile-random从已设置过期的时间的数据中任意挑选数据淘汰
• allkeys-lru在所有数据中挑选最近最少使用的数据淘汰
• allkeys-random在所有数据中任意挑选数据淘汰
• no-eviction禁止驱逐数据

1.6 缓存雪崩、缓存击穿、缓存穿透、缓存预热、缓存降级、缓存更新等概念

• 缓存雪崩主要由于Redis服务器不可用或者缓存的热点数据失效使得同一时间所有的请求都直接落到数据库上。【对于Reids服务器不可用多台计器做主从复制或者多副本实现高可用。对于热点数据同时失效缓存时间加一个随机值】
• 缓存击穿由于key失效此时正好有大量的请求访问这个key。【异步线程维护缓存数据】
• 缓存穿透查询本身不存在的数据。【使用布隆过滤器或者缓存空数据并设置过期时间】
• 缓存预热系统上线后将相关的数据直接加载到缓存系统。【缓存刷新页面、项目启动时进行加载、定时刷新缓存】
• 缓存降级当服务出现问题保证核心服务可用。
• 缓存更新对缓存数据进行失效、过期。

1.7 本地缓存和分布式缓存

本地缓存可以使用java自带的msp或guava实现主要的特点是轻量以及快速生命周期随之jvm的销毁而结束并且在多实例的情况下每个实例都需要各自保存一份缓存缓存不具备一致性。
分布式缓存使用redis或memcached在多实例请跨国下各实例共用一份缓存数据缓存具有一致性。不过要保持redis或memecached的高可用整个程序架构上就较为复杂了。

1.8 Redis的持久化机制

Redis提供了两种持久化机制RDB和AOF。

1.8.1 RDB持久化机制

概念将Redis某一时刻的数据持久化到磁盘中是一种快照式的持久化方法。

优点

1. 只有一个文件dump.rdb方便持久化可以用来做数据的备份
2. RDB对Redis的读写服务性能影响较小主要是因为Redis启动了一个fork子进程进行数据的持久化
3. RDB数据恢复更快

缺点

1. Redis意外宕机时会丢失部分数据
2. 当数据量较大时fork的过程是非常耗时的fork子进行时会阻塞阻塞期间不能响应客户端的请求

1.8.2 AOF持久化机制

概念AOF方式是将执行过的写指令记录下来在数据恢复时按照从前到后的顺序再将指令都执行一遍

优点

1. 保持数据时间间隔为1秒数据丢失更少
2. AOF文件是一个只进行追加的日志文件不需要在写入时读取文件
3. Redis可以在AOF体积过大时自动地在后台对AOF进行重写
4. AOF文件可读性高分析容易

缺点

1. 相同数据量AOF文件比RDP文件大
2. 恢复速度慢

1.8.3 最佳使用

混合持久化结合RDB和AOF的优点在写入的时候先把当前的数据以RDB的方式写入到文件的开头再将后续的操作命令以AOF的格式存入文件这样既能保证Redis重启时的速度又能降低数据丢失的风险。

1.9 如何保证数据库和缓存数据的一致性

1. 更新数据库的同时更新缓存并发场景不高的情况下
2. 通过消息来更缓存时效性无法保证
3. 通过mysql binlog消息更新缓存

2 Redis高可用

2.1 Redis主从

2.1.1 概念

主从模式主要使用主从复制保证主从数据一致进行读写分离的方式避免单点故障。

2.1.2 作用

• 数据冗余 实现了数据的热备份时持久化之外的一种数据冗余。
• 故障恢复 当主节点出现问题时可以有从节点提供服务实现快速故障恢复。
• 负载均衡 主从的基础上配合读写分离分担服务器压力提高并发量。
• 高可用的基础 主从复制时哨兵和集群的基础。

2.1.3 原理

全量复制
首先要确认主从关系其次开始全量复制
步骤

1. 主从建立连接协商同步过程
2. 主库将所有数据同步给从库
3. 主库把第2步执行过程中新收到的写命令再发送个从库

增量复制
如果主从库断开从库与主库需要重新进行一次全量复制的话开销大这是就需要使用增量复制来减小开销

主从同步策略
主从刚刚连接的时候进行全量复制全同步结束后进行增量复制。当然如果有需要slave在任何时候都可以发起全量复制。Redis的策略无论何时首先尝试进行增量复制如果不成功再进行全量复制。

2.2 Redis哨兵

2.2.1 概念

在主从复制的基础上如果主节点出现故障通过哨兵机制实现主从库自动切换。

2.2.2 功能

• 监控不断检查主节点和从节点是否运作正常
• 自动故障转移当主节点不能正常工作时哨兵就开始自动故障转移的操作会将失效的主节点其中一个从节点升级为新的主节点并让其他从节点改为复制新的主节点
• 配置提供者客户端在初始化时通过链接哨兵来获得当前Redis服务主节点的地址
• 通知可以将故障转移的结果发送给客户端

以下几个问题具有连通性、层层递进

2.2.3 哨兵如何监控Redis库

哨兵向主库发送INFO命令来完成监控的。哨兵向主库发送INFO命令主库接收到INFO命令后会给哨兵返回从库列表的连接信息哨兵根据从库列表的链接信息和每个从库进行连接并在这个连接上持续地对从库进行监控。

2.2.4 如何判断主库下线了

• 主观下线 任何一个哨兵都可以监控探测并作出Redis节点下线的判断
• 客观下线 哨兵集群共同决定Redis节点是否下线。 【当某个哨兵判断主库下线后会给其他哨兵发送is-master-down-by-addr命令其他哨兵收到命令后会根据自己和主库的连接情况做出Y赞成或者N反对的响应。如果赞成票数大于等于配置的票数则就可以判定主库客观下线了。】

2.2.5 如何进行哨兵集群的选举

因为故障转移只需要一个哨兵操作即可那么如果主库下线了应该由哨兵集群中的哪个哨兵进行主从切换呢——哨兵集群的选举
通过Raft算法进行选举票数超过一半哨兵数并且大于等于配置的票数就可以成为主哨兵。

2.2.6 如何在从库中选出新主库

首先过滤掉已下线的从库再从中选出复制偏移量最大最完整的从节点。

2.2.7 进行故障转移

选出主哨兵、主哨兵选出可升级为主节点的从节点、其他从节点成为新主节点的从根节点、通知客户端新主节点的地址

2.3 Redis集群

2.3.1 概念

主从复制和哨兵机制保障了高可用就读写分离而言虽然slave节点的扩展提高了读并发的能力但是写能力和存储能力时无法进行扩展的那么对于海量数据必然需要构建master之间的集群同时也必然需要吸收高可用主从复制和哨兵机制的能力即每个master还需要有多个slave节点这就是集群。

3 Redis事务

3.1 概念

Redis’事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。

3.2 相关命令

• MULTI 开启事务
• EXEC 执行事务中所有操作命令
• DISCARD 取消事务
• WATCH 监视一个或多个key如果事务在执行之前监视的key被其他命令修改则事务被中断不会执行事务中的任何命令
• UNWATCH 取消WATCH对所有key的监视

3.3 事务执行的步骤

1. 开启以MULTI命令开启事务
2. 入队将多个命令入队到事务中接到这些命令并不会立即执行而是放到等待执行的事务队列里面
3. 执行有EXEC命令触发事务