柳皓亮,王麗,周陽辰
(中國科學(xué)院電子學(xué)研究所蘇州研究院 存儲(chǔ)計(jì)算組， 江蘇 蘇州 215123)
摘要：Redis是一個(gè)非關(guān)系型數(shù)據(jù)庫，屬于內(nèi)存級(jí)數(shù)據(jù)庫。但是由于數(shù)據(jù)量的不斷增大，單機(jī)的Redis物理內(nèi)存遠(yuǎn)遠(yuǎn)無法滿足大數(shù)據(jù)的需要，因此需要搭建分布式的Redis，可以動(dòng)態(tài)擴(kuò)展內(nèi)存，彌補(bǔ)單機(jī)Redis物理內(nèi)存不夠的缺點(diǎn)。本次測試旨在對(duì)Redis各方面性能有深入的了解，為今后的工作打好基礎(chǔ)。本次實(shí)驗(yàn)的目的主要是搭建Redis Cluster和TwemProxy Redis兩種集群，分別對(duì)其進(jìn)行性能測試，測試出集群性能的拐點(diǎn)，找出性能的瓶頸有哪些，并對(duì)兩套集群進(jìn)行比較，以便于在不同業(yè)務(wù)場景下?lián)駜?yōu)選擇。
關(guān)鍵詞：Redis Cluster；TwemProxy Redis；性能測試
1存儲(chǔ)測試分析
本次存儲(chǔ)測試是用Java程序調(diào)用Jedis提供的API向集群里面灌入數(shù)據(jù)。首先研究灌入少量數(shù)據(jù)后兩種集群的數(shù)據(jù)分布在哪些節(jié)點(diǎn)上，然后研究灌入大量數(shù)據(jù)后兩種集群的落盤情況。
1.1Redis Cluster
（1）少量數(shù)據(jù)儲(chǔ)存分析
用程序向某一個(gè)節(jié)點(diǎn)灌入30條數(shù)據(jù)，結(jié)果發(fā)現(xiàn)每個(gè)節(jié)點(diǎn)擁有部分?jǐn)?shù)據(jù)，數(shù)據(jù)存儲(chǔ)得很分散。由此可知，數(shù)據(jù)落盤時(shí)把一份數(shù)據(jù)分成多份存儲(chǔ)在不同的Redis節(jié)點(diǎn)上，進(jìn)行分片存儲(chǔ)，通過調(diào)研得知這種分配方式是通過sharding算法分配［1］的。
?。?）大量數(shù)據(jù)存儲(chǔ)分析
首先查看單節(jié)點(diǎn)未插入數(shù)據(jù)前的rdb大小為18 B；然后，用Java程序插入10萬條數(shù)據(jù)，查看rdb大小為1 289 892 B，然后改用Java程序向Redis Cluster集群中灌入10萬條數(shù)據(jù)，查看每個(gè)節(jié)點(diǎn)rdb文件大小分別為214 912 B、216 586 B、215 939 B、214 145 B和213 757 B。由此可見，單機(jī)的rdb大小約等于每個(gè)Redis節(jié)點(diǎn)rdb大小之和，并且每個(gè)節(jié)點(diǎn)rdb大小相對(duì)均衡。綜上所述，這種落盤方式把一份數(shù)據(jù)平均分配到每一個(gè)節(jié)點(diǎn)上，也就是說每一個(gè)節(jié)點(diǎn)的rdb文件共同組成一份完整的數(shù)據(jù)。
1.2TwemProxy Redis
?。?）少量數(shù)據(jù)存儲(chǔ)分析
向集群中插入20條key為0~19的數(shù)據(jù)，查看數(shù)據(jù)在各個(gè)Redis節(jié)點(diǎn)分布情況，結(jié)果發(fā)現(xiàn)某個(gè)節(jié)點(diǎn)存儲(chǔ)第0~9的數(shù)據(jù)，另一個(gè)節(jié)點(diǎn)存儲(chǔ)11~19的數(shù)據(jù)，最后一個(gè)節(jié)點(diǎn)沒有存儲(chǔ)數(shù)據(jù)。經(jīng)過多次相同參數(shù)測試，每次落盤結(jié)果相同，由此可見TwemProxy［2］根據(jù)相應(yīng)算法將數(shù)據(jù)落盤到各個(gè)節(jié)點(diǎn)中，并且分配算法是對(duì)一段連續(xù)的數(shù)據(jù)進(jìn)行落盤，而不是對(duì)每一條數(shù)據(jù)進(jìn)行選擇存入到哪個(gè)節(jié)點(diǎn)中的操作，這樣可以減少路由開銷。
?。?）大量數(shù)據(jù)存儲(chǔ)分析
首先查看單機(jī)Redis節(jié)點(diǎn)未插入數(shù)據(jù)前的rdb文件大小為84 B； 然后插入10萬條數(shù)據(jù)，查看rdb文件大小為1.6 MB；接著改用Java程序向TwemProxy Redis［2］集群中灌入10萬條數(shù)據(jù)，查看各各節(jié)點(diǎn)rdb文件大小分別為0.49 MB、0.62 MB和0.51 MB。由此可見，單機(jī)的rdb大小約等于每個(gè)Redis節(jié)點(diǎn)rdb大小之和，并且每個(gè)節(jié)點(diǎn)rdb大小相對(duì)均衡。由此可見，這種落盤方式把一份數(shù)據(jù)平均分配到每一個(gè)節(jié)點(diǎn)上，也就是說每一個(gè)節(jié)點(diǎn)的rdb文件共同組成一份完整的數(shù)據(jù)。
2使用Java代碼測試吞吐率
主要從3個(gè)方面進(jìn)行測試，當(dāng)value類型分別是String類型、list類型和map類型時(shí)，統(tǒng)計(jì)吞吐率的走勢，找出拐點(diǎn)，并分析原因［2］。
2.1Redis Cluster
（1）String插入測試——吞吐率隨value大小變化情況：當(dāng)吞吐量一定時(shí)并且插入的是String類型數(shù)據(jù)時(shí)，如果value值在1 KB以內(nèi)時(shí)，吞吐率基本保持不變；如果 value值大于1 KB，吞吐率隨value增大而減小。當(dāng)value值達(dá)到10 KB且請(qǐng)求總量為1萬條時(shí)，共100 MB的數(shù)據(jù)，內(nèi)存遠(yuǎn)遠(yuǎn)沒有被打滿，即此時(shí)內(nèi)存的使用率仍比較低，所以此時(shí)Redis數(shù)據(jù)存儲(chǔ)瓶頸［3］并不是內(nèi)存。同時(shí)監(jiān)控了網(wǎng)卡和IO，發(fā)現(xiàn)均處于正常水平，所以也不是這兩方面的原因。所以可以推出，此時(shí)吞吐率下降是由于Redis本身不能夠承受過大的value值。
?。?）String插入測試——吞吐率隨吞吐量變化情況：當(dāng)value大小一定時(shí)，吞吐量的增大對(duì)吞吐率沒有影響。
（3）String獲取測試——吞吐率隨value大小變化關(guān)系：結(jié)果與（2）相同。
（4）List插入測試——吞吐率隨List大小變化情況：當(dāng)List元素大小和吞吐量一定時(shí)，吞吐率隨list的size增大而減小，size從10增加大100時(shí)吞吐率下降了一半。由此可見，Redis Cluster對(duì)List的支持效果并不好，性能有待提升，不建議在以后的項(xiàng)目階段用Redis Cluster存儲(chǔ)List。
?。?）List插入測試——吞吐率隨List元素字節(jié)大小變化情況： List的元素字節(jié)大小變化對(duì)吞吐率沒有影響。
?。?）List插入測試——吞吐率隨吞吐量大小的變化關(guān)系：吞吐率與吞吐量無關(guān)。
?。?）Map插入測試——吞吐率隨Map size大小變化關(guān)系：當(dāng)吞吐量和元素字節(jié)一定時(shí)，吞吐率隨Map的size增大而減小。
?。?）Map插入測試——吞吐率隨Map的value大小變化情況：當(dāng)吞吐量和Map的size一定時(shí)，吞吐率隨Map元素字節(jié)增大而減小。
2.2TwemProxy Redis
TwemProxy Redis［2］采用單條讀寫和批量讀寫兩種方式進(jìn)行壓力測試，測試結(jié)果如下。
?。?）String單條插入測試——吞吐率隨value大小變化情況：value值在1 KB以內(nèi)且總請(qǐng)求量為1萬時(shí)吞吐率基本保持不變；當(dāng)value值大于1 KB時(shí), 吞吐率隨value增大而減小，單條TwemProxy Redis的插入吞吐率明顯比Redis Cluster低。
?。?）String批量插入測試——吞吐率隨value大小變化情況：當(dāng)吞吐量一定時(shí)，value值小于100 B時(shí)，吞吐率隨value增大而增大；當(dāng)value值大于100 B時(shí)，吞吐率隨value增大而減小。由此可見，批量插入存在極值點(diǎn)，此外批量插入的吞吐率遠(yuǎn)遠(yuǎn)高于TwemProxy Redis和Redis Cluster的單條插入。
?。?）String單條獲取測試——吞吐率隨value大小變化關(guān)系：測試結(jié)果與（1）的結(jié)果相同。由此可見，TwemProxy Redis的單條讀寫效率一致。
（4）String批量獲取測試——吞吐率隨value大小變化關(guān)系：結(jié)果與（2）相同。
（5）String單條插入測試——吞吐率隨吞吐量的變化關(guān)系：吞吐率與吞吐量無關(guān)，TwemProxy Redis吞吐率只有Redis Cluster的一半，明顯吞吐率很低。
?。?）String批量插入測試——吞吐率隨吞吐量的變化關(guān)系：隨著吞吐量的增加，吞吐率也在增加。但在測試時(shí)將請(qǐng)求量給到10萬條后，程序宕掉并且集群服務(wù)停止工作，說明pipeline批量打包的數(shù)據(jù)量有限，即性能是有限的。但是可以通過打包多次解決這個(gè)問題，批量插入的吞吐率明顯高于TwemProxy Cluster和Redis Cluster的單條插入吞吐率。
（7）List和Map類型的單條插入測試吞吐率變化：吞吐率變化與Redis Cluster的相同，但是吞吐率低于Redis Cluster。
(8)List和Map類型的單條插入測試吞吐率變化：吞吐率變化與Redis Cluster的相同，但是吞吐率高于TwemProxy Cluster和Redis Cluster的單條吞吐率。
3結(jié)論
?。?） TwemProxy Redis的批量讀寫吞吐率遠(yuǎn)遠(yuǎn)高于Redis Cluster單條的吞吐率，Redis Cluster單條讀寫的吞吐率略高于TwemPrxoy Redis單條吞吐率。
（2） Redis Cluster和TwemPrxoy Redis對(duì)List和Map集合的吞吐率很低，不建議存儲(chǔ)這兩種類型的數(shù)據(jù)。
（3）當(dāng)需要進(jìn)行TwemProxy Redis批量操作時(shí)，需要通過程序保證一次批量讀寫的數(shù)據(jù)量不宜過大，否則底層服務(wù)會(huì)宕掉。
參考文獻(xiàn)
?。?］ 王敏，陳亞光.數(shù)據(jù)庫系統(tǒng)輔助測試工具［J］.微型機(jī)與應(yīng)用，2013，32（3）：1315，18.
［2］ 夏文忠,鄒雯奇.基于X86平臺(tái)的高性能數(shù)據(jù)庫集群技術(shù)的研究［J］.微型機(jī)與應(yīng)用,2015,34(1):3639,46.
?。?］ 張蕾,侯瑞春,丁香乾，等.會(huì)話保持機(jī)制在集群系統(tǒng)中的應(yīng)用研究［J］.微型機(jī)與應(yīng)用,2015,34(9):3234,50.