LightOfNight的博客

集群中的各个节点会通过相互发消息的方式来交换集群中各个节点的状态信息，当一个主节点A通过消息得知主节点B认为主节点C进入了疑似下线状态时，主节点A会在自己的clusterState.nodes字典中找到主节点C对应的clusterNode结构，并将主节点B的下线报告添加到clsuterNode结构的fail_reports链表里。Redis集群中的节点分为主节点master和从节点slave，其中主节点用于处理槽，从节点用于复制某个主节点，并在被复制的主节点下线时，代替下线主节点继续处理命令请求。

Redis集群的重新分片操作可以将任意数量已经指派给某个节点（源节点）的槽改为指派给另一个节点（目标节点），并且相关槽所属的键值对也会从源节点被移动到目标节点。一个集群客户端通常会与集群的多个节点创建套接字连接，而所谓的节点转向实际上是换一个套接字来发送命令。跳跃表来保存槽和键之间的关系，跳跃表里每个节点的分值score都是一个槽号，而每个节点的成员member都是一个数据库键。否则，节点向客户端返回一个MOVED错误，指引客户端转向redirect至正确的节点，并再次发送之前想要执行的命令。

介绍了Redis的集群中的节点以及槽指派相关内容

当Sentinel将这一主服务器判断为主观下线后，为了确认这个主服务器是否真的下线，它会向同样监视这一主服务器的其他Sentinel进行询问，看他们是否也认为主服务器已经进入了下线状态（可以是主观下线，也可以是客观下线），当一个主服务器被判断为客观下线时，监视这个下线主服务器的各个Sentinel会进行协商，选举出一个领头Sentinel，并由领头Sentinel对下线主服务器执行故障转移操作。目标Sentinel的局部领头Sentinel的配置纪元，用于选举领头Sentinel。

根据实际的需求选择合适的数据结构，以高效地访问和存储多个属性。比如如果你需要存储用户的多个属性，如用户名、邮箱等，使用哈希可以比使用多个字符串键值对更节省内存较大地key和value会占用更多的内存，还可能影响性能，保持key的简短，并使用简洁的命名约定。比如简化为u:1001:p。也可以做压缩等优化对于多个命令的批量操作，使用Pipeline可以显著降低网络延迟，提升性能。比如，批量设置key可以这样写，这样一次可以发送多个命令，减少了网络往返时间，能够提升性能。

Redis与MySQL如何数据同步以及注意事项

介绍了Sentinel的启动和初始化，注意与普通Redis服务器对比；获取主服务器信息和从服务器信息；向主从服务器发送信息；接收来自主从服务器的频道信息

Redis设计与实现第15章笔记，主要介绍了旧版复制、新版复制、重同步、PSYNC命令、复制和心跳检测机制

每次serverCron函数执行时，函数都会检查BGSAVE命令或者BGREWRITEAOF命令是否正在执行，如果这两个命令都没在执行，并且aof_rewrite_scheduled属性的值为1，那么服务器就会执行之前被推延的BGREWRITEAOF命令。Redis服务器中有不少功能需要获取系统的当前时间，而每次获取系统的当前时间都需要执行一次系统调用，为了减少系统调用的执行次数，服务器状态中的unixtime属性和mstime属性被用作当前时间的缓存。值为1表示关闭服务器。

介绍了如何用Redis的List实现去重的任务队列，包括List不重复添加、List重复添加、借助Hash等

Redis服务器是典型的一对多服务器程序：一个服务器可以与多个客户端建立网络连接，每个客户端可以向服务端发送命令请求，而服务端接口并处理客户端发送的命令请求，并向客户端返回命令回复。对于每个与服务器进行连接的客户端，服务器都为这些客户端建立了相应的redis.h/redisClient结构（客户端状态），这个结构保存了客户端当前的状态信息，以及执行相关功能时需要用到的数据结构，包括套接字描述符、名字等。

Redis服务器是一个事件驱动程序，服务器需要处理以下两类事件：文件事件：Redis通过套接字与客户端（或其他Redis服务器）进行连接，而且文件事件就是服务器对套接字操作的抽象。服务器和客户端的通信会产生相应的文件事件，而服务器通过监听并处理这些事件来完成一系列网络通信操作时间事件：Redis服务器中的一些操作，比如serverCron函数需要在给定的时间点执行。

RDB持久化通过保存数据库中的键值对来记录数据库状态的不同，AOF持久化是通过保存Redis服务器所来记录数据库状态。

Redis是内存数据库，数据库状态存储在内存里，如果服务器进程退出，服务器的数据库状态没有保存到磁盘里，就会丢失。为了解决这个问题，Redis提供了RDB持久化功能，可以把Redis在内存里的数据库状态保存在磁盘里。RDB持久化可以把某个时间点上的数据库状态保存到RDB文件里，既可以手动执行，也可以根据服务器配置选项定期执行。生成的的RDB文件是一个经过压缩的二进制文件，可以通过该文件还原生成RDB文件时的数据库状态。

Redis 服务器中的数据库管理机制包括多个方面。服务器将所有数据库存储在 `redisServer` 结构的 `db` 数组中，每个数据库由 `redisDb` 结构表示。初始化时，根据配置的 `database` 选项创建数据库，默认为 16 个。客户端通过 `SELECT` 命令切换目标数据库，目标数据库由 `redisClient` 结构的 `db` 指针指向。

介绍String类型、List类型、Set类型、ZSet类型、Hash类型、Bitmap类型、HyperLogLog类型、GEO类型 的基本用法、业务场景、实际应用和注意事项

Redis高级架构，从主从复制到哨兵，最后到分片集群的演进

介绍了单机版Redis架构的缺点 以及 数据持久化的内容

使用Redis作为消息队列如何操作，包括List模型，Pub/Sub模型和Stream类型，同时分析了优缺点

使用分布式锁，在上层完成互斥目的，虽然极端情况下锁失效，但是可以最大程度把并发量阻挡在上层，减轻操作资源层的压力对于要求数据绝对正确的业务，在资源层做好兜底，设计思路可以借鉴fencing token。

在多线程的程序里，为了避免同时操作一个共享变量产生数据问题，会加一个，以确保共享变量的正确性，使用范围是。那如果是多个进程，需要同时操作一个共享资源，如何互斥呢？比如，现在的业务基本上都是微服务架构，一个应用会部署多个进程，这多个进程需要修改MySQL的同一行记录时，就需要引入分布式锁来解决这个问题了。要实现分布式锁，需要借助一个外部系统，所有的进程都去这个系统上申请加锁，而这个外部系统必须要实现互斥的能力，换言之，如果有两个请求同时进来，也只会给一个进程返回成功，另一个返回失败或等待。

一般情况下，客户端和Redis通信的时候采用的是Ping-pong模式，即客户端发送命令后会等待服务端返回的命令执行的结果，在客户端收到服务端返回的结果后再发送下一个命令。而Pipeline模式类似流水线的模式：客户端发送一个命令后无需等待执行结果，会继续发送其他的命令。当所有的命令都发送完后，客户端关闭请求，开始接收响应，收到执行结果后再和之前发送的命令按顺序匹配。大部分客户端采用批处理的方式，即一次发送多个命令，等接收完所有命令执行结果后再返回。

Redis中的热Key是高访问频率的Key，如QPS高、大带宽使用或CPU密集型操作。热Key可能导致CPU占用过高、访问倾斜、缓存击穿和系统性能下降。爆款商品、热点事件等可引发热Key。检测热Key可借助云服务、`redis-cli hotkeys`、业务层监控或`MONITOR`命令。优化策略包括复制热Key到多分片、采用读写分离，但需权衡代码复杂性和数据一致性。

Redis大Key标准与影响 在不同场景下，大Key的定义不同，如string超1MB或容器超10K。大Key导致读取延迟高、带宽消耗大、操作阻塞及内存不均衡。常见原因包括业务设计不合理、未处理value增长和程序bug。找到大Key可借助云服务、`redis-cli --bigkeys`或Redis RDB Tools。优化策略包括业务设计避免大Key、拆分Key、更换存储方案、数据压缩、清理机制和异步删除。

介绍了布隆过滤器的特点和原理