自从前段时间，工作重心从java转向了偏运维方面的工作（搭建公司内部的一套监控系统），我寻思着这套系统从打造到完善可能还需要经过很长一段过程，这段时间对微服务的后端一些技术应该是接触不到了，既然开辟了新的方向，但是老的知识也不能丢掉，在与后端分离的这段日子，我要好好整理一些知识点，千万不能让时间把技能给冲刷掉，开个坑，把钱文品的这本redis深度历险再看一遍，记录一下重点的知识，以后万一面试也用得到，不至于被面试官问的太狼狈。

基本数据类型

redis的基本数据类型总共有5种：string（字符串）、list（列表）、hash（字典）、set（集合）、zset（有序集合）。
redis内部存储的格式粗略来看就相当于是java中的一个HashMap，这5种数据类型说的是这个HashMap中的value，每个value必须有一个key与之对应。

String

String和Java中的ArrayList比较类似，说白了就是一个字符型数组，都会在创建时申请一块固定长度的内存区域，当长度不够时进行扩容，字符串长度小于1MB时，当前容量*2+1byte（最后一个字节保存’\0’），字符串长度大于1MB时，每次扩容1MB+1byte，最大512MB。

> set name aaa
> get name
"aaa"
> expire name 5 #5s过期 
> setnx name bbb # 如果 name 不存在就执行 set 创建
(integer) 0 #存在

当然，如果value是个整数，redis还能对它进行数值运算。

> set name 1
OK
> incr name 
(integer) 2
> incrby name 3
(integer) 5

源码

String的字符串叫做简单动态字符串（simple dynamic string，SDS），其内部结构为：

struct SDS<T> {
  T capacity; // 数组容量 （泛型是为了减少内存使用空间，一般用int，长度小的时候可以使用byte和short）
  T len; // 数组长度 
  byte flags; // 特殊标识位，跟redis的对象头有关，不用关心
  byte[] content; // 数组内容，真正存放数据的地方
}

string

当然，对于一个redis对象来讲，String内部有两种存储结构embstr（embeded）和raw。要熟悉这两种结构，首先我们先了解一下一个Redis对象的这个头结构，不管是什么数据类型，它们都会有这样一个结构。

struct RedisObject {
    int4 type; // 4bits 数据类型
    int4 encoding; // 4bits 编码方式 
    int24 lru; // 24bits 跟淘汰策略相关，记录最后一次访问时间
    int32 refcount; // 4bytes 引用计数（学过jvm的都懂吧，计数为零，代表没有对象引用，可以被销毁）
    void *ptr; // 8bytes，64-bit system *代表指针（大学的噩梦），在这里指向SDS
} 

struct SDS {
    int8 capacity; // 最小1byte
    int8 len; // 最小1byte
    int8 flags; // 最小1byte
    byte[] content; // 内联数组，长度为 capacity
}

然后，我们再看一下这两种结构的内存分配策略（embstr中，RedisObject和SDS对象连续存储；raw中是不连续的）：

内存分配

之后，大家需要知道，Redis的内存分配器每次分配的单位都是 2/4/8/16/32/64 byte ，也就是说，最多可一次分配64byte的连续内存空间，当RedisObject和SDS对象大小相加不超过64byte时采用embstr存储格式，反之，则采用raw格式。
最后，有兴趣的朋友可以算一下，以embstr结构存储的SDS中最大的content长度是多少？（长度在上面的代码中已有提示，且由于C语言的特性，content最后一位必须要以’\0’结尾，答案44byte，看能不能凑出来）