Cover_sky的博客

OK每当一个客户端服务器发送一条命令请求时，服务器除了会处理这条命令请求之外，还会将关于这条命令请求的信息发送给所有监视器，如图所示。

Redis的慢查询日志功能用于记录执行时间超过给定时长的命令请求，用户可以通过这个功能产生的日志来监视和优化查询速度。

每当主服务器添加一个新的从服务器时，主服务器都会清空自己的repl_scriptcache_dict字典，这是因为随着新从服务器的出现，repl_scriptcache_字典里面记录的脚本已经不再被所有从服务器载入过，所以主服务器会清空repl_scirptcache_dict字典，强制自己重新向所有从服务器传播脚本，从而确保新的从服务器不会出现脚本未找到错误。

EVALSHA命令式所有与Lua脚本有关的命令中，复制操作最复杂的一个，因为主服务器与从服务器载入Lua脚本的情况可能有所不同，所以主服务器不能像复制EVAL命令、SCRIPT LOAD命令或者SCRIPT FLUSH命令那样，直接将EVALSHA命令传播给从服务器，对于一个在主服务器被成功执行的EVALSHA命令来说，相同的EVALSHA命令在从服务器执行时可能会出现脚本未找到(not found)错误。举个例子。

Redis中与Lua脚本有关的命令还有四个，它们分别是SCRIPT FLUSH命令、SCRIPT EXISTS命令、SCRIPT LOAD命令、以及SCRIPT KILL命令。

当客户端向服务器发送EVAL命令，要求执行某个Lua脚本的时候，服务器首先要做的就是在Lua环境中，为传入的脚本定义一个与这个脚本相对应的Lua函数，其中，Lua函数的名字由f_前缀加上脚本的SHA1校验和(四十个字符长)组成，而函数的体(body)则是脚本本身1.执行脚本的步骤非常简单，只要调用与脚本相对应的函数即可2.通过函数的局部性来让Lua环境保持清洁，减少了垃圾回收的工作量，并且避免了使用全局变量。

为了防止带有副作用的函数令脚本产生不一致的数据，Redis对math库的math.random函数和math.randomseed函数进行了替换。对于Lua脚本来说，另一个可能产生不一致数据的地方是哪些带有不确定性质的命令，比如对于一个集合键来说，因为集合的排列是无序的，所以即使两个集合的元素完全相同，它们的输出结果也可能并不相同。

Redis从2.6版本开始引入对Lua脚本的支持，通过在服务器中嵌入Lua环境,Redis客户端可以使用Lua脚本，直接在服务器端原子地执行多个Redis命令。而使用EVALSHA命令则可以根据脚本的SHA1校验和来对脚本进行求值，但这个命令要求校验和对应的脚本必须至少被EVAL命令执行过。

假设当前服务端为c10086，而数据库watched_keys字典的当前状态如图所示，那么当c10086执行以下WATCH命令之后watched_keys字典将更新如图所示的状态。接下来客户端c10086继续向服务器发送MULTI命令，并将一个SET命令放入c999执行的这个SET命令会导致正在监视"name"键的所有客户端的REDIS_DIRTY_CAS标识被打开，其中包括客户端c10086.

当一个处于事务状态的客户端向服务器发送EXEC命令时，这个EXEC命令将立即被服务器执行，服务器会遍历这个客户端的事务队列，执行队列中保存的所有命令，最后将执行命令所得的结果全部返回给客户端。

Redis通过MULTI、EXEC、WATCH等命令来实现事务(transaction)功能。事务提供了一种将多个命令请求打包,然后一次性、按顺序地执行多个命令的机制，并且在事务执行期间，服务器不会中断事务而改去执行其他客户端的命令请求，它会将事务中的所有命令都执行完毕，然后采取执行其他客户端的命令请求。

当一个Redis客户端执行PUBLISH 命令将消息message发送给频道channel的时候，服务器需要执行以下。

每当客户端执行SUBSCRIBE命令订阅某个或某些频道的时候，服务器都会将客户端与被订阅的频道在pubsub_channels字典中进行关联。

Redis的发布与订阅功能由PUBLISH、SUBSCRIBE、PSUBSCRIBE等命令组成。通过执行SUBSCRIBER命令，客户端可以订阅一个或多个频道，从而成为这些频道的订阅者(subscribe)：每当有其他客户端向被订阅的频道发送消息(message)时，频道的所有订阅者都会收到这条消息.

当集群里的主节点A将主节点B标记为已下线(FAIL)时，主节点A将向集群广播一条关于主节点B的FAIL消息，所有接收到这条FAIL消息的节点都会将主节点B标记为已下线。在集群的节点数量比较大的情况下，单纯使用Gossip协议来传播节点的已下线信息会给节点的信息更新带来一定延迟，因为Gossip协议消息通常许需要一段时间才能传播至整个集群，而发送FAIL消息可以让集群里的所有节点立即知道某个主节点已下线，从而尽快判断是否需要将集群标记为下线，又或者对下线主节点进行故障转移。

集群中的各个节点通过发送和接收消息(message)来进行通信，我们称发送消息的节点为发送者(sender),接收消息的节点成为接收者，如图所示。一条消息由消息头(header)和消息正文(data)组成。

一个节点成为从节点，并开始复制某个主节点这一信息会通过消息发送给集群中的其他节点，最终集群中的所有节点都会知道某个从节点正在复制某个主节点。

在一般情况下，如果客户端向节点发送一个关于槽i的命令，而槽i又没有指派给这个节点的话，那么节点将向客户端返回一个MOVED错误；但是，如果节点的clusterState.importing_slots_from[i]显示节点正在导入槽i,并且发送命令的客户端带有REDIS_ASKING标识，那么节点将破例执行这个关于槽i的命令一次，过程如图所示。当客户端接收到ASK错误并转向至正在导入槽的节点时，客户端会先向节点发送一个ASKING命令，

在进行重新分片期间，源节点向目标节点迁移一个槽的过程中，可能会出现这样一种情况:属于被迁移槽的一部分键值对保存在源节点里面，而另一部分键值对则保存在目标节点里面。

其中slot为键所在的槽，而ip和port则是负责处理槽slot的节点的IP地址和端口号。表示槽789正由IP地址为127.0.0.1，端口号为7000的节点负责。当客户端接收到节点返回的MOVED错误时，客户端会根据MOVED错误中提供的IP地址和端口号，转向至负责处理槽slot的节点，并向该节点重新发送之前想要执行的命令。如图所示展示了客户端向节点7000发送SET命令，并获得MOVED错误的过程客户端根据MOVED错误，转向至节点7001，并重新发送SET命令的过程。

其中CRC16(key)语句用于计算键key的CRC-16校验和，而& 16383语句则用于计算出一个介于0~16383之间的整数作为键key的槽号。1.当客户端第一次向节点7000发送SET命令的时候，节点7000会向客户端返回MOVED错误，指引客户端转向至节点7001。最后，在CLUSTER ADDSLOTS命令执行完毕之后，节点会通过发送消息告知集群中的其他节点，自己目前正在处理哪些槽。2.当客户端转向到节点7001之后，客户端重新向节点7001发送SET命令，这个命令会被节点7001成功执行。

slots属性是一个二进制位数组(bit array)，这个数组的长度位16384/8=2048个字节，共包含16384个二进制位。因为取出和设置slots数组中的任意一个二进制位的值的复杂度仅为O(1)，所以对于一个给定节点的slots数组来说，程序检查节点是否负责处理某个槽，又或者将某个槽指派给节点负责，这两个动作的复杂度都是O(1).至于numslots属性则记录节点负责处理的槽的数量，也即是slots数组中值位1的二进制位的数量。比如说，例子中的节点处理的槽数量分别为8、6。

Redis集群通过分片的方式来保存数据库的键值对:集群的整个数据库被分为16384个槽(slot),数据库中的每个键都属于这16384个槽的其中一个，集群中的每个节点可以处理0个或最多16384个槽。当数据库中的16384个槽都有节点在处理时，集群处于上线状态(ok);相反地，如果数据库中有任何一个槽没有得到处理，那么集群处于下线状态(fail),在前面，我们使用CLUSTER MEET命令将7000、7001、7002三个节点连接到。

Redis集群是Redis提供的分布式数据库方案，集群通过分片(sharding)来进行数据共享，并提供复制和故障转移功能。

当新的主服务器出现之后，领头Sentinel下一步要做的就是，让已下线主服务器属下的所有从服务器去复制新的主服务器，这一动作可以通过向从服务器发送SLAVEOF命令来实现。故障转移操作最后要做的是，将已下线的主服务器设置为新的主服务器的从服务器，比如说，图中就展示了被领头Sentinel设置为从服务器之后，服务器server1的样子，当server1重新上线之后，就成为了server2的从服务器，如图所示。的时候，领头Sentinel就知道server2已经成功升级为了主服务器了。

当一个主服务器被判断为客观下线时，监视这个下线主服务器的各个Sentinel会进行协商，选举出一个领头Sentinel,并由领头Sentinel对下线主服务器执行故障转移操作。

在默认情况下，Sentinel会以每秒一次的频率向所有与它创建了命令连接的实例(包括主服务器、从服务器、其他Sentinel在内)发送PING命令，并通过实例返回的PING命令回复来判断实例是否在线。

Sentinel对_sentinel_:hello频道的订阅会一直持续到Sentinel与服务器的连接断开为止。这也就是说，对于每个与Sentinel连接的服务器，Sentinel既通过命令连接向服务器的_sentinel_:hello频道发送消息，又通过订阅连接从服务器的_sentinel_:hello频道接收消息，如图所示。

Sentinel默认会以每十秒一次的频率，通过命令连接向被监视的主服务器发送INFO命令，并通过分析INFO命令的回复来获取主服务器的当前信息。根据run_id域和role域记录的信息，Sentinel将对主服务器的实例结构进行更新。例如，主服务器重启之后，它的运行ID就会和实例结构之前保存的运行ID不同，Sentinel检测到这一情况之后，就会对实例结构的运行ID进行更新。

在应用了Sentinel的专用代码之后，接下来，服务器会初始化一个sentinel.c/sentinelState结构(简称Sentinel状态),这个结构保存了服务器中所有和Sentinel功能有关的状态(服务器的一般状态仍然由redis.h/redisServer保存);

Sentinel(哨岗、哨兵)是Redis的高可用性(high availability)解决方案:由一个或多个Sentinel实例(instance)组成的Sentinel系统(system)可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器,并在被监视的主服务器进入下线状态时，自动将下线主服务器属性的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。

其中replication_offset是从服务器当前的复制偏移量。

1.如果从服务器设置了masterauth选项，那么进行身份验证2.如果从服务器没有设置masterauth选项，那么不进行身份验证在需要进行身份验证的情况下，从服务器将向主服务器发送一条AUTH命令，命令的参数为从服务器masterauth选项的值.所有错误情况都会令从服务器中止目前的复制工作，并从创建套接字开始重新执行复制，直到身份验证通过，或者从服务器放其执行复制为止。

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

为了解决旧版复制功能在处理断线重复制情况时的低效问题，Redis从2.8版本开始，使用PSYNC命令代替SYNC命令来执行复制时的同步操作。PSYNC命令的部分重同步模式解决了旧版复制功能在处理断线后重复制时出现的低效情况，

在Redis中，用户可以通过执行SLAVEOF命令或者设置slaveof选项，让一个服务器去复制(replicate)另一个服务器，我们称呼被复制的服务器为主服务器(master)，而对主服务器进行复制的服务器则被称为从服务器(slave),如图所示。

一个Redis服务器从启动到能够接受客户端的命令请求，需要经过一系列的初始化和设置过程，比如初始化服务器状态，接受用户指定的服务器配置，创建相应的数据结构和网络连接等等。

每次serverCron函数执行时，程序都会查看服务器当前使用的内存数量，并与stat_peak_memory保存的数值进行比较，如果当前使用的内存数量比stat_peak_memory属性记录的值要大，那么程序就将当前使用的内存数量记录到stat_peak_memory属性里面。INFO memory命令的used_memory_peak和used_memory_peak_human两个域分别以两种格式记录了服务器的内存锋值。

Redis服务器中的serverCron函数默认每隔100毫秒执行一次，这个函数负责管理服务器的资源，并保持服务器自身的良好运转。

被调用的命令实现函数会执行指定的操作，并产生相应的命令回复，这些回复会被保存在客户端状态的输出缓冲区里面(buf属性和reply属性),之后实现函数还会为客户端的套接字关联命令回复处理器，这个处理器负责将命令回复返回给客户端对于前面SET命令的例子来说，函数调用setCommand(client)将产生一个"+OK\r\n"回复，这个回复会被保存到客户端状态的buf属性里面，如图所示。当客户端的套接字变为可写状态时，命令回复处理器会将协议格式的命令回复"+OK\r\n"发送给客户端。