UDN-企业互联网技术人气社区

板块导航

浏览  : 1474
回复  : 0

[讨论交流] Redis与Hazelcast,在重负荷下的表现孰优孰劣?

[复制链接]
杀马特的忧伤的头像 楼主
发表于 2016-4-29 16:59:16 | 显示全部楼层 |阅读模式
  来源:技术风向标

  Redis自2009年发布以来受到了巨大的欢迎,并且成为拥有大型社区的部署数据存储平台之一。

  虽然Radis有令人难忘的特性,但它也有一个严重的限制——它是为单机模式设计的。如果用户需要超过单机的能力,就需要使用专用分区系统。不过3.0.0版本发布了一种集群系统产品,可以从根本上简化分布式Redis部署。

  所有人都认可Radis很快,我们来看看Hazelcast和Redis的比较。这份报告是为了观察Redis集群方案(v3.0.7)对比Hazelcast(v3.6.1)的表现,特别是在重负荷的情况下。

  为了确保在比较Hazelcast和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。

0.jpg


  脚本      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那样是指数级的。

0 (1).jpg


  脚本        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 用户不希望看到这个。他们是真的有低量的数据负载系统,还是他们有另一种更好的方式?我们建议开发者和架构师们在使用任何技术之前,应该尽职预言并充分测试自己的用例。

  翻译:阿采, 无若
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部