Redis

a.【建议】:可读性和可管理性
以业务名(或数据库名)为前缀(防止key冲突)，用冒号分隔，比如业务名:表名:id
```c
trade order:1
```

b.【建议】:简洁性
保证语义的前提下，控制key的长度，当key较多时，内存占用也不容忽视，例如
```c
user:{uid}:friends:messages:{mid} 简化为u:{uid}:fr:m:{mid}
```

c.【强制】:不要包含特殊字符
反例:包含空格、换行、单双引号以及其他转义字符

a.【强制】:拒绝bigkey(防止网卡流量、慢查询)
在Redis中，一个字符串最大512MB,一个二级数据结构(例如hash、list、set、zset)
可以存储大约40亿个(2^32 -1)个元素，但实际中如果下面两种情况，就会认为是bigkey
1.字符串类型，它的big体现在单个value值很大，一般认为超过10KB就是bigkey
2.非字符串类型:哈希、列表、集合、有序集合，它们的big体现在元素个数太多。
一般来说，string类型控制在10KB以内，hash、list、set、zset元素个数不要超过5000
反例:一个包含200万个元素的list.

非字符串的bigkey，不要用del删除，使用hscan、sscan、zscan方式渐进式删除，同时要
注意防止bigkey过期时间自动删除问题(例如一个200万的zset设置1小时过期，会触发del
操作，造成阻塞)

b.【推荐】选择合适的数据类型。
例如:实体类型(要合理控制和使用数据结构，但也要注意节省内存和性能之间的平衡)
反例:
```c
set user:1:name tom
set user:1:age 19
set user:1:favor football
```
正例:
```c
hmset user:1 name tom age 19 favor football
```

连接池参数含义:

优化建议:
1.maxTotal:最大连接数，早期的版本叫maxActive实际上这个是一个很难回答的问题，
考虑的因素比较多:
1.1 业务希望Redis并发量
1.2 客户端执行命令时间
1.3 Redis资源:例如nodes(例如应用个数) * maxTotal是不能超过redis的最大连接数maxclients
1.4 资源开销:例如虽然希望控制空闲连接(连接池此可可马上使用的连接)，但是不希望因为连接池
的频繁释放创建连接造成不必要开销

优化建议:
2.maxIdle和minIdle
maxIdle实际上才是业务需要的最大连接数，maxTotal是为了给出雨量，所以maxIdle不要设置过小，
否则会有new Jedis(新连接)开销
连接池的最佳性能是maxTotal = maxIdle，这样就避免连接池伸缩带来的性能干扰，到那时如果并发
量不大或者maxTotal设置过高，会导致不必要的连接资源浪费。一般推荐maxIdle可以设置为上面的
业务期望QPS计算出来的理论连接数，maxTotal可以再放大一倍。
minIdle()最小空闲连接数，与其说是最小空闲连接数，不如说是"至少需要保持的空闲连接数"，在使用
连接的过程中如果连接数超过了minIdle那么继续建立连接，如果超过了maxIdle，当超过的连接执行完
业务后会慢慢被移除连接池释放掉，如果系统启动完马上就会有很多的请求过来，那么可以给redis连接池
做预热，比如快速的创建一些redis连接，执行简单命令，类似ping(),快速地将连接池里地空闲连接提升到
minIdle地数量

LRU算法(least Recently Used,最近最少使用)
淘汰很久没有被访问过的数据，以最近一次访问时间作为参考

LFU算法(Least Frequently Used,最不经常使用)
淘汰最近一段时间被访问次数最少的数据，以次数作为参考

概述。
由于Redis是单线程再处理用户的命令，而Keys命令会一次性遍历所有key，于是在命令
执行过程中，无法执行其他命令。这就导致如果Redis中的key比较多，那么Keys命令执行
时间就会比较长，从而阻塞Redis，所以推荐使用Scan命令来代替Keys，因为Scan可以限制
每次遍历的key数量。
Keys的缺点:
1.没有limit，我们只能一次性获取所有符合条件的key，如果结果有上百万挑，那么等待的就是
"无穷无尽"的字符串输出
2.keys命令是遍历算法，时间复杂度是O(N)。这个命令非常容易导致Redis服务卡顿，要尽量
避免在生产环境使用该命令。
相比于keys命令，Scan命令有两个比较明显的优势:
1.Scan命令的时间复杂度虽然也是O(N)，但它是分次进行的，不会阻塞线程
2.Scan命令提供了count参数，可以控制每次遍历的集合数

可以理解为Scan是渐进式的keys.

大致用法如下:
SCAN命令是基于游标的，每次调用后，都会返回一个游标，用于下一次迭代。当游标返回0时，
表示迭代结束。
第一次Scan时指定游标为0，表示开启新的一轮迭代，然后Scan命令返回一个新的游标，作为第二次
Scan时的游标值继续迭代，一直到Scan返回游标为0，表示本轮迭代结束

通过这个就可以看出，Scan完成一次迭代，需要和Redis进行多次交互。

Scan使用案例。
使用Scan命令，Count参数指定1000，Redis命中几百万Key.
这里会出现一个问题。Scan命令中的Count指定一次扫描多少key,这里指定为1000，
几百万key就需要几千次迭代，即和Redis交互几千次，再加上网络连接中的数据传输
开销和延迟，将会导致耗时比较长。这就需要将Count参数调大后，减少了交互次数。

Count参数越大，Redis阻塞时间也会越长，需要取舍。如果我们极端一点的话，
Count参数和总Key数一致时，Scan命令就和Keys效果一样了

Scan原理。
Redis使用了Hash表作为底层实现，原因不外乎高校且实现简单。类似于HashMap那样数组+链表的结构.
其中第一维的数组大小为2n(n>=0)，每次扩容数组长度扩大一倍。Scan命令就是对这个一维数组进行遍历。
每次返回的游标值也都是这个数组的索引，Count参数表示遍历多少个数组的元素，将这些元素下挂接的符合
条件的结果都返回。因为每隔元素下挂接的链表大小不同，所以每次返回的结果数量也就不同。

总结。
1.Scan Count参数限制的是遍历的bucket数，而不是限制的返回的元素个数
由于不同bucket中的元素个数不同，其中满足条件的个数也不同，所以每次
Scan返回元素也不一定相同
2.Count越大，Scan总耗时越短，但是单次耗时越大，即阻塞Redis时间变长
2.1 推荐Count大小为1W左右
2.2 当Count = Redis Key总数时，Scan和Keys效果一致
3.Scan采用逆二进制发来计算游标，主要为了兼容Rehash的情况
4.Scan为了兼容缩容后不漏掉数据，会出现重复遍历。需要客户端做去重处理

核心就是逆二进制迭代法，比较复杂，而且算法作者也没有具体证明，为什么
这样就能实现，只是测试发现没有问题，各种情况都能兼容

redis6.0以前线程执行模式，如下操作再一个线程中执行完成

redis6.0线程执行模式:
可以通过如下参数配置多线程模型:
```c
io-threads 4 // 这里说 有三个IO线程，还有一个线程是main线程，main线程负责IO读写和命令执行操作
```
默认情况下，如上配置，有三个IO线程，这三个IO线程只会执行IO中的write操作，也就是说，read和命令执行
都由main线程执行，最后多线程讲数据写回客户端。

开启了如下参数:
```c
io-threadas-do-reads yes // 将支持IO线程执行 读写任务
```

1.Redis6.0之前的版本真的是单线程吗？
Redis在处理客户端的请求是，包括获取(socket读)、解析、执行、内容返回(socket 写)等都有一个
顺序串行的主线程处理，这就是所谓的"单线程"。但如果严格来讲并不是单线程，除了主线程外，它
也有后台线程在处理一些较为缓慢的操作，例如清理脏数据、无用连接的释放、大key的删除等等

2.Redis6.0之前为什么一直不使用多线程?
官方曾做过类似问题的回复:使用Redis时，几乎不存在CPU成为瓶颈的情况，Redis主要受限于内存和
网络。例如在一个普通的Linux系统上，Redis通过使用pipelining每秒可以处理100w个请求，所以如果
应用程序主要使用O(N)或O(log(N))的命令，它几乎不会占用太多CPU.
使用了单线程后，可维护性高。多线程模型虽然在某些方面表现优异，但是它却引入了程序执行顺序的
不确定性，带来了并发读写的一系列问题，增加了系统复杂度、同事还可能存在线程切换、甚至加锁解锁、
死锁造成的性能损耗。Redis通过AE事件模型以及IO多路复用等技术，处理性能非常高，因此没有必要使用
多线程。单线程机制使得Redis内部实现的复杂度大大降低，Hash的惰性、Rehash、Lpush等等"线程不安全"
的命令都可以无锁进行

3.Redis6.0为什么要引入多线程呢?
Redis将所有数据放在内存中，内存的响应时长大约为100纳秒，对于小数据包，Redis服务器可以处理8w~10w QPS，
这也是Redis处理的极限了，对于80%的公司来说，单线程的Redis已经足够使用了。但随着越来越复杂的业务场景，有些
公司动不动就上亿的交易量，因此需要更大的QPS。常见的解决方案是在分布式架构中对数据进行分区并采用多个服务器，
但该方案有非常大的缺点，例如要管理的Redis服务器太多，维护代价大；某些适用于单个Redis服务器的命令不适用于数据
分区；数据分区无法解决热点读/写问题；数据倾斜，重新分配和放大/缩小变得更加复杂等等。

从Redis自身角度来说，因为读/写网络的read/write系统调用占用了Redis执行期间大部分CPU时间，瓶颈主要在于网络的
IO消耗，优化主要有两个方向:
1.提高网络IO性能,典型的实现比如使用DPDK来替代内核网络栈的方式
2.使用多线程充分利用多核，典型的实现比如Memcached
协议栈优化的这种方式跟Redis关系不大，支持多线程是一种最有效最便捷的操作方式，所以总结起来，Redis支持多线程
就是两个原因:
1.可以充分利用服务器的CPU资源，，目前主线程只能利用一个核
2.多线程任务可以分摊Redis同步IO读写负荷

4.Redis6.0默认是否开启了多线程?
Redis6.0的多线程默认是禁用的，只使用主线程。如需开启需要修改redis.conf配置文件
```c
io-threads 4

io-threads-do-reads no
```
开启多线程后，还需要设置线程数，否则是不生效的。
关于线程数的设置，官方有一个建议:
4核的机器建议设置为2或3个线程，
8核的建议设置6个线程，线程数一定要小于机器核数，因为Redis还有预留出其他线程做后台任务
比如备份、删除过期键等操作，还需要注意的是，线程数并不是越大越好，
官方认为超过了8个基本就没什么意义了，因为主线程命令执行会存在一个瓶颈点，如果达到瓶颈，即便IO线程
设置得再多，也是空转

5.Redis6.0采用多线程后，性能的提升效果如何?
Redis作者antirez在RedisConf2019分享时曾提到:Redis6引入的多线程IO特性对性能提升
至少是一倍以上。国内也有大牛曾使用unstable版本在阿里云ESC进行过测试，GET/SET命令
在4线程IO时性能相比单线程是几乎翻倍了。如果开启多线程，至少要4核的机器，且Redis实例
已经占用相当大的CPU的耗时的时候才建议使用，否则使用多线程没有意义

6.Redis60多线程的实现机制?
流程简述:
1.主线程负责接收建立连接请求，获取socket放入全局等待读处理队列
2.主线程处理完读事件之后，通过RR(Round Robin)将这些连接分配给这些IO线程
3.主线程阻塞等待IO线程读取socket完毕
4.主线程通过单线程的方式执行请求命令，请求数据读取并解析完成，但并不执行回写socket
5.主线程阻塞等待IO线程将数据回写socket完毕
6.解除绑定，清空等待队列

该设计有如下特定:
1.IO线程要么同时在读socket，要么同时在写，不会同时读或写
2.IO线程只负责读写socket解析命令，不负责命令处理

7.开启多线程后，是否会存在线程并发安全问题?
Redis的多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程顺序执行。
所以我们不需要去考虑控制key、lua、事务，LPUSH/LPOP等等的并发及线程安全问题

8.Redis6.0的多线程和Memcached多线程模型进行对比
Memcached服务器采用master-worker模式进行工作。服务端采用socket与客户端通讯。
主线程、工作线程采用pipe管道进行通讯。主线程采用libevent监听listen、accept的读事件，
事件响应后将连接信息的数据结构封装起来，根据算法选择合适的工作线程，将连接任务携带
连接信息分发出去，响应的线程利用连接描述符建立与客户端的socket连接并进行后续的存取
数据操作
相同点:都采用了master线程-worket线程的模型
不同点:Memcached执行主逻辑也是在worker线程里，模型更加简单，实现了真正的线程隔离，
符合我们对线程隔离的常规理解。而Redis吧处理逻辑交还给master线程，虽然一定程度上增加了
模型复杂度，但也解决了线程并发安全等问题

举个例子，用户A和用户B抛硬币，规则是用户B负责抛硬币，每次抛的硬币可能正面，
可能反面。每当抛到正面为一回合，用户B可以自己决定进行几个回合。最后需要告诉
用户A最长的那个回合抛了多少次以后出现了正面，再由用户A来猜用户B一共进行了
几个回合.
如图所示，进行了n次，
第一次:抛了3次才出现正面，此时k=3, n = 1
第二次:抛了2次才出现正面，此时k=2, n = 2
第三次:抛了4次才出现正面，此时k=4, n = 3
.........
第n次试验:抛了7次才出现正面，此时我们估算，k = 7, n = n
k是每回合抛到1(硬币的正面)所用的次数，，我们已知的是最大的k值，可以用k_max表示。
由于每次抛硬币的结果只有0和1两种情况,因此，能够推测出k_max在任意回合出现的概率，
并由kmax结合极大似然估计的方法推测出n的次数n=2^(k_max).概率学把这种问题叫做
伯努利实验。现在用户B已经完成了n个回合，并且告诉用户A最长的一次抛了4次，用户A此时
胸有成竹，马上根据公式得出的结果是16，然后用户B却只抛了3次。所以这种预估方法存在较大误差,
为了改善误差情况，HLL中引入了发呢同平均的概念。

同样举抛硬币的例子，如果只有一组抛硬币实验，显然根据公式推导得到的实验次数的估计误差较大，
如果100个组同时进行抛硬币实验，样本数变大，受运气影响的概率就很低了，每组分别进行多次抛
硬币实验，并上报各自实验过程中抛到正面的抛掷次数的最大值，就能根据100组的平均值预估整体的
实验次数了。分桶平均的基本原理是将统计数据划分为m个桶，每个桶分别统计各自的k_max,并能得到
各自的基数预估值，最终对这些基数预估值求平均得到整体的基数预估值。LLC中使用几何平均数预估
整体的基数值，但是当统计数据量较小时误差较大:HLL在LLC基础上做了改进，采用调和平均数过滤掉
不健康的统计值。

什么是调和平均数呢?
举个例子。求平均工资:A的是1000/月，B的是30000/月。采用平均数的方式就是(1000+30000)/2=15500
采用调和平均数的方式就是2/(1/1000 + 1/30000)约等于1935.484.
可见调和平均数比平均数的好处就是不容易受到大的数据的影响，比平均数的效果是要好的。

value被转换为64位的比特串，最终被按照上面的做法记录到每个桶中去。
64位转十进制就是2^64,HyperLogLog仅仅用了16384 *6/8/1024=12K
存储空间久能统计多达2^64个数，同时在具体的算法实现上，HLL还有一个
分阶段偏差修正算法

1.缓存空对象

2.布隆过滤器
对于恶意攻击，向服务器请求大量不存在的数据造成的缓存穿透，还可以用布隆过滤器先做一次过滤，
对于不存在的数据布隆过滤器一般都能够过滤掉，不让请求再往后端发送。当布隆过滤器说某个值存在
时，这个值可能不存在;当它说不存在时，那就肯定不存在.
布隆过滤器就是一个大型的位数组和几个不一样的无偏hash函数。所谓无偏就是能够把元素的hash值
算的比较均匀。向布隆过滤器中添加key时，会使用多个hash函数都会算得一个不同的位置。再把位数组
的这几个位置都置为1，就完成了add操作。向布隆过滤器询问key是否存在时，跟add一样，也会把hash
的几个位置都算出来，看看位数组中这几个位置是否都为1，只要有一个位为0，那么说明布隆过滤器中这个
key不存在。如果都是1，这并不能说明这个key就一定存在，只是极有可能存在，因为这些位置为1可能是
因为其他的key存在所致。如果这个位数组比较稀疏，这个概率就会很大，如果这个位数组比较拥挤，这个
概率就会很低。这种方法适用于数据命中不高、数据相对固定、实时性低(通常是数据集较大)的应用场景，
代码维护较为复杂，但是缓存空间占用很少

解决方案:
1.对于并发几率很小的数据(如个人维度的订单数据、用户数据等)，这种几乎不用考虑这个问题，很少会
发生缓存不一致，可以给缓存数据加上过期时间，每隔一段时间触发读的主动更新即可
2.就算并发很高，如果业务上能容忍短时间内的缓存数据不一致(如商品名称，商品分类菜单等)，缓存加上
过期时间依然可以解决大部分业务对于缓存的要求
3.如果不能容忍缓存数据不一致，可以通过加分布式读写锁保证并发读写或写写的时候按顺序排好队，读读
的时候相当于无锁
4.也可以阿里开源的canal通过监听数据库的binlog日志即时地去修改缓存，但是引入了新地中间件，增加了
系统地复杂度

先更新数据库，还是先更新缓存?
1.先更新数据库，再更新缓存
2.先更新缓存，再更新数据库

Cache Aside(旁路缓存)策略，该策略可以细分为【读策略】和【写策略】
写策略的步骤:
1.更新数据库中的数据；
2.删除缓存中的数据

读策略的步骤:
1.如果读取的数据命中了缓存，则直接返回数据
2.如果读取的数据没有命中缓存，则从数据库中读取数据，然后将数据写入
到缓存，并且返回给用户

但是【写策略】中的数据库和缓存操作又有不同的顺序:
1.先删除缓存，再更新数据库
2.先更新数据库，再删除缓存

哨兵leader选举流程。
当一个master服务器被某sentinel视为下线状态后，该sentinel会与其他sentinel协商选出sentinel的leader
进行故障转移工作。每个发现master服务器进入下线的sentinel都可以要求其他sentitnel选自己为sentinel的
leader，选举是先到先得。同时每个sentinel每次选举都会自增配置纪元(选举周期),每个纪元中只会选择一个
sentinel的leader，如果所有超过一般的sentitnel选举某sentinel作为leader，之后该sentinel进行故障转移
操作，从存活的slave中选举出新的master，这个选举过程跟集群的master选举很类似。
哨兵集群只有一个哨兵节点，redis的主从也能正常运行以及选举master,如果master挂了，那唯一的那个哨兵
就是哨兵leader了，可以正常选举新master。不过为了高可用一般都推荐至少部署三个哨兵节点。

CRC16的算法原理。
1.根据CRC16的标准选择初值CRCIn的值
2.将数据的第一个字节与CRCIn高8位异或
3.判断最高位，若该位为0左移一位，若为1左移一位再与多项式Hex码异或
4.重复3至9位全部移位计算结束
5.重复将所有输入数据操作完成以上步骤，所得16位数即16位CRC校验码

CRC16算法最大值。
CRC16算法，产生的哈希值有16bit位，可以产生65535(2^16)个值，也就是说
值分布在0~65535之间，这个时候疑问就来了，槽位总数为什么是16384？65536不可以吗?

Antirez(Redis作者)大神做了回复，归纳起来就是:
1.正常的心跳数据包携带节点携带节点的完整配置，它能以幂等方式来更新配置，如果采用16384
个插槽，占用空间为2KB(16384 / 8 / 1024 = 2KB),如果采用65536个插槽，占用空间8KB
(65536 / 8 / 1024=8KB)
2.Redis Cluster不太可能扩展到超过1000个主节点，太多可能导致网络拥堵
3.16384个插槽范围比较合适，当集群扩展到1000个节点时，也能确保每个master节点有足够的插槽

8KB的心跳包看似不大，但是这个是心跳包每秒都要将本节点的信息同步给其他集群节点。
比起16384个插槽，头大小增加了4倍，ping消息的消息头太大了，浪费带宽。

Redis主节点的哈希槽配置信息是通过bitmap来保存的，也就是位数组，元素的值为0或1.
在传输过程中，会对bigmap进行压缩，bitmap的填充率越低，压缩率越高。
bitmap填充率 = slots / N(N表示节点数)
所以插槽数偏低的话，填充率就会降低，压缩率会升高
综合下来，从心跳包的大小、网络带宽、心跳并发、压缩率等维度考虑，16384个插槽更有
优势且能满足业务需求

为什么bitmap填充率越低，压缩率就越高？
在Redis中，对bit数组进行压缩时，压缩率与填充的数(或者说是1的数量)的关系是成反比的，
因为在压缩过程中，Redis使用的是基于运行长度编码(Run-Length-Encoding,RLE)的压缩算法。
RLE是一种基本的压缩算法，它通过识别重复出现的连续数据来减少存储空间。如果数据中存在
大量的连续重复字符，RLE算法的随机效果会非常好，反之，如果数据中的字符分布较为随机，
没有出现太多连续的重复字符，那么RLE的压缩效果就不明显，甚至可能使数据变大

master节点间心跳数据包格式:
消息格式分为:消息头+消息体。消息头包含发送节点自身状态数据，接收节点根据消息头就可以获取
到发送节点的相关数据
相关代码在src/cluster.h文件中以5.0版本为例，如代码所示，消息头中有一个myslots的char类型数组，
unsinged char myslots[CLUSTER_SLOTES/8];数组长度为16384/8=2048.底层存储其实是一个
bitmap,每一位代表一个插槽，如果该位为1，表示这个插槽是属于这个节点的。
消息体中，会携带一定数量的其他节点信息用于交换，约为集群总节点数量的1/10，节点数量越多，
消息体内容越大。10个节点的消息体大小约为1kb,char 在C语言中占用一个字节

master节点间心跳通讯。
Redis集群采用Gossip(流言)协议，Gossip协议工作原理就是节点彼此不断通信交换信息，一段时间后所有
的节点都会知道集群完整的信息，类似流言传播

具体规则如下:
1.每秒会随机选取5个节点，找出最久没有通信的节点发送ping消息
2.每隔100ms都会扫描本地节点列表，如果发现节点最近一次接收pong消息的时间大于cluster-node-timeout/2,
则立即发送ping消息

集中式。
优点在于元数据的更新和读取，时效性非常好，一旦元数据出现变更立即回更新到
集中式的存储中，其他节点读取的时候立即就可以感知到；不足在于所有的元数据
的更新压力全部集中在一个地方，导致元数据的存储压力。很多中间件都会借助
Zookeeper集中式存储元数据

Gossip:gossip协议包含多种消息，包括ping,pong,meet，fail等等。
1.meet:某个节点发送meet给新加入的节点，让新节点加入集群中，然后新节点就会
开始与其他节点进行通信；
2.ping:每个节点都会频繁给其他节点发送ping，其中包含自己的状态还有自己维护的
集群元数据，互相通过ping交换元数据(类似自己感知到的集群节点增加和移除，hash slot信息等)
3.pong:对ping和meet消息的返回，包含自己的状态和其他信息，也可以用于信息广播和更新
4.fail:某个节点判断另一个节点fail之后，就发送fail给其他节点，通知其他节点，指定的节点宕机了

概述。
Redis没有直接使用C语言传统的字符串表示(以空字符结尾的字符数组，简称C字符串)，
而是自己构建了一种名为简单动态字符串(Simple Dynamic String, SDS)的后向类型，
并将SDS用作Redis的默认字符串表示。在Redis里面C字符串只会作为字符串字面量
(string literal)用在一些无须对字符串值进行修改的地方。比如打印日志。

当Redis需要的不仅仅是一个字符串字面量，而是一个可以被修改的字符串时，Redis就会
使用SDS来表示字符串值，比如在Redis的数据库里面，包含字符串值的键值对在底层都是
由SDS来实现的

除了用来保存数据库中的字符串值之外，SDS还被用作缓冲区(buffer)：AOF模块中的AOF
缓冲区、以及客户端状态中的输入缓冲区，都是由SDS实现的

定义。
每个sds.h/sdshdr结构表示一个SDS值如图.

SDS遵循C字符串以空字符结尾的惯例，保存空字符的1字节空间不计算在SDS的len属性里面，
并且为空字符分配额外的1字节空间，以及添加空字符到字符串末尾等操作，都是由SDS函数
自动完成的，所以这个空字符对于SDS的使用者来说是完全透明的。遵循空字符结尾这一惯例
的好处是，SDS可以直接重用一部分C字符串函数库里的函数，例如printf函数，printf("%s", s->buf)
来打印SDS保存的字符串值"Redis",而无需为SDS编写专门的打印函数

SDS与C字符串的区别。
根据传统，C语言使用长度为N+1的字符串数组来表示长度为N的字符串，并且字符数组的
最后一个元素总是空字符'\0',如图所示。
C语言使用的这种简单的字符串表示方式，并不能满足Redis对字符串在安全性、效率性以及
功能方面的要求

概述。
链表提供了高效的节点重拍能力，以及顺序性的节点访问方式，并且可以通过增删节点来灵活地
调整链表的长度。作为一种常用的数据结构，链表内置在很多高级的变成语言里面，因为Redis
使用的C语言并没有内置这种数据结构，所以Redis构建了自己的链表实现。链表在Redis中的应用
非常广泛，比如列表键的底层实现之一就是链表。当一个列表键包含了数量比较多的元素，又或者
列表中包含的元素都是比较长的字符串时，Redis就会使用链表作为列表键的底层实现。

除了链表键之外，发布与订阅、慢查询、监视器等功能也用到了链表，Redis服务器本身还使用
链表来保存多个客户端的状态信息，以及使用链表来构建客户端输出缓冲区(output buffer)

链表和链表节点的实现。
每个链表节点使用一个adlist.h/listNode结构来表示:

概述。
字典又称为符号表(symbol table)、关联数组(associative array)或映射(map)，是一种
保存键值对(key-value pair)的抽象数据结构，在字典中，一个键(key)可以和一个值(value)
进行关联(或者说将键映射为值)，这些关联的键和值就称为键值对。字典中的每个键都是
独一无二的，程序可以在字典中根据键查找与之关联的值，或者通过键来更新值，又或者
根据键来删除整个键值对等等

字典经常作为一种数据结构内置在很多高级编程语言里面，但Redis所使用的C语言并没有
内置这种数据结构，因此Redis构建了自己的字典实现。字典在Redis中的应用相当广泛，
比如Redis的数据库就是使用字典来作为底层实现的，对数据库的增删改查操作也是构建
在对字典的操作之上的。

除了用来表示数据库之外，字典还是哈希键的底层实现之一，当一个哈希键包含的键值对
比较多，又或者键值对中的元素都是比较长的字符串时，Redis就会使用字典作为哈希键
的底层实现。

除了用来实现数据库和哈希键之外，Redis的不少功能也用到了字典

字典的实现。
Redis的字典使用哈希表作为子层实现，一个哈希表里面可以有多个哈希表节点，而每个
哈希表节点就保存了字典中的一个键值对

概述。
跳跃表(skiplist)是一种有序数据结构，它通过在每个节点中维持多个指向其他节点的指针，从而
达到快速访问节点的目的。
跳跃表支持平均O(logN)、最坏O(N)复杂度的节点查找，还可以通过顺序性操作来批量处理节点。
在大部分情况下，跳跃表的效率可以和平衡树相媲美，并且因为跳跃表的实现比平衡树要来得更为
简单，所以有不少程序都是用跳跃表来代替平衡树。Redis使用跳跃表作为有序集合键的底层实现之一,
如果有一个有序集合包含的元素数量比较多，又或者有序集合中元素的成员(member)是比较长的字符串
时，Redis就会使用跳跃表来作为有序集合键的底层实现。

和链表、字典等数据结构被广泛地应用在Redis内部不同，Redis只在两个地方用到了跳跃表，一个是实现
有序集合键，另一个是在集群节点中用作内部数据结构，除此之外，跳跃表在Redis里面没有其他用途。

跳跃表的实现。
Redis的跳跃表由redis.h/zskiplistNode和redis.h/zskiplist两个结构定义，其中zskiplistNode结构用于
表示跳跃表节点，而zskiplist结构则用于保存跳跃表节点的相关信息，比如节点的数量，以及指向表头
节点和表尾节点的指针等等。

跳跃表节点。
跳跃表节点的实现由redis.h/zskiplistNode结构定义

跳跃表。
仅靠多个跳跃表节点就可以组成一个跳跃表，如图所示。
但通过使用一个zskiplist结构来持有这些节点，程序可以更方便地对整个跳跃表进行处理，
比如快速访问跳跃表地表头节点和表尾节点，或者快速地获取跳跃表节点地数量(也即是
跳跃表的长度)等信息

概述。
整数集合(intset)是集合键的底层实现之一，当一个集合只包含整数值元素，并且这个结合的元素数量
不多时，Redis就会使用整数集合作为集合键的底层实现。

整数集合的实现。
整数集合(intset)是Redis用于保存整数值的集合抽象数据结构，它可以保存类型为int16_t、
int32_t或者int64_t的整数值，并且保证集合中不会出现重复元素。每个intset.h/intset结构
表示一个整数集合:
contents数组是整数集合的底层实现:整数集合的每个元素都是contents数组的一个数组项(item),
各个项在数组中按值得大小从小到大有序地排列，并且数组中不包含任何重复项
length属性记录了整数集合包含地元素数量，也即是contents数组地长度.
虽然intset结构将contents属性声明为int8_t类型地数组，但实际上contents数组并不保存任何
int8_t类型的值，contents数组的真正类型取决于encoding属性的值:
1.如果encoding属性的值为INTSET_ENC_INT16,那么contents就是一个int16_t类型的数组，数组
里的每个项都是一个int16_t类型的整数值(最小值为-32768，最大值为32767，正负2的16-1次方)
2.如果encoding属性的值为INTSET_ENC_INT32，那么contents就是一个int32_t类型的数组，
数组里的每个项都是一个int32_t类型的整数值(最大值、最小值为正负2的32-1次方)
3.如果encoding属性为INTSET_ENC_INT64，那么contents就是一个int64_t类型的数组，数组里的
每个项都是一个int64_t类型的整数值(最大值最小值为，2的64-1次方-1，2的64-1次方)

升级。
每当我们要将一个新元素添加到整数集合里面，并且新元素的类型比整数集合现有所有元素的类型
都要长时，整数集合需要先进行升级(upgrade)，然后才能将新元素添加到整数集合里面。
升级整数集合并添加新元素共分为三步进行:
1.根据新元素的类型，扩展整数集合底层数组的空间大小，并为新元素分配空间
2.将底层数组现有的所有元素都转换成与新元素相同的类型，并将类型转换后的元素防止到正确的位上，
而且在放置元素的过程中，需要继续维持底层数组的有序性质不变
3.将新元素添加到底层数组里面

降级。
整数集合不支持降级操作，一旦对数组进行了升级，编码就会一直保持升级后的状态

概述。
压缩列表(ziplist)是列表键和哈希键的底层实现之一。当一个列表键只包含少量列表项，并且每个列表项要么
就是小整数值，要么就是长度比较短的字符串，那么Redis就会使用压缩列表来做列表键的底层实现。

压缩列表的构成。
压缩列表是Redis为了节约内存而开发的，是由一系列特殊编码的连续内存块组成的顺序型(sequential)
数据结构。一个压缩列表可以包含任意多个节点(entry)，每个节点可以保存一个字节数组或者一个整数值。

压缩列表节点的构成。
每个压缩列表节点可以保存一个字节数组或者一个整数值，其中，字节数组可以是以下三种长度之一:
1.长度小于等于63(2 ^ 6 - 1)字节的字节数组
2.长度小于等于16383(2 ^ 14 - 1)字节的字节数组
3.长度小于等于4294967295(2 ^ 32 - 1)字节的字节数组
而整数值则可以是以下六种长度之一:
1.4位长，介于0至12之间的无符号整数
2.1字节长的有符号整数
3.3字节长的有符号整数
4.int16_t类型整数
5.int32_t类型整数
6.int64_t类型整数
每个压缩列表节点都由previous_entry_length、encoding、content三个部分组成

连锁更新。
每个节点的previous_entry_length属性都记录了前一个节点的长度:
1.如果前一节点的长度小于254字节，那么previous_entry_length属性需要用1字节长的空间来
保存这个长度值
2.如果前一节点的长度大于等于254字节，那么previous_entry_length属性需要用5字节长的空间
来保存这个长度值
现在，考虑这样一种情况:在一个压缩列表中，有多个连续的、长度介于250字节到253字节之间的
节点e1至eN,如图所示。因为e1至eN的所有节点的长度都小于254字节，所以记录这些节点的长度
只需要1字节长的previous_entry_length属性，换句话说，e1至eN的所有节点的previous_entry_length
属性都是1字节长。
这时，如果将一个长度大于等于254字节的新节点new设置为压缩列表的表头节点，那么new将称为e1的
前置节点

概述。
Redis使用对象来表示数据库中的键和值，每次当我们在Redis的数据库中新建一个键值对时，我们至少会
创建两个对象，一个对象用作键值对的键(键对象)，另一个对象用作键值对的值(值对象).

Redis中的每个对象都由一个redisObject结构表示，该结构中的保存数据有关的
三个属性分别是type属性、encoding属性和ptr属性

类型。
对象的types属性记录了对象的类型，这个属性的值可以是图中列出的常量中的其中一个。
对于Redis数据库保存的键值对来说，键总是一个字符串对象，而值则可以是字符串对象、
列表对象、哈希对象、集合对象或者有序对象的其中一种。
1.当称呼一个数据库键为"字符串键"时，指的是"这个数据库键所对应的值为字符串对象";
2.当称呼一个键为"列表键"时，指的是"这个数据库键所对应的值为列表对象"

 编码的底层实现。
对象的ptr指针指向对象的底层实现数据结构，而这些数据结构由对象的encoding属性决定。
encoding属性记录了对象所使用的编码，也即是说这个对象使用了什么数据结构作为对象的
底层实现,这个属性的值可以是图中列出的常量的其中一个

如果一个字符串对象保存的是整数值，并且这个整数值可以用long类型来表示，那么字符串对象会将整数值
保存在字符串对象结构的ptr属性里面(将void *转换成long)，并且将字符串对象的编码设置为int
举个例子，如果执行以下SET命令，那么服务器将创建一个如图所示的int编码的字符串对象作为number键的值:
```c
127.0.0.1:6379> SET number 10086
OK
127.0.0.1:6379> OBJECT ENCODING number
"int"
```

如果字符串对象保存的是一个字符串值，并且这个字符串值的长度大于(3.2版本之前是39字节，之后变成44字节，
后面再分析)，那么字符串对象将使用简单动态字符串(SDS)来保存这个字符串，并将对象的编码设置为raw.
举个例子，如果执行以下命令，那么服务器将创建一个如图所示的字符串对象作为story键的值:
```c
127.0.0.1:6379> SET stroy "Long, long, long,  ago, there, lived, a, king, 123456789987654321"
OK
127.0.0.1:6379> STRLEN stroy
(integer) 65
127.0.0.1:6379> OBJECT ENCODING stroy
"raw"
```

如果字符串对象的保存的是一个字符串值，并且这个字符串值的长度小于等于(39或44字节)，那么字符串对象
将使用embstr编码的方式来保存这个字符串值。embstr编码是专门用于保存短字符串的一种优化编码方式，
这种编码和raw编码一样，都是用redisObject结构和sdshdr结构来表示字符串对象，但raw编码会调用两次
内存分配函数来分别创建redisObject结构和sdshdr结构，而embstr编码则通过调用一次内存分配函数来分配
一块连续的空间，空间中依次包含redisObject和sdshdr两个结构，如图所示。

embstr编码的字符串对象在执行命令时，产生的效果和raw编码的字符串对象执行命令时产生的效果时相同的，
但使用eembstr编码将创建字符串对象来保存短字符串值有以下好处:
1.embstr编码将创建字符串对象所需的内存分配次数从raw编码的两次降低为一次。
2.释放embstr编码的字符串对象只需要调用一次内存释放函数，而释放raw编码的字符串对象需要调用两次内存释放函数
3.因为embstr编码的字符串对象的所有数据都保存在一块连续的内存里面，所以这中编码的字符串对象比起raw编码的
字符串对象比起raw编码的字符串对象能够更好地利用缓存带来的优势。

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

编码的转换。
int编码的字符串对象和embstr编码的字符串对象在条件满足的情况下，会被转换为raw编码的对象。
对于int编码的字符串对象来说，如果向对象执行了一些命令，使得这个对象保存的不再是整数值，
而是一个字符串值。那么字符串对象的编码将从int变为raw.

另外，因为Redis没有为embstr编码的字符串对象编写任何相应的修改程序(只有int编码的字符串对象和
raw编码的字符串对象有这些程序)，所以embstr编码的字符串对象实际上是只读的。当对embstr编码
的字符串对象执行任何修改命令时，程序会先将对象的编码从embstr转换成raw，然后再执行修改命令。
因为这个原因，embstr编码的字符串对象在执行修改命令之后，总会变成一个raw编码的字符串对象。

概述。
ziplist编码的列表对象使用压缩列表作为底层实现，每个压缩列表节点(entry)保存了一个列表元素。
例子如下。如果numbers键的值对象使用的是ziplist编码，这个这个值对对象将会是如图所示的样子。

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

注意，linkedlist编码的列表对象在底层的双端链表结构中包含了多个字符串对象，这种嵌套字符串对象的
行为在哈希对象、集合对象、有序集合对象中都会出现，字符串对象是Redis五种类型的对象中唯一一种
会被其他四种对象嵌套的对象

编码转换。
当列表对象可以同时满足以下两个条件时，列表对象使用ziplist编码:
1.列表对象保存的所有字符串元素的长度都小于64字节
2.列表对象保存的元素数量小于512个；
不能满足这两个条件的列表对象需要使用linkedlist编码

对于使用ziplist编码的列表对象来说，当使用ziplist编码所需的两个条件
的任意一个不能被满足时，对象的编码转换操作就会被执行，原本保存在
压缩列表里的所有列表元素都会被转移并保存到双端链表里面，对象的编码
也会从ziplist变为linkedlist

概述。
ziplist编码的哈希对象使用压缩列表作为底层实现，每当有新的键值对要加入
到哈希对象时，程序会先将保存了键的压缩列表推入到压缩列表表尾，然后再
将保存了值的压缩列表节点推入到压缩列表表尾，因此:
1.保存了同一键值对的两个节点总是紧挨在一起，保存键的节点在前，保存值的
节点在后。
2.先添加到哈希对象中的键值对会被放在压缩列表的表头方向(相对于值对象来说)，
而后来添加到哈希对象中的键值对会被放在压缩列表的表尾方向

另一方面，hashtable编码的哈希对象使用字典作为底层实现，哈希对象中的每个
键值对都使用一个字典键值对来保存:
1.字典的每个键都是一个字符串对象，对象中保存了键值对的键
2.字典的每个值都是一个字符串对象，对象中保存了键值对的值

编码转换。
当哈希对象可以同时满足以下两个条件时，哈希对象使用ziplist编码：
1.哈希对象保存的所有键值对的键和值的字符串长度都小于64字节
2.哈希对象保存的键值对数量小于512个
不能满足这两个条件的哈希对象需要使用hashtable编码

对于使用ziplist编码的列表对象，当使用ziplist编码所需的两个条件任意
一个不能被满足时，对象的编码转换操作就会被执行，原本保存在压缩
列表里的所有键值对都会被转移并保存到字典里面，对象的编码也会从ziplist
变为hashtable.

概述。
intset编码的集合对象使用整数集合作为底层实现，集合对象包含的所有元素都被保存在
整数集合里面。

另一方面，hashtable编码的集合对象使用字典作为底层实现，字典的每个键都是一个字符串
对象，每个字符串对象包含了一个集合对象，而字典的值则全部被设置为NULL.

编码的转换。
当集合对象可以同时满足以下两个条件时，对象使用intset编码:
1.集合对象保存的所有元素都是整数值
2.集合对象保存的元素不超过512个
不能满足中两个条件的集合对象需要使用hashtable编码

对于使用intset编码的集合对象来说，当使用intset编码所需的两个条件的任意一个不能被满足时，
就会执行对象的编码转换操作，原本保存在整数集合中的所有元素都会被转移并保存到字典里面，
并且对象的编码也会从intset变为hashtable

概述。

编码的转换。
当有序集合对象可以同时满足以下两个条件时，对象使用ziplist编码
1.有序集合保存的元素数量小于128个
2.有序集合保存的所有元素成员的长度都小于64字节
不能满足以上两个条件的有序集合对象将使用skiplist编码

对于使用ziplist编码的有序集合对象来说，当使用ziplist比那吗所需的两个条件中
的任意一个不能被满足时，程序就会执行编码转换操作，将原本储存在压缩列表里面
的所有集合元素转移到zset里面，并将对象的编码从ziplist改为skiplist

举个例子，以下代码就展示了使用DEL命令来删除三种不同类型的键:
```c
// 字符串键
127.0.0.1:6379> SET msg "hello"
OK
// 列表键
127.0.0.1:6379> RPUSH numbers 1 2 3
(integer) 3
// 集合键
127.0.0.1:6379> SADD  fruits apple banana cherry
(integer) 3

127.0.0.1:6379> DEL msg
(integer) 1
127.0.0.1:6379> DEL numbers
(integer) 1
127.0.0.1:6379> DEL fruits
(integer) 1
```

举个例子，我们可以用SET命令创建一个字符串键，然后用GET命令和APPEND命令操作这个键，
但如果我们试图对这个键执行只有列表键才能执行的LLEN命令，那么Redis将向我们返回一个类型
错误
```c
127.0.0.1:6379> SET msg "hello world"
OK
127.0.0.1:6379> GET msg
"hello world"
127.0.0.1:6379> APPEND msg " again!"
(integer) 18
127.0.0.1:6379> GET msg
"hello world again!"
127.0.0.1:6379> LLEN msg
(error) WRONGTYPE Operation against a key holding the wrong kind of value
```

举个例子，对于LLEN命令来说:
1.在执行LLEN命令之前，服务器会先检查输入数据库键的之对象是否为列表类型，
也即是，检查值对象redisObject结构type属性的值是否为REDIS_LIST.如果是的话，
服务器就对键执行LLEN命令
2.否则的话，服务器就拒绝执行命令并向客户端返回一个类型错误。
检查过程如图

举个例子，列表对象有ziplist和linkedlist两种编码可用，其中前者使用压缩列表API
来实现列表命令，而后者则使用双端链表API来实现列表命令。

如图展示了LLEN命令从类型检查到根据编码选择实现函数的整个执行过程，
其他类型特定命令的执行过程也是类似

对象的整个生命周期可以划分为创建对象、操作对象、释放对象三个阶段。
举个例子，以下代码展示了一个字符串对象从创建到释放的整个过程
```c
// 创建一个字符串对象s，对象的引用计数为1
robj *s = createStringObject(....);

// 对象s执行各种操作...

// 将对象s的引用计数减一，使得对象的引用计数变为0
// 导致对象s被释放
decrRefCount(s);
```
其他不同类型的对象也会经历类似的过程

举个例子，假设键A创建了一个包含整数值100的字符串对象作为值对象，
如图所示

如果这时键B也要创建一个同样保存了整数100的字符串对象作为之对象，
那么服务器有以下两种做法：
1.为键B新创建一个包含整数值100的字符串对象
2.让键A和键B共享同一个字符串
以上两种方法明显是第二种方法更节约内存

举个例子,如图所示展示了包含整数值100的字符串对象同时被键A和键B
共享之后的样子，可以看到，除了对象的引用计数从之前的1变成了2之外，
其他属性都没有变化，共享对象机制对于节约内存非常有帮助，数据库中
保存的相同的值对象越多，对象共享机制就能节约越多的内存

例如，假设数据库中保存了整数值100的键不只有键A和键B两个，而是有一百个,
那么服务器只需要用一个字符串对象的内存就可以保存原本需要使用一百个字符串
对象的内存才能保存的数据。

举个例子，如果创建一个值为100的键A，并使用OBJECT REFCOUNT命令查看
键A的值对象的引用计数，就会发现值对象的引用计数为2
```c
127.0.0.1:6379> SET A 100
OK
127.0.0.1:6379> OBJECT REFCOUNT A
(integer) 2
```
引用这个值对象的两个程序分别时持有这个之对象的服务器程序，以及共享这个值对象
的键A,如图所示。如果此时再创建一个值为100的键B,那么键B也会指向包含整数值100
的共享对象，使得共享对象的引用计数值变为3，如图所示
```c
127.0.0.1:6379> SET B 100
OK
127.0.0.1:6379> OBJECT REFCOUNT A
(integer) 3
127.0.0.1:6379> OBJECT REFCOUNT B
(integer) 3
```

```c
127.0.0.1:6379> SET msg "hello world"
OK
// 等待一小段时间
127.0.0.1:6379> OBJECT IDLETIME msg
(integer) 11
// 等待一阵子
127.0.0.1:6379> OBJECT IDLETIME msg
(integer) 16
// 访问msg键的值
127.0.0.1:6379> GET msg
"hello world"
// 键处于活跃状态，空转时长为0
127.0.0.1:6379> OBJECT IDLETIME msg
(integer) 5
```

TTL命令和PTTL命令接受一个带有生存时间或者过期时间的键，返回这个键的剩余生存时间，
也就是，返回距离这个键被服务器自动删除还有多长时间
```c
127.0.0.1:6379> SET key value
OK
127.0.0.1:6379> EXPIRE key 1000
(integer) 1
127.0.0.1:6379> TTL key
(integer) 996
```

举个例子,图中的过期字典保存了两个键值对:
1.第一个键值对的键为alphabet键对象，值为1385877900000，这表示数据库键
alphabet的过期时间为1385877600000(2013年12月)
2.第二个键值对的键为book键对象，值为1388556000000，这表示数据库键book
的过期时间为1388556000000(2014年1月1日零时)
当客户端执行PEXPIREAT命令(或者其他三个会转换成PEXIPREAT命令的命令)为一个
数据库键设置过期时间时，服务器会在数据库的过期字典中关联给定的数据库和过期时间

例如，如果正有大量的命令请求在等待服务器处理，并且服务器当前不缺少内存，那么服务器应该
优先将CPU时间用在处理客户端的命令请求上面，而不是用在删除过期键上面

除此之外，创建一个定时器需要用到Redis服务器中的时间事件，而当前事件事件的实现方式——
无序链表，查找一个事件的事件复杂度为O(N)——并不能高效地处理大量时间事件。
因此，要让服务器创建大量的定时器，从而实现定时删除策略，在现阶段来说并不现实

举个例子，对于一些和时间相关的数据，比如日志(log)，在某个时间点之后，对他们的访问就会
大大减少，甚至不再访问，如果这类过期数据大量地积压在数据库中，用户以为服务器已经自动
将它们删除了，但实际上这些键仍然存在，而且键所占用地内存也没有释放，那么造成的后果肯定
是非常严重的。

命令调用expireIfNeeded函数的过程。
expireIfNeeded函数就像一个过滤器，它可以在命令真正执行之前，过滤掉
过期的输入键，从而避免命令接触到过期键。

举个例子，如图所示展示了GET命令的执行过程，在这个执行过程中，命令需要
判断键是否存在以及键是否过期，然后根据判断来执行合适的动作

```c
# 默认每次检查的数据库数量
DEFAULT_DB_NUMBERS = 16
# 默认每个数据库检查的键数据量
DEFAULT_KEY_NUMBERS = 20;

# 全局变量，记录检查进度
current_db= 0

def activeExpireCycle() :
 # 初始化要检查的数据库数量
 # 如果服务器的数据库数量比DEFAULT_DB_NUMBERS药效
 # 那么以服务器的数据库数量为准
 if server.dbnum < DEFAULT_DB_NUMBERS:
  db_numbers = server.dbnum
 else:
  db_numbers = DEFAULT_DB_NUMBERS
  
 
 # 遍历各个数据库
 for i in range(db_numbers):
  # 如果current_db的值等于服务器的数据库数量
  # 这表示检查程序已经遍历了服务器的所有数据库一次
  # 将current_db重置为0，开始新的一轮遍历
  if current_db = server.dbnum
   current_db = 0
  
  # 获取当前要处理的数据库
  redisDb = server.db[current_db]
  
  # 将数据库索引增1，指向下一个要处理的数据库
  current_db += 1
  
  # 检查数据库键
  for j in range(DEFAULT_KEY_NUMBERS):
   # 如果数据库中没有一个键带有过期时间，那么跳过这个数据库
   if redisDb.expires.size() == 0: break
   # 随机获取一个带有过期时间的键
   key_with_ttl = redisDb.expires.get_random_key()
   
   # 检查键是否过期，如果过期就删除它
   if is_expired(key_with_ttl):
    delete_key(key_with_ttl)
   # 已达到时间上线，停止处理
   if reach_time_limit() :return
```
伪代码实现

activeExpireCycle函数的工作模式可以总结如下:
1.函数每次运行时，都从一定数量的数据库中取出一定数量的随机键进行检查，并删除其中的过期键
2.全局变量current_db会记录当前activeExpireCycle函数检查的进度，在下一次activeExpireCycle函数
被调用时，接着上一次的进度进行处理，比如说，如果当前activeExpireCycle函数在遍历10号数据库时
返回了，那么下次activeExpireCycle函数执行时，将从11号数据库开始查找并删除过期键
3.随着activeExpireCycle函数的不断执行，服务器中的所有数据库都会被检查一遍，这时函数将
current_db变量重置为0，然后再次开始新一轮的检查工作

举个例子，如果数据库中包含三个键k1、k2、k3，并且k2已经过期，那么当执行SAVE命令
或者BGSAVE命令时，程序只会将k1和k3的数据保存到RDB文件中，而k2则会被忽略。因此，
数据库中包含过期键不会对新生成的RDB文件造成影响。

举个例子，如果数据库中包含三个键k1、k2、k3，并且k2已经过期，那么当服务器
启动时:
1.如果服务器以主服务器模式运行，那么程序只会将k1和k3载入到数据库，k2会被忽略
2.如果服务器以从服务器模式运行，那么k1、k2和k3都会被载入到数据库

举个例子。如果客户端使用GET message命令，试图访问过期的message键，那么服务器
将执行以下三个动作:
1.从数据库中删除message键
2.追加一条DEL message命令到AOF文件
3.向执行GET命令的客户端返回空回复

举个例子，如果数据库中包含三个键,k1、k2、k3,并且k2已经过期，那么在进行重写工作时，
程序只会对k1和k3进行重写，而k2则会被忽略。因此，数据库中包含过期键不会对AOF重写
造成影响。

举个例子，有一对主从服务器，它们的数据库中都保存着同样的三个键message、xxx和yyy,
其中message位过期键

如果这时有客户端向从服务器发送命令GET message,那么从服务器将发现message键已经过期，
但从服务器并不会删除message键，而是继续将message键的值返回给客户端，就好像message
键并没有过期一样

假设在此之后，有客户端向主服务器发送命令GET message，那么主服务器将发现键message已经过期:
主服务器会删除message键，向客户端返回空回复，并向从服务器发送DEL message命令

从服务器在接收到主服务器发来的DEL message命令之后，也会从数据库中删除message键，在这
之后，主从服务器都不再保存过期键message了

SAVE和BGSAVE的区别。
创建RDB文件的实际工作由rdb.c/rdbSave函数完成，SAVE命令和BGSAVE命令会以不同的方式调用这个
函数，通过以下伪代码可以明显地看出这两个命令之间的区别:
```c
def SAVE():
 # 创建RDB文件
 rdbSave()
 
def BGSAVE():
 # 创建子进程
 pid = fork()
 
 if pid == 0:
  # 子进程负责创建RDB文件
  rdbSave()
  
  # 完成之后向父进程发送信号
  signal_parent();
 elif pid > 0:
  # 父进程继续处理命令请求，并通过轮询等待子进程的信号
  handle_request_and_wait_signal()
 else:
  # 处理出错情况
```

文件载入。
和使用SAVE命令或者BGSAVE命令创建RDB文件不同，RDB文件的载入工作是在服务器启动自动执行的，
所以Redis并没有专门用于载入RDB文件的命令，只要Redis服务器在启动时检测到RDB文件存在，它就会
自动z载入RDB文件。以下时Redis服务器启动时打印的日志记录，其中第二条日志DB loaded from disk....
就是服务器在成功RDB文件之后打印的:
```c
[95568] 24 Mar 12:01:29.565 # Server started, Redis version 3.0.504
[95568] 24 Mar 12:01:29.565 * DB loaded from disk: 0.000 seconds
[95568] 24 Mar 12:01:29.566 * The server is now ready to accept connections on port 6379
```

注意.
值得一提的是，因为AOF文件的更新频率通常比RDB文件的更新频率高，所以:
1.如果服务器开启了AOF持久化功能，那么服务器会优先使用AOF文件来还原数据库状态
2.只有在AOF持久化功能处于关闭状态时，服务器才会使用RDB文件来还原数据库状态。
服务器判断该用哪个文件来还原数据库状态的流程如图所示。

服务器在载入RDB文件期间，会一直处于阻塞状态，直到载入共工作完成为止。

SAVE命令执行时的服务器状态.
当SAVE命令执行时，Redis服务器会被阻塞，所以当SAVE命令正在执行时，客户端发送的
所有命令请求都会被阻塞。只有在服务器执行完SAVE命令、重新开始接受命令请求之后，客户端
发送的命令才会被处理

BGSAVE命令执行时的服务器状态。
因为BGSAVE的保存工作是由子进程执行的，所以在子进程创建RDB文件的过程中，Redis服务器
仍然可以继续处理客户端的命令请求，但是，在BGSAVE命令执行期间，服务器处理SAVE、BGSAVE、
BGREWRITEAOF三个命令的方式会和平时有所不同.
首先，在BGSAVE命令执行期间，客户端发送的SAVE命令会被服务器拒绝，服务器禁止SAVE命令和BGSAVE
命令执行是为了避免父进程(服务器进程)和子进程同时执行两个rdbSave调用，防止产生竞争条件。
其次，在BGSAVE命令执行期间，客户端发送的BGSAVE命令会被服务器拒绝，因为同时执行两个BGSAVE
会被服务器拒绝，因为同时执行两个BGSAVE命令也会产生竞争条件，代码如下
```c
127.0.0.1:6379> BGSAVE
Background saving started
127.0.0.1:6379> BGSAVE
(error) ERR Background save already in progress
```
最后，BGREWRITEAOF和BGSAVE两个命令不能同时执行：
1.如果BGSAVE命令正在z执行，那么客户端发送的BGREWRITEAOF命令会被延迟到BGSAVE命令执行完毕
之后执行
2.如果BGREWRITEAOF和BGSAVE两个命令的实际工作都由子进程执行，所以这两个命令在操作方面并没有
什么冲突的地方，不能同时执行它们只是一个性能方面的考虑——并发出两个子进程，并且这两个子进程都
同时执行大量的磁盘写入操作

举个例子，比如说，如果save选项的值为以下条件
```c
save 900 1
save 300 10
save 60 10000
```
那么服务器状态中的saveparams数组将会是如图所示

例如。如果我们为一个字符串键设置值:
```c
127.0.0.1:6379> SET message "hello"
OK
```
那么程序会将dirty计数器的值增加1。

又例如，如果像一个集合键增加三个新元素:
```c
127.0.0.1:6379> SADD database Redis MongoDB MariaDB
(integer) 3
```
那么程序会将dirty计数器的值增加3。

如图所示，该图展示了服务器状态中包含的dirty计数器和lastsave属性，
说明如下:
1.dirty计数器的值为123，表示服务器在上次保存之后对数据库状态共进行了123次修改
2.lastsave属性则记录了服务器上次执行保存的时间1378270800

检查保存条件是否满足。
以下伪代码z展示了serverCron函数检查保存条件的过程:
```python
def serverCron():
 # ...
 
 # 遍历所有保存条件
 for saveparam in servr.saveparams:
  # 计算距离上次执行保存操作有多少秒
  save_interval = unixtime_now() - server.lastsave
  
  # 如果数据库状态的修改次数超过条件所设置的次数
  # 并且距离上次保存的时间超过条件设置的时间
  # 那么执行保存操作
  if server.dirty >= saveparam.changes and 
   save_interval > saveparam.seconds:
   
   BGSAVE()
```
程序会遍历并检查saveparams数组中的所有保存条件，只要有任意一个条件被满足，
那么服务器就会执行BGSAVE命令。

重写后AOF文件里变成

如下两个配置可以控制AOF自动重写频率，当然AOF还可以手动重写，进入redis客户端执行命令
bgrewriteaof重写AOF,注意,AOF重写redis会fork出一个子进程去做(与bgsave命令类似)，不会对
redis正常命令处理有太多影响

AOF文件重写的实现。
虽然Redis将生成新AOF文件替换旧AOF文件的功能命名为"AOF文件重写"，但实际上，AOF文件
重写并不需要对现有的AOF文件进行任何读取、分析或者写入操作，这个功能是通过读取服务器当前的
数据库状态来实现的。

AOF后台重写。
虽然AOF重写程序aof_rewrite函数可以很好地完成创建一个新AOF文件的任务，但是，因为这个
函数会进行大量的写入操作，所以调用这个函数的线程将被长时间阻塞，因为Redis服务器使用单个
线程来处理命令请求，所以如果由服务器直接调用aof_rewrite函数的话，那么在重写AOF文件期间，
服务器将无法处理客户端发来的命令请求。
很明显，作为一种辅佐性的维护手段，Redis不希望AOF重写造成服务器无法处理请求，所以Redis决定
将AOF重写程序放到子进程里执行，这样做可以同时达到两个目的:
1.子进程进行AOF重写期间，服务器进程(父进程)可以继续处理命令请求
2.子进程带有服务器进程的数据副本，使用子进程而不是线程，可以在避免使用锁的情况下，保证数据的
安全性。
不过，使用子进程也有一个问题需要解决，因为子进程在进行AOF重写期间，服务器进程还需要继续处理
命令请求，而新的命令可能会对现有的数据库状态进行修改，从而使得服务器当前的数据库状态和重写后
的AOF文件所保存的数据库状态不一致。

文件的写入和同步。
为了提高文件的写入效率，在现代操作系统中，当用户调用write函数，将一些数据写入到文件的时候，
操作系统通产会将写入数据暂时保存在一个内存缓冲区里面，等到缓冲区的空间被填满，或者超过了指定
的时限之后，才真正地将缓冲区中的数据写入到磁盘里面。这种做法虽然提高了效率，但也为写入数据带来
了安全问题，因为如果计算机发生停机，那么保存在内存缓冲区里面的写入数据将会丢失。为此，系统提供
了fsync和fdatasync两个同步函数，它们可以强制让操作系统立即将缓冲区中的数据写入到硬盘里面，从而
确保写入数据的安全性

AOF持久化的效率和安全性。
服务器配置appendfsync选项的值直接决定AOF持久化功能的效率和安全性。
1.当appendfsync的值为always时，服务器在每个事件循环都要讲aof_buf缓冲区中的所有内容写入到AOF文件
并且同步AOF文件，所以always的效率时appendfsync选项三个当中最慢的一个，但从安全性来说，always也是
最安全的，因为即使出现故障停机，AOF持久化也只会丢失一个事件循环中所产生的命令数据
2.当appendfsync的值为everysec时，服务器在每个事件循环都要将aof_buf缓冲区中的所有内容写入到AOF文件
并且每隔一秒就要在子线程中对AOF文件进行一次同步。从效率上来讲，everysec模式足够快，并且就算出现故障
停机，数据库也只丢失一秒钟的命令数据
3.当appendfsync的值为no时，服务器在每隔事件循环都要将aof_buf缓冲区中的所有内容写入到AOF文件，至于
何时对AOF文件进行同步，则由操作系统控制。因为处于no模式下的flushAppendOnlyFile调用无须执行同步操作，
所以该模式下的AOF文件写入速度总是最快的，不过因为这种模式会在系统缓存中积累一段时间的写入数据，所以
该模式的单次同步时长通常是三种模式中时间最长的。从平摊操作的角度来看，no模式和everysec模式的效率类似，
当出现故障停机时，使用no模式的服务器将丢失上次同步AOF文件之后的所有写命令数据

例如，对于以下AOF文件来说
```c
*2
$6
SELECT
$1
0
*5
$4
SADD
$6
fruits
$6
banana
$6
cherry
$5
apple
*3
$3
SET
$3
msg
$5
hello
*5
$5
RPUSH
$7
numbers
$3
128
$3
256
$3
512
```

服务器首先读入并执行SELECT 0命令，之后是SET msg hello命令，在之后是SADD fruits apple banana cherry命令，
最后是RPUSH numbers 128 256 512 命令，当这些命令都执行完毕之后，服务器的数据库就被还原到之前的状态了,
整个重写过程可以用以下伪代码表示:
```c
def aof_rewrite(new_aof_file_name):
 # 创建新的AOF文件
 f = create_file(new_aof_file_name)
 # 遍历数据库
 for db in redisServr.db:
  # 忽略空数据
  if db.is_empth(): continue
  # 写入SELECT命令，指定数据库索引
  f.write_command("SELECT" + db.id)
  
  # 遍历数据库中的所有键
  for key in db:
   # 忽略已过期的键
   if key.is_expired(): continue
   
   # 根据键的类型对键进行重写
   if key.type == String:
    rewrite_string(key)
   elif key.type == List:
    rewrite_list(key)
   elif key.type == Hash:
    rewrite_hash(key)
   elif key.type == Set:
    rewrite.set(key)
   elif key.type == SortedSet:
    rewrite_sorted_set(key)
   
   # 如果键带有过期时间，那么过期时间也要被重写
   if key.have_expire_time():
    rewrite_expir_time(key)
# 写入完毕，关闭文件
f.close()

def rewrite_string(key):
 # 使用GET命令获取字符串键的值
 value = GET(key)
 
 # 使用SET命令重写字符串键
 f.write_command(SET,key,value)
 
def rewrite_list(key):
 # 使用LRANGE命令获取列表键包含的所有元素
 item1, item2, item3, ....itemN = LRANGE(key, 0, -1)
 
 # 使用RPUSH命令重写列表键
 f.write_command(RPUSH, key, item1, item2, item3,...,itemN)
 
def rewrite_hash(key):
 # 使用HGETALL命令后去哈希键包含的所有键值对
 field1, value1, field2, value2, fieldN, valueN = HGETALL(key)
 # 使用HMSET命令重写哈希键
 f.write_command(HMSET, key, field1, value1, field2,value2,...,fieldN, valueN)
 
def rewrite_set(key):
 # 使用SMEMBERS命令获取集合键包含的所有元素
 elem1, elem2, elem3,....,elemN = SMEMBERS(key)
 # 使用SADD命令重写集合键
 f.write_command(SADD, key, elem1, elem2,...elemN)
 
def rewrite_sorted_set(key):
 # 使用ZRANGE命令获取有序集合键包含的新元素
 member1,score1, member2,score2,..., memberN, scoreN = ZRANGE(key, 0, -1, "WOTJSCPRES")
 
 # 使用ZADD命令重写有序集合键
 f.write_command(ZADD, key, score1, memeber1, score2, member2, ...., scoreN, memberN)

def rewrite_expire_time(key):
 # 获取毫秒精度的键过期时间戳
 timestamp = get_expire_time_in_unixstamp(key)
 
 # 使用PEXIREAT命令重写键的过期时间
 f.write_command(PEXIREAT, key, timestamp
)
 
```

因为aof_rewrite函数生成的AOF文件只包含还原当前数据库状态所必须的命令，所以新AOF文件不会浪费任何硬盘空间

文件事件分派器接收IO多路复用程序传来的套接字，并根据套接字产生的事件
的类型，调用相应的事件处理器。
服务器会为执行不同任务的套接字关联不同的事件处理器，这些处理器是一个个函数,
它们定义了某个事件发生时，服务器应该执行的动作。

连接应答处理器。
networking.c/acceptTcpHandler函数是Redis的连接应答处理器，这个处理器用于对
连接服务器监听套接字的客户端进行应答，具体实现为sys/socket.h/accept函数的包装。
当Redis服务器进行初始化的时候，程序会将这个连接应答处理器和服务器监听套接字的
AE_READABLE事件关联起来，当有客户端用sys/socket.h/connect函数连接服务器监听
套接字的时候，套接字就会产生AE_READABLE事件，引发连接应答处理器执行，并执行
相应的套接字应答操作，，如图所示

命令请求处理器。
networking.c/readQueryFromClient函数是Redis的命令请求处理器，这个处理器负责
从套接字中读入客户端发送的命令请求内容，具体实现为unistd.h/read函数的包装。
当一个客户端通过连接应答处理器成功连接到服务器之后，服务器会将客户端套接字的
AE_READABLE事件和命令请求处理器关联起来，当客户端向服务器发送命令请求的时候，
套接字就会产生AE_READABLE事件，引发命令请求处理器执行，并执行相应的套接字读入
操作

命令回复处理器。
networking.c/sendReplyToClient函数是Redis的命令回复处理器，这个处理器负责将
服务器执行命令后得到的命令回复通过套接字返回给客户端，具体实现为unistd.h/write
函数的包装。当服务器有命令回复需要传送给客户端的时候，服务器会将客户端套接字的
AE_WRITABLE事件和命令回复处理器关联起来，当客户端准备好接收服务器传回的命令时，
就会产生AE_WRITABLE事件，引发命令回复处理器执行，并执行相应的套接字写入操作。
当命令回复发送完毕之后，服务器就会解除命令回复处理器与客户端套接字的AE_WRITABLE
事件之间的关联。

一次完整的客户端与服务器连接事件示例。
假设一个Redis服务器正在运作，那么这个服务器的监听套接字的AE_READABLE事件应该处于监听
状态之下，而该事件所对应的处理器为连接应答处理器。如果这时有一个Redis客户端向服务器发起
连接，那么监听套接字将产生AE_READABLE事件，触发连接应答处理器执行。处理器会对客户端的
连接请求进行应答，然后创建客户端套接字，以及客户端状态，并将客户端套接字的AE_READABLE事件
与命令请求处理器进行关联，使得客户端可以向主服务器发送命令请求。之后，假设客户端向主服务器
发送一个命令请求，那么客户端套接字将产生AE_READABLE事件，引发命令请求处理器执行，处理器
读取客户端的命令内容，然后传给相关程序去执行。
执行命令将产生相应的命令回复，为了将这些命令回复传送回客户端，服务器会将客户端套接字的AE_WRITABLE
事件与命令回复处理器进行关联。当客户端尝试读取命令回复的时候，客户端套接字将产生AE_WRITABLE事件，
触发命令回复处理器执行，当命令回复处理器将命令回复全部写入到套接字之后，服务器就会解除客户端
套接字的AE_WRITABLE事件与命令回复处理器之间的关联

举个例子。链表中包含了三个不同的时间事件:因为新的时间事件总是i插入到链表的表头，
所以三个时间事件分别按ID逆序排序，表头事件的ID为3，中间事件的ID为2，表尾事件的ID
为1.

将aeProcessEvents函数置于一个循环里面，加上初始化和清理函数，这就构成了Redis服务器的
主函数，以下是该函数的伪代码表示:
```python
def main():
 # 初始化服务器
 init_server()
 
 # 一直处理事件，直到服务器关闭为止
 while server_is_not_shutdown():
  aeProcessEvents()
  
 # 服务器关闭，执行清理操作
 clean_server()
```
从事件处理的角度来看，Redis服务器的运行流程可以用流程图来表示

事件的调度和执行规则:
1.aeApiPoll函数的最大阻塞事件由到达时间最接近当前时间的时间事件决定，这个方法既可以避免
服务器对时间事件进行频繁的轮询(忙等待)，也可以确保aeApiPoll函数不会阻塞过长时间
2.因为文件事件是随机出现的，如果等待并处理完一次文件事件之后，仍未有任何时间事件到达，
那么服务器将再次等待并处理文件事件。随着文件事件的不断执行，时间会逐渐向时间事件所设置
的到达时间逼近，并最终来到到达时间，这时服务器就可以开始处理到达的时间事件了
3.对文件事件和时间事件的处理都是同步的、有序、原子地执行的，服务器不会中途中断事件处理，
也不会对事件进行抢占，因此，不管是文件事件的处理器，还是时间事件的处理器，它们都会尽可能地
减少程序地阻塞时间，并在有需要时主动让出执行权，从而降低造成事件饥饿地可能性。比如说，在命令
回复处理器将一个命令回复写入到客户端套接字时，如果写入字节数超过了一个预设常量的话，命令回复
处理器就会主动用break跳出写入循环，将余下的数据留到下次再写；另外时间事件也会将非常耗时的
持久化操作放到子线程或者子进程执行
4.因为时间事件在文件事件之后执行，并且事件之间不会出现抢占，所以时间事件的实际处理事件，通常
回避时间事件设定的到达时间晚一些

举个例子。如图展示了一个客户端状态示例，根据name属性显示，
客户端的名字为"testName1"

PUBSUB命令和SCRIPT LOAD命令的特殊性。
通常情况下，Redis只会将那些对数据库进行了修改的命令写入到AOF文件，并复制到各个从服务器。
如果一个命令没有对数据库j进行任何修改，那么它就会被认为是只读命令，这个命令不会被写入到AOF
文件，也不会被复制到从服务器。以上规则适用于绝大部分Redis命令，但PUBSUB命令和SCRIPT LOAD
命令是其中的例外。PUBSUB命令虽然没有修改数据库，但PUBSUB命令向频道的所有订阅者发送消息
这一行为带有副作用，接收到消息的所有客户端的状态都会因为这个命令而改变。因此，服务器需要使用
REDIS_FORCE_AOF标志，强制将这个命令写入AOF文件，这样在将来载入AOF文件时，服务器就可以再次
执行相同的PUBSUB命令，并产生相同的副作用。SCIRPT LOAD命令的情况与PUBSUB命令类似:
虽然SCRIPT LOAD命令没有修改数据库，但它修改了服务器状态，所以它是一个带有副作用的命令，服务器
需要使用REDIS_FORCE_AOF标志，强制将这个命令写入AOF文件，使得将来在载入AOF文件时，服务器可以
产生相同的副作用。另外，为了让主服务器和从服务器都可以正确地载入SCRIPT LOAD命令指定的脚本，
服务器需要使用REDIS_FORCE_REPL标志，强制将SCIRPT LOAD命令复制给所有从服务器

举个flags属性的例子:
```c
# 客户端是一个主服务器
REDIS_MASTER
# 客户端正在被列表命令阻塞
REDIS_BLOCKED
# 客户端正在执行事务，但事务的安全性已被破坏
REDIS_MULTI | REDIS_DIRTY_CAS
# 客户端是一个从服务器，并且版本低于Redis2.8
REDIS_SLAVE | REDIS_PRE_PSYNC
# 这是专门用于执行Lua脚本包含的Redis命令的伪客户端
# 它强制服务器将当前的命令写入AOF文件，并复制给从服务器
REDIS_LUA_CLIENT | REDIS_FORCE_AOF | REDIS_FORCE_REPL
```

举个例子，如果客户端向服务器发送了以下命令请求:
```c
SET key value
```
那么客户端状态的qureybuf属性将是一个包含以下内容的SDS值
```c
*3\r\n$3\r\nSET\r\n$3\r\nkey\r\n$5\r\nvalue\r\n
```
如图所示占了这个SDS值以及querybuf属性的样子。输入缓冲区的大小会
根据输入内容动态地缩小或者扩大，但它的最大大小不能超过1GB，否则服务器
将关闭这个客户端

举个例子，图中展示的客户端状态中，argc属性的值伪3，而不是2，
因为命令的名字"SET"本身也是一个参数

图中演示了服务器在argv[0]为"SET"时，查找命令表并将客户端状态的
cmd指针指向目标redisCommand结构的整个过程。
针对命令表的查找操作不区分输入字母的大小写，所以无论argv[0]是"SET"、
"set" 、或者"Set"等等，查找的结构都是相同的。

如图展示了一个包含三个字符串对象的reply链表

举个例子，对于一个尚未进行身份验证的客户端来说，客户端状态的authenticated的属性如图所示.
当客户端authenticated属性的值为0时，除了AUTH命令之外，客户端发送的所有其他命令都会被
服务器拒绝执行:(前提是你需要设置密码requirepass)
redis.conf
```c
requirepass 1234
```
```c
(error) NOAUTH Authentication required.
127.0.0.1:6379> SET msg "hello world"
(error) NOAUTH Authentication required.
```

当客户端通过AUTH命令成功进入身份验证之后，客户端状态authenticated属性的值就会从0变为1，
如图所示，这时客户端就可以像往常一样向服务器发送命令请求了:
```c
127.0.0.1:6379> AUTH 1234
OK
127.0.0.1:6379> PING
PONG
127.0.0.1:6379> SET msg "hello world"
OK
```
authenticated属性仅在服务器启用了身份验证功能时使用，如果服务器没有启用身份验证功能的话，
那么即使authenticated属性的值为0(这是默认值),服务器也不会拒绝执行客户端发送的命令请求。

举个例子。假设当前有c1和c2两个普通客户端正在连接服务器，那么当一个新的
普通客户端c3连接到服务器之后，服务器会将c3所对应的客户端状态添加到clients
链表的末尾，如图所示，其中用虚线包围的就是服务器为c3新创建的客户端状态

举个例子，
```c
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 64
client-output-buffer-limit pubsub 32mb 8mb 60
```
第一行设置将普通客户端的硬性限制和软性限制都设置为0，表示不限制客户端的输出缓冲区大小
第二行设置将从服务器客户端的硬性限制设置为256MB,而软性限制设置为64MB,软性限制的时长为60s
第三行设置将执行发布与订阅功能的客户端的硬性限制设置为32MB,软性限制设置为8MB，软性限制的时长为60s

之后，服务器将通过命令执行器来完成执行命令所需的余下步骤

如表所示，sflags属性可以使用的标识值。

如图所示命令表，并以SET和GET命令作为例子。
1.SET命令的名字为"set"，实现函数为setCommand；m命令的参数个数为-3，表示命令接受
三个或以上数量的参数；命令的参数为"wm",表示SET命令式一个写入命令，并且在执行这个
命令之前，服务器应该对占用内存状况进行检查，因为这个命令可能会占用大量内存。
2.GET命令的名字为"get"，实现函数为getCommand函数；命令的参数个数为2，表示命令
的标识为"r",表示这是一个只读命令。

继续之前SET命令的例子，当程序以图中的argv[0]作为输入，在命令表中进行查找时，命令表
将返回"set"键所对应的redisCommand结构，客户端状态的cmd指针会指向这个redisCommand
结构

```c
127.0.0.1:6379> info server
# Server
redis_version:3.0.504
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:a4f7a6e86f2d60b3
redis_mode:standalone
os:Windows
arch_bits:64
multiplexing_api:WinSock_IOCP
process_id:5512
run_id:87544bbfd0b6ddf6c7168be02719f23b94c97a96
tcp_port:6379
uptime_in_seconds:95307
uptime_in_days:1
hz:10
lru_clock:581331
config_file:E:\redis\redis.windows-service.conf
```

```c
127.0.0.1:6379> info stats
# Stats
total_connections_received:3
total_commands_processed:16
instantaneous_ops_per_sec:0
total_net_input_bytes:542
total_net_output_bytes:2417
instantaneous_input_kbps:0.00
instantaneous_output_kbps:0.00
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:0
evicted_keys:0
keyspace_hits:1
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:69502
migrate_cached_sockets:0
```
上面命令的结果显示中，在最近的一秒钟内，服务器没有处理命令。
trackOperationPerSecond函数和服务器状态中四个ops_sec开头的属性有关:
```c
struct redisServer {
 // ...
 // 上一次进行抽样的时间
 long long ops_sec_last_sample_time;
 // 上一次抽样时，服务器已执行命令的数量
 long long ops_sec_last_sample_ops;
 // REDIS_OPS_SEC_SAMPLE 大小(默认值为16)的环形数组
 long long ops_sec_sample[REDIS_OPS_SEC_SAMPLES];
 // ops_sec_sample数组的索引值
 // 每次抽样后将值增一
 // 再值等于16时重置为0
 // 让ops_sec_samples数组构成一个唤醒数组
 int opts_sec_ids;
 // ...
}
```
trackOperationsPerSecond函数每次运行，都回根据ops_sec_last_sample_time记录的上一次抽样时间和服务器
的当前时间，以及ops_sec_last_sample_ops记录的上一次抽样的已执行命令数量和服务器当前的已执行命令数量，
计算出两次trackOperationsPerSecond调用之间，服务器平均每一毫秒处理了多少个命令请求，然后将这个平均值
乘以1000，这就得到了服务器在一秒钟内处理多少个命令请求的估计值，这个估计值会被作为一个新的数组项被放
进ops_sec_samples唤醒数组里面。当客户端执行INFO命令时，服务器就会调用getOperationsPerSecond函数，
根据ops_sec_samples唤醒数组中的抽样结果，计算出instantaneous_ops_per_sec属性的值，

以下是getOperationsPerSecond
函数的实现代码:
```c
long long getOperationsPerSecond(void) {
 int j;
 long long sum = 0;
 // 计算所有取样值综合
 for (j = 0; j < REDIS_OPS_SEC_SAMPLES; j++) {
  sum += server.ops_sec_samples[j];
 }
 // 计算取样的平均值
 return sum / REDIS_OPS_SEC_SAMPLES;
}
```
根据getOperationsPerSeoncd函数的定义可以看出，instantaneous_ops_per_sec
属性的值是通过计算最近REDIS_OPS_SEC_SAMPLES次取样的平均值来计算得出的，它只是
一个估算值。

整个检查过程如图所示。

不过，如果用户在启动服务器时为配置选项port指定了新值10086，那么server.port属性的值就会被更新为10086，
这将使得服务器的端口号从默认的6379变为yoghurt指定的10086.
例如，在初始化server变量时，程序会为决定数据库数量的dbnum属性设置默认值:
```c
void initServerConfig(void) {
 
 // ...
 
 // 默认值为16
 server.dbnum = REDIS_DEFUALT_DBNUM;
}
```
不过，如果用户在启动服务器时为选项databases设置了值32，那么server.dbnum属性的值就会被更新为32，这将
使得服务器的数据库数量从默认的16个变为用户指定的32个。
其他配置选项相关的服务器状态属性的情况与上面列举的port属性和dbnum属性一样:
1.如果用户为这些属性的相应选项指定了新的值，那么服务器就使用用户指定的值来更新相应的属性
2.如果用户没有为属性的相应选项设置新的值，那么服务器就沿用之前initServerConfig函数为属性的默认值。
服务器在载入用户指定的配置选项，并对server状态进行更新之后，服务器就可以进入初始化的第三个阶段——
初始化服务器数据结构

```c
file use E:\redis\redis-server.exe /path/to/redis.conf
                _._
           _.-``__ ''-._
      _.-``    `.  `_.  ''-._           Redis 3.0.504 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._
 (    '      ,       .-`  | `,    )     Running in standalone mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 6379
 |    `-._   `._    /     _.-'    |     PID: 20212
  `-._    `-._  `-./  _.-'    _.-'
 |`-._`-._    `-.__.-'    _.-'_.-'|
 |    `-._`-._        _.-'_.-'    |           http://redis.io
  `-._    `-._`-.__.-'_.-'    _.-'
 |`-._`-._    `-.__.-'    _.-'_.-'|
 |    `-._`-._        _.-'_.-'    |
  `-._    `-._`-.__.-'_.-'    _.-'
      `-._    `-.__.-'    _.-'
          `-._        _.-'
              `-.__.-'

[20212] 01 Apr 21:06:44.205 # Server started, Redis version 3.0.504
[20212] 01 Apr 21:06:44.210 * DB loaded from disk: 0.005 seconds
[20212] 01 Apr 21:06:44.210 * The server is now ready to accept connections on port 6379
```

举个例子。

举个例子，假设一个主服务器和一个从服务器刚刚完成同步操作，它们的数据库都保存了
相同的五个键k1至k5,如图所示，如果这是，客户端向主服务器发送命令DEL k3，那么主服务器
在执行完这个DEL命令之后，主从服务器的数据库将出现不一致:主服务器的数据库已经不再包含键
k3,但这个键却仍然包含在从服务器的数据库里面，如图所示.
为了让z主从服务器再次回到一致状态，主服务器需要对从服务器执行命令传播操作:主服务器会将
自己执行的写命令，也即是造成主从服务器不一致的那条写命令，发送给从服务器执行，当从服务器
执行了相同的写命令之后，主从服务器将再次回到y一致状态。

在上面的例子中，主服务器因为执行了命令DEL k3而导致主从服务器不一致，所以主服务器将向从服务器
发送相同的命令DEL k3。当从服务器执行完这个命令之后，主从服务器将再次回到一致状态，现在主从
服务器两者的数据库都不再包含键k3,

举个例子。主从服务器的复制偏移量的值都为10086。
如果这时主服务器向三个从服务器传播长度为33字节的数据，那么主服务器的复制偏移量将
更新为10086+33=10119,而三个服务器在接收到主服务器传播的数据之后，也会将偏移量
更新为10119，如图所示

举个例子，如果在向从服务器传播33字节数据之前，上图中的从服务器A断线了，那么主服务器传播的
数据将只有从服务器B和从服务器C能收到，在这之后，主服务器、从服务器B和从服务器C三个服务器的
复制偏移量都将更新为10119，而断线的从服务器A的复制偏移量仍然停留在10086，着说明从服务器A
与主服务器并不一致，如图所示.
假设从服务器A在断线之后就立即重新连接主服务器，并且成功，那么接下来，从服务器将向主服务器发送
PSYNC命令，报告从服务器A当前的复制偏移量为10086，那么这时，主服务器应该对从服务器执行完整
重同步还是部分重同步呢?如果执行部分重同步的话，主服务器又如何补偿从服务器A在断线期间丢失的那
部分数据呢?以上问题的答案都和复制积压缓冲区有关。

固定长度先进先出队列。
固定长度先进先出队列的入队和出队规则跟普通的先进先出队列一样:新元素从一边进入队列，而旧元素
从另一边弹出队列。和普通先进先出队列随着元素的增加和减少而动态调整长度不同，固定长度先进先出
队列的长度是固定的，当入队元素的数量大于队列长度时，最先入队的元素会被弹出，而新元素会被放入
队列。

举个例子。如上图中的断线后重连接：
1.当从服务器A断线之后，它立即重新连接主服务器，并向主服务器发送PSYNC命令，报告自己的复制
偏移量为10086.
2.主服务器收到从服务器发来的PSYNC命令以及偏移量10086之后，主服务器将检查偏移量10086之后的
数据是否存在于复制积压缓冲区里面，结果发现这些数据仍然存在，于是主服务器向从服务器发送+CONTINUE
回复，表示数据同步将以部分重同步模式来进行
3.接着主服务器会将复制积压缓冲区10086偏移量之后的所有数据(偏移量为10087至10119)都发送给从服务器
4.从服务器只要接收这33字节的缺失数据，就可以回到与主服务器一致的状态。如图所示

根据需要调整复制积压缓冲区的大小。
Redis为复制积压缓冲区设置的默认大小为1MB,如果主服务器需要执行大量写命令，又或者主从服务器断线后
重连接所需的时间比较长，那么这个大小也许并不合适。如果复制积压缓冲区的大小设置得不恰当，那么PSYNC
命令得复制重同步模式就不能正常发挥作用，因此，正确估算和设置复制积压缓冲区的大小非常重要。
复制积压缓冲区的最小大小可以根据公式seoncd * write_size_per_second来估算:
1.其中second为从服务器断线后重新连接上主服务器所需的平均时间(以秒计算)
2.而write_size_per_second则是主服务器平均每秒产生的写命令数据量(协议格式的写命令的长度总和)

例如，如果主服务器平均每秒产生1MB的写数据，而从服务器断线之后平均要5秒才能重新连接上服务器，那么
复制积压缓冲区的大小就不能低于5MB.
为了安全期间，可以将复制积压缓冲区的大小设为2 * second * write_size_per_second,这样可以保证绝大部分
断线情况都能用部分重同步来处理，至于复制积压缓冲区大小的修改方法，可以参考配置文件中关于
```c
repl-backlog-size
```

举个例子。假设从服务器原本正在复制一个运行ID为1的主服务器，那么在网络断开，从服务器
重新连接上主服务器之后，从服务器将向主服务器发送这个运行ID，主服务器根据自己的运行ID
是否为1来判断是否执行部分重同步还是执行完整重同步

流程图总结。

举个例子。
如果从服务器masterauth选项的值为100086，那么从服务器将向主服务器发送命令
AUTH 10086,如图所示。
从服务器在身份验证阶段可能遇到的情况有以下集中:
1.如果主服务器没有设置requirepass选项，并且从服务器也没有设置masteratuh选项，
那么主服务器将继续执行从服务器发送的命令，复制工作可以继续执行
2.如果从服务器通过AUTH命令发送的密码和主服务器requirepass选项所设置的密码相同，
那么主服务器将继续执行从服务器发送的命令，复制工作可以继续执行
3.如果主服务器设置了requirepass选项，但从服务器却没有设置masterauth选项，那么
主服务器将返回一个NOAUTH错误。另一方面，如果主服务器没有设置requirepass选项，
但从服务器却设置了masterauth选项，那么主服务器将返回一个no password is set错误。

流程图总结。

如图所示展示了客户端状态设置slave_listening_port属性之后的样子

举个例子。我们向主服务器提供以下配置:
```c
min-slaves-to-write 3
min-slaves-max-lag 10
```
那么在从服务器的数量少于3个，或者三个从服务器的延迟(lag)值
都大于或等于10秒时，主服务器将拒绝执行写命令，这里的延迟值就是
INFO replication命令的lag值

举个例子。假设有两个处于一致状态的主从服务器，它们的复制偏移量都是200，如图所示..
如果这时主服务器执行了命令SET key value(协议格式的长度为33字节)，将自己的复制偏移量
更新到了233，并尝试向从服务器传播命令SET key value，但这条命令却因为网络故障而在
传播的途中丢失，那么主从服务器之间的复制偏移量就会出现不一致，主服务器的偏移量会被
更新为233，而从服务器的复制偏移量仍然为200，如图所示。
在这之后，当从服务器向主服务器发送REPLCONF ACK命令的时候，主服务器会察觉从服务器
的复制偏移量依然为200，而自己的复制偏移量为233，这说明复制积压缓冲区里面复制偏移量
为201至233的数据(也即是命令SET key value)在传播过程中丢失了，于是主服务器会再次向
从服务器传播命令SET key value，从服务器通过接收并执行这个命令，可以将自己更新至
主服务器当前所处的状态，如图所示。

注意。
主服务器向从服务器补发缺失数据这一操作的原理和部分重同步操作的原理非常相似，这两个操作
的区别在于，补发缺失数据操作在主从服务器没有断线的情况下进行，而部分重同步操作则在主从
服务器断线并重连之后执行。

Redis2.8版本以前的命令丢失。
REPLCONF ACK命令和复制积压缓冲区都是Redis2.8版本新增的，在Redis2.8版本以前，即是命令
在传播过程中丢失，主服务器和从服务器都不会注意到，主服务器更不会向从服务器补发丢失的数据，
所以为了保证复制时主从服务器的数据一致性，最好使用Redis2.8版本以上的

```c
struct redisCommand redisCommandTable[] = {
    {"get",getCommand,2,"read-only fast @string",0,NULL,1,1,1,0,0,0},
{"getex",getexCommand,-2,"write fast @string",0,NULL,1,1,1,0,0,0},
{"set",setCommand,-3,"write use-memory @string",0,NULL,1,1,1,0,0,0},
{"setnx",setnxCommand,3,
     "write use-memory fast @string",0,NULL,1,1,1,0,0,0},
{"setex",setexCommand,4,"write use-memory @string",0,NULL,1,1,1,0,0,0},
{"append",appendCommand,3,"write use-memory fast @string",0,NULL,1,1,1,0,0,0},
{"strlen",strlenCommand,2,"read-only fast @string",0,NULL,1,1,1,0,0,0},
{"del",delCommand,-2,"write @keyspace",0,NULL,1,-1,1,0,0,0},
{"unlink",unlinkCommand,-2,"write fast @keyspace",0,NULL,1,-1,1,0,0,0},
{"exists",existsCommand,-2,"read-only fast @keyspace",0,NULL,1,-1,1,0,0,0},
{"mget",mgetCommand,-2,"read-only fast @string",0,NULL,1,-1,1,0,0,0},
// ....
}
```
redis.c/redisCOmmandTable命令表

```c
struct redisCommand sentinelcmds[] = {
    {"ping",pingCommand,1,"fast @connection",0,NULL,0,0,0,0,0},
    {"sentinel",sentinelCommand,-2,"admin",0,NULL,0,0,0,0,0},
    {"subscribe",subscribeCommand,-2,"pub-sub",0,NULL,0,0,0,0,0},
    {"unsubscribe",unsubscribeCommand,-1,"pub-sub",0,NULL,0,0,0,0,0},
    {"psubscribe",psubscribeCommand,-2,"pub-sub",0,NULL,0,0,0,0,0},
    {"punsubscribe",punsubscribeCommand,-1,"pub-sub",0,NULL,0,0,0,0,0},
    {"publish",sentinelPublishCommand,3,"pub-sub fast",0,NULL,0,0,0,0,0},
    {"info",sentinelInfoCommand,-1,"random @dangerous",0,NULL,0,0,0,0,0},
    {"role",sentinelRoleCommand,1,"fast read-only @dangerous",0,NULL,0,0,0,0,0},
    {"client",clientCommand,-2,"admin random @connection",0,NULL,0,0,0,0,0},
    {"shutdown",shutdownCommand,-1,"admin",0,NULL,0,0,0,0,0},
    {"auth",authCommand,-2,"no-auth fast @connection",0,NULL,0,0,0,0,0},
    {"hello",helloCommand,-1,"no-auth fast @connection",0,NULL,0,0,0,0,0},
    {"acl",aclCommand,-2,"admin",0,NULL,0,0,0,0,0,0},
    {"command",commandCommand,-1, "random @connection", 0,NULL,0,0,0,0,0,0}
};
```
sentinelcmds命令表

```c
typedef struct sentinelRedisInstance {
// 标识值,记录了实例的类型，以及该实例的当前状态
int flags;
// 实例的名字
// 主服务器的名字由用户在配置文件中设置
// 从服务器以及Sentinel的名字由Sentinel自动设置
// 格式为ip:port 例如"127.0.0.1:26379"
char *name;

// 实例的运行ID
char *runid;

// 配置纪元，用于实现故障转移
uint64_t coding_epoch;
// 实例的地址
sentinelAddr *addr;
// SENTINEL down-after-milliseconds选项设定的值
// 实例无响应多少毫秒之后才会被判断为主观下线(subjectively down)
mstime_t down_after_period;

// SENTINEL monitor <master-name> <IP> <port> <quorum>选项中的quorum参数
// 判断这个实例为客观下线(objectively down)所需的支持投票数量
int quorum;

// SENTINEL parallel-syncs <master-name> <number>选项的值
// 在执行故障转移操作时，可以同时对新的主服务器进行同步的从服务器数量
int parallel_syncs;
// SENTINEL failover-timeout <master-name> < ms> 选项的值
// 刷新故障迁移状态的最大时限
mstime_t failover_timeout;
// ....
} sentinelRedisInstance;
```
sentinelRedisInstance结构

举个例子。如果用户在启动Sentinel时，指定了包含以下内容的配置文件:
```c
# master1 configure
sentinel monitor master1 127.0.0.1 6379 2
sentinel down-after-milliseconds master1 3000
sentinel parallel-syncs master1 1
sentinel failover-timeout master1 900000
```
```c
# master2 configure
sentinel monitor master2 127.0.0.1 12345 5
sentinel down-after-milliseconds master2 50000
sentinel parallel-syncs master2 5
sentinel failover-timeout master2 450000
```
那么Sentinel将为主服务器master1创建如图所示的实例结构，并未主服务器master2
创建如图所示的实例结构，而这两个实例结构又会被保存到Sentinel状态的masters
字典中

为什么有两个连接?
在Redis目前的发布与订阅功能中，被发送的信息都不会保存在Redis服务器里面，
如果在信息发送时，想要接收信息的客户端不在线或者断线，那么这个客户端就会
丢失这条信息。因此，为了不丢失_sentinel_:hello频道的任何信息,Sentinel必须专门
用一个订阅连接来接收该频道的信息。
另一方面，除了订阅频道之外，Sentinel还必须向主服务器发送命令，以此来与主服务器
进行通信，所以Sentinel还必须向主服务器创建命令连接。因为Sentinel需要与多个实例
创建多个网络连接，所以Sentinel使用的是异步连接

补充
通过这两个连接，Sentinel 可以实时监控 Redis 实例的状态，并在发生故障时迅速做出反应。
此外，通过使用两个连接而不是一个，可以增加系统的健壮性，一旦其中一个连接出现问题，
Sentinel 仍然可以通过另一个连接与 Redis 进行通信，以继续执行监视和管理操作。
总之，Sentinel 向 Redis 主服务器创建两个连接是为了增强监视的可靠性和鲁棒性，
确保 Sentinel 能够及时感知到 Redis 实例的状态变化并采取相应的措施。

从服务器实例结构

举个例子。假设分别有127.0.0.1:26379、127.0.0.1:26380、1270.0.1:26381三个Sentinel正在
监视主服务器127.0.0.1:6379，那么当127.0.0.1:26379这个Sentinel接收到以下信息时:
```c
1."message"
2."_sentinel_:hello"
3."127.0.0.1,26379,a5bd47a1e569ed14567eca650de57f9d83301638,0,mymaster,127.0.0.1,6379,0"

1."message"
2."_sentinel_:hello"
3."127.0.0.1,26381,a5bd47a1e569ed14567eca650de57f9d83301637,0,mymaster,127.0.0.1,6379,0"

1."message"
2."_sentinel_:hello"
3."127.0.0.1,26380,a5bd47a1e569ed14567eca650de57f9d83301636,0,mymaster,127.0.0.1,6379,0"
```
Sentinel将执行以下动作:
1.第一条信息的发送者127.0.0.1:26379自己，这条信息会被忽略。
2.第二条信息的发送者为127.0.0.1:26381，Sentinel会根据这条信息中提取出的内容，对sentinels字典中的
127.0.0.1:26381对应的实例进行更新
3.第三条信息的发送者为127.0.0.1:26380，Sentinel会根据这条信息提取出的内容，对sentinels字典中的
127.0.0.1:26380所对应的实例结构进行更新
图中展示了Sentinel127.0.0.1:26379为主服务器127.0.0.1:6379创建的实例结构，以及结构中的sentinels字典
和127.0.0.1:26379一样，其他两个Sentinel也会创建类似于图中所示的sentinels字典，区别在于字典中保存的
Sentinel信息不同:
1.127.0.0.1:26380创建的sentinels字典会保存127.0.0.1:26379和127.0.0.1:26381两个Sentinel的信息
2.而127.0.0.1:23681创建的sentinels字典则会保存127.0.0.1:26379和127.0.0.1:26380两个Sentinel的信息

因为一个Sentinel可以通过分析接收到的频道信息来获知其他Sentinel的存在，并通过发送频道信息来让其他
Sentinel知道自己的存在，所以用户在使用Sentinel的时候并不需要提供各个Sentinel的地址信息，监视同一个
主服务器的多个Sentinel可以自动发现对方

Sentinel之间不会创建订阅连接。
Sentinel在连接主服务器或者从服务器时，会同时创建命令连接和订阅连接，但是在连接其他Sentinel时，
却只会创建命令连接，而不创建订阅连接。这是因为Sentinel需要通过接收主服务器或者从服务器发来的
频道信息来发现未知的新Sentinel，所以才需要建立订阅连接，而相互已知的Sentinel只要使用命令连接
来进行通信就足够了

举个例子，如果被Sentinel判断为主观下线的主服务器的IP为127.0.0.1，端口号为6379，
并且Sentinel当前的配置纪元为0，那么Sentinel将向其他Sentinel发送以下命令:
```c
SENTINEL is-master-down-by-addr 127.0.0.1 6379 0 *
```

举个例子。如果一个Sentinel返回以下回复作为SENTINEL is-master-down-by-addr命令的回复:
```c
1.1
2.*
3.0
```
那么说明Sentinel也同意主服务器已下线

新的主服务器是怎样挑选出来的。
领头Sentinel会将已下线主服务器的所有从服务器保存到一个列表里面，然后按照以下规则，一项一项地对列表进行过滤:
1.删除列表中所有处于下线或者断线状态的从服务器，这可以保证列表中剩余的从服务器都是正常在线
2.删除列表中所有最近五秒内没有回复过领头Sentinel的INFO命令的从服务器
3.删除所有与已下线主服务器连接断开超过down-after-milliseconds * 10 毫秒的从服务器:down-after-milliseconds选项
指定了判断主服务器下线所需的时间，而删除断开时长超过down-after-milliseconds * 10 毫秒的从服务器，则可以保证列表
中剩余的从服务器都没有过早地与主服务器断开连接，换句话说，列表中剩余的从服务器保存的数据都是比较新的。
之后，领头Sentinel将根据从服务器的优先级，对列表中剩余的从服务器进行排序，并选出其中优先级最高的从服务器。如果
有多个具有相同最高优先级的从服务器，那么领头Sentinel将按照从服务器的复制偏移量，对具有相同最高优先级的所有从服务器
进行排序，并选出其他偏移量最大的从服务器(复制偏移量最大的从服务器就是保存着最新数据的从服务器)。最后，如果有多个
优先级最高、复制偏移量最大的从服务器，那么领头Sentinel将按照运行ID对这些从服务器进行排序，并选出其中运行ID最小的服务器

举个例子。如图展示了在一次故障转移操作中，领头Sentinel向选中的从服务器server2发送SLAVEOF no one命令的情形。
在发送SLAVEOF no one命令之后，领头Sentinel会以每秒一次的频率(平时是每十秒一次)，向被升级的从服务器发送INFO
命令，并观察命令回复中的角色(role)信息，当被升级服务器的role从原来的slave变为master时，领头Sentinel就知道被选中
的从服务器已经顺利升级为主服务器了

如果在上图的例子中，领头Sentinel会一直向server2发送INFO命令，当server2返回的命令回复从:
```c
# Replcation
role:slave
...
# Other sections
...
```
变为：
```c
# Replication
role:master
...
# Other sections
...
```
的时候，领头Sentinel就知道server2已经成功升级为了主服务器了。
当server2升级成功之后，各个服务器和领头Sentinel如图所示

server3和server4成为server2的从服务器

1.三个独立的节点

2.节点7000和7001进行握手

3.握手成功的7000与7001处于同一个集群

4.节点7000与节点7002进行握手

5.握手成功的三个节点处于同一个集群

```c
struct clusterNode {
// 创建节点的时间
mstime_t ctime;

// 节点的名字，由40个十六进制字符组成
// 例如ceb9e23e93e0aae13e5333f50d39336a97e5cba3
char name[REDIS_CLUSTER_NAMELEN];

// 节点标识
// 使用各种不同的标识值记录节点的角色(比如主节点或者从节点)
// 以及节点目前所处的状态(比如在线或者下线)
int flags;

// 节点当前的配置纪元，用于实现故障转移
uint64_t configEpoch;

// 节点的IP地址
char ip[REDIS_IP_STR_LEN];

// 节点的端口号
int port;

// 保存连接节点所需的有关信息
clusterLink *link;
// ...
};
```
clusterNode结构

```c
typedef struct clusterLink {
// 连接的创建时间
mstime_t ctime;
// TCP 套接字描述符
int fd;
// 输出缓冲区，保存着等待发送给其他节点的消息(message)
sds sndbuf;
// 输入缓冲区，保存着从其他节点接收到的消息
sds rcvbuf;
// 与这个连接相关联的节点，如果没有的话就为NULL
struct clusterNode *node;
}clusterLink;
```
clusterLink结构

```c
typedef struct clusterState {
// 指向当前节点的指针
clusterNode *myself;

// 集群当前的配置纪元，用于实现故障转移
uint64_t currentEpoch;

// 集群当前的状态:是在线还是下线
int state;

// 集群中至少处理着一个槽的节点的数量
int size;

// 集群节点名单(包括myself节点)
// 字典的键为节点的名字，字典的值为节点对应的clusterNode结构
dict *nodes;

// ...
}clusterState;
```
clusterState结构

redisClient结构和clusterLink结构的相同和不同之处。
redisClient结构和clusterLink结构都有自己的套接字描述符和输入、输出缓冲区，这两个结构的区别在于，
redisClient结构中的套接字和缓冲区是用于连接客户端的，而clusterLink结构中的套接字和缓冲区是用于
连接节点的。

举个例子。以前面介绍的7000、7001、7002三个节点为例，如图展示了节点7000创建的clusterState结构，
这个结构从节点7000的角度记录了集群以及集群包含的三个节点的当前状态:
1.结构的currentEpoch属性的值为0，表示集群当前的配置纪元为0
2.结构的size属性的值为0，表示集群目前没有任何节点在处理槽，因此结构的state属性的值为REDIS_CLUSTER_FAIL,
这表示集群目前处于下线状态
3.结构的nodes字典记录了集群目前包含的三个节点，这三个节点分别由clusterNode结构表示，其中myself指针指向
代表节点7000的clusterNode结构，而字典中的另外两个指针则分别指向节点7001和代表节点7002的clusterNode
结构，这两个节点是节点7000已知的在集群中的其他节点
4.三个节点的clusterNode结构的flags属性都是REDIS_NODE_MASTER,说明三个节点都是主节点。
节点7001和节点7002也会创建类似的clusterState结构：
1.不过在节点7001创建的clusterState结构中，myself指针将指向代表节点7001的clusterNode结构，而节点7000和
节点7002则是集群中的其他节点.
2.而在节点7002创建的clusterState结构中，myself指针将指向代表节点7002的clusterNode结构，而节点7000和节点
7001则是集群中的其他节点。

举个例子。如图展示了一个slots数组的示例:这个数组索引0至索引7上的二进制位的值都为1,
其余所有二进制位的值都为0，这表示节点负责处理槽0至槽7

如图展示了另一个slots数组示例:这个数组索引1、3、5、8、9、10上的二进制位的值都为1，
而其余所有二进制位的值都为0，这表示节点负责处理1、3、5、8、9、10

举个例子，对于前面展示的7000、7001、7002三个节点的集群来说:
1.节点7000会通过消息向节点7001和节点7002发送自己的slots数组，以此来告知两个节点，自己负责
处理槽0至槽5000，如图所示
2.节点7001会通过消息向节点7000和节点7002发送自己的slots数组，以此来告知两个节点，自己负责
处理槽5001至槽10000，如图所示
3.节点7002会通过消息向节点7000和节点7001发送自己的slots数组，以此来告知两个节点，自己负责
处理槽10001至槽16383，如图所示

举个例子，对于7000、7001、7002三个节点来说，它们的clusterState结构的slots数组将会是如图所示的样子:
1.数组项slots[0]至slots[5000]的指针都指向7000的clusterNode结构，表示槽0至5000都指派给了节点7000
2.数组项slots[5001]至slots[10000]的指针都指向代表节点7001的clusterNode结构，表示槽5001至槽10000都
指派给了节点7001
3.数组项slots[10001]至slots[16383]的指针都指向代表节点7002的clusterNode结构，表示槽10001至槽16383
都指派给了节点7002

举个例子，对于上图中的slots数组来说，如果程序需要直到槽10002被指派给了哪个节点，那么只需要访问
数组项slots[10002]，就可以马上直到槽10002被指派给了节点7002，如图所示

要说明的一点是，虽然slutserState.slots数组记录了集群中素有槽的指派信息，但使用clusterNode结构的slots
数组来记录单个节点的槽指派信息仍然是有必要的:
1.因为当程序需要将某个节点的槽指派信息通过消息发送给其他节点时，程序只需要将相应节点的clusterNode.slots
数组整个发送出去就可以了
2.另一方面，如果Redis不使用clusterNode.slots数组，而单独使用clusterNode.slots数组的话，那么每次要将节点A
的槽指派信息传播给其他节点时，程序必须先遍历整个clusterState.slots数组，记录节点A负责处理哪些槽，然后才能
发送节点A的槽指派信息，这比直接发哦是那个clusterNode.slots数组要麻烦和低效得多。
clusterState.slots数组记录了集群中所有槽的指派信息，而clusterNode.slots数组只记录了clusterNode结构所代表的
节点的槽指派信息，这时两个slots数组的关键区别所在

举个例子。如图展示了一个节点的clusterState结构，clusterState.slots数组中的所有指针都指向NULL,
并且clusterNode.slots数组中的所有二进制位的值都是0，这说明当前节点没有被指派任何槽，并且集群
中的所有槽都是未指派的。当客户端对如图所示的节点执行命令:
```c
CLUSTER ADDSLOTS 1 2
```
将槽1和槽2指派给节点之后，节点的clusterState结构将被更新为如图所示的样子:
1.clusterState.slots数组在索引1和索引2上的指针指向了代表当前节点的clusterNode
2.并且clusterNode.slots数组在索引1和索引2上的为止被设置成了1

最后，在CLUSTER ADDSLOTS命令执行完毕之后，节点会通过发送消息告知集群中的其他节点，自己目前
正在处理哪些槽

举个例子。假设如图所示为节点7000的clusterState结构:
1.当客户端向节点7000发送命令SET date "2024-04-10"的时候，节点首先计算出键date属于槽2022，
然后检查得出clusterState.slots[2022]等于clusterState.myself,这说明槽2022正是由节点7000负责，
于是节点7000直接执行这个SET命令，并将结果返回发送命令的客户端
2.当客户端向节点7000发送命令SET msg "happy new year!"的时候，节点首先计算出键msg属于槽6257,
然后检查clusterState.slots[6257]是否等于clusterState.myself,结果发现两者并不相等:这说明槽6257并非
由节点7000负责处理，于是节点7000访问clusterState.slots[6257]所指向的clusterNode结构，并根据
结构中记录的IP地址127.0.0.1和端口号7001,向客户端返回错误MOVED 6257 127.0.0.1:7001,指引节点
转向至正在负责处理槽6257的节点7001

如图所示展示了客户端向节点7000发送SET命令，并获得MOVED错误的过程

客户端根据MOVED错误，转向至节点7001，并重新发送SET命令的过程

一个集群客户端通常会与集群中的多个节点创建套接字连接，而所谓的节点转向
实际上就是换一个套接字来发送命令。如果客户端尚未与想要转向的节点创建套接字连接，
那么客户端会先根据MOVED错误提供的IP地址和端口号来连接节点，然后再进行转向

被隐藏的MVOED错误。
集群模式的redis-cli客户端在接收到MOVED错误时，并不会打印出MOVED错误，而是根据
MOVED错误自动进行节点转向，并打印出转向信息，所以是看不见节点返回的MOVED错误的
```c
redis-cli -c -p 7000 #集群模式

127.0.0.1:7000> SET msg "happy new year!"
-> Redirected to slot[6257] located at 127.0.0.1:7001
OK
```
但是如果，使用单机(stand alone)模式的redis-cli客户端，再次向节点7000发送相同的命令，那么
MOVED错误就会被打印出来:
```c
redis-cli -p 7000 # 单机模式
127.0.0.1:7000> SET msg "happy new year!"
(error) MOVED 6257 127.0.0.1:7001
```
这是因为单机模式的redis-cli客户端不清除MOVED错误的作用，所以它只会直接将MOVED错误直接
打印出来，而不会进行自动转向。

举个例子。如图展示了节点7000的数据库状态，数据库中包含列表键"lst"，哈希键"book"，以及字符串键"date",
其中键"lst"和键"book"带有过期时间。另外除了将键值对保存在数据库里面之外，节点还会用clusterState结构中的
slots_to_keys跳跃表来保存槽和键之间的关系:
```c
typedef struct clusterState {
//...
zskiplist *slot_to_keys;
// ...
}clusterState;
```

举个例子。对于上图所示的数据库，节点7000将创建类似如图所示的slots_to_keys跳跃表:
1.键"book"所在跳跃表节点的分值为1337.0,这表示键"book"所在的槽位1337
2.键"date"所在跳跃表节点的分值位2022.0，这表示键"date"所在的槽为2022
3.键"lst"所在跳跃表节点的分值为3347.0，这表示键"lst"所在的槽为3347

通过在slots_to_keys跳跃表中记录各个数据库键所属的槽，节点可以很方便地对属于某个或
某些槽的所有数据库进行批量操作，例如命令CLUSTER GETKEYSINSLOT <slot><count>命令
可以返回最多count个属于槽slot的数据库键，而这个命令就是通过遍历slots_to_keys跳跃表来实现的

举个例子。
如果客户端向节点7003发送以下命令:
```c
# b4348045d1eadca5abd96b8d0d13b0309ed117e1 是节点7002的id
127.0.0.1:7003> CLUSTER SETSLOT 16198 IMPORTING  b4348045d1eadca5abd96b8d0d13b0309ed117e1
OK
```
那么节点7003的clusterState.importing_slots_from数组将变成如图所示的样子。

举个例子。如果客户端向节点7002发送以下命令:
```c
# b4348045d1eadca5abd96b8d0d13b0309ed117e1 是节点7003的ID
127.0.0.1:7002>CLUSTER SETSLOT 16198 MIGRATING  b4348045d1eadca5abd96b8d0d13b0309ed117e1
``` 
那么节点7002的clusterstate.migrating_slots_to数组将变成如图所示的样子

举个例子。假设在节点7002向节点7003迁移槽16198期间，有一个客户端向节点发送命令：
```c
GET "love"
```
因为键"love"正好属于槽16198，所以节点7002会首先在自己的数据库中查找键"love",但并没有
找到，通过检查自己的clusterState.migrating_slots_to[16198]，节点7002发现自己正在将槽16198
迁移至节点7003，于是它向客户端返回错误:
```c
ASK 16198 127.0.0.1:7003
```
这个错误表示客户端可以尝试到IP为127.0.0.1，端口号为7003的节点去执行和槽16198有关的操作，
如图所示.接到ASK错误的客户端会根据错误提供的IP地址和端口号，转向至正在导入槽的目标节点，
然后首先向目标节点发送一个ASKING命令，之后再重新发送原本想要执行的命令。
当客户端接收到节点7002返回的以下错误时:
```c
ASK 16198 127.0.0.1:7003
```
客户端会转向至节点7003，首先发送命令:
```c
ASKING
```
然后再次发送命令:
```c
GET "love"
```
并获得回复:
```c
"you get the key 'love'"
```

举个例子，我们可以使用普通模式的redis-cli客户端，向正在导入槽16198的节点7003发送以下命令:
```c
./redis-cli -p 7003
127.0.0.11:7003> GET "love"
(error) MOVED 16198 127.0.0.1:7002
```
虽然节点7003正在导入槽16198，但槽16198目前仍然是指派给了节点7002，所以节点7003会向客户端
返回MOVED错误，指引客户端转向节点7002.但是，如果我们在发送GET命令之前，先向节点发送一个
ASKING命令，那么这个GET命令就会被节点7003执行:
```c
127.0.0.1:7003> ASKING
OK
127.0.0.1:7003> GET "love"
"you get the key 'love'"
```
另外要注意的是，客户端的REDIS_ASKING标识是一个一次性标识，当节点执行了一个带有REDIS_ASKING标识
的客户端发送的命令之后，客户端的REDIS_ASKING标识就会被移除。

举个例子。如果我们在成功执行GET命令之后，再次向节点7003发送GET命令，那么第二次发送的GET命令将执行
失败，因为这时客户端的REDIS_ASKING标识已经被移除:
```c
127.0.0.1:7003> ASKING # 打开REDIS_ASKING标识
OK
127.0.0.1:7003> GET "love" # 移除REDIS_ASKING标识
"you get the key 'love'"
127.0.0.1:7003> GET 'love' # REDIS_ASKING 标识未打开，执行失败
(error) MOVED 16198 127.0.0.1:7002
```

节点7004成为新的主节点

举个例子。图中记录了节点7004和节点7005成为节点7000的从节点之后，集群中的各个节点为节点7000
创建的clusterNode结构的样子:
1.代表节点7000的clusterNode结构的numslaves属性的值为2，这说明有两个从节点正在复制节点7000
2.代表节点7000的clusterNode结构的slaves数组的两个项分别指向代表节点7004和代表节点7005的clusterNode结构
这说明节点7000的两个从节点分别是节点7004和节点7005

举个例子。如果节点7001向节点7000发送了一条PING消息，但是节点7000没有在规定的时间内，向节点7001返回一条PONG消息，
那么节点7001就会在自己的clusterState.nodes字典中找到7000所对应的clusterNode结构，并在结构的flags属性中打开REDIS_NODE_PFAIL标识，
以此表示节点7000进入了疑似下线状态，如图所示

举个例子。如果主节点7001在收到主节点7002、主节点7003发送的消息后得知，主节点7002和主节点7003都认为主节点7000进入了
疑似下线状态，那么主节点7001将为主节点7000创建如图所示的下线报告.

举个例子，对于上图所示的下线报告来说，主节点7002和主节点7003都认为主节点7000进入了下线状态，并且主节点70001也认为主节点7000
进入了疑似下线状态(代表主节点7000的结构打开了REDIS_NODE_PFAIL标识),综合起来在集群四个负责处理槽的主节点里面，有三个主节点都
将主节点标记为下线，数量已经超过了半数，所以主节点7001会将主节点7000标记为已下线，并向集群广播一条关于主节点7000的FAIL消息，
如图所示

```c
typedef struct {
// 消息的长度(包括这个消息头的长度和消息正文的长度)
uint32_t totlen;

// 消息的类型
uint16_t type;

// 消息正文包含的节点信息数量
// 只在发送MEET、PING、PONG这三种Gossip协议信息时使用
uint16_t count;

// 发送者所处的纪元
uint64_t currentEpoch;

// 如果发送者是一个主节点，那么这里记录的是发送者的配置纪元
// 如果发送者是一个从节点，那么这里记录的是发送者正在复制的主节点的配置纪元
uint64_t configEpoch;

// 发送者的名字(id)
char sender[REDIS_CLUSTER_NAMELEN];

// 发送者目前的槽指派信息
unsigned char myslots[REDIS_CLUSTER_SLOTS/8];
// 如果发送者是一个从节点，那么这里记录的是发送者正在复制的主节点的名字
// 如果发送者是一个主节点，那么这里记录的是REDIS_NODE_NULL_NAME
char slaveof[REDIS_CLUSTER_NAMELEN];
// 发送者的端口号
uint16_t port;
// 发送者的标识值
uint16_t flags;

// 发送者所处集群的状态
unsigned char state;
// 消息的正文(或者说，内容)
unio clusterMsgData data;
}clusterMsg;
```
clusterMsg结构表示

```c
union clusterMsgData {
struct {
// MEET、PING、PONG消息都包含两个clusterMsgDataGossip结构
clusterMsgDataGossip gossip[1];
} ping;

// FAIL消息的正文
struct {
clusterMsgDataFail abount;
}fail;

// PUBLISH消息的正文
struct {
clusterMsgDataPublish msg;
}publish;

// 其他消息正文...
}
```
clusterMsgData表示:

举个发送PING消息和返回PONG消息的例子，假设在一个包含A、B、C、D、E、F六个节点的集群里:
1.节点A向节点D发送PING消息，并且消息里面包含了节点B和节点C信息，当节点D接收到这条信息,
它将更新自己对节点B和节点C的认知
2.之后，节点D将向节点A返回一条PONG消息，并且消息里面包含了节点E和节点F的消息，当节点A接收到
这条PONG消息时，它将更新自己对节点E和节点F的认知。

举个例子。对于包含7000、7001、7002、7003四个主节点的集群来说:
1.如果主节点7001发现主节点7000已下线，那么主节点7001将向主节点7002和主节点7003发送FAIL消息，
其中FAIL消息中包含的节点名字为主节点7000的名字，以此来表示主节点7000已下线
2.当主节点7002和主节点7003都接收到主节点7001发送的FAIL消息时，它们也会将主节点7000标记为已下线
3.因为这时集群已经有超过一半的主节点认为主节点7000已下线，所以集群剩下的几个主节点可以判断是否需要
将集群标记为下线，又或者开始对主节点7000进行故障转移

图中展示了节点发送和接收FAIL消息的整个过程

举个例子。对于包含7000、7001、7002、7003四个节点的集群来说，如果节点7000收到了
客户端发送的PUBLISH命令，那么节点7000将向7001、7002、7003三个节点发送PUBLISH消息，
如图所示

举个例子。如果节点收到的PUBLISH命令为:
```c
PUBLISH "news.it" "hello"
```
那么节点发送的PUBLISH消息的clusterMsgDataPublish结构将如图所示:
其中bulk_data数组的前七个字节保存了channel参数的值"news.it"而bulk_data数组的后五个字节
则保存了message参数的值"hello"

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

举个例子。假设服务器pubsub_channels字典的当前状态如图所示，那么当客户端client-10086执行命令
```c
SUBSCRIBE "news.sport" "news.movie"
```
之后，pubsub_channels字典将更新至如图所示的状态，其中用虚线包围的是新添加的节点:
1.更新后的pubsub_channels字典新增了"news.movie"键，该键对应的链表值只包含一个client-10086节点，
表示目前只有client-10086一个客户端在订阅"news.movie"频道
2.至于原本就已经有客户端在订阅的"news.sport"频道，client-10086的节点放在了频道对应链表的末尾，
排在client-4节点的后面

SUBSCRIBE命令的实现可以用以下伪代码来描述:
```c
def subscribe(*all_input_channels):
# 遍历输入的所有频道
for channel in all_input_channels:
# 如果channel不存在于pubsub_channels字典(没有任何订阅者)
# 那么在字典中添加channel键，并设置它的值为空链表
if channel not in server.pubsub_channels:
server.pubsub_channels[channel] = []

# 将订阅者添加到频道所对应的链表的末尾
server.pubsub_channels[channel].append(client)
```

举个例子，假设pubsub_channels的当前状态如图所示，那么当客户端client-10086执行命令:
```c
UNSUBSCRIBE "news.sport" "news.movie"
```
之后，图中用虚线包围的两个节点将被删除如图所示
1.在pubsub_channels字典更新之后，client-10086的信息已经从"news.sport"频道和"news.movie"频道
的订阅者链表中被删除了
2.另外，因为删除client-10086之后，频道"news.movie"已经没有任何订阅者，因此键"news.movie"也从
字典中被删除了

UNSUBSCRIBE命令的实现可以用以下伪代码来描述:
```c
def unsubscribe(*all_input_channels):
# 遍历要退订的所有频道
for channel in all_input_channels:
# 在订阅者链表中删除退订
server.pubsub_channels[channel].remove(client);

# 如果频道已经没有任何订阅者(订阅者链表为空)
# 那么将频道从字典中删除
if len(server.pubsub_channels[channel]) == 0:
server.pubsub_channels.remove(channel)
```

举个例子，假设服务器中的pubsub_pattern链表的当前状态如图所示。
当客户端client-9执行命令:
```c
PSUBSCRIBE "news.*"
```
之后，pubsub_patterns链表将更新至如图所示的状态，其中用虚线包围的是新添加的pubsubPattern结构

PSUBSCRIBE命令的实现原理可以用以下伪代码来描述
```c
def psubscribe(*all_input_patterns):
# 遍历输入的所有模式
for pattern in all_input_patterns:
# 创建新的pubsubPattern结构
# 记录被订阅的模式，以及订阅模式的客户端
pubsubPattern = create_new_pubsubPattern()
pubsubPattern.client = client
pubsubPattern.pattern = pattern

# 将新的pubsubPattern追加到pubsub_patterns链表末尾
server.pubsub_patterns.append(pubsubPattern)
```

举个例子。假设服务器pubsub_patterns链表的当前状态如图所示，当客户端client-9执行命令:
```c
PUNSUBSCRIBE "news.*"
```
之后，client属性为client-9，pattern属性为"news.*"的pubsubPattern结构将被删除，pubsub_patterns链表
将更新至如图所示的样子

PUNSUBSCRIBE命令的实现原理可以用以下伪代码来描述
```c
def punsubscribe(*all_input_patterns):
# 遍历所有要退订的模式
for pattern in all_input_patterns:
# 遍历pubsub_patterns
for pubsubPattern in server.pubsub_patterns:
# 如果当前客户端和pubsubPattern记录的客户端相同
# 并且要退订的模式也和pubsubPattern记录的模式相同
if client == pubsubPattern.client and \ pattern == pubsubPattern.pattern:

# 那么将这个pubsubPattern从链表删除
server.pubsub_patterns.remove(pubsubPattern)
```

举个例子。假设服务器pubsub_channels字典当前的状态如图所示,
如果这时某个客户端执行命令
```c
PUBLISH "news.it" "hello"
```
那么PUBLISH命令将在pubsub_channels字典中查找键"news.it"对应的链表值，并
通过遍历链表将消息"hello"发送给"news.it"频道的三个订阅者:client-1、client-2、client-3

PUBLISH命令将消息发送给频道订阅者的方法可以用以下伪代码来描述:
```c
def channel_publish(channel, message):
# 如果channel键不存在于pubsub_channels字典中
# 那么说明channel频道没有任何订阅者
# 程序不做发送动作，直接返回
if channel not in server.pubsub_channels:
return

# 运行到这里，说明channel频道至少有一个订阅者
# 程序遍历channel频道的订阅者链表
# 将消息发送给所有订阅者
for subscriber in server.pubsub_channels[channel]:
send_message(subscriber, message)
```

举个例子。假设pubsub_patterns链表的当前状态如图所示。
如果这时客户端执行命令
```c
PUBLISH "news.it" "hello"
```
那么PUBLISH命令会首先将消息"hello"发送给"news.it"频道的所有订阅者，
然后开始在pubsub_patterns链表中查找是否有被订阅的模式与"news.it"频道相匹配，
结果发现"news.it"频道和客户端client-9订阅的"news.*"频道匹配，于是命令将消息"hello"
发送给客户端client-9

PUBLISH命令将消息发送给模式订阅者的方法可以用以下伪代码来描述:
```c
def pattern_publish(channel, message):
# 遍历所有模式订阅消息
for pubsubPattern in server.pubsub_patterns:
# 如果频道和模式相匹配
if match(channel, pubsubPattern.pattern):
# 那么将消息发送给订阅该模式的客户端
send_message(pubsubPattern.client, message)
```
最后，PUBLISH命令的实现可以用以下伪代码来描述:
```c
def publish(channel, message):
# 将消息发送给channel频道的所有订阅者
channel_publish(channel, message)

# 将消息发送给所有和channel频道相匹配的模式的订阅者
pattern_publish(channel, message)
```

举个例子。对于图中所示的pubsub_channels字典来说，执行PUBSUB CHANNELS命令
将返回服务器目前订阅的四个频道:
```c
1."news.it"
2."news.sport"
3."news.business"
4."news.movie"
```
另一方面，执行PUBSUB CHANNELS "news.[is]*"命令将返回"news.it"和"news.sport"两个频道,
因为只有这两个频道和"news[is]*"模式相匹配
```c
1."news.it"
2."news.sport"
```

举个例子。对于图中所示的pubsub_channels字典来说，对字典中的四个频道执行PUBSUB NUMSUB
命令将获得以下回复
```c
redis>PUBSUB NUMSUB news.it news.sport news.business news.movie
1)."news.it"
2)."3"
3)."news.sport"
4)."2"
5)."news.business"
6)."2"
7)."news.movie"
8)."1"
```