Redis 面试问题

    nosql 缓存 reids 0  评论

problem

什么事redis

Redis(Remote Dictionary Server) 是一个使用 C 语言编写的，开源的（BSD许可）高性能非关系型（NoSQL）的键值对数据库。

Redis 可以存储键和五种不同类型的值之间的映射。键的类型只能为字符串，值支持五种数据类型：字符串、列表、集合、散列表、有序集合。

与传统数据库不同的是 Redis 的数据是存在内存中的，所以读写速度非常快，因此 redis 被广泛应用于缓存方向，每秒可以处理超过 10万次读写操作，是已知性能最快的Key-Value DB。另外，Redis 也经常用来做分布式锁。除此之外，Redis 支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案。

Redis有哪些优缺点

  • 优点

    • 读写性能优异， Redis能读的速度是110000次/s，写的速度是81000次/s。
    • 支持数据持久化，支持AOF和RDB两种持久化方式。
    • 支持事务，Redis的所有操作都是原子性的，同时Redis还支持对几个操作合并后的原子性执行。
    • 数据结构丰富，除了支持string类型的value外还支持hash、set、zset、list等数据结构。
    • 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离。

  • 缺点

    • 数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。
    • Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。
    • 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。
    • Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。

Redis为什么这么快

  1. 完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，类似于 HashMap，HashMap 的优势就是查找和操作的时间复杂度都是O(1)；
  2. 数据结构简单，对数据操作也简单，Redis 中的数据结构是专门进行设计的；
  3. 采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；
  4. 使用多路 I/O 复用模型，非阻塞 IO；
  5. 使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis 直接自己构建了 VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求；

数据类型

  • String的实际应用场景比较广泛的有：

    • 缓存功能：String字符串是最常用的数据类型，不仅仅是Redis，各个语言都是最基本类型，因此，利用Redis作为缓存，配合其它数据库作为存储层，利用Redis支持高并发的特点，可以大大加快系统的读写速度、以及降低后端数据库的压力。
    • 计数器：许多系统都会使用Redis作为系统的实时计数器，可以快速实现计数和查询的功能。而且最终的数据结果可以按照特定的时间落地到数据库或者其它存储介质当中进行永久保存。
    • 共享用户Session：用户重新刷新一次界面，可能需要访问一下数据进行重新登录，或者访问页面缓存Cookie，但是可以利用Redis将用户的Session集中管理，在这种模式只需要保证Redis的高可用，每次用户Session的更新和获取都可以快速完成。大大提高效率。

  • Hash：

    这个是类似 Map 的一种结构，这个一般就是可以将结构化的数据，比如一个对象（前提是这个对象没嵌套其他的对象）给缓存在 Redis 里，然后每次读写缓存的时候，可以就操作 Hash 里的某个字段。但是这个的场景其实还是多少单一了一些，因为现在很多对象都是比较复杂的，比如你的商品对象可能里面就包含了很多属性，其中也有对象。一般key为ID或者唯一标示，value对应的就是详情了。如商品详情，个人信息详情，新闻详情等。

  • List：

    List 是有序列表，这个还是可以玩儿出很多花样的。

    • 比如可以通过 List 存储一些列表型的数据结构，类似粉丝列表、文章的评论列表之类的东西。
    • 比如可以通过 lrange 命令，读取某个闭区间内的元素，可以基于 List 实现分页查询，这个是很棒的一个功能，基于 Redis 实现简单的高性能分页，可以做类似微博那种下拉不断分页的东西，性能高，就一页一页走。
    • 比如可以搞个简单的消息队列，从 List 头怼进去，从 List 屁股那里弄出来。
    • 消息队列：Redis的链表结构，可以轻松实现阻塞队列，可以使用左进右出的命令组成来完成队列的设计。比如：数据的生产者可以通过Lpush命令从左边插入数据，多个数据消费者，可以使用BRpop命令阻塞的“抢”列表尾部的数据。 文章列表或者数据分页展示的应用。比如，我们常用的博客网站的文章列表，当用户量越来越多时，而且每一个用户都有自己的文章列表，而且当文章多时，都需要分页展示，这时可以考虑使用Redis的列表，列表不但有序同时还支持按照范围内获取元素，可以完美解决分页查询功能。大大提高查询效率。

  • Set

    是无序集合，会自动去重的那种。 直接基于 Set 将系统里需要去重的数据扔进去，自动就给去重了，如果你需要对一些数据进行快速的全局去重，你当然也可以基于 JVM 内存里的 HashSet 进行去重，但是如果你的某个系统部署在多台机器上呢？得基于Redis进行全局的 Set 去重。 可以基于 Set 玩儿交集、并集、差集的操作，比如交集吧，我们可以把两个人的好友列表整一个交集，看看俩人的共同好友是谁？

  • Sorted Set：

    Sorted set 是排序的 Set，去重但可以排序，写进去的时候给一个分数，自动根据分数排序。有序集合的使用场景与集合类似，但是set集合不是自动有序的，而Sorted set可以利用分数进行成员间的排序，而且是插入时就排序好。所以当你需要一个有序且不重复的集合列表时，就可以选择Sorted set数据结构作为选择方案。排行榜：有序集合经典使用场景。例如视频网站需要对用户上传的视频做排行榜，榜单维护可能是多方面：按照时间、按照播放量、按照获得的赞数等。用Sorted Sets来做带权重的队列，比如普通消息的score为1，重要消息的score为2，然后工作线程可以选择按score的倒序来获取工作任务。让重要的任务优先执行。微博热搜榜，就是有个后面的热度值，前面就是名称

高级用法：

  • Bitmap : 位图是支持按 bit 位来存储信息，可以用来实现 布隆过滤器（BloomFilter）；
  • HyperLogLog: 供不精确的去重计数功能，比较适合用来做大规模数据的去重统计，例如统计 UV；
  • Geospatial:可以用来保存地理位置，并作位置距离计算或者根据半径计算位置等。有没有想过用Redis来实现附近的人？或者计算最优地图路径？
  • pub/sub：功能是订阅发布功能，可以用作简单的消息队列。
  • Pipeline：可以批量执行一组指令，一次性返回全部结果，可以减少频繁的请求应答。
  • Lua：Redis 支持提交 Lua 脚本来执行一系列的功能。

使用场景

  • 热点数据缓存，需要考虑 缓存三大问题 缓存雪崩，缓存击穿， 缓存穿透
  • 轻量级消息队列， 基于list的，实现生产者者写入，消费者读出处理
  • 异步队列，基于消息队列类似的原理
  • 分布式锁，基于setnx 命令实现分布式锁，但是考虑到集群情况，需要设计更优的方案，详见
  • 布隆过滤器，如果系统即将会有大量的新用户涌入时，布隆过滤器就会非常有价值，可以显著降低缓存的穿透率，降低数据库的压力, 这个新用户的涌入不一定是业务系统的大规模铺开，也可能是因为来自外部的缓存穿透攻击
  • 位图

持久化

  • 什么是Redis持久化？

    持久化就是把内存的数据写到磁盘中去，防止服务宕机了内存数据丢失。

  • Redis 的持久化机制是什么？各自的优缺点？

    Redis 提供两种持久化机制 RDB（默认） 和 AOF 机制:

  • RDB：是Redis DataBase缩写快照

    RDB是Redis默认的持久化方式。按照一定的时间将内存的数据以快照的形式保存到硬盘中，对应产生的数据文件为dump.rdb。通过配置文件中的save参数来定义快照的周期。

    • 优点:
      1. 只有一个文件 dump.rdb，方便持久化。
      2. 容灾性好，一个文件可以保存到安全的磁盘。
      3. 性能最大化，fork 子进程来完成写操作，让主进程继续处理命令，所以是 IO 最大化。使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 redis 的高性能
      4. 相对于数据集大时，比 AOF 的启动效率更高。
    • 缺点：
      1. 数据安全性低。RDB 是间隔一段时间进行持久化，如果持久化之间 redis 发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候

  • AOF: (Append-only file)持久化方式

    是指所有的命令行记录以 redis 命令请 求协议的格式完全持久化存, 则是将Redis执行的每次写命令记录到单独的日志文件中，当重启Redis会重新将持久化的日志中文件恢复数据。当两种方式同时开启时，数据恢复Redis会优先选择AOF恢复。

    • 优点:
      1. 数据安全，aof 持久化可以配置 appendfsync 属性，有 always，每进行一次 命令操作就记录到 aof 文件中一次。
      2. 通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-check-aof 工具解决数据一致性问题。
      3. AOF 机制的 rewrite 模式。AOF 文件没被 rewrite 之前（文件过大时会对命令 进行合并重写），可以删除其中的某些命令（比如误操作的 flushall）)
    • 缺点:
      1. AOF 文件比 RDB 文件大，且恢复速度慢。
      2. 数据集大的时候，比 rdb 启动效率低。

  • RDB & AOF

    1. AOF文件比RDB更新频率高，优先使用AOF还原数据。
    2. AOF比RDB更安全也更大
    3. RDB性能比AOF好
    4. 如果两个都配了优先加载AOF

  • 如何选择合适的持久化方式

    • 一般来说， 如果想达到足以媲美PostgreSQL的数据安全性，你应该同时使用两种持久化功能。在这种情况下，当 Redis 重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
    • 如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失，那么你可以只使用RDB持久化。
    • 有很多用户都只使用AOF持久化，但并不推荐这种方式，因为定时生成RDB快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比AOF恢复的速度要快，除此之外，使用RDB还可以避免AOF程序的bug。
    • 如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式。

  • Redis持久化数据和缓存怎么做扩容？

    • 如果Redis被当做缓存使用，使用一致性哈希实现动态扩容缩容。
    • 如果Redis被当做一个持久化存储使用，必须使用固定的keys-to-nodes映射关系，节点的数量一旦确定不能变化。否则的话(即Redis节点需要动态变化的情况），必须使用可以在运行时进行数据再平衡的一套系统，而当前只有Redis集群可以做到这样。)

skybosi上海混的

skybosi is learing fly in the sky!!!