測試環境

軟硬體環境

• 4個彼此相互獨立阿里rds例項：硬體配置相同，每個配置為：4核心、8GB記憶體、20GB磁碟、2000 IOPS，每個例項建立一個數據庫名稱為dbproxy
• 一箇中間件節點，硬體配置相同，配置為：8核心、8GB記憶體、20GB磁碟 中介軟體預設工作執行緒數：32
• 一個客戶端節點，硬體配置相同，配置為：4核心、8GB記憶體、20GB磁碟
  壓力測試工具：基於sysbench-0.5開源定製擴充套件版
• 一個表：表名為為sbtest1用hash演算法切分到4個rds資料庫中
• 測試方法：每次壓力測試時，分別在2個節點近乎同時各啟動一個sysbench客戶端。
• 中介軟體日誌級別設定：Mycat和Altas日誌級別設定為error
• Mycat jvm堆記憶體配置：4GB heap 1GB堆外記憶體
• 測試資料：每次執行insert操作向空表中寫入400w條記錄，select、update以此資料為基礎進行操作

資料庫Sharding

測試報告

Atlas與Mycat比較

一個sysbench客戶端，利用sysbench測試併發執行緒個數不同的情況下，分別執行insert、select，update三種操作，執行400w次。 測試連線Atlas和Mycat這兩種情況下的QPS（QPS越大，系統性能越好）、每條記錄請求響應耗時， 每組資料重複測試三次後取平均值，具體資料對比如下表所示：

所有下面測試Mycat執行操作過程中，為了獲得最佳效果效能和吞吐量，使用不同gc垃圾回收演算法進行基準壓力測試且都是jit熱程式碼(多次呼叫後再測試)，取出表格中最佳一組資料用於趨勢圖對比，經過實驗資料得出不同gc演算法對Mycat吞吐量影響很小，高階gc演算法有些吞吐量還降低了，影響較大因素為新生代堆大小配置。

統計QPS

(記錄數/sec、T95資料)

統計QPS趨勢圖

上表資料對應的Atlas和Mycat執行insert操作QPS對比趨勢圖

結合以上圖表和資料可以看出，當sysbench達到64執行緒數出現拐點，Mycat吞吐量上升比較平緩，Altas則近似直線上升，與Mycat相比Altas吞吐量高近40%

上表資料對應的Atlas和Mycat執行select操作QPS對比趨勢圖

結合以上圖表和資料可以看出，當sysbench達到64執行緒出現拐點，經過業務和場景分析得出中介軟體轉發資料為短生命週期，且多次測試驗證，當調大新生代堆大小會有一些改善。以128執行緒壓測為例，預設新生代堆大小為350MB時QPS是34351/sec，當新生代堆大小改為1500MB時QPS是35076/sec，改為2500MB則QPS是37376，吞吐量提升8%左右。總體上atlas吞吐量高於Mycat一倍以上

上表資料對應的Atlas和Mycat執行update操作QPS對比趨勢圖

結合以上圖表和資料可以看出，當sysbench達到64執行緒出現拐點，Mycat吞吐量遇到瓶頸上升不明顯，以128執行緒壓測為例，預設新生代堆大小為350MB時QPS是30377/sec，當新生代堆大小改為1500MB時QPS是31922/sec，改為2500MB則QPS是37970/sec，吞吐量提升25%左右

統計記錄請求響應耗時

(每條記錄請求響應耗時、單位毫秒、T95資料)：

統計記錄請求響應耗時趨勢圖

上表資料對應的Atlas和Mycat執行insert操作耗時對比趨勢圖

結合以上圖表和資料可以看出，Atlas和Mycat耗時相近，原因是瓶頸在於rds的IOPS限制，insert效能依賴於rds的IOPS能力，不能充分發揮Atlas能量

上表資料對應的Atlas和Mycat執行select操作耗時對比趨勢圖

結合以上圖表和資料可以看出，當sysbench達到64執行緒出現拐點，Mycat耗時陡然增加且增速比Atlas快

上表資料對應的Atlas和Mycat執行update操作耗時對比趨勢圖

結合以上圖表和資料可以看出，Atlas和Mycat耗時較為相近，原因是瓶頸在於rds的IOPS限制，update效能依賴於rds的IOPS能力，不能充分發揮Atlas能量

統計硬體資源消耗

一個sysbench客戶端，利用sysbench測試併發執行緒個數不同的情況下，分別執行400w次insert、select、update操作，中介軟體部署機器資源消耗(cpu消耗、load負載)，每組資料重複測試三次後取平均值，具體資料對比如下表所示：

統計硬體資源消耗趨勢圖

cpu消耗趨勢圖：

上表資料對應的Atlas和Mycat執行insert操作cpu消耗對比趨勢圖

結合以上圖表和資料可以看出，當sysbench達到64執行緒出現拐點，Mycat的cpu消耗更大，通過jstack + top分析java程序消耗cpu最多執行緒(開源工具)，原因為jvm內建執行緒消耗較大(gc等執行緒)

上表資料對應的Atlas和Mycat執行select操作cpu消耗對比趨勢圖

結合以上圖表和資料可以看出，雖然客戶端64執行緒壓測Atlas的吞吐量遠大於Mycat，但cpu消耗卻相近，Atlas相比Mycat消耗cpu少很多。

上表資料對應的Atlas和Mycat執行update操作cpu消耗對比趨勢圖

結合以上圖表和資料可以看出，當sysbench達到32執行緒出現拐點，Mycat的cpu消耗更大，通過jstack + top分析java程序消耗cpu最多執行緒(開源工具)，原因為jvm內建執行緒消耗較大(gc等執行緒)

load負載趨勢圖

上表資料對應的Atlas和Mycat執行insert操作load負載對比趨勢圖

結合以上圖表和資料以及QPS、cpu綜合分析可以看出，當sysbench達到32執行緒出現拐點，rds遇到IOPS瓶頸，Atlas很多執行緒處於wait狀態，效能無法充分發揮，隨著客戶端執行緒增加，所以導致Atlas待排程執行的任務較多

上表資料對應的Atlas和Mycat執行select操作load負載對比趨勢圖

同理select分析

上表資料對應的Atlas和Mycat執行update操作load負載對比趨勢圖

同理select分析

mycat jvm監控

當Mycat用預設gc演算法時，用java提供視覺化工具jvisualvm，監控了jvm heap、cpu等情況，綜合分析轉發資料生命週期短，堆記憶體佔用較少，很少fullgc，在400w資料測試中也就出現1~2次fullgc，mingc相對較多，cpu波峰值地方是sysbench初始化時候發生的。

insert

select

update

綜合分析

本次測試時中介軟體執行緒數為機器4倍，基本能充分發揮中介軟體效能。從執行SQL型別、記錄請求響應耗時、cpu消耗、cpu load負載等多個維度綜合評估Atlas和Mycat的效能及吞吐量，最大限度保證資料和效能儘量接近真實值。在同等軟硬體環境下，Atlas能充分利用硬體資源，極限吞吐量為Mycat一倍以上(個人覺得25~40%比較正常，但是測試select確實大一倍)，通過商業中介軟體OneProxy與Mycat對比，也可以作出印證，OneProxy測試報告地址。

OneProxy與Atlas一樣，用c語言開發

某Java類的Proxy，就是指的Mycat，因為平民軟體遷移了好幾個Mycat的客戶端

用sysbench測試的缺點就是模擬的表結構太簡單，而且每條記錄最大為200位元組，因此無法驗證gc對Mycat影響，400w資料操作過程中只有1~2次fullgc，如果真實環境中是不是資料量大些fullgc會頻繁些呢？

方案選型

關於中介軟體方案選型，要從多個維度考慮，例如效能和吞吐量、關鍵功能完善度，公司投入力量，單純從吞吐量考慮Atlas無疑勝出，如果自動化(運維化)、服務化、產品化角度考慮Mycat是必然選擇。不過Mycat優勢也明顯;

關於吞吐量和效能問題，Mycat雖然吞吐量較差，但線上一般都是通過中介軟體前面加一層lvs代理部署來做ha的，就是可以多部署Mycat例項彌補不足。

個人觀點：我沒有特定傾向，任意語言都可以，主要是結合公司業務場景、需求、功能要求、資源投入程度、緊急程度等綜合因素來做決定。如果這方面清晰了(方向和目標定了)，就容易選擇了。

中介軟體上線準備工作

Atlas和Mycat測試的版本都支援分庫但不分表，一個數據庫只能建立一張表，但不支援單庫多表，如果業務需要支援分庫分表，就要在一個數據庫內可以切分多張表情況。上線需要適配改造，1.通過DBA運維手段解決 2.修改中介軟體程式碼實現單庫分表功能，二者選其一。

註明：Atlas開源有2個版本，一個版本支援只支援單庫分表，另外一個版本支援跨庫分表不支援單庫多表