Redis基础概念和数据类型详解_redis的基础和基础数据类型

目录

1.什么是Redis？

2.为什么要使用Redis？

3.Redis为什么这么快？

4.Redis的使用场景有哪些？

5.Redis的基本数据类型

   5.1 5种基础数据类型

     5.1.1 String字符串

     5.1.2 List列表

     5.1.3 Set集合

     5.1.4 Hash散列

     5.1.5 Zset有序集合

   5.2 3种特殊数据类型

   5.3 Stream详解

6.Redis基础常见问题

---

1.什么是Redis？

Redis 是完全开源免费的，遵守BSD协议，是一个高性能的key-value数据库。与传统数据库不同的是 Redis 的数据是存在内存中的（内存数据库），读写速度非常快，被广泛应用于缓存，事件发布或订阅，高速队列等场景。支持网络，提供字符串，哈希，列表，队列，集合结构直接存取，基于内存，可持久化。

Redis 与其他 key - value 缓存产品有以下三个特点：

• Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。
• Redis不仅仅支持简单的key-value类型的数据，同时还提供list（列表），set（集合），zset（有序集合），hash（哈希表）等数据结构的存储。
• Redis支持数据的备份，即master-slave（主从模式）模式的数据备份。

 zset原为sorted set。为了避免sorted set简写sset导致命令冲突，所以改为zset。

Redis 没有外部依赖，Linux 和 OS X 是 Redis 开发和测试最多的两个操作系统，官方推荐生产环境使用 Linux 部署 Redis。

个人学习的话，你可以自己本机安装 Redis 或者通过 Redis 官网提供的 Try Redis（进不去开梯子即可）来实际体验 Redis。

• Redis官网:Redis

2.为什么要使用Redis？

• 读写性能优异
  • Redis能读的速度是110000次/s,写的速度是81000次/s （测试条件见下一节）。
• 数据类型丰富
  • Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。
• 原子性
  • Redis的所有操作都是原子性的，同时Redis还支持对几个操作全并后的原子性执行。
• 丰富的特性
  • Redis支持 publish/subscribe, 通知, key 过期等特性。
• 持久化
  • Redis支持RDB, AOF等持久化方式
• 发布订阅
  • Redis支持发布/订阅模式
• 分布式
  • Redis Cluster

3.Redis为什么这么快？

Redis 内部做了非常多的性能优化，比较重要的有下面 3 点：

1. Redis 基于内存，内存的访问速度是磁盘的上千倍；
2. Redis 基于 Reactor 模式设计开发了一套高效的事件处理模型，主要是单线程事件循环和 IO 多路复用（Redis 线程模式下篇会详细介绍）；
3. Redis 内置了多种优化过后的数据结构实现，性能非常高。

4.Redis的使用场景有哪些？

热点数据的缓存

缓存是Redis最常见的应用场景，之所有这么使用，主要是因为Redis读写性能优异。而且逐渐有取代memcached，成为首选服务端缓存的组件。而且，Redis内部是支持事务的，在使用时候能有效保证数据的一致性。

作为缓存使用时，一般有两种方式保存数据：

• 读取前，先去读Redis，如果没有数据，读取数据库，将数据拉入Redis。
• 插入数据时，同时写入Redis。

方案一：实施起来简单，但是有两个需要注意的地方：

• 避免缓存击穿。（数据库没有就需要命中的数据，导致Redis一直没有数据，而一直命中数据库。）
• 数据的实时性相对会差一点。

方案二：数据实时性强，但是开发时不便于统一处理。

当然，两种方式根据实际情况来适用。如：方案一适用于对于数据实时性要求不是特别高的场景。方案二适用于字典表、数据量不大的数据存储。

限时业务的应用

redis中可以使用expire命令设置一个键的生存时间，到时间后redis会删除它。利用这一特性可以运用在限时的优惠活动信息、手机验证码等业务场景。

计数器相关问题

redis由于incrby命令可以实现原子性的递增，所以可以运用于高并发的秒杀活动、分布式序列号的生成、具体业务还体现在比如限制一个手机号发多少条短信、一个接口一分钟限制多少请求、一个接口一天限制调用多少次等等。

分布式锁

这个主要利用redis的setnx命令进行，setnx："set if not exists"就是如果不存在则成功设置缓存同时返回1，否则返回0 ，这个特性在很多后台中都有所运用，因为我们服务器是集群的，定时任务可能在两台机器上都会运行，所以在定时任务中首先 通过setnx设置一个lock， 如果成功设置则执行，如果没有成功设置，则表明该定时任务已执行。 当然结合具体业务，我们可以给这个lock加一个过期时间，比如说30分钟执行一次的定时任务，那么这个过期时间设置为小于30分钟的一个时间就可以，这个与定时任务的周期以及定时任务执行消耗时间相关。

在分布式锁的场景中，主要用在比如秒杀系统等。

延时操作

比如在订单生产后我们占用了库存，10分钟后去检验用户是否真正购买，如果没有购买将该单据设置无效，同时还原库存。 由于redis自2.8.0之后版本提供Keyspace Notifications功能，允许客户订阅Pub/Sub频道，以便以某种方式接收影响Redis数据集的事件。 所以我们对于上面的需求就可以用以下解决方案，我们在订单生产时，设置一个key，同时设置10分钟后过期， 我们在后台实现一个监听器，监听key的实效，监听到key失效时将后续逻辑加上。

当然我们也可以利用rabbitmq、activemq等消息中间件的延迟队列服务实现该需求。

排行榜相关问题

关系型数据库在排行榜方面查询速度普遍偏慢，所以可以借助redis的SortedSet进行热点数据的排序。

比如点赞排行榜，做一个SortedSet, 然后以用户的openid作为上面的username, 以用户的点赞数作为上面的score, 然后针对每个用户做一个hash, 通过zrangebyscore就可以按照点赞数获取排行榜，然后再根据username获取用户的hash信息，这个当时在实际运用中性能体验也蛮不错的。

点赞，好友等相互关系的存储

Redis 利用集合的一些命令，比如求交集、并集、差集等。

在微博应用中，每个用户关注的人存在一个集合中，就很容易实现求两个人的共同好友功能。

简单队列

由于Redis有list push和list pop这样的命令，所以能够很方便的执行队列操作。

5.Redis的基本数据类型

   5.1 5种基础数据类型

首先对redis来说，所有的key（键）都是字符串。我们在谈基础数据结构时，讨论的是存储值的数据类型，主要包括常见的5种数据类型，分别是：String、List、Set、Zset、Hash。

     5.1.1 String字符串

String是redis中最基本的数据类型，一个key对应一个value。

String类型是二进制安全的，意思是 redis 的 string 可以包含任何数据。如数字，字符串，jpg图片或者序列化的对象。

下图是一个String类型的实例，其中键为hello，值为world

实战场景

• 缓存： 经典使用场景，把常用信息，字符串，图片或者视频等信息放到redis中，redis作为缓存层，mysql做持久化层，降低mysql的读写压力。
• 计数器：用户单位时间的请求数（简单限流可以用到）、页面单位时间的访问数。。
• session：常见方案spring session + redis实现session共享

     5.1.2 List列表

Redis中的List其实就是链表（Redis用双端链表实现List）

使用List结构，我们可以轻松地实现最新消息排队功能（比如新浪微博的TimeLine）。List的另一个应用就是消息队列，可以利用List的 PUSH 操作，将任务存放在List中，然后工作线程再用 POP 操作将任务取出进行执行。

• 实战场景
  • 微博TimeLine: 有人发布微博，用lpush加入时间轴，展示新的列表信息。
  • 消息队列 

     5.1.3 Set集合

Redis 的 Set 是 String 类型的无序集合。集合成员是唯一的，这就意味着集合中不能出现重复的数据。

Redis 中集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。

• 实战场景
  • 标签（tag）,给用户添加标签，或者用户给消息添加标签，这样有同一标签或者类似标签的可以给推荐关注的事或者关注的人。
  • 点赞，或点踩，收藏等，可以放到set中实现
• 

     5.1.4 Hash散列

Redis hash 是一个 string 类型的 field（字段） 和 value（值） 的映射表，hash 特别适合用于存储对象。

• 实战场景
  • 缓存： 能直观，相比string更节省空间，的维护缓存信息，如用户信息，视频信息等。

     5.1.5 Zset有序集合

Redis 有序集合和集合一样也是 string 类型元素的集合,且不允许重复的成员。不同的是每个元素都会关联一个 double 类型的分数。redis 正是通过分数来为集合中的成员进行从小到大的排序。

有序集合的成员是唯一的, 但分数(score)却可以重复。有序集合是通过两种数据结构实现：

1. 压缩列表(ziplist): ziplist是为了提高存储效率而设计的一种特殊编码的双向链表。它可以存储字符串或者整数，存储整数时是采用整数的二进制而不是字符串形式存储。它能在O(1)的时间复杂度下完成list两端的push和pop操作。但是因为每次操作都需要重新分配ziplist的内存，所以实际复杂度和ziplist的内存使用量相关
2. 跳跃表（zSkiplist): 跳跃表的性能可以保证在查找，删除，添加等操作的时候在对数期望时间内完成，这个性能是可以和平衡树来相比较的，而且在实现方面比平衡树要优雅，这是采用跳跃表的主要原因。跳跃表的复杂度是O(log(n))。

• 实战场景
  • 排行榜：有序集合经典使用场景。例如小说视频等网站需要对用户上传的小说视频做排行榜，榜单可以按照用户关注数，更新时间，字数等打分，做排行。

 

   5.2 3种特殊数据类型

     5.2.1 HyperLogLogs（基数统计）

这个结构可以非常省内存的去统计各种计数，比如注册 IP 数、每日访问 IP 数、页面实时UV、在线用户数，共同好友数等。

Redis 提供的 HyperLogLog 占用空间非常非常小，只需要 12k 的空间就能存储接近2^64个不同元素。这是真的厉害，并且，Redis 对 HyperLogLog 的存储结构做了优化，采用两种方式计数：

• 稀疏矩阵：计数较少的时候，占用空间很小。
• 稠密矩阵：计数达到某个阈值的时候，占用 12k 的空间。

Redis 官方文档中有对应的详细说明：

基数计数概率算法为了节省内存并不会直接存储元数据，而是通过一定的概率统计方法预估基数值（集合中包含元素的个数）。因此， HyperLogLog 的计数结果并不是一个精确值，存在一定的误差（标准误差为 0.81% ）。

• 实战场景
  • 数量量巨大（百万、千万级别以上）的计数场景：热门网站每日/每周/每月访问 ip 数统计、热门帖子 uv 统计

     5.2.2 Bitmap （位存储）

Bitmap 即位图数据结构，都是操作二进制位来进行记录，只有0 和 1 两个状态。

• 实战场景
  • 需要保存状态信息（0/1 即可表示）的场景：用户签到情况、活跃用户情况、用户行为统计（比如是否点赞过某个视频）。两个状态的，都可以使用 Bitmaps！

     5.2.3 geospatial (地理位置)

主要用于存储地理位置信息，基于 Sorted Set 实现。通过 GEO 我们可以轻松实现两个位置距离的计算、获取指定位置附近的元素等功能。

• 实战场景
  • 需要管理使用地理空间数据的场景：附近的人。

   5.3 Stream详解

Redis5.0 中还增加了一个数据结构Stream，从字面上看是流类型，但其实从功能上看，应该是Redis对消息队列（MQ，Message Queue）的完善实现。

解释：

1. 消费者组： Consumer Group,即使用 XGROUP CREATE 命令创建的，一个消费者组中可以存在多个消费者，这些消费者之间是竞争关系。
   1. 同一条消息，只能被这个消费者组中的某个消费者获取。
   2. 多个消费者之间是相互独立的，互不干扰。
2. 消费者： Consumer 消费消息。
3. last_delivered_id： 这个id保证了在同一个消费者组中，一个消息只能被一个消费者获取。每当消费者组的某个消费者读取到了这个消息后，这个last_delivered_id的值会往后移动一位，保证消费者不会读取到重复的消息。
4. pending_ids：记录了消费者读取到的消息id列表，但是这些消息可能还没有处理，如果认为某个消息处理，需要调用ack命令。这样就确保了某个消息一定会被执行一次。
5. 消息内容：是一个键值对的格式。
6. Stream 中 消息的 ID： 默认情况下，ID使用 * ，redis可以自动生成一个，格式为 时间戳-序列号，也可以自己指定，一般使用默认生成的即可，且后生成的id号要比之前生成的大。

6.Redis基础常见问题

   6.1 Redis单线程模型，为什么效率这么高呢？

   6.2 Redis的key过期策略

• 被动方式 - 惰性删除
• 主动方式 - 定期删除

为保证 Redis 的高性能，所以不会单独安排一个线程专门去删除。

惰性删除

key过期时不删除，每次获取key时，再去检查是否过期。若过期，则删除，返回nil。

优点

删除操作只发生在取key时，且只删除当前key，所以对CPU时间占用较少。此时删除已非做不可，毕竟若还不删除，就会获取到已过期key。

当查询该key时，Redis再很懒惰地检查是否删除。这和 Spring 的延迟初始化有着异曲同工之妙。

缺点

但这是不够的，因为有过期key，永远不会再访问。若大量key在超出TTL后，很久一段时间内，都没有被获取过，则可能发生内存泄露（无用垃圾占用了大量内存）。

无论如何，这些key都应过期，因此还需要定期 Redis 在具有过期集的key之间随机测试几个key。已过期的所有key将从key空间中删除。

定时删除

在设置key的过期时间的同时，为该key创建一个定时器，让定时器在key的过期时间来临时，对key进行删除。

优点

保证内存被尽快释放。

缺点

若过期key很多，删除这些key会占用很多的CPU时间，在CPU时间紧张的情况下，CPU不能把所有的时间用来做要紧的事儿，还需要去花时间删除这些key

定时器的创建耗时，若为每一个设置过期时间的key创建一个定时器（将会有大量的定时器产生），性能影响严重

定期删除

每隔一段时间执行一次删除过期key操作。

优点

通过限制删除操作的时长和频率，来减少删除操作对CPU时间的占用–处理"定时删除"的缺点

定期删除过期key–处理"惰性删除"的缺点

缺点

在内存友好方面，不如"定时删除"

在CPU时间友好方面，不如"惰性删除"

难点

合理设置删除操作的执行时长（每次删除执行多长时间）和执行频率（每隔多长时间做一次删除）（这个要根据服务器运行情况来定了）

Redis采用的过期策略

惰性删除+定期删除。