为什么我的红包填得这么快？

Question

我是使用redis存储位以跟踪每小时、每天、每周和每月活动用户。。每当我有一个具有唯一user、hour或eventType的事件时，就会存储一个位。

我使用的redis命令(节点客户端)是client.setbit(key, id, 1);

其中key类似于login-mobile-2015-11-14-04，id是一个6位整数(指用户)。

在短短几天内，我就达到了heroku免费计划的25 of限制，但是最大的实际数据量(基于唯一事件的数量&用户是每天的192000 )，它的字节数少于25 of。我怀疑我的钥匙太长或什么问题，但我真的不太了解瑞迪斯，所以我只想问。

Answer 1

答案是Redis字符串内部数据结构。Redus使用SDS，SDS字符串，有时它真正重要的是弄清它是如何工作的。最重要的是SDS中的内存分配策略。

实际上，当它小于SDS_MAX_PREALLOC(1MB)时，它仅仅是原来大小的两倍。当内存不足时，这类似于C++矢量分配策略。这就是为什么字符串追加操作不需要每次都分配内存。

为什么这对我们的问题很重要。SETBIT只使用字符串作为容器，因此如果使用userId那样的6位整数，那么(最糟糕的情况下)99,999/8= 125,000字节+8字节的开销。但是根据分配策略，每个键的开销可能高达250,000 +8字节。

所以一些数学：

• 小时统计值为250 kb *每天24 = 6mb
• 每日、每周和每月每个柜台250 is (总计1mb)

所以，在最坏的情况下，你只用了4天就花了25毫巴。但在最好的情况下，那么125 kb是一个最大的关键内存，你花25毫b在7-8天。

BITSET是快速和好的，但消耗了大量的内存。如果你有很多在线用户，使用BITSET进行每日、每周和每月的数据似乎是一个正确的决定。Bitset并不是稀疏数据的最佳选择。

分析您的每小时数据-可能使用SET允许使用较少的内存-您的userId是整数(4个字节)，所以128 be是~32,000用户每小时。还可以看看红宝石内存优化指南 --您可能会发现，在redis中，实际内存的使用非常有趣。

关于SET解决方案--你的在线时间是否少于3.2万用户-- SET是你的选择。

此外，您还可以使用redis命令DEBUG SDSLEN <key name>调试BITSET键-它显示您在位集数据下为SDS字符串分配了内存。