Redis

介绍

Redis：
	全称Remote Dictionary Server（远程字典服务）
	是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API
Redis的数据是存在内存中。它的读写速度非常快，因此redis被广泛应用于缓存
Redis也经常用来做分布式锁
Redis支持事务、持久化、LUA 脚本、LRU 驱动事件、多种集群方案

数据结构

redis存储的是(key,value)格式数据，其中Key都是字符串，value有5种基本数据类型

• String（字符串）
• List（列表）
• Set（集合）
• SortedSet（有序集合）
• Hash（哈希）
• Bitmap

持久化

• RDB：

  • 把内存数据以快照的形式保存到磁盘上，默认的持久化方式
  • 在指定的时间间隔内，执行指定次数的写操作，将内存中的数据集快照写入磁盘中
  • 优点：适合大规模的数据恢复场景，如备份，全量复制
  • 缺点：没办法做到实时持久化/秒级持久化、新老版本存在格式兼容问题

• AOF：

  • 采用日志的形式来记录每个写操作，追加到文件中，重启时再重新执行AOF文件中的命令来恢复数据
  • 优点：数据的一致性和完整性更高
  • 缺点：记录的内容越多，文件越大，数据恢复变慢

Redis为什么这么快

1. 基于内存存储实现
2. 高效的数据结构
3. 合理的数据编码
4. 合理的线程模型
5. 虚拟内存机制

过期策略

Redis中同时使用惰性过期和定期过期两种过期策略

• 定时过期

  • 每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即对key进行清除

  • 优点：可以立即清除过期的数据，对内存很友好

  • 缺点：会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量

• 惰性过期

  • 只有当访问一个key时，才会判断该key是否已过期，过期则清除

  • 优点：可以最大化地节省CPU资源

  • 缺点：对内存非常不友好，极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存

• 定期过期

  • 每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key

  • 优点：可以在不同情况下使得CPU和内存资源达到最优的平衡效果

  • 缺点：可能会有很多已经过期的key没被删除

应用场景

• 缓存
• 排行榜
• 计数器应用
• 共享Session
• 分布式锁
• 社交网络
• 消息队列
• 位操作

缓存

缓存穿透

查询一个一定不存在的数据
由于缓存不命中时需要从数据库查询，查不到数据则不写入缓存，导致这个不存在的数据每次请求都要到数据库去查询

• 产生：

  • 业务不合理的设计：查询某个不存在的id
  • 业务/运维/开发失误的操作：如缓存和数据库的数据都被误删除了
  • 黑客非法请求攻击：如黑客故意捏造大量非法请求

• 避免：

  • 使用布隆过滤器快速判断数据是否存在
  • 如果查询数据库为空，给缓存设置空或者默认值
  • 在API入口，对参数进行校验，过滤非法值

缓存雪崩

缓存中数据大批量到过期时间
查询数据量巨大，请求都直接访问数据库，引起数据库压力过大甚至down机

• 原因：大量数据同时过期
• 避免：均匀设置过期时间

缓存击穿

热点key在某个时间点过期的时候，恰好这个时间点对这个Key有大量的并发请求过来，从而大量的请求打到db

• 原因：热点key过期时，对这个Key有大量的并发请求
• 避免：
  • “永不过期”：快要过期时，异步线程去更新和设置过期时间

内存满

• 原因：

  • 数据量过大

  • 键过期机制不合理

  • 内存碎片

  • 内存泄漏

  • 大量短期数据存储

• 解决方案：

  • 增加内存

  • 设置过期时间

  • 使用LRU算法

  • 持久化数据

  • 分片数据

  • 优化数据结构

实现Redis高可用

主从模式

主从模式：Redis部署多台机器，主节点:负责读写操作，从节点:只负责读操作

从节点的数据来自主节点，实现原理就是主从复制机制

主从复制包括全量复制，增量复制两种

• 主从复制：
  1. 一般当slave第一次启动连接master，或者认为是第一次连接，就采用全量复制
  2. slave与master全量同步之后，master上的数据，如果再次发生更新，就会触发增量复制
• 缺点：
  • 一旦主节点由于故障不能提供服务，需要人工将从节点晋升为主节点
  • 同时还要通知应用方更新主节点地址

哨兵模式

Redis从2.8开始正式提供了Redis Sentinel（哨兵）架构来解决主节点故障问题。

由一个或多个Sentinel实例组成的Sentinel系统，它可以监视所有的Redis主节点和从节点

• 作用：
  1. 发送命令，等待Redis服务器（包括主服务器和从服务器）返回监控其运行状态
  2. 哨兵监测到主节点宕机，会自动将从节点切换成主节点，然后通过发布订阅模式通知其他的从节点，修改配置文件，让它们切换主机
  3. 哨兵之间还会相互监控，从而达到高可用
• 缺点：
  • 每个节点存储的数据是一样的，浪费内存，并且不好在线扩容

集群模式

Redis3.0加入的，实现了Redis的分布式存储

对数据进行分片（每台Redis节点上存储不同的内容），来解决在线扩容的问题
并且也提供复制和故障转移功能

• 通信：
  • Redis Cluster集群通过Gossip协议进行通信
  • 常用的Gossip消息分为4种，分别是：ping、pong、meet、fail
• 分布式算法：Hash Slot插槽算法
• 复制：引入了主从复制，一个主节点对应一个或者多个从节点
• 故障转移：
  • 通过ping/pong消息，实现故障发现
  • 对故障节点采用主观下线和客观下线
• 故障恢复：
  • 故障发现后，如果下线节点的是主节点，则需要在它的从节点中选一个替换它，以保证集群的高可用
  • 资格检查：检查从节点是否具备替换故障主节点的条件。
  • 准备选举时间：资格检查通过后，更新触发故障选举时间。
  • 发起选举：到了故障选举时间，进行选举。
  • 选举投票：只有持有槽的主节点才有票，从节点收集到足够的选票（大于一半），触发替换主节点操作

Redis问题