redis基础及常见模型简介

肆弋

于 2022-08-25 12:52:35 发布

阅读量727

点赞数 1

文章标签： redis 哈希算法数据库

本文链接：https://blog.csdn.net/mqb195128/article/details/126521935

版权

1、redis 常见的数据结构

常见的 5 种：

String ：字符串，最基础的数据类型。

List ：列表。

Hash ：哈希对象。

Set ：集合。

Sorted Set ：有序集合， Set 的基础上加了个分值。

2、redis 持久化你们怎么做的？

redis 持久化主要有两种 ROD 和 AOF ，当先现在还有混合的，从 reids4.0 后引入的

RDB 实现原理：

RDB 类似于快照，在某个时间点，将 Redis 在内存中的数据库状态（数据库的键值对等信息）保存到磁盘里面。RDB 持久化功能生成的 RDB 文件是经过压缩的二进制文件。

RDB 的优点：

RDB 文件是经过压缩的，占用空间很小，它保存了某个时间点的数据集，很适合做备份。比如你可以在24 小时内，每个小时备份一次 RDB 文件，并且每个月的每一天备份一个 RDB 文件。

RDB 非常适合用来做灾备恢复，可以加密后传送到数据中心

RDB 可以最大化 redis 的性能

从恢复速度来看， RDB 明显要比 AOF 要快

但是 RDB 也有一定的缺点：

RDB 在服务器故障的时候，容易造成数据损失。我们通常设置每 5 分钟保存一次快照，这样数据丢

失也只有 5 分钟的数据。 RDB保存时使用 fork 子进程数据的持久化，如果数据量大的话，会非常耗时，造成 redis 停止处理服务N 毫秒。

AOF ：

保存 Redis 服务器所执行的所有写操作命令来记录数据库状态，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF默认是关闭的，可以通过 appendonley yes 开启 AOF 持久化功能的实现可以分为三个步骤：命令追加、文件写入、文件同步。

AOF 的优点：

1 ） AOF 比 RDB 可靠。你可以设置不同的 fsync 策略： no 、 everysec 和 always 。默认是 everysec ，在这种配置下，redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据。

2 ） AOF 文件是一个纯追加的日志文件。即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机等等），我们也可以使用 redis-check-aof 工具也可以轻易地修复这种问题。

3 ）当 AOF 文件太大时， Redis 会自动在后台进行重写：重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。整个重写是绝对安全，因为重写是在一个新的文件上进行，同时 Redis 会继续往旧的文件追加数据。当新文件重写完毕，Redis 会把新旧文件进行切换，然后开始把数据写到新文件上。

4 ） AOF 文件有序地保存了对数据库执行的所有写入操作以 Redis 协议的格式保存，因此 AOF 文件的内容非常容易被人读懂，对文件进行分析（parse ）也很轻松。如果你不小心执行了 FLUSHALL 命令把所有数据刷掉了，但只要 AOF 文件没有被重写，那么只要停止服务器，移除 AOF 文件末尾的 FLUSHALL 命令，并重启 Redis ，就可以将数据集恢复到 FLUSHALL 执行之前的状态。

AOF 缺点：

1 ）对于相同的数据集， AOF 的文件一般会比 RDB 大

2 ） AOF 所使用的 fsync 策略，备份速度也会比 RDB 曼

如何使用：

如果想尽量保证数据安全性，你应该同时使用 RDB 和 AOF 持久化功能，同时可以开启混合持久化。

如果你的数据是可以丢失的，则可以关闭持久化功能，在这种情况下， Redis 的性能是最高的。

3、redis主从复制实现的原理

Redis 虽然读取写入的速度都特别快，但是也会产生读压力特别大的情况，为分担读压力， Redis 支持主从复制，Redis 的主从结构可以采用一主多从或者级联结构， Redis 主从复制可以根据是否是全量分为全量同步和增量同步

4、redis 哨兵模式原理

哨兵是特殊的 redis 服务，不提供读写服务，主要用来监控 redis 实例节点。哨兵架构下 client 端第一次从哨兵找出redis 的主节点，后续就直接访问 redis 的主节点，不会每次都通过 sentinel 代理访问 redis 的主节点，当redis 的主节点发生变化，哨兵会第一时间感知到，并且哨兵会早主从模式的从节点中重新选出来一个新的master ，并且将新的 master 信息通知给 client 端。

这里面 redis 的 client 端一般都实现了订阅功能，订阅 sentinel 发布的节点变动消息。 Redis 服务是通过配置文件启动的，比如上面的从节点设置了只读模式，它被选举成了master 之后就是可读写的了，感觉很奇怪，后来看了下重新选举之后的各redis 服务的配置文件，发现文件里面的内容会被哨兵修改。要想真的高可用，我们的哨兵也要集群模式。

5、memcache和redis的区别

1 、 Redis 和 Memcache 都是将数据存放在内存中，都是内存数据库。不过 memcache 还可用于缓存其他东西，例如图片、视频等等。

2 、 Redis 不仅仅支持简单的 k/v 类型的数据，同时还提供 list ， set ， hash 等数据结构的存储。

3 、虚拟内存 –Redis 当物理内存用完时，可以将一些很久没用到的 value 交换到磁盘

4 、过期策略 –memcache 在 set 时就指定，例如 set key1 0 0 8, 即永不过期。 Redis 可以通过例如 expire 设定，例如expire name 10

5 、分布式 – 设定 memcache 集群，利用 magent 做一主多从 ;redis 可以做一主多从。都可以一主一从

6 、存储数据安全 –memcache 挂掉后，数据没了； redis 可以定期保存到磁盘（持久化）

7 、灾难恢复 –memcache 挂掉后，数据不可恢复 ; redis 数据丢失后可以通过 aof 恢复

8 、 Redis 支持数据的备份，即 master-slave 模式的数据备份。

redis和memecache的不同在于[2]：

1 、存储方式：

memecache 把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小

redis 有部份存在硬盘上，这样能保证数据的持久性，支持数据的持久化（笔者注：有快照和 AOF 日志两种持久化方式，在实际应用的时候，要特别注意配置文件快照参数，要不就很有可能服务器频繁满载做 dump）。

2 、数据支持类型：

redis 在数据支持上要比 memecache 多的多。

3 、使用底层模型不同：

新版本的 redis 直接自己构建了 VM 机制，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。

4 、运行环境不同：

redis 目前官方只支持 LINUX 上去行，从而省去了对于其它系统的支持，这样的话可以更好的把精力用于本系统环境上的优化，虽然后来微软有一个小组为其写了补丁。但是没有放到主干上

个人总结一下，有持久化需求或者对数据结构和处理有高级要求的应用，选择 redis ，其他简单的

key/value 存储，选择 memcache 。

6、redis 有哪些架构模式？

存在问题：内容容量有限，处理能力有限，无法高可用

Redis 的复制（ replication ）功能允许用户根据一个 Redis 服务器来创建任意多个该服务器的复制品，其中被复制的服务器为主服务器（master ），而通过复制创建出来的服务器复制品则为从服务器（slave ）。只要主从服务器之间的网络连接正常，主从服务器两者会具有相同的数据，主服务器就会一直将发生在自己身上的数据更新同步给从服务器，从而一直保证主从服务器的数据相同。

特点：

1 、 master/slave 角色

2 、 master/slave 数据相同

3 、降低 master 读压力在转交从库

问题：

无法保证高可用

没有解决 master 写的压力