資料與儲存 2026 年 5 月 16 日

2026-05-16 — Redis 驚群效應七種防護、CloudNativePG CVE-2026-44477 CVSS 9.4

primary=https://redis.io/en/blog/how-to-tame-the-thundering-herd-problem/ primary=https://www.postgresql.org/about/news/cloudnativepg-1291-and-1283-released-critical-cve-fix-3296/

驚群效應的工程解法:Redis 的七種防護模式

Redis Blog · 2026-05-13

Redis 官方技術部落格在 2026 年 5 月發表了驚群效應(thundering herd problem)的完整解析,涵蓋問題根因、七種緩解模式,以及 Redis 在各模式中的具體實作方式。

原本的問題

驚群效應的典型觸發場景是快取集中失效:多個 key 同時過期,數百個請求同一時刻打到後端資料庫,造成延遲尖峰、資料庫過載、甚至雪崩性故障。問題不在 Redis 本身,而在於不恰當的 TTL 配置導致失效時刻同步化,以及缺乏並發存取協調機制。

採用的方法

文章描述七種防護模式:

  • TTL Jitter(隨機化過期時間):在固定 TTL 上加入隨機偏差(如 55–65 分鐘取代固定 60 分鐘),將失效分散至時間軸上,最直接且成本最低。
  • Request Coalescing(請求合併 / 分散式鎖):只允許一個請求進行後端查詢,其餘等待。透過 Redis 分散式鎖(SET NX EX)協調。Lua script 可原子性地標記「正在查詢中」,防止重複後端呼叫。
  • Rate Limiting(速率限制):以 Token Bucket 或原子計數器(INCR/EXPIRE)限制每個 IP 或 API key 的請求速率,控制瞬間流量峰值。
  • Load Shedding + Queue(負載卸除 + 佇列):高負載時捨棄非關鍵請求,將請求寫入 Redis Streams 作為緩衝,由後台消費者以可控速率處理,用戶端感受輕微延遲而非系統崩潰。
  • Bloom Filter(布隆過濾器):在快取層前加一個 Bloom Filter,過濾掉對不存在 key 的查詢(cache penetration),防止攻擊者利用無效 key 穿透快取打穿資料庫。
  • In-Memory Caching(熱點資料記憶體快取):維持高快取命中率,讓驚群效應無法到達資料庫層。
  • Proactive Refresh(主動預刷新):在熱點 key 到期前主動更新,可透過 Redis Pub/Sub 或 Streams 的事件驅動失效通知觸發,也可直接在應用層設定提前刷新閾值。

實際效果

文章強調這些模式並非互斥,TTL Jitter + Request Coalescing 的組合通常能解決大多數驚群問題。Redis 在此扮演三重角色:分散式鎖的協調器、速率限制的計數器、以及 Streams 的請求緩衝區。文章也指出 Amazon ElastiCache 與 Google Memorystore 因被凍結在舊版 Redis/Valkey,缺少 Redis Streams 與 Active-Active 等企業功能,這些模式的可用性因部署環境而有差異。

原始來源:Redis Blog


CloudNativePG CVE-2026-44477:metrics exporter 超級用戶降權繞過,CVSS 9.4

PostgreSQL News · 2026-05-15

CloudNativePG 在 2026 年 5 月 15 日發佈 1.29.11.28.3 緊急維護版,修補 CVE-2026-44477(GHSA-423p-g724-fr39,CVSS v4 9.4),漏洞允許低權限資料庫角色透過 metrics 抓取工作階段取得 PostgreSQL 超級用戶權限,進而在 primary pod 內執行任意 OS 命令。

漏洞機制

CloudNativePG 的 metrics exporter 原本以 postgres 超級用戶建立 PostgreSQL 連線,然後在工作階段內執行 SET ROLE pg_monitor 嘗試降低權限。這個降權是不完整的session_user 仍為 postgres,因此工作階段內的任意 SQL 可執行 RESET ROLE 重新取得完整超級用戶特權。攻擊者獲得超級用戶權限後,可透過 COPY ... TO PROGRAM 語法在 primary pod 內生成任意作業系統進程。

更嚴重的是:預設組態即可觸發。隨附的 pg_extensions metric 查詢已足以啟動完整攻擊鏈,且由 bootstrap.initdb 自動建立的 app 角色(所有預設叢集都有)就能完成利用,無需自訂 metric,攻擊視窗僅需一個抓取間隔(≤30 秒)。

受影響版本

  • 1.29.x(1.29.1 之前)
  • 1.28.x(1.28.3 之前)

修補與緩解

主要修補(PR #10576)建立了專用的 cnpg_metrics_exporter PostgreSQL 角色,僅具 pg_monitor 成員資格,透過 pg_ident.conf peer 認證映射(與 PgBouncer pooler 角色的處理方式相同),exporter 不再以超級用戶身分連線。所有隨附的監控查詢也加上了明確的 pg_catalog. 前綴,防止非限定的 relation/function 引用被替換為惡意版本。此次版本也一併升級 github.com/jackc/pgx/v5 至 v5.9.2(修補 CVE-2026-33816 與 GHSA-j88v-2chj-qfwx)及 Go 1.26.3 runtime(修補六個 CVE)。建議立即升級,無可行的外部緩解措施。

原始來源:PostgreSQL NewsGHSA-423p-g724-fr39


End of article
0
Would love your thoughts, please comment.x
()
x