Redis 内存优化建议答案

【问题标题】：Redis Memory Optimization suggestionsRedis 内存优化建议
【发布时间】：2018-07-12 21:08:35
【问题描述】：

我有一个 Redis Master 和 2 个 slave。目前所有 3 个都在同一个 unix 服务器上。 3 个实例使用的内存大约为 3.5 G 、 3 G 、 3G 。 redis 数据库中大约有 275000 个键。大约 4000 个是哈希值。 1 Set 有 100000 个值。 1 列表中有 275000 个键。它是一个哈希和集合列表。服务器的总内存为 16 GB。当前使用 9.5 GB。持久性当前处于关闭状态。 rdb 文件通过强制后台保存一天写入一次。请提供任何优化建议。 max-ziplist 配置目前是默认配置。

【问题讨论】：

将主服务器和从服务器托管在同一台服务器上有何意义？
是的，这是一个很好的观点。最初我们没有很多可用的服务器，因此我们在同一台服务器上设置了 3 个实例。但是现在我们已经将 2 个从属实例移到了不同的服务器上。

标签： memory optimization hash redis set

【解决方案1】：

优化哈希

首先，让我们看一下哈希。两个重要的问题 - 每个散列中有多少元素，这些散列中的最大值是多少？如果满足以下条件，则哈希使用内存高效的 ziplist 表示：

len(hash) < hash-max-ziplist-entries && length-of-largest-field(hash) < hash-max-ziplist-value

你应该根据你的数据增加redis.conf中的两个设置，但是不要增加超过默认值的3-4倍。

优化集

无法优化包含 100000 的集合，除非您提供有关用例的其他详细信息。不过有一些通用策略 -

也许使用 HyperLogLog - 您是否使用集合来计算唯一元素？如果您运行的唯一命令是 sadd 和 scard - 也许您应该切换到超级日志。
也许使用布隆过滤器 - 您是否使用集合来检查成员是否存在？如果您运行的唯一命令是sadd 和sismember - 也许您应该实现一个布隆过滤器并使用它而不是集合。
每个元素有多大？ - 集合成员应该很小。如果您要存储大对象，那么您可能做错了什么。

优化列表

包含 275000 的单个列表似乎是错误的。访问列表中心的元素会很慢。您确定您列出的数据结构适合您的用例吗？
将list-compress-depth 更改为1 或更高。在redis.conf 中阅读有关此设置的信息 - 需要权衡取舍。但对于 275000 个元素的列表，您当然希望启用压缩。

工具

使用开源redis-rdb-tools 分析您的数据集（免责声明：我是该工具的作者）。它会告诉你每个键占用了多少内存。它将帮助您决定将精力集中在哪里。

你也可以参考这个memory optimization cheat sheet。

还有什么？

您提供的用例细节非常少。最好的节省来自为您的用例选择正确的数据结构。我鼓励您更新您的问题，详细了解您在哈希/列表/集合中存储的内容。

【讨论】：

谢谢！！这很有帮助！

【解决方案2】：

我们做了以下配置，这有助于将内存占用减少 40%

list-max-ziplist-entries 2048
list-max-ziplist-value 10000

list-compress-depth 1

set-max-intset-entries 2048

hash-max-ziplist-entries 2048
hash-max-ziplist-value 10000

此外，我们增加了 linux 服务器上的 RAM，这有助于我们解决 Redis 内存问题。

【讨论】：