redis

Redis 系列（一）：全景与最小闭环——从 `SET` 命令到内存数据结构核心目标：理解 Redis 解决什么、不解决什么；看懂"客户端 → RESP 协议 → 事件循环 → 数据结构"的命令执行链路；用 redis-py 完成一次可观察、可验证的最小读写，并亲手触发类型错误与连接失败两类异常。

当 Redis 写入成为性能瓶颈时，如何利用异步批量 Sink 将吞吐量从 1w QPS 提升到 10w+？在上一篇文章中，我们解决了“高可用”问题——通过 Sentinel 让 Flink 任务在 Redis 主从切换时自动恢复。但高可用解决了“活下来”的问题，却未必解决“活得快”的问题。

Redis 系列（六）：过期、内存淘汰与内存优化——让 Redis 活得更久核心目标：理解 TTL 过期删除的两种机制（惰性 + 定期）及其代价；掌握 maxmemory 八种淘汰策略的语义与选型；会用 MEMORY USAGE/MEMORY DOCTOR/--bigkeys/INFO memory 定位大 key 与内存问题；理解"淘汰导致的缓存雪崩"风险。

Redis 系列（七）：事务、Pipeline 与 Lua 脚本——从原子性到 Functions核心目标：区分 Redis 事务与关系型数据库事务；理解 Pipeline 的性能收益与边界；用 Lua 脚本实现真正原子的复合操作；了解 Redis 7 Functions 的定位。用秒杀扣库存贯穿三种工具。

Redis 系列（八）：缓存设计模式与一致性——从 Cache Aside 到防雪崩核心目标：掌握 Cache Aside 等主流缓存模式；理解"先删缓存还是先更新库"的时序窗口；用真实实验复现缓存不一致、击穿重建风暴与穿透；能设计带防护的缓存架构。

当 Redis 写入不再是瓶颈后，Flink 任务的反压可能来自哪里？如何系统性地定位和解决 Flink 反压问题？经过前面几篇文章的改造，你的 Flink 作业已经实现了：Sink 不再是瓶颈了，但任务可能依然跑不动。

服务端高并发分布式结构演进之路在介绍Redis之前，还是先来介绍一下服务端⾼并发分布式结构演进之路。首先了解一下基础的概念1.应用/系统

Redis 系列（三）：底层实现（一）——对象系统、SDS 与 dict核心目标：理解 RedisObject 对象系统与 String/Hash 的底层结构；用源码与实验解释"10 字节的键为什么占 55 字节内存"、“为什么数据多了会偶发卡顿”（渐进式 rehash）；掌握 OBJECT ENCODING/MEMORY USAGE 两类观察手段。

当 Redis 集群发生主从切换（Failover）时，Flink 任务会崩溃吗？如何利用 Sentinel 实现高可用？在上一篇文章中，我们基于 FlinkJedisPoolConfig 构建了一个可运行的 Flink Redis Sink。但生产环境从来不是“能跑就行”——当 Redis 单节点宕机时，整个 Flink 任务会直接崩溃，因为连接池配置的 localhost:6379 已经不可用了。

海上小飞龙

Redis 分布式锁原理：从 SET NX EX 到 Redisson 看门狗Redis 给了个 setNX，名字拆开就是 set if not exists——只有 key 不存在才写进去。

万物皆字节

【避坑】使用CacheEvict需要注意的坑在使用spring cache的时候，如果对注解类型使用不当、并发情况没有很好的了解的情况下，可能会造成生产的故障；

如何通过Linux命令自动切割nginx和redis日志生产环境随着业务的持续执行，nginx日志【access.log】或redis日志【redis.log】文件会越来越庞大，处理不及时会导致系统告急。本文分享如何用Linux命令自动切割日志和清理旧日志。

范什么特西

回答知识总结04（redis）1、redis为什么这么快Redis 基于内存操作，采用 IO 多路复用，命令执行单线程规避锁竞争，搭配高度优化的数据结构，因此性能极高。

Redis学习笔记：Cluster 集群读写分离实战，Lettuce + Spring Boot 从配置到验证📝 本文首发于栏轩·阁欢迎访问阅读原文，获取更好的阅读体验。Redis Cluster 采用分片架构，将 16384 个 hash slot 均分到各个 master 节点。默认情况下，所有读写请求都路由到 slot 对应的 master 节点。这意味着你的 replica 节点只在 master 宕机时被动接管，平时完全空转——而你却为它们支付着同等的内存和 CPU 成本。

Redis02:库切换、监控与安全配置目录4.redis的不同库切换和运维监控命令Redis 不同数据库的切换查看 key监控命令Info 常用信息说明（Zabbix 监控参考）

海上小飞龙

Redis 持久化：RDB 与 AOFRedis 虽然快，但它的数据主要存储在内存中，而内存属于易失性存储介质。一旦断电或者服务重启，如果没有持久化机制，数据就可能丢失。

redis中AOF 重写机制解析AOF（Append Only File）持久化机制通过记录所有写命令来保证数据安全，但随之而来的问题是：随着运行时间增长，AOF 文件会不断膨胀。假设你反复对一个 key 执行 INCR 操作 1000 次，AOF 文件中会记录 1000 条 INCR 命令，但恢复时只需要一条 SET key 1000 即可。这就是 AOF 重写的价值所在。AOF 重写的核心目标就是将 AOF 文件重写为包含相同数据集的最小命令集，从而减少文件体积，加速数据恢复。

范什么特西

知识总结04（redis）1、redis为什么这么快2、数据类型及其对应的底层结构3、SDS是什么4、Zset怎么实现的5、Hash的扩容，渐进式rehash是什么

redis缓存完整详解在高并发、高流量的业务场景中，数据库的IO性能往往是系统的最大瓶颈。传统数据库基于磁盘读写，无法支撑海量高频的查询请求，而Redis基于内存运行、读写速度极快。

redis常用数据类型与操作方法redis中的数据结构有以下五种：string（字符串）、list（列表）、hash（哈希）、set（集合）、zset（有序集合）。如下：在redis中所说的这些数据结构只是一种表现形式，或者说是redis承诺给用户的，但它底层不一定就是用这个结构来实现。它的底层实现也就是它的编码方式，不同的数据结构分别有以下几种： string