redis

前言 @Cacheable 是 Spring 框架中用于方法级缓存的注解。它主要用于减少方法调用的次数，通过缓存方法的返回结果来提高应用程序的性能。 核心原理是，Spring 提供了统一的标准抽象，可

前言 要想实现客户端与服务端间通信，在传输层协议 TCP 或 UDP 的基础上，定义客户端与服务端都能识别信息的规则，俗称【协议】。 在 Redis 中，定义了简单的 RESP（REdis Seria

分布式系统 分布式系统是应对海量请求、海量数据存储的核心应用，而分散的多节点如何确保数据的正确性、一致性呢？这也分布式系统要解决的核心问题。 分布式系统中有很多协议算法，不同的应用场景最适用的协议算法

使用场景 1. 针对前端页面 网络问题导致用户重复点击，发了多次请求引起的重复提交 2. 针对系统间接口调用 因网络超时重试或者程序bug导致的重复请求 3. 通用的业务层面的验证 比如要限制某个接口

1. 前言 一般情况 Redis 连接数问题并不常见，但是当你业务服务增加、对 Redis 的依赖持续增强的过程中，可能会遇到很多 Redis 的问题，这个时候，Redis 连接数可能就成了一个常见的

Redis 核心原理总览（全局篇） 正文开始之前，我们先思考下「如何造一个缓存组件？」 1）最小可用版： 要快：缓存最核心的目的是支持快速访问，硬件层面一般选择「内存」 远程访问：作为缓存组件，要支持

Redis 核心原理总览（全局篇） 正文开始之前，我们先思考下「如何造一个缓存组件？」 1）最小可用版： 要快：缓存最核心的目的是支持快速访问，硬件层面一般选择「内存」 远程访问：作为缓存组件，要支持

Redis 核心原理总览（全局篇） 正文开始之前，我们先思考下「如何造一个缓存组件？」 1）最小可用版： 要快：缓存最核心的目的是支持快速访问，硬件层面一般选择「内存」 远程访问：作为缓存组件，要支持

前言 Redis（Remote Dictionary Server），即「远程字典服务」是一个使用 ANSI C 编写的、开源的、支持网络的、基于内存的、可选持久化的键值对存储系统。 在 2013

译文如下： Redis internals （内部结构） 当你阅读 README 文档时，不管是通过 GitHub 页面上还是下载 Redis 分支源码等方式，离源码仅一步之遥，因此，我们在这里对 R

译文如下： Redis 发版周期 Redis 新版本如何发布的？ Redis 是系统软件，并且是处理用户数据的软件，也就是说，它处于软件栈关键的一环上。 基于此，Redis 版本周期以较慢的迭代速度为

前言 考虑这样一个场景，如何统计一个大型网站的去重日活、月活用户（UV）？ 你可以通过 set 集合、bitmap 这类常用工具，但有个最大的缺点是，如果数据量巨大，比如 1 亿，甚至 10 亿将耗费

前言 如果一个键过期了，什么时候会被删除呢？又如何找出这些过期 key 并删除？会不会影响服务正常运行？ redis 中有两种 key，一种带有 expire 过期时间，另一种则是不带过期时间，本文讨

前言 所谓 协议，本质是一种约定，需要使用者双方来准守，常见于 C/S 通信模式中，比如在浏览器中最常用的 HTTP 应用层通信协议。 通信两端需要某种约定，才能保持正常通信。一端通过约定的格式发送数

前言 Redis 基于内存设计，所有数据存放在内存，随着时间推移，内存占用也越来也高 ... 由于内存容量这个物理限制，我们需要在内存使用量达到一定比例后，做一些内存清理工作，以保证有足够的空间来完成

前言 事务，古老而神秘的词汇，说起它，你应该能想起它的四大特性：原子性、隔离性、持久性和一致性。 我们先往简单了想，事务解决了什么问题？确保一揽子修改操作的 正确性 和 一致性。 事务需要做什么？本质

前言 管道，你肯定不陌生，你家里的自来水管、天然气管等，应用相当广泛。这些管道有啥特点？传输特定的物质、流式，.... 等等。 我们知道，redis 是 C/S 模式，即客户端 + 服务端。当两端想要

前言 发布订阅模式，本质来说，是将提供消息的人和需要消息的人，通过第三方组件联系起来，使得两类群体之间的消息能够及时触达。 比如，在一些优化场景下，可能会使用 本地 + 远程 双缓存机制，远程缓存是一

前言 限流，是网站防止流量洪峰的必要手段，尤其是一些重要资源的处理，甚为重要。限流的核心目的自然是保障网站的正常运行，避免处理超过网站自身的流量，压死骆驼的最后一个稻草，你懂得。 常见的限流算法有 计

前言 前面系列文章，我们聊了 redis 主从模式、哨兵模式，这些都是单节点的高可用保障，受限于单机内存，另外，由于 redis 持久化的特性，单个 redis 实例的内存不宜过大。 分布式存储的终极