Redis 和 Hazelcast – RadarGun 對二者的比較
自從2009年初始發布以來，Redis受到了巨大的歡迎并且成為擁有大型社區的部署數據存儲平臺之一。
雖然Radis有很令人難忘的特性，但是它也有一個嚴重的限制--它是為了單機模式設計的。如果用戶需要超過單機的能力，就需要使用專用分區系統。不過3.0.0版本發布了一種集群系統產品，可以從根本上簡化分布式Redis部署。
所有人都認可Radis很快，我們來看看Hazelcast和Redis的比較。這份報告是為了觀察Redis集群方案（v3.0.7）對比Hazelcast（v3.6.1）的表現, 特別是在重負荷的情況下。
為了確保我們在比較Hazelcaset和Redis時候擁有穩定的環境，我們選擇使用我們通常用于測試Hazelcast性能改進的室內測試實驗室。
實驗室配置
測試在由HP ProLiant DL380系列服務器構成的集群上進行。每一臺機器配置有雙socket Xeon E5-2687W v3@3.10Ghz， 每個CPU10核，超線程可用（一共有20個物理的，40個虛擬核），并且還有768G 2133Mhz的內存（24X32GB 模塊）。在操作系統方面，我們使用簡單的RHEL7安裝，這表示在測量中不會使用虛擬軟件。每臺機器使用一個40 GbE SolarFlare 網卡（Sloarflare SFN7142Q Dual Port 40 GbE)來做點對點的通信。
為了執行Redis 測試，我們決定小痾怒責Jedis做客戶端，因為它很流行（在github上有3481個星）并且對集群模式有非常好的支持度。
為了排除其他影響，我們決定雇傭Infinispan開發社區創建的第三方測量工具RadarGun。因為RadarGun不提供直接可用的Redis支持，我們需要自己集成。感興趣的人可以去github上獲取RadarGun fork和Redis插件。
我們需要什么
作為測試場景，我們想要基于客戶增長數和并發處理數據數來比較Hazelcast和Redis的表現。所有的測試都在測試環境的 4個節點集群上執行并觀察，4個基本測試場景需要被執行：
腳本 客戶端數 每個客戶端的進程數
1 1 1
2 4 8
3 4 32
4 4 64
正如上文所說，我們用以下版本來執行測試：
-
Hazelcast Version 3.6.1
-
Redis Version 3.0.7， Jedis 2.8.0
吞吐量
看一下吞吐量結果，Redis在少量客戶端和/或進程的情況下非常快，但是它在高并發負載下變得很慢。測量超過特定數量的線程會拖慢Redis內部結構的可擴展性。另一方面，Hazelcast在很小的負載情況下表現較差，但是在并發處理和高數量客戶端或線程開始被進入的時候，測量表現要遠高于Redis。
腳本 Hazelcast 結果(reqs/s) Redis 結果(reqs/s)
| 1 | 13,954 | 50,634 |
| 2 | 365,792 | 645,976 |
| 3 | 872,773 | 702,671 |
| 4 | 1,166,204 | 722,531 |
延遲性
根據結果，延遲性表現和并發性測試里有類似模式。Redis在低數據負載的時候響應比Hazelcast表現更好，而在數據負載和并發請求增加時則表現相反。在不常見的大環境（如我們在腳本4）我們可以看到Redis的平均響應時間劇烈的增長。Hazelcast響應時間雖然也隨著線程數增加而增長，但是這種增長要穩定得多，而且不像Redis表現的那樣是指數級。
| 腳本 | Hazelcast (響應時間 μs) | Redis (響應時間 μs) |
|---|---|---|
| 1 | 70,14 | 19,37 |
| 2 | 85,83 | 48,98 |
| 3 | 144,7 | 225,22 |
| 4 | 217,52 | 640,51 |
結論
盡管在基準測試中的變量來自于測試的方法，調整設置，相對來說是一種常見的模式。Redis 在低用戶數量和低資源爭用連接情況下是一個好的選擇，而這個霸主地位將會被更多的負載集群所打破。
從這個結果來說，大量的 Redis 用戶不希望看到這個。他們真的有低量的數據負載系統，還是他們有另一種更好的方式呢？我們推薦開發者和架構師在使用任何技術之前，應該盡職預言并充分測試自己的用例。
一定要下載完整的基準（ PDF 格式），并查看新的 Redis 為 Hazelcast 用戶對應的白皮書。
來源：http://www.oschina.net/translate/redis-vs-hazelcast-radargun-puts-them-to-a-challenge