Redis 内存优化神技，小内存保存大数据

这次跟大家分享一些优化神技，当你面试或者工作中你遇到如下问题，那就使出今天学到的绝招，一招定乾坤！

如何用更少的内存保存更多的数据？

我们应该从 Redis 是如何保存数据的原理展开，分析键值对的存储结构和原理。

从而继续延展出每种数据类型底层的数据结构，针对不同场景使用更恰当的数据结构和编码实现更少的内存占用。

为了保存数据， Redis 需要先申请内存，数据过期或者内存淘汰需要回收内存，从而拓展出内存碎片优化。

最后，说下 key、value 使用规范和技巧、 Bitmap 等高阶数据类型，运用这些技巧巧妙解决有限内存去存储更多数据难题……

这一套组合拳下来直接封神。

主要优化神技如下：

• 键值对优化；

• 小数据集合的编码优化；

• 使用对象共享池；

• 使用 Bit 比特位或 byte 级别操作

• 使用 hash 类型优化；

• 内存碎片优化；

• 使用 32 位的 Redis。

在优化之前，我们先掌握 Redis 是如何存储数据的。

Redis 如何存储键值对

Redis 以 redisDb 为中心存储，Redis 7.0 源码在 https://github.com/redis/redis/blob/7.0/src/server.h：

redisDb

• dict：最重要的属性之一，就是靠这个定义了保存了对象数据键值对，dcit 的底层结构是一个哈希表；

• expires：保存着所有 key 的过期信息；

• blocking_keys 和 ready_keys 主要为了实现 BLPOP 等阻塞命令；

• watched_keys 用于实现 watch 命令，记录正在被 watch 的一些 key，与事务相关；

• id 为当前数据库的 id。Redis 支持单个服务多数据库，默认有1 6 个；

• clusterSlotToKeyMapping：Cluster 模式下，存储 key 与哈希槽映射关系的数组。

Redis 使用「dict」结构来保存所有的键值对（key-value）数据，这是一个全局哈希表，所以对 key 的查询能以 O(1) 时间得到。

所谓哈希表，我们可以类比 Java 中的 HashMap，其实就是一个数组，数组的每个元素叫做哈希桶。

dict 结构如下，源码在 https://github.com/redis/redis/blob/7.0/src/dict.h：

struct dict {
      // 特定类型的处理函数    dictType *type;  // 两个全局哈希表指针数组，与渐进式 rehash 有关    dictEntry **ht_table[2];    // 记录 dict 中现有的数据个数。    unsigned long ht_used[2];   // 记录渐进式 rehash 进度的标志， -1 表示当前没有执行 rehash     long rehashidx;
   // 小于 0 表示 rehash 暂停    int16_t pauserehash;    signed char ht_size_exp[2];};

• dictType：存储了 hash 函数，key 和 value 的复制等函数；

• ht_table：长度为 2 的 数组，正常情况使用 ht_table[0] 存储数据，当执行 rehash 的时候，使用 ht_table[1]  配合完成 。

key 的哈希值最终会映射到 ht_table  的一个位置，如果发生哈希冲突，则拉出一个哈希链表。

大家重点关注 dictEntry 类型的 ht_table，ht_table 数组每个位置我们也叫做哈希桶，就是这玩意保存了所有键值对。

Redis 支持那么多的数据类型，哈希桶咋保存？

哈希桶的每个元素的结构由 dictEntry 定义：

typedef struct dictEntry {
     // 指向 key 的指针    void *key;    union {
          // 指向实际 value 的指针        void *val;        uint64_t u64;        int64_t s64;        double d;    } v;