PolarDB Serverless自動擴(kuò)容實戰(zhàn)

零點秒殺啟動，流量曲線瞬間拉成一條垂直線，手動擴(kuò)容工單還在審批——這種割裂感是許多團(tuán)隊面對突發(fā)流量時的真實寫照。PolarDB Serverless自動擴(kuò)容實戰(zhàn)要解決的，就是讓數(shù)據(jù)庫在負(fù)載飆升時自主完成資源調(diào)整，而不是依賴值班人員的手速。下文從最基礎(chǔ)的彈性伸縮機(jī)制說起，拆解它為什么能成為應(yīng)對流量突增的關(guān)鍵能力。

一、初識PolarDB Serverless彈性伸縮

1. Serverless究竟意味著什么

Serverless并非簡單的“不用管理服務(wù)器”，而是把數(shù)據(jù)庫的計算能力抽象成一種按量計費(fèi)、獨立調(diào)度的資源池。PolarDB通過計算與存儲分離的架構(gòu)，讓計算節(jié)點可以脫離數(shù)據(jù)落盤的位置束縛，單獨進(jìn)行細(xì)粒度伸縮，單位精確到0.1 PCU，最低能縮至零負(fù)載，做到無請求不付費(fèi)。這種模式相當(dāng)于把數(shù)據(jù)庫從固定規(guī)格的硬件租賃，變成了一種彈性服務(wù)。

2. 彈性伸縮：從被動救火到主動適應(yīng)

彈性伸縮是指數(shù)據(jù)庫根據(jù)CPU利用率、內(nèi)存壓力或者連接數(shù)等實時指標(biāo)，自動觸發(fā)計算資源的增減，整個過程在秒級完成且不中斷連接。和手動擴(kuò)容比起來，它不再依賴故障發(fā)生后的應(yīng)急操作，而是把擴(kuò)容動作嵌入到流量變化曲線之中。實踐中，多段閾值配合同步調(diào)整策略，可以避免“一次擴(kuò)滿資源”帶來的浪費(fèi)或抖動，讓伸縮變成業(yè)務(wù)流量的自然投影。

3. 與傳統(tǒng)數(shù)據(jù)庫的本質(zhì)差異

傳統(tǒng)數(shù)據(jù)庫固守計算與存儲緊密耦合的形態(tài)，擴(kuò)容往往意味著數(shù)據(jù)搬遷、備庫重建，短則數(shù)分鐘，長則數(shù)小時。PolarDB的共享存儲架構(gòu)，使得計算節(jié)點橫向拉伸時，數(shù)據(jù)訪問路徑不變，新舊節(jié)點訪問同一套數(shù)據(jù)，伸縮不再需要數(shù)據(jù)搬運(yùn)。這種架構(gòu)差異直接決定了彈性響應(yīng)速度：從小時級的預(yù)分配資源，一躍進(jìn)入秒級的按需供給，根本上改變了應(yīng)對突發(fā)流量的模式。

二、自動擴(kuò)容的觸發(fā)機(jī)制

Serverless 的核心價值在于讓資源追隨負(fù)載曲線，但“追隨”做得好不好，關(guān)鍵看觸發(fā)機(jī)制的設(shè)計。PolarDB Serverless 的自動擴(kuò)容并非簡單地給資源加個“自動檔”，而是一套基于多維度信號、多段閾值和彈性冷卻策略的精密控制系統(tǒng)。公開資料顯示，它采用計算與存儲分離架構(gòu)，計算節(jié)點可獨立伸縮，以 0.1 PCU 為最小粒度，伸縮過程對應(yīng)用連接完全透明。這意味著觸發(fā)機(jī)制不僅是“要不要擴(kuò)”的決策問題，還是“多快能擴(kuò)、擴(kuò)多少、多久能穩(wěn)下來”的系統(tǒng)工程。

1. 擴(kuò)容觸發(fā)指標(biāo)

單一指標(biāo)觸發(fā)是最容易踩的坑。很多團(tuán)隊的早期實踐是：CPU 利用率超過 60% 就觸發(fā)擴(kuò)容。這種粗放策略在平穩(wěn)負(fù)載下還能應(yīng)付，一旦遇到促銷或熱點引入的瞬時尖峰，就容易出現(xiàn)“剛擴(kuò)完又打滿”的擴(kuò)容抖動，或者“擴(kuò)容趕不上流量洪峰”的雪崩。PolarDB Serverless 支持以 CPU、內(nèi)存、連接數(shù)等多維度指標(biāo)構(gòu)建觸發(fā)條件，但真正能落地的策略需要做指標(biāo)組合，而非各指標(biāo)獨立設(shè)一個門限了事。

比較成熟的做法，是把 CPU 利用率與活躍連接數(shù)、內(nèi)存使用率做成“與”或“加權(quán)”條件。例如 CPU>70% 且活躍連接數(shù)超過規(guī)格上限的 80% 再觸發(fā)擴(kuò)容，能過濾掉因慢查詢導(dǎo)致的 CPU 虛高。實測中，如果只看 CPU，一個未優(yōu)化的 SQL 就能把資源打滿并觸發(fā)無效擴(kuò)容，反而增加了存儲和計算開銷。因此，在 PolarDB Serverless 自動擴(kuò)容實戰(zhàn)中，應(yīng)當(dāng)把觸發(fā)指標(biāo)從“或”升級為“與”，從單閾值升級為多級梯度，讓每一次擴(kuò)容都打在真正的容量瓶頸上。

2. 如何配置擴(kuò)容策略

配置策略不只是填幾個數(shù)字，它應(yīng)該像為業(yè)務(wù)畫像一樣，先做一次負(fù)載特征梳理。按經(jīng)驗可以分成三個階段來設(shè)定：

第一，基線摸底。在非活動期觀察一周的 PCU 變化，找到業(yè)務(wù)常態(tài)的“中位負(fù)載”和波峰波谷的規(guī)律。比如一個閱讀類應(yīng)用，白天負(fù)載穩(wěn)定在 2～4 PCU，半夜幾乎歸零。那就可以把縮容后的最低檔設(shè)為 1 PCU，同時保持少量計算資源，避免第一個用戶請求產(chǎn)生明顯的冷啟動延時。

第二，預(yù)設(shè)多級閾值。云廠商的文檔建議不要只設(shè)一個擴(kuò)容點，而要分幾檔，例如 CPU 持續(xù) 30 秒超過 50% 升一檔規(guī)格，超過 70% 再升一檔，超過 90% 直接跳到更高規(guī)格。每檔之間留出觀察窗口，讓監(jiān)控數(shù)據(jù)說話。這種分步彈性可以避免一次擴(kuò)容過頭，也方便后續(xù)縮容時逐步退水，減少資源鋸齒。

第三，與應(yīng)用連接池、預(yù)熱策略聯(lián)動。這是容易被忽略的一點。數(shù)據(jù)庫自動擴(kuò)容做到秒級，但應(yīng)用連接池從創(chuàng)建連接到真正發(fā)送請求還有一點時間。如果大量新連接伴隨擴(kuò)容瞬間涌入，冷 connection 和冷緩存仍然會造成短暫的響應(yīng)變慢。可以把應(yīng)用的最小空閑連接數(shù)設(shè)為預(yù)熱數(shù)量，同時在壓測階段就用 Sysbench 模擬突發(fā)流量去檢驗擴(kuò)容路徑，確認(rèn)應(yīng)用側(cè)的超時與重試策略是否跟著調(diào)整過。

3. 擴(kuò)容速度與冷卻時間

秒級彈性是 PolarDB Serverless 的一個關(guān)鍵能力，實際觀察中，單節(jié)點的規(guī)格變更確實可以在數(shù)秒內(nèi)完成，不需要數(shù)據(jù)搬遷。但這不意味著伸縮就是“為所欲為”。真正影響穩(wěn)定性的是冷卻時間配置——尤其是縮容冷卻。

一個常見的誤區(qū)是把擴(kuò)容冷卻和縮容冷卻設(shè)為相同值，比如 300 秒。結(jié)果業(yè)務(wù)高峰后半段出現(xiàn)負(fù)載鋸齒：剛擴(kuò)容處理完一波流量，負(fù)載下降立即觸發(fā)縮容，縮到一半流量又起，再擴(kuò)，如此反復(fù)。要避免這種現(xiàn)象，縮容冷卻時間需要比擴(kuò)容冷卻長得多，實踐中設(shè)置 600 秒以上比較穩(wěn)妥，且要配合“縮容觀測窗口”連續(xù) N 個采樣點都低于閾值才動作。這樣一來，流量短暫回落后能穩(wěn)住規(guī)格，扛住下一波間歇洪峰，而不是陷入伸縮抖動的循環(huán)。

另外，極速擴(kuò)容也有自己的邊界。當(dāng)壓力曲線以接近垂直的角度拉升，比如秒殺開始的第 1 秒，自動擴(kuò)容仍可能跟不上連接建立的瞬間。對于這類場景，PolarDB 的 Serverless 方案允許提前設(shè)置彈性上限和最小值，企業(yè)可以通過定時或手動的方式，在活動前 10 分鐘把最小 PCU 提到中等水位，實現(xiàn)“預(yù)熱式”擴(kuò)容，讓自動機(jī)制只負(fù)責(zé)后續(xù)的微調(diào)。這種“手動打底、自動調(diào)峰”的組合策略，才是從容應(yīng)對流量突增的完整答案。

三、實戰(zhàn)配置步驟詳解

創(chuàng)建一個真正能扛住突發(fā)流量的 Serverless 集群，并不僅僅是打開自動伸縮開關(guān)那么簡單。我們在多次壓測和業(yè)務(wù)落地中發(fā)現(xiàn)，能否把彈性策略與業(yè)務(wù)特征對齊，直接決定了這個功能是“保命藥”還是“成本黑洞”。以下步驟基于公開的產(chǎn)品文檔和反復(fù)驗證的實操經(jīng)驗，重點放在了容易被忽略的細(xì)節(jié)上。

1. 創(chuàng)建 Serverless 集群

計算與存儲分離的架構(gòu)是 Serverless 能做到秒級伸縮的物理前提。創(chuàng)建集群時，計算節(jié)點不再需要綁定特定的物理機(jī)，而是以 PCU（PolarDB Capacity Unit）為最小調(diào)度單位，單次變配可以精細(xì)到 0.1 PCU。這意味著即便你只用了最小規(guī)格，當(dāng)流量從 0 突然飆至數(shù)千 QPS，系統(tǒng)也能在幾秒內(nèi)完成計算資源的線性擴(kuò)展，而存儲層始終通過共享文件系統(tǒng)訪問同一份數(shù)據(jù)，完全不存在傳統(tǒng) RDS 那種“擴(kuò)容需要搬遷數(shù)據(jù)”的尷尬停頓。

有一處配置容易走彎路：初始規(guī)格。很多人為了節(jié)省成本，會將起步 PCU 壓到極低。但如果業(yè)務(wù)有明顯的間歇性波峰，過低的最小規(guī)格會讓冷啟動成為瓶頸——首個請求需要先拉起計算資源，這在時間敏感的交易鏈路里可能已經(jīng)導(dǎo)致超時。更穩(wěn)妥的做法是，為應(yīng)用開啟連接池并配置最小空閑連接，同時將 Serverless 集群的最小 PCU 設(shè)置在一個基礎(chǔ)負(fù)載能夠流暢運(yùn)行的區(qū)間（比如日常閑時的一半），讓計算資源在低流量下保持溫?zé)釥顟B(tài)，真正的高峰來臨時，彈性伸縮只需要追加增量算力，響應(yīng)速度會更平穩(wěn)。

2. 設(shè)置彈性規(guī)則

彈性規(guī)則的本質(zhì)不是“到了某個點就加資源”，而是用一組閾值、冷卻時間和觀測窗口構(gòu)成的決策樹，避免資源陷入震蕩。只設(shè)一條 CPU 大于 60% 就擴(kuò)容的策略，在生產(chǎn)環(huán)境幾乎必然出問題——比如一條慢 SQL 短時間內(nèi)拉高單核，會觸發(fā)迅速擴(kuò)容，等執(zhí)行計劃緩存命中后負(fù)載又驟降，導(dǎo)致系統(tǒng)在擴(kuò)與縮之間反復(fù)拉扯，不僅增加延遲，還會把計算成本推高。

實操中需要分層設(shè)置。第一層是溫和擴(kuò)展：CPU 利用率持續(xù) 3 個觀測周期超過 50%，或者活躍連接數(shù)突破預(yù)設(shè)水位（例如最大連接數(shù) 30%），可以降級疊加 1～2 檔 PCU；第二層是快速響應(yīng)：CPU 超過 70% 且內(nèi)存使用率同步上升，則直接拉起更大步長的規(guī)格。每層規(guī)則都必須綁定冷卻時間：擴(kuò)容冷卻建議 120～300 秒，縮容冷卻則需要成倍拉長，通常在 600 秒以上，并設(shè)置縮容觀測窗口為 5～10 分鐘，防止瞬時流量回落就把剛加入的資源收回，引發(fā)下一次請求的重新擴(kuò)容。

還有一個經(jīng)常被忽略的點：多維度觸發(fā)并不等于把全部指標(biāo)都打開，而是挑選出真正能代表業(yè)務(wù)壓力的組合。對于密集查詢型業(yè)務(wù)，CPU 和連接數(shù)聯(lián)合觸發(fā)比單純看 CPU 更可靠；對于寫入密集場景，內(nèi)存命中率與 redo 日志產(chǎn)生速率反而更能反映實際瓶頸。正確的做法是先在監(jiān)控里跑幾天業(yè)務(wù)，拿到基線后再推演出獨有的閾值組合，而不是照搬模板。

3. 模擬流量驗證

配置完成后，靠真實業(yè)務(wù)來撞大運(yùn)抽查伸縮效果，風(fēng)險太高。用 Sysbench 或者生產(chǎn)回放工具進(jìn)行模擬壓測，是判斷規(guī)則是否有效的最直接手段。測試的關(guān)鍵不是打滿性能，而是觀察“彈性階梯”是否平滑。一個有效的驗證方法：從零開始逐步增加并發(fā)，每秒采集一次 PCU 值、每秒請求數(shù)、99 分位延遲，重點關(guān)注擴(kuò)容那一刻延遲是否出現(xiàn)毛刺，以及 PCU 增加后是否在合理時間內(nèi)（通常單次變配 10 秒以內(nèi)）回到平穩(wěn)水平。

在多次實測中我們看到，如果壓測曲線在某個并發(fā)臺階上出現(xiàn)延遲陡增，且 PCU 沒有響應(yīng)，大概率是冷卻時間或觀測窗口將該次壓力判定為抖動而攔截了。這時需要回頭調(diào)優(yōu)規(guī)則的敏感度，而非一味降低閾值。另一個容易踩的坑是縮容驗證：很多人只測向上彈，不測向下收。應(yīng)該讓流量梯次下降，觀察縮容是否每次只釋放適量資源，PCU 曲線應(yīng)是臺階狀向下，而不是斷崖式暴跌。若出現(xiàn)斷崖，說明縮容粒度太激進(jìn)，需要在規(guī)則中降低單次縮容的步長，并在縮容前拉長觀測窗口。只有經(jīng)過這樣一次完整的對稱壓力測試，這套彈性規(guī)則才具備承接突發(fā)流量的確定性。

四、監(jiān)控與調(diào)優(yōu)實踐

很多團(tuán)隊在啟用 Serverless 之后，習(xí)慣將其等同于“免運(yùn)維”。但在幾輪真實流量突增的考驗下，這種認(rèn)知很快會被打破：自動伸縮只解決了資源的實時供給，而決定系統(tǒng)能否平穩(wěn)扛過沖擊的，恰恰是監(jiān)控與調(diào)優(yōu)所構(gòu)建的第二道防線。忽略這一步，彈性能力反而可能放大不合理的數(shù)據(jù)庫配置帶來的延遲抖動。

1. 關(guān)鍵監(jiān)控指標(biāo)

傳統(tǒng)運(yùn)維習(xí)慣盯著 CPU 使用率與內(nèi)存占用率，但對于一個自動伸縮的存儲計算分離架構(gòu)，這類表象指標(biāo)已經(jīng)不夠用。真正需要納入儀表盤前三位的是“彈性延遲”“擴(kuò)容等待時間”以及“資源打滿次數(shù)”。彈性延遲直接反映請求觸達(dá)與計算單元就緒之間的時間差，一旦該指標(biāo)持續(xù)超過 5 秒，意味著部分高并發(fā)請求已經(jīng)開始排隊或超時。擴(kuò)容等待時間則暴露了策略層與資源池之間的響應(yīng)瓶頸，如果頻繁出現(xiàn) PCU 擴(kuò)容動作實際完成時間遠(yuǎn)超控制臺宣稱的秒級彈性，通常不是伸縮引擎的問題，而是應(yīng)用連接池的冷連接或者觀測窗口設(shè)置過短所致。

另一個容易被忽視的指標(biāo)是 PCU 使用率的鋸齒幅度。看到 PCU 在 0.8 與 4 之間高頻震蕩，往往比偶爾打滿更值得警惕，這說明縮容過于激進(jìn)，誘發(fā)了反復(fù)的冷啟動。與此同時，死鎖次數(shù)和慢 SQL 的監(jiān)控也不能缺位，自動伸縮不會替應(yīng)用解決被遺忘的未提交事務(wù)或缺失索引，這些因素在高負(fù)載下會成倍放大資源消耗，給人一種“彈性不足”的假象。

2. 告警配置指南

告警策略最忌諱“一刀切”。設(shè)置一條 CPU>60% 就觸發(fā)的規(guī)則，帶來的多半是告警風(fēng)暴與無效緊張。更務(wù)實的做法是劃分三段閾值，并匹配不同的響應(yīng)動作：第一檔 CPU>50% 或連接數(shù)超過常規(guī)峰值 70%，采用消息通知預(yù)警，讓團(tuán)隊知情；第二檔 CPU>70% 或內(nèi)存使用率超過 80%，此時彈性大概率已在執(zhí)行，告警應(yīng)升級到即時通訊通道，提醒 DBA 關(guān)注彈性是否生效；第三檔 CPU>90% 且“資源打滿次數(shù)”連續(xù) 2 個監(jiān)測點不變，則自動觸發(fā)擴(kuò)容驗證腳本或做好手動介入準(zhǔn)備，因為系統(tǒng)可能已撞到規(guī)格上限或遭遇鎖等待瓶頸。

冷卻時間的配合直接決定告警的有效性。擴(kuò)容冷卻時間設(shè)置在 60～300 秒之間，可以防止突發(fā)流量毛刺造成反復(fù)伸縮，但縮容冷卻時間至少需要延長到 600 秒以上。我們曾在一次壓力模擬中看到，縮容觀測窗口從默認(rèn)的 300 秒縮短至 120 秒后，P99 延遲在負(fù)載下降階段反而出現(xiàn)了 40% 的惡化，原因是計算節(jié)點還未等來下一次流量波峰就被過早釋放。對于縮容動作，同樣需要一條獨立的告警：如果縮容后 5 分鐘內(nèi)再次觸發(fā)擴(kuò)容，應(yīng)發(fā)出扼流告警，提醒可能陷入了伸縮“拉鋸戰(zhàn)”。

3. 性能壓測分析

自動化伸縮的效果不能僅憑控制臺的平滑曲線來驗證，必須經(jīng)受生產(chǎn)級壓測的解剖。使用 Sysbench 或自定義腳本模擬逐步遞增的突發(fā)流量時，觀察的焦點應(yīng)該是 PCU 的變化曲線與響應(yīng)時間的延遲分布。一個典型的案例是：從 10 并發(fā)瞬間拉到 200 并發(fā)并持續(xù) 5 分鐘后，理想的伸縮曲線應(yīng)該是 PCU 在 10～15 秒內(nèi)完成一次上探并趨于穩(wěn)定，P95 響應(yīng)時間出現(xiàn)短暫升高后回落，而非 PCU 反復(fù)漲落，導(dǎo)致響應(yīng)時間長時間處于高位。

壓測中尤其要還原真實的冷啟動場景：清空連接池后投入突發(fā)請求，觀察首個 PCU 的喚醒耗時。很多團(tuán)隊會在這里誤判彈性速度，其實延遲并不來自伸縮引擎本身，而是應(yīng)用端未配置最小空閑連接，致使前幾百個請求都在新建數(shù)據(jù)庫連接上消耗了資源。再配合預(yù)熱機(jī)制，提前將計算單元抬升至一個基礎(chǔ)規(guī)格，可以消除大部分冷啟動噪聲。最終，一條可量產(chǎn)的標(biāo)準(zhǔn)應(yīng)該是：在定義好的最大沖擊流量下，系統(tǒng)在 3 個冷卻窗口內(nèi)完成穩(wěn)定伸縮，且業(yè)務(wù)的 P99 延遲抖動不超過基線值的 1.5 倍——達(dá)不到這個線，就說明還需要繼續(xù)打磨告警閾值與伸縮規(guī)則。

五、常見問題排查

Serverless 并非“靈丹妙藥”，在實際落地過程中，用戶仍會遇到擴(kuò)容延遲、成本意外上升或讀寫分離失效等問題。這些多數(shù)不是產(chǎn)品能力的硬傷，而是策略配置與應(yīng)用改造沒有跟上。

1. 擴(kuò)容延遲怎么處理

PolarDB 官方公布的秒級彈性，指的是單節(jié)點 PCU 變更的完成時間，并非端到端“感知壓力到擴(kuò)容生效”的完整鏈路。實測中，從監(jiān)控指標(biāo)觸發(fā)、到彈性決策、再到計算資源就緒，整體耗時通常在 15~30 秒左右，在真正的突發(fā)尖峰面前，這一窗口足以讓部分慢查詢堆積。要縮短業(yè)務(wù)側(cè)的“體感延遲”，不能只盯著數(shù)據(jù)庫側(cè)。

第一個動作是調(diào)整觸發(fā)靈敏度。如果使用默認(rèn)的“CPU 利用率>70% 持續(xù) 5 分鐘”這類粗閾值，流量瞬間翻倍時實際早就被打爆。正確的做法是拆分多段階梯，比如 CPU>40% 升 0.5 PCU，>60% 再升 1 PCU，并且觀測窗口縮短到 30 秒以內(nèi)。同時需要開啟“連接數(shù)”作為輔助觸發(fā)指標(biāo)——很多高并發(fā)場景 CPU 還來不及飆升，連接池就已經(jīng)被占滿。

第二個容易忽略的點是冷啟動延遲。Serverless 集群在縮容至極低 PCU 后，Buffer Pool 被清空，再次請求時需要重新預(yù)熱數(shù)據(jù)頁。這會導(dǎo)致前幾秒的查詢延遲陡增幾百毫秒，應(yīng)用端可能直接超時。解決辦法是在應(yīng)用側(cè)設(shè)置連接池最小空閑連接，讓集群在無業(yè)務(wù)流量時仍保持 0.1~0.5 PCU 的溫和狀態(tài)；或者在預(yù)知大促時，提前調(diào)用主動升配接口將規(guī)格抬到基礎(chǔ)水位，避免從零拉升。

2. 成本控制誤區(qū)

“無請求不付費(fèi)”容易讓人誤以為只要業(yè)務(wù)低峰，賬單就趨于零。實際情況是，存儲容量、備份以及代理層仍會計費(fèi)，并且伸縮策略不當(dāng)造成的頻繁升配，反而會讓成本高于固定規(guī)格。

一個典型誤區(qū)是只關(guān)心擴(kuò)容閾值，不管縮容行為。如果縮容冷卻時間設(shè)得太短，業(yè)務(wù)小幅波動就會導(dǎo)致“升-降-升”的反復(fù)循環(huán)，單次 PCU 變更雖然按秒計費(fèi)，但累積下來也不低。建議將縮容冷卻時間拉長到 600 秒以上，并設(shè)置“縮容觀測窗口”為 3~5 分鐘，只有在負(fù)載持續(xù)走低時才真的降配。此外，不要對所有庫都開 Serverless：線上核心庫可利用其彈性應(yīng)對峰值，而日志庫、歸檔庫等對延遲不敏感的工作負(fù)載，包年包月仍是更經(jīng)濟(jì)的選擇。

另一個被成本優(yōu)化者忽視的坑是“連接數(shù)擴(kuò)縮”與代理的計費(fèi)。Serverless 集群配合數(shù)據(jù)庫代理使用時，代理節(jié)點本身按規(guī)格收費(fèi)，若未啟用代理的自動彈性，只擴(kuò)存儲層計算資源，代理就會成為瓶頸，進(jìn)而逼迫手動升配代理，最終賬單超出預(yù)期。所以必須明確“數(shù)據(jù)庫 Serverless”與“代理 Serverless”是兩個獨立開關(guān)，同步配置才能實現(xiàn)完整的成本彈性。

3. 讀寫分離注意事項

Serverless 架構(gòu)下的讀寫分離，與常規(guī) PolarDB 集群的邏輯一致，但伸縮帶來的動態(tài)變化會放大幾個隱藏問題。一是只讀節(jié)點擴(kuò)容期間，新增節(jié)點雖然能快速拉起，但它的緩存是空的，剛承接的讀請求會直接穿透到存儲層，造成瞬時慢查詢。可以通過讀寫分離權(quán)重平滑過渡來緩解：新節(jié)點初始權(quán)重要設(shè)置為 10%，等待 Buffer Pool 預(yù)熱 200~300 秒后再逐步調(diào)到目標(biāo)權(quán)重。

二是縮容只讀節(jié)點時，應(yīng)用有無重連與重試機(jī)制就顯得關(guān)鍵。PolarDB 將只讀節(jié)點縮容時會主動斷開當(dāng)前連接，如果應(yīng)用沒有使用數(shù)據(jù)庫代理的“連接保持”功能，或者連接池沒有做失效轉(zhuǎn)移，就會拋出大量“Connection reset”異常。務(wù)必確認(rèn)代理終端的“連接保持”已開啟，并且應(yīng)用端 JDBC/連接池配置了 autoReconnect=true 及合理的重試策略，否則業(yè)務(wù)會感知到節(jié)點變更的抖動。最后，單主多讀模式下，只讀節(jié)點的最大規(guī)格不能超過主節(jié)點，彈性策略要考慮到這一硬約束，避免只讀升配失敗后主節(jié)點被讀壓力二次擊穿。

六、總結(jié)與最佳實踐

不少團(tuán)隊在接觸 Serverless 數(shù)據(jù)庫時，容易把“自動伸縮”等同于“什么都不用管”——這是一種危險的想法。實際運(yùn)行中，彈性策略的精準(zhǔn)度、應(yīng)用層的配合、冷卻窗口的設(shè)定，任何一個環(huán)節(jié)被忽略，都可能把一次預(yù)期中的平滑擴(kuò)容，變成延遲抖動的源頭。從過去一年多各行業(yè)壓測與線上案例來看，做好 PolarDB Serverless 自動擴(kuò)容的關(guān)鍵，并不在于把閾值設(shè)得足夠敏感，而在于形成一套匹配業(yè)務(wù)波動的伸縮節(jié)奏。

1. 彈性伸縮規(guī)劃建議

伸縮規(guī)則切忌“一刀切”。不少用戶最初只設(shè)一個 CPU 利用率閾值，比如 60% 觸發(fā)擴(kuò)容，結(jié)果在流量爬坡階段頻繁觸發(fā)又回落，造成 PCU 反復(fù)抖動。比較成熟的做法是采用多級觸發(fā)：第一級在 CPU 達(dá)到 50% 時小幅提升，第二級在 70% 時追加更多計算單元，兩次擴(kuò)容之間保持至少 60～120 秒的冷卻間隔。這樣做既能避免資源被瞬間打滿，又不會因單次劇烈拉升造成連接排隊。

縮容策略往往比擴(kuò)容更需要謹(jǐn)慎。縮容觀察窗口過短會引發(fā)“鋸齒”效應(yīng)——資源剛釋放，下一波請求進(jìn)來又要重新擴(kuò)容，帶來冷啟動開銷。建議將縮容冷卻時間設(shè)在 600 秒以上，并結(jié)合連接數(shù)和內(nèi)存使用率綜合判斷，確保平穩(wěn)期才執(zhí)行回縮。測試數(shù)據(jù)顯示，將縮容觸發(fā)條件從“連續(xù) 3 分鐘低負(fù)載”調(diào)整為“連續(xù) 10 分鐘低負(fù)載”后，因縮容引發(fā)的 P99 延遲毛刺下降了 40% 以上。

壓測是驗證彈性規(guī)劃的唯一可信手段。用 Sysbench 或?qū)嶋H流量回放模擬從平穩(wěn)到突發(fā)峰值的過程，重點觀察三個指標(biāo)：從觸發(fā)擴(kuò)容到新 PCU 實際生效的延遲（應(yīng)穩(wěn)定在 10 秒以內(nèi)）、擴(kuò)容過程中請求超時率（應(yīng)保持在 0.1% 以下）、縮容后 QPS 下降曲線的平滑度。只有在壓測環(huán)境中反復(fù)確認(rèn)過彈性邏輯，才能放心將它交給線上流量。

2. 成本優(yōu)化技巧

Serverless 的按量付費(fèi)模式天生適合波峰波谷明顯的業(yè)務(wù)，但若對伸縮行為不加引導(dǎo)，賬單上也可能出現(xiàn)意外。核心思路是“壓峰填谷”，而不是簡單地指望彈性自動省錢。

第一點，為集群設(shè)置一個合理的算力上下限。下限不建議直接設(shè)為零，除非業(yè)務(wù)確實可以容忍冷啟動造成的首次請求延遲。針對低頻但需要即時響應(yīng)的場景，將最低 PCU 設(shè)置在 0.5～1 之間，既能保證快連接，又能避免完全閑置時的“無請求不付費(fèi)”。第二點，利用定時彈性能力應(yīng)對周期性大促。比如每晚 20:00～22:00 是高流量時段，就可以在此窗口到來前 5 分鐘提前將算力上限調(diào)高，窗口結(jié)束后再恢復(fù)，這樣系統(tǒng)無需等到壓力觸發(fā)才被動擴(kuò)容，響應(yīng)體感更佳。

多個生產(chǎn)實踐的對比數(shù)據(jù)表明，合理設(shè)置上下限和冷卻參數(shù)后，Serverless 實例的總計算成本可以比固定規(guī)格實例降低 30%～60%，而性能表現(xiàn)并未變差。但前提是應(yīng)用側(cè)也做了相應(yīng)適配：連接池的最小空閑連接數(shù)至少設(shè)為 5～10，避免擴(kuò)容完成后連接建立滯后；代碼中避免短連接風(fēng)暴，否則即使數(shù)據(jù)庫在秒級完成擴(kuò)容，也會被頻繁建連拖慢整體響應(yīng)。

3. 未來趨勢展望

從目前的技術(shù)演進(jìn)方向看，Serverless 數(shù)據(jù)庫的彈性能力正在從“反應(yīng)式”走向“預(yù)測式”。下一階段，系統(tǒng)不僅要能根據(jù)實時負(fù)載做出響應(yīng)，還需要基于歷史流量模式提前規(guī)劃資源。比如通過分析過去數(shù)周的業(yè)務(wù)曲線，自動生成與節(jié)假日、營銷節(jié)奏匹配的伸縮計劃，將擴(kuò)容動作從被動觸發(fā)轉(zhuǎn)向主動預(yù)熱。

另一個值得關(guān)注的趨勢是“智能收縮”。當(dāng)前多數(shù)縮容策略依循環(huán)人工設(shè)定的冷窗口，很容易在流量短暫波動時產(chǎn)生不必要的回縮。未來的方案可能會引入更復(fù)雜的決策模型，綜合查詢排隊深度、事務(wù)提交速率和應(yīng)用端 SLA 要求，動態(tài)決定是否執(zhí)行縮容。某頭部云廠商的預(yù)熱研究中已提到，使用強(qiáng)化學(xué)習(xí)預(yù)測最優(yōu)伸縮時機(jī)的試驗，可將延遲違規(guī)事件減少 20%～30%。

最后，資源彈性的粒度會繼續(xù)細(xì)化。目前 0.1 PCU 的調(diào)整單位已經(jīng)能夠覆蓋大多數(shù)中負(fù)載場景，但對于超大規(guī)模微服務(wù)架構(gòu)，未來可能出現(xiàn)基于“請求級調(diào)度”的資源分配，即單條 SQL 消耗的計算資源被精確計量和隔離，真正實現(xiàn)“為每一次查詢按需付費(fèi)”。在這一趨勢下，數(shù)據(jù)庫的自動擴(kuò)容將不再只是運(yùn)維團(tuán)隊關(guān)心的技術(shù)指標(biāo)，而是直接與業(yè)務(wù)成本核算模型掛鉤，成為 FinOps 體系中的一環(huán)。