<p>自从2009年初始发布以来，Redis受到了巨大的欢迎并且成为拥有大型社区的部署数据存储平台之一。</p>    <p>虽然Radis有很令人难忘的特性，但是它也有一个严重的限制--它是为了单机模式设计的。如果用户需要超过单机的能力，就需要使用专用分区系统。不过3.0.0版本发布了一种集群系统产品，可以从根本上简化分布式Redis部署。</p>    <p>所有人都认可Radis很快，我们来看看Hazelcast和Redis的比较。这份报告是为了观察Redis集群方案（v3.0.7）对比Hazelcast（v3.6.1）的表现, 特别是在重负荷的情况下。</p>    <p>为了确保我们在比较Hazelcaset和Redis时候拥有稳定的环境，我们选择使用我们通常用于测试Hazelcast性能改进的室内测试实验室。</p>    <p><strong>实验室配置</strong></p>    <p>测试在由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)来做点对点的通信。</p>    <p>为了执行Redis 测试，我们决定小痾怒责Jedis做客户端，因为它很流行（在github上有3481个星）并且对集群模式有非常好的支持度。</p>    <p>为了排除其他影响，我们决定雇佣Infinispan开发社区创建的第三方测量工具RadarGun。因为RadarGun不提供直接可用的Redis支持，我们需要自己集成。感兴趣的人可以去github上获取RadarGun fork和Redis插件。</p>    <h2><strong>我们需要什么</strong></h2>    <p>作为测试场景，我们想要基于客户增长数和并发处理数据数来比较Hazelcast和Redis的表现。所有的测试都在测试环境的 4个节点集群上执行并观察，4个基本测试场景需要被执行：</p>    <p><strong>脚本  客户端数 每个客户端的进程数</strong></p>    <p>1        1            1</p>    <p>2        4            8</p>    <p>3        4            32</p>    <p>4        4            64</p>    <p>正如上文所说，我们用以下版本来执行测试：</p>    <ul>     <li> <p>Hazelcast Version 3.6.1</p> </li>     <li> <p>Redis Version 3.0.7， Jedis 2.8.0</p> </li>    </ul>    <h2><strong>吞吐量</strong></h2>    <p>看一下吞吐量结果，Redis在少量客户端和/或进程的情况下非常快，但是它在高并发负载下变得很慢。测量超过特定数量的线程会拖慢Redis内部结构的可扩展性。另一方面，Hazelcast在很小的负载情况下表现较差，但是在并发处理和高数量客户端或线程开始被进入的时候，测量表现要远高于Redis。</p>    <p><img src="https://simg.open-open.com/show/a5517e917c72b6662954dbffc5a7c3ee.png" alt="Redis 和 Hazelcast – RadarGun 对二者的比较" width="1280" height="730"></p>    <p><strong>脚本  Hazelcast 结果(reqs/s)     </strong><strong>Redis 结果(reqs/s)</strong></p>    <table>     <tbody>      <tr>       <td>1         </td>       <td>13,954</td>       <td> 50,634</td>      </tr>      <tr>       <td>2</td>       <td>365,792                    </td>       <td>645,976</td>      </tr>      <tr>       <td>3</td>       <td>872,773</td>       <td>702,671</td>      </tr>      <tr>       <td>4</td>       <td>1,166,204</td>       <td>722,531</td>      </tr>     </tbody>    </table>    <p> </p>    <h2><strong>延迟性</strong></h2>    <p>根据结果，延迟性表现和并发性测试里有类似模式。Redis在低数据负载的时候响应比Hazelcast表现更好，而在数据负载和并发请求增加时则表现相反。在不常见的大环境（如我们在脚本4）我们可以看到Redis的平均响应时间剧烈的增长。Hazelcast响应时间虽然也随着线程数增加而增长，但是这种增长要稳定得多，而且不像Redis表现的那样是指数级。</p>    <p><img src="https://simg.open-open.com/show/0d974511c9e434a1dcf5dad138704fe7.png" alt="Redis 和 Hazelcast – RadarGun 对二者的比较" width="1280" height="728"></p>    <table>     <tbody>      <tr>       <th>                脚本</th>       <th>                Hazelcast (响应时间 μs)</th>       <th>                  Redis (响应时间 μs)</th>      </tr>     </tbody>     <tbody>      <tr>       <td>                1</td>       <td>                  70,14  </td>       <td>                    19,37</td>      </tr>      <tr>       <td>                2</td>       <td>                  85,83</td>       <td>                    48,98</td>      </tr>      <tr>       <td>                3</td>       <td>                  144,7</td>       <td>                    225,22</td>      </tr>      <tr>       <td>                4</td>       <td>                  217,52  </td>       <td>                    640,51</td>      </tr>     </tbody>    </table>    <h2>结论</h2>    <p>尽管在基准测试中的变量来自于测试的方法，调整设置，相对来说是一种常见的模式。Redis 在低用户数量和低资源争用连接情况下是一个好的选择，而这个霸主地位将会被更多的负载集群所打破。</p>    <p>从这个结果来说，大量的 Redis 用户不希望看到这个。他们真的有低量的数据负载系统，还是他们有另一种更好的方式呢？我们推荐开发者和架构师在使用任何技术之前，应该尽职预言并充分测试自己的用例。</p>    <p>一定要<a href="/misc/goto?guid=4959671234069910829" rel="nofollow">下载完整的基准（ PDF 格式）</a>，并查看新的 <a href="/misc/goto?guid=4959671234149934493" rel="nofollow">Redis 为 Hazelcast 用户对应的白皮书</a>。</p>    <p>来源：http://www.oschina.net/translate/redis-vs-hazelcast-radargun-puts-them-to-a-challenge</p>