redis vs hazelcast [关闭]答案

【问题标题】：redis vs hazelcast [closed]redis vs hazelcast [关闭]
【发布时间】：2011-05-05 19:02:54
【问题描述】：

Redis 与 Hazelcast 如果我的应用：

有很多 http 请求（每分钟 6000 个，我收集点击信息）需要保存
有大量 http 请求查询之前保存的数据。

我的问题是 - 我应该在 Redis 和 Hazelcast 之间选择哪一个来存储和查询数据 - 哪个读写速度更快？ - 哪个更可靠？ - Cassandra 会是更好的选择吗？

回答任何问题都有帮助

【问题讨论】：

您应该尝试更好地描述您的问题。您要放入的数据，尤其是您需要查询数据的方式。
我计划放置大约 30 M 键值。数据看起来像。用户标识集。 set 具有该用户的属性，大约 10 个。它会不断更新，并且会不断得到查询。我喜欢 redis，因为它知道 Set 是什么，而且它是一个操作，但它无法扩展。
差不多十年后，6000 req/min 已经很普遍了，几乎不是“很多”。

标签： redis hazelcast

【解决方案1】：

Redis 和 Hazelcast 都是基于内存的数据库，因此理论上它们应该提供相同的速度和性能。查看 Hazelcast 的文档，您将获得对 Redis 的更好支持，因为有大量用于与数据库交互的库。 Hazelcast 看起来他们只有 java 库，Redis 每种语言都有一个。

答案：

你必须自己测试，据我所知，不同的比较显示 Redis 更快one of them is here，但我不会说这些基准测试是 100%
它们应该都是可靠的，但我不能保证 Hazelcast。
也许……

我会选择 Redis，因为我发现它是最有用的，而且它有很好的文档。

【讨论】：

该基准将 Redis 与 memcached 进行比较，而不是 Hazelcast。

【解决方案2】：

为了缓存需求，我们从 redis 切换到 hazelcast。

原始生物 + Hazelcast 比我们快得多
Protostuff + Jedis（池化）+ Redis

我们使用 protostuff 序列化创建成本高的 bean。 Hazelcast 的标准序列化机制要慢得多。我们的环境是 Glassfish 3.1。

Hazelcast 看起来他们只有 java 库，Redis 每种语言都有一个。

没错。 Hazelcast 仅提供 REST API 和 memcached 协议的实现。

【讨论】：

现在 Hazelcast 在 .Net、Java、C++、NodeJS、Python、Go 和 Scala 中拥有许多官方客户端，列在here

【解决方案3】：

有一个非常方便的库 - Redisson。它提供分布式Java对象和服务（BitSet、BloomFilter、Set、SortedSet、Map、ConcurrentMap、List、Queue、Deque、@98765433333 @, ReadWriteLock, Semaphore, Lock, AtomicLong, CountDownLatch, Publish / Subscribe, RemoteService, ExecutorService, LiveObjectService, ScheduledExecutorService!) 在 Re 服务器之上p>

它支持集群、哨兵、主/从和单连接模式。

完美地在云端运行，支持 AWS Elasticache 和 Azure Redis Cloud

以下是 Redisson 客户的一些成功案例：

Moving from Hazelcast to Redis
Distributed Locking with Redis (Migration from Hazelcast)

请注意：我是 Redisson 的作者

【讨论】：

恕我直言，您是 redisson 的作者，所以请在答案中明确说明。
@hosseinbakhtiari 完成

【解决方案4】：

截至 2017 年，Redis 和 Hazelcast 都提供高度可用\可扩展的键\值存储。响应时间非常快

Redis 的独特之处在于它支持其他数据结构，例如排序集、哈希集和 pub\sub 机制。它也可以通过 lua 脚本进行扩展。它可能是这两种产品中最受欢迎和使用最广泛的。尤其是在 Java 生态系统之外。

Hazelcast 的独特之处在于它可以嵌入到 Java 主机进程中，非常适合构建无外部数据库依赖的有状态微服务。它还有一些其他的小区别，比如从密钥过期中获得回调的能力。从某种意义上说，它总体上做得更少，但它做的几件事，它做得更好。特别是如果您使用的是 Java。

总体而言，这些都是为类似用例设计的类似解决方案，例如缓存外部数据、为有状态微服务创建通信背板或共享内存状态，或者甚至可能存储（少量非关系型）具有一定持久性的业务数据.

【讨论】：

不同意你的意见。 Redis 规模配置没花多少时间就花了一个小时左右。例如，如果您使用 Redisson，您也不需要 Twemproxy。它可以为您解决任何连接平衡问题。
我同意 Redis 集群的 RC 和用于 Redis 的新 SaaS 托管服务，自从我写这篇文章以来，在将 Redis 扩展到多个水平负载平衡实例方面，情况已经发生了变化。
@Eric 那么请编辑或删除你的答案。

【解决方案5】：

要决定哪个好，有一个关于客户端线程使用的问题。

据此benchmark Hazelcast 如果您使用更多线程，则比 Redis 更好。也许这是一个不公平的公司基准，但显示了一些关于线程的东西。

【讨论】：

如果有任何反馈或批评，我可以从中学习或用于帮助我改进答案，我将不胜感激。因此，请在对答案投反对票时发表评论...
我不会相信这样的基准。首先，它没有提供任何关于 Redis 集群的信息，例如它所包含的主/从节点数量等主要部分。例如，Redis 集群写入操作的规模取决于读取操作的主节点数量。这是另一个基准，显示 Redis 集群 highscalability.com/blog/2014/8/27/… 的 120 万次操作/秒
我认为你之所以被否决主要是因为人们正在寻找对不同产品的独立和中立的评价，而你刚刚链接了 Hazelcast 自己的博客，即使他们试图保持中立，但仍有可能是有偏见，因为他们会创建适合他们产品的测试。此外，stackoverflow 更希望您引用相关信息并提供链接，以防链接停止工作。