摘要：目前市面上已經有OneProxy、TDSQL、MyCat、360Atlas等出色的數據庫中間件，對于如何選型，不同公司會有不同的考慮，當然也有公司會選擇自研，網易電商樂得在實際生產中就根據需要研發了自己的中間件Cetus，并于不久前開源。...
電商系統中，隨著業務量的增大，讀寫 QPS 越來越高，單節點 MySQL 實例壓力越來越大，單純的對服務器硬件升級已經無法滿足生產環境的需要，對數據分片增加多個節點，降低單節點 MySQL 實例的壓力成了必然選擇。傳統的分片是通過 DAO 層進行的，但是 DAO 層對數據分片存在諸多問題：
從業務角度看，配置修改需要重啟服務，代價巨大；需要對分片結果集進行處理，業務邏輯愈加復雜；功能相對簡單。
從數據庫運維角度看，配置管理的統一化難度較大；DB的升級、遷移等操作復雜。
因此 MySQL 數據庫中間件應運而生，解決了上述 DAO 層的諸多問題。MySQL 數據庫中間件為業務提供了統一的入口、對業務透明，提供了讀寫分離、分片、豐富的路由策略，以及其它較為實用的統計、管理、鑒權等功能。
目前市面上已經有 OneProxy、TDSQL、MyCat、360 Atlas 等出色的數據庫中間件，對于如何選型，不同公司會有不同的考慮，當然也有公司會選擇自研，網易電商樂得在實際生產中就根據需要研發了自己的中間件 Cetus，并于不久前開源。
項目地址：
GitHub
碼云
Cetus 主打穩定、高性能和對開發友好，并以 OneProxy 等出色中間件為追趕目標，那它的具體設計思路與能力如何？開源中國采訪了 Cetus 負責人@王斌，請他從項目背景、設計思路、研發經驗與未來計劃等幾個方面為讀者全面解讀 Cetus。本文由采訪整理而成。
嘉賓介紹
王斌，網易高級技術專家，愛好開源，tcpcopy 和 Cetus 主要開發人員之一，希望為中國開源做點貢獻，目前主要負責 Cetus 項目，關注領域包括分布式數據庫、網絡與機器學習。
項目背景
樂得作為網易的電商系統，近年來業務不斷發展，隨之而來的是數據庫數據量和訪問量的不斷變大。當數據量達到一定量級，尤其是寫請求過于頻繁時，傳統 MySQL 架構很難支持樂得的大業務，因此我們考慮用水平切分的方式進行優化，以降低單個庫、單個表的壓力。
已有的開源分布式 MySQL 中間件具有不穩定、對開發不友好等問題，很難直接采用，于是我們決定自主開發一款分布式事務功能的 MySQL 中間件，我們有幾個目標想要達到，包括高可用、高性能、讀寫分離、分庫等。自己開發有個好處就是自研可控，可以按照實際需求添加新功能，并且可以及時修復 bug。
這一次將 Cetus 開源也是想跟同行一起將它打造成一款出色的 MySQL 中間件，把 MySQL 后端集群整合成一個強有力的分布式數據庫。
讓 MySQL 更加強大
先介紹一下 Cetus 這個名字的意思，Cetus 這個英文翻譯成中文是“鯨魚座”，大家知道 MySQL 官方 logo 是海豚，鯨魚和海豚同屬于一個類別，而鯨魚體型更大點，把這個項目命名為 Cetus，一方面是想讓 MySQL 更加強大的意思，另一方面鯨魚座代表了我們有著胸懷宇宙的情懷，想把 Cetus 做得更好、更長久。
Cetus 專注于性能、穩定和分布式事務，目標是做一款可以媲美 OneProxy 和 TDSQL 等商業軟件的中間件。
下邊拿 Cetus 和一些知名的數據庫中間件或者NewSQL一起做個小分析：
OneProxy 是商業軟件，在穩定性和性能方面遠勝其它開源中間件，它一直是我們追趕的對象。
TiDB 代表了 NewSQL，是為大數據設計的，但由于成本較高，在可以使用 MySQL 的地方不建議使用 TiDB。
TDSQL 是騰訊開發的數據庫中間件，為騰訊云服務，它在 MySQL XA 分布式事務方面進行了很多探索，為我們的分布式事務處理提供了很多思路。
MyCat 功能較為復雜，細節方面還待改善（如算法沒有優化、存在很多使用上的坑），用戶的抱怨比較多，與優秀的數據庫中間件差距較大。
至于360 Atlas，它是一個長期沒有更新的中間件，設計、穩定和性能不佳，導致了很多用戶放棄使用。
……
了解到其它開源和商業數據庫中間件的設計思路和存在的問題，我們在 Cetus 中大量借鑒和改進，這成了 Cetus 的優勢。相比其它開源數據庫中間件，Cetus 會更加貼近用戶，兼顧開發和整體效率，同時規避了影響數據庫中間件穩定和性能的坑。主要特點有：
自主開發的解析器，無需依賴第三方解析器，更新可控
異步處理，無任何阻塞，類似 Nginx
并行處理，對多個后端并行訪問，減少延遲
tcp stream 處理，tcp stream 可以分解大響應處理過程，從而可以公平處理各個外部事件，同時也解決了內存炸裂問題
分布式事務支持
對開發無感知，開發無需去了解這個事務是不是分布式事務，像MyCat、DRDS 等中間件需要用戶顯式去指定這個事務是不是分布式事務，這對開發人員不是很友好
分布式事務深度優化，繼承了騰訊 TDSQL 的不少優良特點
緊跟 MySQL 趨勢
在重置 MySQL 連接方面，MySQL 5.7 開始支持 reset conn，而 Cetus 已經采用了 reset conn 代替 change user，以降低 MySQL 的 CPU 開銷
支持 MySQL Group Replication，集群產生新的寫節點，Cetus 會及時更新寫節點信息，實現服務高可用
利用GTID tracking，自動實現一致性讀（正在開發中）
設計思路與技術細節
Cetus 位于應用程序與 MySQL 數據庫之間，作為前端應用與數據庫的通訊。其中，前端應用連接 LVS 節點，LVS 節點映射端口到多個 Cetus 服務，后者通過自身的連接池連接到后端的數據庫。
整體網絡架構如下圖所示：
Cetus 主要的功能模塊包括以下五個部分：
讀寫分離
分庫
SQL 解析
連接池
管理功能
各個功能模塊間的交互關系如下：
其中，SQL 解析模塊為后續讀寫分離和數據分片等功能解析出 SQL 類型、表名和查詢條件等關鍵信息；連接池模塊是自維護連接池，支持 Cetus 根據需求查詢和檢測后端，維護連接數，具有高效連接共享性、事務與 Prepare 的前后端綁定功能和熱點連接重用與連接等待機制；管理功能模塊通過用戶在管理界面輸入，獨立認證并轉到下一狀態，給用戶回復狀態查詢結果或調整參數。
Cetus 的整體工作流程：
Cetus 讀取啟動配置文件和其他配置并啟動，監聽客戶端請求；
收到客戶端新建連接請求后，Cetus 經過用戶鑒權和連接池判斷連接數是否達到上限，確定是否新建連接；
連接建立和認證通過后，Cetus 接收客戶端發送來的 SQL 語句，并進行詞法和語義分析，對 SQL 語句進行解析，分析 SQL 的請求類型，必要時改寫 SQL，然后選取相應的 DB 并轉發；
等待后端處理查詢，接收處理查詢結果集，進行合并和修改，然后轉發給客戶端；
如收到客戶端關閉連接的請求，Cetus 判斷是否需要關閉后端連接，關閉連接。
如下圖所示：
Cetus 目前分為兩個版本，分別是讀寫分離和分庫版本，這主要有兩個考慮：
分庫解析器和讀寫分離解析器很不一樣
Cetus 是基于 MySQL proxy 基礎上做的，由于原先代碼架構不是很好，不易統一，隨著以后代碼架構的不斷完善，兩個版本統一問題會最終得到解決
在讀寫分離版本中，通過對 SQL 進行解析，根據 SQL 特點和 GTID tracking 智能選擇路由主庫或從庫，從而實現讀寫分離，減少主庫的壓力，同時通過相關策略，保證從庫上進行負載均衡。
而分庫的思想是參考了 Fabric 和 OneProxy，采用了 vdb 的思想，一個 vdb 代表一個具體的分片規則，Cetus 確保同一個 vdb 內可以 join，不同 vdb 相互隔離，兼顧垂直拆分和開發對 join 的需求，不同 vdb 之間可以走分布式事務。
但 Cetus 基于以下考慮，不支持分表：
MySQL 分區性能會越來越好
Oracle 分區功能強大，而 MySQL 是 Oracle 公司的，并且 MySQL 5.7 以后的分區性能越來越好。
我們電商系統沒有用到分表功能
我們預測，未來 MySQL 分區會逐漸取代分表，類似 Oracle 原先走的路線，鑒于這個判斷和緊跟 MySQL 趨勢，樂得電商放棄了分表功能開發。
研發過程中暴露的問題
在項目開發過程中，我們遇到了一些難點與坑，并且有相應的解決思路，這里與大家分享一下。
構造分庫測試環境
我們改造了 tpcc、Zabbix 等軟件，以支持分布式數據庫使用場景。改造 tpcc 是為了測試分庫性能和分布式事務性能；改造 Zabbix，是為了讓分庫版本盡快用起來，盡早去發現問題。
線上規避問題
線上如果出大的問題，開發是很難接受的，因此確保線上盡量不出大問題，是遇到的最大挑戰。為了更好地解決此問題，我們專門優化了 tcpcopy，使其更加適合流量測試。
目前80%以上的線上潛在問題都被流量測試所發現。
分布式事務
MySQL 在這方面是不太完美的，一旦 MySQL 在分布式事務支持方面出問題，是需要去補救的。
在測試過程中，我們發現 MySQL 在分布式事務處理方面有如下兩大問題：
1、只有主庫存在懸掛事務
MySQL 主庫已接受到 xa commit 通知，xa commit 未完成前，kill -9 殺掉 MySQL 主庫，再啟動 MySQL 主庫，主庫出現懸掛事務，而從庫該分布式事務已提交。主庫此時需要執行 xa commit 語句，提交分布式事務，這個操作同步到從庫后，會導致從庫 SQL 應用進程報錯，提示找不到該分布式事務。
2、只有從庫出現懸掛事務
Cetus 向后端分片發送 xa prepare，分片 MySQL 主庫接收到 xa prepare，xa prepare 未完成前，kill -9 殺掉 MySQL 主庫，再啟動 MySQL 主庫，xa 事務已回滾，主庫未出現懸掛事務；從庫出現懸掛事務。這種情況下，從庫需要回滾 xa 事務，才能保證數據的一致性。
以上兩種情況，主庫的 xa 事務狀態，跟 binlog 記錄的事務狀態不一致。在 MySQL 官方文檔找到解釋，MySQL 異常關閉，有可能導致數據庫狀態和 binlog 不一致。這些 bug，在非正常關閉 MySQL 時才出現，正常關閉 MySQL 不會出現這個問題。如果出現 xa 事務懸掛，可以用 Cetus xa 懸掛處理工具自動處理。
tcp stream 改造
由于 MySQL 協議是有狀態的協議，Cetus 是純異步的，再加上 tcp stream，處理過程就變得異常復雜。我們采用的策略是讓線上運行禁止 tcp stream 功能的 Cetus，而流量測試環境使用 tcp stream 的 Cetus，這樣就很容易去發現 tcp stream 的很多問題。
網易樂得目前使用 Cetus 已經一年多了，線上沒有遇到大的問題，而在測試的時候遇到了原先 MySQL proxy 帶過來的一個問題，因為設置 max-open-files 過小導致 CPU 100%，也正因為這個問題，使我們堅決部署了 tcpcopy 流量測試環境。
展望
我們對 Cetus 的短期計劃是讓用戶大量用起來，并完成基于GTID tracking一致性讀的功能， 對MGR 的完善支持和擴容工具的完善。
長期計劃是在不斷成長中，將 Cetus 打造成類似 OneProxy 的高性能數據庫中間件，支持多進程、query cache、ssl與更好的安全過濾等，為MySQL保駕護航。
