redis底层算法（redis底层数据如何实现）

大家好！今天让创意岭的小编来大家介绍下关于redis底层算法的问题，以下是小编对此问题的归纳整理，让我们一起来看看吧。

ChatGPT国内免费在线使用，一键生成原创文章、方案、文案、工作计划、工作报告、论文、代码、作文、做题和对话答疑等等

只需要输入关键词，就能返回你想要的内容，越精准，写出的就越详细，有微信小程序端、在线网页版、PC客户端

官网：https://ai.de1919.com

本文目录:

• 1、Redis高级用法与删除方式

• 2、Redis哨兵模式的实现原理

• 3、redis 数据分区--一致性hash&&虚拟槽分区

• 4、Redis hash槽分配

一、Redis高级用法与删除方式

一、redis为什么这么快

1、完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)；

2、数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的；

3、采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；

4、使用多路I/O复用模型，非阻塞IO；

5、使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求；

以上几点都比较好理解，下边我们针对多路 I/O 复用模型进行简单的探讨：

（1）多路 I/O 复用模型

多路I/O复用模型是利用 select、poll、epoll 可以同时监察多个流的 I/O 事件的能力，在空闲的时候，会把当前线程阻塞掉，当有一个或多个流有 I/O 事件时，就从阻塞态中唤醒，于是程序就会轮询一遍所有的流（epoll 是只轮询那些真正发出了事件的流），并且只依次顺序的处理就绪的流，这种做法就避免了大量的无用操作。

这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程。采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络 IO 的时间消耗），且 Redis 在内存中操作数据的速度非常快，也就是说内存内的操作不会成为影响Redis性能的瓶颈，主要由以上几点造就了 Redis 具有很高的吞吐量。

采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；完全基于内存，没有磁盘IO的限制。在redis中对数据进行持久化的时候

resp通信协议

使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求；

二、高级用法

1、位图

bitmap：体积小，10M可存储8千万bit位，最大允许访问512M，可存储40亿bit位

2、布隆过滤器

由一串很长的二进制向量组成，可以将其看成一个二进制数组（里面存放的都为0或者1，初始默认值为0）。向里面添加元素时，会使用多个hash函数进行计算取模得出一个数组的下标，每个hash都会算出不同的位置，再把这些位置都置为1，就完成了add操作

3、GEO

将指定的地理空间位置（经纬度及名称）添加到指定的key中，必须经度在纬度之前。（场景：微信摇一摇；周边餐饮；快递距离等）

4、HyperLogLog

用来做基数统计的算法，HyperLogLog 的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定 的、并且是很小的。

HyperLogLog 可以接受多个元素作为输入，并给出输入元素的基数估算值：

• 基数：集合中不同元素的数量。比如 {'apple', 'banana', 'cherry', 'banana', 'apple'} 的基数就是 3 。

• 估算值：算法给出的基数并不是精确的，可能会比实际稍微多一些或者稍微少一些，但会控制在合

理的范围之内。

HyperLogLog 的优点是，即使输入元素的数量或者体积非常非常大，计算基数所需的空间总是固定

的、并且是很小的。

在 Redis 里面，每个 HyperLogLog 键只需要花费 12 KB 内存，就可以计算接近 2^64 个不同元素的基

数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。

但是，因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以

HyperLogLog 不能像集合那样，返回输入的各个元素。

提问：为什么不使用redis替代MQ

1、redis无法对消息持久化存储

2、redis没有提供消息传输保障

3、redis协议支持较少

三、删除方式

1、被动删除：惰性删除

客户端访问 key 的时候，redis 对 key 的过期时间进行检查，如果过期了就立即删除，不会给你返回任何东西。

2、主动删除：定期删除

redis 会将每个设置了过期时间的 key 放入到一个独立的字典中，以后会定期遍历这个字典来删除到期的 key。

3、主动删除：redis会周期性的随机测试一批设置了过期时间的key并进行处理（redis-3.0.0中默认值是10，代表每秒钟调用10次后台任务）

4、LRU:这个缓存算法将最近使用的条目存放到靠近缓存顶部的位置。当一个新条目被访问时，LRU将它放置到缓存的顶部。当缓存达到极限时，较早之前访问的条目将从缓存底部开始被移除。这里会使用到昂贵的算法，而且它需要记录“年龄位”来精确显示条目是何时被访问的。此外，当一个LRU缓存算法删除某个条目后，“年龄位”将随其他条目发生改变。

5、LFU:这个缓存算法使用一个计数器来记录条目被访问的频率。通过使用LFU缓存算法，最低访问数的条目首先被移除。这个方法并不经常使用，因为它无法对一个拥有最初高访问率之后长时间没有被访问的条目缓存负责。

二、Redis哨兵模式的实现原理

Redis哨兵模式的实现原理。

关于哨兵的原理，关键是了解以下几个概念：

定时任务：每个哨兵节点维护了3个定时任务。定时任务的功能分别如下：通过向主从节点发送info命令获取最新的主从结构；通过发布订阅功能获取其他哨兵节点的信息；通过向其他节点发送ping命令进行心跳检测，判断是否下线。

主观下线：在心跳检测的定时任务中，如果其他节点超过一定时间没有回复，哨兵节点就会将其进行主观下线。顾名思义，主观下线的意思是一个哨兵节点“主观地”判断下线；与主观下线相对应的是客观下线。

客观下线：哨兵节点在对主节点进行主观下线后，会通过sentinel is-master-down-by-addr命令询问其他哨兵节点该主节点的状态；如果判断主节点下线的哨兵数量达到一定数值，则对该主节点进行客观下线。

需要特别注意的是，客观下线是主节点才有的概念；如果从节点和哨兵节点发生故障，被哨兵主观下线后，不会再有后续的客观下线和故障转移操作。

选举领导者哨兵节点：当主节点被判断客观下线以后，各个哨兵节点会进行协商，选举出一个领导者哨兵节点，并由该领导者节点对其进行故障转移操作。

监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法；Raft算法的基本思路是先到先得：即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者。选举的具体过程这里不做详细描述，一般来说，哨兵选择的过程很快，谁先完成客观下线，一般就能成为领导者。

三、redis 数据分区--一致性hash&&虚拟槽分区

1.节点区域分区:

使用特定的数据,如redis的键或用户ID,再根据节点数量N使用公式:hash(key)%N计算出hash值,用来决定数据映射到哪一个节点上.

这种方案的问题是:

当节点数量变化时,需要重新计算hash,会导致数据的重新迁移.

2.一致性hash算法

一致性hash算法实现思路是为系统中每一个节点分配一个token,范围在0~2^32,这些token构成一个hash环.数据的读写执行节点查找操作时,先根据key计算hash值,然后顺时针找到第一个大于等于该hash的token节点.

好处:

这种方式最大的好处就是,在加入或删除节点时,只影响hash环中相邻的两个节点,对其他节点无影响.

问题:

3.虚拟槽算法

使用分散度较好的hash函数,将所有的数据映射到 比如0~16383(2^14)范围的槽中(slot).这个槽的数量一般远远大于实例的数量.

槽是集群数据管理和迁移的基本单位.采用大范围槽的主要目的是为了方便数据拆分和集群扩展.

每一个实例会映射一部分范围的槽.

特点:

1.解耦数据和节点之间的关系,简化扩容和锁容的难度

2.节点自身维护槽的映射关系,不需要客户端或代理服务维护槽分区的元数据.

3.支持节点,槽,键之间的映射查询,用于数据路由,在线伸缩灯场景.

HashTags（面试）

Mset k1 v1 k2 v2 k3 v3

通过分片手段，可以将数据合理的划分到不同的节点上，这本来是一件好事。但是有的时候，我们希望对相关联的业务以原子性方式进行操作。举个简单的例子

我们在单节点上执行MSET （m表示多个，一次向redis设置多个key和值）, 它是一个原子性的操作，我们要求所有给定的key要在同一时间内被设置，不能出现某些指定的key被更新另一些指定的key没有被更新的情况。但是在集群环境下，我们仍然可以执行MSET命令，但它的操作不在是原子操作，会存在某些指定的key被更新，而另外一些指定的key没有改变，原因是多个key可能会被分配到不同的机器上。

所以，这里就会存在一个矛盾点，及要求key尽可能的分散在不同机器，又要求某些相关联的key分配到相同机器。

这个也是在面试的时候会容易被问到的内容。怎么解决呢？

从前面的分析中我们了解到，分片其实就是一个hash的过程，对key做hash取模然后划分到不同的机器上。所以为了解决这个问题，我们需要考虑如何让相关联的key得到的hash值都相同呢？如果key全部相同是不现实的，所以怎么解决呢？在redis中引入了HashTag的概念，可以使得数据分布算法可以根据key的某一个部分进行计算，然后让相关的key落到同一个数据分片；

举个简单的例子，假如对于用户的信息进行存储，

redis:store:1001、redis:store:1002

那么通过hashtag的方式，

redis:{store}:1001、redis:{store}:1002; 表示

当一个key包含 {} 的时候，就不对整个key做hash，而仅对 {} 包括的字符串做hash。

四、Redis hash槽分配

Redis 集群中内置了 16384 个哈希槽，当需要在 Redis 集群中放置一个 key-value

时，redis 先对 key 使用 crc16 算法算出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，redis 会根据节点数量大致均等的将哈希槽映射到不同的节点。Redis 集群没有使用一致性hash, 而是引入了哈希槽的概念。

Redis 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽.集群的每个节点负责一部分hash槽。这种结构很容易添加或者删除节点，并且无论是添加删除或者修改某一个节点，都不会造成集群不可用的状态。使用哈希槽的好处就在于可以方便的添加或移除节点。当需要增加节点时，只需要把其他节点的某些哈希槽挪到新节点就可以了；当需要移除节点时，只需要把移除节点上的哈希槽挪到其他节点就行了；在这一点上，我们以后新增或移除节点的时候不用先停掉所有的 redis 服务。

"用了哈希槽的概念，而没有用一致性哈希算法，不都是哈希么？这样做的原因是为什么呢？

"Redis Cluster是自己做的crc16的简单hash算法，没有用一致性hash。Redis的作者认为它的crc16(key) mod 16384的效果已经不错了，虽然没有一致性hash灵活，但实现很简单，节点增删时处理起来也很方便。"为了动态增删节点的时候，不至于丢失数据么？"节点增删时不丢失数据和hash算法没什么关系，不丢失数据要求的是一份数据有多个副本。“还有集群总共有2的14次方，16384个哈希槽，那么每一个哈希槽中存的key 和 value是什么？”当你往Redis Cluster中加入一个Key时，会根据crc16(key) mod 16384计算这个key应该分布到哪个hash slot中，一个hash slot中会有很多key和value。你可以理解成表的分区，使用单节点时的redis时只有一个表，所有的key都放在这个表里；改用Redis Cluster以后会自动为你生成16384个分区表，你insert数据时会根据上面的简单算法来决定你的key应该存在哪个分区，每个分区里有很多key。

以上就是关于redis底层算法相关问题的回答。希望能帮到你，如有更多相关问题，您也可以联系我们的客服进行咨询，客服也会为您讲解更多精彩的知识和内容。

推荐阅读：

快速记忆previous（快速记忆的方法和技巧）

comprehensive谐音记忆

自动降重软件免费（papereasy论文降重）

景观设计插画招聘文章（景观设计插画招聘文章怎么写）

如何让直播出立体声（手机直播 立体声输入）