Redis学习总结

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u012904764/article/details/79963493

Redis

1.redis的特点

Redis由意大利开发的一款内存高速缓存数据库。Redis全称为:Remote Dictionary Server(远程数据服务),C语言编写,典型的NoSQL数据库服务器,Redis是一个key-value存储系统,支持丰富的数据类型,如:string、list、set、zset(sorted set)、hash。
本质是key-value类型的内存数据库,很像memcached,整个数据库都加载在内存中进行操作。定期通过异步把数据flush到硬盘上进保存,因为是纯内存操作,Redis的性能非常好,每秒可以处理超过10万次读写操作。

Redis优点:
- 性能极高(支持超过100k+每秒的读写频率)
- 支持保存多种数据结构 Strings, Lists, Hashes, Sets 及 Ordered Sets(最大魅力)
- 支持的value大,单个value的最大限制是1GB,
- 原子性 (Redis 的所有操作都是原子性【要么完整的被执行,要么完全不执行,这种特性就叫原子性】的)
- 还可以对存入的key-value**设置expire(失效)时间**,
- 丰富的特性 – Redis 还支持 publish/subscribe, 通知, key 过期等等特性


Redis缺点:
- 数据库容量受到物理内存限制,不能作为海量数据的高性能读写,因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。
- 如果进行完整重同步,有雨需要生成rdb文件,并进行传输,会占用主机的CPU,炳辉消耗现网的带宽
- 修改配置文件,进行重启,会将硬盘中的数据加载进内存,时间比较久。在这个过程中,redis不能提供服务。


2.为什么redis需要把所有数据放到内存中?

Redis具有快速和数据持久化的特征。如果不将数据放在内存中,磁盘I/O速度 会严重影响redis的性能。如果设置了最大使用的内存,则数据已有记录数达到内存限值后不能继续插入新值。


3.Redis常见性能问题?

  1. Master写内存快照,save命令调度rdbSave函数,会阻塞主线程的工作,当快照比较大时对性能影响是非常大的,会间歇性暂停服务,所以Master最好不要写内存快照。
  2. Master AOF持久化,如果不重写AOF文件,这个持久化方式对性能的影响是最小的,但是AOF文件会不断增大,AOF文件过大会影响Master重启的恢复速度。Master最好不要做任何持久化工作,包括内存快照和AOF日志文件,特别是不要启用内存快照做持久化;如果数据比较关键,某个Slave开启AOF备份数据,策略为每秒同步一次。
  3. Master调用BGREWRITEAOF重写AOF文件,AOF在重写的时候会占大量的CPU和内存资源,导致load过高,出现短暂服务暂停现象。
  4. Redis主从复制的性能问题,为了主从复制的速度和连接的稳定性,Slave和Master最好在同一个局域网内。

4.Redis最适合的场景有哪些?

  1. 会话缓存(Session Cache)
  2. 全页缓存(FPC)
  3. 队列
  4. 排行榜/计数器
  5. 发布/订阅

5.Memcache与Redis的区别?

  1. 存储方式不同,Memcache是把数据全部存在内存中,数据不能超过内存的大小,断电后数据会挂掉。而Redis有部分存在硬盘上,这样能保证数据的持久性。
  2. 数据支持的类型不同,memcache对数据类型支持非常简单,Redis支持复杂的数据类型。
  3. 使用底层模型不同,它们之间底层实现方式以及与客户端之间通信的应用协议不一样。Redis直接自己构建了VM机制,因为一般的系统调用系统函数的话,会浪费一定的时间去移动和请求。、
  4. 支持的value大小不一样,redis最大可以达到1GB,而Memcache只有1MB。

6.Redis有哪几种数据结构?

  • String——字符串(支持设置过期时间
  • Hash——字典 (hash是一个string类型的field和value的映射表。添加和删除操作都是O(1)(平均)的复杂度。hash类型特别适合用于存储对象。Hash里的key不支持过期时间,适合长期保存
  • List——列表
  • Set——集合
  • Sorted Set——有序集合 (和 Sets 相比,Sorted Sets 是将 Set 中的元素增加了一个权重参数 score,使得集合中的元素能够按 score 进
    行有序排列)

7.Redis的持久化

RDB持久化:该机制可以在指定的时间间隔内生成数据集的时间点快照(point-in-time snapshot)
AOF持久化:疾苦服务器执行的所有写操作命令,并在服务器启动时,通过重新执行这些命令来还原数据集。AOF文件中的命令全部以Redis协议的格式来保存,新命令会被追加到文件的末尾。Redis还可以在后台对AOF文件进行重写,使得AOF文件的体积不会超出保存数据集状态所需的实际大小。
无持久化:让数据只在服务器运行时存在
同时应用AOF和RDB:当Redis重启时,它会优先使用AOF文件来还原数据集,因为AOF文件保存的数据集通常比RDB文件保存的数据集更完整。
RDB的优缺点:
优点:*RDB是一个非常紧凑(compact)的文件,它保存了Redis在某个时间点上的数据集。这种文件非常适用于进行备份。定时备份一个RDB文件,即使出问题,也可以随时将数据集还原到不同的版本,RDB非常适用于灾难恢复(disaster recovery)*:它只有一个文件,并且内容都非常紧凑,可以(在加密后)将它传送到别的数据中心,RDB 可以最大化 Redis 的性能:父进程在保存 RDB 文件时唯一要做的就是 fork出一个子进程,然后这个子进程就会处理接下来的所有保存工作,父进程无须执行任何磁盘 I/O 操作。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
缺点:如果你需要尽量避免在服务器故障时丢失数据,那么RDB不适合适用。虽然Redis允许你设置不同的保存点(save point)来控制保存RDB文件的频率,但是,因为RDB文件需要保存整个数据集的状态,所以并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下, 一旦发生故障停机, 你就可能会丢失好几分钟的数据。每次保存 RDB 的时候,Redis 都要 fork() 出一个子进程,并由子进程来进行实际的持久化工作。 在数据集比较庞大时, fork() 可能会非常耗时,造成服务器在某某毫秒内停止处理客户端; 如果数据集非常巨大,并且 CPU 时间非常紧张的话,那么这种停止时间甚至可能会长达整整一秒。
AOF 的优缺点:
优点:
- 使用 AOF 持久化会让 Redis 变得非常耐久(much more durable):你可以设置不同的 fsync 策略,比如无 fsync ,每秒钟一次 fsync ,或者每次执行写入命令时 fsync 。 AOF 的默认策略为每秒钟 fsync 一次,在这种配置下,Redis 仍然可以保持良好的性能,并且就算发生故障停机,也最多只会丢失一秒钟的数据( fsync 会在后台线程执行,所以主线程可以继续努力地处理命令请求)。AOF 文件是一个只进行追加操作的日志文件(append only log), 因此对 AOF 文件的写入不需要进行 seek , 即使日志因为某些原因而包含了未写入完整的命令(比如写入时磁盘已满,写入中途停机,等等), redis-check-aof 工具也可以轻易地修复这种问题。
- Redis 可以在 AOF 文件体积变得过大时,自动地在后台对 AOF 进行重写: 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的,因为 Redis 在创建新 AOF 文件的过程中,会继续将命令追加到现有的 AOF 文件里面,即使重写过程中发生停机,现有AOF 文件也不会丢失。 而一旦新 AOF文件创建完毕,Redis 就会从旧AOF 文件切换到新 AOF 文件,并开始对新 AOF 文件进行追加操作。
缺点:
- 对于相同的数据集来说,AOF 文件的体积通常要大于 RDB 文件的体积。根据所使用的 fsync 策略,AOF 的速度可能会慢于 RDB 。 在一般情况下, 每秒 fsync 的性能依然非常高, 而关闭 fsync 可以让 AOF 的速度和 RDB一样快, 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时,RDB 可以提供更有保证的最大延迟时间(latency)

阅读更多
想对作者说点什么?

博主推荐

换一批

没有更多推荐了,返回首页