世界上并没有完美的程序，但是我们并不因此而沮丧，因为写程序就是一个不断追求完美的过程。

Redis的列表（List），其存储结构采用的是双向链表，而非数组形式。这种结构在随机定位方面性能欠佳，但在首尾插入和删除数据方面表现出色。当数据量较大时，需要特别关注链表操作的时间消耗。如果，使用Redis来存储用户的购物车数据。每个用户都有一个对应的购物车列表，以用户 ID作为键。如果，使用Redis存储用户的订单列表。当需要查询某个用户特定订单在列表中的详细信息时，就可以使用lindex指令。例如，如果你有一个名为【用户ID-1lrange 用户ID-1 0 3。

随着数据需求的迅猛增长，持久化和数据查询技术的重要性日益凸显。关系型数据库已不再是唯一选择，数据的处理方式正变得日益多样化。在众多新兴的解决方案与工具中，Redis凭借其独特的优势脱颖而出。跳跃表是有序集合的底层实现机制之一，Redis的跳跃表实现精巧地由zskiplist和zskiplistNode两个结构共同构成。其中，zskiplist结构负责保存整个跳跃表的关键信息，如表头节点、表尾节点以及长度等，而zskiplistNode结构则用于具体表示跳跃表中的每一个节点。

随着数据需求的迅猛增长，持久化和数据查询技术的重要性日益凸显。关系型数据库已不再是唯一选择，数据的处理方式正变得日益多样化。在众多新兴的解决方案与工具中，Redis凭借其独特的优势脱颖而出。

随着数据需求的迅猛增长，持久化和数据查询技术的重要性日益凸显。关系型数据库已不再是唯一选择，数据的处理方式正变得日益多样化。在众多新兴的解决方案与工具中，Redis凭借其独特的优势脱颖而出。以下是关于相关方法的介绍，这些方法定义在adlist.h头文件中，如以下源码所示。但值得注意的是，.h头文件通常只包含函数的声明和定义概念，而真正的函数实现机制则位于adlist.c源文件中。

随着数据需求的迅猛增长，持久化和数据查询技术的重要性日益凸显。关系型数据库已不再是唯一选择，数据的处理方式正变得日益多样化。在众多新兴的解决方案与工具中，Redis凭借其独特的优势脱颖而出。

对于熟悉Redis功能的开发相关人员而言，Lua语言想必不会陌生。作为Redis的一个重要扩展，Lua在Redis中扮演着至关重要的角色，使得Redis具备了更为强大的脚本处理能力。Lua是一款轻量级脚本语言，以标准C语言为基础，其源码开放，设计初衷即是为了嵌入各类应用程序，赋予它们灵活的扩展与定制能力。

在分布式架构的实践中，某一特定的Key数据往往会被针对性地分配至后端某台服务器上的独立Redis实例中，以实现高效的数据存储。然而，当这一Key遭遇突发性且高强度的请求操作时，往往会出现流量过于集中的情况。这种流量集中现象会导致单一Redis实例的处理能力受到严峻挑战，很可能使其CPU利用率急剧上升，逼近甚至达到满载状态。这种满载状态不仅会对整个系统的稳定性造成冲击，降低其可靠性，更可能直接威胁到系统的可用性，导致服务中断或性能下降。充分利用这些数据，我们可以设计一套定时上报机制。

在Redis 6.0版本中，引入了多线程技术，这是为了进一步提高Redis的性能和并发处理能力。通过启用多线程，Redis能够同时处理多个客户端请求，有效地利用多核处理器资源，提高系统的吞吐量和响应速度。开启多线程可以在处理阻塞操作时提供更好的性能，例如慢查询、持久化操作等。此外，多线程还能够更好地应对高并发的情况，减少请求的排队等待时间，提高系统的响应能力。Redis 引入了多线程机制，但主要的数据处理和查询请求处理仍然是基于单线程的。

Redis作为一种高性能的内存NoSQL数据库，其容量受限于最大内存的限制。用户在使用阿里云Redis时，除了对性能和稳定性有较高的要求外，对内存占用也非常敏感。然而，在实际使用中，一些用户可能会发现他们的线上实例的内存占用比预期的要大。不要放垃圾数据，及时清理无用数据：定期清理垃圾数据和下线的业务数据，避免占用不必要的内存空间和资源。设置过期时间：对具有时效性的键设置合理的过期时间，利用Redis自身的过期键清理策略，降低过期键对内存的占用，并避免手动清理的麻烦。

在RedisConfig类的Bean初始化之前，将配置文件中的属性的值赋给静态变量。这样可以在其他地方通过访问来获取Redis的用户名。但是代码中的部分内容，如和似乎没有实际作用，可能是作者误写或者遗留的无用代码。

在上述命令中，将"新节点ip"替换为要添加的从节点的IP地址，将"端口号"替换为对应的端口号，将"主节点的id"替换为主节点的实际ID，将"集群中任意节点ip"替换为已存在的集群中的任意一个节点的IP地址和端口号。如果您需要添加新的Redis节点到集群中，请将"新节点ip"替换为要添加的Redis节点的IP地址，将"端口号"替换为对应的端口号，并将"集群中任意节点ip"替换为已存在的集群中的任意一个节点的IP地址和端口号。在删除主节点之前，需要进行一些数据迁移操作，并将该节点上的哈希槽分配给其他主节点。

Redis集群提供了可靠的高可用性和扩展性，能够满足大规模分布式应用中对于高性能和数据可靠性的要求。通过节点间的数据分片、主从复制和自动迁移，Redis集群能够实现数据的平衡分布和故障恢复。节点自动发现：Redis Cluster可以自动发现新加入的节点，并将其加入到集群中。当一个新的节点加入集群时，其他节点会自动感知到并进行相应的配置更新。

Redis是一种面向"key-value"类型数据的分布式NoSQL数据库系统，具有高性能、持久存储和适应高并发应用场景等诸多优势。尽管Redis的发展起步较晚，但它的发展速度迅猛。

自Redis 3.0版本之后，Redis开始支持Cluster功能（因此您需要安装3.0版本或更高版本的Redis）。Failover是一种系统设计和实现的机制，旨在确保在主节点（Master）故障或不可用时能够无缝切换到备用节点（Slave）以保持服务的连续性和可用性。在服务器A上执行下面语句测试连通性在服务器B上执行下面语句测试连通性如果上面的测试没有问题，则可进行下步操作。

Redis是一个开源、高性能的key-value存储系统。它支持数据持久化、多样的数据结构、数据备份以及拥有高性能和原子性操作等特点。此外，Redis提供了丰富的扩展特性，包括发布/订阅、通知和键的过期等，适用于各种实时应用和消息系统。Redis的代码风格简洁，源码可读性强，进一步促进了开发者对Redis的理解和使用。相信看了本篇内容，你应该对Redis的启动逻辑有了一定的认识，后面会针对于源码进行深入分析，敬请期待！

是Redis的一个配置项，用于设置慢查询日志的阈值。它表示执行时间超过该阈值的命令会被记录到慢查询日志中。在您提供的示例中，被配置为10000，单位是微秒（μs），即10毫秒。这意味着当一个命令的执行时间超过10毫秒时，它将被Redis记录到慢查询日志中。是Redis的另一个配置项，表示慢查询日志的最大长度。它决定了慢查询日志中可以保存的记录数量。在您提供的示例中，被配置为128，即最多保存128条慢查询日志记录。当慢查询日志中的记录达到最大长度后，新的慢查询会替换掉最旧的记录。

高消耗资源的命令即时间复杂度为O(N)或更高的命令，通常情况下，命令时间复杂度越高，在执行时消耗的资源越高，这会导致CPU使用率超高，容易触发主备倒换。slowlog-log-slower-than：如果在Redis实例的数据节点中执行一个命令，执行时间超过了slowlog-log-slower-than参数设置的阈值（单位为微秒），则会被记录到慢查询中。慢查询功能会记录执行超过指定时间阈值的命令，通过分析慢查询的语句和执行时长可帮助您找出高消耗命令，具体操参见慢查询。删除后，信息将永远丢失。

当你的应用服务在连接Redis时出现了拒绝连接的场景，首先你可以根据调整Redis实例参数maxclients的配置。maxclients代表着最大同时连接的客户端个数，Proxy集群实例不支持该参数，取值范围1,000～50,000，默认值：10,000，可以调整的再大一些。如果你使用的是集群模式，而使用客户端连接进行连接Cluster集群时，连接失败出现Read timed out或Could not get a resource from the pool。Jedis连接池调优，建议参考Jedis参数

本篇文章主要介绍了Redis的执行的慢查询的功能的查询和配置功能，从而可以方便我们在实际工作中，进行分析Redis的性能运行状况以及对应的优化Redis性能的佐证和指标因素。在我们5.0左右的版本中Redis使用单线程架构和I/O多路复用模型来实现高性能的内存数据服务。接下来主要分析Redis单线程命令处理机制，接着分析Redis单线程模型为什么性能如此之高。慢查询就是当Redis在处理一条指令的时候，当超过了系统配置的执行时间的阈值的时候，就会被系统当作慢查询统计和判定。

之前我们的服务，在上线的时候发现有一些大Key的使用不是很规范，特别是没有设置过期时间，因此导致redis中内存的数据越来越多，目前Redis节点的内存已经快撑不住了。所以根据缓存键的规则去批量删除这些数据，比较常见的就是按前缀去删除。现在由于不得以为的原因要删除这几百个Key-Value的数据，这个时候我们肯定就要把缓存键全部删除掉。一般情况下在Redis中是可以很容易去实现的。但是如果在不阻塞业务的前提下，并且以高效的方式进行清理内存数据。就需要好好想想办法了。

Redis是一个开源（BSD 许可）、内存存储的数据结构服务器，可用作数据库，高速缓存和消息队列代理。它支持字符串、哈希表、列表、集合、有序集合等数据类型。内置复制、Lua 脚本、LRU收回、事务以及不同级别磁盘持久化功能，同时通过 Redis Sentinel 提供高可用，通过Redis Cluster提供自动分区。

redis-full-check是阿里云自研的Redis数据校验工具，能够提取源端和目的端的数据进行多轮差异化比较，并将比较结果记录在一个SQLite3数据库中，从而达到全量数据校验的目的。迁移源端和目的端Redis实例需为主从版、单节点版、开源集群版以及部分云上带proxy的集群版（阿里云、腾讯云）。redis-full-check对比的方向是单向，如果希望对比双向，则需要对比2次，第一次以A为源库，B为目的库，第二次以B为源库，A为目的库。

下面是有效的ACL规则列表。某些规则只是单个单词，用于激活或删除标志，或执行对用户ACL的给定更改。其他规则是与命令或类别名称、键模式等连接在一起的字符前缀。+: 将该命令添加到用户可以调用的命令列表中。可以与一起使用，允许子命令(例如“+config | get”)。-: 将该命令移到用户可以调用的命令列表中。从Redis 7.0开始，它可以与|一起用于阻塞子命令(例如“-config|set”)。: 添加该类别中所有用户调用的命令，有效类别为@admin@set。

源端有多少个分片，cluster_helper.py 就会起多少个 redis-shake 进程，所以如果源端分片数较多的时候，需要评估当前机器是否可以承担这么多进程。cluster_helper.py 异常退出的时候，可能没有正常退出 redis-shake 进程，需要 ps aux | grep redis-shake 检查。使用redis-shake的scan在线迁移操作，主要通过scan.toml文件进行配置和执行迁移操作，如下图所示。

在第一轮校验时，Redis-full-check 会找出在源实例上的所有 key，然后从源实例和目的实例中把相应的值也都查找出来，进行比对。随着 Redis-shake 增量同步的进行，源实例和目的实例中的不一致数据也会逐步减少，所以，我们校验比对的轮数不用很多。Redis-full-check 的工作原理很简单，就是对源实例和目的实例中的数据进行全量比对，从而完成数据校验。与在线迁移相比，离线迁移适宜于源实例与目标实例的网络无法连通的场景，或者源端实例部署在其他云厂商Redis服务中，无法实现在线迁移。

RedisShake是基于redis-port基础上进行改进的是一款开源的Redis迁移工具，支持Cluster集群的在线迁移与离线迁移（备份文件导入）。数据可平滑迁移，当部署在其他云厂商Redis服务上的Cluster集群数据，由于SYNC、PSYNC命令被云厂商禁用，无法在线迁移时，可以选择离线迁移。

使用 Redis 主从服务的时候，会有一个问题，就是当 Redis 的主从服务器出现故障宕机时，需要手动进行恢复，为了解决这个问题，Redis 增加了哨兵模式（因为哨兵模式做到了可以监控主从服务器，并且提供自动容灾恢复的功能）。如果主线程执行写操作，则被修改的数据会复制一份副本（指令传播），然后bgsave子进程会把该副本数据写入 RDB 文件，在这个过程中，主线程仍然可以直接修改原来的数据。要注意，Redis 对 RDB 的执行频率非常重要，因为这会影响快照数据的完整性以及 Redis 的稳定性，

伴随着缓存处于高并发下的高性能和高可用的特性，在互联网或者传统软件行业下的地位也与日俱增，无论在平时的开发过程中或者在面试中都是出场率非常高的存在，所以本人写了一些关于从基础到高级的阶段性的面试题集，希望可以对一些小伙伴们有帮助，祝愿天下的小伙伴都可以拥有更加健全的知识体系以及更理想的生活，加油奋斗！

总体过程主节点负责写数据，从节点负责读数据。主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)；数据的复制是单向的，只能由主节点到从节点。默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

Redission 为 Redis 官网分布式解决方案官网：快速入门： https://github.com/redisson/redisson#quick-startgithub的Redission系列：https://github.com/orgs/redisson/repositoriesend;end;

每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。AOF 的数据完整性比RDB高，但记录内容多了，会影响数据恢复的效率。RDB与AOF二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。Redis允许同时开启AOF和RDB，既保证了数据安全又使得进行备份等操作十分容易。

Redis 默认开启RDB持久化方式，在指定的时间间隔内，执行指定次数的写操作，则将内存中的数据写入到磁盘中。RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。Redis 需要手动开启AOF持久化方式，默认是每秒将写操作日志追加到AOF文件中。所以Redis的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。

Redis 集群没有使用一致性hash，而是引入了哈希槽的概念，预分好16384个桶，根据 CRC16(key) mod 16384的值，决定将一个key放到哪个桶中，每个Redis物理结点负责一部分桶的管理，当发生Redis节点的增减时，调整桶的分布即可。为了实现哈希标签，哈希槽是用另一种不同的方式计算的。基本来说，如果一个键包含一个 “{…}” 这样的模式，只有 { 和 } 之间的字符串会被用来做哈希以获取哈希槽。如果键包含一个 { 字符。那么在 { 的右边就会有一个 }。

首先，脑裂从字面上理解就是脑袋裂开了，就是思想分家了，就是有了两个山头，就是有了两个主思想。

Redis Cluster 实现了一种 混合形式 的 查询路由，但并不是 直接 将请求从一个 Redis 节点 转发 到另一个 Redis 节点，而是在 客户端 的帮助下直接 重定向（ redirected）到正确的 Redis 节点。Redis的Sentinel解决了主从复制故障不能自动迁移的问题，但是主节点的写性能和存储能力依然是受到了Redis单机容量有限的限制，所以使用Redis集群去解决这个问题，将Redis的数据根据一定的规则分配到多台机器。

业务中存在访问热点是在所难免的，redis也会遇到这个问题，然而如何发现热点key一直困扰着许多用户，redis4.0为我们带来了许多新特性，其中便包括基于LFU的热点key发现机制。} robj;高16位用来记录访问时间（单位为分钟）LRU低8位用来记录访问频率，简称counter LFU熟悉Redis的人都知道，它是单线程的。因此在使用一些时间复杂度为O(N)的命令时要非常谨慎。可能一不小心就会阻塞进程，导致Redis出现卡顿。

Redis作为一个成熟的数据存储中间件，它提供了完善的数据管理功能，比如之前我们提到过的数据过期和今天我们要讲的数据淘汰(evict)策略。

很多小伙伴都跟我说，redis中，ZSet（有序集合）是他们最陌生的集合，同时也是觉得特别复杂的集合之一，在开发过程中经常会用到它，而且也是大家最不太有把握使用的集合，所以笔者就从ZSet集合开始去讲解Redis的集合的使用指南，希望可以帮助大家！有序集合（ZSet）：它是一个存储着成员（member）本身对象值以及和它对应的分值（score）的键值对，并且按照分值从小到大自动排序。对应的具体的数据结构，有序集合的键被称为成员（member）每个成员各不相同。

默认情况下，Sentinel运行侦听到TCP端口26379的连接，因此要使Sentinel正常工作，服务器的端口26379必须打开，才能从其他Sentinel实例的IP地址接收连接。实际上，这意味着使用Sentinel可以创建一个Redis部署，在没有人为干预的情况下抵抗某些类型的故障。新的开发是在不稳定的分支中执行的，新的特性有时在被认为是稳定的时候就被移植到最新的稳定分支中。当前版本的Sentinel称为Sentinel 2，是对最初的Sentinel实现的重写，使用了更强、更简单的预测算法。

Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主备切换，而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动切换。Redis从 2.8发布了一个稳定版本的Redis Sentinel。当前版本的 Sentinel称为Sentinel 2。