皮皮网

1.【Azure Redis 码调缓存】使用开源工具redis-copy时遇见6379端口无法连接到Redis服务器的问题
2.Redisson限流器RRateLimiter使用及源码分析
3.Java响应式编程 第十一篇 WebFlux集成Redis
4.第七篇：实战redis-operator
5.RedisTemplate：我不背锅，是码调你用错了
6.Redis参数设置

【Azure Redis 缓存】使用开源工具redis-copy时遇见6379端口无法连接到Redis服务器的问题

       当使用Azure Redis服务时，数据迁移需求促使寻找替代方案。码调直接导入/导出RDB文件受限于服务等级，码调转而使用开源工具Redis-Copy实现数据迁移。码调然而，码调奇幻射击源码在尝试使用该工具时，码调遇到了无法连接到Redis服务器的码调问题，尤其是码调针对端口的连接失败。

       Redis-Copy工具默认使用端口，码调此端口连接失败表明问题可能出在工具配置上。码调通过对比Redis-cli.exe工具的码调正常连接，可以初步判断问题与端口选择及SSL设置有关。码调

       深入分析，码调发现Redis-Copy工具在连接过程中未正确处理SSL参数值，码调导致尝试使用SSL方式连接非SSL端口。在调试源码时，定位到CommandLine.Parser.Default.ParseArguments(args)代码，发现其在转换bool类型参数时存在问题，无论实际值为何，均被错误地转换为true。

       为解决此问题，可采取两种方案。方案一：修改Options.cs文件，将SourceSSL和DestinationSSL的默认值设为False，同时在命令行中通过--sssl和--dssl参数指定需要使用SSL连接。方案二：修改SourceSSL和DestinationSSL类型为String，在初始化Redis连接字符串时进行类型转换。

       采用任一方案后，需要重新编译生成的exe文件。然后根据目标端口选择相应的命令行参数。对于端口连接，命令为：redis-copy.exe --se xxxx --sa **** --sp --de xxxx --da **** --dp ；对于端口连接，则命令调整为：redis-copy.exe --se xxxx --sa **** --sp --sssl true --de xxxx --da **** --dp --dssl true。

       通过这些步骤，可以解决使用Redis-Copy工具连接Azure Redis服务器时遇到的端口连接问题。重要的是，当在复杂环境中面临技术挑战时，保持冷静分析，逐步排查问题原因，最终找到解决方案。

Redisson限流器RRateLimiter使用及源码分析

       Redisson限流器RRateLimiter使用及源码分析

       在项目中引入Redisson限流器RRateLimiter，通过以下步骤实现限流功能。首先使用Redis命令将限流的贵阳智慧农业源码配置信息保存在Redis中，具体代码如下：

       执行`hsetnx testRedissonRateLimiter rate `，设置限流次数为，`testRedissonRateLimiter`为自定义的键名。

       执行`hsetnx testRedissonRateLimiter interval `，设置限流时间，单位为毫秒。

       执行`hsetnx testRedissonRateLimiter type 0`，设置限流类型，枚举值为RateType.OVERALL。

       将配置信息保存于Redis的HashMap结构中，使用`hsetnx`确保设置成功。然后判断是否超过限流次数。

       通过`getValueName()`方法获取限流配置，进一步调用`tryAcquire()`方法检查是否超过限流次数。Lua脚本返回`nil`代表未超过限流，若有值则已超过限流。`pttl`命令始终返回值，即使用于不存在的键。

       使用`getConfig()`方法获取所有限流配置信息，执行`delete()`方法清除限流配置。值得注意的是，Redisson在删除限流配置时存在一个BUG，仅删除了`testRedissonRateLimiter`键，未清理`{ testRedissonRateLimiter}:value`键，影响判断请求是否超过限流次数。此问题于年2月日::被发现，Redisson版本为3..7。

       为了验证限流功能，调试时逐步执行代码，同时观察Redis服务器命令监控，确保限流功能按预期运行。

Java响应式编程 第十一篇 WebFlux集成Redis

       在现代的分布式系统中，缓存是提高性能和扩展性的关键因素之一。Redis，作为一个开源的内存数据结构存储系统，不仅可以作为数据库，还可以作为缓存和消息中间件。WebFlux，作为Spring框架提供的响应式编程模型，在处理高并发和大数据量方面表现出色。

       本文将探讨如何使用Reactor和WebFlux与Redis集成，利用其响应式特性来执行缓存操作。

       首先，ios开源软件源码我们需要在项目的pom.xml文件中引入Spring WebFlux和Spring Data Redis的依赖项。

       然后，在application.properties文件中配置Redis的连接信息。

       在配置类中创建一个RedisCacheManager以管理缓存，并在其中使用RedisCacheConfiguration配置缓存的默认过期时间、键和值的序列化方式。

       接下来，定义一个Service类来处理缓存操作。使用Spring框架的缓存注解来定义缓存逻辑，如@Cacheable用于读取缓存，@CachePut用于更新缓存，@CacheEvict用于清除缓存。同时，使用ReactiveRedisOperations执行Redis操作。

       编写WebFlux控制器以处理请求，使用@GetMapping、@PostMapping和@DeleteMapping映射URL，并调用UserService中的相应方法处理业务逻辑。

       在集成过程中可能会遇到错误或异常，例如无法连接到Redis服务器或Redis命令执行失败。通过使用Spring的全局异常处理器（@ControllerAdvice）或Reactor的操作符（如onErrorResume）来处理异常，可以提高系统的健壮性和可靠性。

       根据具体需求和环境，可能还会遇到其他问题。但通过研究和调试，您应该能够成功集成WebFlux和Redis，并实现预期的功能和效果。

       本文介绍了如何利用Reactor和WebFlux与Redis集成来处理缓存操作。通过使用ReactiveRedisOperations和Spring框架的缓存注解，我们可以方便地实现响应式的缓存逻辑，提高系统的性能和扩展性，尤其适用于高并发和大数据量的场景。

第七篇：实战redis-operator

       实战调试、修改、编译、打包Redis Operator，以GitHub - spotahome/redis-operator为例。spotahome/redis-operator源码逻辑简洁，仅支持哨兵集群模式，主要逻辑位于cmd/redisoperator/main.go。

       若需根据实际业务修改operator，可通过在api/redisfailover/v1目录下添加字段，执行make generate-crd命令，动力飞轮指标源码即可在manifests目录生成新的yaml文件。

       镜像打包涉及Dockerfile和build.sh的修改，原设置采用docker buildx，旨在生成兼容不同操作系统的镜像。然而实践操作中常遇失败，鉴于实际场景无需支持多种操作系统，仅需为centos、redhat等AMD系统打包镜像即可。因此，调整Dockerfile和build.sh以适应上述需求。

RedisTemplate：我不背锅，是你用错了

       RedisTemplate的使用问题，探讨原因与解决方案。

       观察问题，发现使用RedisTemplate获取不到值。首先怀疑RedisTemplate与StringRedisTemplate使用的Connection不同。经确认，使用的是同一Connection，问题可能出在代码逻辑或序列化方式上。

       通过调试源码，发现在Redis客户端BinaryJedis的hget方法中，Redis并未返回数据。分析问题，发现是RedisTemplate默认使用了JDK序列化，与StringRedisTemplate的数据格式不匹配。

       进一步对比StringRedisTemplate与RedisTemplate的关系，发现StringRedisTemplate专门用于字符串操作，而RedisTemplate用于复杂对象操作，主要区别在于序列化方式不同。

       通过redis客户端查看数据格式，发现存储的是字符串格式的Hash。使用StringRedisTemplate能获取数据的原因，可能是存储时使用了StringRedisTemplate。而RedisTemplate默认使用JDK序列化，导致数据格式不匹配，无法获取。

       调整RedisTemplate的序列化方式，将其从JDK序列化改为与StringRedisTemplate一致的字符串序列化方式。重新运行测试，发现仍然无法获取数据。查看RedisTemplate对象信息，发现虽然valueSerializer已更改为一致，但hash序列化仍使用了JDK序列化。usdr矿机源码

       为了确保一致性，将所有序列化方式统一设置为一致的字符串序列化。修改后，成功获取到了数据。个人认为，这主要是由于使用RedisTemplate时对默认序列化方式的理解不足，导致了问题的出现。

       仔细阅读源码，可以发现StringRedisTemplate与RedisTemplate在序列化方式上的区别，即StringRedisTemplate默认为所有操作设置了String序列化方式，而RedisTemplate默认使用JDK序列化。理解这些差异，有助于正确使用这两个类，并避免类似问题。

Redis参数设置

       Redis的高效运行离不开合理的参数配置。以下是几个关键方面的建议，以确保最佳性能:

内存优化: 优化内存管理是提升Redis性能的重要步骤。确保设置合适的`maxmemory`值，以限制存储的键值对数量，避免内存溢出。

持久化配置: 配置`save`指令以定期将数据写入磁盘，避免数据丢失。选择合适的持久化策略（如RDB或AOF）以平衡性能和数据完整性。

网络配置: 调整`tcp-backlog`以提高连接接纳能力，设置`tcp_keepalive`以保持长连接的稳定性。合理设置`bind`和`protected-mode`以控制服务器的网络访问范围。

并发配置: 通过`client-output-buffer-limit`控制输出缓冲，防止阻塞连接。设置`maxclients`限制同时连接数，防止服务器资源过度消耗。

日志配置: 确保`loglevel`设置为合适的级别，以避免过多的日志记录影响性能。同时，合理配置`logfile`和`syslog-enabled`以记录错误和调试信息。

       特别值得注意的是，为了防止僵尸连接浪费资源，务必设置`timeout=`，这有助于及时清理无响应的连接请求，保证服务的正常响应速度。

redis源码解读（一）：事件驱动的io模型，为什么，是什么，怎么做

       Redis作为一个高性能的内存数据库，因其出色的读写性能和丰富的数据结构支持，已成为互联网应用不可或缺的中间件之一。阅读其源码，可以了解其内部针对高性能和分布式做的种种设计，包括但不限于reactor模型（单线程处理大量网络连接），定时任务的实现（面试常问），分布式CAP BASE理论的实际应用，高效的数据结构的实现，其次还能够通过大神的代码学习C语言的编码风格和技巧，让自己的代码更加优雅。

       下面进入正题：为什么需要事件驱动的io模型

       我们可以简单地将一个服务端程序拆成三部分，接受请求->处理请求->返回结果，其中接收请求和处理请求便是我们常说的网络io。那么网络io如何实现呢，首先我们介绍最基础的io模型，同步阻塞式io，也是很多同学在学校所学的“网络编程”。

       使用同步阻塞式io的单线程服务端程序处理请求大致有以下几个步骤

       其中3,4步都有可能使线程阻塞（6也会可能阻塞，这里先不讨论）

       在第3步，如果没有客户端请求和服务端建立连接，那么服务端线程将会阻塞。如果redis采用这种io模型，那主线程就无法执行一些定时任务，比如过期key的清理，持久化操作，集群操作等。

       在第4步，如果客户端已经建立连接但是没有发送数据，服务端线程会阻塞。若说第3步所提到的定时任务还可以通过多开两个线程来实现，那么第4步的阻塞就是硬伤了，如果一个客户端建立了连接但是一直不发送数据，服务端便会崩溃，无法处理其他任何请求。所以同步阻塞式io肯定是不能满足互联网领域高并发的需求的。

       下面给出一个阻塞式io的服务端程序示例：

       刚才提到，阻塞式io的主要问题是，调用recv接收客户端请求时会导致线程阻塞，无法处理其他客户端请求。那么我们不难想到，既然调用recv会使线程阻塞，那么我们多开几个几个线程不就好了，让那些没有阻塞的线程去处理其他客户端的请求。

       我们将阻塞式io处理请求的步骤改造下：

       改造后，我们用一个线程去做accept，也就是获取已经建立的连接，我们称这个线程为主线程。然后获取到的每个连接开一个新的线程去处理，这样就能够将阻塞的部分放到新的线程，达到不阻塞主线程的目的，主线程仍然可以继续接收其他客户端的连接并开新的线程去处理。这个方案对高并发服务器来说是一个可行的方案，此外我们还可以使用线程池等手段来继续优化，减少线程建立和销毁的开销。

       将阻塞式io改为多线程io：

       我们刚才提到多线程可以解决并发问题，然而redis6.0之前使用的是单线程来处理，之所以用单线程，官方给的答复是redis的瓶颈不在cpu，既然不在cpu那么用单线程可以降低系统的复杂度，避免线程同步等问题。如何在一个线程中非阻塞地处理多个socket，进而实现多个客户端的并发处理呢，那就要借助io多路复用了。

       io多路复用是操作系统提供的另一种io机制，这种机制可以实现在一个线程中监控多个socket，返回可读或可写的socket，当一个socket可读或可写时再去操作它，这样就避免了对某个socket的阻塞等待。

       将多线程io改为io多路复用：

       什么是事件驱动的io模型（Reactor）

       这里只讨论redis用到的单线程Reactor模型

       事件驱动的io模型并不是一个具体的调用，而是高并发服务器的一种抽象的编程模式。

       在Reactor模型中，有三种事件：

       与这三种事件对应的，有三种handler，负责处理对应的事件。我们在一个主循环中不断判断是否有事件到来（一般通过io多路复用获取事件），有事件到来就调用对应的handler去处理时间。

       听着玄乎，实际上也就这一张图：

       事件驱动的io模型在redis中的实现

       以下提及的源码版本为 5.0.8

       文字的苍白的，建议参照本文最后的方法下载代码，自己调试下

       整体框架

       redis-server的main方法在 src/server.c 最后，在main方法中，首先进行一系列的初始化操作，最后进入进入Reactor模型的主循环中：

       主循环在aeMain函数中，aeMain函数传入的参数 server.el ，是一个 aeEventLoop 类型的全局变量，保存了主循环的一些状态信息，包括需要处理的读写事件、时间事件列表，epoll相关信息，回调函数等。

       aeMain函数中，我们可以看到当 eventLoop->stop 标志位为0时，while循环中的内容会被重复执行，每次循环首先会调用beforesleep回调函数，然后处理时间。beforesleep函数在main函数中被注册，会进行集群状态更新、AOF落盘等任务。

       之所以叫beforesleep，是因为aeProcessEvents函数中包含了获取事件和处理事件的逻辑，其中获取读写事件时通过epoll_wait实现，会将线程阻塞。

       在aeProcessEvents函数中，处理读写事件和时间事件，参数flags定义了需要处理的事件类型，我们可以暂时忽略这个参数，认为读写时间都需要处理。

       aeProcessEvents函数的逻辑可以分为三个部分，首先获取距离最近的时间事件，这一步的目的是为了确定epoll_wait的超时时间，并不是实际处理时间事件。

       第二个部分为获取读写事件并处理，首先调用epoll_wait，获取需要处理的读写事件，超时时间为第一步确定的时间，也就是说，如果在超时时间内有读写事件到来，那么处理读写时间，如果没有读写时间就阻塞到下一个时间事件到来，去处理时间事件。

       第三个部分为处理时间事件。

       事件注册与获取

       上面我们讲了整体框架，了解了主循环的大致流程。接下来我们来看其中的细节，首先是读写事件的注册与获取。

       redis将读、写、连接事件用结构aeFileEvent表示，因为这些事件都是通过epoll_wait获取的。

       事件的具体类型通过mask标志位来区分。aeFileEvent还保存了事件处理的回调函数指针（rfileProc、wfileProc）和需要读写的数据指针（clientData）。

       既然读写事件是通过epoll io多路复用实现，那么就避不开epoll的三部曲 epoll_create epoll_ctrl epoll_wait，接下来我们看下redis对epoll接口的封装。

       我们之前提到aeMain函数的参数是一个 aeEventLoop 类型的全局变量，aeEventLoop中保存了epoll文件描述符和epoll事件。在aeApiCreate函数（src/ae_epoll.c）中，会调用epoll_create来创建初始化epoll文件描述符和epoll事件，调用关系为 main -> initServer -> aeCreateEventLoop -> aeApiCreate

       调用epoll_create创建epoll后，就可以添加需要监控的文件描述符了，需要监控的情形有三个，一是监控新的客户端连接连接请求，二是监控客户端发送指令，也就是读事件，三是监控客户端写事件，也就是处理完了请求写回结果。

       这三种情形在redis中被抽象为文件事件，文件事件通过函数aeCreateFileEvent（src/ae.c）添加，添加一个文件事件主要包含三个步骤，通过epoll_ctl添加监控的文件描述符，指定回调函数和指定读写缓冲区。

       最后是通过epoll_wait来获取事件，上文我们提到，在每次主循环中，首先根据最近到达的时间事件来计算epoll_wait的超时时间，然后调用epoll_wait获取事件，再处理事件，其中获取事件在函数aeApiPoll（src/ae_epoll.c）中。

       获取到事件后，主循环中会逐个调用事件的回调函数来处理事件。

       读写事件的实现

       写累了，有空补上……

       如何使用vscode调试redis源码

       编译出二进制程序

       这一步有可能报错：

       jemalloc是内存分配的一种更高效的实现，用于代替libc的默认实现。这里报错找不到jemalloc，我们只需要将其替换成libc默认实现就好：

       如果报错：

       我们可以在src目录找到一个脚本名为mkreleasehdr.sh，其中包含创建release.h的逻辑，将报错信息网上翻可以发现有一行：

       看来是这个脚本没有执行权限，导致release.h没有成功创建，我们需要给这个脚本添加执行权限然后重新编译：

       2. 创建调试配置（vscode）

       创建文件 .vscode/launch.json，并填入以下内容：

       然后就可以进入调试页面打断点调试了，main函数在 src/server.c

Redis | Lua脚本

       Redis通过其内置的Lua脚本功能，极大地扩展了其功能范围。这些脚本主要通过以下几个命令实现：EVAL和EVALSHA，前者用于执行脚本，后者则是针对预先缓存的脚本。在执行过程中，lua.call()和lua.pcall()的区别在于错误处理策略，前者会返回错误信息，而后者会封装错误并返回。通过SCRIPT LOAD命令，开发者可以将自定义脚本存储在服务器中，然后使用EVALSHA来执行。

       管理脚本的其他工具包括SCRIPT EXISTS检查脚本缓存状态，SCRIPT FLUSH用于清除所有缓存，而遇到超时情况，SCRIPT KILL则允许终止执行中的脚本。Redis的Lua环境还内置了丰富的函数库，如redis.log()用于写入日志，redis.shalhex()计算SHA1校验和，以及处理错误和状态的函数。

       此外，bit包提供了bit.tohex()将数字转换为进制字符串的功能，struct包用于Lua值和C结构间的转换，struct.pack()打包值，struct.unpack()解包。cjson和cmsgpack则支持快速的JSON和MessagePack操作。调试方面，Lua脚本支持step和next命令，以及查看局部变量，断点设置和执行continue，动态断点有助于调试条件和循环。

       Redis调试器提供了eval和redis命令，可以执行脚本，并通过trace查看调用链。例如，Lua脚本可以用于实现带身份验证的锁，如LPOPRPUSH命令，展示了Lua脚本在实际场景中的应用。