Redis 延迟偶发飙升：从 Hot Key 与 Big Key 定位到分阶段治理实践
## 适用场景 业务使用 Redis 承载登录态、商品详情、计数器或排行榜。平时接口稳定，但在促销、定时任务或某些请求集中到来时，应用开始出现 Redis 超时；监控中 `instantaneous_ops_per_sec` 并不一定很高，CPU 也可能没有持续满载。 本文以单实例或主从架构为例，说明如何区分 **
Tag
#Redis
包含这个标签的文章。
Redis replication backlog 不足导致频繁全量同步的排查与治理实践
## 适用场景 Redis 采用主从复制，业务高峰时偶发写入延迟、主库 CPU 或网络突刺。日志中反复出现 `Full resync requested`、`Partial resynchronization not accepted`，从库短时间内加载 RDB，甚至与主库断开后很久才恢复。 本文适用于 Redis
Redis AOF 重写导致磁盘 IO 飙高和写入延迟的排查与治理
## 适用场景 本文适用于线上 Redis 开启 AOF 持久化后，业务在某些时间段出现接口变慢、写入超时、Redis `used_cpu_sys` 升高、磁盘 `await` 或 `util` 接近打满的场景。常见部署形态包括单机 Redis、主从 Redis、哨兵架构，以及运行在云主机本地盘或云盘上的 Redis
Redis 大 key 和热 key 导致接口延迟升高的排查实践
## 适用场景 这篇文章适用于线上 Redis 作为缓存、会话、计数器或排行榜组件时，出现接口响应时间突然升高、Redis CPU 飙升、慢查询增多、网络出口流量变大等问题的排查。 典型环境包括： - 单机 Redis 或 Redis Sentinel 架构； - Redis Cluster 分片集群； - 业务
Python基于Redis实现分布式锁
分布式锁应该具备的条件： - 在分布式系统环境下，任意时刻，只能有一个客户端能持有锁； - 高可用/高性能的获取锁和释放锁，必须保证加锁和解锁是同一个客户端所为； - 具备锁失效机制（防止死锁）,即使有一个客户端在持有锁期间崩溃而没有主动释放锁，也能保证后续其他客户端能正常加锁； - 具备非堵塞特性，即没有获取到锁，
Redis简介
<h1>Redis简介</h1> Redis是完全开源免费的，准守BSD协议，是一个高性能的key-value数据库 Redis与其他key-value缓存产品有以下三个特点： <ul> <li>Redis支持数据持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载使用</li> <li>Redis不仅支
Redis 安装
<h1>安装Redis</h1> 下载地址：http://redis.io/download 下载最新文档版本。 本教程使用的最新文档版本为 redis-4.0.9，下载并安装： <pre><code class="language-bash line-numbers">yum install -y gcc g++