Redis设计与实现总结

结构

结构

结构

扩容或收缩操作

对ht[0]中所有键值对rehash到ht[1]中

释放ht[0]，将ht[1]置为ht[0]，并在ht[1]新创建一个空的哈希表

负载因子公式：load_factor= ht[0].used / ht[0].size

扩展

收缩

联想到 JDK 的HashMap 中关于索引值的重新计算问题。

总结：得益于 HashMap 规定哈希桶的容量为 2的n次方，还有扩容时新数组的容量是旧数组容量的2倍，首先保证了可以使用位运算，然后，新数组的容量永远是旧数组的二进制左移一位，不管是n还是n-1。
所以可以利用高位运算（hash & oldCap == 0 ？）来判断元素是否需要移动，省去每个元素都要重新计算数组索引。
如果高位运算的结果是0，则表示扩展前后的索引值是一样的（newIndex = oldIndex）。
如果高位运算的结果是1，则扩展后索引值等于扩展前索引值+旧哈希表容量（newIndex = oldIndex + oldCap）

header：指向跳跃表的表头节点

tail：指向跳跃表的表尾节点

level：记录目前跳跃表内，层数最大的那个节点的层数（表头节点的层数不计算在内）

length：记录跳跃表的长度，也就是，跳跃表目前包含节点的数量（表头节点不计算在内）

层（level）：节点中用L1、L2、L3等字样标记节点的各个层，L1代表第一层，L2代表第二层，以此类推。每个层都带有两个属性：前进指针(struct zskiplistNode *forward)和跨度(unsigned int span)。

后退（backward）指针：它指向位于当前节点的前一个节点。后退指针在程序从表尾向表头遍历时使用。

分值（score）：是一个 double 类型的浮点数，在跳跃表中，节点按各自所保存的分值从小到大排列。

成员对象（obj）：是一个指针，它指向一个字符串对象，而字符串对象则保存着一个 SDS 值

uint32_t encoding：编码方式

uint32_t length：集合包含的元素数量

int8_t contents：保存元素的数组

根据新元素的类型，扩展整数集合底层数组的空间大小（空间重分配），并为新元素分配空间。

将底层数组现有的所有元素都转换成与新元素相同的类型，并将类型转换后的元素放置到正确的位上，而且在放置元素的过程中，需要继续维持底层数组的有序性质不变。

将新元素添加到底层数组里面。

将 intset 的 encoding 属性改成对应元素类型的值。例如从 INTSET_ENC_INT16 改成 INTSET_ENC_INT32。

修改 inset 的 length 属性。例如从 4 改成 5。

因为引发升级的新元素的长度总是比整数集合现有所有元素的长度都大，所以这个新元素的值要么就大于所有现有元素，要么就小于所有现有元素

在新元素小于所有现有元素的情况下，新元素会被放置在底层数组的最开头（索引0）

在新元素大于所有现有元素的情况下，新元素会被放置在底层数组的最末尾（索引length-1）

长度小于等于63（2^6–1）字节的字节数组

长度小于等于16383（2^14–1）字节的字节数组

长度小于等于4294967295（2^32–1）字节的字节数组

4位长，介于0至12之间的无符号整数

1字节长的有符号整数

3字节长的有符号整数

int16_t类型整数

int32_t类型整数

int64_t类型整数

int<var> prevlen：

int<var> encoding：

optional byte[] content：

由于每个节点的 previous_entry_length 属性是记录前一个节点的长度的，而这个属性的所需要的空间是根据前一个节点的长度来判断的。

如果前一节点的长度小于254字节，那么 previous_entry_length 属性需要用1字节长的空间来保存这个长度值

如果前一节点的长度大于等于254字节，那么 previous_entry_length 属性的长度为5字节：其中属性的第一字节会被设置为0xFE（十进制值254），而之后的四个字节则用于保存前一节点的长度。

假如压缩列表有连续多个长度介于 250 至 253字节的节点

此时，一个长度大于 254 的大节点插入到表头，那么后面的所有节点都需要更新自己的 previous_entry_length 属性了。

当然了，尽管新增节点可能导致连锁更新操作，但是这个几率还是比较低。而且，本来压缩列表就是用来存放节点数比较少的情况下的，所以少量节点的连锁更新还是不会太过于影响压缩列表的性能的。

REDIS_STRUBG：字符串对象

REDIS_LIST：列表对象

REDIS_HASH：哈希对象

REDIS_SET：集合对象

REDIS_ZSET：有序集合对象

REDIS_ENCODING_INT：Long 类型的整数

REDIS_ENCODING_EMBSTR：embstr 编码的简单动态字符串

REDIS_ENCODING_RAW：简单动态字符串

REDIS_ENCODING_HT：字典

REDIS_ENCODING_LINKEDLIST：双端链表

REDIS_ENCODING_ZIPLIST：压缩列表

REDIS_ENCODING_INTSET：整数集合

REDIS_ENCODING_SKIPLIST：跳跃表和字典

int、embstr或者raw

如果一个字符串对象保存的是整数值，并且这个整数值可以用 long 类型来表示，那么字符串对象会将整数值保存在字符串对象结构的 ptr 属性里面（将 void* 转换成 long），并将字符串对象的编码设置为 int（encoding = REDIS_ENCODING_INT）。

如果字符串对象保存的是一个字符串值，并且这个字符串值的长度小于等于32字节，那么字符串对象将使用embstr编码的方式来保存这个字符串值。

如果字符串对象保存的是一个字符串值，并且这个字符串值的长度大于32字节，那么字符串对象将使用一个简单动态字符串（SDS）来保存这个字符串值，并将对象的编码设置为raw。

embstr 编码 和 raw 编码的区别

embstr 编码的好处

最后要说的是，可以用long double类型表示的浮点数在Redis中也是作为字符串值来保存的。如果我们要保存一个浮点数到字符串对象里面，那么程序会先将这个浮点数转换成字符串值，然后再保存转换所得的字符串值。

可以用 long 类型保存的整数，编码为 int

可以用 long double 类型保存的浮点数，编码为 embstr 或 raw

字符串值，或者因为长度太大而无法用 long 类型表示的整数，又或者因为长度太大而无法用 long double 类型表示的浮点数，编码为 embstr 或 raw

int 转 raw：当利用 append 命令往整数后面添加字符串，那么字符串对象的编码将从 int 变为 raw。

embstr 转 raw：embstr 编码的字符串对象实际上是只读的。当我们调用修改命令（如 append）时，会先将对象的编码从 embstr 转为 raw，然后再执行修改命令。

可以是 ziplist 或者 linkedlist

ziplist编码的列表对象使用压缩列表作为底层实现，每个压缩列表节点（entry）保存了一个列表元素。
压缩列表节点的组成部分包括：prevlength、encoding、content[]

linkedlist编码的列表对象使用双端链表作为底层实现，每个双端链表节点（node）都保存了一个字符串对象，而每个字符串对象都保存了一个列表元素

使用 ziplist 编码的两个条件

不能满足这两个条件的列表对象需要使用linkedlist编码

可以是ziplist或者hashtable

ziplist 编码

hashtable 编码

使用 ziplist 编码的两个条件

不能满足这两个条件的哈希对象需要使用hashtable编码

可以是 intset 或者 hashtable

intset 编码

hashtable 编码

使用 intset 编码的两个条件

不能满足这两个条件的集合对象需要使用hashtable编码

可以是 ziplist 或者 skiplist

ziplist 编码

skiplist 编码

为什么同时使用跳跃表和字典？

使用 ziplist 编码的两个条件

不能满足以上两个条件的有序集合对象将使用skiplist编码

DEL、EXPIRE、RENAME、TYPE、OBJECT等等

SET、GET、APPEND、STRLEN等命令只能对字符串键执行

HDEL、HSET、HGET、HLEN等命令只能对哈希键执行

RPUSH、LPOP、LINSERT、LLEN等命令只能对列表键执行

SADD、SPOP、SINTER、SCARD等命令只能对集合键执行

ZADD、ZCARD、ZRANK、ZSCORE等命令只能对有序集合键执行

如果共享对象是保存整数值的字符串对象，那么验证操作的复杂度为O（1）

如果共享对象是保存字符串值的字符串对象，那么验证操作的复杂度为O（N）

如果共享对象是包含了多个值（或者对象的）对象，比如列表对象或者哈希对象，那么验证操作的复杂度将会是O（N 2）

函数每次运行时，都从一定数量的数据库中取出一定数量的随机键进行检查，并删除其中的过期键。

全局变量current_db会记录当前activeExpireCycle函数检查的进度，并在下一次activeExpireCycle 函数调用时，接着上一次的进度进行处理。

随着 activeExpireCycle 函数的不断执行，服务器中的所有数据库都会被检查一遍，这时函数将current_db变量重置为0，然后再次开始新一轮的检查工作。

函数的type参数是当前想要发送的通知的类型，程序会根据这个值来判断通知是否就是服务器配置notify-keyspace-events选项所选定的通知类型，从而决定是否发送通知。

event、keys和dbid分别是事件的名称、产生事件的键，以及产生事件的数据库号码，函数会根据type参数以及这三个参数来构建事件通知的内容，以及接收通知的频道名。

每当一个Redis命令需要发送数据库通知的时候，该命令的实现函数就会调用notify-KeyspaceEvent函数，并向函数传递传递该命令所引发的事件的相关信息。

先根据notify-keyspace-events 判断，看给定的通知类型 type 是否允许发送通知，如果不允许则直接返回，不做任何操作。

如果允许发送，则检测服务器是否允许发送键空间通知，如果允许，则构建频道名称并发送事件通知

最后，函数还会检测服务器是否允许发送键事件通知，如果允许的话，则构建频道名称并发送事件通知

dirty计数器记录距离上一次成功执行SAVE命令或者BGSAVE命令之后，服务器对数据库状态（服务器中的所有数据库）进行了多少次修改（包括写入、删除、更新等操作）

lastsave属性是一个UNIX时间戳，记录了服务器上一次成功执行SAVE命令或者BGSAVE命令的时间。

ps：如果使用 sadd 往集合里面一次添加三个元素，dirty计数器的值会增加3。

如果服务器的数据库状态为空（所有数据库都是空的），那么这个部分也为空，长度为0字节

如果服务器的数据库状态为非空（有至少一个数据库非空），那么这个部分也为非空，根据数据库所保存键值对的数量、类型和内容不同，这个部分的长度也会有所不同。

一个8字节长的无符号整数，保存着一个校验和

这个校验和是程序通过对REDIS、db_version、databases、EOF四个部分的内容进行计算得出的

服务器在载入RDB文件时，会将载入数据所计算出的校验和与check_sum所记录的校验和进行对比，以此来检查RDB文件是否有出错或者损坏的情况出现

TYPE key value

EXPIRETIME_MS ms TYPE key value

REDIS_RDB_TYPE_STRING

REDIS_RDB_TYPE_LIST

REDIS_RDB_TYPE_SET

REDIS_RDB_TYPE_ZSET

REDIS_RDB_TYPE_HASH

REDIS_RDB_TYPE_LIST_ZIPLIST

REDIS_RDB_TYPE_SET_ZIPLIST

REDIS_RDB_TYPE_ZSET_ZIPLIST

REDIS_RDB_TYPE_HASH_ZIPLIST

TYPE 的值为REDIS_RDB_TYPE_STRING，字符串对象的编码可以是REDIS_ENCODING_INT或者REDIS_ENCODING_RAW。

字符串对象编码是 REDIS_ENCODING_INT，那么字符串对象在 RDB 文件保存的结构为 "ENCODING integer"

字符串对象编码是 REDIS_ENCODING_RAW

如果TYPE 的值为 REDIS_RDB_TYPE_LIST，那么 value 保存的就是一个 REDIS_ENCODING_LINKEDLIST 编码的列表对象

RDB 文件保存的结构为："list_length item1 item2 ... itemN"

如果TYPE 的值为 REDIS_RDB_TYPE_SET，那么 value 保存的就是一个 REDIS_ENCODING_HT 编码的集合对象

RDB 文件保存的结构为："set_size elem1 elem2 ... elemN"

如果TYPE的值为REDIS_RDB_TYPE_HASH，那么value保存的就是一个REDIS_ENCODING_HT编码的集合对象

RDB 文件保存的结构为："hash_size key_value_pair1 key_value_pair2 ... key_value_pairN"

如果TYPE的值为REDIS_RDB_TYPE_ZSET，那么value保存的就是一个REDIS_ENCODING_SKIPLIST编码的有序集合对象

RDB 文件保存的结构为："sorted_set_size element1 element2 ... elementN"

如果TYPE的值为REDIS_RDB_TYPE_SET_INTSET，那么value保存的就是一个整数集合对象

RDB文件保存这种对象的方法是，先将整数集合转换为字符串对象，然后将这个字符串对象保存到RDB文件里面

如果程序在读入RDB文件的过程中，碰到由整数集合对象转换成的字符串对象，那么程序会根据TYPE值的指示，先读入字符串对象，再将这个字符串对象转换成原来的整数集合对象。

如果TYPE的值为REDIS_RDB_TYPE_LIST_ZIPLIST、REDIS_RDB_TYPE_HASH_ZIPLIST或者REDIS_RDB_TYPE_ZSET_ZIPLIST，那么value保存的就是一个压缩列表对象

RDB 文件保存这种对象的方法：

如果程序在读入RDB文件的过程中，碰到由压缩列表对象转换成的字符串对象，那么程序会根据TYPE值的指示，执行以下操作：

写命令：SET MSG HELLO

Redis 命令请求协议内容：*3\r\n$3\r\nSET\r\n$3\r\nMSG\r\n$5\r\nzHELLO\r\n

协议内容详解

always：将 aof_buf 缓存区中的所有内容写入并同步到 AOF 文件

everysec：将 aof_buf 缓冲区中的所有内容写入到 AOF 文件，如果此时距离上次同步已经超过一秒，那么继续对 AOF 文件进行同步，并且这个同步操作是由一个线程专门负责执行的。

no：将 aof_buf 缓冲区中的所有内容写入 AOF 文件中，但并不对 AOF 文件进行同步，何时同步由操作系统来决定。

为了提高文件的写入效率，在现代操作系统中，当用户调用write函数，将一些数据写入到文件的时候，操作系统通常会将写入数据暂时保存在一个内存缓冲区里面，等到缓冲区的空间被填满、或者超过了指定的时限之后，才真正地将缓冲区中的数据写入到磁盘里面。

这种做法虽然提高了效率，但也为写入数据带来了安全问题，因为如果计算机发生停机，那么保存在内存缓冲区里面的写入数据将会丢失。

为此，系统提供了fsync和fdatasync两个同步函数，它们可以强制让操作系统立即将缓冲区中的数据写入到硬盘里面，从而确保写入数据的安全性。

当Redis服务器执行完一个写命令之后，它会同时将这个写命令发送给AOF缓冲区和AOF重写缓冲区

当子进程完成 AOF 重写工作后，会向主进程发送一个信号，主进程在接到该信号后，会调用一个信号处理函数，并执行以下工作。

1）将AOF重写缓冲区中的所有内容写入到新AOF文件中，这时新AOF文件所保存的数据库状态将和服务器当前的数据库状态一致。

2）对新的AOF文件进行改名，原子地（atomic）覆盖现有的AOF文件，完成新旧两个AOF文件的替换。

ps：信号函数执行会对主进程造成阻塞，其他的不会。

负责监听多个套接字，并向文件事件分派器传送那些产生了事件的套接字。

I/O多路复用程序，利用队列来控制产生事件的套接字的并发；队列中的套接字以有序、同步、每次一个的方式分派给文件事件分派器。

当一个套接字的事件被处理完了，I/O多路复用程序才会接着给文件事件分派器传送下一个队列中的套接字。

更新服务器的各类统计信息，比如时间、内存占用、数据库占用情况等。

清理数据库中的过期键值对。

关闭和清理连接失效的客户端。

尝试进行AOF或RDB持久化操作。

如果服务器是主服务器，那么对从服务器进行定期同步。

如果处于集群模式，对集群进行定期同步和连接测试。

客户端状态的输入缓冲区用于保存客户端发送的命令请求
ps：保存的格式就是 Redis 的命令请求协议

输入缓冲区的大小会根据输入内容动态地缩小或者扩大，但它的最大大小不能超过1GB，否则服务器将关闭这个客户端。

每个客户端都有两个输出缓冲区可用，一个缓冲区的大小是固定的，另一个缓冲区的大小是可变的

客户端的固定大小缓冲区由buf和bufpos两个属性组成.
buf是一个大小为REDIS_REPLY_CHUNK_BYTES字节的字节数组，而bufpos属性则记录了buf数组目前已使用的字节数量。

可变大小缓冲区由reply链表和一个或多个字符串对象组成。
通过使用链表来连接多个字符串对象，服务器可以为客户端保存一个非常长的命令回复，而不必受到固定大小缓冲区16KB大小的限制。

服务器会在初始化时创建负责执行Lua脚本中包含的Redis命令的伪客户端，并将这个伪客户端关联在服务器状态结构的lua_client属性中

lua_client伪客户端在服务器运行的整个生命期中会一直存在，只有服务器被关闭时，这个客户端才会被关闭。

服务器在载入AOF文件时，会创建用于执行AOF文件包含的Redis命令的伪客户端，并在载入完成之后，关闭这个伪客户端。

检查客户端状态（RedisClient）的 cmd 指针是否为null

根据 cmd 属性指向的 redisCommand结构的 arity 属性，检查命令请求的参数个数是否正确

检查客户端是否通过了身份验证

如果服务器打开了 maxmemory 功能，命令执行前判断内存是否足够

如果服务器上一次执行 BGSAVE 命令失败，并且开启了 stop-writes-on-bgsave-error 功能，则拒绝执行命令

判断客户端此时是否正在用 subscribe 命令订阅频道，如果是，只能执行 subscribe 、 psubscribe 、 unsubscribe、punsubscribe 这四个命令。 

如果服务器正在进行数据载入，那么客户端发送的命令必须带有l标识（比如INFO、SHUTDOWN、PUBLISH等等）才会被服务器执行，其他命令都会被服务器拒绝。

如果服务器因为执行Lua脚本而超时并进入阻塞状态，那么服务器只会执行客户端发来的SHUTDOWN nosave命令和SCRIPT KILL命令，其他命令都会被服务器拒绝。

如果客户端正在执行事务，那么服务器只会执行客户端发来的EXEC、DISCARD、MULTI、WATCH四个命令，其他命令都会被放进事务队列中。

如果服务器打开了监视器功能，那么服务器会将要执行的命令和参数等信息发送给监视器。当完成了以上预备操作之后，服务器就可以开始真正执行命令了。

上面只是单机情况下的检查操作，集群会更多。。。

慢查询日志功能：如果服务器开启了慢查询日志功能，那么慢查询日志模块会检查是否需要为刚刚执行完的命令请求添加一条新的慢查询日志。

命令耗时记录：根据刚刚执行命令所耗费的时长，更新被执行命令的redisCommand结构的milliseconds属性，并将命令的redisCommand结构的calls计数器的值增一。

AOF持久化：如果服务器开启了AOF持久化功能，那么AOF持久化模块会将刚刚执行的命令请求写入到AOF缓冲区里面。

主从复制：如果有其他从服务器正在复制当前这个服务器，那么服务器会将刚刚执行的命令传播给所有从服务器。

Redis 服务器中不少功能是要使用系统的当前时间的，而获取系统当前时间需要执行一次系统调用。

为了减少系统调用，提升性能，服务器状态（redisServer）中的 unixtime 属性和 mstime 属性分别保存了秒级精度的系统当前 UNIX 时间戳和毫秒级精度的系统当前 UNIX 时间戳。

serverCron 函数会每隔 100 毫秒更新一次这两个属性。

ps：这两个时间只会用在对时间精确度要求不高的功能上，例如打印日志、计算服务器上线时间等等。
像设置键过期时间、添加慢查询日志这种需要时间精确度高的功能上，服务器还是会每次都调用系统来获取。

服务器状态中的lruclock属性保存了服务器的LRU时钟；而每个 Redis 对象都会有一个 lru 属性，这个属性记录了对象最后一次被命令访问的时间。

当服务器要计算一个数据库键的空转时间（也即是数据库键对应的值对象的空转时间），程序会用服务器的lruclock属性记录的时间减去对象的lru属性记录的时间，得出的计算结果就是这个对象的空转时间

serverCron函数默认会以每10秒一次的频率更新lruclock属性的值

因为这个时钟不是实时的，所以根据这个属性计算出来的LRU时间实际上只是一个模糊的估算值。

在启动服务器时，Redis会为服务器进程的SIGTERM信号关联处理器sigtermHandler函数，这个信号处理器负责在服务器接到SIGTERM信号时，打开服务器状态的shutdown_asap标识

每次serverCron函数运行时，程序都会对服务器状态的shutdown_asap属性进行检查，并根据属性的值决定是否关闭服务器

1：关闭服务器；0：不做动作

释放长时间与服务器没有互动的客户端

控制客户端的输入缓冲区大小

例如删除过期键

当执行 BGSAVE 时，BGREWRITEAOF 操作会被延迟执行

服务器状态使用rdb_child_pid属性和aof_child_pid属性记录执行BGSAVE命令和BGREWRITEAOF命令的子进程的ID，这两个属性也可以用于检查BGSAVE命令或者BGREWRITEAOF命令是否正在执行

如果其中一个值不为 -1，则检查子进程是否有信号发到服务器进程中

两个值都为 -1

设置服务器的运行ID。

设置服务器的默认运行频率。

设置服务器的默认配置文件路径。

设置服务器的运行架构。

设置服务器的默认端口号。

设置服务器的默认RDB持久化条件和AOF持久化条件。

初始化服务器的LRU时钟。

创建命令表。

initServerConfig函数设置的服务器状态属性基本都是一些整数、浮点数、或者字符串属性，除了命令表之外，initServerConfig函数没有创建服务器状态的其他数据结构，数据库、慢查询日志、Lua环境、共享对象这些数据结构在之后的步骤才会被创建出来。

为服务器设置进程信号处理器。

创建共享对象：这些对象包含Redis服务器经常用到的一些值，比如包含"OK"回复的字符串对象，包含"ERR"回复的字符串对象，包含整数1到10000的字符串对象等等，服务器通过重用这些共享对象来避免反复创建相同的对象。

打开服务器的监听端口，并为监听套接字关联连接应答事件处理器，等待服务器正式运行时接受客户端的连接。

为serverCron函数创建时间事件，等待服务器正式运行时执行serverCron函数。

如果AOF持久化功能已经打开，那么打开现有的AOF文件，如果AOF文件不存在，那么创建并打开一个新的AOF文件，为AOF写入做好准备。

初始化服务器的后台I/O模块（bio），为将来的I/O操作做好准备。

从服务器向主服务器发送 SYNC 命令

主服务器收到 SYNC 命令后，后台生成一个 RDB 文件（BGSAVE），并使用一个缓冲区记录从现在开始执行的所有写命令。

当主服务器的 BGSAVE 命令执行完毕，将生成的 RDB 文件发送给从服务器；从服务器接收并载入这个 RDB 文件。

主服务器将缓冲区里的所有写命令发送给从服务器；从服务器执行这些写命令。

至此，主从服务器两者的数据库将达到一致状态。

主服务器的复制偏移量（replication offset）和从服务器的复制偏移量。

主服务器的复制积压缓冲区（replication backlog）。

服务器的运行ID（run ID）。

主服务器和从服务器会分别维护自己的复制偏移量

主服务器每次向从服务器传播N个字节的数据时，就将自己的复制偏移量的值加上N。

从服务器每次收到主服务器传播来的N个字节的数据时，就将自己的复制偏移量的值加上N。

ps：只要我们对比主从服务器的复制偏移量，就知道主从服务器的数据库状态是否一致。

复制积压缓冲区是由主服务器维护的一个固定长度（fixed-size）先进先出（FIFO）队列，默认大小为1MB。
固定长度先进先出队列的长度是固定的，当入队元素的数量大于队列长度时，最先入队的元素会被弹出，而新元素会被放入队列。

主服务器的复制积压缓冲区里面会保存着一部分最近传播的写命令，并且复制积压缓冲区会为队列中的每个字节记录相应的复制偏移量。

当从服务器重新连上主服务器时，从服务器会通过PSYNC命令将自己的复制偏移量offset发送给主服务器，主服务器会根据这个复制偏移量来决定对从服务器执行何种同步操作。如果偏移量 offset+1 开始的数据仍然存在在复制积压缓冲区，则执行部分重同步操作，否则执行完整重同步操作。

ps：复制积压缓冲区的大小应该根据业务来设置。为了安全起见，可以将复制积压缓冲区的大小设为2*second（从服务器从断线到脸上的平均时间，单位为秒）*write_size_per_second（主服务器平均每秒产生的写命令数据量，协议格式的写命令的长度总和），这样可以保证绝大部分断线情况都能用部分重同步来处理。

每个 Redis 服务器，不管是主还是从，都会有自己的运行ID；运行ID在服务器启动时自动生成，由40个随机的十六进制字符组成。

当从服务器对主服务器进行初次复制时，主服务器会将自己的运行ID传送给从服务器，而从服务器则会将这个运行ID保存起来。

当从服务器断线并重新连上一个主服务器时，从服务器将向当前连接的主服务器发送之前保存的运行ID。
如果从服务器保存的运行ID和当前主服务器的运行ID相同，主服务器尝试执行部分重同步操作；否则，执行完整重同步操作。

如果从服务器以前没有复制过任何主服务器，或者之前执行过SLAVEOF no one命令，那么从服务器在开始一次新的复制时将向主服务器发送PSYNC ? -1命令，主动请求主服务器进行完整重同步（因为这时不可能执行部分重同步）。

相反地，如果从服务器已经复制过某个主服务器，那么从服务器在开始一次新的复制时将向主服务器发送PSYNC ＜runid＞ ＜offset＞命令：其中runid是上一次复制的主服务器的运行ID，而offset则是从服务器当前的复制偏移量，接收到这个命令的主服务器会通过这两个参数来判断应该对从服务器执行哪种同步操作。

如果主服务器返回+FULLRESYNC ＜runid＞ ＜offset＞回复，那么表示主服务器将与从服务器执行完整重同步操作：其中runid是这个主服务器的运行ID，从服务器会将这个ID保存起来，在下一次发送PSYNC命令时使用；而offset则是主服务器当前的复制偏移量，从服务器会将这个值作为自己的初始化偏移量。

如果主服务器返回+CONTINUE回复，那么表示主服务器将与从服务器执行部分重同步操作，从服务器只要等着主服务器将自己缺少的那部分数据发送过来就可以了。

如果主服务器返回-ERR回复，那么表示主服务器的版本低于Redis 2.8，它识别不了PSYNC命令，从服务器将向主服务器发送SYNC命令，并与主服务器执行完整同步操作。

客户端向从服务器发送命令：SLAVEOF <master_ip> <master_port>。

从服务器将命令中的主服务器信息（ip地址和端口号）保存在服务器状态中的 masterhost 属性和 masterport 属性。

ps：SLAVEOF命令是一个异步命令，在完成masterhost属性和masterport属性的设置工作之后，从服务器将向发送SLAVEOF命令的客户端返回OK，表示复制指令已经被接收，而实际的复制工作将在OK返回之后才真正开始执行。

从服务器创建的套接字能成功连接（connect）主服务器后，为套接字关联一个专门用于处理复制工作的文件事件处理器，负责执行后续的负责工作。

主服务器在接受（accept）从服务器的套接字连接后，为该套接字创建对应的客户端状态（redisClient）。从服务器可以发送命令请求，主服务区也可以返回命令回复。

虽然主从服务器成功建立起了套接字连接，但双方并未使用该套接字进行过任何通信，通过发送PING命令可以检查套接字的读写状态是否正常。

因为复制工作接下来的几个步骤都必须在主服务器可以正常处理命令请求的状态下才能进行，通过发送PING命令可以检查主服务器能否正常处理命令请求。

发送 PING 命令后的三种情况

接收 PONG 响应后

从服务器在身份验证阶段可能遇到的情况有以下几种

在身份验证步骤之后，从服务器将执行命令REPLCONF listening-port ＜port-number＞，向主服务器发送从服务器的监听端口号。

主服务器在接收到这个命令之后，会将端口号记录在从服务器所对应的客户端状态的slave_listening_port属性中

完整重同步还是部分重同步

通过主服务器将自己执行的写命令发送给从服务器，保证主从服务器的数据库状态是一致的。

检测主从服务器的网络连接状态

辅助实现min-slaves选项

检测命令丢失

字典的键是由 Sentinel 自动设置的从服务器名字，格式为ip:port：如对于IP地址为127.0.0.1，端口号为11111的从服务器来说，Sentinel为它设置的名字就是127.0.0.1:11111。

字典的值则是从服务器对应的实例结构（也是 sentinelRedisInstance 结构）：比如说，如果键是127.0.0.1:11111，那么这个键的值就是IP地址为127.0.0.1，端口号为11111，名称为"127.0.0.1:11111" 的从服务器的实例结构。

ip：被 Sentinel 判断为主观下线的主服务器的 IP 地址

port：被 Sentinel 判断为主观下线的主服务器的端口号

current_epoch：Sentinel 当前的配置纪元，用于选举领头 Sentinel

runid：可以是 * 符号或者是 Sentinel 的运行ID。* 符号代表命令仅仅用于检测主服务器的客观下线状态，而 Sentinel 的运行 ID 用于选举领头 Sentinel。

1) <down_state>：返回目标 Sentinel 对主服务器的下线检查结果，1 代表已下线，0 代表未下线。

2) <leader_runid>：可以是 * 符号或者目标 Sentinel 的局部领头 Sentinel 的运行 ID。* 符号代表命令仅仅用于检测主服务器的下线状态，而局部领头 Sentinel 的运行 ID 用于选举领头 Sentinel。

3) <leader_epoch>：目标 Sentinel 的局部领头 Sentinel 的配置纪元。用于选举领头 Sentinel。仅在 leader_runid 不为 * 时有效，如果 leader_runid 为 *，那么 leader_epoch 总为0。

领头Sentinel会将已下线主服务器的所有从服务器保存到一个列表里面，然后按照以下规则，一项一项地对列表进行过滤

之后，领头Sentinel将根据从服务器的优先级，对列表中剩余的从服务器进行排序，并选出其中优先级最高的从服务器。

如果有多个具有相同最高优先级的从服务器，那么领头Sentinel将按照从服务器的复制偏移量，对具有相同最高优先级的所有从服务器进行排序，并选出其中偏移量最大的从服务器（复制偏移量最大的从服务器就是保存着最新数据的从服务器）。

最后，如果有多个优先级最高、复制偏移量最大的从服务器，那么领头Sentinel将按照运行ID对这些从服务器进行排序，并选出其中运行ID最小的从服务器。

1、去掉处于下线或断线状态的从服务器

2、去掉最近五秒内没回复过领头 Sentinel 的 INFO 命令的从服务器

3、删除于已下线主服务器连接断开超过 down-after-milliseconds * 10 毫秒的从服务器

4、选择优先级最高的从服务器

5、优先级相等，则选择复制偏移量最大的从服务器

6、优先级和复制偏移量都相等，则选择运行 ID 最小的从服务器

例子

使用文件事件处理器处理命令请求和返回回复。

使用时间处理器执行 serverCron 函数，serverCron 函数会调用集群模式下特有的 clusterCron 函数。
clusterCron 函数主要负责发送 Gossip 消息，检查节点是否断线等等。

使用数据库保存键值对数据。

使用 RDB 和 AOF 持久化。

使用发布订阅模块执行 PUBLISH 和 SUBSCRIBE。

使用复制模块进行节点的复制工作。

使用 Lua 脚本环境来执行 Lua 脚本。

clusterNode：保存了一个节点的当前状态
每个节点里面，还会为集群中其他节点（包括主节点和从节点）的创建对应的 clusterNode 结构。

clusterLink：对应 clusterNode 的 link 属性，保存了连接节点所需要的信息
比如套接字描述符，输入缓冲区和输出缓冲区。

clusterState：在当前节点的视角下，保存了集群目前所处的状态
当然了，集群中每个节点都会有 clusterState 结构。

客户端向节点A发送 CLUSTER MEET 命令，节点A将会与命令中参数对应的节点B进行握手。

步骤

重点：之后，节点A会将节点B的信息通过Gossip协议传播给集群中的其他节点，让其他节点也与节点B进行握手，最终，经过一段时间之后，节点B会被集群中的所有节点认识。

unsigned char slots[16384/8]

int numslots

每个数组项都是一个指向clusterNode结构的指针

如果 slots[i] 指针指向 NULL，那么表示槽i尚未指派给任何节点。

如果 slots[i] 指针指向一个clusterNode结构，那么表示槽i已经指派给了 clusterNode 结构所代表的节点。

clusterState.slots 数组记录了集群中所有槽的指派信息，而 clusterNode.slots 数组只记录了 clusterNode 结构所代表的节点的槽指派信息，这是两个 slots 数组的关键区别所在。

使用 clusterState.slots 是为了方便判断槽是否被指派了，或者判断键所对应的槽被哪个节点负责，此时的复杂度是 0(1)；而如果使用 clusterNode.slots 来判断，那么我们需要遍历整个 clusterState.nodes 字典，此时复杂度是 O(N)，N为 nodes 字典中 clusterNode 的数量。

使用 clusterNode.slots 是为了方便将某个节点的槽指派信息发送给集群中的其他节点，此时只需要将 clusterNode.slots 整个发送出去就可以了；而如果使用 clusterState.slots，则需要遍历整个 clusterState.slots 数组。

节点接收命令后，会先计算出命令要处理的数据库键属于哪个槽

计算算法：CRC16(key) & 16383

我们可以利用 CLUSTER KEYSLOT <key> 命令来查看一个给定键属于哪个槽。当然了，这个命令也是利用上面的算法实现的。

如果 clusterState.slots[i] 等于 clusterState.myself ，那么说明槽i由当前节点负责，节点可以执行客户端发送的命令

如果 clusterState.slots[i] 不等于 clusterState.myself ，那么说明槽 i 并非由当前节点负责，节点会根据 clusterState.slots[i] 指向的 clusterNode 结构所记录的节点 IP 和端口号，向客户端返回 MOVED 错误，指引客户端转向至正在处理槽 i 的节点。

1）redis-trib 对目标节点发送 CLUSTER SETSLOT＜slot＞IMPORTING＜source_id＞命令，让目标节点准备好从源节点导入（import）属于槽slot的键值对。

2）redis-trib 对源节点发送 CLUSTER SETSLOT＜slot＞MIGRATING＜target_id＞ 命令，让源节点准备好将属于槽slot的键值对迁移（migrate）至目标节点。

3）redis-trib 向源节点发送 CLUSTER GETKEYSINSLOT＜slot＞＜count＞ 命令，获得最多count个属于槽slot的键值对的键名（key name）。

4）对于步骤3获得的每个键名，redis-trib 都向源节点发送一个 MIGRATE＜target_ip＞＜target_port＞＜key_name＞0＜timeout＞ 命令，将被选中的键原子地从源节点迁移至目标节点。

5）重复执行步骤3和步骤4，直到源节点保存的所有属于槽slot的键值对都被迁移至目标节点为止。

6）redis-trib 向集群中的任意一个节点发送 CLUSTER SETSLOT＜slot＞NODE＜target_id＞ 命令(Gossip 协议)，将槽 slot 指派给目标节点，这一指派信息会通过消息发送至整个集群，最终集群中的所有节点都会知道槽 slot 已经指派给了目标节点。

clusterState 结构的 importing_slots_from 数组记录了当前节点正在从其他节点导入的槽。

如果 importing_slots_from[i] 的值不为NULL，而是指向一个 clusterNode 结构，那么表示当前节点正在从 clusterNode 所代表的节点导入槽 i。

在对集群进行重分片时，向目标节点发送命令：CLUSTER SETSLOT <i> IMPORTING <source_id>，可以将目标节点 clusterState.importing_slots_from[i] 的值设置为 source_id 所代表节点的 clusterNode 结构。

clusterState结构的migrating_slots_to数组记录了当前节点正在迁移至其他节点的槽

如果 migrating_slots_to[i] 的值不为NULL，而是指向一个 clusterNode 结构，那么表示当前节点正在将槽i迁移至 clusterNode 所代表的节点。

在对集群进行重分片时，向源节点发送命令：CLUSTER SETSLOT <i> MIGRATING <target_id>，可以将目标节点 clusterState.migrating_slots_to[i] 的值设置为 target_id 所代表节点的 clusterNode 结构。

Redis集群中的节点分为主节点（master）和从节点（slave），其中主节点用于处理槽，而从节点则用于复制某个主节点，并在被复制的主节点下线时，代替下线主节点继续处理命令请求。

首先利用命令 CLUSTER MEET <ip> <port> 将一个新节点加入到集群中，此时节点的状态是 REDIS_NODE_MASTER，即此时节点是主节点来的。

然后向新节点发送 CLUSTER REPLICATE <node_id> 命令，将新节点成为 node_id 所指定节点的从节点，并开始对主节点进行复制。此时新节点的状态为 REDIS_NODE_REDIS，即此节点是从节点。

实现

一个节点成为从节点，并开始复制某个主节点这一信息会通过消息发送给集群中的其他节点，最终集群中的所有节点都会知道某个从节点正在复制某个主节点。
集群中的所有节点都会在代表主节点的 clusterNode 结构的 slaves 属性和 numslaves 属性中记录正在复制这个主节点的从节点名单~

集群中的每个节点都会定期地向集群中的其他节点发送 PING 消息，以此来检测对方是否在线，如果接收 PING 消息的节点没有在规定的时间内，向发送 PING 消息的节点返回 PONG 消息，那么发送 PING 消息的节点就会将接收 PING 消息的节点标记为疑似下线（probable fail，PFAIL）。

集群中的各个节点会通过互相发送消息的方式来交换集群中各个节点的状态信息，例如某个节点是处于在线状态、疑似下线状态（PFAIL），还是已下线状态（FAIL）。

实现

1）复制下线主节点的所有从节点里面，会有一个从节点被选中。

2）被选中的从节点会执行SLAVEOF no one命令，成为新的主节点。

3）新的主节点会撤销所有对已下线主节点的槽指派，并将这些槽全部指派给自己。

4）新的主节点向集群广播一条PONG消息，这条PONG消息可以让集群中的其他节点立即知道这个节点已经由从节点变成了主节点，并且这个主节点已经接管了原本由已下线节点负责处理的槽。

5）新的主节点开始接收和自己负责处理的槽有关的命令请求，故障转移完成。

1）集群的配置纪元是一个自增计数器，它的初始值为0。

2）当集群里的某个节点开始一次故障转移操作时，集群配置纪元的值会被增一。

3）对于每个配置纪元，集群里每个负责处理槽的主节点都有一次投票的机会，而第一个向主节点要求投票的从节点将获得主节点的投票。

4）当从节点发现自己正在复制的主节点进入已下线状态时，从节点会向集群广播一条CLUSTERMSG_TYPE_FAILOVER_AUTH_REQUEST消息，要求所有收到这条消息、并且具有投票权的主节点向这个从节点投票。

5）如果一个主节点具有投票权（它正在负责处理槽），并且这个主节点尚未投票给其他从节点，那么主节点将向要求投票的从节点返回一条CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK消息，表示这个主节点支持从节点成为新的主节点。

6）每个参与选举的从节点都会接收CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK消息，并根据自己收到了多少条这种消息来统计自己获得了多少主节点的支持。

7）如果集群里有N个具有投票权的主节点，那么当一个从节点收集到大于等于N/2+1张支持票时，这个从节点就会当选为新的主节点。

8）因为在每一个配置纪元里面，每个具有投票权的主节点只能投一次票，所以如果有N个主节点进行投票，那么具有大于等于N/2+1张支持票的从节点只会有一个，这确保了新的主节点只会有一个。

9）如果在一个配置纪元里面没有从节点能收集到足够多的支持票，那么集群进入一个新的配置纪元，并再次进行选举，直到选出新的主节点为止。

这个选举新主节点的方法和选举领头Sentinel的方法非常相似，因为两者都是基于Raft算法的领头选举（leader election）方法来实现的。

节点发送的所有消息都由一个消息头包裹，消息头除了包含消息正文之外，还记录了消息发送者自身的一些信息，因为这些信息也会被消息接收者用到，所以严格来讲，我们可以认为消息头本身也是消息的一部分。

结构：cluster.h/clusterMsg 
clusterMsg.data 属性就是消息正文，指向 cluster.h/clusterMsgData

clusterMsg结构的currentEpoch、sender、myslots、flags等属性记录了发送者自身的节点信息，接收者会根据这些信息，在自己的clusterState.nodes字典里找到发送者对应的clusterNode结构，并对结构进行更新。

结构：cluster.h/clusterMsgData

实际上，要让集群的所有节点都执行相同的PUBLISH命令，最简单的方法就是向所有节点广播相同的PUBLISH命令，这也是Redis在复制PUBLISH命令时所使用的方法，不过因为这种做法并不符合Redis集群的“各个节点通过发送和接收消息来进行通信”这一规则，所以节点没有采取广播PUBLISH命令的做法。

PUBSUB CHANNELS[pattern] 子命令用于返回服务器当前被订阅的频道，其中 pattern 参数是可选的。

❑如果不给定 pattern 参数，那么命令返回服务器当前被订阅的所有频道。 例如：PUBLISH CHANNEL

❑如果给定 pattern 参数，那么命令返回服务器当前被订阅的频道中那些与 pattern 模式相匹配的频道。例如

1、程序遍历服务器状态（redisServer）的 pubsub_channels 属性（字典）。

2、然后返回那些符合下面判断条件的 channel。判断条件：（命令中的 pattern 为空） or（pattern 不为空并且 channel 与 pattern 匹配）。

伪代码

PUBSUB NUMSUB [channel1 channel2 .... channelN] 子命令可以接受多个频道作为输入参数，然后返回这些频道的订阅者数量。

1、遍历 pubsub_channels 字典，找到所有匹配命令参数的键。

2、然后计算键对应的值的长度（链表长度），来作为频道的订阅者数量。

伪代码

返回服务器当前被订阅模式的数量

实现

❑如果客户端发送的命令为EXEC、DISCARD、WATCH、MULTI四个命令的其中一个，那么服务器立即执行这个命令。

❑与此相反，如果客户端发送的命令是EXEC、DISCARD、WATCH、MULTI四个命令以外的其他命令，那么服务器并不立即执行这个命令。首先检查此命令的格式是否正确，如果不正确就返回错误信息，如果正确将这个命令放入一个事务队列里面，然后向客户端返回QUEUED回复。

每个 Redis 客户端都有自己的事务状态，对应的是客户端状态（redisClient）的 mstate 属性。

事务状态（mstate）包含一个事务队列（FIFO 队列），以及一个已入队命令的计数器。

事务队列是一个 multiCmd 类型数组，数组中每个 multiCmd 结构都保存了一个如入队命令的相关信息。例如指向命令实现函数的指针，命令的参数，以及参数的数量。

事务具有原子性指的是，数据库将事务中的多个操作当作一个整体来执行，服务器要么就执行事务中的所有操作，要么就一个操作也不执行。

Redis 事务执行过程中，如果一个命令执行出错，那么就返回错误，接着继续执行下面的命令。那为什么还说 Redis 事务原子性？请看看下面红色框框的讨论！

Redis的事务和传统的关系型数据库事务的最大区别在于，Redis不支持事务回滚机制（rollback），即使事务队列中的某个命令在执行期间出现了错误，整个事务也会继续执行下去，直到将事务队列中的所有命令都执行完毕为止。
ps：不支持事务回滚是因为这种复杂的功能和Redis追求简单高效的设计主旨不相符。

为什么很多人说 Redis 事务不是原子性？
正是因为 Redis 事务不支持事务回滚机制，如果事务执行中出现了命令执行错误（例如对 String 类型的数据库键执行 LPUSH 操作），只会返回当前命令执行的错误给客户端，并不会影响下面的命令的执行。所以很多人觉得和关系型数据库（MySQL） 不一样，所以认为 Redis 事务不支持原子性。

其实应该这么分析：
首先，他们俩的定位不一样，一个是关系型数据库，一个是 NoSQL。
MySQL 的查询 SQL 是可以相当复杂的，而且MySQL没有事务队列这种说法，SQL 真正开始执行才会进行分析和检查，MySQL 不可能提前知道下一条 SQL 是否正确。所以支持事务回滚是非常有必要的~
但是~ Redis 使用了事务队列来预先将执行命令存储起来，并且会对其进行格式检查的，提前就知道命令是否可执行了。所以 Redis 作者认为基本只会出现在开发环境的编程错误其实在生产环境基本是不可能出现的（例如对 String 类型的数据库键执行 LPUSH 操作），所以他觉得没必要为了这事务回滚机制而改变 Redis 追求简单高效的设计主旨。
所以最后，其实 Redis 事务真正支持原子性的前提：开发者不要傻不拉几的写有逻辑问题的代码！

事务具有一致性指的是，如果数据库在执行事务之前是一致的，那么在事务执行之后，无论事务是否执行成功，数据库也应该仍然是一致的。

“一致”指的是数据符合数据库本身的定义和要求，没有包含非法或者无效的错误数据。

Redis通过谨慎的错误检测和简单的设计来保证事务的一致性

1、入队错误

2、执行错误

3、服务器停机

事务的隔离性指的是，即使数据库中有多个事务并发地执行，各个事务之间也不会互相影响，并且在并发状态下执行的事务和串行执行的事务产生的结果完全相同。

因为 Redis 使用单线程的方式来执行事务（以及事务队列中的命令），并且服务器保证，在执行事务期间不会对事务进行中断，因此，Redis 的事务总是以串行的方式运行的，并且事务也总是具有隔离性的。

事务的耐久性指的是，当一个事务执行完毕时，执行这个事务所得的结果已经被保存到永久性存储介质（比如硬盘）里面了，即使服务器在事务执行完毕之后停机，执行事务所得的结果也不会丢失。

当服务器在无持久化的内存模式下运作时，事务不具有耐久性：一旦服务器停机，包括事务数据在内的所有服务器数据都将丢失。

当服务器在 RDB 持久化模式下运作时，服务器只会在特定的保存条件被满足时，才会执行 BGSAVE 命令，对数据库进行保存操作，并且异步执行的 BGSAVE 不能保证事务数据被第一时间保存到硬盘里面，因此 RDB 持久化模式下的事务也不具有耐久性。

当服务器运行在 AOF 持久化模式下，并且 appendfsync 选项的值为 always 时，程序总会在执行命令之后调用同步（sync）函数，将命令数据真正地保存到硬盘里面，因此这种配置下的事务是具有耐久性的。

当服务器运行在 AOF 持久化模式下，并且 appendfsync 选项的值为 everysec 时，程序会每秒同步一次命令数据到硬盘。因为停机可能会恰好发生在等待同步的那一秒钟之内，这可能会造成事务数据丢失，所以这种配置下的事务不具有耐久性。

当服务器运行在 AOF 持久化模式下，并且 appendfsync 选项的值为 no 时，程序会交由操作系统来决定何时将命令数据同步到硬盘。因为事务数据可能在等待同步的过程中丢失，所以这种配置下的事务不具有耐久性。

no-appendfsync-on-rewrite配置选项对耐久性的影响

SADD fruits apple banana cherry

MSET apple-price 8 banana-price 5.5 cherry-price 7
利用 mset 命令创建对个字符串类型的键值对。

SORT fruits BY *-price

1、创建一个 redisSortObject 结构数组，数组的长度等于 fruits 集合的大小。

2、遍历数组，将各个数组项的 obj 指针分别指向 fruits 集合的各个元素。

3、遍历数组，根据各个数组项的 obj 指针所指向的集合元素，以及 BY 选项所给定的模式 *-price ，查找相应的权重键。
例如 apple 就会找到数据库键 apple-price

4、将各个权重键的值转换成一个 double 类型的浮点数，然后保存在相应数组项的 u.score 属性里面。

5、以项目组 u.score 属性的值为权重，对数组进行排序，得到一个按 u.score 属性的值从小到大排序的数组。

6、遍历数组，依次将数组项的 obj 指针所指向的集合元素返回给客户端。

SADD fruits apple banana cherry

MSET app-id "FRUIT-25" banana-id "FRUIT-79" cherry-id "FRUIT-13" 

SORT fruits BY *-id ALPHA

1、创建一个 redisSortObject 结构数组，数组的长度等于 fruits 集合的大小。

2、遍历数组，将各个数组项的 obj 指针分别指向 fruits 集合的各个元素。

3、遍历数组，根据各个数组项的 obj 指针所指向的集合元素，以及 BY 选项所给定的模式 *-id ，查找相应的权重键。
例如 apple 就会找到数据库键 apple-id

4、将各个数组项的 u.cmpobj 指针分别指向相应的权重键（一个字符串对象）。

5、以各个数组项的权重键的值为权重，对数组执行字符串排序。

6、遍历数组，依次将数组项的 obj 指针所指向的集合元素返回给客户端。

SADD alphabet a b c d e f

SORT alphabet ALPHA LIMIT 0 4

SORT alphabet ALPHA LIMIT 2 3

1、创建一个 redisSortObject 结构数组，数组的长度等于 alphabet 集合的大小。

2、遍历数组，将各个数组项的 obj 指针分别指向 alphabet 集合的各个元素。

3、根据 obj 指针所指向的集合元素，对数组进行字符串排序。

4、根据选项 LIMIT 0 4，将指针移动到数组的索引0上面，然后依次访问array[0]、array[1]、array[2]、array[3]这4个数组项，并将数组项的 obj 指针所指向的元素"a"、"b"、"c"、"d"返回给客户端。

服务器执行 SORT alphabet ALPHA LIMIT 2 3 命令时的第一至第三步都和执行 SORT alphabetALPHA LIMIT 0 4 命令时的步骤一样，只是第四步有所不同

4、根据选项 LIMIT 2 3，将指针移动到数组的索引2上面，然后依次访问array[2]、array[3]、array[4]这3个数组项，并将数组项的 obj 指针所指向的元素"c"、"d"、"e"返回给客户端。

SADD students peter jack tom

MSET peter-name "Peter White" jack-name "Jack Snow" tom-name "Tom Smith"

SORT students ALPSHA GET *-name

1、创建一个 redisSortObject 结构数组，数组的长度等于 students 集合的大小。

2、遍历数组，将各个数组项的 obj 指针分别指向 students 集合的各个元素。

3、根据 obj 指针所指向的集合元素，对数组进行字符串排序。

4、遍历数组，根据数组项 obj 指针所指向的集合元素，以及 GET 选项所给定的 “*-name”模式，查找到对应的键。
例如 jack 就会找到 jack-name

5、遍历查找程序返回的三个键，并向客户端返回他们的值。

SADD students peter jack tom

MSET peter-name "Peter White" jack-name "Jack Snow" tom-name "Tom Smith"

MSET peter-birth "1995-5-5" jack-birth "1996-6-6" tom-birth "1997-7-7"

SORT students ALPSHA GET *-name GET *-birth

1、2、3、前三个步骤和上面一个 GET 选项是一样的

4、遍历数组，根据数组项 obj 指针所指向的集合元素，以及两个 GET 选项所给定的 *-name 模式和 *-birth 模式，查找相应的键。
例如 jack 就会找到 jack-name 和 jack-birth

5、遍历查找程序返回的六个键，并向客户端返回他们的值。

SADD students peter jack tom

SORT students ALPSHA STORE sorted_students

1、创建一个 redisSortObject 结构数组，数组的长度等于 students 集合的大小。

2、遍历数组，将各个数组项的 obj 指针分别指向 students 集合的各个元素。

3、根据 obj 指针所指向的集合元素，对数组进行字符串排序。

4、检查 sorted_students 键是否存在，如果存在就删除该键。

5、设置 sorted_students 为空白的列表键。

6、遍历数组，将排序后的三个元素依次推入 sorted_students 列表的末尾（相当于执行命令 RPUSH sorted_students xx1 xx2 xxx3）。

7、遍历数组，向客户端返回三个元素。