最佳實務 Databases for Redis
如果您使用 Databases for Redis,請花時間檢閱建議的下列最佳作法。
何謂 Databases for Redis?
Databases for Redis 是 IBM Cloud上提供的受管理 Redis OSS 服務。 它是記憶體內 資料結構儲存庫,用作資料庫、快取、訊息分配管理系統及串流引擎。 與將資料儲存在磁碟上的傳統資料庫不同,Redis 會將資料儲存在記憶體 (RAM) 中,以啟用低延遲。 資料是 暫時,可讓 Databases for Redis 提供最高效能和高傳輸量。 您也可以將 Redis 配置為透過使用資料可用性來交換效能,以將資料持續儲存在磁碟上,因為這是透過啟用具有 RBD Snapshot 的 AOF (僅附加檔案) 同步來達成。
RBD Snapshot 已啟用備份及高可用性,即使已停用持續性也一樣。
實例產能規劃的最佳作法
您必須根據您的應用程式和架構設計來規劃 Databases for Redis 實例容量,瞭解硬體需求,並準備增加或減少需求。 下列建議可協助您最佳化實例大小。
- 瞭解您的資料
- 您應該知道資料的資料類型、大小及生命期限。 這可協助您瞭解資料在被刪除或移動之前的記憶體內可用持續時間。
- 預估記憶體需求
- 請務必計算您的記憶體需求。 請記住不僅要考量資料,還要考量抄寫、用戶端連線、記憶體上限緩衝區及 Redis meta 資料所需的記憶體。
- 瞭解讀寫負載
- 識別讀寫負載可協助您準備自動擴充需求、為應用程式要求提供時間,以及維護主要追蹤者同步。
- 瞭解您的 IOPS 需求
- 每秒輸入/輸出作業數是您在實例產能規劃中應該考量的關鍵因素。Databases for Redis 會定期取得 RDB Snapshot,以符合預設 Redis 配置,即使您的實例已設定快取,也會使用磁碟。 非常忙碌的資料庫可能會超出磁碟大小的 IOPS,而增加磁碟大小可以減輕效能瓶頸。
- 規劃備援及重新連接
- 雲端計算涉及多個元件,這可能導致瞬間失敗。 不過,在 IBM® Cloud Databases中,我們提供 99.99% 高可用性,並鼓勵您使用重試及重新連接邏輯來規劃應用程式設計中的連線 blips。
- 考量網路頻寬
- 您的網路頻寬可能會顯著影響 Databases for Redis 效能。 請確定您有足夠的網路頻寬來處理資料庫負載。
- 監測和調整
- 我們的建議是使用 IBM Cloud® Monitoring 監控您的 Databases for Redis 實例效能和使用量,以確定資料庫實例不斷演變的使用模式,並視需要調整大小。
效能最佳作法
- 停用持續性
- 依預設,Databases for Redis 已啟用持續性。 這會寫入 AOF 同步並增加 IOPS 負載。 如果您的應用程式不需要持續保存資料,請使用指令
Set appendonly = no
停用此功能。 如需相關資訊,請參閱:
設定範例快取。 - RAM 對核心
- Redis 是單一執行緒的記憶體內資料庫。 本質上,它需要比 CORE 更多的 RAM,與其他持續性資料庫不同。 即使它是單一執行緒,它也會使用「多工」來處理要求,但所有要求都由執行緒處理。 不過,需要其他核心才能維護其內部處理程序的資料庫完整性和穩定性。 建議您更加關注 Databases for Redis的 RAM 和磁碟 (針對 IOPS)。 如需相關資訊,請參閱 實例產能規劃的最佳作法。
- 縮小記憶體
- 當您減少 Databases for Redis 實例的記憶體時,建議您小心。 因為 Redis 是記憶體內資料庫,所以其記憶體會保留您的資料以供儲存、處理及擷取之用。 大幅減少記憶體可能會暫時停止傳回錯誤的實例,因為沒有足夠的可用空間來完成作業。 例如,假設嘗試在 15 GB 記憶體中載入 20 GB 資料,則此案例會傳回錯誤。
- 避免昂貴的指令
- Redis 中的某些指令執行的成本很高。 例如,經常使用但應該避免的 KEYS 指令。 相反地,請使用 SCAN 指令,它會將反覆運算分散在許多呼叫中,且不會一次佔用整個伺服器。
- 選擇收回原則
- 您應該選擇適用於應用程式的收回原則。 依預設,部署會配置
noeviction
原則。 使用驅逐策略,如allkeys-lru
、volatile-lru
、allkeys-random
、volatile-random
、volatile-ttl
。有關詳細信息,請參閱 內存策略。 - 設定 maxmemory 值
- 您可以調整
maxmemory
值。 不過,請設定合理的限制,否則您的資料可能會耗用所有可用的記憶體,而且您的部署可能會耗盡資源。 依預設,我們將它設為資料節點可用記憶體的 80%。 - 設定 TTL (存活時間) 原則
- TTL 是一個很好的特性,在定義的時間之後,會從資料庫中刪除金鑰。 如果您使用 Redis 快取,這非常有用。 不過,請小心設定非常短或非常長的值,因為非常短的值可以建立值的重新計算,而非常長的值可以建立不必要的記憶體使用。 有關詳細信息,請參閱 TTL 命令。
高可用性的最佳作法
- 重試並重新連接邏輯
- 系統很容易受到干擾。 強烈建議您實作重試,並將邏輯重新連接至應用程式架構,以避免中斷。 請使用 IOREDIS、NODEREDIS 或您選擇的任何其他套件,以確保應用程式的連續性。
有關更多信息,請參閱 使用Redis進行錯誤檢測和處理部落格文章。
監視的最佳作法
您必須監視 LogDNA 是否有下列一般錯誤,並採取更正措施:
- AOF 同步
- 唯讀可用
- 失去與主要伺服器的連線
- 如需防止錯誤的指引,請參閱 如何避免常見的 Databases for Redis 錯誤?。
一般最佳作法
- 連線儲存區 (connection pooling)
- 建立或關閉連線成本高昂。 有效管理連線很重要,而連線儲存區有助於將與開啟及關閉連線相關聯的額外負擔降到最低。 如需詳細資訊,請參閱 連線池。
- 連線限制
- 有效率地使用連線。 Databases for Redis 負載過多連線時會傳回錯誤,您會面臨應用程式中斷的問題。 保留部分連線可用,因為其中一些連線會在內部保留,以維護資料庫的狀態及完整性。 建議您使用連線儲存區。 如需詳細資訊,請參閱 連線限制。
- 連線逾時值
- 為連線設定適當的逾時值也很重要,可避免無限期佔用資源。 不過,請小心設定短暫逾時,因為這可能會導致連線流失及增加延遲。 讓逾時符合您應用程式的作業預期。
- 使用 Redis 管線特性
- Redis 管線化是一種技術,可透過一次發出多個指令而不等待每個個別指令的回應,來增進效能。 如需相關資訊,請參閱 Redis 管線化。
- 使用 Redis Streams 特性
- Redis Streams 是一種資料類型,可提供僅限附加日誌的超快速記憶體內摘要。
- 分割大型資料
- 建議您將大型資料集分割成具有更多索引鍵的較小區塊,亦即將資料分割為多個索引鍵。
- 批次排程
- Databases for Redis 已排定在每天排定的時間建立自動備份。 在此期間,會使用您的資料庫 IOPS。 建議您此時不要執行自己的批次工作。
- 設定通知通道
- 建議您 Databases for Redis 在 IBM Accounts 中設定電子郵件 ID,以接收關於版本變更、使用期限或維護排程的定期更新。 您也可以監視 IBM 帳戶通知圖示,以接收這些更新項目。
有關更多信息,請參閱 IBM Cloud部落格文章上的Redis最佳實踐。