揭祕Sharding-Proxy——面向DBA的資料庫中間層
大家好,我今天想跟大家分享的是Sharding-Sphere的第二個產品Sharding-Proxy。
在上個月亮相的Sharding-Sphere 3.0.0.M1中首次釋出了Sharding-Proxy,希望這次分享能夠通過幾個優化實踐,幫助大家管中窺豹,從幾個關鍵細節想象出Sharding-Proxy的全貌。至於更詳細的MySQL協議、IO模型、Netty等議題,以後有機會再和大家專題分享。
一、Sharding-Proxy簡介
1Sharding-Proxy概覽
Sharding-Proxy定位為透明化的資料庫代理端,提供封裝了資料庫二進位制協議的服務端版本,用於完成對異構語言的支援。目前先提供MySQL版本,它可以使用任何相容MySQL協議的訪問客戶端操作資料(如:MySQLCommandClient、MySQLWorkbench等),對DBA更加友好。
適用於任何相容MySQL協議的客戶端。
與其他兩個產品(Sharding-JDBC、Sharding-Sidecar)的對比:
它們既可以獨立使用,也可以相互配合,以不同的架構模型、不同的切入點,實現相同的功能目標。而其核心功能,如資料分片、讀寫分離、柔性事務等,都是同一套實現程式碼。
舉個例子,對於僅使用Java為開發技術棧的場景,Sharding-JDBC對各種Java的ORM框架支援度非常高,開發人員可以非常便利地將資料分片能力引入到現有的系統中,並將其部署至線上環境執行,而DBA就可以通過部署一個Sharding-Proxy例項,對資料進行查詢和管理。
2Sharding-Proxy架構
整個架構可以分為前端、後端和核心元件三部分來看:
前端(Frontend)負責與客戶端進行網路通訊,採用的是基於NIO的客戶端/伺服器框架,在Windows和Mac作業系統下采用NIO模型,Linux系統自動適配為Epoll模型,在通訊的過程中完成對MySQL協議的編解碼;核心元件(Core-module)得到解碼的MySQL命令後,開始呼叫Sharding-Core對SQL進行解析、改寫、路由、歸併等核心功能;
後端(Backend)與真實資料庫的互動暫時藉助基於BIO的Hikari連線池。BIO的方式在資料庫叢集規模很大,或者一主多從的情況下,效能會有所下降。所以未來我們還會提供NIO的方式連線真實資料庫。