Lassen Sie uns darüber sprechen, wie man mit dem Cache-Hotkey-Problem in Redis umgeht. Häufig verwendete Lösungsfreigabe-Redis-php.cn

Wie gehe ich mit dem Hotkey-Problem in Redis um? Der folgende Artikel stellt Ihnen gängige Lösungen für das Redis-Cache-Hotkey-Problem vor. Ich hoffe, er wird Ihnen helfen!

Lassen Sie uns darüber sprechen, wie man mit dem Cache-Hotkey-Problem in Redis umgeht. Häufig verwendete Lösungsfreigabe

Bei einigen C-seitigen Geschäften ist es unvermeidlich, einen First-Level-Cache einzuführen, um den Druck der Datenbank zu ersetzen und die Geschäftsreaktionszeit zu verkürzen. Tatsächlich wird jedes Mal eine Middleware eingeführt, um das Problem zu lösen Dies wird unweigerlich viele neue Probleme mit sich bringen, die Aufmerksamkeit erfordern, beispielsweise die Frage, wie die Cache-Konsistenz erreicht werden kann, die im vorherigen Artikel „Datenbank- und Cache-Konsistenz in der Praxis“ erwähnt wurde. Tatsächlich kann es bei der Verwendung von Redis als Cache der ersten Ebene zu einigen anderen Problemen wie Hotkeys, großen Tasten usw. kommen. In diesem Artikel werden wir den Hotkey(Hotkey) besprechen )-Problem und wie man dasHotkey-Problem sinnvoll löst. -

Hintergrund

热key（hot key）问题来讨论，如何合理的解决 热key问题。

背景

热key是什么问题，如何导致的？

一般来说，我们使用的缓存Redis都是多节点的集群版，对某个key进行读写时，会根据该key的hash计算出对应的slot，根据这个slot就能找到与之对应的分片(一个master和多个slave组成的一组redis集群)来存取该K-V。但是在实际应用过程中，对于某些特定业务或者一些特定的时段（比如电商业务的商品秒杀活动），可能会发生大量的请求访问同一个key。所有的请求（且这类请求读写比例非常高）都会落到同一个redis server上，该redis的负载就会严重加剧，此时整个系统增加新redis实例也没有任何用处，因为根据hash算法，同一个key的请求还是会落到同一台新机器上，该机器依然会成为系统瓶颈2，甚至造成整个集群宕掉，若此热点key的value 也比较大，也会造成网卡达到瓶颈，这种问题称为 “热key” 问题。【相关推荐：Redis视频教程】

如下图1、2所示，分别是正常redis cluster集群和使用一层proxy代理的redis 集群key访问。

Lassen Sie uns darüber sprechen, wie man mit dem Cache-Hotkey-Problem in Redis umgeht. Häufig verwendete Lösungsfreigabe

如上所说，热key会给集群中的少部分节点带来超高的负载压力，如果不正确处理，那么这些节点宕机都有可能，从而会影响整个缓存集群的运作，因此我们必须及时发现热key、解决热key问题。

1.热key探测

热key探测，看到由于redis集群的分散性以及热点key带来的一些显著影响，我们可以通过由粗及细的思考流程来做热点key探测的方案。

1.1 集群中每个slot的qps监控

热key最明显的影响是整个redis集群中的qps并没有那么大的前提下，流量分布在集群中slot不均的问题，那么我们可以最先想到的就是对于每个slot中的流量做监控，上报之后做每个slot的流量对比，就能在热key出现时发现影响到的具体slot。虽然这个监控最为方便，但是粒度过于粗了，仅适用于前期集群监控方案，并不适用于精准探测到热key的场景。

1.2 proxy的代理机制作为整个流量入口统计

如果我们使用的是图2的redis集群proxy代理模式，由于所有的请求都会先到proxy再到具体的slot节点，那么这个热点key的探测统计就可以放在proxy中做，在proxy中基于时间滑动窗口，对每个key做计数，然后统计出超出对应阈值的key。为了防止过多冗余的统计，还可以设定一些规则，仅统计对应前缀和类型的key。这种方式需要至少有proxy的代理机制，对于redis架构有要求。

1.3 redis基于LFU的热点key发现机制

redis 4.0以上的版本支持了每个节点上的基于LFU的热点key发现机制，使用redis-cli –hotkeys即可，执行redis-cli时加上–hotkeys选项。可以定时在节点中使用该命令来发现对应热点key。

Lassen Sie uns darüber sprechen, wie man mit dem Cache-Hotkey-Problem in Redis umgeht. Häufig verwendete Lösungsfreigabe

如下所示，可以看到redis-cli –hotkeysHot KeyWie wird es verursacht?

Im Allgemeinen handelt es sich bei dem von uns verwendeten Cache-Redis um eine Multi-Node-Cluster-Version. Beim Lesen und Schreiben eines bestimmten Schlüssels wird der entsprechende Slot anhand des Hashs des Schlüssels berechnet und der entsprechende Slot kann auf dieser Grundlage gefunden werden Für den Zugriff auf den K-V wird Sharding (ein Satz von Redis-Clustern bestehend aus einem Master und mehreren Slaves) verwendet. Im eigentlichen Antragsprozess kann es jedoch für bestimmte Unternehmen oder bestimmte Zeiträume (z. B. Produkt-Flash-Sales-Aktivitäten in E-Commerce-Unternehmen) zu einer großen Anzahl von Anfragen kommen, die auf denselben Schlüssel zugreifen. Alle Anfragen (und das Lese-/Schreibverhältnis dieser Anfragen ist sehr hoch) fallen auf denselben Redis-Server, und die Belastung des Redis wird erheblich erhöht. Zu diesem Zeitpunkt wird das Hinzufügen neuer Redis-Instanzen zum gesamten System erforderlich sein Kein Nutzen, da laut Hash-Algorithmus Anfragen für denselben Schlüssel immer noch auf denselben neuen Computer fallen, was immer noch zu einem Systemengpass2 führt und sogar zum Absturz des gesamten Clusters führt, wenn der Wert dieses Hotspot-Schlüssels relativ ist groß, es wird auch dazu führen, dass die Netzwerkkarte den Engpass erreicht. Dieses Problem wird als „Hotkey“-Problem bezeichnet. [Verwandte Empfehlungen: Redis-Video-Tutorial] Wie in den Abbildungen 1 und 2 dargestellt Nachfolgend finden Sie den normalen Redis-Cluster-Cluster und den Redis-Cluster-Schlüsselzugriff mithilfe einer Proxy-Agent-Ebene. Lassen Sie uns darüber sprechen, wie man mit dem Cache-Hotkey-Problem in Redis umgeht. Häufig verwendete Lösungsfreigabe

Lassen Sie uns darüber sprechen, wie man mit dem Cache-Hotkey-Problem in Redis umgeht. Häufig verwendete Lösungsfreigabe

Wie oben erwähnt, Hotkeys führen zu einem extrem hohen Lastdruck auf eine kleine Anzahl von Knoten im Cluster. Wenn sie nicht richtig gehandhabt werden, können diese Knoten ausfallen, was sich auf den Betrieb des gesamten Cache-Clusters auswirkt. Daher müssen wir Hotkeys rechtzeitig erkennen und lösen Sie sie.

1. Hotkey-Erkennung

Die Hotkey-Erkennung hat aufgrund der Streuung des Redis-Clusters und des Hotkeys einige erhebliche Auswirkungen und kann daher sorgfältig überlegt werden über den Prozess zur Entwicklung einer Lösung zur Erkennung von Hotspot-Schlüsseln.

1.1 QPS-Überwachung jedes Slots im Cluster

Die offensichtlichste Auswirkung von Hotkeys besteht darin, dass die QPS im gesamten Redis-Cluster überwacht werden Unter der Voraussetzung, dass der Verkehr ungleichmäßig auf die Slots im Cluster verteilt ist, können wir uns zunächst vorstellen, den Verkehr in jedem Slot zu überwachen, den Verkehr in jedem Slot zu vergleichen und ihn dann zu vergleichen Beim Erkennen der betroffenen Steckplätze wird ein Hotkey angezeigt. Obwohl diese Überwachung am bequemsten ist, ist die Granularität zu grob. Sie eignet sich nur für frühe Cluster-Überwachungslösungen und nicht für Szenarien, in denen Hotkeys genau erkannt werden.

1.2 Der Proxy-Mechanismus wird als gesamte Verkehrseingangsstatistik verwendet

Wenn wir den Redis-Cluster-Proxy-Modus in Abbildung 2 verwenden, Aufgrund von Alle Anforderungen werden zuerst an den Proxy und dann an den spezifischen Slot-Knoten weitergeleitet. Anschließend können die Erkennungsstatistiken dieses Hotkeys im Proxy erstellt werden, basierend auf dem Zeitgleitfenster. Zählen Sie jeden Schlüssel und dann die Schlüssel, die den entsprechenden Schwellenwert überschreiten. Um zu viele redundante Statistiken zu verhindern, können Sie auch einige Regeln festlegen, um nur Schlüssel zu zählen, die dem Präfix und Typ entsprechen. Diese Methode erfordert mindestens einen Proxy-Mechanismus und stellt Anforderungen an die Redis-Architektur.

1.3 Redis LFU-basierter Hotspot-Schlüsselerkennungsmechanismus

Versionen von Redis 4.0 oder höher unterstützen LFU-basierte Hotspots auf jedem Knoten Schlüsselerkennungsmechanismus: Verwenden Sie redis-cli –hotkeys. Fügen Sie die Option –hotkeys hinzu, wenn Sie redis-cli ausführen. Sie können diesen Befehl regelmäßig auf dem Knoten verwenden, um den entsprechenden Hotspot-Schlüssel zu ermitteln. Lassen Sie uns darüber sprechen, wie man mit dem Cache-Hotkey-Problem in Redis umgeht. Häufig verwendete Lösungsfreigabe

as Wie in der Abbildung gezeigt, können Sie die Ausführungsergebnisse von redis-cli –hotkeysund die statistischen Informationen zu Hotkeys sehen. Die Ausführungszeit dieses Befehls ist lang und Sie können eine geplante Ausführung einrichten um Statistiken zu sammeln.

1.4 Erkennung basierend auf dem Redis-Client

Da Redis-Befehle jedes Mal vom Client ausgegeben werden, können wir auf dieser Grundlage statistische Zählungen in einigen Codes des Redis-Clients durchführen, und jeder Client führt Statistiken basierend auf dem Zeitgleitfenster durch. Nach Überschreiten eines bestimmten Schwellenwerts wird es dem Server gemeldet, und der Server sendet es dann einheitlich an jeden Client und konfiguriert die entsprechende Ablaufzeit.

Diese Methode sieht schöner aus, ist jedoch in einigen Anwendungsszenarien tatsächlich nicht so geeignet, da die Änderung auf der Clientseite einen größeren Speicheraufwand für den laufenden Prozess mit sich bringt. Direkter sind Sprachen mit automatischer Speicherverwaltung, z Java und goLang erstellen häufiger Objekte, lösen GC aus und führen zu einer Verlängerung der Schnittstellenantwortzeit. Dies ist nicht leicht vorherzusagen.优美，其实在一些应用场景中并不是那么合适，因为在client端这一侧的改造，会给运行的进程带来更大的内存开销，更直接的来说，对于Java和goLang这种自动内存管理的语言，会更加频繁的创建对象，从而触发gc导致接口响应耗时增加的问题，这个反而是不太容易预料到的事情。

最终可以通过各个公司的基建，做出对应的选择。

2.热key解决

通过上述几种方式我们探测到了对应热key或者热slot，那么我们就要解决对应的热key问题。解决热key也有好几种思路可以参考，我们一个一个捋一下。

2.1 对特定key或slot做限流

一种最简单粗暴的方式，对于特定的slot或者热key做限流，这个方案明显对于业务来说是有损的，所以建议只用在出现线上问题，需要止损的时候进行特定的限流。

2.2 使用二级（本地）缓存

本地缓存也是一个最常用的解决方案，既然我们的一级缓存扛不住这么大的压力，就再加一个二级缓存吧。由于每个请求都是由service发出的，这个二级缓存加在service端是再合适不过了，因此可以在服务端每次获取到对应热key时，使用本地缓存存储一份，等本地缓存过期后再重新请求，降低redis集群压力。以java为例，guavaCache就是现成的工具。以下示例：

//本地缓存初始化以及构造 private static LoadingCache> configCache = CacheBuilder.newBuilder() .concurrencyLevel(8) //并发读写的级别，建议设置cpu核数 .expireAfterWrite(10, TimeUnit.SECONDS) //写入数据后多久过期 .initialCapacity(10) //初始化cache的容器大小 .maximumSize(10)//cache的容器最大 .recordStats() // build方法中可以指定CacheLoader，在缓存不存在时通过CacheLoader的实现自动加载缓存 .build(new CacheLoader>() { @Override public List