2017雙11技術揭秘—TDDL/DRDS 的類 KV 查詢優化實踐

作者：勵強（君瑜）

場景介紹

性能優化是企業級應用永恆的話題，關係型資料庫查詢優化更是如此。在前台核心業務場景中，類 KeyValue 查詢(以下簡稱類 KV 查詢)是非常常見的（例如，SELECT id, name FROM users WHERE id=1002），並且在應用總 SQL 流量佔比很高，例如，天貓某核心業務的類 KV 查詢佔比近90%，商品某系統中佔比近80%，交易訂單系統中佔比也有50%左右，菜鳥等其他核心業務場景中這個現象也是相當普遍。

這類 SQL 已經非常簡單，如果僅在SQL層面進行進一步優化會非常困難，因此針對這類場景，TDDL/DRDS 配合 AliSQL 提出了全新的解決方案。

產品簡介

在進入正題前，簡單介紹下 TDDL/DRDS 產品，TDDL 是阿里巴巴集團為了解決淘寶電商資料庫單機瓶頸，在2008年研製的中間件產品，以分庫分表為核心理念，基於 MySQL 存儲簡單有效解決數據存儲和訪問容量問題，該產品支撐了歷屆天貓雙十一核心交易鏈路的資料庫流量，並且在此期間逐步成長為阿里巴巴集團訪問關係型資料庫的標準。

2014年，TDDL 團隊和阿里雲 RDS 團隊合作，在雲上輸出這款產品，取名DRDS(Distributed Relational Database Service)，專註於解決單機關係型資料庫擴展性問題，目前該產品在公共雲上具有超過 1000 家企業用戶，並且在私有雲輸出，支撐多家大型企業和政府部門的核心業務，並且隨著業務的擴大和業界技術的進展，DRDS 產品也會逐步給大家帶來更加高效和務實的分散式資料庫功能和解決方案。

新的思路

TDDL/DRDS 的類 KV 查詢優化是怎麼做的?這得從尋找基於 MySQL 的新優化思路說起。2015年，我們注意到社區版 MySQL 在5.6支持了 InnoDB memcached 插件，該插件允許應用的類 KV 查詢走 Memcached 協議來直接訪問 MySQL InnoDB 引擎的Buffer（走 Memcached 協議與走 MySQL SQL 協議都能訪問 InnoDB 上的同一份數據）。這樣讓類 KV 查詢直接繞開 MySQL Server 層的解析器、優化器與執行器等過程，從而大大降低應用類 KV 查詢的 MySQL CPU 開銷，擴大類似雙十一極端場景下資料庫容量,並且有效降低資料庫響應時間。

MySQL Memcahced Plugin 的類KV查詢容量之所以能做到大幅度提升，是因為查詢完全繞開了 SQL 在 MySQL Server 層的各項開銷，查詢鏈路被極致縮短，事實上，這樣的優化思路對 TDDL/DRDS 也同樣適用。

TDDL/DRDS 目前作為阿里巴巴集團關係型資料庫的接入標準，為應用屏蔽了底層眾多的水平拆分及主備庫技術細節，然而，為業務帶來便捷的分散式 SQL 入口同時,付出的代價也是有的。在 TDDL/DRDS 中，每一條 SQL，從入口到返回結果，需要經過 SQL 語法解析、查詢優化、分散式執行計劃生成，以及分散式執行、連接處理、類型處理等一系列過程，這些動作需要消耗大量應用端 CPU ( TDDL 客戶端模式)，因此如果類 KV 查詢能在執行過程中完全繞開上述處理過程，直接走 Memcached 協議去查 MySQL 數據，那麼整個鏈路將被進一步精簡，從而提升應用的業務吞吐量和 DB 查詢容量。

沿著這個優化思路，TDDL/DRDS 在阿里巴巴集團內提供了 KV 功能，專門針對此類查詢場景實現極致的性能優化。

壓測驗證效果

為了專門驗證 TDDL/DRDS 的這一項優化在具體業務場景中的實際效果，我們與天貓某核心業務團隊共同在今年雙11的全鏈路壓測中進行 SQL 與 KV 的流量切換驗證。

KV場景TDDL-KV QPSTDDL-SQL QPS提升情況備註說明PK查詢1.7萬0.75萬PK吞吐提升124%PK類型是整數UK查詢1.6萬0.7萬UK吞吐提升131%UK類型是字元串二級索引查詢1.6萬0.7萬二級索引吞吐提升132%平均每個二級索引的KV結果集是2行

在這次壓測的過程中，應用層通過開關將集群QPS穩定在30w/s左右。然後，我們在 t1 時刻，將業務流量從走 KV 協議切回到走 SQL 協議，應用集群的 CPU 從 t1 時刻之後開始出現飆升，CPU從 46% 迅速升高到 63%,然後在 t2 時刻前後，業務再將流量從SQL切回KV，應用的 CPU 開始下降，整個過程持續5分鐘,對比切換前後，同等QPS的流量，走 KV 比走 SQL 能節省 17% 左右的CPU，這個對於動則以萬台來計算節點數量的核心應用而言，節省成本是明顯的。

此外，TDDL/DRDS還做了更為純粹的 KV 基準性能測試。在單純的 KV 查詢場景下，由於排除了業務處理邏輯的 CPU 開銷，類 KV 查詢走 KV 協議比走 SQL 協議吞吐提升會更為明顯。

技術的創新點

在技術原理上，TDDL/DRDS 的類 KV 查詢優化實現需要要依賴於 MySQL InnoDB Memcached 插件的特性。目前阿里巴巴集團 AliSQL 5.6 基於開源的 Memcached 插件代碼支持了這一特性。

在 TDDL/DRDS 中，一個類 KV 查詢走 SQL 介面與走 KV 介面卻有著本質的不同，它們分別使用不同的埠來與MySQL進行通信。因此，這使TDDL在內部要維護兩套不同的連接池，以及要處理兩種不同的查詢鏈路。

動態的分散式 KV 連接池

TDDL/DRDS 為保證 SQL 執行的穩定可靠，沉澱了各種成熟的保障機制，包括FailFast、主備切換、備庫分流與連接池動態管理等等。這些機製為 TDDL/DRDS 的穩定性發揮著不可替代的作用。

同樣為了保障 KV 優化功能在雙11核心業務場景中穩定可靠，TDDL/DRDS 引入分散式 KV 連接池以及動態管理機制。

該機制的核心實現思想是 KV 連接池管理器會定時拉取相關配置信息，然後核對配置信息，如果發現有變更，自動對池中各個KV連接狀態的進行相應的調整操作，例如完成KV的主備切換、備庫分流、替換DB機器IP等等等。

TDDL/DRDS 採用這樣的實現方案，一方面是為了保證 KV 連接池與 SQL 連接池的相互獨立，另一方面是為保證 KV 連接池的變更能夠與 SQL 連接池的變更保持協同。這樣一旦 KV 連接池存在穩定性的風險，允許應用將流量及時切回 SQL 連接池並做到快速恢復，從而很好地管控風險。

此外，TDDL/DRDS 為 KV功能在穩定性上還做其它一些很有用的工作，例如，支持按分庫灰度 KV ，這個特性允許單獨對某個分庫的查詢流量在 SQL 協議與 KV 協議之間進行對應用透明的動態切換，這非常適合在 TDDL/DRDS 這種管理眾多數據分片的場景下做流量的灰度驗證。

優化的KV通信協議

原生的Memcached協議的查詢結果默認使用「|」符號對一行記錄的各個列進行分隔，使用這樣的方式雖然簡單，但缺點也顯而易見。假如用戶記錄中含有「|」這種字元串或者因為中文亂碼導致一些奇怪的字元，Memcached協議的結果的傳輸就會錯亂，導致查詢結果不正確。

TDDL/DRDS 為了解決這個問題，在原生 Memcached 協議的基礎上進行了優化，設計了新的 KV 協議。新 KV 協議採用了更加普遍的通信協議設計方案，不再使用分隔符，而是改為固定長度位元組的header描述一行記錄中各個列值的長度，有效解決原生協議存在的問題。

KV 協議本身很簡單，返回的數據包中只有數據本身，協議開銷很低，並不像SQL協議，返回的數據包中除了含有結果集的數據外，還有相當部分是含有查詢結果對應Meta信息（如每列的數據類型、列名、別名、表名和庫名等等）。這些Meta信息會給SQL協議帶來額外的CPU開銷與網路開銷，更嚴重的是，這些開銷在KV查詢的場景下會被放大，因為KV查詢的返回結果通常是1~2條的記錄，Meta的數據包在返回的數據包中的比重會明顯增大，這並不太適全 KV 查詢場景。因此，KV 協議更適合 KV 查詢場景，這也是 TDDL/DRDS 的KV查詢能做到吞吐優化的原因之一。

KV結果的自動類型轉換

TDDL/DRDS 通過 KV 協議獲取的數據都是字元串類型，直接返回給業務字元串類型數據不符合需求。因此，TDDL/DRDS 必須具備對查詢結果各個列的字元串值進行自動類型轉換的能力。與此同時，這個類型轉換過程，必須嚴格遵循 MySQL 規範，才能良好適配 JDBC ResultSet 介面規範。

但是 KV 協議返回的數據包里並不含有列的元信息。因此，TDDL/DRDS 在解析 KV 返回結果之前，需要自己去獲取表相關的Meta信息並進行緩存,這樣，在解析過程中，就可以對結果按Meta進行類型轉換。

後續的規劃

TDDL/DRDS 目前還未在阿里雲公共雲或者私有雲產品上輸出這一特性，後續隨著產品發展，我們慢慢會開放這種能力。另外產品層面，我們將會使用類Plan Cached方案，進一步優化性能，從而達到使用SQL轉KV的鏈路如同直接使用KV一樣損耗的效果。