在億級(jí)用戶規(guī)模的業(yè)務(wù)場(chǎng)景下，數(shù)據(jù)庫(kù)作為核心數(shù)據(jù)載體，其訪問(wèn)鏈路的穩(wěn)定性、性能和可維護(hù)性，直接決定了系統(tǒng)的健壯性與迭代效率。

然而，隨著業(yè)務(wù)快速發(fā)展，數(shù)據(jù)庫(kù)接入方式逐漸碎片化：直連、多版本 SDK、自研中間件……不同的接入模式帶來(lái)了協(xié)議兼容性差、故障恢復(fù)慢、運(yùn)維成本高等一系列挑戰(zhàn)。

為解決這一系統(tǒng)性難題，小紅書(shū)數(shù)據(jù)庫(kù)團(tuán)隊(duì)研發(fā)了新一代數(shù)據(jù)庫(kù)代理系統(tǒng) —— RedHub，致力于構(gòu)建統(tǒng)一、高性能、易運(yùn)維的數(shù)據(jù)庫(kù)接入層，支撐未來(lái)十年的數(shù)據(jù)庫(kù)架構(gòu)演進(jìn)。

本文將分享 RedHub 的設(shè)計(jì)思考、關(guān)鍵技術(shù)突破與生產(chǎn)實(shí)踐成果。

01、演進(jìn)動(dòng)因：從碎片化接入到統(tǒng)一代理的必然選擇

在小紅書(shū)業(yè)務(wù)快速發(fā)展的過(guò)程中，為滿足不同場(chǎng)景的敏捷迭代需求，數(shù)據(jù)庫(kù)接入方式逐漸形成了“多路徑并行”的局面。據(jù)初步統(tǒng)計(jì)，曾存在 6 種以上非標(biāo)準(zhǔn)化接入方式，而符合統(tǒng)一規(guī)范的占比不足三分之一。

這種快速迭代的業(yè)務(wù)節(jié)奏，在早期有效支撐了業(yè)務(wù)創(chuàng)新，但由于缺乏統(tǒng)一的長(zhǎng)期架構(gòu)規(guī)劃，數(shù)據(jù)庫(kù)接入方式逐漸演變?yōu)槎嗦窂讲⑿械木置?，帶?lái)了后續(xù)的治理復(fù)雜性和技術(shù)債務(wù)：

• 可用性風(fēng)險(xiǎn)高：多種接入模式依賴各異，健康檢查與故障切換機(jī)制不統(tǒng)一，部分場(chǎng)景下難以及時(shí)隔離異常；
• 運(yùn)維成本高昂：工具鏈需適配不同路徑，問(wèn)題定位效率低，擴(kuò)容、變更流程復(fù)雜；
• 擴(kuò)展能力受限：缺乏統(tǒng)一的元數(shù)據(jù)管理、鏈路追蹤和精細(xì)化管控能力；
  

同時(shí)，作為前期主要的標(biāo)準(zhǔn)化接入載體，舊版代理（MyHub）在功能上也逐漸暴露短板：SQL解析能力弱、不支持復(fù)雜查詢（如跨分片 JOIN、子查詢）、執(zhí)行引擎簡(jiǎn)陋，嚴(yán)重制約了業(yè)務(wù)對(duì)分庫(kù)分表的使用體驗(yàn)。

我們意識(shí)到：當(dāng)業(yè)務(wù)規(guī)?？缭脚R界點(diǎn)，基礎(chǔ)設(shè)施不僅需要“統(tǒng)一入口”，更需要一個(gè)功能完整、穩(wěn)定可控、可持續(xù)演進(jìn)的數(shù)據(jù)庫(kù)接入層 —— “統(tǒng)一性”已從可選項(xiàng)，變?yōu)楸剡x項(xiàng)。

02、架構(gòu)轉(zhuǎn)型：走向輕量客戶端與中心化代理的融合架構(gòu)

橫向上看，業(yè)界的數(shù)據(jù)接入層架構(gòu)主要分為兩個(gè)流派：一種是 SDK 層做（從業(yè)務(wù)層攔截流量做代理分發(fā)），嵌入在業(yè)務(wù)服務(wù)中，這種情況的優(yōu)點(diǎn)是訪問(wèn)數(shù)據(jù)庫(kù) RT 比較低，但缺點(diǎn)是后續(xù)升級(jí)不夠靈活，推動(dòng)業(yè)務(wù)改造難度大；另一種是 SDK 做薄，Proxy 做厚，將以前 SDK 的能力下沉到 Proxy 層，這樣 SDK 將流量轉(zhuǎn)發(fā)到Proxy 層，由 Proxy 再分發(fā)到下游數(shù)據(jù)庫(kù)服務(wù)。這種情況的優(yōu)點(diǎn)是后續(xù)升級(jí)方便，無(wú)需業(yè)務(wù)改造，缺點(diǎn)是會(huì)帶來(lái)一定 RT 上漲（毫秒級(jí)）。

基于 SDK 的方式在早期比較流行，隨著 SDK + Proxy 的誕生，目前各大公司已在逐步升級(jí)替換，但部分長(zhǎng)尾業(yè)務(wù)依然使用 SDK 的訪問(wèn)形式。從趨勢(shì)看，基于 SDK + Proxy 的訪問(wèn)方式將會(huì)是未來(lái)的終態(tài)。

因此，小紅書(shū)也堅(jiān)定選擇了“輕 SDK + 重 Proxy”的技術(shù)路徑，將數(shù)據(jù)庫(kù)訪問(wèn)的復(fù)雜性收口到 Proxy 層實(shí)現(xiàn)。

03、重構(gòu)決策：基于開(kāi)源內(nèi)核的重新研發(fā)之路

面對(duì)舊代理 MyHub 在功能、架構(gòu)與運(yùn)維上的持續(xù)退化，我們面臨一個(gè)根本性抉擇：是繼續(xù)在其陳舊代碼基礎(chǔ)上局部?jī)?yōu)化，還是構(gòu)建一個(gè)面向未來(lái)十年演進(jìn)的新一代數(shù)據(jù)庫(kù)接入層？經(jīng)過(guò)系統(tǒng)評(píng)估，我們明確放棄“漸進(jìn)式迭代”路徑，轉(zhuǎn)而啟動(dòng) RedHub 項(xiàng)目，采用“基于成熟開(kāi)源項(xiàng)目深度二次開(kāi)發(fā)”的技術(shù)路線，實(shí)現(xiàn)從能力到架構(gòu)的全面升級(jí)。

3.1 舊系統(tǒng)已不具備可演進(jìn)性

MyHub 作為六年前的技術(shù)產(chǎn)物，長(zhǎng)期缺乏系統(tǒng)性維護(hù)，核心模塊耦合嚴(yán)重、擴(kuò)展困難，暴露出三大不可逆缺陷：

• 功能層面：SQL 解析能力薄弱，復(fù)雜查詢（如跨分片 JOIN、子查詢）支持率不足 20%，嚴(yán)重制約分庫(kù)分表落地；
• 架構(gòu)層面：高可用鏈路依賴非標(biāo)組件，探活機(jī)制無(wú)法覆蓋磁盤(pán)故障等真實(shí)異常，連接池?zé)o剛性限制，存在打爆 DB 的風(fēng)險(xiǎn)；
• 運(yùn)維層面：缺乏全局會(huì)話視圖與精細(xì)化限流能力，問(wèn)題定位效率低，變更流程高度依賴人工。

這些問(wèn)題已非局部修補(bǔ)所能解決。我們判定：MyHub 不僅是一個(gè)落后的系統(tǒng)，更是一個(gè)阻礙長(zhǎng)期演進(jìn)的架構(gòu)負(fù)資產(chǎn)。

3.2  技術(shù)路徑選擇：從頭自研 or 基于開(kāi)源二次開(kāi)發(fā)？

數(shù)據(jù)庫(kù)代理系統(tǒng)復(fù)雜度高，涉及協(xié)議解析、分布式執(zhí)行、連接管理、高可用控制等多個(gè)關(guān)鍵模塊 。我們重點(diǎn)評(píng)估了兩條核心路徑：

進(jìn)一步分析發(fā)現(xiàn)，從頭自研雖然理論上可控性強(qiáng)，但面臨“時(shí)間成本高、試錯(cuò)代價(jià)大、人才投入密集”三大挑戰(zhàn)。尤其是在數(shù)據(jù)庫(kù)這類(lèi)基礎(chǔ)設(shè)施領(lǐng)域，協(xié)議兼容性、執(zhí)行引擎優(yōu)化、并發(fā)控制等底層能力需要長(zhǎng)期打磨，難以在短期內(nèi)達(dá)到生產(chǎn)級(jí)穩(wěn)定。

而基于開(kāi)源項(xiàng)目二次開(kāi)發(fā)，盡管前期需要投入大量時(shí)間閱讀源碼、理解架構(gòu)，但可以快速獲得經(jīng)過(guò)驗(yàn)證的分布式執(zhí)行引擎、SQL 優(yōu)化器、元數(shù)據(jù)管理等核心能力。只要選型得當(dāng)，并在關(guān)鍵路徑上做深度增強(qiáng)，完全能夠構(gòu)建出滿足企業(yè)級(jí)需求的定制化系統(tǒng)。

因此，我們選擇基于開(kāi)源項(xiàng)目 PolarDB-X 計(jì)算層進(jìn)行深度二次開(kāi)發(fā)的技術(shù)路徑。在保證技術(shù)自主性的同時(shí)，復(fù)用其成熟的分布式 SQL 執(zhí)行引擎與優(yōu)化器能力，有效規(guī)避重復(fù)造輪子的風(fēng)險(xiǎn)，實(shí)現(xiàn)研發(fā)效率與系統(tǒng)質(zhì)量的平衡。同時(shí)，針對(duì)小紅書(shū)作為云原生、多云架構(gòu)下的高并發(fā)、多租戶業(yè)務(wù)特點(diǎn)，在關(guān)鍵鏈路進(jìn)行深度定制增強(qiáng)：

• 高可用層面，適配多云網(wǎng)絡(luò)異構(gòu)環(huán)境，提升故障識(shí)別精度；
• 連接與元數(shù)據(jù)層面，去中心化配置管理，保障跨云部署的一致性與韌性；
• 治理層面，產(chǎn)品化參數(shù)級(jí)限流、邏輯會(huì)話管理等能力，支撐統(tǒng)一可觀測(cè)與精細(xì)化管控。

RedHub 并非簡(jiǎn)單“拿來(lái)主義”，而是“站在巨人肩膀上，走出自己的路”——既借力開(kāi)源，又超越通用，打造真正服務(wù)于小紅書(shū)未來(lái)十年架構(gòu)演進(jìn)的數(shù)據(jù)庫(kù)接入層。

04、能力突破：高可用、智能執(zhí)行與透明治理的系統(tǒng)實(shí)現(xiàn)

RedHub 的價(jià)值不僅在于替代舊系統(tǒng)，更在于構(gòu)建一套完整的能力體系。圍繞穩(wěn)定性、功能性和可觀測(cè)性三大目標(biāo)，我們?cè)诙鄠€(gè)關(guān)鍵技術(shù)維度實(shí)現(xiàn)了系統(tǒng)性突破。

4.1 穩(wěn)定性：從“脆弱依賴”到“閉環(huán)高可用”

MyHub 的高可用鏈路像一條“長(zhǎng)鏈條”，任何一個(gè)環(huán)節(jié)出問(wèn)題，整個(gè)系統(tǒng)就卡住。而 RedHub 的設(shè)計(jì)哲學(xué)是：核心路徑最短，依賴最少，自愈最快。

關(guān)鍵改進(jìn)：

• 探活獨(dú)立：使用短連接獨(dú)立探活，磁盤(pán)故障也能秒級(jí)感知；
• Leader 仲裁：僅由 Leader 節(jié)點(diǎn)探活，避免集群放大問(wèn)題；

<滑動(dòng)查看 MyHub 和 RedHub 的對(duì)比>

基于 MyHub 的訪問(wèn)

1. 不合理的組件依賴：配置變更路徑上存在 binlog 訂閱鏈路，導(dǎo)致依賴了 RedDTS 和 Kafka，從架構(gòu)層級(jí)上看不合理、可用性上達(dá)不到高可用系統(tǒng)的要求，存在穩(wěn)定性風(fēng)險(xiǎn)

2. 強(qiáng)依賴不可靠的配置中心：高可用切換核心鏈路上依賴了中心化的 Nacos 配置中心，非公司標(biāo)準(zhǔn)化組件，屬于自運(yùn)維的開(kāi)源產(chǎn)品，可用性保障弱

基于 RedHub 的訪問(wèn)

3. 外部依賴簡(jiǎn)潔清晰：僅依賴 orch、redhub-admin、metaDB 等幾個(gè)核心組件，內(nèi)部閉環(huán)，且變更路徑短

4. 配置管理分布式化：不依賴中心化的配置中心，集群配置通過(guò)數(shù)據(jù)庫(kù)實(shí)現(xiàn)，下沉到各套集群并結(jié)合中心化 metaDB 實(shí)現(xiàn)雙備，可靠性高

• 連接可控：剛性連接池，最大連接數(shù)可配，徹底杜絕DB被打爆。

<滑動(dòng)查看 MyHub 和 RedHub 的對(duì)比>

基于 MyHub 的訪問(wèn)

連接上限不可控：MyHub 與 MySQL 之間的連接無(wú)上限，獲取連接時(shí)如果無(wú)空閑連接則觸發(fā)建連，通過(guò)控制建連的并發(fā)度來(lái)軟性限制，遇到流量洪峰和大量慢查場(chǎng)景，容易導(dǎo)致 MySQL 連接數(shù)打滿甚至直接宕機(jī)

隨著洪峰流量達(dá)到，MyHub 的后端連接數(shù)快速飆升到了1600+，直到達(dá)到 MySQL 配置的連接數(shù)上限，此時(shí)如果 MySQL 配置不足以應(yīng)對(duì)這些連接開(kāi)銷(xiāo)，將會(huì)被直接打掛。

基于 RedHub 的訪問(wèn)

連接上限可控可調(diào)：通過(guò)最小和最大連接數(shù)參數(shù)控制 RedHub 與 MySQL 的連接數(shù)上限，有效保護(hù) MySQL ，支持動(dòng)態(tài)調(diào)節(jié)連接數(shù)限制，來(lái)實(shí)現(xiàn)性能調(diào)優(yōu)、流量洪峰預(yù)熱等能力

RedHub 的后端連接數(shù)被嚴(yán)格控制在了連接池上限之下，MySQL 上的連接數(shù)得到了良好的控制，避免了被打掛的風(fēng)險(xiǎn)。

4.2 能力升級(jí)：從“SQL 轉(zhuǎn)發(fā)器”到“智能 SQL 引擎”

MyHub 的本質(zhì)是“流量搬運(yùn)工”，而 RedHub 是一個(gè)具備分布式數(shù)據(jù)庫(kù)能力的智能代理。

SQL 兼容性：從“寫(xiě)不了”到“基本不用改”

• 基于 Druid 重構(gòu) SQL 解析器，支持復(fù)雜子查詢、ORDER BY、聚合函數(shù)；
• 引入 Session Context，支持事務(wù)隔離級(jí)別等會(huì)話變量；
• 經(jīng) SQLancer 工具測(cè)試，分庫(kù)分表場(chǎng)景 SQL 通過(guò)率從19%提升至92%。

分庫(kù)分表：終于能寫(xiě) JOIN 了

• 內(nèi)置分布式優(yōu)化器（RBO + CBO），自動(dòng)拆解并優(yōu)化跨分片查詢；
• 支持跨分片 JOIN、聚合、排序，語(yǔ)義正確，性能可控。

發(fā)號(hào)器：從“手動(dòng)取號(hào)”到“無(wú)感自增”

• 支持 AUTO_INCREMENT BY SEQUENCE，建表時(shí)指定，插入時(shí)自動(dòng)填充；
• 業(yè)務(wù)代碼不再手動(dòng)獲取 ID 或者填寫(xiě)發(fā)號(hào)器函數(shù)；
• 多種序列類(lèi)型可選：號(hào)段、Snowflake、時(shí)間序列，靈活適配。

4.3 運(yùn)維體驗(yàn)：從“黑盒排查”到“透明治理”

以前查慢查詢，要登錄多個(gè) MySQL 實(shí)例，手動(dòng)拼 SQL；現(xiàn)在，RedHub 提供了真正的“全局視角”。

實(shí)時(shí)會(huì)話管理

• SHOW PROCESSLIST 查看到的是邏輯 SQL，一鍵 KILL 即可終止所有關(guān)聯(lián)的物理查詢；
• SHOW PHYSICAL_PROCESSLIST 查看底層實(shí)際執(zhí)行，排障效率提升數(shù)倍。

<滑動(dòng)查看 MyHub 和 RedHub 的對(duì)比>

基于 MyHub 的訪問(wèn)

• 不支持邏輯 processlist：
  MyHub 層無(wú) processlist 視圖，需要到底層的各MySQL節(jié)點(diǎn)上分別執(zhí)行 show processlist 獲取當(dāng)前各自正在運(yùn)行的SQL來(lái)進(jìn)行匯總分析；需要kill慢查時(shí)，也需要在各MySQL節(jié)點(diǎn)上執(zhí)行 kill 命令，可能會(huì)涉及多次kill，運(yùn)維成本高，時(shí)效性難以保證

基于 RedHub 的訪問(wèn)

• 具備邏輯 processlist 管理能力：
  RedHub 層可以直接通過(guò) show processlist 和 show physical_processlist 命令來(lái)分別獲取當(dāng)前正在執(zhí)行的邏輯查詢和物理查詢，并且支持直接kill對(duì)應(yīng)的查詢，尤其是 kill 邏輯查詢時(shí)，能夠自動(dòng)把關(guān)聯(lián)的底層所有物理查詢一并 kill 掉，大大簡(jiǎn)化運(yùn)維工作量，時(shí)效提升明顯
  

精細(xì)化限流：精準(zhǔn)打擊“熱點(diǎn)SQL”

• MyHub 只能按SQL模板限流，而 RedHub 支持：

     a.按庫(kù)、表、用戶、IP、SQL類(lèi)型

     b.按SQL模板和參數(shù)關(guān)鍵字（如 oid=2）精準(zhǔn)限流

• 配置一條規(guī)則，即可熔斷特定熱點(diǎn)請(qǐng)求，避免雪崩。

RedHub熱點(diǎn)限流樣例

熱點(diǎn)SQL：

配置限流規(guī)則：

05、實(shí)踐驗(yàn)證：低侵入遷移與關(guān)鍵場(chǎng)景閉環(huán)檢驗(yàn)

我們深知技術(shù)再好，升級(jí)成本高也白搭。因此RedHub 的遷移設(shè)計(jì)核心是：業(yè)務(wù)無(wú)感、風(fēng)險(xiǎn)可控、支持到位。

5.1 平滑遷移：流量回放 + 漸進(jìn)灰度

從 MyHub 升級(jí)到 RedHub，整體分為三個(gè)階段，業(yè)務(wù)側(cè)基本無(wú)改造：

1. 流量回放：

• 在 MyHub Pod 上部署流量錄制組件，錄制業(yè)務(wù)SQL模板
• 部署獨(dú)立的 RedHub 集群，復(fù)制原集群的庫(kù)表結(jié)構(gòu)
• 將錄制的業(yè)務(wù) SQL 模板在 RedHub 集群上回放，完成 SQL 兼容性驗(yàn)證

2. 灰度接流：將集群標(biāo)記為遷移狀態(tài)，并在 MyHub 的集群中加入 RedHub Pod，灰度承接業(yè)務(wù)流量，逐步增加 RedHub Pod 占比

3. 完成升級(jí)：將所有 MyHub Pod 節(jié)點(diǎn)全部下線，僅保留 RedHub Pod，將集群狀態(tài)標(biāo)記為遷移完成，集群類(lèi)型變更為 RedHub。

5.2 真實(shí)場(chǎng)景驗(yàn)證，助力穩(wěn)定與高效

? 案例一：從庫(kù)磁盤(pán)故障自動(dòng)隔離

某次線上從庫(kù)因磁盤(pán)寫(xiě)滿導(dǎo)致服務(wù)不可用，RedHub 通過(guò)短連接探活機(jī)制在 15 秒內(nèi)精準(zhǔn)識(shí)別異常，自動(dòng)將其從負(fù)載列表中摘除，業(yè)務(wù)查詢無(wú)抖動(dòng)、無(wú)報(bào)錯(cuò)，實(shí)現(xiàn)了故障“靜默自愈”。

? 案例二：熱點(diǎn) SQL 快速限流恢復(fù)

某內(nèi)部應(yīng)用，因?yàn)闊狳c(diǎn)消息推送導(dǎo)致一個(gè)高頻查詢 SQL 掃描過(guò)多的數(shù)據(jù)，產(chǎn)生了大量的慢查詢。通過(guò) RedHub 的精細(xì)化限流能力，我們?cè)?2 分鐘內(nèi)配置規(guī)則，精準(zhǔn)攔截特定用戶 + 關(guān)鍵參數(shù)的請(qǐng)求，系統(tǒng)負(fù)載迅速回落，避免了服務(wù)雪崩。

與此同時(shí)，RedHub 的高 SQL 兼容性與完整功能支持，打破了過(guò)去“因能力不足無(wú)法接入代理”的僵局，讓原本只能直連數(shù)據(jù)庫(kù)的業(yè)務(wù)，也能以標(biāo)準(zhǔn)化方式接入。這為未來(lái)實(shí)現(xiàn)全量數(shù)據(jù)庫(kù)流量統(tǒng)一治理奠定了堅(jiān)實(shí)基礎(chǔ)。

06、長(zhǎng)期遠(yuǎn)景：構(gòu)建數(shù)據(jù)庫(kù)統(tǒng)一控制面與智能中樞

RedHub 的定位，從來(lái)不只是一個(gè)“流量轉(zhuǎn)發(fā)層”。我們正在將其打造為小紅書(shū)數(shù)據(jù)庫(kù)生態(tài)的統(tǒng)一控制面 —— 一個(gè)集 流量治理、安全管控、可觀測(cè)性與智能優(yōu)化 于一體的數(shù)據(jù)庫(kù)中樞。

接下來(lái)，我們將圍繞四個(gè)方向持續(xù)演進(jìn)：

• 統(tǒng)一訪問(wèn)治理：構(gòu)建細(xì)粒度權(quán)限模型，支持字段級(jí)脫敏、行級(jí)訪問(wèn)控制，滿足多租戶與合規(guī)場(chǎng)景需求；
• 增強(qiáng)型數(shù)據(jù)安全：集成動(dòng)態(tài)脫敏、SQL審計(jì)與敏感操作熔斷，讓每一次數(shù)據(jù)庫(kù)訪問(wèn)都可管、可控、可追溯；
• 智能化運(yùn)維能力：基于SQL執(zhí)行數(shù)據(jù)構(gòu)建性能畫(huà)像，自動(dòng)識(shí)別慢查詢模式、推薦索引、預(yù)測(cè)容量瓶頸；
• HTAP 能力探索：支持冷熱數(shù)據(jù)自動(dòng)分離，熱數(shù)據(jù)留存行存引擎保障事務(wù)性能，冷數(shù)據(jù)歸檔至列存引擎；通過(guò) SQL 路由自動(dòng)將分析型查詢導(dǎo)向列存，實(shí)現(xiàn) AP 與 TP 資源隔離與統(tǒng)一入口，逐步邁向輕量級(jí) HTAP 架構(gòu)。

未來(lái)，RedHub 將不僅是業(yè)務(wù)訪問(wèn)數(shù)據(jù)庫(kù)的“必經(jīng)之路”，更會(huì)成為我們實(shí)現(xiàn)數(shù)據(jù)庫(kù)自治、可觀測(cè)、合規(guī)閉環(huán)與混合負(fù)載支持的核心樞紐。

07、作者簡(jiǎn)介

Core Contributors

克邪（沈力鍇）

小紅書(shū)數(shù)據(jù)庫(kù)中間件研發(fā)負(fù)責(zé)人，主要負(fù)責(zé)小紅書(shū)數(shù)據(jù)庫(kù)代理、數(shù)據(jù)庫(kù) SDK 和數(shù)據(jù)傳輸服務(wù)等數(shù)據(jù)庫(kù)中間件產(chǎn)品的整體架構(gòu)和技術(shù)演進(jìn)。

程普（沈文浩）

小紅書(shū)數(shù)據(jù)庫(kù)中間件研發(fā)工程師，聚焦數(shù)據(jù)庫(kù)代理研發(fā)，主攻數(shù)據(jù)分片、SQL 解析、流量染色與識(shí)別等核心技術(shù)，打造支持單元化架構(gòu)的流量治理閉環(huán)，保障大規(guī)模場(chǎng)景下數(shù)據(jù)庫(kù)訪問(wèn)的穩(wěn)定與可控。

正雪（李宇辰）

小紅書(shū)數(shù)據(jù)庫(kù)中間件研發(fā)工程師，負(fù)責(zé)數(shù)據(jù)庫(kù)代理研發(fā)，聚焦高可用機(jī)制（探活摘流、故障隔離）、多云流量路由、SQL 性能優(yōu)化及平滑升級(jí)、自動(dòng)擴(kuò)容等自動(dòng)化運(yùn)維能力建設(shè)，支撐大規(guī)模、多云環(huán)境下數(shù)據(jù)庫(kù)系統(tǒng)的穩(wěn)定與高效運(yùn)維。