癸卯七月風雨大作
京東零售·袁博文
僵卧雙九不自哀，尚思為東戍輪台。
夜闌卧聽珊瑚雨，鐵馬內核入夢來。
前言略長，只關心技術的同學可直接跳過看第二章
一、前言：技術的底色是什麼？
這個問題在技術人心中其實沒有標準答案，每個人都有每個人的見解。架構師眼裏大抵是高屋建瓴，統領全局；技術大牛的視角可能是剖根溯源，精刀細琢；新人小白或許更單純，無非就是學習進步，快速成長為大牛之類了。
但在我——一個京東數據庫人的眼裏，技術的底色或許應該是五彩斑斕的吧。
白是純粹的起點
經常聽人説，每個人呱呱墜地那一刻，都是一張白紙，父母在其上着墨。對於技術人來説又何嘗不是呢？初學一門技術，初入一個領域，每個人都是一張白紙，在這張白紙上是隨意草稿塗鴉，還是認真吸收不斷進步，都取決於自己。
數據庫內核技術，在 2020 年初，於我個人於內核團隊於京東而言都是一個純白的起點。自此開始探索數據庫內核的每一行源碼、每一個模塊，然後攻關研究每一個技術難點，再設計實現雲原生的珊瑚數據庫直到其落地承接業務。我和我們團隊的小夥伴都可以拍着胸脯説，我們無愧於京東，無愧於這份純白。
青是朝氣是成長
內核團隊每一個小夥伴，不論是社招還是校招，都是那麼朝氣蓬勃，都對數據庫內核技術求知若渴。騰龍認真鑽研探索，成功打通了數據庫測試用例線上部署和初始的內核監控框架；福哥將華為的優良編碼風格帶入團隊並影響了許多小夥伴，還在DDL模塊鑽研並頗有造詣；海鵬探索並打通了內核與JED接口，為高可用付出良多；金蓬初入團隊，甚至連技術棧都是初學，抱着一本經典的《C++ Primer》邊啃邊研究珊瑚數據庫內核源碼，但不妨礙進步速度驚人，最終能夠獨當一面；海波攻關的修改緩衝影子頁技術以及共享集羣測試框架至今還在持續帶來價值；珊哥和齊哥更不用説，一個將多年積累的開發經驗與珊瑚數據庫內核模塊深入結合，做出了諸多貢獻；另一個不但對元數據鎖研究透徹，更是獨自一人承擔了整個珊瑚數據庫的工程化落地與高可用及運維工具建設。作為校招生的彭凱和宇歆，更是在短短的時間內，迅速成長，深入研究SQL詞法和語法解析，以及主從複製模塊，併為新產品的鑄劍做出了突出的貢獻。現在，越來越多的朝氣蓬勃的新夥伴陸續加入了我們團隊，大家的快速成長都有目共睹。
大家都從當初的青澀小白，成長成了各個內核領域的專家，或者獨當一面的人才。所以青這個底色，一定是技術人努力成長，拼搏向上的顏色吧。
黃是最後的執着
在眼看京東數據庫內核團隊蒸蒸日上，大家在內核領域日漸深耕的時候，不出意外的還是出意外了……
集團層面的架構調整，讓零售和科技的技術團隊不得不融合成一個團隊了，我想初衷肯定是好的，大家也都為之努力過。但出於種種不便明説的原因，數據庫內核團隊成了大的架構齒輪磨合下的那個代價，團隊動盪，未來不明，無奈之下許多初露鋒芒的優秀小夥伴不得不做出各自的選擇。就在我以為京東數據庫內核就要黃了的時候，不幸中的萬幸，在零售眾多大佬同事的全力保護下，內核的種子留了下來，靜待花開。而屬於技術人的這份堅守，或許就像鵝卵黃一樣，等待破殼重生的那一刻吧。
赤是對技術的熱忱
如果希望有顏色，那麼一定是紅色！
就像赤色當年卧薪嚐膽，艱苦奮鬥，爬雪山過草地，把希望帶給神州大地一樣。屬於京東技術的赤色，也在京東技術中心迎來新的大家長後隨之到來。我不知道其他團隊是不是有類似的感受，但數據庫團隊在迴歸零售以後，大家的心氣神都不一樣了，對技術那顆火熱的心又重新燃了起來。數據庫團隊也迎來了新leader：一位在數據庫領域有着二十年經驗的超級大佬和一位在數據庫內核領域有十多年經驗的資深大佬。在兩位大佬的帶領下，我們開始朝着新的方向前進。
同時，數據庫內核團隊也很快迎來了越來越多的新鮮血液：來自其他大廠的林康、正茂、張揚，將他們所掌握的數據庫內核以及工程化經驗引入，為我們內核的研發裝上了加速器；來自各大名牌高校的校招生以及實習生曉冰、江昊、一賢、祖才等等，也都快速學習迅速成長，以最飽滿的熱情融入我們團隊並做出了相應的貢獻。
大家都飽含赤誠，攜手開始向未來進發！
黑是五彩斑斕的未來
始於白，終於黑。就像太極陰陽魚一樣，生生不息，周而復始。技術也一樣！
自然界當所有的顏色混在一起後，只有一個顏色——黑。數據庫內核的團隊也在沉澱和挫折中更加強大，隨着不斷補充新鮮的血液，從市場上吸引更多優秀的數據庫內核人才，當所有技術的底色混在一起後，所有的五彩斑斕，所有的初心、成長、堅守、希望融為一體後，所有的不同領域的人才齊心協力共渡難關後，那結合在一起的力量，其實就只剩下未來那無限的可能——五彩斑斕的黑。內核技術的深淵也如黑洞般，深不見底，等待我們去探索。但我相信，只要我們秉持技術人的底色，就一定可以達到那個彼岸！
二、正篇：五彩熔爐，鑄劍！
正篇開始！
抱歉大家，前面扯了這麼多其實只是前言。但我又不想像以前寫前言那樣，只是簡單的交代一下背景。花了五節的筆墨介紹我心中的技術底色，只希望大家能懂一點——我們會以最大的熱情和最強的技術為京東打造基礎數據庫產品，為大家帶來更優質的數據庫服務。
到底鑄了什麼劍？
屬於我們京東電商版本的自研數據庫內核——DongSQL！
五年前，數據庫內核團隊立項直接瞄準了新的數據庫形態——雲原生關係型數據庫，也就是存算分離共享存儲架構的珊瑚數據庫(shared storage)，這一版技術難點主要是在共享存儲的架構以及雲原生的數據一致性，其產品價值主要是在節約數據庫成本以及極致的雲上資源伸縮性等。但由於與存量JED庫(shared nothing)採用了不一樣的技術架構，所以面臨一個現實問題——存量用户版本無法平滑升級。
用過或者瞭解數據庫的人都知道，有的時候不是大家不想使用更新的版本，更強的性能，更優秀的功能，而是數據庫本身太基礎太重要了，如果業務系統已經建設很多年，與數據庫綁定太深的話，更多還是求穩為主，能不動則不動。這不是京東獨有的情況，可以説整個行業皆是如此，這叫技術慣性。正是因為採用了新的技術架構，帶來了一個問題：存量業務如果要使用必須進行數據庫的遷移。就這一個原因，很多業務就望而卻步。
正是由於這個原因，在新leader帶領我們團隊以後，基於豐富的數據庫經驗，敏鋭地察覺到京東整個數據庫的基本盤其實是存量的數據庫，解決存量數據庫用户的問題才能帶來更大的價值。再優秀的產品，如果沒人用一樣白費力氣。
因此，我們需要做的是，一個完全適配存量架構的數據庫內核，不引入更復雜的架構變更和過多的設計，只在其基礎上對數據庫內核性能進行優化、對配套能力進行提升、對零售電商場景進行針對性擴展，完美支持JED以及DongDAL，秉持穩定性和兼容性為前提的基礎上，讓京東的數據庫內核更好用，更強大！
電商場景下數據庫痛點的解決之道
電商場景的數據庫需求其實是用户最迫切的，因此我們在首選開刀方向時，沒有選擇引入花裏胡哨高大上的功能等角度。而是從用户中來，回到用户中去，深入分析目前線上用户最常見的問題，以及大促最常見的故障場景，針對性的引入了內核層新的解決方案。
問題一：“過載” 大促激增的流量，或者超時SQL不斷重試直接把數據庫CPU打滿甚至打掛
這種場景真的非常常見，甚至前段時間還有一個白虎故障就是類似的原因。業務研發在設計功能的時候，其實是無法預知線上生產環境真實的流量的，或許可以設計應用側限流，也或許可以加緩存抗量，但限流不是每個系統都有，即使有也可能存在疏漏，緩存如果被擊穿那帶給數據庫的流量更是暴擊。有的時候甚至不是真實暴增的流量，而只是超時機制的負反饋，失敗的不斷重試就帶來了超出預期的數據庫請求。
當請求流量突然暴漲時或者突發的慢sql佔用大量資源時，它會像一個被瞬間涌入人羣擠垮的服務枱：每個新連接都需要數據庫創建一個線程來處理，大量線程的創建、上下文切換和維持本身就會吃掉可觀的內存和CPU；更重要的是，每個查詢進來，內核都要瘋狂工作——解析複雜的SQL語句、在成千上萬條索引條目中查找路徑、拼湊關聯多張表的數據、進行排序分組計算、管理事務保證一致性（這涉及到頻繁的加鎖解鎖，高併發時極易堵塞排隊）、還要不斷從磁盤讀取數據或把改動寫回去。所有這些操作都是極度消耗CPU算力的密集計算。當每秒涌入的請求遠超CPU能處理的速度時，CPU就會被完全佔滿，所有查詢都擠在一起排隊等待計算資源。與此同時，高併發下鎖衝突劇增，大量線程因等待鎖而阻塞卻不釋放資源；內存可能被臨時表、排序緩存塞爆；嚴重時磁盤IO也跟不上。最終，CPU被徹底耗盡，新連接無法建立，已有查詢完全卡死，整個數據庫進程失去響應，就像被“打掛”了一樣，本質上就是所有關鍵資源（CPU、內存、IO、連接）在瞬間洪峯下被徹底榨乾導致的系統性崩潰。
原因很清楚，解決方式也很簡單，前面也提到了，限流即可，可實際生產環境操作起來還是會出現諸多困難。
業務層自行限流面臨的主要挑戰在於其“粗放”和“滯後”。它通常只能基於簡單的請求頻率或用户維度（如QPS）進行攔截，無法洞察數據庫內部真實的瓶頸所在（比如是在CPU、內存、磁盤IO還是鎖衝突）。這極易導致“誤殺”——核心的重資源消耗型SQL可能未被攔住，反而大量高頻但輕量的請求被限流，犧牲了業務可用性卻未能真正緩解數據庫壓力。同時，在分佈式微服務架構下，協調各個服務模塊統一、實時地實施並調整限流策略異常困難，很容易出現限流不一致或響應遲緩，當業務層感知到數據庫響應變慢或報錯再觸發限流時，往往已經錯過了最佳干預時機，雪崩可能已經發生。
目前的實際操作往往是高可用程序或者DBA依靠HA機制進行主備切換來應對過載。切換過程本身必然導致數秒到數十秒的服務中斷（連接閃斷、短暫只讀），對連續性要求高的業務會造成直接影響。更重要的是數據一致性問題：主庫在故障或過載瞬間可能存在未同步到備庫的事務數據，切換後這些數據可能永久丟失（異步複製下），即使使用半同步複製也可能因網絡問題阻塞寫入或退化為異步。歷年大促線上生產環境不少故障甚至是發生在切換操作之後(普通RDS集羣以及低版本vitess集羣風險尤其顯著)。
解：SQL自提示實現精準限流
基於以上痛點，不少用户提出，如果可以實現精準限流就好了，既能在業務根據流量預測的基礎上預防性限流，又能在過載發生後根據簡單排查的結果定向限流。有求必應——Hint限流方案橫空出世！
// 根據特定 SQL 指紋進行限流
update/*+ ccl_queue_digest(INT<當前語句的並行數>) */ t set col1 = col1+1 where 1=id;
update/*+ ccl_queue_digest() */ t set col1 = col1+1 where 1=id;
數據庫內核自身支持限流的核心優勢是，我們能深入到SQL執行層，根據用户指定規則（如匹配特定SQL指紋、或者SQL語句全文等不同模式規則）實時識別並優先抑制那些真正“吃掉”大量資源的“罪魁禍首”查詢。這如同在數據庫引擎內部安裝了一個智能節流閥，直接從源頭（消耗資源的查詢）進行精準控制，避免了業務層限流的盲目性和HA切換的破壞性。它能在資源緊張初現端倪時就主動干預，最大限度保障核心業務請求的通過和系統整體的穩定性，且由內核統一管理，規則生效及時、策略執行高效。
問題二：“秒殺” 單點高頻寫入帶來的數據庫性能下降，以及庫存一致性問題
秒殺是電商業務非常常見的場景，無論秒殺業務是否設計緩存前置抗量，庫存數據的最終變更都是需要落到數據庫的。如果緩存發生擊穿，更是需要數據庫來進行兜底策略。但秒殺這個場景的數據庫操作又極其特殊，甚至可以説會導致傳統數據庫痛點集中爆發。
首先，高頻單行更新使行級鎖競爭成為致命瓶頸：當海量請求同時扣減同一商品庫存時，存儲引擎的行鎖強制串行更新，導致線程在鎖等待中堆積；死鎖檢測機制在隊列過長時（如超1000線程）觸發深度遍歷，CPU資源被瘋狂消耗，事務響應時間驟增甚至超時。
其次，高頻事務的ACID保障帶來巨大開銷：事務在數據庫內核中是核心能力之一，在秒殺場景下往往都是簡單事務，但為了保證查詢更新的一致性，又不得不開顯式事務(非auto commit)，而顯式事務的BEGIN、Statement、COMMIT/ROLLBACK，每一個子句都會完整的經歷應用側到數據庫底層的多級轉發和網絡開銷，伴隨多次網絡交互（跨節點延遲加劇堵塞）及日誌寫入，單事務耗時飆升，系統吞吐量斷崖式下跌。
最後，秒殺場景的庫存扣減不允許出現意料外的更新：傳統數據庫的高併發扣減需通過SELECT檢查庫存後再執行UPDATE，但兩步操作存在時序漏洞——高併發下多個請求可能同時讀到相同庫存值，導致超賣；同時所有請求（包括庫存不足的無效請求）均需競爭同一行鎖，引發線程堆積和死鎖檢測的CPU暴增。
解：電商秒殺場景定製優化
秒殺排隊：高頻更新問題很好解決，借用限流的思路，只不過秒殺場景要限的是具體的字段甚至是具體的值，因為高頻SQL是集中在具體數量的庫存或者單一品類上的，要改的可能就幾行甚至是一行數據。因此，我們借用了限流的Hint語法，業務只需要在預期秒殺需要更改的具體SQL上，加上對應的Hint規則，約定具體字段或者具體值需要進行限制排隊執行，數據庫內部就會對秒殺類的SQL進行管理排隊，極大程度的規避了行鎖的競爭以及其連鎖反應，經測試單行更新高併發場景下，比傳統數據庫的流量能提升一倍以上。
// 根據熱點值限流
update/*+ ccl_queue_value('茅台') */ t set c=c+1 where name ='茅台';
// 根據熱點字段限流
update/*+ ccl_queue_field(order_id) */ t set c=c+1 where order_id =1and name ='茅台';
事務快速提交/回滾：針對秒殺事務的特性，設計了事務快速提交回滾的Hint，即用户在事務COMMIT/ROLLBACK前的最後一個SQL語句上，如果加上該Hint，則內核即明白該操作提交或者回滾了。此方案在秒殺場景下，尤其是特定單行更新的場景下，最高可以提升 3 倍以上的性能！優勢非常明顯。
影響行數約束：秒殺場景庫存扣減，或者其他非秒殺場景也可能存在，業務側的邏輯明確知道某條SQL更新後應該影響幾行數據，如果數據庫執行完發現影響的行數不符合預期則大概率出現問題了，需要將事務進行回滾。我們設計了預期影響行數的Hint，通過該Hint（示例 UPDATE /*+ TARGET\_AFFECT\_ROW(1) */ stock SET count=count-1 WHERE id=100 AND count>=1），可同步實現兩大核心優化：
其一，引擎在加鎖前優先校驗 WHERE 條件（庫存≥1），僅當庫存充足時才嘗試加鎖更新，庫存不足的請求直接返回影響行數=0，避免無效鎖競爭；
其二，庫存檢查與扣減壓縮為單原子操作，確保影響行數嚴格為1才成功，否則自動失敗，徹底杜絕跨事務的髒讀與超賣風險。當然也可以配置其他數值，只要與您預期的影響行數一致即可。
問題三：“緩存更新一致性問題” 業務前置緩存失效時，會直接更新數據庫，然後查詢已更新數據並返回
許多業務系統會在數據庫訪問層之上引入緩存，例如京東的分佈式緩存JIMDB，以利用其極致的讀寫響應速度優化用户體驗。然而，緩存的易失性本質決定了其無法獨立承擔關鍵數據的持久化職責——數據庫始終是不可或缺的兜底保障（除非數據可容忍丟失）。維護緩存與數據庫之間的強一致性是系統設計的核心挑戰，當緩存失效導致請求穿透至數據庫時，業務常需同步獲取剛更新的數據並實時刷新緩存或響應前端。傳統數據庫在此場景下存在顯著侷限：若要在事務中確保更新後立即可見且數據一致，必須在DML操作後緊跟一條SELECT語句進行查詢。但即便採用此方案，在讀已提交（RC）隔離級別下，其他事務的併發修改仍可能導致該查詢讀到不一致數據，無法滿足嚴格的實時一致性要求。
解：實現RETURNING語法
我們通過實現RETURNING語法解決這一問題：在UPDATE/INSERT等DML語句末尾追加RETURNING子句，就能直接獲取修改後的完整行數據。比如庫存扣減場景下，一條UPDATE inventory SET stock=stock-1 WHERE id=100 RETURNING *;語句既完成了原子扣減，又能立即返回最新庫存值，無需額外SELECT查詢。
這一內核級優化不僅消除了RC隔離下的併發髒讀風險（DML與返回數據基於同一事務快照，其他事務的併發修改不會干擾結果），還將“更新 + 查詢”的兩次網絡交互壓縮為單次請求，把事務耗時再降一個級別。對緩存架構而言，業務側拿到RETURNING返回的實時數據後，能立刻刷新緩存層，在事務提交時就完成數據對齊，讓秒殺、大促等高併發場景下的“緩存擊穿兜底邏輯”，既快又穩。
問題四："執行計劃漂移" 好好的SQL突然就慢了
這個問題真的讓人頭疼，一條SQL在開發環境跑得飛快，到了線上就變成了蝸牛。更要命的是，有時候同一條SQL，今天還好好的，明天就突然慢得要死。
舉個例子，我們有條訂單查詢的SQL：
SELECT o.*, u.name
FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.create_time
BETWEEN '2025-10-01' AND '2025-10-30' AND o.status IN('PAID','SHIPPED')
ORDER BY o.create_time DESC LIMIT 100;
平時這條SQL毫秒級就能出結果，用的是orders.idx_create_time索引。但有一天大促期間，這條SQL突然開始走全表掃描，30秒才能跑完，直接把系統拖垮了。
為什麼會這樣？數據庫優化器是個"聰明"的傢伙，它會根據表的統計信息來選擇執行計劃。但問題就出在這些統計信息上——ANALYZE TABLE更新了統計信息，數據分佈發生了變化，或者系統負載影響了成本計算，優化器就可能突然"變心"，選擇一個完全不同的執行路徑。
這種情況在大促期間特別危險，數據量激增、系統負載變化，一條核心查詢的執行計劃突然劣化，整個系統可能就垮了。
傳統的解決辦法要麼重啓數據庫（代價太大），要麼業務研發加Hint強制索引（破壞代碼可維護性，還得緊急上線，時間週期長），要麼調優化器參數（可能影響其他SQL），都不是很好的選擇。
解：Statement Outline執行計劃固化功能
為了解決這個問題，我們實現了Statement Outline功能，可以把穩定高效的執行計劃"固化"下來，讓優化器按照我們指定的方式執行。這個功能通過存儲過程包來管理，使用起來很簡單。比如我們發現某個查詢有個很好的執行計劃，就可以把它記下來，一旦發生上述意外場景，可以立即將其注入數據庫從而穩定該類型SQL的執行：
-- 添加優化器hint的outline
CALL dbms_outln.add_optimizer_outline(
'your_db', -- 數據庫名稱
'', -- SQL語句的摘要，為空時自動計算
1, -- 位置，通常為1
'/*+ USE_INDEX(orders idx_create_time) */', -- 優化器提示文本
'SELECT o.*, u.name FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.create_time BETWEEN '2025-10-01' AND '2025-10-30' AND o.status IN ('PAID', 'SHIPPED')
ORDER BY o.create_time DESC LIMIT 100;' -- SQL語句文本);
-- 添加強制索引的outline
CALL dbms_outln.add_index_outline( 'your_db', -- 數據庫名稱
'', -- SQL語句的摘要，為空時自動計算
1, -- 位置，通常為1
'USE INDEX', -- 索引提示類型，如'USE INDEX'、'IGNORE INDEX'等
'idx_status', -- 索引列表，多個索引用逗號分隔
'', -- 索引提示選項，如'FOR JOIN'、'FOR ORDER BY'等
'SELECT o.*, u.name
FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.create_time BETWEEN '2025-10-01' AND '2025-10-30' AND o.status IN ('PAID', 'SHIPPED')
ORDER BY o.create_time DESC LIMIT 100;' -- SQL語句文本);
這樣一來，即使統計信息變化了，優化器也會按照我們固化的執行計劃來執行，保證查詢性能的穩定性，讓我們能夠精確控制查詢的執行方式。對於那些業務關鍵的SQL，這個功能簡直是"定海神針"，徹底解決了執行計劃漂移的問題。
Outline還可以注入自定義的hint，比如“問題一”中的解決過載問題hint或者“問題二”中的秒殺場景hint。
問題五："線程擁堵" 每連接每線程的弊病
傳統數據庫是沒有線程池的，每個連接都要創建一個獨立的線程來處理，常規場景每連接每線程還很穩定，但高併發場景下就是災難。
想象一下大促期間的場景：成千上萬個連接同時涌入數據庫，每個連接都要創建線程，線程創建和銷燬的開銷巨大，CPU忙着做上下文切換，真正用來處理SQL的時間反而不多。更要命的是，所有請求都是一視同仁，核心的支付查詢可能被大量的日誌寫入、報表查詢這些不緊急的請求給"淹沒"了。在JED架構下，由vitess控制了連接的數量，這個問題還不大，但目前DongDAL直連DongSQL的架構，這個就成了不得不面對的重點問題！
線程擁堵的問題看起來和過載很像，但還略有一點區別。過載場景可以精確識別到個別問題SQL，並進行精準限流，從而保證不影響其他SQL。而線程擁堵的大部分甚至所有連接都是正常SQL，沒有誰是受害者，只不過突發流量真的太大了！所以這種場景，我們就不得不祭出大殺器——線程池！
解：DongSQL線程池
我們實現了完整的線程池功能，能夠有效複用線程資源，避免頻繁創建和銷燬線程的開銷。線程池會維護一組工作線程，新來的連接請求會被分配到空閒的線程上處理，這樣就能大大減少上下文切換，提升高併發場景下的性能。
這樣一來，來自核心服務器/核心用户的請求就能優先得到處理，不會被其他不那麼緊急的請求給擠佔了。系統會智能識別高優先級連接，確保關鍵功能的響應時間。
這些優化功能的加入，讓DongSQL在高併發、大數據量的零售電商核心場景下展現出了更強的穩定性和性能。每一個功能都是我們在實際業務中遇到問題、分析問題、解決問題的結果，希望能夠幫助更多的團隊應對類似的挑戰。
三、結語：技術的成色又是什麼呢？
如果説技術的底色，是求知、是成長、是執着、是熱忱、是我們所有技術人團結在一起爆發出的力量。
那麼技術的成色，一定有腳踏實地，追根溯源，不浮於表象，而深入骨髓地解決根本問題。正所謂：求木之長者，必固其根本；欲流之遠者，必浚其泉源。對於數據庫，則必須具備掌控數據庫內核的能力，方能使自身以及其上承接的業務行穩致遠。
除此之外，更宏觀的維度，技術的成色我想應該就是為團隊、為公司、為用户、乃至為社會產生實實在在的價值吧！正如公司使命説的那樣：技術為本，讓生活更美好！ 讓我們攜手所有業務研發團隊做實事、有價值的事、長期的事，為京東的 35711 夢想付出我們自己的一份力！
