作者簡(jiǎn)介

藍(lán)寅，開(kāi)源分布式中間件DBLE項(xiàng)目負(fù)責(zé)人；持續(xù)專注于數(shù)據(jù)庫(kù)方面的技術(shù), 始終在一線從事開(kāi)發(fā)；對(duì)數(shù)據(jù)復(fù)制，讀寫分離，分庫(kù)分表的有深入的理解與實(shí)踐。

問(wèn)題起因：

用benchmarksql_for_mysql對(duì)原生MyCat-1.6.1和DBLE-2.17.07版做性能測(cè)試對(duì)比，發(fā)現(xiàn)DBLE性能只到原生版MyCat的70%左右。

問(wèn)題分析過(guò)程：

分析過(guò)程主要有以下內(nèi)容：包括現(xiàn)象，收集數(shù)據(jù)，分析猜測(cè)原因，驗(yàn)證猜測(cè)的方式來(lái)進(jìn)行。

開(kāi)源分布式中間件DBLE：  
社區(qū)官網(wǎng)，獲取DBLE快速入門指南及最新資訊： 
https://opensource.actionsky.com  
GitHub主頁(yè)，查看官方文檔： 
https://github.com/actiontech...  
社區(qū)技術(shù)交流群，迅速獲取官方支持：  
QQ群：669663113

**1.分析瓶頸

1.1 先對(duì)兩者進(jìn)行一個(gè)CPU占用的堆棧分析**

通過(guò)對(duì)CPU火焰圖的比較，發(fā)現(xiàn)DBLE用在純排序上的CPU占用在15%以上，而MyCat在排序上沒(méi)有看到明顯的CPU占用。（ 復(fù)盤時(shí)的思考：這里有明顯的可疑之處，應(yīng)當(dāng)及早觀察兩者是否公平）

1.2 首先猜測(cè)可能的原因

a.由于MyCat對(duì)以下這條用例實(shí)現(xiàn)有bug：具體方式是直接原句下發(fā)SQL到節(jié)點(diǎn)，收到各個(gè)節(jié)點(diǎn)的結(jié)果后直接做加法；而DBLE則是改寫為select distinct s_i_id 收集全部結(jié)果集，然后在中間件做去重和統(tǒng)計(jì)的工作。所以兩者在這個(gè)case上的對(duì)比是不公平的。

b.排序本身算法選擇的問(wèn)題

1.3 對(duì)猜測(cè)原因的驗(yàn)證

a.去除有bug的case，并未看到性能有提升，而且考慮這條用例在所有用例出現(xiàn)的概率只有4%，涉及到的數(shù)據(jù)也不多，所以應(yīng)該不是性能問(wèn)題的主因。

b.去除有排序的case，看到兩者性能接近，確定是排序的問(wèn)題。

2.猜測(cè)原因

2.1 猜測(cè)一：源碼實(shí)現(xiàn)原因

2.1.1 猜測(cè)描述

梳理DBLE源碼排序邏輯的實(shí)現(xiàn)細(xì)節(jié)，是多路歸并的排序，理論上是最優(yōu)選擇。

實(shí)際上具體的實(shí)現(xiàn)上有可優(yōu)化的空間，如下圖， N個(gè)數(shù)的K路排序的初始化值理論最優(yōu)復(fù)雜度是O(N),而這里變成了O（NlogK2) 。

2.1.2 驗(yàn)證猜測(cè)

為了快速將排序的因素排除，將cmp函數(shù)直接返回1再次做測(cè)試。結(jié)果提升了10%的性能，所以雖然cmp是有性能問(wèn)題，但導(dǎo)致性能如此大還有其他原因。（復(fù)盤：新版本已優(yōu)化此處10%的性能差異）

2.2 猜測(cè)二：回到排序SQL

查看B-SQL源碼，有3個(gè)排序SQL，其中有2個(gè)排序SQL的排序列不在select 項(xiàng)中，這本來(lái)應(yīng)該引發(fā)MyCat的bug的，但我們?cè)诜祷丶妥グ卸紱](méi)有發(fā)現(xiàn)。再仔細(xì)閱讀源碼，原來(lái)B-SQL通過(guò)hard code的方式使得壓力永遠(yuǎn)跑不到這兩個(gè)代碼路徑上，這樣我們又排除了2個(gè)干擾因素，問(wèn)題集中到剩下的那個(gè)排序上了。

將排序除去，64數(shù)據(jù)量，64并發(fā)，DBLE的性能是MyCat的96%。

證明確實(shí)和排序有關(guān)。

3.分析多并發(fā)壓力排序性能的原因

3.1 猜測(cè)排序算法在特殊場(chǎng)景下的適用性

3.1.1 猜測(cè)描述

由于MyCat排序采用的是timsort， 時(shí)間復(fù)雜度的可能最優(yōu)是O(n)。
而DBLE的多路歸并排序在B-SQL這個(gè)場(chǎng)景下時(shí)間復(fù)雜度最差情況是O（n*(k-1)).
猜測(cè)timSort排序在B-SQL多并發(fā)場(chǎng)景下可能會(huì)優(yōu)于多路歸并。

3.1.2 驗(yàn)證猜測(cè)

用B-SQL壓測(cè)并統(tǒng)計(jì)函數(shù)調(diào)用次數(shù)。

結(jié)論：

在B-SQL場(chǎng)景下:

兩者平均每個(gè)排序調(diào)用的cmp函數(shù)的次數(shù)并沒(méi)有發(fā)生明顯的異化

每個(gè)排序cmp次數(shù)雖然沒(méi)有大的差異，但總的調(diào)用次數(shù)卻相差很大,DBLE大約是MyCat的5倍

4. 分析DBLE排序時(shí)cmp函數(shù)次數(shù)調(diào)用多的原因

問(wèn)題集中在了為什么DBLE會(huì)有更多次的比較函數(shù)調(diào)用。

4.1 驗(yàn)證壓力下發(fā)的SQL是否與cmp函數(shù)調(diào)用相符是否下發(fā)的SQL就不公平

4.1.1收集數(shù)據(jù)

用抓包的方式分別抓取B-SQL發(fā)給MyCat和DBLE的包，結(jié)果發(fā)現(xiàn) DBLE的所有SQL中排序這條SQL的發(fā)生次數(shù)是MyCat的10倍左右。

再次用yourkit查看調(diào)用次數(shù)和CPU分布驗(yàn)證，發(fā)現(xiàn)調(diào)用次數(shù)確實(shí)符合抓包的結(jié)論，CPU分布也是DBLE分了大量的時(shí)間用于排序，而MyCat對(duì)排序的分配幾乎可以忽略。這也與最一開(kāi)始的火焰圖結(jié)論一樣。

用wireshark分析DBLE抓包結(jié)果，發(fā)現(xiàn)某些連接執(zhí)行一段時(shí)間之后大量的重復(fù)出現(xiàn)排序+delete的query請(qǐng)求直到壓力結(jié)束，舉例如下圖。

4.1.2 分析原因

分析B-SQL源碼這里發(fā)現(xiàn)只有delete的數(shù)據(jù)為0才會(huì)引發(fā)死循環(huán)。

4.1.3 驗(yàn)證測(cè)試

在引發(fā)死循環(huán)的原因找到之前，先修改代碼驗(yàn)證測(cè)試。無(wú)論result是否是0都設(shè)置newOrderRemoved=true使得B-SQL跳出死循環(huán)。

驗(yàn)證測(cè)試，DBLE性能終于符合預(yù)期，變?yōu)镸yCat的105%。

至此，B-SQL有排序引發(fā)DBLE性能下降的原因找到了，某種場(chǎng)景下B-SQL對(duì)DBLE執(zhí)行delete，影響行數(shù)為0，導(dǎo)致此時(shí)會(huì)有死循環(huán)，發(fā)送了大量排序請(qǐng)求，嚴(yán)重降低了DBLE性能，并且并發(fā)壓力越大越容易出現(xiàn)，但也有一定幾率不會(huì)觸發(fā)。

5.分析哪種場(chǎng)景下delete行數(shù)為0

5.1隔離級(jí)別測(cè)試

因?yàn)閷?duì)隔離級(jí)別并不熟悉，花了很長(zhǎng)時(shí)間才想到原因，在MySQL上做了一個(gè)實(shí)驗(yàn)：

也就是說(shuō)，在并發(fā)情況下確實(shí)有可能有死循環(huán)出現(xiàn)。

5.2 分析為什么只有在DBLE上有這個(gè)問(wèn)題而在MyCat上沒(méi)有這個(gè)問(wèn)題

原因是DBLE和MyCat的默認(rèn)隔離級(jí)別都是REPEATED_READ，但MyCat的實(shí)現(xiàn)有bug，除非客戶端顯式使用set語(yǔ)句，MyCat后端連接使用的隔離級(jí)別都是下屬結(jié)點(diǎn)上的默認(rèn)隔離級(jí)別；而DBLE會(huì)在獲取后端連接后同步上下文，使得session級(jí)別的隔離級(jí)別和DBLE配置相同。而后端的四個(gè)結(jié)點(diǎn)中除了1臺(tái)是REPEATED_READ，其他三個(gè)結(jié)點(diǎn)都是READ_COMMITTED。這樣同樣的并發(fā)條件，DBLE100%會(huì)觸發(fā)，而MyCat只有25%的概率觸發(fā)。

5.3 驗(yàn)證測(cè)試

將DBLE上的配置添加2（默認(rèn)是3）與默認(rèn)做對(duì)比:

性能比是1:0.75.符合期望，性能原因全部找到。

6. 吐槽

最后吐槽一下B-SQL，找了官方的B-SQL4.1版和5.0版，4.1版并未對(duì)此情況做任何改進(jìn)，仍有可能陷入死循環(huán)影響測(cè)試。

而5.0的對(duì)應(yīng)代碼處有這么一段注釋，不知道PGSQL是否這里真的會(huì)觸發(fā)異常，但MySQL并不會(huì)觸發(fā)異常，仍有可能陷入死循環(huán)。

7.性能原因回顧

1.cmp函數(shù)時(shí)候初始化值的問(wèn)題，影響部分性能，非主要性能瓶頸，新版本已改進(jìn)。
2.同時(shí)觸發(fā)了MyCat和B-SQL的兩個(gè)bug，導(dǎo)致測(cè)試的性能數(shù)據(jù)負(fù)負(fù)得正；

Mycat bug：配置的隔離級(jí)別不生效問(wèn)題

B-SQL bug：RR隔離級(jí)別下，delete死循環(huán)問(wèn)題

需要將MySQL結(jié)點(diǎn)都改為READ_COMMITED,再將配置改為2，避開(kāi)上述的bug。

8.收獲

1.測(cè)試環(huán)境的搭建無(wú)論是配置參數(shù)還是各個(gè)節(jié)點(diǎn)的狀態(tài)都要同步，保證公平。
2.性能分析工具的使用。
3.性能測(cè)試可能一次的結(jié)果具有偶然性，需要多次驗(yàn)證。
4.當(dāng)有矛盾的結(jié)論時(shí)候，可能就快接近問(wèn)題的真相了，需要持續(xù)關(guān)注。

開(kāi)源分布式中間件DBLE

社區(qū)官網(wǎng)： https://opensource.actionsky....

GitHub主頁(yè)： https://github.com/actiontech...

技術(shù)交流群：669663113

開(kāi)源數(shù)據(jù)傳輸中間件DTLE

社區(qū)官網(wǎng)： https://opensource.actionsky....

GitHub主頁(yè)： https://github.com/actiontech...

技術(shù)交流群：852990221