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

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

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

對 Cloud Memorystore 進行基準測試

首先，讓我們看一下如何衡量基準。

選擇基準工具

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

●Redis-benchmark

●Memtier-benchmark

●YCSB

●PerfKit Benchmark

在本文中，我們將使用 YCSB，因為它具有靈活控制流量和字段模式的特點，并且在社區(qū)得到很好維護。

分析您的應用的流量模式

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

要配置基準工具，需要以下信息：

●每個記錄的字段數量

●記錄數

●每行的字段長度

●查詢模式，例如，SET（設置）和GET（獲?。┍嚷?/span>

●正常和高峰時段的吞吐量

基于實際流量模式配置基準工具

針對特定用例進行性能基準測試時，重要的是通過考慮表數據模式、查詢模式和實際系統(tǒng)的流量模式來設計基準內容。

在此，我們將假設以下要求。

●表的每行有兩個字段

●字段最大長度為 1,000,000

●最大記錄數為 1 億

●查詢模式的 GET:SET 比為 7:3

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

YCSB 可通過配置文件控制基準模式。以下是使用這些要求的示例。

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

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

在這種情況下，運行以下兩個測試：

●在字段長度與實際系統(tǒng)相同的情況下進行測試

●在記錄數與實際系統(tǒng)相同的情況下進行測試

測試模式和架構

準備配置文件后，要考慮測試條件，包括測試模式和架構。

測試模式

如果您要對比不同條件下實例的性能，應當定義目標條件。在本文中，我們將根據存儲層使用以下三種內存大小模式進行測試。

架構

您需要創(chuàng)建 VM 以運行基準腳本。您應當選擇足夠數量和虛擬機類型，這樣，在進行基準測試時，VM 資源不會變成瓶頸。在這種情況下，我們要衡量 Memorystore 本身的性能，因此，VM 應當位于與目標 Memorystore 相同的區(qū)域，以最大限度減少網絡延遲的影響。架構如下圖所示：

運行基準工具

制定了這些決策后，就可以運行基準工具了。

控制吞吐量模式的運行時選項

您可以通過使用配置文件中的 operationcount 參數和 -target命令行選項來控制客戶端吞吐量。

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

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

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

如下所示，您應當使用增量吞吐量來運行基準測試。注意，為了減少離群值的影響，單一基準測試運行時間應當更長一些：

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

加載基準數據

運行基準測試前，您需要為擬測試的 Memorystore 實例加載數據。以下是加載數據的 YCSB 命令的示例：

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

運行基準測試

現在，您已經加載了數據并選擇了命令，可以運行基準測試。調整進程和實例的數量以根據負載量執(zhí)行 YCSB。為了識別性能瓶頸，您需要查看多項指標。以下是要調查的典型指標：

延遲

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

吞吐量

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

資源使用指標

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

Memorystore 性能調整最佳實踐

現在，您已經運行了基準測試，應當使用基準測試結果來調整您的Memorystore。

基于測試結果，您可能需要消除 Memorystore 實例的瓶頸并提升性能。盡管 Memorystore 是一項完全托管的服務，并且提前對不同參數進行了優(yōu)化，但仍然會有您可以基于您的特定用例進行調整的項。

有以下幾個常見的優(yōu)化方面：

●數據存儲優(yōu)化

●內存管理

●查詢優(yōu)化

●監(jiān)控 Memorystore

數據存儲優(yōu)化

優(yōu)化數據存儲方式，不僅節(jié)省內存使用，而且還減少 I/O 和網絡帶寬。

壓縮數據

壓縮數據通常會導致內存使用和網絡帶寬的大幅節(jié)省。

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

由 JSON 轉向 MessagePack

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

使用哈希數據結構

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

保持實例大小足夠小

Memorystore 實例的內存大小最高可達 300GB。不過，對于要處理的單一實例，大于 100GB 的數據可能太大，可能由于 CPU 瓶頸導致性能下降。在這種情況下，我們建議創(chuàng)建使用少量內存的多個實例，對其進行分布，并在應用程序端使用鍵變更它們的接入點。

內存管理

內存的有效使用至關重要，不僅體現在性能調整方面，而且也是為了保持您的 Memorystore 實例穩(wěn)定運行，不會發(fā)生類似內存溢出 (OOM) 的錯誤。有一些您可以用來管理內存的技巧：

制定驅逐策略

驅逐策略是在 Memorystore 實例內存已滿時驅逐數據的規(guī)則。您可以通過適當指定這些參數來提高緩存命中率。有以下三組驅逐策略：

●Noeviction：嘗試插入更多數據時，如果達到內存限制，將返回錯誤。

●Allkeys-XXX：驅逐所選擇的數據。XXX 是選擇擬驅逐的數據的算法名。

●Volatile-XXX：通過設置“expire”（過期）字段驅逐選擇的數據。XXX 是選擇擬驅逐的數據的算法名。

volatile-lru 默認適用于 Memorystore。為數據驅逐和 TTL 變更數據選擇算法。

內存碎片整理

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

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

升級 Redis 版本

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

查詢優(yōu)化

由于可在客戶端執(zhí)行查詢優(yōu)化并且不涉及對實例進行任何變更，它是優(yōu)化使用 Memorystore 的現有應用程序的最簡便的方法。

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

使用流水線和 mget/mset

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

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

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

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

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

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