redis基本类型及优点特性

最新推荐文章于 2022-05-30 16:59:44 发布

一块巧克力@

最新推荐文章于 2022-05-30 16:59:44 发布

阅读量227

点赞数

分类专栏： Redis 文章标签： Redis

本文链接：https://blog.csdn.net/qq_35491812/article/details/80271555

版权

Redis 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

1.什么是redis?

redis是一个基于内存的高性能key-value数据库

2.redis基本数据类型及应用场景

支持多种数据类型：

string(字符串)

String数据结构是简单的key-value类型，value其实不仅可以是String，也可以是数字。
常规key-value缓存应用；

list(列表)

list就是链表，略有数据结构知识的人都应该能理解其结构。使用Lists结构，我们可以轻松地实现最新消息排行等功能。List的另一个应用就是消息队列，可以利用List的PUSH操作，将任务存在List中，然后工作线程再用POP操作将任务取出进行执行。Redis还提供了操作List中某一段的api，你可以直接查询，删除List中某一段的元素。
Redis的list是每个子元素都是String类型的双向链表，可以通过push和pop操作从列表的头部或者尾部添加或者删除元素，这样List即可以作为栈，也可以作为队列。

消息队列系统
使用list可以构建队列系统，使用sorted set甚至可以构建有优先级的队列系统。
比如：将Redis用作日志收集器
实际上还是一个队列，多个端点将日志信息写入Redis，然后一个worker统一将所有日志写到磁盘。

hash(散列)

Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。
存储部分变更的数据，如用户信息等。

sets (集合)

set就是一个集合，集合的概念就是一堆不重复值的组合。利用Redis提供的set数据结构，可以存储一些集合性的数据。set中的元素是没有顺序的。

sorted set(有序集合)

和set相比，sorted set增加了一个权重参数score，使得集合中的元素能够按score进行有序排列，比如一个存储全班同学成绩的sorted set，其集合value可以是同学的学号，而score就可以是其考试得分，这样在数据插入集合的时候，就已经进行了天然的排序。可以用sorted set来做带权重的队列，比如普通消息的score为1，重要消息的score为2，然后工作线程可以选择按score的倒序来获取工作任务。让重要的任务优先执行。

3.分布式

redis支持主从的模式。

　　原则：

Master会将数据同步到slave，而slave不会将数据同步到master。Slave启动时会连接master来同步数据。

(从机定时通过ping访问主节点，成功则建立权限校验-复制数据，失败则在下个定时周期继续执行.)

典型的读写分离模型。利用master来插入数据，slave提供检索服务。有效减少单个机器的并发访问数量。

　　读写分离模型：

通过增加Slave DB的数量，读的性能可以线性增长，为了避免Master DB的单点故障，集群一般都会采用两台Master DB 做双机热备，所以整个集群的读和写的可用性都非常高。

　　缺陷：

不管是Master还是Slave，每个节点都必须保存完整的数据，如果在数据量很大的情况下，集群的扩展能力是受限于单个节点的存储能力，而且对于Write-intensive类型的应用，读写分离架构并不适合。

为了解决读写分离模型的缺陷，可以将数分片模型应用进来。可以将每个节点看成都是master，然后通过业务实现数据分片。结合两种模型，可以将每个master设计成由一个master和多个slave组成的模型。

4.redis优点

　　a.单线程，利用redis队列技术并将访问变为串行访问，消除了传统数据库串行控制的开销

　　b.redis具有快速和持久化的特征，速度快，因为数据存在内存中。

　　c.分布式读写分离模式

　　d.支持丰富数据类型

　　e.支持事务，操作都是原子性，所谓原子性就是对数据的更改要么全部执行，要不全部不执行。

　　f.可用于缓存，消息，按key设置过期时间，过期后自动删除

缺点：

1 Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。

2 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。

3 Redis的主从复制采用全量复制，复制过程中主机会fork出一个子进程对内存做一份快照，并将子进程的内存快照保存为文件发送给从机，这一过程需要确保主机有足够多的空余内存。若快照文件较大，对集群的服务能力会产生较大的影响，而且复制过程是在从机新加入集群或者从机和主机网络断开重连时都会进行，也就是网络波动都会造成主机和从机间的一次全量的数据复制，这对实际的系统运营造成了不小的麻烦。

4 Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。

5.回收策略

　　从最近最少使用的数据淘汰，挑选将要过期的数据淘汰。

　　volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰

　　volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰

　　volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰

　　allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰

　　allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰

　　no-enviction（驱逐）：禁止驱逐数据

6.redis和memcache相比，有哪些优势？

　　a.memcache所有的值均是简单的字符串，redis支持更为丰富的数据类型

　　b.redis速度比memcached快很多

　　c.redis支持持久化

7.redis与memcache区别

　　a.存储方式 memcache存在内存中，redis存在硬盘中，保证数据持久化

　　b.数据类型 memcache对数据类型支持相对简单，redis有复杂的数据类型

　　c.使用底层模型不同:底层实现方式以及客户端之间通信的应用协议不一样

　　d.redis最大可以达到1G而memcache只有1MB

8.redis 持久化

redis提供了不同级别的持久化方式，一种是RDB，一种AOF。可以同时开启两种持久化方式, 在这种情况下, 当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.

　　RDB：在指定的时间间隔能对数据进行快照存储(隔一段时间,把内存里的数据转存在硬盘里的文件)

　　优点：

RDB是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份,比如您可以在每个小时报保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题您也可以根据需求恢复到不同版本的数据集.
RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心或者亚马逊的S3（可能加密），非常适用于灾难恢复.
RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能.
与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些.

　　缺点：

如果您希望在redis意外停止工作（例如电源中断）的情况下丢失的数据最少的话，那么RDB不适合您.虽然您可以配置不同的save时间点(例如每隔5分钟并且对数据集有100个写的操作),是Redis要完整的保存整个数据集是一个比较繁重的工作,您通常会每隔5分钟或者更久做一次完整的保存,万一在Redis意外宕机,您可能会丢失几分钟的数据.
RDB 需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒,AOF也需要fork,但是您可以调节重写日志文件的频率来提高数据集的耐久度.

　　AOF：每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大.

　　优点：

使用AOF 会让您的Redis更加耐久: 您可以使用不同的fsync策略：无fsync,每秒fsync,每次写的时候fsync.使用默认的每秒fsync策略,Redis的性能依然很好(fsync是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障，您最多丢失1秒的数据.
AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令,您也也可使用redis-check-aof工具修复这些问题.
Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写：重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
AOF 文件有序地保存了对数据库执行的所有写入操作，这些写入操作以 Redis 协议的格式保存，因此 AOF 文件的内容非常容易被人读懂，对文件进行分析（parse）也很轻松。导出（export） AOF 文件也非常简单：举个例子，如果您不小心执行了 FLUSHALL 命令，但只要 AOF 文件未被重写，那么只要停止服务器，移除 AOF 文件末尾的 FLUSHALL 命令，并重启 Redis ，就可以将数据集恢复到 FLUSHALL 执行之前的状态。

　　缺点：

对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。在一般情况下，每秒 fsync 的性能依然非常高，而关闭 fsync 可以让 AOF 的速度和 RDB 一样快，即使在高负荷之下也是如此。不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。