Beispielanalyse für die Redis-Optimierung

Speicherdimension

Kontrollieren Sie die Länge des Schlüssels

Schlüssel verwenden im Allgemeinen Zeichenfolgen, und die zugrunde liegende Datenstruktur von Zeichenfolgen ist SDS. Die SDS-Struktur enthält Metadateninformationen wie Zeichenfolgenlänge, zugewiesene Speicherplatzgröße usw. Wenn das Schlüsselzeichen Wenn die Länge der Zeichenfolge zunimmt, belegen auch die Metadaten im SDS mehr Speicherplatz. Um den vom Schlüssel belegten Platz zu reduzieren, können wir zur Darstellung die entsprechende englische Abkürzung entsprechend dem Firmennamen verwenden. Beispielsweise wird der Benutzer durch u und die Nachricht durch m dargestellt.

Vermeiden Sie das Speichern von Bigkey

Wir müssen sowohl auf die Länge des Schlüssels als auch auf die Größe des Werts achten. Redis verwendet einen einzelnen Thread zum Lesen und Schreiben von Daten. Die Lese- und Schreibvorgänge von Bigkey blockieren den Thread die Verarbeitungseffizienz von Redis.

So fragen Sie Bigkey ab

Wir können den Befehl --bigkey verwenden, um die in Redis belegten Bigkey-Informationen anzuzeigen. Der spezifische Befehl lautet wie folgt:

redis-cli -h 127.0.0.1 -p 6379 -a 'xxx' --bigkeys

Wie in der obigen Abbildung gezeigt, können wir sie anzeigen Redis Der Schlüssel belegt 32098 Bytes und muss optimiert werden.

Empfehlung:

• Wenn der Schlüssel vom Typ Zeichenfolge ist, wird empfohlen, dass die Größe des im Wert gespeicherten Werts etwa 10 KB beträgt.

• Wenn der Schlüssel vom Typ List/Hash/Set/ZSet ist, wird empfohlen, die Anzahl der gespeicherten Elemente auf unter 10.000 zu beschränken.

Wählen Sie den geeigneten Datentyp

Redis ist für die Art der gespeicherten Daten optimiert und auch der Speicher ist entsprechend optimiert. Relevantes Wissen über Datenergebnisse finden Sie in früheren Artikeln.

Zum Beispiel: String und set verwenden beim Speichern von int-Daten eine Ganzzahlkodierung. Hash und ZSet verwenden komprimierte Listenspeicher (Ziplist), wenn die Anzahl der Elemente relativ gering ist, und werden in Hash-Tabellen und Sprungtabellen konvertiert, wenn relativ große Datenmengen gespeichert werden.

Effiziente Serialisierungs- und Komprimierungsmethoden anwenden

Strings in Redis werden mit binärsicheren Byte-Arrays gespeichert, sodass wir das Geschäft in Binärformate serialisieren und in Redis schreiben können, aber unterschiedliche Serialisierungen verwenden. Der belegte Speicherplatz variiert. Die Serialisierung von Protostuff ist effizienter als die integrierte Serialisierung von Java und nimmt weniger Platz ein. Um den Speicherplatzverbrauch zu reduzieren, können wir JSON- und XML-Datenformate komprimieren und speichern. Zu den optionalen Komprimierungsalgorithmen gehören Gzip und Snappy.

Legen Sie den maximalen Redis-Speicher und die Eliminierungsstrategie fest.

Wir schätzen die Speichergröße im Voraus basierend auf der Menge der Geschäftsdaten, um eine kontinuierliche Erweiterung des Redis-Speichers zu vermeiden und zu viele Ressourcen zu belegen.

Um die Eliminierungsstrategie festzulegen, müssen Sie die tatsächlichen Geschäftsmerkmale kombinieren, um Folgendes auszuwählen:

• volatile-lru / allkeys-lru: Priorisieren Sie die Aufbewahrung kürzlich aufgerufener Daten

• volatile- lfu / allkeys -lfu: Priorisieren Sie die Aufbewahrung der Daten, auf die am häufigsten zugegriffen wird

• volatile-ttl: Priorisieren Sie ablaufende Daten, die bald ablaufen

• volatile-random/allkeys-random: Löschen Sie Daten nach dem Zufallsprinzip

Redis-Instanzgröße steuern

Es wird empfohlen, die Speichergröße einer Redis-Einzelinstanz auf 2 bis 6 GB einzustellen. Da RDB-Snapshots und die Datensynchronisierung des Master-Slave-Clusters schnell abgeschlossen werden können, wird die Verarbeitung normaler Anforderungen nicht blockiert.

Speicherfragmente regelmäßig löschen

Häufige neue Änderungen führen zu einer Zunahme der Speicherfragmente, daher müssen Speicherfragmente rechtzeitig gelöscht werden.

Redis stellt den Info-Speicherbefehl bereit, um Informationen zur Speichernutzung wie folgt anzuzeigen:

Erklärung:

• used_memory_rss ist der physische Speicherplatz, der Redis tatsächlich vom Betriebssystem zugewiesen wird.

• used_memory ist der von Redis tatsächlich beantragte Speicherplatz zum Speichern von Daten.

• mem_fragmentation_ratio=used_memory_rss/ used_memory

• mem_fragmentation_ratio ist größer als 1, aber kleiner als 1,5. Diese Situation ist vernünftig.

• Wenn mem_fragmentation_ratio größer als 1,5 ist, bedeutet dies, dass die Speicherfragmentierungsrate mehr als 50 % erreicht hat. In diesem Fall müssen in der Regel Maßnahmen ergriffen werden, um die Speicherfragmentierungsrate zu verringern. Spezifische Maßnahmen zur Speicherbereinigung werden in den folgenden Artikeln erläutert.

Leistungsdimension

Die Verwendung der Befehle KEYS, FLUSHALL und FLUSHDB ist verboten.

• KEYS stimmt mit dem Schlüsselinhalt überein und gibt Schlüssel-Wert-Paare zurück, die die Übereinstimmungsbedingungen erfüllen. Dieser Befehl erfordert einen vollständigen Tabellenscan der globalen Redis-Hash-Tabelle, wodurch der Redis-Hauptthread ernsthaft blockiert wird.

• FLUSHALL löscht alle Daten auf der Redis-Instanz. Wenn die Datenmenge groß ist, wird der Redis-Hauptthread ernsthaft blockiert.

• FLUSHDB, löscht die Daten in der aktuellen Datenbank. Wenn die Datenmenge groß ist, wird der Redis-Hauptthread blockiert.

Optimierungsvorschläge

Wir müssen diese Befehle online deaktivieren. Die spezifische Methode besteht darin, dass der Administrator den Befehl rename-command verwendet, um diese Befehle in der Konfigurationsdatei umzubenennen, sodass der Client diese Befehle nicht verwenden kann.

慎用全量操作的命令

对于集合类型的来说，在未清楚集合数据大小的情况下，慎用查询集合中的全量数据，例如Hash的HetALL、Set的SMEMBERS命令、LRANGE key 0 -1 或者ZRANGE key 0 -1等命令，因为这些命令会对Hash或者Set类型的底层数据进行全量扫描，当集合数据量比较大时，会阻塞Redis的主线程。

优化建议：

当元素数据量较多时，可以用SSCAN、HSCAN 命令分批返回集合中的数据，减少对主线程的阻塞。

慎用复杂度过高命令

Redis执行复杂度过高的命令，会消耗更多的 CPU 资源，导致主线程中的其它请求只能等待。常见的复杂命令如下：SORT、SINTER、SINTERSTORE、ZUNIONSTORE、ZINTERSTORE 等聚合类命令。

优化建议：

当需要执行排序、交集、并集操作时，可以在客户端完成，避免让Redis进行过多计算，从而影响Redis性能。

设置合适的过期时间

Redis通常用于保存热数据。热数据一般都有使用的时效性。因此，在数据存储的过程中，应根据业务对数据的使用时间合理地设置数据的过期时间。否则写入Redis的数据会一直占用内存，如果数据持续增增长，会达到机器的内存上限，造成内存溢出，导致服务崩溃。

采用批量命令代替个命令

当我们需要一次性操作多个key时，可以使用批量命令来处理，批量命令可以减少客户端与服务端的来回网络IO次数。

• String或者Hash类型可以使用 MGET/MSET替代 GET/SET，HMGET/HMSET替代HGET/HSET

• 其它数据类型使用Pipeline命令，一次性打包发送多个命令到服务端执行。

Pipeline具体使用：

redisTemplate.executePipelined(new RedisCallback<String>() {
            @Override
            public String doInRedis(RedisConnection connection) throws DataAccessException {
                for (int i = 0; i < 5; i++) 
                {
                    connection.set(("test:" + i).getBytes(), "test".getBytes());
                }
                return null;
            }
        });

高可用维度

按照业务部署不同的实例

不同的业务线来部署 Redis 实例，这样当其中一个实例发生故障时，不会影响到其它业务。

避免单点问题

业务上根据实际情况采用主从、哨兵、集群方案，避免单点故障，影响业务的正常使用。

合理的设置相关参数

针对主从环境，我们需要合理设置相关参数，具体内容如下：

• 合理的设置repl-backlog参数：如果repl-backlog设置过小，当写流量比较大的场景下，主从复制中断可能会引发全量复制数据的风险。

• 合理设置slave client-output-buffer-limit：当从库复制发生问题时，过小的 buffer会导致从库缓冲区溢出，从而导致复制中断。

Das obige ist der detaillierte Inhalt vonBeispielanalyse für die Redis-Optimierung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!