九师兄

我们知道hgetAll的性能是极差的，然后我们优化成hkeys的，但是hkeys真的好吗？下面我们来说一下我们的现场，就是现场我们改成hkeys之后，发现在Flink打规模并行度的时候，这个方法会报错，然后导致redis整体不可用。然后我们研究了一下，建议使用hscan，下面我们来测试一下性能。

自定义目录：/myredis/redis.conf。

本章节主要讲解redis中的红锁，假设我们有个客户端要获取锁，然后向master去获取锁，然后master会把锁同步到slave节点，假设现在还没同步出去的时候,master节点挂了。然后从节点升级为主节点，然后另外一个刚刚在竞争锁失败处于阻塞状态的线程去获取锁的时候，但是新的master上，并没有锁的信息，然后就能拿到锁，此时就可能导致一些问题。此时我们就能使用红锁，来解决这个问题。一个客户端要向多个master节点发送加锁请求。只有半数的锁加锁成功，才是获取锁。

Redis哨兵机制和集群有什么区别？redis集群有几种实现方式，一个是主从集群，一个是redis cluster.

在Redis中，大key是指存储了大量数据的键。处理大key可能会对Redis服务器的性能和资源消耗产生负面影响。询问这个问题，首先要知道redis的大key会有什么影响。大key占用的内存空间较大，当大量的大key存在时，会消耗大量的内存资源。这可能导致Redis服务器的内存不足，并触发内存溢出，从而影响系统的稳定性和性能。当读取或写入大key时，需要将大量的数据通过网络传输。对于大量的网络传输，特别是在高并发的情况下，会增加整体的延迟，并占用带宽资源。

如果需要根据某种模式来获取键，更好的选择是使用更高效的命令，如SCAN命令，它使用游标方式迭代返回匹配的键，避免了遍历整个键空间的性能问题，并且可以逐步处理数据。KEYS命令用于检索匹配指定模式的所有键。如果匹配的键非常多，返回的结果列表可能巨大无比，占用大量的内存。在极端情况下，如果执行KEYS命令返回的结果集非常大，并且内存不足以容纳整个结果集，Redis服务器可能会发生内存溢出错误。如果KEYS命令运行时间较长或遇到大量匹配的键，会导致服务器长时间无法响应其他请求，从而对系统的可用性产生负面影响。

为了避免子进程在重写过程过程中，主进程中的数据发生变化，导致AOF文件里面的数据和redis内存中的数据不一致，redis中还做了一个优化，也就是说在子进程在做这个重写的过程中，主进程中的数据变更，需要追加到AOF的重写缓冲区中，等到AOF重写完成以后，再把AOF重写缓冲区的数据，追加到新的AOF文件里面，这样意料就能保证新的AOF文件里面的数据和当前Redis中的数据保持一致。子进程在进行重写的过程中，主进程依然可以去处理客户端的一个请求，这样一来子进程在重写的过程中，不耽误客户端的使用。

对网络同学开销的平衡：redis集群中的每个节点，会发送心跳消息，而心跳包中会携带节点的完整配置，他能够以幂等的方式来实现配置的更新。但是修改集群的槽位数量需要进行数据迁移和重新均衡，会对集群产生较大的影响，因此一般情况下建议使用默认的 16384 个槽位。可用性和容错性：16384 是一个较大的数字，可以提供足够的槽位数量来分布数据，从而提高集群的可用性和容错性。应用程序去存储一个key的时候会通过，对key进行一个CRC16去计算，再取模，然后路由到hash slot所在的节点。

Redis 实现后台快照的方式非常巧妙，通过操作系统提供的 fork 和写时拷贝的特性轻而易举的就实现了这个功能，从这里我们就能看出作者对于操作系统知识的掌握还是非常扎实的，大多人在面对类似的场景时，想到的方法可能就是手动实现类似『写时拷贝』的特性，然而这不仅增加了工作量，还增加了程序出现问题的可能性。通过 fork 创建的子进程能够获得和父进程完全相同的内存空间，父进程对内存的修改对于子进程是不可见的，两者不会相互影响；

此 demo 主要演示了 Spring Boot 项目如何通过 AOP 结合 Redis + Lua 脚本实现分布式限流，旨在保护 API 被恶意频繁访问的问题，是的升级版。

ZSET可以简单的理解为带权重的集合；与前面的set最大的区别，就是每个元素可以设置一个score，从而可以实现各种排行榜的功能。

Redis的五大数据结构，前面讲述了String和List,Hash的使用姿势，接下来就是Set集合，与list最大的区别就是里面不允许存在重复的数据。

Redis的五大数据结构，前面讲述了String和List的使用姿势，而Hash数据结构，也是比较常用的，接下来看下hash数据结构的读取，删除，塞入的基本使用姿势增删改查代码如下。

redis列表使用如下。

【Spring】Spring redis key/value 出现乱码\xAC\xED\x00\x05t\x00\x05

Redis目前常用的存储结构有五种，String字符串，List列表，Set集合，Hash散列，ZSet有序集合；本篇则主要集中在String这个数据结构的读写操作之上对于String的操作，除了常见的get/set之外，还有一些比较有特色的功能，如用于实现redis分布式锁的setnx/getset方法；用于实现计数的incr/decr方法；位图算法的经典实用场景之bitmap的使用方法等也有必要了解一下。

redis-cli连接服务器。最后的cmd是执行的命令类型。

合理的JedisPool资源池参数设置能为业务使用Redis保驾护航，本文将对JedisPool的使用、资源池的参数进行详细说明，最后给出“最合理”配置。

本篇文章是对下面两个文章的一点点补充。

觉得写的好，收集一下，便于自己查找。在大数据高并发场景下，单个 Redis 实例往往会显得捉襟见肘。首先体现在内存上，单个 Redis 的内存不宜过大，内存太大会导致 rdb 文件过大，进一步导致主从同步时全量同步时间过长，在实例重启恢复时也会消耗很长的数据加载时间，特别是在云环境下，单个实例内存大小往往都是受限的。其次体现在 CPU 的利用率上，单Redis 实例只能利用单个核心，这单个核心要完成海量数据的存取和管理工作，压力会非常大。

主要是方便自己查找，建议大家去看原文。Redis集群是Redis提供的分布式数据库方案， 集群通过分片（sharding） 来进行数据共享， 并提供复制和故障转移功能。

选 项，让一个服务器去复制(replicate)另一个服务器，我们称呼被复制 的服务器为主服务器(master)，而对主服务器进行复制的服务器则被 称为从服务器(slave)，如图所示。那么服务器127.0.0.1:12345将成为127.0.0.1:6379的从服务器，而服 务器127.0.0.1:6379则会成为127.0.0.1:12345的主服务器。主要是方便自己查找，建议大家去看原文。在Redis中，用户可以通过执行。

主要是方便自己查找，建议大家去看原文。通过执行MONITOR命令，客户端可以将自己变为一个监视器，实每当一个客户端向服务器发送一条命令请求时，服务器除了会处理 这条命令请求之外，还会将关于这条命令请求的信息发送给所有监视 器，如图所示。

主要是方便自己查找，建议大家去看原文。Redis的慢查询日志功能用于记录执行时间超过给定时长的命令请求，用户可以通过这个功能产生的日志来监视和优化查询速度。举个例子，如果这个选项的值为100，那么执行时间超过100微秒的 命令就会被记录到慢查询日志;如果这个选项的值为500，那么执行时 间超过500微秒的命令就会被记录到慢查询日志。

主要是方便自己查找，建议大家去看原文。Redis通过等命令来实现事务 (transaction)功能。事务提供了一种将多个命令请求打包，然后一次 性、按顺序地执行多个命令的机制，并且在事务执行期间，服务器不会 中断事务而改去执行其他客户端的命令请求，它会将事务中的所有命令 都执行完毕，然后才去处理其他客户端的命令请求。

主要是方便自己查找，建议大家去看原文。一个Redis服务器从启动到能够接受客户端的命令请求，需要经过 一系列的初始化和设置过程，比如初始化服务器状态，接受用户指定的 服务器配置，创建相应的数据结构和网络连接等等。

主要是方便自己查找，建议大家去看原文。Redis服务器是典型的一对多服务器程序:一个服务器可以与多个 客户端建立网络连接，每个客户端可以向服务器发送命令请求，而服务 器则接收并处理客户端发送的命令请求，并向客户端返回命令回复。通过使用由I/O多路复用技术实现的文件事件处理器，Redis服务器 使用单线程单进程的方式来处理命令请求，并与多个客户端进行网络通 信。对于每个与服务器进行连接的客户端，服务器都为这些客户端建立 了相应的。

主要是方便自己查找，建议大家去看原文。在本章之前的内容中，我们介绍了Redis服务器保存和载入RDB文 件的方法，在这一节，我们将对RDB文件本身进行介绍，并详细说明文 件各个部分的结构和意义。图展示了一个完整RDB文件所包含的各个部分。为了方便区分变量、数据、常量，图10-10中用全大写单词标示常 量，用全小写单词标示变量和数据。本章展示的所有RDB文件结构图都 遵循这一规则。RDB文件的最开头是REDIS部分，这个部分的长度为5字节，保存 着“REDIS”五个字符。

延时队列可以通过 Redis 的zset（有序列表）来实现。我们将消息序列化成一个字符串作为zset 的value，这个消息的到期处理时间作为 score，然后用多个线程轮询zset 获取到期的任务进行处理。多个线程是为了保障可用性，万一挂了一个线程还有其他线程可以继续处理。因为有多个线程，所以需要考虑并发争抢任务，确保任务不会被多次执行。

主要是方便自己查找，建议大家去看原文。在这一节，我们将探讨过期键对Redis服务器中其他模块的影响， 看看RDB持久化功能、AOF持久化功能以及复制功能是如何处理数据库 中的过期键的。

仅供自己翻阅查询，建议看原文。Redis 早期版本存储 list 列表数据结构使用的是压缩列表 ziplist 和普通的双向链表 linkedlist，也就是说当元素少时用 ziplist，当元素多时用 linkedlist。考虑到链表的附加空间相对太高， prev 和 next 指针就要占去 16 个字节( 64 位 操作系统的指针占 8 个字节)，另外每个节点的内存都是单独分配，会加剧内存的 碎片化，影响内存管理效率。

摘自:仅供自己学习，方便查找，建议看原文。前面讲了 Redis懒惰删除的特性，它是使用异步线程对已删除的节点进行内 存回收。但讲得还不够深入，所以本节要对异步线程逻辑处理的细节进行分析， 看看 Antirez 是如何实现异步线程处理的。异步线程在 Redis 内部有一个特别的名称，就是“BIO”，全称是 Background IO，意思是在。不过内存回收本身并不是什么 IO 操作，只 是 CPU 的计算消耗可能会比较大而已。

摘自:仅供自己学习，方便查找，建议看原文。所以就像看看这三个有什么区别，已经redis中使用的是不是这样的。在第，我们讲到了 Redis 的 LRU 模式，它可以。Antirez 在 Redis 4.0 里引人了一个新的淘汰策略一一LFU 模式，老钱认为它比 LRU 更加优秀。LFU 的全称是 Least Frequently Used，。如果一个 key 长时间不被访问，只是刚刚偶然被用户访问了一下，那么在 LRU 算法下，它是不容易被淘汰的，因为 LRU 算法认为这个 key 是很“热”的。

1.概述仅供自己翻阅查询，建议看原文。， 它是对ziplist结构的改进版， 在存储空间上会更加节省，而且结构上也比 ziplist更精筒。listpack的整体形式和 ziplist 还是比较接近的，如果你认真阅读了 ziplist的内部结构分析， 那么对于listpack 也是比 较容易理解的。图 所示是紧 凑列表的 内部结构示意 图。首先，只是少了一个 zltail_offset 字段。

仅供自己翻阅查询，建议看原文。Redis 的 zset 是一个复合结构，如图所示，一方面它需要一个 hash 结构来 存储 value 和 score 的对应关系，另 一方 面需要提供按照 score 排序的功能，还需要能 够指定 score 的范围来获取 value 列表的功能，这就需要另外一个结构“跳跃列表“。。hash 结构，它很像 Java语言中的 HashMap 结构。本节我们来讲跳 跃列表，它比较复杂，读者要有心理准备。

仅供自己翻阅查询，建议看原文。Redis 为了节约内存空间使用， zset和hash 容器对象在元素个数较少的时候，采用压缩列表（ ziplist ）进行存储。压缩列表是一块连续的内存空间，元素之间紧接着存储，没有任何冗余空隙。这里，注意观察 debug object 输出的 encoding 字段都是 ziplist ，这就表示内部采用压缩列表结构进行存储。图所示是压缩列表的内部结构示意图。

仅供自己翻阅查询，建议看原文。没法设置转载，侵权可删，仅供自己学习。字典是 Redis 服务器中出现最为频繁的复合型数据结构，除了 hash 结构的数据会用到字典（ dict ）外，整个 Redis 数据库的所有 key value 也组成了一个全局字典，还有带过期时间的 key 集合也是一个字典。zset 集合中存储 value score 值的映射关系也是通过字典结构实现的。

仅供自己翻阅查询，建议看原文。。我们知道 语言里面的字符串标准形式是以 NULL （即0x\0）作为结束待，但是在Redis 里面，字符串不是这么表示的。因为要获取以 NULL 结尾的字符串的长度使用的是 strlen 标准库函数，这个函数的算法复杂度是O(n)时，它需要对字节数组进行遍历扫描，作为单线程的 Redis 表示承受不起。Redis 的字符串叫着“ SDS ”，也就是 Simple Dynamic String。它的结构是一个带长度信息的字节数组。

摘自:仅供自己学习，方便查找，建议看原文。

Redis Cluster 的客户端来连接集群时，也会得到一份集群的槽位配置信息这样当客户端要查找某个 key 时，可以直接定位到目标节点。客户端为了可以直接定位某个具体的 key 所在的节点，需要缓存槽位相关信息，这样才可以准确快速地定位到相应的节点。，如图 所示，该集群由三个Redis 节点组成，每个节点负责整个集群的一部分数据，每个节点负责的数据多少可能不一样。，每个节点负责其中－部分槽位。槽位的信息存储于每个节点中，它不像Codis ，不需要另外的分布式存储空间来存储节点槽位信息。