Redis篇--常见问题篇5--热Key（Hot Key，什么是热Key，服务降级，一致性哈希）

热key（Hot Key）是指在Redis中访问频率非常高、读写请求非常频繁的键。由于Redis是单线程模型，所有操作都是串行执行的，Hot Key处理不好，会产生一些问题。比如短时间的群蜂效应（群蜂请求），大量请求会在短时间内朝着Redis服务冲击，很可能会导致被访问的Redis服务器压力剧增，甚至可能将Redis服务器击垮。

1、热键可能会导致以下问题

（1）、性能下降：当某个键的读写请求量非常大时，Redis会花费大量时间处理这些请求，导致其他请求被阻塞，进而影响整个系统的性能。
（2）、系统不稳定：频繁访问同一个键会导致Redis的CPU、内存和网络资源被过度占用，影响其他键的正常访问。在极端情况下，Redis 实例可能会崩溃或无法正常工作。
（3）、延迟增加：由于Redis是单线程的，所有命令都是按顺序执行的。如果某个热键的请求过多，其他命令的执行会被推迟，导致整体延迟增加。
（4）、缓存击穿：如果热键是一个缓存数据，并且该键突然失效或过期，可能会导致大量的请求直接打到后端数据库，造成“缓存击穿”现象，给后端系统带来巨大压力。

2、热键问题的表现

高QPS（每秒查询数）：某个键的读写请求量远高于其他键，导致Redis实例的整体QPS非常高。
高延迟：由于Redis是单线程的，热键的请求会阻塞其他请求，导致整体延迟增加，尤其是在高并发场景下。
CPU和内存使用率升高：热键的频繁访问会导致Redis的CPU和内存使用率升高，甚至可能达到瓶颈。
网络流量激增：热键的频繁访问会占用大量的网络带宽，导致网络流量激增，影响其他服务的通信。

3、热键易发生的业务场景

某些业务场景中，特定的数据项（如热门商品、明星主页、热门新闻，配置文件等）可能会被大量客户端同时访问。
例如：

电商促销活动：在促销期间，大量用户会同时访问某个热门商品的信息，导致该商品对应的Redis键成为热键。
社交平台的热门话题：在社交媒体平台上，某些热门话题或帖子可能会被大量用户同时查看，导致相关数据成为热键。
配置文件：某些全局配置文件（如系统参数、API限流规则等）可能会被多个服务实例频繁读取，导致配置文件对应的键成为热键。

4、如何识别热键

要识别热键，可以使用以下几种方法：

（1）、使用Redis内置命令

- SLOWLOG：Redis提供了SLOWLOG命令，用于记录和查看执行时间较长的命令。你可以通过SLOWLOG GET获取最近的慢查询日志，分析哪些键的请求耗时较长。

SLOWLOG GET 10

在这里插入图片描述
结果说明下：
第一行：2，标识ID，作为唯一标识
第二行：1734573443，时间戳，即该命令执行的时间
第三行：100939，命令执行耗费的时间，微秒级。
第四行：为执行的实际命令。

- INFO keyspace：INFO keyspace命令可以显示每个数据库中键的数量、过期键的数量以及最近的访问统计信息。你可以通过这些信息来判断哪些键的访问频率较高。

INFO keyspace

在这里插入图片描述
结果说明：
db0库中有9个键，设置过期的为0。

- MEMORY USAGE：MEMORY USAGE命令可以获取单个键的内存使用情况。结合SCAN命令，你可以批量查找占用大量内存的键。

MEMORY USAGE key

- KEYS或SCAN：你可以使用SCAN命令遍历Redis数据库中的所有键，并结合DEBUG OBJECT或MEMORY USAGE来查找访问频率较高的键。

SCAN 0 COUNT 1000

（2）、使用监控工具

Redis Desktop Manager (RDM)：RDM提供了"Big Keys"和"Monitor"功能，可以帮助你实时监控Redis的内存使用情况，并识别出访问频率较高的热键。
RedisInsight：由Redis官方提供的图形化管理工具，提供了丰富的监控和分析功能，帮助你识别热键。
Prometheus + Grafana：结合Prometheus和Grafana，可以实现更高级的Redis监控和告警功能。你可以通过自定义的监控指标（如QPS、延迟、内存使用等）来识别热键。

（3）、使用Redis慢查询日志和性能分析工具

慢查询日志：Redis的慢查询日志可以记录执行时间较长的命令。你可以通过分析慢查询日志，找出哪些键的请求耗时较长。
性能分析工具：使用Redis性能分析工具（如redis-benchmark、redis-stat等）可以模拟高并发场景，帮助你识别热键。

5、如何优化热键

（1）、优化缓存设计

细化缓存粒度：将缓存的粒度细化，避免多个不同的请求命中同一个缓存键。例如，将页面中的各个部分分别缓存为不同的键，而不是将整个页面缓存为一个键。
合理设置缓存过期时间：根据业务需求，合理设置缓存的过期时间。过短的过期时间会导致频繁的缓存更新操作，增加热键的压力；过长的过期时间可能会导致缓存数据不及时更新，影响业务的准确性。
使用分布式缓存：将缓存分散到多个Redis实例上，避免单个实例承受过大的压力。如：使用Redis Cluster。

（2）、引入限流等降级机制

限流

对热键的访问进行限流，限制单位时间内对该键的请求次数。你可以使用Redis的 INCR功能实现限流。
示例如：（1分钟限制访问10次）
第一步：生成唯一的键名，格式为"rate_limit:ip:<IP地址>:<年月日时分>"

例如：rate_limit:192.168.1.1:1634:202412191457
第二步：使用INCR命令增加计数器，并设置过期时间为60秒
如果计数器不存在，则创建并初始化为 1
如果计数器已存在，则增加计数器的值
第三步：检查计数器的值是否超过最大请求数（10 次）
如果超过，则返回异常 Too Many Requests
如果未超过，则允许请求通过

Java代码示例：
为了保证上述多步骤操作的原子性，需要通过lua语言实现。

import redis.clients.jedis.Jedis;
import redis.clients.jedis.Response;
import redis.clients.jedis.Transaction;public class RateLimiter {private static final String LIMITER_SCRIPT ="local key = KEYS[1]\n" +"local max_requests = tonumber(ARGV[1])\n" +"local window_time = tonumber(ARGV[2])\n" +"\n" +"local current_count = redis.call('GET', key)\n" +"if not current_count then\n" +"    redis.call('SET', key, 1)\n" +"    redis.call('EXPIRE', key, window_time)\n" +"    return 1\n" +"else\n" +"    current_count = tonumber(current_count) + 1\n" +"    if current_count > max_requests then\n" +"        return 0\n" +"    else\n" +"        redis.call('INCR', key)\n" +"        return current_count\n" +"    end\n" +"end";private Jedis jedis;public RateLimiter(Jedis jedis) {this.jedis = jedis;}/检查是否允许请求@param ip          客户端 IP 地址@param maxRequests 最大请求数@param windowTime  时间窗口（秒）@return 如果允许请求，返回当前计数；否则返回 0/public long checkRateLimit(String ip, int maxRequests, int windowTime) {String key = "rate_limit:ip:" + ip;Object result = jedis.eval(LIMITER_SCRIPT, 1, key, String.valueOf(maxRequests), String.valueOf(windowTime));return Long.parseLong(result.toString());}public static void main(String[] args) {// 连接到 RedisJedis jedis = new Jedis("localhost", 6379);// 创建限流器RateLimiter rateLimiter = new RateLimiter(jedis);// 模拟 IP 地址String ip = "192.168.1.1";// 设置限流规则：每分钟最多 10 次请求int maxRequests = 10;int windowTime = 60;// 模拟多次请求for (int i = 1; i <= 15; i++) {long count = rateLimiter.checkRateLimit(ip, maxRequests, windowTime);if (count == 0) {System.out.println("请求被拒绝：超出限流限制");} else {System.out.println("请求通过，当前计数：" + count);}}// 关闭连接jedis.close();}
}

降级

如上的示例是使用了Redis的特性实现的限流。在java实现中也有很多的降级机制。
当热键的请求量过大时，可以考虑对非核心业务进行降级处理，减少对热键的依赖。例如，对于某些非关键数据，可以直接返回默认值或空结果，而不必每次都查询 Redis。

（3）、使用Redis Cluster或分片（推荐）

Redis Cluster：Redis Cluster是Redis的官方分布式解决方案，支持自动分片和故障转移。通过将数据分散到多个节点上，可以有效缓解单个节点的压力，避免热键问题。
分片（Sharding）：如果你不想使用Redis Cluster，也可以手动将数据分片到多个Redis实例上。你可以使用一致性哈希算法或其他分片策略，确保热点数据均匀分布在不同的实例上。

（4）、使用缓存预热和双缓存机制或分布式锁

缓存预热：在系统启动时，预先加载一些常用的数据到缓存中，避免冷启动时的缓存击穿问题。你可以使用定时任务或后台进程来定期预热缓存。
双缓存机制：使用双缓存机制，即在Redis缓存之前再加一层本地缓存（如Caffine）。这样可以进一步减少对数据库的访问压力，尤其是在高并发场景下。

（5）、使用Redis的持久化和备份机制

AOF持久化：启用AOF持久化，确保Redis在重启时能够快速恢复数据。你可以根据业务需求调整AOF的同步频率，避免频繁的磁盘I/O操作影响性能。
RDB快照：定期生成RDB快照，确保Redis的数据不会丢失。你可以结合AOF和RDB持久化机制，确保数据的安全性和可用性。

6、总结

热键问题是Redis在高并发场景下常见的性能瓶颈之一。由于Redis是单线程模型，热键的频繁访问会导致性能下降、延迟增加，甚至影响整个系统的稳定性。要解决热键问题，比较推荐的方式就是Redis集群和降级的方式。即上面优化建议的前3点

附录：

一、降级，限流，熔断三个概念

1、限流（Rate Limiting）

限流是一种通过限制请求频率来防止系统过载的技术手段。它的主要目的是在系统资源有限的情况下，确保系统不会因为过多的请求而崩溃。

常见的限流算法包括：
- 固定窗口算法：将时间划分为固定的时间窗口（如每秒），并在每个窗口内限制请求数量。
- 滑动窗口算法：基于固定窗口算法的改进，允许更平滑地处理跨窗口的请求。
- 令牌桶算法：模拟一个桶，桶中有一定数量的令牌，每次请求消耗一个令牌。如果桶中没有令牌，则拒绝请求。桶会以固定的速率生成新的令牌。
- 漏桶算法：类似于令牌桶，但每次请求都会被放入一个“桶”中，以固定的速率处理请求。如果桶满了，则拒绝请求。

限流的作用：

防止系统过载：通过限制请求频率，避免系统因过多的并发请求而崩溃。
保护下游服务：限流不仅可以保护当前系统，还可以防止过多的请求打到下游依赖的服务（如数据库、第三方API等），避免整个链路的瘫痪。

限流与降级的关系：

限流是降级的一种具体实现方式，它通过限制请求频率来降低系统的负载，确保系统能够在高并发情况下保持一定的可用性。
限流通常用于应对系统过载的情况，属于降级策略中的一种防御性措施。

2、熔断（Circuit Breaker）

熔断是一种用于应对依赖服务不可用的技术手段。它的主要目的是在某个依赖的服务（如数据库、缓存、第三方API等）不可用时，避免系统陷入无限等待或重试的状态，从而导致整个系统的崩溃。

熔断机制通常包括以下几个状态：
- 闭合状态（Closed）：当依赖服务正常工作时，熔断器处于闭合状态，允许请求正常通过。
- 打开状态（Open）：当依赖服务出现故障（如超时、异常等），并且故障次数超过设定的阈值时，熔断器会切换到打开状态，直接拒绝后续的请求，避免系统陷入无限等待或重试的状态。
- 半开状态（Half-Open）：在经过一段时间后，熔断器会进入半开状态，允许少量请求通过，试探依赖服务是否已经恢复。如果请求成功，熔断器会切换回闭合状态；如果请求失败，熔断器会重新切换到打开状态。

熔断的作用：

防止雪崩效应：当某个依赖服务不可用时，熔断器可以快速切断对该服务的调用，避免系统因等待响应而陷入阻塞状态，进而导致整个系统的崩溃。
提供快速失败机制：熔断器可以在依赖服务不可用时，立即返回错误或默认值，而不是让请求长时间等待，提升系统的响应速度。

熔断与降级的关系：

熔断是降级的一种具体实现方式，它通过切断对不可用服务的调用，确保系统能够在依赖服务不可用的情况下保持一定的可用性。
熔断通常用于应对依赖服务不可用的情况，属于降级策略中的一种保护性措施。

限流和熔断区别：
在这里插入图片描述

3、降级（Degradation）

降级是指在系统出现故障、性能瓶颈或其他异常情况时，为了保证系统的部分功能能够继续正常运行，而采取的一种临时性措施。降级的核心思想是牺牲非关键功能，确保核心业务不受影响，避免整个系统崩溃。
降级是一个更广泛的概念，涵盖了多种应对系统异常的策略，限流和熔断只是其中的两种常见手段。

降级的常见策略：

功能降级：关闭或简化非关键功能。
读写降级：将系统降级为只读模式或异步写入。
限流与熔断：限制请求频率或暂时停止对不可用服务的调用。
降级为本地缓存或静态数据：使用本地缓存或预定义的静态数据来替代远程服务。
切换到备用服务：自动切换到备用节点或降级为纯数据库模式。

降级的核心思想：

牺牲非关键功能：在资源有限或服务不可用的情况下，优先保证核心业务的正常运行，暂时关闭或简化非关键功能。
降低服务质量：虽然系统可能无法提供最佳的服务质量，但仍然可以提供基本的功能，确保用户体验不至于完全中断。
提高系统的容错性和可用性：通过降级，系统可以在面对突发情况时保持一定的可用性，避免因单点故障导致整个系统瘫痪。

降级的常见场景：

系统过载：当系统的负载过高，导致响应变慢或无法处理更多的请求时，可以通过降级来限制流量，避免系统崩溃。
服务不可用：当某个依赖的服务（如数据库、缓存、第三方API等）不可用时，可以通过降级来绕过该服务，提供替代方案。
资源不足：当系统的资源（如CPU、内存、网络带宽等）不足时，可以通过降级来减少资源消耗，确保核心业务的正常运行。
硬件故障：当服务器或网络设备发生故障时，可以通过降级来切换到备用节点或降级为只读模式，确保系统的部分功能仍然可用。

4、简单总结下降级，限流，熔断的关系

当系统出现故障或遇到瓶颈时，为了保证系统可用，采用一些方法以牺牲一定的次要功能为代价，保证主业务还可以继续使用的手段，我们称之为降级。
限流和熔断只是实现降级的一种策略，实际降级的策略还有很多。
例如：
一个饭店既卖黄焖鸡，又卖西红柿炒鸡蛋。
当遇到瓶颈是客人太多时，需要通过限流的方式降级店的功能。如果屋内桌子都坐满了就不接待新的客人了。
当遇到的瓶颈是缺少鸡蛋时，需要通过熔断的方式降级店的功能。如果客人需要西红柿炒鸡蛋就直接拒绝，当买来鸡蛋后，在恢复西红柿炒鸡蛋的服务。

二、传统哈希算法和一致性哈希算法。

这里先假设有3台Redis服务器，需要把数据存储到3台服务器上。

1、传统哈希算法

为了实现数据均匀分布在3台Redis服务器上，最简单的做法是使用传统的哈希算法（如 hash(key) % N），这里N是服务器的数量。通过这种方式，你可以将每个数据项映射到一台服务器上。

- 优点：简单易实现，数据可以均匀分布到各个服务器。
- 缺点：当服务器数量发生变化时（如增加或删除服务器），所有数据的哈希值都会发生变化，导致几乎所有数据都需要重新分配。大大增加了系统的负载，甚至可能导致系统不可用。

假设有3台服务器，使用hash(key) % 3来分配数据。如果此时新增加了一台服务器，服务器数量变为4，那么所有的数据都需要重新计算哈希值，并重新分配到新的服务器上。这种大规模的数据迁移显然是不可取的。重新分配的数据量是几乎100%。

2、一致性哈希

为了解决传统哈希算法在服务器动态变化时的问题，一致性哈希引入了虚拟环和虚拟节点的概念。

核心思想

将服务器和数据都映射到一个环形结构上，而不是直接根据服务器数量进行哈希计算。
当服务器数量变化时，只有部分数据需要重新分配，而不会影响整个系统的数据分布。

虚拟环的概念：
一致性哈希将所有的服务器和数据项都映射到一个0到2^32 - 1的整数环上（即哈希空间）。这个环是一个逻辑上的环形结构，方便进行顺时针查找。

服务器映射：
每个服务器通过哈希函数计算出一个或多个哈希值，并将这些哈希值放置在环上的不同位置。这些位置称为“虚拟节点”。多个虚拟节点确保数据分布更加均匀，且数据分布计算更快。同时，虚拟节点还可以减少服务器增减时的数据迁移量。
虚拟节点具体作用：
虚拟节点将虚拟环分成了多个不同的区间段。数据key计算的哈希值映射到虚拟环后，一定是属于某一段区间的。一致性哈希算法会根据key在虚拟环上的位置一直向右查找到最近的虚拟节点，该虚拟节点属于哪一个服务器，则该数据就分布到这一个服务器上。
数据映射：
同样，每个数据项也通过哈希函数计算出一个哈希值，并将该哈希值放置在环上的某个位置。

数据分配规则：
对于每个数据项，找到它在环上的位置后，顺时针方向查找最近的一个虚拟节点，该虚拟节点对应的物理服务器就是负责存储该数据项的服务器。

插入数据：
当你插入一个新的数据项时，首先计算它的哈希值，然后在环上顺时针查找最近的虚拟节点，将数据存储在该虚拟节点对应的物理服务器上。
查询数据：
当你查询一个数据项时，同样计算它的哈希值，然后在环上顺时针查找最近的虚拟节点，从该虚拟节点对应的物理服务器中获取数据。

示例理解：
上面的概念其实不是很好理解，这里我们以一个简单示例说明一下。
假设我们有3台服务器（Server1、Server2和Server3），且每台服务器有三个虚拟节点（Server1#1，Server1#2，Server1#3，Server2#1，Server2#2，Server2#3，Server3#1，Server3#2，Server3#3）。
我们存入key1，计算key1的哈希值，分布在Server1#1，Server1#2的区间内，即保存到了服务器Server1上。
我们存入key2，计算key2的哈希值，分布在Server2#1，Server2#2的区间内，即保存到了服务器Server2上。
我们存入key3，计算key3的哈希值，分布在Server3#1，Server3#2的区间内，即保存到了服务器Server3上。

此时增加了一台服务器（Server4），虚拟节点为（Server4#1，Server4#2，Server4#3）。
此时数据需要重新分布，发起数据迁移计算。
发现key1位于Server4#3和Server1#1之间，则key1需要迁移到Server4上。
发现key2位于Server2#2，Server2#3之间，则key2不需要迁移。
发现key3位于Server3#3，Server4#1之间，则key3不需要迁移。

这样的实现，使得数据迁移相对传统哈希而言会少很多。