小紅書新一代數據庫代理 RedHub 的設計與實踐
在億級用戶規模的業務場景下，數據庫作為核心數據載體，其訪問鏈路的穩定性、性能和可維護性，直接決定了系統的健壯性與迭代效率。
然而，隨著業務快速發展，數據庫接入方式逐漸碎片化：直連、多版本 SDK、自研中間件……不同的接入模式帶來了協議兼容性差、故障恢復慢、運維成本高等一系列挑戰。
為解決這一系統性難題，小紅書數據庫團隊研發了新一代數據庫代理系統 —— RedHub，致力于構建統一、高性能、易運維的數據庫接入層，支撐未來十年的數據庫架構演進。
本文將分享 RedHub 的設計思考、關鍵技術突破與生產實踐成果。
01、演進動因：從碎片化接入到統一代理的必然選擇
在小紅書業務快速發展的過程中，為滿足不同場景的敏捷迭代需求，數據庫接入方式逐漸形成了“多路徑并行”的局面。據初步統計，曾存在 6 種以上非標準化接入方式，而符合統一規范的占比不足三分之一。
這種快速迭代的業務節奏，在早期有效支撐了業務創新，但由于缺乏統一的長期架構規劃，數據庫接入方式逐漸演變為多路徑并行的局面，帶來了后續的治理復雜性和技術債務：
- 可用性風險高：多種接入模式依賴各異，健康檢查與故障切換機制不統一，部分場景下難以及時隔離異常；
- 運維成本高昂：工具鏈需適配不同路徑，問題定位效率低，擴容、變更流程復雜；
- 擴展能力受限：缺乏統一的元數據管理、鏈路追蹤和精細化管控能力；
同時，作為前期主要的標準化接入載體，舊版代理（MyHub）在功能上也逐漸暴露短板：SQL解析能力弱、不支持復雜查詢（如跨分片 JOIN、子查詢）、執行引擎簡陋，嚴重制約了業務對分庫分表的使用體驗。
我們意識到：當業務規模跨越臨界點，基礎設施不僅需要“統一入口”，更需要一個功能完整、穩定可控、可持續演進的數據庫接入層 —— “統一性”已從可選項，變為必選項。
02、架構轉型：走向輕量客戶端與中心化代理的融合架構
橫向上看，業界的數據接入層架構主要分為兩個流派：一種是 SDK 層做（從業務層攔截流量做代理分發），嵌入在業務服務中，這種情況的優點是訪問數據庫 RT 比較低，但缺點是后續升級不夠靈活，推動業務改造難度大；另一種是 SDK 做薄，Proxy 做厚，將以前 SDK 的能力下沉到 Proxy 層，這樣 SDK 將流量轉發到Proxy 層，由 Proxy 再分發到下游數據庫服務。這種情況的優點是后續升級方便，無需業務改造，缺點是會帶來一定 RT 上漲（毫秒級）。
基于 SDK 的方式在早期比較流行，隨著 SDK + Proxy 的誕生，目前各大公司已在逐步升級替換，但部分長尾業務依然使用 SDK 的訪問形式。從趨勢看，基于 SDK + Proxy 的訪問方式將會是未來的終態。
因此，小紅書也堅定選擇了“輕 SDK + 重 Proxy”的技術路徑，將數據庫訪問的復雜性收口到 Proxy 層實現。
03、重構決策：基于開源內核的重新研發之路
面對舊代理 MyHub 在功能、架構與運維上的持續退化，我們面臨一個根本性抉擇：是繼續在其陳舊代碼基礎上局部優化，還是構建一個面向未來十年演進的新一代數據庫接入層？經過系統評估，我們明確放棄“漸進式迭代”路徑，轉而啟動 RedHub 項目，采用“基于成熟開源項目深度二次開發”的技術路線，實現從能力到架構的全面升級。
3.1 舊系統已不具備可演進性
MyHub 作為六年前的技術產物，長期缺乏系統性維護，核心模塊耦合嚴重、擴展困難，暴露出三大不可逆缺陷：
- 功能層面：SQL 解析能力薄弱，復雜查詢（如跨分片 JOIN、子查詢）支持率不足 20%，嚴重制約分庫分表落地；
- 架構層面：高可用鏈路依賴非標組件，探活機制無法覆蓋磁盤故障等真實異常，連接池無剛性限制，存在打爆 DB 的風險；
- 運維層面：缺乏全局會話視圖與精細化限流能力，問題定位效率低，變更流程高度依賴人工。
這些問題已非局部修補所能解決。我們判定：MyHub 不僅是一個落后的系統，更是一個阻礙長期演進的架構負資產。
3.2 技術路徑選擇：從頭自研 or 基于開源二次開發？
數據庫代理系統復雜度高，涉及協議解析、分布式執行、連接管理、高可用控制等多個關鍵模塊 。我們重點評估了兩條核心路徑：
進一步分析發現，從頭自研雖然理論上可控性強，但面臨“時間成本高、試錯代價大、人才投入密集”三大挑戰。尤其是在數據庫這類基礎設施領域，協議兼容性、執行引擎優化、并發控制等底層能力需要長期打磨，難以在短期內達到生產級穩定。
而基于開源項目二次開發，盡管前期需要投入大量時間閱讀源碼、理解架構，但可以快速獲得經過驗證的分布式執行引擎、SQL 優化器、元數據管理等核心能力。只要選型得當，并在關鍵路徑上做深度增強，完全能夠構建出滿足企業級需求的定制化系統。
因此，我們選擇基于開源項目 PolarDB-X 計算層進行深度二次開發的技術路徑。在保證技術自主性的同時，復用其成熟的分布式 SQL 執行引擎與優化器能力，有效規避重復造輪子的風險，實現研發效率與系統質量的平衡。同時，針對小紅書作為云原生、多云架構下的高并發、多租戶業務特點，在關鍵鏈路進行深度定制增強：
- 高可用層面，適配多云網絡異構環境，提升故障識別精度；
- 連接與元數據層面，去中心化配置管理，保障跨云部署的一致性與韌性；
- 治理層面，產品化參數級限流、邏輯會話管理等能力，支撐統一可觀測與精細化管控。
RedHub 并非簡單“拿來主義”，而是“站在巨人肩膀上，走出自己的路”——既借力開源，又超越通用，打造真正服務于小紅書未來十年架構演進的數據庫接入層。
04、能力突破：高可用、智能執行與透明治理的系統實現
RedHub 的價值不僅在于替代舊系統，更在于構建一套完整的能力體系。圍繞穩定性、功能性和可觀測性三大目標，我們在多個關鍵技術維度實現了系統性突破。
4.1 穩定性：從“脆弱依賴”到“閉環高可用”
MyHub 的高可用鏈路像一條“長鏈條”，任何一個環節出問題，整個系統就卡住。而 RedHub 的設計哲學是：核心路徑最短，依賴最少，自愈最快。
關鍵改進：
- 探活獨立：使用短連接獨立探活，磁盤故障也能秒級感知；
- Leader 仲裁：僅由 Leader 節點探活，避免集群放大問題；
<滑動查看 MyHub 和 RedHub 的對比>
基于 MyHub 的訪問
1. 不合理的組件依賴：配置變更路徑上存在 binlog 訂閱鏈路，導致依賴了 RedDTS 和 Kafka，從架構層級上看不合理、可用性上達不到高可用系統的要求，存在穩定性風險
2. 強依賴不可靠的配置中心：高可用切換核心鏈路上依賴了中心化的 Nacos 配置中心，非公司標準化組件，屬于自運維的開源產品，可用性保障弱
基于 RedHub 的訪問
3. 外部依賴簡潔清晰：僅依賴 orch、redhub-admin、metaDB 等幾個核心組件，內部閉環，且變更路徑短
4. 配置管理分布式化：不依賴中心化的配置中心，集群配置通過數據庫實現，下沉到各套集群并結合中心化 metaDB 實現雙備，可靠性高
- 連接可控：剛性連接池，最大連接數可配，徹底杜絕DB被打爆。
<滑動查看 MyHub 和 RedHub 的對比>
基于 MyHub 的訪問
連接上限不可控：MyHub 與 MySQL 之間的連接無上限，獲取連接時如果無空閑連接則觸發建連，通過控制建連的并發度來軟性限制，遇到流量洪峰和大量慢查場景，容易導致 MySQL 連接數打滿甚至直接宕機
隨著洪峰流量達到，MyHub 的后端連接數快速飆升到了1600+，直到達到 MySQL 配置的連接數上限，此時如果 MySQL 配置不足以應對這些連接開銷，將會被直接打掛。
基于 RedHub 的訪問
連接上限可控可調：通過最小和最大連接數參數控制 RedHub 與 MySQL 的連接數上限，有效保護 MySQL ，支持動態調節連接數限制，來實現性能調優、流量洪峰預熱等能力
RedHub 的后端連接數被嚴格控制在了連接池上限之下，MySQL 上的連接數得到了良好的控制，避免了被打掛的風險。
4.2 能力升級：從“SQL 轉發器”到“智能 SQL 引擎”
MyHub 的本質是“流量搬運工”，而 RedHub 是一個具備分布式數據庫能力的智能代理。
SQL 兼容性：從“寫不了”到“基本不用改”
- 基于 Druid 重構 SQL 解析器，支持復雜子查詢、ORDER BY、聚合函數；
- 引入 Session Context，支持事務隔離級別等會話變量；
- 經 SQLancer 工具測試，分庫分表場景 SQL 通過率從19%提升至92%。
分庫分表：終于能寫 JOIN 了
- 內置分布式優化器（RBO + CBO），自動拆解并優化跨分片查詢；
- 支持跨分片 JOIN、聚合、排序，語義正確，性能可控。
發號器：從“手動取號”到“無感自增”
- 支持 AUTO_INCREMENT BY SEQUENCE，建表時指定，插入時自動填充；
- 業務代碼不再手動獲取 ID 或者填寫發號器函數；
- 多種序列類型可選：號段、Snowflake、時間序列，靈活適配。
4.3 運維體驗：從“黑盒排查”到“透明治理”
以前查慢查詢，要登錄多個 MySQL 實例，手動拼 SQL；現在，RedHub 提供了真正的“全局視角”。
實時會話管理
- SHOW PROCESSLIST 查看到的是邏輯 SQL，一鍵 KILL 即可終止所有關聯的物理查詢；
- SHOW PHYSICAL_PROCESSLIST 查看底層實際執行，排障效率提升數倍。
<滑動查看 MyHub 和 RedHub 的對比>
基于 MyHub 的訪問
- 不支持邏輯 processlist：
MyHub 層無 processlist 視圖，需要到底層的各MySQL節點上分別執行 show processlist 獲取當前各自正在運行的SQL來進行匯總分析；需要kill慢查時，也需要在各MySQL節點上執行 kill 命令，可能會涉及多次kill，運維成本高，時效性難以保證
基于 RedHub 的訪問
- 具備邏輯 processlist 管理能力：
RedHub 層可以直接通過 show processlist 和 show physical_processlist 命令來分別獲取當前正在執行的邏輯查詢和物理查詢，并且支持直接kill對應的查詢，尤其是 kill 邏輯查詢時，能夠自動把關聯的底層所有物理查詢一并 kill 掉，大大簡化運維工作量，時效提升明顯
精細化限流：精準打擊“熱點SQL”
- MyHub 只能按SQL模板限流，而 RedHub 支持：
a.按庫、表、用戶、IP、SQL類型
b.按SQL模板和參數關鍵字（如 oid=2）精準限流
- 配置一條規則，即可熔斷特定熱點請求，避免雪崩。
RedHub熱點限流樣例
熱點SQL：
配置限流規則：
05、實踐驗證：低侵入遷移與關鍵場景閉環檢驗
我們深知技術再好，升級成本高也白搭。因此RedHub 的遷移設計核心是：業務無感、風險可控、支持到位。
5.1 平滑遷移：流量回放 + 漸進灰度
從 MyHub 升級到 RedHub，整體分為三個階段，業務側基本無改造：
- 流量回放：
- 在 MyHub Pod 上部署流量錄制組件，錄制業務SQL模板
- 部署獨立的 RedHub 集群，復制原集群的庫表結構
- 將錄制的業務 SQL 模板在 RedHub 集群上回放，完成 SQL 兼容性驗證
2. 灰度接流：將集群標記為遷移狀態，并在 MyHub 的集群中加入 RedHub Pod，灰度承接業務流量，逐步增加 RedHub Pod 占比
3. 完成升級：將所有 MyHub Pod 節點全部下線，僅保留 RedHub Pod，將集群狀態標記為遷移完成，集群類型變更為 RedHub。
5.2 真實場景驗證，助力穩定與高效
? 案例一：從庫磁盤故障自動隔離
某次線上從庫因磁盤寫滿導致服務不可用，RedHub 通過短連接探活機制在 15 秒內精準識別異常，自動將其從負載列表中摘除，業務查詢無抖動、無報錯，實現了故障“靜默自愈”。
? 案例二：熱點 SQL 快速限流恢復
某內部應用，因為熱點消息推送導致一個高頻查詢 SQL 掃描過多的數據，產生了大量的慢查詢。通過 RedHub 的精細化限流能力，我們在 2 分鐘內配置規則，精準攔截特定用戶 + 關鍵參數的請求，系統負載迅速回落，避免了服務雪崩。
與此同時，RedHub 的高 SQL 兼容性與完整功能支持，打破了過去“因能力不足無法接入代理”的僵局，讓原本只能直連數據庫的業務，也能以標準化方式接入。這為未來實現全量數據庫流量統一治理奠定了堅實基礎。
06、長期遠景：構建數據庫統一控制面與智能中樞
RedHub 的定位，從來不只是一個“流量轉發層”。我們正在將其打造為小紅書數據庫生態的統一控制面 —— 一個集 流量治理、安全管控、可觀測性與智能優化 于一體的數據庫中樞。
接下來，我們將圍繞四個方向持續演進：
- 統一訪問治理：構建細粒度權限模型，支持字段級脫敏、行級訪問控制，滿足多租戶與合規場景需求；
- 增強型數據安全：集成動態脫敏、SQL審計與敏感操作熔斷，讓每一次數據庫訪問都可管、可控、可追溯；
- 智能化運維能力：基于SQL執行數據構建性能畫像，自動識別慢查詢模式、推薦索引、預測容量瓶頸；
- HTAP 能力探索：支持冷熱數據自動分離，熱數據留存行存引擎保障事務性能，冷數據歸檔至列存引擎；通過 SQL 路由自動將分析型查詢導向列存，實現 AP 與 TP 資源隔離與統一入口，逐步邁向輕量級 HTAP 架構。
未來，RedHub 將不僅是業務訪問數據庫的“必經之路”，更會成為我們實現數據庫自治、可觀測、合規閉環與混合負載支持的核心樞紐。
07、作者簡介
Core Contributors
克邪（沈力鍇）
小紅書數據庫中間件研發負責人，主要負責小紅書數據庫代理、數據庫 SDK 和數據傳輸服務等數據庫中間件產品的整體架構和技術演進。
程普（沈文浩）
小紅書數據庫中間件研發工程師，聚焦數據庫代理研發，主攻數據分片、SQL 解析、流量染色與識別等核心技術，打造支持單元化架構的流量治理閉環，保障大規模場景下數據庫訪問的穩定與可控。
正雪（李宇辰）
小紅書數據庫中間件研發工程師，負責數據庫代理研發，聚焦高可用機制（探活摘流、故障隔離）、多云流量路由、SQL 性能優化及平滑升級、自動擴容等自動化運維能力建設，支撐大規模、多云環境下數據庫系統的穩定與高效運維。
