Google Cloud：針對(duì) Memorystore for Redis 的性能優(yōu)化最佳實(shí)踐

Redis 是最流行的開(kāi)源內(nèi)存數(shù)據(jù)庫(kù)之一，可作為數(shù)據(jù)庫(kù)、緩存和消息代理使用。針對(duì)基于 Google Cloud 運(yùn)行 Redis 有幾種部署場(chǎng)景，Memorystore for Redis 是我們的集成選項(xiàng)。Memorystore for Redis 既能夠提供 Redis 的優(yōu)勢(shì)，又無(wú)需管理成本。

在將系統(tǒng)投入生產(chǎn)之前，對(duì)系統(tǒng)進(jìn)行基準(zhǔn)測(cè)試并根據(jù)您的特定工作負(fù)載特性對(duì)其進(jìn)行調(diào)整至關(guān)重要 —— 即使系統(tǒng)依賴(lài)托管服務(wù)。在本文中，我們將介紹您能如何衡量 Memorystore for Redis 的性能以及性能調(diào)整的最佳實(shí)踐。一旦我們了解了影響 Memorystore for Redis 性能的因素以及如何對(duì)其進(jìn)行適當(dāng)調(diào)整，您就能保持應(yīng)用程序的穩(wěn)定性。

對(duì) Cloud Memorystore 進(jìn)行基準(zhǔn)測(cè)試

首先，讓我們看一下如何衡量基準(zhǔn)。

選擇基準(zhǔn)工具

有一些工具可用于執(zhí)行針對(duì) Memorystore for Redis 的基準(zhǔn)測(cè)試。以下所列工具是一些示例。

●Redis-benchmark

●Memtier-benchmark

●YCSB

●PerfKit Benchmark

在本文中，我們將使用 YCSB，因?yàn)樗哂徐`活控制流量和字段模式的特點(diǎn)，并且在社區(qū)得到很好維護(hù)。

分析您的應(yīng)用的流量模式

配置基準(zhǔn)工具之前，了解實(shí)際的的流量模式是什么樣的至關(guān)重要。如果您已經(jīng)一直在運(yùn)行要基于 Memorystore for Redis 進(jìn)行測(cè)試的應(yīng)用程序，并且有一些可用指標(biāo)，應(yīng)考慮首先對(duì)它們進(jìn)行分析。如果您要向 Memorystore for Redis 部署新的應(yīng)用程序，可在測(cè)試環(huán)境中對(duì)您的應(yīng)用程序進(jìn)行初步負(fù)載測(cè)試，并使用Cloud Monitoring 監(jiān)控性能。

要配置基準(zhǔn)工具，需要以下信息：

●每個(gè)記錄的字段數(shù)量

●記錄數(shù)

●每行的字段長(zhǎng)度

●查詢(xún)模式，例如，SET（設(shè)置）和GET（獲?。┍嚷?/span>

●正常和高峰時(shí)段的吞吐量

基于實(shí)際流量模式配置基準(zhǔn)工具

針對(duì)特定用例進(jìn)行性能基準(zhǔn)測(cè)試時(shí)，重要的是通過(guò)考慮表數(shù)據(jù)模式、查詢(xún)模式和實(shí)際系統(tǒng)的流量模式來(lái)設(shè)計(jì)基準(zhǔn)內(nèi)容。

在此，我們將假設(shè)以下要求。

●表的每行有兩個(gè)字段

●字段最大長(zhǎng)度為 1,000,000

●最大記錄數(shù)為 1 億

●查詢(xún)模式的 GET:SET 比為 7:3

●通常流量為 1k ops/秒，高峰流量為 20k ops/秒

YCSB 可通過(guò)配置文件控制基準(zhǔn)模式。以下是使用這些要求的示例。

path/to/my_workload

workload=site.ycsb.workloads.CoreWorkload

recordcount=50000

operationcount=3000

insertcount=50000

insertstart=0

fieldcount=2

fieldlength=700

fieldlengthdistribution=zipfian

readproportion=0.7

updateproportion=0.3

insertorder=ordered

requestdistribution=zipfian

實(shí)際系統(tǒng)包含不同的字段長(zhǎng)度，但您只能通過(guò) YCSB 使用固定字段長(zhǎng)度。因此，同時(shí)配置字段 = 1,000,000 和記錄數(shù) =100,000,000，基準(zhǔn)數(shù)據(jù)規(guī)模將與實(shí)際系統(tǒng)的數(shù)據(jù)規(guī)模相差甚遠(yuǎn)。

在這種情況下，運(yùn)行以下兩個(gè)測(cè)試：

●在字段長(zhǎng)度與實(shí)際系統(tǒng)相同的情況下進(jìn)行測(cè)試

●在記錄數(shù)與實(shí)際系統(tǒng)相同的情況下進(jìn)行測(cè)試

測(cè)試模式和架構(gòu)

準(zhǔn)備配置文件后，要考慮測(cè)試條件，包括測(cè)試模式和架構(gòu)。

測(cè)試模式

如果您要對(duì)比不同條件下實(shí)例的性能，應(yīng)當(dāng)定義目標(biāo)條件。在本文中，我們將根據(jù)存儲(chǔ)層使用以下三種內(nèi)存大小模式進(jìn)行測(cè)試。

架構(gòu)

您需要?jiǎng)?chuàng)建 VM 以運(yùn)行基準(zhǔn)腳本。您應(yīng)當(dāng)選擇足夠數(shù)量和虛擬機(jī)類(lèi)型，這樣，在進(jìn)行基準(zhǔn)測(cè)試時(shí)，VM 資源不會(huì)變成瓶頸。在這種情況下，我們要衡量 Memorystore 本身的性能，因此，VM 應(yīng)當(dāng)位于與目標(biāo) Memorystore 相同的區(qū)域，以最大限度減少網(wǎng)絡(luò)延遲的影響。架構(gòu)如下圖所示：

運(yùn)行基準(zhǔn)工具

制定了這些決策后，就可以運(yùn)行基準(zhǔn)工具了。

控制吞吐量模式的運(yùn)行時(shí)選項(xiàng)

您可以通過(guò)使用配置文件中的 operationcount 參數(shù)和 -target命令行選項(xiàng)來(lái)控制客戶(hù)端吞吐量。

以下是執(zhí)行 YCSB 命令的示例：

bin/ycsb run redis -s -P path/to/my_workload -p “redis.host=” -p “redis.port=” -threads 10 -target 10

參數(shù) operationcount=3000 在配置文件中，并運(yùn)行上述命令。這意味著，YCSB 每秒發(fā)送 10 個(gè)請(qǐng)求，總請(qǐng)求數(shù)為 3,000。因此，YCSB 在 300 秒內(nèi)拋出 10 個(gè)請(qǐng)求。

如下所示，您應(yīng)當(dāng)使用增量吞吐量來(lái)運(yùn)行基準(zhǔn)測(cè)試。注意，為了減少離群值的影響，單一基準(zhǔn)測(cè)試運(yùn)行時(shí)間應(yīng)當(dāng)更長(zhǎng)一些：

●客戶(hù)端吞吐量模式：10、100、1,000、10,000、100,000

加載基準(zhǔn)數(shù)據(jù)

運(yùn)行基準(zhǔn)測(cè)試前，您需要為擬測(cè)試的 Memorystore 實(shí)例加載數(shù)據(jù)。以下是加載數(shù)據(jù)的 YCSB 命令的示例：

bin/ycsb load redis -s -P path/to/my_workload -p “redis.host=” -p “redis.port=”

運(yùn)行基準(zhǔn)測(cè)試

現(xiàn)在，您已經(jīng)加載了數(shù)據(jù)并選擇了命令，可以運(yùn)行基準(zhǔn)測(cè)試。調(diào)整進(jìn)程和實(shí)例的數(shù)量以根據(jù)負(fù)載量執(zhí)行 YCSB。為了識(shí)別性能瓶頸，您需要查看多項(xiàng)指標(biāo)。以下是要調(diào)查的典型指標(biāo)：

延遲

針對(duì)每項(xiàng)操作（例如，讀取 (GET) 和更新 (SET)）的 YCSB 輸出延遲統(tǒng)計(jì)信息，例如，平均、最小、最大以及第 95 個(gè)百分位和第 99 個(gè)百分位。根據(jù)客戶(hù)服務(wù)水平協(xié)議 (SLA)，我們建議將第 95 個(gè)百分位或者第 99 個(gè)百分位用于延遲指標(biāo)。

吞吐量

您可以將吞吐量用于整個(gè)操作，這由 YCSB 輸出。

資源使用指標(biāo)

您可以檢查資源使用指標(biāo)，例如，CPU 利用率、內(nèi)存使用、網(wǎng)絡(luò)字節(jié)輸入/輸出以及使用 Cloud Monitoring 監(jiān)控的緩存命中率。

Memorystore 性能調(diào)整最佳實(shí)踐

現(xiàn)在，您已經(jīng)運(yùn)行了基準(zhǔn)測(cè)試，應(yīng)當(dāng)使用基準(zhǔn)測(cè)試結(jié)果來(lái)調(diào)整您的Memorystore。

基于測(cè)試結(jié)果，您可能需要消除 Memorystore 實(shí)例的瓶頸并提升性能。盡管 Memorystore 是一項(xiàng)完全托管的服務(wù)，并且提前對(duì)不同參數(shù)進(jìn)行了優(yōu)化，但仍然會(huì)有您可以基于您的特定用例進(jìn)行調(diào)整的項(xiàng)。

有以下幾個(gè)常見(jiàn)的優(yōu)化方面：

●數(shù)據(jù)存儲(chǔ)優(yōu)化

●內(nèi)存管理

●查詢(xún)優(yōu)化

●監(jiān)控 Memorystore

數(shù)據(jù)存儲(chǔ)優(yōu)化

優(yōu)化數(shù)據(jù)存儲(chǔ)方式，不僅節(jié)省內(nèi)存使用，而且還減少 I/O 和網(wǎng)絡(luò)帶寬。

壓縮數(shù)據(jù)

壓縮數(shù)據(jù)通常會(huì)導(dǎo)致內(nèi)存使用和網(wǎng)絡(luò)帶寬的大幅節(jié)省。

我們建議將 Snappy 和 LZO 工具用于延遲敏感型用例，并使用 GZIP 以實(shí)現(xiàn)最大壓縮率。

由 JSON 轉(zhuǎn)向 MessagePack

Msgpack 和 Protocol Buffers 有與 JSON 相同的模式，但比 JSON 更緊湊。Lua 腳本支持 MessagePack。

使用哈希數(shù)據(jù)結(jié)構(gòu)

哈希數(shù)據(jù)結(jié)構(gòu)可減少內(nèi)存使用。例如，假設(shè)您有通過(guò)查詢(xún) SET “date:20200501” “hoge” 存儲(chǔ)的數(shù)據(jù)。如果您有許多按這樣的連續(xù)日期鍵入的數(shù)據(jù)，通過(guò)將其存儲(chǔ)為 HSET “month:202005” “01” “hoge”，可以減少字典編碼所需要的內(nèi)存使用。但是要注意，當(dāng) hash-map-ziplist-entries 值太高時(shí)，可能導(dǎo)致高 CPU 利用率。

保持實(shí)例大小足夠小

Memorystore 實(shí)例的內(nèi)存大小最高可達(dá) 300GB。不過(guò)，對(duì)于要處理的單一實(shí)例，大于 100GB 的數(shù)據(jù)可能太大，可能由于 CPU 瓶頸導(dǎo)致性能下降。在這種情況下，我們建議創(chuàng)建使用少量?jī)?nèi)存的多個(gè)實(shí)例，對(duì)其進(jìn)行分布，并在應(yīng)用程序端使用鍵變更它們的接入點(diǎn)。

內(nèi)存管理

內(nèi)存的有效使用至關(guān)重要，不僅體現(xiàn)在性能調(diào)整方面，而且也是為了保持您的 Memorystore 實(shí)例穩(wěn)定運(yùn)行，不會(huì)發(fā)生類(lèi)似內(nèi)存溢出 (OOM) 的錯(cuò)誤。有一些您可以用來(lái)管理內(nèi)存的技巧：

制定驅(qū)逐策略

驅(qū)逐策略是在 Memorystore 實(shí)例內(nèi)存已滿(mǎn)時(shí)驅(qū)逐數(shù)據(jù)的規(guī)則。您可以通過(guò)適當(dāng)指定這些參數(shù)來(lái)提高緩存命中率。有以下三組驅(qū)逐策略：

●Noeviction：嘗試插入更多數(shù)據(jù)時(shí)，如果達(dá)到內(nèi)存限制，將返回錯(cuò)誤。

●Allkeys-XXX：驅(qū)逐所選擇的數(shù)據(jù)。XXX 是選擇擬驅(qū)逐的數(shù)據(jù)的算法名。

●Volatile-XXX：通過(guò)設(shè)置“expire”（過(guò)期）字段驅(qū)逐選擇的數(shù)據(jù)。XXX 是選擇擬驅(qū)逐的數(shù)據(jù)的算法名。

volatile-lru 默認(rèn)適用于 Memorystore。為數(shù)據(jù)驅(qū)逐和 TTL 變更數(shù)據(jù)選擇算法。

內(nèi)存碎片整理

當(dāng)操作系統(tǒng)分配內(nèi)存頁(yè)時(shí)會(huì)發(fā)生內(nèi)存碎片整理，Redis 在重復(fù)執(zhí)行寫(xiě)入/刪除操作后無(wú)法充分利用內(nèi)存頁(yè)。此類(lèi)內(nèi)存頁(yè)的累積可能導(dǎo)致系統(tǒng)內(nèi)存不足并最終引發(fā) Redis 服務(wù)器崩潰。

如果您的實(shí)例運(yùn)行 4.0 或更高版本的 Redis，可為您的實(shí)例啟用 activedefrag 參數(shù)。Active Defrag 2 有更智能的策略，并且是 5.0 版 Redis 的組成部分。注意，此功能是對(duì) CPU 使用的一種折衷。

升級(jí) Redis 版本

如前所述，activedefrag 參數(shù)僅適用于 4.0 或更高版本的 Redis，5.0 版有更好的策略。一般而言，采用更新版本的 Redis 能夠以多種方式獲得性能優(yōu)化優(yōu)勢(shì)，而不僅僅是內(nèi)存管理。如果您的 Redis 版本是 3.2，請(qǐng)考慮升級(jí)至 4.0 或更高版本。

查詢(xún)優(yōu)化

由于可在客戶(hù)端執(zhí)行查詢(xún)優(yōu)化并且不涉及對(duì)實(shí)例進(jìn)行任何變更，它是優(yōu)化使用 Memorystore 的現(xiàn)有應(yīng)用程序的最簡(jiǎn)便的方法。

注意，不能通過(guò) YCSB 檢查查詢(xún)優(yōu)化的效果，因此，在您的環(huán)境中運(yùn)行查詢(xún)并檢查延遲和吞吐量。

使用流水線和 mget/mset

當(dāng)連續(xù)執(zhí)行多個(gè)查詢(xún)時(shí)，往返引起的網(wǎng)絡(luò)流量可能成為延遲瓶頸。在這種情況下，建議使用流水線或者聚合命令（例如，MSET/MGET）。

避免對(duì)許多元素執(zhí)行繁重的命令

您可以使用 slowlog 命令監(jiān)控慢命令。使用許多元素的 SORT、LREM 和 SUNION 可能計(jì)算成本很高。檢查這些慢命令是否存在問(wèn)題，如果存在，考慮減少這些操作。

使用 Cloud Monitoring 監(jiān)控 Memorystore

最后，讓我們討論一下通過(guò)資源監(jiān)控以預(yù)測(cè)現(xiàn)有系統(tǒng)的性能下降。您可以使用 Cloud Monitoring 監(jiān)控 Memorystore 的資源狀態(tài)。

即使在部署之前對(duì) Memorystore 進(jìn)行了基準(zhǔn)測(cè)試，生產(chǎn)中的 Memorystore 的性能也可能由于各種影響（例如，系統(tǒng)增長(zhǎng)以及使用趨勢(shì)的變化）而下降。要在早期預(yù)測(cè)此類(lèi)性能下降，您可以創(chuàng)建一個(gè)當(dāng)資源狀態(tài)超過(guò)某個(gè)閾值時(shí)可提醒您或者自動(dòng)擴(kuò)展的系統(tǒng)。