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

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

一、初識PolarDB Serverless彈性伸縮

1. Serverless究竟意味著什么

Serverless并非簡單的“不用管理服務(wù)器”，而是把數(shù)據(jù)庫的計(jì)算能力抽象成一種按量計(jì)費(fèi)、獨(dú)立調(diào)度的資源池。PolarDB通過計(jì)算與存儲分離的架構(gòu)，讓計(jì)算節(jié)點(diǎn)可以脫離數(shù)據(jù)落盤的位置束縛，單獨(dú)進(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ù)等實(shí)時(shí)指標(biāo)，自動觸發(fā)計(jì)算資源的增減，整個(gè)過程在秒級完成且不中斷連接。和手動擴(kuò)容比起來，它不再依賴故障發(fā)生后的應(yīng)急操作，而是把擴(kuò)容動作嵌入到流量變化曲線之中。實(shí)踐中，多段閾值配合同步調(diào)整策略，可以避免“一次擴(kuò)滿資源”帶來的浪費(fèi)或抖動，讓伸縮變成業(yè)務(wù)流量的自然投影。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 模擬流量驗(yàn)證

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

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

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

很多團(tuán)隊(duì)在啟用 Serverless 之后，習(xí)慣將其等同于“免運(yùn)維”。但在幾輪真實(shí)流量突增的考驗(yàn)下，這種認(rèn)知很快會被打破：自動伸縮只解決了資源的實(shí)時(shí)供給，而決定系統(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è)自動伸縮的存儲計(jì)算分離架構(gòu)，這類表象指標(biāo)已經(jīng)不夠用。真正需要納入儀表盤前三位的是“彈性延遲”“擴(kuò)容等待時(shí)間”以及“資源打滿次數(shù)”。彈性延遲直接反映請求觸達(dá)與計(jì)算單元就緒之間的時(shí)間差，一旦該指標(biāo)持續(xù)超過 5 秒，意味著部分高并發(fā)請求已經(jīng)開始排隊(duì)或超時(shí)。擴(kuò)容等待時(shí)間則暴露了策略層與資源池之間的響應(yīng)瓶頸，如果頻繁出現(xiàn) PCU 擴(kuò)容動作實(shí)際完成時(shí)間遠(yuǎn)超控制臺宣稱的秒級彈性，通常不是伸縮引擎的問題，而是應(yīng)用連接池的冷連接或者觀測窗口設(shè)置過短所致。

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

2. 告警配置指南

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

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

3. 性能壓測分析

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

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

五、常見問題排查

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

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

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

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

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

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

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

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

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

3. 讀寫分離注意事項(xiàng)

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

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

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

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

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

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

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

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

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

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

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

多個(gè)生產(chǎn)實(shí)踐的對比數(shù)據(jù)表明，合理設(shè)置上下限和冷卻參數(shù)后，Serverless 實(shí)例的總計(jì)算成本可以比固定規(guī)格實(shí)例降低 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ù)實(shí)時(shí)負(fù)載做出響應(yīng)，還需要基于歷史流量模式提前規(guī)劃資源。比如通過分析過去數(shù)周的業(yè)務(wù)曲線，自動生成與節(jié)假日、營銷節(jié)奏匹配的伸縮計(jì)劃，將擴(kuò)容動作從被動觸發(fā)轉(zhuǎn)向主動預(yù)熱。

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

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