标签：stl 多次 color imp 地址 特征 完成 def 其他
1、Simple Dynamic String：简单动态字符串，Sds
是Redis底层所使用的字符串表示，sds在Redis中的主要作用：
char*类型功能单一，抽象层次低，不能高效地支持一些Redis常用的操作（比如追加操作和长度计算操作）-->每次计算字符串长度（strlen(s)）的复杂度为O（N）；对字符串进行N次追加，必定需要对字符串进行N次内存重分配（realloc）
sds既可以高效地实现追加和长度计算，并且它还是二进制安全的
1 typedef char * sds; 2 3 struct sdshdr { 4 // buf已占用长度-->通过len属性，sdshdr可以实现复杂度为O(1)的长度计算操作 5 int len; 6 // buf剩余可用长度-->通过对buf分配一些额外的空间，并使用free记录未使用空间的大小，sdshdr可以让执行追加操作所需的内存重分配次数大大减少 7 int free; 8 // 实际保存字符串数据的地方 9 char buf[]; 10 }; 11 12 struct sdshdr { 13 len = 11; 14 free = 0; 15 buf = "hello world\0"; //buf的实际长度为len+1 16 };
//优化追加操作-->sdshdr结构减少追加（append）操作所需的内存重分配次数
//当调用SET命令创建sdshdr时，sdshdr的free属性为0，Redis也没有为buf创建额外的空间，而在执行APPEND之后，Redis为buf创建了多于所需空间一倍的大小
//sdsMakeRoomFor函数描述了sdshdr的这种内存预分配优化策略，伪代码如下
1 def sdsMakeRoomFor(sdshdr, required_len): 2 #预分配空间足够，无须再进行空间分配 3 if (sdshdr.free >= required_len): 4 return sdshdr 5 6 #计算新字符串的总长度 7 newlen = sdshdr.len + required_len 8 9 #如果新字符串的总长度小于SDS_MAX_PREALLOC 10 #那么为字符串分配2倍于所需长度的空间 11 #否则就分配所需长度加上SDS_MAX_PREALLOC数量的空间 12 if newlen < SDS_MAX_PREALLOC: 13 newlen *= 2 14 else: 15 newlen += SDS_MAX_PREALLOC 16 17 #分配内存 18 newsh = zrelloc(sdshdr, sizeof(struct sdshdr)+newlen+1) 19 20 #更新free属性 21 newsh.free = newlen - sdshdr.len 22 23 #返回 24 return newsh
在目前版本的Redis中，SDS_MAX_PREALLOC的值为1024*1024，也就是说，当大小小于1MB的字符串执行追加操作时，sdsMakeRoomFor就为它们分配多于所需大小一倍的空间；当字符串的大小大于1MB，那么sdsMakeRoomFor就为它们额外多分配1MB的空间
这种分配策略会浪费内存吗？
执行过APPEND命令的字符串会带有额外的预分配空间不会被释放，除非该字符串所对应的键被删除，或者等到关闭Redis之后，再次启动时重新载入的字符串对象将不会有预分配空间。
因为执行APPEND命令的字符串键数量通常并不多，占用内存的体积通常也不大，所以这一般并不算什么问题。
另一方面，如果执行APPEND操作的键很多，而字符串的体积又很大的话，那可能就需要修改Redis服务器，让它定时释放一些字符串键的预分配空间，从而更有效地使用内存。
sds模块的API
Redis 的字符串表示为 sds ，而不是 C 字符串（以 \0 结尾的 char*）。
• 对比 C 字符串，sds 有以下特性：
– 可以高效地执行长度计算（strlen）；
– 可以高效地执行追加操作（append）；
– 二进制安全；
• sds 会为追加操作进行优化：加快追加操作的速度，并降低内存分配的次数，代价是多占 用了一些内存，而且这些内存不会被主动释放。
2、双端链表
双端链表在Redis内部的应用：是Redis列表结构的底层实现之一，还被大量Redis模块所使用，用于构建Redis的其他功能
Redis列表使用两种数据结构作为底层实现：双端链表；压缩列表
因为双端链表占用的内存比压缩列表要多，所以当创建新的列表键时，列表会优先考虑使用压缩列表作为底层实现，并且在有需要的时候，才从压缩列表实现转换到双端链表实现
1 //双端链表的实现由listNode和list两个数据结构构成，listNode是双端链表的节点，list是双端链表本身 2 typedef struct listNode { 3 //前驱节点 4 struct listNode *prev; 5 6 //后继节点 7 struct listNode *next; 8 9 //listNode带有prev和next两个指针，因此对链表的遍历可以在两个方向上进行 10 11 //值-->listNode的value属性的类型是void *，说明这个双端链表对节点所保存的值的类型不做限制 12 void *value; 13 } listNode; 14 15 //对于不同类型的值，有时候需要不同的函数来处理这些值，因此，list类型保留了三个函数指针--dup、free和match，分别用于处理值的复制、释放和对比匹配。在对节点的值进行处理时，如果有给定这些函数，那么它们就会被调用 16 typedef struct list { 17 //表头指针 18 listNode *head; 19 20 //表尾指针 21 listNode *tail; 22 23 //list保存了head和tail两个指针，因此对链表的表头和表尾进行插入的复杂度都为O(1)，这是高效实现LPUSH、RPOP、RPOPLPUSH等命令的关键 24 25 //节点数量 26 unsigned long len; 27 28 //list带有保存节点数量的len属性，所以计算链表长度的复杂度仅为O(1)，保证了LLEN命令不会成为性能瓶颈 29 30 //复制函数 31 void *(*dup)(void *ptr); 32 //释放函数 33 void (*free)(void *ptr); 34 //比对函数 35 int (*match)(void *ptr, void *key); 36 } list;
1 //迭代器，Redis为双端链表实现了一个迭代器，这个迭代器可以从两个方向对双端链表进行迭代 2 3 typedef struct listIter { 4 //下一节点 5 listNode *next； 6 7 //迭代方向 8 int direction； 9 } listIter；
• Redis 实现了自己的双端链表结构。
• 双端链表主要有两个作用：
– 作为 Redis 列表类型的底层实现之一；
– 作为通用数据结构，被其他功能模块所使用；
• 双端链表及其节点的性能特性如下：
– 节点带有前驱和后继指针，访问前驱节点和后继节点的复杂度为 O(1) ，并且对链表 的迭代可以在从表头到表尾和从表尾到表头两个方向进行；
– 链表带有指向表头和表尾的指针，因此对表头和表尾进行处理的复杂度为 O(1) ；
– 链表带有记录节点数量的属性，所以可以在 O(1) 复杂度内返回链表的节点数量（长度）；
3、字典
字典dictionary，又名映射map或关联数组associative array
Redis中字典的主要用途：
实现数据库键空间-->Redis 是一个键值对数据库，数据库中的键值对就由字典保存：每个数据库都有一个与之相对 应的字典，这个字典被称之为键空间（key space）
用作Hash类型键的其中一种底层实现-->因为压缩列表比字典更节省内存，所以程序在创建新 Hash 键时，默认使用压缩列表作为底层 实现，当有需要时，程序才会将底层实现从压缩列表转换到字典
字典的实现：
实现字典的方法有很多种：
• 最简单的就是使用链表或数组，但是这种方式只适用于元素个数不多的情况下；
• 要兼顾高效和简单性，可以使用哈希表；
• 如果追求更为稳定的性能特征，并且希望高效地实现排序操作的话，则可以使用更为复 杂的平衡树；
1 //字典 每个字典使用两个哈希表，用于实现渐进式rehash 2 typedef struct dict { 3 //特定于类型的处理函数 4 dictType *type; 5 6 //类型处理函数的私有数据 7 void *privdata; 8 9 //哈希表（2个） 10 dictht ht[2]; 11 12 //dict类型使用了两个指针分别指向两个哈希表，其中0号哈希表（ht[0]）是字典主要使用的哈希表，而1号哈希表（ht[1]）则只有在程序对0号哈希表进行rehash时才使用 13 14 //记录rehash进度的标志，值为-1表示rehash未进行 15 int rehashidx; 16 17 //当前正在运作的安全迭代器数量 18 int iterators; 19 } dict;
1 //哈希表 2 3 typedef struct dictht { 4 //哈希表节点指针数组（桶，bucket） 5 dictEntry **table; 6 7 //table属性是一个数组，数组的每个元素都是一个指向dictEntry结构的指针。每个dictEntry都保存着一个键值对，以及一个指向另一个dictEntry结构的指针 8 9 //指针数组的大小 10 unsigned long size; 11 12 //指针数组的长度掩码，用于计算索引值 13 unsigned long sizemask; 14 15 //哈希表现有的节点数量 16 unsigned long used; 17 } dictht; 18 19 //哈希表节点 20 typedef struct dictEntry { 21 //键 22 void *key; 23 24 //值 25 union { 26 void *val; 27 uint64_t u64; 28 int64_t s64; 29 } v; 30 31 //链后继节点 32 struct dictEntry *next; 33 34 //next属性指向另一个dictEntry结构，多个dictEntry可以通过next指针串联成链表，dictht使用链地址法处理键碰撞 35 } dictEntry;
创建新字典-->
新创建的两个哈希表都没有为 table 属性分配任何空间：• ht[0]->table 的空间分配将在第一次往字典添加键值对时进行； • ht[1]->table 的空间分配将在 rehash 开始时进行；
添加键值对到字典-->
根据字典所处的状态，将一个给定的键值对添加到字典可能会引起一系列复杂的操作：
• 如果字典为未初始化（也即是字典的 0 号哈希表的 table 属性为空），那么程序需要对 0 号哈希表进行初始化；
• 如果在插入时发生了键碰撞，那么程序需要处理碰撞；
• 如果插入新元素使得字典满足了 rehash 条件，那么需要启动相应的 rehash 程序；
添加新元素到空白字典-->
当第一次往空字典里添加键值对时，程序会根据 dict.h/DICT_HT_INITIAL_SIZE 里指定的大 小为 d->ht[0]->table 分配空间（在目前的版本中，DICT_HT_INITIAL_SIZE 的值为 4 ）。
添加新键值对时发生碰撞处理-->
链地址法
添加新键值对时触发了rehash操作-->
对于使用链地址法来解决碰撞问题的哈希表dictht来说，哈希表的性能依赖于它的大小（size 属性）和它所保存的节点的数量（used 属性）之间的比率：
• 比率在 1:1 时，哈希表的性能最好；
• 如果节点数量比哈希表的大小要大很多的话，那么哈希表就会退化成多个链表，哈希表 本身的性能优势就不再存在；
为了在字典的键值对不断增多的情况下保持良好的性能，字典需要对所使用的哈希表（ht[0]） 进行 rehash 操作：在不修改任何键值对的情况下，对哈希表进行扩容，尽量将比率维持在 1:1 左右。
dictAdd 在每次向字典添加新键值对之前，都会对哈希表 ht[0] 进行检查，对于 ht[0] 的 size 和 used 属性，如果它们之间的比率 ratio = used / size 满足以下任何一个条件的话， rehash 过程就会被激活：
1. 自然 rehash ：ratio >= 1 ，且变量 dict_can_resize 为真。
2. 强 制 rehash ： ratio 大 于 变 量 dict_force_resize_ratio （目 前 版 本 中， dict_force_resize_ratio 的值为 5 ）。
什么时候 dict_can_resize 会为假？一个数据库就是一个字典，数据库里的哈希类型键也是一个字典，当 Redis 使用子进程对数据库执行后台持久化任务时（比如执行 BGSAVE 或 BGREWRITEAOF 时），为了最大化地利用系统的 copy on write ?机制，程序会暂时将 dict_can_resize 设为假，避免执行自然 rehash ，从而减少程序对内存的触碰（touch）。当持久化任务完成之后，dict_can_resize 会重新被设为真。
另一方面，当字典满足了强制 rehash 的条件时，即使 dict_can_resize 不为真（有 BGSAVE 或 BGREWRITEAOF 正在执行），这个字典一样会被 rehash 。
rehash执行过程-->
字典的 rehash 操作实际上就是执行以下任务：
1. 创建一个比 ht[0]->table 更大的 ht[1]->table ；
2. 将 ht[0]->table 中的所有键值对迁移到 ht[1]->table ；
3. 将原有 ht[0] 的数据清空，并将 ht[1] 替换为新的 ht[0] ；
开始Rehash：
这个阶段有两个事情要做： 1. 设置字典的 rehashidx 为 0 ，标识着 rehash 的开始； 2. 为 ht[1]->table 分配空间，大小至少为 ht[0]->used 的两倍；
Rehash进行中：
在这个阶段，ht[0]->table 的节点会被逐渐迁移到 ht[1]->table ，因为 rehash 是分多次进行的，字典的 rehashidx 变量会记录 rehash 进行到 ht[0] 的哪个索引位置上。
节点迁移完毕：
到了这个阶段，所有的节点都已经从 ht[0] 迁移到 ht[1] 了
Rehash完毕：
在 rehash 的最后阶段，程序会执行以下工作：
1. 释放 ht[0] 的空间；
2. 用 ht[1] 来代替 ht[0] ，使原来的 ht[1] 成为新的 ht[0] ；
3. 创建一个新的空哈希表，并将它设置为 ht[1] ；
4. 将字典的 rehashidx 属性设置为 -1 ，标识 rehash 已停止；
渐进式rehash-->
rehash 程序并不是在激活之 后就马上执行直到完成的，而是分多次、渐进式地完成的。
假设这样一个场景：在一个有很多键值对的字典里，某个用户在添加新键值对时触发了 rehash 过程，如果这个 rehash 过程必须将所有键值对迁移完毕之后才将结果返回给用户，这样的处理 方式将是非常不友好的。
另一方面，要求服务器必须阻塞直到 rehash 完成，这对于 Redis 服务器本身也是不能接受的。
为了解决这个问题，Redis 使用了渐进式（incremental）的 rehash 方式：通过将 rehash 分散 到多个步骤中进行，从而避免了集中式的计算。 渐进式 rehash 主要由 _dictRehashStep 和 dictRehashMilliseconds 两个函数进行：
• _dictRehashStep 用于对数据库字典、以及哈希键的字典进行被动 rehash ；
• dictRehashMilliseconds 则由 Redis 服务器常规任务程序（server cron job）执行，用 于对数据库字典进行主动 rehash ；
_dictRehashStep
每次执行 _dictRehashStep ，ht[0]->table 哈希表第一个不为空的索引上的所有节点就会全 部迁移到 ht[1]->table
在 rehash 开始进行之后（d->rehashidx 不为 -1），每次执行一次添加、查找、删除操作， _dictRehashStep 都会被执行一次
因为字典会保持哈希表大小和节点数的比率在一个很小的范围内，所以每个索引上的节点数量 不会很多（从目前版本的 rehash 条件来看，平均只有一个，最多通常也不会超过五个），所以 在执行操作的同时，对单个索引上的节点进行迁移，几乎不会对响应时间造成影响
dictRehashMilliseconds
dictRehashMilliseconds 可以在指定的毫秒数内，对字典进行 rehash 。 当 Redis 的服务器常规任务执行时，dictRehashMilliseconds 会被执行，在规定的时间内， 尽可能地对数据库字典中那些需要 rehash 的字典进行 rehash ，从而加速数据库字典的 rehash 进程（progress）
在哈希表进行 rehash 时，字典还会采取一些特别的措施，确保 rehash 顺利、正确地进行：
• 因为在 rehash 时，字典会同时使用两个哈希表，所以在这期间的所有查找、删除等操作， 除了在 ht[0] 上进行，还需要在 ht[1] 上进行
• 在执行添加操作时，新的节点会直接添加到 ht[1] 而不是 ht[0] ，这样保证 ht[0] 的节 点数量在整个 rehash 过程中都只减不增
字典的收缩-->
如果哈希表的 可用节点数比已用节点数大很多的话，那么也可以通过对哈希表进行 rehash 来收缩（shrink） 字典
收缩 rehash 和上面展示的扩展 rehash 的操作几乎一样，它执行以下步骤：
1. 创建一个比 ht[0]->table 小的 ht[1]->table ；
2. 将 ht[0]->table 中的所有键值对迁移到 ht[1]->table ；
3. 将原有 ht[0] 的数据清空，并将 ht[1] 替换为新的 ht[0] ；
1 //字典的收缩规则 2 3 //检查字典的使用率是否低于系统允许的最小比率，是返回1，否则返回0 4 int htNeedsResize(dict *dict) { 5 long long size, used; 6 7 //哈希表已用节点数量 8 size = dictSlots(dict); 9 10 //哈希表大小 11 used = dictSize(dict); 12 13 //当哈希表的大小大于DICT_HT_INITIAL_SIZE并且字典的填充率低于REDIS_HT_MINFILL时返回1 14 return (size && used &&size > DICT_HT_INITIAL_SIZE && 15 (used*100/size < REDIS_HT_MINFILL)); 16 }
在默认情况下，REDIS_HT_MINFILL 的值为 10 ，也即是说，当字典的填充率低于 10% 时，程 序就可以对这个字典进行收缩操作了。
字典收缩和字典扩展的一个区别是：
• 字典的扩展操作是自动触发的（不管是自动扩展还是强制扩展）；
• 而字典的收缩操作则是由程序手动执行
字典的迭代-->
对字典进行迭代实际上就是对字典所使用的哈希表进行迭代：
• 迭代器首先迭代字典的第一个哈希表，然后，如果 rehash 正在进行的话，就继续对第二 个哈希表进行迭代。
• 当迭代哈希表时，找到第一个不为空的索引，然后迭代这个索引上的所有节点。
• 当这个索引迭代完了，继续查找下一个不为空的索引，如此循环，一直到整个哈希表都迭 代完为止。
#迭代过程伪码
1 def iter_dict(dict): 2 3 #迭代0号哈希表 4 iter_table(ht[0]->table) 5 6 #如果正在执行rehash，那么也迭代1号哈希表 7 if dict.is_rehashing(): 8 iter_table(ht[1]->table) 9 10 def iter_table(table): 11 12 #遍历哈希表上的所有索引 13 for index in table: 14 15 #跳过空索引 16 if table[index].empty(): 17 continue 18 19 #遍历索引上的所有节点 20 for node in table[index]: 21 #处理节点 22 do_something_with(node)
字典的迭代器有两种：
• 安全迭代器：在迭代进行过程中，可以对字典进行修改。
• 不安全迭代器：在迭代进行过程中，不对字典进行修改。
1 //迭代器的数据结构定义 2 typedef struct dictIterator { 3 dict *d; //正在迭代的字典 4 5 int table, //正在迭代的哈希表的号码（0或者1） 6 index, //正在迭代的哈希表数组的索引 7 safe; //是否安全 8 9 dictEntry *entry, //当前哈希节点 10 *nextEntry; //当前哈希节点的后继节点 11 } dictIterator;
• 字典由键值对构成的抽象数据结构。
• Redis 中的数据库和哈希键都基于字典来实现。
• Redis 字典的底层实现为哈希表，每个字典使用两个哈希表，一般情况下只使用 0 号哈希 表，只有在 rehash 进行时，才会同时使用 0 号和 1 号哈希表。
• 哈希表使用链地址法来解决键冲突的问题。
• Rehash 可以用于扩展或收缩哈希表。
• 对哈希表的 rehash 是分多次、渐进式地进行的。
4、跳表
跳跃表（skiplist）是一种随机化的数据，这种数据结构以有序的方式在层次化的链表中保存元素，它的效率可以和平衡树媲美——查找、删除、添加等操作都可以在对数期望时间下完成， 并且比起平衡树来说，跳跃表的实现要简单直观得多。
跳表的构成-->
表头head ：负责维护跳表的节点指针
跳表节点：保存着元素值，以及多个层
层：保存着指向其他元素的指针。高层的指针越过的元素数量大于等于底层的指针，为了提高查找的效率，程序总是从高层先开始访问，然后随着元素值范围的缩小，慢慢降低层次
表尾：全部由NULL组成，表示跳表的末尾
Redis对跳表的修改：
允许重复的score值：多个不同的member的score值可以相同
进行对比操作时，不仅要检查score值，还要检查member：当score值可以重复时，单靠score值无法判断一个元素的身份，所以需要连member域都一并检查才行
每个节点都带有一个高度为1层的后退指针，用于从表尾方向向表头方向迭代：当执行ZREVRANGE或ZREVRANGEBYSCORE这类以逆序处理有序集的命令时，就会用到这个属性
1 //跳表 2 typedef struct zskiplist { 3 4 //头节点，尾节点 5 struct zskiplistNode *head, *tail; 6 7 //节点数量 8 unsigned long length; 9 10 //目前表内节点的最大层数 11 int level; 12 } zskiplist; 13 14 //跳表的节点 15 typedef struct zskiplistNode { 16 17 //member对象 18 robj *obj; 19 20 //分值 21 double score; 22 23 //后退指针 24 structzskiplistNode *backward; 25 26 //层 27 struct zskiplistLevel { 28 //前进指针 29 struct zskiplistNode *forward; 30 31 //这个层跨越的节点数量 32 unsigned int span; 33 } level[]; 34 } zskiplistNode;
应用-->
跳跃表在 Redis 的唯一作用，就是实现有序集数据类型。 跳跃表将指向有序集的 score 值和 member 域的指针作为元素，并以 score 值为索引，对有序集元素进行排序。
• 跳跃表是一种随机化数据结构，它的查找、添加、删除操作都可以在对数期望时间下完成。
• 跳跃表目前在 Redis 的唯一作用就是作为有序集类型的底层数据结构（之一，另一个构 成有序集的结构是字典）。
• 为了适应自身的需求，Redis 跳跃表进行了修改，包括：
1. score 值可重复。
2. 对比一个元素需要同时检查它的 score 和 memeber 。
3. 每个节点带有高度为 1 层的后退指针，用于从表尾方向向表头方向迭代。
标签：stl 多次 color imp 地址 特征 完成 def 其他
原文地址：https://www.cnblogs.com/liushoudong/p/12885954.html
