我们在系统设计面试或者在实际工作中，免不了要进行一些估算。之前的文章里讲过一些技巧，今天来个实战。

这是我最近在做的一个工作，将内存中的一个超大的 map[int64]int64 写入到 redis，map 里的元素个数是千万级的。设计方案的时候，需要对 redis 的容量做一个估算。

如果不了解 redis 的话，可能你的答案是用元素个数直接乘以 16B（key 和 value 各占 8B）。我们假设元素个数是 5kw，那估算结果就是：5kw _ 16B=50kk _ 16B = 800MB。

答案是错的。

为了解决这个问题，需要深入地研究一下 redis 的数据结构。

整个 redis 数据库就是一个大的 map，它容纳了所有的 key，我们都知道 key 都是 string 类型，而 value 则有 string, list, set, hashmap, zset……等类型。

Redis 中的一个 k-v 对用一个 entry 项表示，其中每个 entry 包含 key、value、next 三个指针，共 24 字节。由于 redis 使用 jemalloc 分配内存，因此一个 entry 需要申请 32 字节的内存。这里的 key, value 指针分别指向一个 RedisObject：

redis entry 

1typedef struct redisObject {
2    unsigned type:4;
3    unsigned encoding:4;
4    unsigned lru:LRU_BITS;
5    int refcount;
6    void *ptr;
7} robj;

RedisObject 对应前面提到的各种数据类型，其中最简单的就是 redis 内部的字符串了。它有如下几种编码格式：

SDS 编码

图中的元数据包括 type，encoding，lru， refcount，分别表示数据类型，编码类型，最近一次访问的时间戳，引用次数。

当字符串是一个整型时，直接放在 ptr 位置，不用再分配新的内存了，非常高效。

解析一下 44 字节的原因：元数据和 ptr 共占 16 字节，加上 44 字节，再加上字符串末尾的 ‘\0’，共 61 字节。因为字符串的长度只有 44，因此 len 和 alloc 各用 1 个字节就够了。再加上 1 个字节的 flags，刚好是 64 字节。超过了这个值，SDS 就需要单独再申请一块内存，导致访问的时候就多了一跳指针。

多提一句，redis 最大支持 512MB 大小的字符串。

回答本文的问题，恰好我们要写入 redis 的 map 中的 key 和 value 都是整数，因此直接将值写入 ptr 处即可。

于是 map 的一个 key 占用的内存大小为：32（entry）+16（value）+16（value）=64B。于是，5kw 个 key 占用的内存大小是 5kw*64B = 50 kk * 64B = 3200MB ≈ 3G。

假如我们在 key 前面加上了前缀，那就会生成 SDS，占用的内存会变大，访问效率也会变差。

总之，我们根据要写入 redis 中的字符串的长度可以很方便地估算占用内存的总大小。如果 key 和 value 恰好都是 int64 类型的，那么尽量不要在 key 前加前缀，这样可以直接使用 key 的个数乘以 64B 就能算出占用内存的大小。