柳皓亮,王麗,周陽辰

　　(中國科學院電子學研究所蘇州研究院 存儲計算組， 江蘇 蘇州 215123)

　　摘要：Redis是一個非關系型數據庫，屬于內存級數據庫。但是由于數據量的不斷增大，單機的Redis物理內存遠遠無法滿足大數據的需要，因此需要搭建分布式的Redis，可以動態擴展內存，彌補單機Redis物理內存不夠的缺點。本次測試旨在對Redis各方面性能有深入的了解，為今后的工作打好基礎。本次實驗的目的主要是搭建Redis Cluster和TwemProxy Redis兩種集群，分別對其進行性能測試，測試出集群性能的拐點，找出性能的瓶頸有哪些，并對兩套集群進行比較，以便于在不同業務場景下擇優選擇。

　　關鍵詞：Redis Cluster；TwemProxy Redis；性能測試

1存儲測試分析

　　本次存儲測試是用Java程序調用Jedis提供的API向集群里面灌入數據。首先研究灌入少量數據后兩種集群的數據分布在哪些節點上，然后研究灌入大量數據后兩種集群的落盤情況。

　　1.1Redis Cluster

　　（1）少量數據儲存分析

　　用程序向某一個節點灌入30條數據，結果發現每個節點擁有部分數據，數據存儲得很分散。由此可知，數據落盤時把一份數據分成多份存儲在不同的Redis節點上，進行分片存儲，通過調研得知這種分配方式是通過sharding算法分配［1］的。

　　（2）大量數據存儲分析

　　首先查看單節點未插入數據前的rdb大小為18 B；然后，用Java程序插入10萬條數據，查看rdb大小為1 289 892 B，然后改用Java程序向Redis Cluster集群中灌入10萬條數據，查看每個節點rdb文件大小分別為214 912 B、216 586 B、215 939 B、214 145 B和213 757 B。由此可見，單機的rdb大小約等于每個Redis節點rdb大小之和，并且每個節點rdb大小相對均衡。綜上所述，這種落盤方式把一份數據平均分配到每一個節點上，也就是說每一個節點的rdb文件共同組成一份完整的數據。

　　1.2TwemProxy Redis

　　（1）少量數據存儲分析

　　向集群中插入20條key為0~19的數據，查看數據在各個Redis節點分布情況，結果發現某個節點存儲第0~9的數據，另一個節點存儲11~19的數據，最后一個節點沒有存儲數據。經過多次相同參數測試，每次落盤結果相同，由此可見TwemProxy［2］根據相應算法將數據落盤到各個節點中，并且分配算法是對一段連續的數據進行落盤，而不是對每一條數據進行選擇存入到哪個節點中的操作，這樣可以減少路由開銷。

　　（2）大量數據存儲分析

　　首先查看單機Redis節點未插入數據前的rdb文件大小為84 B； 然后插入10萬條數據，查看rdb文件大小為1.6 MB；接著改用Java程序向TwemProxy Redis［2］集群中灌入10萬條數據，查看各各節點rdb文件大小分別為0.49 MB、0.62 MB和0.51 MB。由此可見，單機的rdb大小約等于每個Redis節點rdb大小之和，并且每個節點rdb大小相對均衡。由此可見，這種落盤方式把一份數據平均分配到每一個節點上，也就是說每一個節點的rdb文件共同組成一份完整的數據。

2使用Java代碼測試吞吐率

　　主要從3個方面進行測試，當value類型分別是String類型、list類型和map類型時，統計吞吐率的走勢，找出拐點，并分析原因［2］。

　　2.1Redis Cluster

　　（1）String插入測試——吞吐率隨value大小變化情況：當吞吐量一定時并且插入的是String類型數據時，如果value值在1 KB以內時，吞吐率基本保持不變；如果 value值大于1 KB，吞吐率隨value增大而減小。當value值達到10 KB且請求總量為1萬條時，共100 MB的數據，內存遠遠沒有被打滿，即此時內存的使用率仍比較低，所以此時Redis數據存儲瓶頸［3］并不是內存。同時監控了網卡和IO，發現均處于正常水平，所以也不是這兩方面的原因。所以可以推出，此時吞吐率下降是由于Redis本身不能夠承受過大的value值。

　　（2）String插入測試——吞吐率隨吞吐量變化情況：當value大小一定時，吞吐量的增大對吞吐率沒有影響。

　　（3）String獲取測試——吞吐率隨value大小變化關系：結果與（2）相同。

　　（4）List插入測試——吞吐率隨List大小變化情況：當List元素大小和吞吐量一定時，吞吐率隨list的size增大而減小，size從10增加大100時吞吐率下降了一半。由此可見，Redis Cluster對List的支持效果并不好，性能有待提升，不建議在以后的項目階段用Redis Cluster存儲List。

　　（5）List插入測試——吞吐率隨List元素字節大小變化情況： List的元素字節大小變化對吞吐率沒有影響。

　　（6）List插入測試——吞吐率隨吞吐量大小的變化關系：吞吐率與吞吐量無關。

　　（7）Map插入測試——吞吐率隨Map size大小變化關系：當吞吐量和元素字節一定時，吞吐率隨Map的size增大而減小。

　　（8）Map插入測試——吞吐率隨Map的value大小變化情況：當吞吐量和Map的size一定時，吞吐率隨Map元素字節增大而減小。

　　2.2TwemProxy Redis

　　TwemProxy Redis［2］采用單條讀寫和批量讀寫兩種方式進行壓力測試，測試結果如下。

　　（1）String單條插入測試——吞吐率隨value大小變化情況：value值在1 KB以內且總請求量為1萬時吞吐率基本保持不變；當value值大于1 KB時, 吞吐率隨value增大而減小，單條TwemProxy Redis的插入吞吐率明顯比Redis Cluster低。

　　（2）String批量插入測試——吞吐率隨value大小變化情況：當吞吐量一定時，value值小于100 B時，吞吐率隨value增大而增大；當value值大于100 B時，吞吐率隨value增大而減小。由此可見，批量插入存在極值點，此外批量插入的吞吐率遠遠高于TwemProxy Redis和Redis Cluster的單條插入。

　　（3）String單條獲取測試——吞吐率隨value大小變化關系：測試結果與（1）的結果相同。由此可見，TwemProxy Redis的單條讀寫效率一致。

　　（4）String批量獲取測試——吞吐率隨value大小變化關系：結果與（2）相同。

　　（5）String單條插入測試——吞吐率隨吞吐量的變化關系：吞吐率與吞吐量無關，TwemProxy Redis吞吐率只有Redis Cluster的一半，明顯吞吐率很低。

　　（6）String批量插入測試——吞吐率隨吞吐量的變化關系：隨著吞吐量的增加，吞吐率也在增加。但在測試時將請求量給到10萬條后，程序宕掉并且集群服務停止工作，說明pipeline批量打包的數據量有限，即性能是有限的。但是可以通過打包多次解決這個問題，批量插入的吞吐率明顯高于TwemProxy Cluster和Redis Cluster的單條插入吞吐率。

　　（7）List和Map類型的單條插入測試吞吐率變化：吞吐率變化與Redis Cluster的相同，但是吞吐率低于Redis Cluster。

　　(8)List和Map類型的單條插入測試吞吐率變化：吞吐率變化與Redis Cluster的相同，但是吞吐率高于TwemProxy Cluster和Redis Cluster的單條吞吐率。

3結論

　　（1） TwemProxy Redis的批量讀寫吞吐率遠遠高于Redis Cluster單條的吞吐率，Redis Cluster單條讀寫的吞吐率略高于TwemPrxoy Redis單條吞吐率。

　　（2） Redis Cluster和TwemPrxoy Redis對List和Map集合的吞吐率很低，不建議存儲這兩種類型的數據。

　　（3）當需要進行TwemProxy Redis批量操作時，需要通過程序保證一次批量讀寫的數據量不宜過大，否則底層服務會宕掉。

參考文獻

　　［1］ 王敏，陳亞光.數據庫系統輔助測試工具［J］.微型機與應用，2013，32（3）：1315，18.

　　［2］ 夏文忠,鄒雯奇.基于X86平臺的高性能數據庫集群技術的研究［J］.微型機與應用,2015,34(1):3639,46.

　　［3］ 張蕾,侯瑞春,丁香乾，等.會話保持機制在集群系統中的應用研究［J］.微型機與應用,2015,34(9):3234,50.