Redis① —— Redis基础

1. 什么是Redis

• 内存型数据库，对数据读写都在内存中完成，读写速度快
• 有多种数据类型来支持不同的业务场景
• 执行命令由单线程负责，不存在并发竞争

2. 为什么用Redis作为MySQL的缓存

• 因为redis具备高性能
  • 用户第一次访问mysql中的数据比较慢，因为是从硬盘上读取的，之后将用户访问的数据缓存在redis中，下次一次再访问就可以直接从缓存中获取，速度快
• 因为redis具备高并发
  • 单台设备redis的qps是mysql的10倍，直接访问 Redis 能够承受的请求是远远大于直接访问 MySQL 的

3. Redis数据结构

3.1 String

• value最多容纳数据长度是512M
• String 类型的底层的数据结构实现主要是 int 和 SDS（简单动态字符串）
  • SDS可以保存本文数据和二进制数据
  • 获取字符串长度的时间复杂度是O(1)
  • redis的SDS API是安全的，拼接字符串不会造成缓冲区溢出
• 应用场景：
  • 缓存对象
    • 直接缓存整个对象的 JSON，如：`SET user:1 ‘{“name”:“xiaolin”, “age”:18}’
    • 采用将 key 进行分离为 user:ID:属性，采用 MSET 存储，用 MGET 获取各属性值，如：MSET user:1:name xiaolin user:1:age 18 user:2:name xiaomei user:2:age 20
  • 常规计数
    • 因为redis处理命令是单线程，所以执行命令的过程也是原子的，适合计数场景
  • 分布式锁：
    • 如果 key 不存在，则显示插入成功，可以用来表示加锁成功；
    • 如果 key 存在，则会显示插入失败，可以用来表示加锁失败。
    • 还会对分布式锁加上过期时间，如：SET lock_key unique_value NX PX 10000
  • 共享session信息：
    • 在分布式系统中，借助 Redis 对这些 Session 信息进行统一的存储和管理，这样无论请求发送到那台服务器，服务器都会去同一个 Redis 获取相关的 Session 信息，这样就解决了分布式系统下 Session 存储的问题

3.2 List

• 按照插入顺序排序，可以从头部或尾部向 List 列表添加元素。每个列表支持超过40亿个元素
• List 类型的底层数据结构是由双向链表或压缩列表实现的
  • 如果列表的元素个数小于 512 个，列表每个元素的值都小于 64 字节，使用压缩列表
  • 否则使用双向链表
  • 在redis 3.2后，统一使用 quicklist 实现
• 应用场景：
  • 消息队列
    • 消息队列在存取消息时，必须要满足三个需求，分别是消息保序、处理重复的消息和保证消息可靠性。
    • 消息保序：List 本身就是按先进先出的顺序对数据进行存取的
    • 处理重复消息：
      • 要满足两个要求：一个是每个消息都有一个全局ID，另一个是消费者要记录处理过的ID，当收到一条消息后可以通过对比ID来判断消息是否被处理
      • 我们需要自行为每个消息生成一个全局唯一ID
    • 消息可靠性：出现故障能恢复
      • List 类型提供了 BRPOPLPUSH 命令，作用是让消费者程序从一个 List 中读取消息，同时，Redis 会把这个消息再插入到另一个 List（可以叫作备份 List）留存。
    • 缺点：List 不支持多个消费者消费同一条消息，因为一旦消费者拉取一条消息后，这条消息就从 List 中删除了，无法被其它消费者再次消费。

3.3 Hash

• Hash 特别适合用于存储对象。
• 底层数据结构是由压缩列表或哈希表实现的
  • 如果哈希类型元素个数小于 512 个，所有值小于 64 字节，使用压缩列表
  • 否则使用哈希表
  • redis 7.0中，压缩列表由 listpack 代替
• 应用场景：
  • 缓存对象
    • Hash 类型的 （key，field， value） 的结构与对象的（对象id， 属性， 值）的结构相似
  • 购物车
    • 以用户 id 为 key，商品 id 为 field，商品数量为 value，恰好构成了购物车的3个要素

3.4 Set

• 无序并唯一，它的存储顺序不会按照插入的先后顺序进行存储。
• Set 类型除了支持集合内的增删改查，同时还支持多个集合取交集、并集、差集。
• 底层数据结构是由哈希表或整数集合实现的
  • 如果集合中的元素都是整数且元素个数小于 512，使用整数集合
  • 否则使用哈希表
• 应用场景：
  • 点赞
    • Set 类型可以保证一个用户只能点一个赞，这里举例子一个场景，key 是文章id，value 是用户id
  • 共同关注
    • Set 类型支持交集运算，所以可以用来计算共同关注的好友、公众号等。key 可以是用户id，value 则是已关注的公众号的id。
  • 抽奖活动
    • 存储某活动中中奖的用户名 ，Set 类型因为有去重功能，可以保证同一个用户不会中奖两次。key为抽奖活动名，value为员工名称。

3.5 ZSet

• 每个存储元素相当于有两个值组成的，一个是有序集合的元素值，一个是排序值。
• 集合不能有重复成员，分值可以重复，有序集合中的元素可以排序
• 底层数据结构是由压缩列表或跳表实现的
  • 如果有序集合的元素个数小于 128 个，并且每个元素的值小于 64 字节时，使用压缩列表
  • 否则使用跳表
  • redis 7.0 压缩列表替换为 listpack
• 应用场景：
  • 排行榜
    • 例如学生成绩的排名榜、游戏积分排行榜、视频播放排名、电商系统中商品的销量排名等
  • 电话、姓名排序

3.6 BitMap

• 位图，是一串连续的二进制数组（0和1），可以通过偏移量（offset）定位元素。BitMap通过最小的单位bit来进行0|1的设置，表示某个元素的值或者状态，时间复杂度为O(1)。
• 底层数据结构用string类型来实现
• 应用场景：
  • 签到统计：我们只用记录签到（1）或未签到（0）
  • 判断用户登录状态

3.7 HyperLogLog

• HyperLogLog 提供不精确的去重计数，是基于概率完成的，不是非常准确
• 优点：在输入元素的数量或者体积非常非常大时，计算基数所需的内存空间总是固定的、并且是很小的（非常节省空间）
• 应用场景：
  • 百万级网页UV计数

3.8 GEO

• 主要用于存储地理位置信息，并对存储的信息进行操作
• 直接使用了 Sorted Set 集合类型作为底层数据结构
• 应用场景：
  • 滴滴叫车

3.9 Stream

• 专门为消息队列设计的数据类型，它支持消息的持久化、支持自动生成全局唯一 ID、支持 ack 确认消息的模式、支持消费组模式等，让消息队列更加的稳定和可靠。
• 应用场景：
  • 消息队列