redis原理（redis原理面试题）

本篇文章给大家谈谈redis原理，以及redis原理面试题对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、Redis持久化的方式选择与原理
• 2、Redis的五种数据结构及其底层实现原理
• 3、redis缓存原理
• 4、redis是怎么实现的

Redis持久化的方式选择与原理

通常Redis将数据存储在内存中或虚拟内存中，但它提供了数据持久化功能可以把内存中的数据持久化到磁盘。持久化有什么好处呢？比如可以保证断电后数据不会丢失，升级服务器也会变得更加方便。

1.RDB 持久化机制 ：是对 redis 数据执行周期性的持久化。

这种方式就是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为 dump.rdb。客户端也可以使用save或者bgsave命令通知redis做一次快照持久化。save操作是在主线程中保存快照的，由于redis是用一个主线程来处理所有客户端的请求，这种方式会阻塞所有客户端请求。所以不推荐使用。另一点需要注意的是，每次快照持久化都是将内存数据完整写入到磁盘一次，并不是增量的只同步增量数据。如果数据量大的话，写操作会比较多，必然会引起大量的磁盘IO操作，可能会严重影响性能。

2.AOF持久化机制 ：AOF 机制对每条写入命令作为日志，以 append-only 的模式写入一个日志文件中，在 redis 重启的时候，可以通过回放 AOF 日志中的写入指令来重新构建整个数据集。当宽仿差然由于操作系统会在内核中缓存write做的大蔽修改，所以可能不是立即写到磁盘上。这样的持久化还是有可能会丢失部分修改。不过我们可以通过配置文件告诉 redis我们想要通过fsync函数强制操作系统写入到磁盘的时机。

appendonly yes //启用日志追加持久化方式

（1）appendfsync always //收到写命令就立即强制写入磁盘。最慢的，但是保证完全持久化，不推荐使用。

（2）appendfsync everysec //每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐使用。

（3）appendfsync no //完全依赖操作系统，性能最好,持久化没保证。

通过 RDB 或 AOF，都可以将 redis 内存中的数据持久化到磁盘上面来，然后可以将这些数据备份到别的地方去。

1.RDB方式

优点：

缺点：

2.AOF方式

优点:

缺点：

不要仅仅使用 RDB，因为那样会导致你丢失很多数据；也不要仅仅使用 AOF，因为那样有两个问题：第一，你通过 AOF 做冷备，没有 RDB 做冷备来的恢复速度更快；第二，RDB 每次简单粗暴生成数据快照，更加慎皮健壮，可以避免 AOF 这种复杂的备份和恢复机制的 bug；redis 支持同时开启开启两种持久化方式，我们可以综合使用 AOF 和 RDB 两种持久化机制，用 AOF 来保证数据不丢失，作为数据恢复的第一选择; 用 RDB 来做不同程度的冷备，在 AOF 文件都丢失或损坏不可用的时候，还可以使用 RDB 来进行快速的数据恢复。

出处：

[img]

Redis的五种数据结构及其底层实现原理

redis的字符串类型是由一种叫做简单动态字符串(SDS)的数据类型来实现

SDC和C语言字符串的区别：

1：SDS保存了字符串的长度，而C语言不保存，盯棚凯只能遍历找到第一个\0的结束符才能确定字符串的长度

2：修改SDS，会检查空间是否足够，不足会先扩展空间，防止缓冲区溢出，C字符串不会检查

3：SDS的预分配空间机制，可以减少为字符串重新分配空间的次数

备注：重新分配空间方式，小于1M的数据 翻倍+1，例如：13K+13K+1，如果大于1M，每次多分配1M，例如：10M+1M+1,如果字符串变短，并不会立即缩短，而是采用惰性空间释放，有专门的API可以释放多余空间

hash结构里其实是一个字典，有许多的键值对

redis的哈希表是一个dictht结构体：

哈希表节点的结构体如下：

hash算法：

当要将一个新的键值对添加到字典里面时， 程序需要先根据键值对的键计算出哈希值和索引值， 然后再根据索引值， 将包含新键值对的哈希表节点放到哈希表数组的指定索引上面。

hash冲突解决方式：链表法，后入的放到最前面

rehash：

键值数据量变动时，时为了让哈希表的负载因子（load factor）维持在一个合理的范围之内， 当哈希表保存的键值对数量太多或者太少时， 程序需要对哈希表的大小进行相应的扩展或和仿者收缩。

如果是扩充，新数组的空间大小为 大于2*used的2的n次方，比如：used=5,则去大于10的第一个2的n次方，为16

如果是缩小，新数组的空间大小为第一个不大于used的2的n次方，比如：used=5,则新大小为4

redis的list列表是使用双向链表来实现的

···

typedef struct listNode {

struct listNode * pre; //前置节点

struct listNode * next; //后置节点

void * value; //节点的值

}

typedef struct list {

listNode *head; //表头节点

listNode tail; //表尾节点

unsigned long len; //链表所包含的节点数量

void ( dup) (void ptr); //节点值赋值函数 这里有问题

void ( free) (void ptr); //节点值释放函数

int ( match) (void *ptr, void *key) //节点值对比函数

}

···

1：有序集合的底层实现之一是跳表， 除此之外跳表它在 Redis 中没有其他应用。

2：整数集合（intset）是集合键的底层实现之一： 当一个集合只包含整数值元素， 并且这个集合的元素数量不多时， Redis 就会使用整数集合作为集合键的底层实现。

3：数据少是，使用ziplist(压缩列表)，占用连续内存，每项元素都是(数据+score)的方式连续存储，按照score从小到大排序。ziplist为了节省内存，每个元素占用的空间可以不同，对于大数据(long long),就多用一些字节存储，而对于小的数据(short)，就少用一些字节来存储。因此查找的时候需要按顺序遍历。ziplist省内存但是查找效率低。

无序集合可以用整数集合(intset)或者凯唤字典实现

Redis的5.0版本中，放出一个新的数据结构Stream。其实也是一个队列，没一个不同的key对应的是不同的队列，没个队列的元素，也就是消息，都有一个msgid，并且需要保证msgid是严格递增的。在Stream当中，消息是默认持久化的，即便是Redis重启，也能够读取到信息。

Stream的多播，与其它队列系统相似，对不同的消费者，也有消费者Group这样的概念，不同的消费组，可以消费通一个消息，对于不同的消费组，都维护一个Idx下标，表示这一个消费群组费到了哪里，每次进行消费，都会更新一下这个下标，往后面一位进行偏移。

跳跃表是一种有序数据结构，它通过在每个节点中维持多个指向其它节点的指针，从而大道快速访问节点的目的，具有以下性质：

1：有很多层结构组成

2：每一层都是一个有序的链表，排列顺序为由高到低，都至少包含两个链表节点，分别是前面的head节点和后面的nil节点

3：最底层的链表包含了所有的元素

4：如果一个元素出现在某一层的链表中，那么在该层之下的链表也全部都会出现

5：链表中的每个节点都包含两个指针，一个指向同一层的下一个链表节点，另一个指向下一层的通一个链表节点

多个跳跃表节点构成一个跳跃表

1：搜索，从最高层的链表节点开始，如果比当前节点要大和比当前层的下一个节点要小，那么则往下找，也及时和当前层的下一层的节点下一个节点

2：插入，首先确定插入的层数，有一种方法是抛一个硬币，如果是正面就累加，直到遇到反面为止，最后记录正面的次数作为插入的层数，当确定插入的层数K后，则需要将新元素插入从底层到K层

3：删除，在各个层中找到包含指定值得节点，然后将节点从链表中删除即可，如果删除以后只剩下头尾两个节点，则删除这一层。

整数集合是Redis用于保存整数值集合的抽象数据类型，它可以保存int16_t、int32_t、int64_t的整数值，并且保证集合中不会出现重复元素。

整数集合的每个元素都是contents数组的一个数据项，他们按照从小到大的顺序排列，并且不包含任何重复项。

length属性记录了contents数组的大小。

需要注意的是虽然contents数组声明为int8_t类型，但是实际上contents数组并不保存任何int8_t类型的值，其真正类型由encoding来决定。

压缩列表(ziplist)是Redis为了节省内存而开发的，是由一系列特殊编码的连续内存块组成的顺序型数据结构，一个压缩列表可以包含任意多个节点(entry)，每个节点可以保存一个字节数组或一个整数值。

压缩列表的原理：压缩列表并不是对数据利用某种算法进行压缩的，而是将数据按照一定规则编码在一块连续的内存区域，目的是节省内存。

压缩列表的每个节点构成如下：

redis缓存原理

1、Redis是一种内存高速cache，如果使用redis缓存，那经常被访问的内容会被缓存在内存中，需要使用的时候直接从内存调取，不知道比硬盘调取快了多少倍，并且支持复杂的数据结构，段侍应用于许多高并发的场景中。

2、Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。存盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。zset是set的一个升级版本，他在set的基础上增加了一个顺序属性，这一属性在添加修改元素的时候可以指定，每次指定后，zset会自动重新按新的值调整顺序。可以理解了有两列的mysql表族返，一列存value，一列存顺序。操作中key理解为zset的名字。

更握穗吵多关于redis缓存原理，进入：查看更多内容

redis是怎么实现的

第一：Redis 是什么？

Redis是基于内存、可持久化的日志型、Key-Value数据库 高性能存储系统，并提供多种语言的API.

第二：出现背景

数据结构(Data Structure)需求越来越多, 但memcache中没有, 影响开发效率

性能需求, 随着读操作的量的上升需要解决，经历的过程有: 

数据库读写分离(M/S)–数据库使用多个Slave–增加Cache (memcache)–转到Redis

解决写的问题： 

水平拆分，对表的拆分，将有的用户放在这个表，有的用户放在另外一个表；

可靠性需求 

Cache的"雪崩"问题让人纠结 

Cache面临着快速恢复的挑战

开发成本需求 

Cache和DB的一致性维护成本越来越高(先清理DB, 再清理缓存, 不行啊, 太慢了!) 

开发需要跟上不断涌入的产品需求 

硬件成本最贵的就是数据库层面的机器，基本上比前端的机器要贵几倍，主要是IO密集型，很耗硬件；

维护性复杂 

一致性维护成本越来越高； 

BerkeleyDB使用B树，会一直写新的，内部不会有文件重新组织；这样会导致文件越来越大；大的时候需要进行文件归档，归档的操作要定期做； 

这样，就需要有一定的down time；

基于以上考虑， 选择了Redis

第三：Redis 在新浪微博中的应用

Redis简介

1. 支持5种数据结构

支持strings, hashes, lists, sets, sorted sets 

string是很好的存储方式，用来做计数存储。sets用于建立索引库非常棒；

2. K-V 存储 vs K-V 缓存

新浪微博目前使用的98%都是持久化的应用，2%的是缓存，用到了600+服务器 

Redis中持久化的应用和非持久化的方式高基誉不会差别很大： 

非持久化的为8-9万tps，那么持久化在7-8万tps左右； 

当使用持久化时，需要考虑到持久化和写性能的配比，也就是要考虑redis使用的内存大小和硬盘写的速率的比例计算；

3. 社区活跃

Redis目前有3万多行代码, 代码写的精简，有很多巧妙的实现，作者有技术洁癖 

Redis的社区活跃度很高，这是衡量开源软件质量的重要指标，开源软件的初期一般都没有商业技术服务支持，如果没有活跃社区做支撑，一旦发生问题都无处求救；

Redis基本原理

redis持久化(aof) append online file： 

写log(aof), 到一定程度再和内存合并. 追加再追加, 顺序写磁盘, 对性能影响非常小

1. 单实例单进程

Redis使用的是单进程，所以在配置时，一个实例只会用到一个CPU； 

在配置时，如果需要让CPU使用率最大化，可以配置Redis实例数对应CPU数, Redis实例数对应端口数(8核Cpu, 8个实锋猛例, 8个端口), 以提高并发: 

单机测试时, 单条数据在200字节, 测试的结果为8~9万tps；

2. Replication

过程: 数据写到master–master存储到slave的rdb中–slave加载rdb到内存。 

存储点(save point): 当网络中断了, 连上之后, 继续传. 

Master-slave下第一次同步是全传，后面是增量同步；、

3. 数据一致性

长期运行后多个结点之间存在不一致的可能性； 

开发两个工具程序： 

1.对于数据量大的数据，会周期性的全量检查； 

2.实时的检查增量数据，是否具有一致性；

对于主库未及时同步从库导致的不一致，称之为延时问题； 

对于一致性要求不是那么严格的场景，我们只需要要保证最终一致性即可； 

对于延时问题，需要根据业务场景特点分析，从应用层面增加策略来解决这个问题； 

例如： 

1.新注册的用户，必须先查询主库； 

2.注册戚段成功之后，需要等待3s之后跳转，后台此时就是在做数据同步。

第四：分布式缓存的架构设计

1.架构设计

由于redis是单点，项目中需要使用，必须自己实现分布式。基本架构图如下所示：

2.分布式实现

通过key做一致性哈希，实现key对应redis结点的分布。

一致性哈希的实现：

l        hash值计算：通过支持MD5与MurmurHash两种计算方式，默认是采用MurmurHash，高效的hash计算.

l        一致性的实现：通过java的TreeMap来模拟环状结构，实现均匀分布

3.client的选择

对于jedis修改的主要是分区模块的修改，使其支持了跟据BufferKey进行分区，跟据不同的redis结点信息，可以初始化不同的 ShardInfo，同时也修改了JedisPool的底层实现，使其连接pool池支持跟据key,value的构造方法，跟据不同 ShardInfos，创建不同的jedis连接客户端，达到分区的效果，供应用层调用

4.模块的说明

l        脏数据处理模块，处理失败执行的缓存操作。

l        屏蔽监控模块，对于jedis操作的异常监控，当某结点出现异常可控制redis结点的切除等操作。

整个分布式模块通过hornetq，来切除异常redis结点。对于新结点的增加，也可以通过reload方法实现增加。（此模块对于新增结点也可以很方便实现）

对于以上分布式架构的实现满足了项目的需求。另外使用中对于一些比较重要用途的缓存数据可以单独设置一些redis结点，设定特定的优先级。另外对 于缓存接口的设计，也可以跟据需求，实现基本接口与一些特殊逻辑接口。对于cas相关操作，以及一些事物操作可以通过其watch机制来实现。

声明：所有博客服务于分布式框架，作为框架的技术支持及说明，框架面向企业，是大型互联网分布式企业架构，后期会介绍linux上部署高可用集群项目。

关于redis原理和redis原理面试题的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。