Redis 数据结构与内存管理策略（下）
Redis 数据结构与内存管理策略（下）标签： Redis Redis数据结构 Redis内存管理策略 Redis数据类型 Redis类型映射
[*]Redis 数据类型特点与使用场景
[*]String、List、Hash、Set、Zset
[*]案例：沪江团购系统大促 hot-top 接口 cache 设计
[*]Redis 内存数据结构与编码
[*]OBJECT encoding key、DEBUG OBJECT key
[*]简单动态字符串（simple dynamic string）
[*]链表（linked list）
[*]字典（dict）
[*]跳表（skip list）
[*]整数集合（int set）
[*]压缩表（zip list）
[*]Redis Object 类型与映射
[*]Redis 内存管理策略
[*]键 过期时间、生存时间
[*]过期键删除策略
[*]AOF 、RDB 处理过期键策略
[*]Redis LRU 算法
[*]Redis 持久化方式
[*]RDB (Redis DataBase)
[*]AOF (Append-only file)
字典（dict）
dict 字典是基于 hash算法 来实现，是 Hash 数据类型的底层存储数据结构。我们来看下 redis 3.0.0 版本的 dict.h 头文件定义。
typedef struct dict { dictType *type;
void *privdata;
dictht ht;
long rehashidx;
int iterators;
} dict;
typedef struct dictht { dictEntry **table;
unsigned long>
unsigned long> unsigned long used;
} dictht;
typedef struct dictEntry { void *key;
union {
void *val;
uint64_t u64;
int64_t s64;
double d;
} v;
struct dictEntry *next;
} dictEntry;
说到 hash table 有两个东西是我们经常会碰到的，首先就是 hash 碰撞 问题，redis dict是采用链地址法来解决，dictEntry->next 就是指向下个冲突 key 的节点。
还有一个经常碰到的就是 rehash 的问题，提到 rehash 我们还是有点担心性能的。那么redis 实现是非常巧妙的，采用 惰性渐进式 rehash 算法 。
在 dict struct 里有一个 ht 组数，还有一个 rehashidx 索引。redis 进行 rehash 的大致算法是这样的，首先会开辟一个新的 dictht 空间，放在 ht 索引上，此时将 rehashidx 设置为0，表示开始进入 rehash 阶段，这个阶段可能会持续很长时间，rehashidx 表示 dictEntry 个数。
每次当有对某个 ht索引中的 key 进行访问时，获取、删除、更新，redis 都会将当前 dictEntry 索引中的所有 key rehash 到 ht 字典中。一旦 rehashidx=-1 表示 rehash 结束。
跳表（skip list）
skip list 是 zset 的底层数据结构，有着高性能的查找排序能力。
我们都知道一般用来实现带有排序的查找都是用 Tree 来实现，不管是各种变体的 B Tree 还是 B+ Tree，本质都是用来做顺序查找。
skip list 实现起来简单，性能也与 B Tree 相接近。
typedef struct zskiplistNode { robj *obj;
double score;
struct zskiplistNode *backward;
struct zskiplistLevel {
struct zskiplistNode *forward;
unsigned int span;
} level[];
} zskiplistNode;
typedef struct zskiplist {
struct zskiplistNode *header, *tail;
unsigned long length;
int level;
} zskiplist;
zskiplistNode->zskiplistLevel->span 这个值记录了当前节点距离下个节点的跨度。每一个节点会有最大不超过 zskiplist->level 节点个数，分别用来表示不同跨度与节点的距离。
每个节点会有多个 forward 向前指针，只有一个 backward 指针。每个节点会有对象 *obj 和 score 分值，每个分值都会按照顺序排列。
整数集合（int set）
int set 整数集合是 set 数据类型的底层实现数据结构，它的特点和使用场景很明显，只要我们使用的集合都是整数且在一定的范围之内都会使用整数集合编码。
SADD set:userid 100 200 300
(integer) 3
OBJECT encoding set:userid
"intset"
int set 使用一块连续的内存来存储集合数据，它是数组结构不是链表结构。
typedef struct intset { uint32_t encoding;
uint32_t length;
int8_t contents[];
} intset;
intset->encoding 用来确定 contents[] 是什么类型的整数编码，以下三种值之一。
#define INTSET_ENC_INT16 (sizeof(int16_t))
#define INTSET_ENC_INT32 (sizeof(int32_t))
#define INTSET_ENC_INT64 (sizeof(int64_t))
redis 会根据我们设置的值类型动态 sizeof 出一个对应的空间大小。如果我们集合原来是 int16 ，然后往集合里添加了 int32 整数将触发升级，一旦升级成功不会触发降级操作。
压缩表（zip list）
zip list 压缩表是 list、zset、hash 数据类型的底层数据结构之一。它是为了节省内存通过压缩数据存储在一块连续的内存空间中。
typedef struct zlentry { unsigned int prevrawlensize, prevrawlen;
unsigned int lensize, len;
unsigned int headersize;
unsigned char encoding;
unsigned char *p;
} zlentry;
它最大的优点就是压缩空间，空间利用率很高。缺点就是一旦出现更新可能就是连锁更新，因为数据在内容空间中都是连续的，最极端情况下就是可能出现顺序连锁扩张。
压缩列表会由多个 zlentry 节点组成，每一个 zlentry 记录上一个节点长度和大小，当前节点长度 lensize 和大小 len 包括编码 encoding 。
这取决于业务场景，redis 提供了一组配置，专门用来针对不同的场景进行阈值控制。
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-entries 512
list-max-ziplist-value 64
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
上述配置分别用来配置 ziplist 作为 hash 、list、zset 数据类型的底层压缩阈值控制。
Redis Object 类型与映射
redis 内部每一种数据类型都是对象化的，也就是我们所说的5种数据类型其实内部都会对应到 redisObject 对象，然后在由 redisObject 来包装具体的存储数据结构和编码。
typedef struct redisObject { unsigned type:4;
unsigned encoding:4;
unsigned lru:REDIS_LRU_BITS;
int refcount;
void *ptr;
} robj;
这是一个很 OO 的设计，redisObject->type 是 5 种数据类型之一，redisObject->encoding 是这个数据类型所使用的数据结构和编码。
我们看下 redis 提供的 5 种数据类型与每一种数据类型对应的存储数据结构和编码。
/* Object types */
#define REDIS_STRING 0
#define REDIS_LIST 1
#define REDIS_SET 2
#define REDIS_ZSET 3
#define REDIS_HASH 4
#define REDIS_ENCODING_RAW 0
#define REDIS_ENCODING_INT 1
#define REDIS_ENCODING_HT 2
#define REDIS_ENCODING_ZIPMAP 3
#define REDIS_ENCODING_LINKEDLIST 4
#define REDIS_ENCODING_ZIPLIST 5
#define REDIS_ENCODING_INTSET 6
#define REDIS_ENCODING_SKIPLIST 7
#define REDIS_ENCODING_EMBSTR 8
REDIS_ENCODING_ZIPMAP 3 这个编码可以忽略了，在特定的情况下有性能问题，在 redis 2.6 版本之后已经废弃，为了兼容性保留。
上图是 redis 5 种数据类型与底层数据结构和编码的对应关系，但是这种对应关系在每一个版本中都会有可能发生变化，这也是 redisObject 的灵活性所在，有着 OO 的这种多态性。
redisObject->refcount 表示当前对象的引用计数，在 redis 内部为了节省内存采用了共享对象的方法，当某个对象被引用的时候这个 refcount 会加 1，释放的时候会减 1。
redisObject->lru 表示当前对象的 空转时长，也就是 idle time ，这个时间会是 redis lru 算法用来释放对象的时间依据。可以通过 OBJECT> 命令查看某个 key 的空转时长 lru 时间。
Redis 内存管理策略
redis 在服务端分别为不同的 db index 维护一个 dict 这个 dict 称为 key space 键空间 。每一个 redis client 只能属于一个 db index ，在 redis 服务端会维护每一个链接的 redisClient 。
typedef struct redisClient { uint64_t> int fd;
redisDb *db;
} redisClient;
在服务端每一个 redis 客户端都会有一个指向 redisDb 的指针。
typedef struct redisDb { dict *dict;
dict *expires;
dict *blocking_keys;
dict *ready_keys;
dict *watched_keys;
struct evictionPoolEntry *eviction_pool;
int> long long avg_ttl;
} redisDb;
key space 键空间就是这里的 redisDb->dict 。redisDb->expires 是维护所有键空间的每一个 key 的过期时间。
键 过期时间、生存时间
对于一个 key 我们可以设置它多少秒、毫秒之后过期，也可以设置它在某个具体的时间点过期，后者是一个时间戳。
EXPIRE 命令可以设置某个 key 多少秒之后过期
PEXPIRE 命令可以设置某个 key 多少毫秒之后过期
EXPIREAT 命令可以设置某个 key 在多少秒时间戳之后过期
PEXPIREAT 命令可以设置某个 key 在多少毫秒时间戳之后过期
PERSIST 命令可以移除键的过期时间
其实上述命令最终都会被转换成对 PEXPIREAT 命令。在 redisDb->expires 指向的 key 字典中维护着一个到期的毫秒时间戳。
TTL、PTTL 可以通过这两个命令查看某个 key 的过期秒、毫秒数。
redis 内部有一个 事件循环，这个事件循环会检查键的过期时间是否小于当前时间，如果小于则会删除这个键。
过期键删除策略
在使用 redis 的时候我们最关心的就是键是如何被删除的，如何高效的准时的删除某个键。其实 redis 提供了两个方案来完成这件事情。
redis 采用 惰性删除 、 定期删除 双重删除策略。
当我们访问某个 key 的时候 redis 会检查它是否过期，这是惰性删除。
robj *lookupKeyRead(redisDb *db, robj *key) { robj *val;
expireIfNeeded(db,key);
val = lookupKey(db,key);
if (val == NULL)
server.stat_keyspace_misses++;
else
server.stat_keyspace_hits++;
return val;
}
int expireIfNeeded(redisDb *db, robj *key) { mstime_t when = getExpire(db,key);
mstime_t now;
if (when < 0) return 0; /* No expire for this key */
if (server.loading) return 0;
now = server.lua_caller ? server.lua_time_start : mstime();
if (server.masterhost != NULL) return now > when;
/* Return when this key has not expired */
if (now id);
return dbDelete(db,key);
}
redis 也会通过 事件循环 周期性的执行 key 的过期删除动作，这是定期删除。
int serverCron(struct aeEventLoop *eventLoop, long long>/* Handle background operations on Redis databases. */
databasesCron();
}
void databasesCron(void) { /* Expire keys by random sampling. Not required for slaves
* as master will synthesize DELs for us. */
if (server.active_expire_enabled && server.masterhost == NULL)
activeExpireCycle(ACTIVE_EXPIRE_CYCLE_SLOW);
}
惰性删除 是每次只要有读取、写入都会触发惰性删除代码。周期删除 是由 redis EventLoop 来触发的。redis 内部很多维护性工作都是基于 EventLoop 。
AOF 、RDB 处理过期键策略
既然键会随时存在过期问题，那么涉及到持久化 redis 是如何帮我们处理的。
当 redis 使用 RDB 方式持久化时，每次持久化的时候就会检查这些即将被持久化的 key 是否已经过期，如果过期将直接忽略，持久化那些没有过期的键。当 redis 作为 master 主服务器 启动的时候，在载入 rdb 持久化键时也会检查这些键是否过期，将忽略过期的键，只载入没过期的键。
当 redis 使用 AOF 方式持久化时，每次遇到过期的 key redis 会追加一条 DEL 命令 到 AOF 文件，也就是说只要我们顺序载入执行 AOF 命令文件就会删除过期的键。
如果 redis 作为从服务器启动的化，它一旦与 master 主服务器 建立链接就会清空所有数据进行完整同步，当然新版本的 redis 支持 SYCN2 的半同步。如果是已经建立了 master/slave 主从同步之后，主服务器会发送 DEL 命令给所有从服务器执行删除操作。
Redis LRU 算法
在使用 redis 的时候我们会设置 maxmemory 选项，64 位的默认是 0 不限制。线上的服务器必须要设置的，要不然很有可能导致 redis 宿主服务器直接内存耗尽最后链接都上不去。
所以基本要设置两个配置：
maxmemory 最大内存阈值
maxmemory-policy 到达阈值的执行策略
可以通过 CONFIG GET maxmemory/maxmemory-policy 分别查看这两个配置值，也可以通过 CONFIG SET 去分别配置。
maxmemory-policy 有一组配置，可以用在很多场景下：
noeviction：客户端尝试执行会让更多内存被使用的命令直接报错
allkeys-lru： 在所有key里执行lru算法
volatile-lru：在所有已经过期的key里执行lru算法
allkeys-random：在所有key里随机回收
volatile-random：在已经过期的key里随机回收
volatile-ttl：回收已经过期的key，并且优先回收存活时间（TTL）较短的键
关于 cache 的命中率可以通过 info 命令查看 键空间的命中率和未命中率。
# Stats
keyspace_hits:33
keyspace_misses:5
maxmemory 在到达阈值的时候会采用一定的策略去释放内存，这些策略我们可以根据自己的业务场景来选择，默认是 noeviction 。
redis LRU 算法有一个取样的优化机制，可以通过一定的取样因子来加强回收的 key 的准确度。CONFIG GET maxmemory-samples 查看取样配置，具体可以参考更加详细的文章。
Redis 持久化方式
redis 本身提供持久化功能，有两种持久化机制，一种是数据持久化 RDB ，一种是命令持久化 AOF，这两种持久化方式各有优缺点，也可以组合使用，一旦组合使用 redis 在载入数据的时候会优先载入 aof 文件，只有当 AOF 持久化关闭的时候才会载入 rdb 文件。
RDB (Redis DataBase)
RDB 是 redis 数据库，redis 会根据一个配置来触发持久化。
#save
save 900 1
save 300 10
save 60 10000
CONFIG GET save
1) "save"
2) "3600 1 300 100 60 10000"
表示在多少秒之类的变化次数，一旦达到这个触发条件 redis 将触发持久化动作。redis 在执行持久化的时候有两种模式 BGSAVE、SAVE 。BGSAVE 是后台保存，redis 会 fork 出一个子进程来处理持久化，不会 block 用户的执行请求。而 SAVE 则会 block 用户执行请求。
struct redisServer {
long long dirty;/* Changes to DB from the last save */
time_t lastsave; /* Unix time of last successful save */
long long dirty_before_bgsave;
pid_t rdb_child_pid;/* PID of RDB saving child */
struct saveparam *saveparams; /* Save points array for RDB */
}
struct saveparam { time_t seconds;
int changes;
};
redisServer 包含的信息很多，其中就包含了有关于 RDB 持久化的信息。redisServer->dirty至上次 save 到目前为止的 change 数。redisServer->lastsave 上次 save 时间。
saveparam struct 保存了我们通过 save 命令设置的参数，__time_t是个 long__ 时间戳。
typedef __darwin_time_t time_t;
typedef long __darwin_time_t; /* time() */
int serverCron(struct aeEventLoop *eventLoop, long long>for (j = 0; j < server.saveparamslen; j++) {
struct saveparam *sp = server.saveparams+j;
if (server.dirty >= sp->changes &&
server.unixtime-server.lastsave > sp->seconds &&
(server.unixtime-server.lastbgsave_try >
REDIS_BGSAVE_RETRY_DELAY ||
server.lastbgsave_status == REDIS_OK))
{
redisLog(REDIS_NOTICE,"%d changes in %d seconds. Saving...",
sp->changes, (int)sp->seconds);
rdbSaveBackground(server.rdb_filename);
break;
}
}
}
redis 事件循环会周期性的执行 serverCron 方法，这段代码会循环遍历 server.saveparams 参数链表。
如果 server.dirty 大于等于 我们参数里配置的变化并且 server.unixtime-server.lastsave 大于参数里配置的时间并且 __server.unixtime-server.lastbgsave_try减去 bgsave重试延迟时间或者当前 server.lastbgsave_status==REDIS_OK则执行rdbSaveBackground__ 方法。
AOF (Append-only file)
AOF 持久化是采用对文件进行追加对方式进行，每次追加都是 redis 处理的 命令。有点类似 command sourcing 命令溯源 的模式。
只要我们可以将所有的命令按照执行顺序在重放一遍就可以还原最终的 redis 内存状态。
AOF 持久化最大的优势是可以缩短数据丢失的间隔，可以做到秒级的丢失率。RDB 会丢失上一个保存周期到目前的所有数据，只要没有触发 save 命令设置的 save seconds changes 阈值数据就会一直不被持久化。
struct redisServer { /* AOF buffer, written before entering the event loop */
sds aof_buf;
}
struct sdshdr { unsigned int len;
unsigned int free;
char buf[];
};
aof_buf是命令缓存区，采用 sds结构缓存，每次当有命令被执行当时候都会写一次到 aof_buf 中。有几个配置用来控制 AOF 持久化的机制。
appendonly no
appendfilename "appendonly.aof"
appendonly 用来控制是否开启 AOF 持久化，appendfilename 用来设置 aof 文件名。
appendfsync always
appendfsync everysec
appendfsync no
appendfsync 用来控制命令刷盘机制。现在操作系统都有文件 cache/buffer 的概念，所有的写入和读取都会走 cache/buffer，并不会每次都同步刷盘，因为这样性能一定会受影响。所以 redis 也提供了这个选项让我们来自己根据业务场景控制。
always ：每次将 aof_buf命令写入 aof文件并且执行实时刷盘。
everysec：每次将 aof_buf 命令写入 aof 文件，但是每隔一秒执行一次刷盘。
no ：每次将 __aof_buf命令写入 aof__ 文件不执行刷盘，由操作系统来自行控制。
AOF 也是采用后台子进程的方式进行，与主进程共享数据空间也就是 aof_buf，但是只要开始了 AOF_ 子进程之后 redis 事件循环文件事件处理器_ 会将之后的命令写入另外一个 __aof_buf ，这样就可以做到平滑的切换。
AOF 会不断的追加命令进 aof 文件，随着时间和并发量的加大 aof 文件会极速膨胀，所以有必要对这个文件大小进行优化。redis基于 rewrite 重写对文件进行压缩。
no-appendfsync-on-rewrite no/yes
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
no-appendfsync-on-rewrite 控制是否在 bgrewriteaof 的时候还需要进行命令追加，如果追加可能会出现磁盘 IO 跑高现象。
上面说过，当 AOF 进程在执行的时候原来的事件循环还会正常的追加命令进 aof 文件，同时还会追加命令进另外一个 aof_buf，用来做新 aof文件的重写。这是两条并行的动作，如果我们设置成 yes就不追加原来的 aof_buf 因为新的 aof 文件已经包含了之后进来的命令。
auto-aof-rewrite-percentage、auto-aof-rewrite-min-size 64mb 这两个配置前者是文件增长百分比来进行 rewrite ，后者是按照文件大小增长进行 rewrite 。
页:
[1]