Redis读写状态那些事儿，怎么看又怎么影响性能呢？

“Redis读写状态那些事儿，怎么看又怎么影响性能呢？”

要搞清楚Redis的读写状态和性能,我们得先弄明白Redis是怎么工作的，你可以把Redis想象成一个记忆力超强、但有点小脾气的伙计，他所有的东西都记在脑子里（也就是内存里），所以读写得特别快，但正因为一切都放在内存里，我们才需要时刻关心他的“工作状态”，看他是不是忙得过来，有没有“累着了”。

第一部分：怎么看Redis的读写状态？

我们不能瞎猜这个伙计累不累,得有些具体的指标来看，这些指标就像是他身体的“体检报告”。

最直接的命令是INFO命令，在Redis的命令行里输入INFO，会吐出一大堆信息，我们重点关注几块：

1. INFO stats 部分（统计信息）：

   • instantaneous_ops_per_sec： 这个最直观，意思是“每秒瞬间操作数”，它告诉你Redis在上一秒钟处理了多少个命令，这个数字如果持续很高，说明你的Redis非常繁忙。
   • total_commands_processed： 从启动到现在总共处理了多少个命令，你可以隔一段时间看一次，算一下差值，就能知道这段时间的平均吞吐量。
   • keyspace_hits 和 keyspace_misses： 这是看缓存命中率的黄金指标。hits表示你要找一个key，结果在Redis里找到了；misses表示没找到，可能得去后面的数据库查了，一个健康的系统，命中率（hits/(hits+misses)）通常应该很高，比如95%以上，如果misses很多，说明Redis可能没缓存多少有用的数据，或者缓存策略有问题，大量请求都穿透到了数据库，会给数据库带来巨大压力。

2. INFO commandstats 部分（命令统计）：

   • 这个块会详细列出每种命令被调用了多少次、总共花了多少时间，比如你能看到get命令调用了多少回，set命令调用了多少回，这对于分析具体是哪种操作最频繁、最耗时有巨大帮助，比如你发现KEYS *这种危险命令（后面会讲为什么危险）被调用了很多次，那性能瓶颈很可能就在它身上。

3. INFO memory 部分（内存信息）：

   • used_memory： Redis当前使用了多少内存，这是生命线，一定要确保它不会超过你服务器的总内存，否则Redis会崩溃或者开始删数据。
   • 如果Redis配置了最大内存限制（maxmemory），还要关注内存碎片率等指标，碎片太多也会影响效率。

除了INFO命令，Redis还提供了慢查询日志（slowlog），你可以设置一个时间阈值（比如10毫秒），任何执行时间超过这个阈值的命令都会被记录下来，查看慢查询日志是定位性能问题的“杀手锏”，能直接告诉你到底是哪些慢操作拖累了整个系统。

第二部分：读写操作是怎么影响性能的？

现在我们知道怎么看状态了,那具体哪些读写行为会让我们这个“伙计”性能下降呢？

1. 大Key问题（Big Key）： 这是头号杀手，想象一下，你让伙计去记忆一篇万字长文（一个value很大的字符串，比如几百KB），或者一个包含十万个元素的名单（一个很大的List或Hash），无论是写入、读取还是删除这个“大Key”，都会耗费非常长的时间，因为需要分配大片内存、进行大量数据传输，更可怕的是，Redis是单线程的（核心网络模型和读写是单线程），处理这个“大Key”的时候，其他所有请求都得排队等着！这就造成了请求延迟飙升，根据阿里云开发者社区的一篇文章所述，大Key会引发一系列问题，包括网络阻塞、慢查询，甚至可能引发集群内存不均。

2. 复杂度过高的命令（Complex Commands）： 有些命令本身执行起来就很耗时，最经典的例子就是KEYS *，这个命令会列出所有的key，当你的Redis里有几百万、上千万个key时，这个命令会扫描整个key空间，导致Redis在很长一段时间内（可能好几秒）无法响应其他任何请求，基本等于一次小型“服务瘫痪”，类似的还有FLUSHALL（清空所有数据）、对一个大集合进行SINTER（求交集）或SUNION（求并集）等操作，应该用SCAN这类渐进式命令替代KEYS。

3. 大量Key集中过期（Massive Expiration）： 你可以给Redis的key设置过期时间，如果有很多key在同一个时间点过期，Redis会定期去清理这些过期key，如果某一时刻过期的key特别多，清理工作会占用大量CPU资源，从而影响正常请求的处理，所以最好让key的过期时间稍微随机一些，避免在同一时刻产生峰值。

4. 持久化操作（Persistence）带来的压力： 虽然持久化（把内存数据写到磁盘）是后台进行的，但也会影响性能。

   • RDB快照： 执行bgsave fork出一个子进程来写快照，如果数据量很大，fork过程本身可能会因为复制内存页表而短暂阻塞主线程（尤其在虚拟机环境下），写磁盘会占用大量I/O资源。
   • AOF日志： 如果AOF配置为每次写操作都同步磁盘（appendfsync always），那么每次写入都会变成磁盘操作，速度会慢很多，通常我们会用每秒同步一次的折中方案（appendfsync everysec），但在磁盘压力大时仍可能拖慢写入速度。

5. 网络瓶颈和连接数： 如果客户端和Redis服务器之间的网络延迟很高，或者带宽被打满了，那么即使Redis本身处理得再快，整体响应时间也会很慢，如果客户端建立了成千上万个连接，Redis需要维护这些连接上下文，也会消耗一定的内存和CPU。

要保证Redis高性能,关键就是“体谅”它单线程和基于内存的特点。避免单次操作太重（大Key），避免使用全局阻塞的命令（复杂命令），让工作负载尽量平滑（避免过期峰值），并合理配置持久化，平时多看看INFO命令和慢查询日志这份“体检报告”，就能及时发现问题，让你的Redis伙计一直保持最佳状态。