字符串
SDS（Simple Dynamic String）是一个带长度信息的字节数组
struct SDS<T> {
T capacity; // 数组容量
T len; // 数组长度
byte flags； // 特殊标识
byte[] content; // 数组内容
}
content里存储了真正的字符串内容，类似于Java的ArrayList结构，需要比实际内容长度多分配一些冗余空间，capacity表示所分配数组的长度，len表示字符串的实际长度。字符串是可以修改的，要支持append操作，如果数组没有冗余空间，那么追加操作必然涉及到分配新数组，将旧内容复制，append新内容，如果字符串长度很长，这样分配和复制开销就会很大。
/* Append the specified binary-safe string pointed by 't' of 'len' bytes to the * end of the specified sds string 's'.
*
* After the call, the passed sds string is no longer valid and all the
* references must be substituted with the new pointer returned by the call. */ sds sdscatlen(sds s, const void *t, size_t len) {
size_t curlen = sdslen(s); // 原字符串长度
// 按需调整空间，如果 capacity 不够容纳追加的内容，就会重新分配字节数组并复制原字 符串的内容到新数组中
s = sdsMakeRoomFor(s,len);
if (s == NULL) return NULL; // 内存不足
memcpy(s+curlen, t, len); // 追加目标字符串的内容到字节数组中
sdssetlen(s, curlen+len); // 设置追加后的长度值
s[curlen+len] = ' '; // 让字符串以 结尾，便于调试打印，还可以直接使用 glibc 的字符串
函数进行操作
return s; }
为什么使用泛型T而不使用int，因为字符串较短时，len和capacity可以用byte和short表示，对内存做了极致优化，不同长度的字符串可以使用不同的结构体表示。
redis规定字符串的长度不得超过512M，创建字符串时，len和capacity一样长，不会分配冗余空间，因为绝大多数场景不会修改字符串。
embstr vs raw
127.0.0.1:6379> set str abcdefghijklmnopqrstuvwxyz012345678912345678
OK
127.0.0.1:6379> debug object str
Value at:0x7fb20e50d8d0 refcount:1 encoding:embstr serializedlength:45 lru:11843071 lru_seconds_idle:8
127.0.0.1:6379> set codehole abcdefghijklmnopqrstuvwxyz0123456789123456789
OK
127.0.0.1:6379> debug object codehole
Value at:0x7fb20f90b690 refcount:1 encoding:raw serializedlength:46 lru:11843088 lru_seconds_idle:5
所有的redis对象都有下面这个结构头
struct RedisObject {
int4 type; // 4bits
int4 encoding; // 4bits
int24 lru; // 24bits
int32 refcount; // 4bytes
void *ptr; // 8bytes，64-bit system
} robj;
不同的对象具有不同的类型 type(4bit)，同一个类型的 type 会有不同的存储形式 encoding(4bit)，为了记录对象的 LRU 信息，使用了 24 个 bit 来记录 LRU 信息。每个对 象都有个引用计数，当引用计数为零时，对象就会被销毁，内存被回收。ptr 指针将指向对 象内容 (body) 的具体存储位置。这样一个 RedisObject 对象头需要占据 16 字节的存储空 间。
SDS对象头最少时19（16+3）字节
struct SDS {
int8 capacity; // 1byte
int8 len; // 1byte
int8 flags; // 1byte
byte[] content; // 内联数组，长度为 capacity
}
而内存分配器 jemalloc/tcmalloc 等分配内存大小的单位都是 2、4、8、16、32、64 等 等，为了能容纳一个完整的 embstr 对象，jemalloc 最少会分配 32 字节的空间，如果字符 串再稍微长一点，那就是 64 字节的空间。如果总体超出了 64 字节，Redis 认为它是一个 大字符串，不再使用 emdstr 形式存储，而该用 raw 形式。
SDS 结构体中的 content 中的字符串是以字节 结尾的字符串，之所以 多出这样一个字节，是为了便于直接使用 glibc 的字符串处理函数，以及为了便于字符串的 调试打印输出。
看上面这张图可以算出，留给 content 的长度最多只有 45(64-19) 字节了。字符串又是
以 结尾，所以 embstr 最大能容纳的字符串长度就是 44。
扩容策略
字符串在长度小于 1M 之前，扩容空间采用加倍策略，也就是保留 100% 的冗余空 间。当长度超过 1M 之后，为了避免加倍后的冗余空间过大而导致浪费，每次扩容只会多分 配 1M 大小的冗余空间。
字典
dict内部结构
dict结构内层包含两个hashtable，通常只有一个hashtable有值，但是在dict扩容缩容时，需要分配新的hashtable，然后进行渐进式搬迁，搬迁完毕后，旧的hashtable被删除。
hashtable几乎和java重的hashmap数据结构一样，数组+链表。
查找过程
元素是在第二维的链表上，首先找出元素对应的链表。
func get(key){
let index = hash_func(key)%size;
let entry = table[index];
while(entry != null){
if entry.key = target{
return entry.value;
}
entry = entry.next;
}
}
hash_func，会将key映射为一个整数，不同的key会被映射成分布均匀的散乱整数，只有hash值均匀了，整个hashtable才是平衡的，所有的二维链表的长度就不会差很远，比较稳定。
扩容条件
正常情况下，当 hash 表中元素的个数等于第一维数组的长度时，就会开始扩容，扩容 的新数组是原数组大小的 2 倍。不过如果 Redis 正在做 bgsave，为了减少内存页的过多分 离 (Copy On Write)，Redis 尽量不去扩容 (dict_can_resize)，但是如果 hash 表已经非常满 了，元素的个数已经达到了第一维数组长度的 5 倍 (dict_force_resize_ratio)，说明 hash 表 已经过于拥挤了，这个时候就会强制扩容。
缩容条件
当 hash 表因为元素的逐渐删除变得越来越稀疏时，Redis 会对 hash 表进行缩容来减少
hash 表的第一维数组空间占用。缩容的条件是元素个数低于数组长度的 10%。缩容不会考 虑 Redis 是否正在做 bgsave。
集合
Redis里面set的的结构底层实现也是字典，只不过所有的value都是null，其他特性和字典一样。
127.0.0.1:6379> sadd country china japan usa
(integer) 3
127.0.0.1:6379> debug object country
Value at:0x7fb20e60d3f0 refcount:1 encoding:hashtable serializedlength:17 lru:12015767 lru_seconds_idle:9