无题
在上一节中，我们已经详细介绍了 Redis Cluster 中集群配置的两个方面，一个是 Cluster 节点之间的主从关系配置，另一个是 slot 槽位分配的问题。之后，分析了 clusterCron() 周期性发送 PING 消息以及PING 消息接收方解析 PING 消息的逻辑，其中重点介绍了对 clusterMsgDataGossip 部分的解析和处理。
在 Redis Cluster 完成前面两节介绍的启动流程之后，就可以正常对外提供服务了。在提供服务的期间，Redis Cluster 中可能会因为网络、磁盘、内存等各种方面的问题，导致其中某些 Master 节点出现不可用的情况。这个时候，就需要 Redis Cluster 进行自动故障转移，将 Slave 节点提升为 Master 节点继续对外提供服务，保证整个 Redis Cluster 集群的高可用。
Redis Cluster 中的 failover 分为自动 failover 和手动 failover，自动 failover 是由 Redis Cluster 通过自身的探活机制发现宕机而触发的，手动 failove ...
无题
在前面的文章中，我们已经完整介绍了 Redis Cluster 启动流程，以及完整的 failover 流程，对应的核心实现和关键函数也进行了说明和介绍。这一节，我们再来讨论一下 Redis Cluster 在 Slave 漂移以及数据迁移方面的功能。
Slave 节点漂移在 clusterCron() 这个周期性任务中，除了前面介绍的定时发送 PING 消息、触发 failover 操作之外，还会检查 Master 的单点问题。所谓“单点 Master 问题”意思就是：一个 Master 节点下没有任何可用的 Slave 节点存在，如果此时 Master 节点发生了故障，整个 Redis Cluster 将进入不可用的状态。
为了解决这个问题，Redis Cluster 提供了 Slave 节点漂移的功能，redis.conf 配置文件中的 cluster-allow-replica-migration 配置项为该功能的开关。Slave 节点漂移的核心原理是：当 Redis Cluster 发现单点 Master 的时候，会从其他拥有多个可用 Slave 的 Master 节点那里， ...
无题
Redis 作为一个基于内存的 NoSQL 数据库，在实践中最常作为缓存或是存储使用。除此之外，我们还可以将 Redis 作为一个消息通道，实现生产者发送数据、消息者消费数据的效果，这就有点类似于 Kafka、RabbitMQ 等消息中间件的功能。前面介绍的 List 结构，就可以用来实现简易版本的生产者消费者模式，优缺点在前面第 7 篇《实战应用篇：List 命令详解与实战（下）》中也有描述，小伙伴有遗忘的话，可以进行简单的回顾。
本节要介绍的 Pub/Sub，是一种发布订阅机制，也可以用来实现生产者消费者模式。当然 Redis 的 Pub/Sub 功能比较弱，远远没有那些成熟的消息中间件的功能完善，但是在实际应用中还是有很多应用场景的。
首先，我们先从整体上了解一下 Pub/Sub 的功能，如下图所示，Redis 中可以创建多个 Channel，一个 Channel 可以有多个 Client 订阅，当其他 Client 向 Channel 中发送消息的时候，订阅了该 Channel 的 Client 就能收到消息。
Pub/Sub命令核心实 ...
无题
GeoHash 是一种坐标编码算法，其目的是将一个经纬度坐标编码成一个 Base 32 字符串。
地球经度范围为东经 180° 到西经 180°，纬度范围是南纬 90° 到北纬 90°。在 GeoHash 算法中，将西经设置为负，东经设置为正，南纬设置为负，北纬设置正，则得到经度范围是 [-180，180]，纬度范围是 [-90，90]。每个 GeoHash 都表示地球上的一块区域。例如，我们以赤道和本初子午线为边界，就可以将地球划分为 4 个区域，如下图所示，我们可以为每个区域设置一个二进制编码：
上图只将地球划分为四个区域，没有什么作用，因为粒度实在太大了，实现不了精确的定位和范围搜索功能。我们可以继续对整个地球进行更细致的划分，得到更精准的一个个小区域，如下图所示，然后将这些表示小块区域的二进制进行 Base32 编码得到的字符串，也就是 GeoHash 编码。
下面我们来看计算（40.085138, 116.327313）这个坐标的 GeoHash 的核心流程。
首先，将地区的经度分为 [-180, 0]、[0, 180]，116° 位于右侧的 [0, 180] 区间 ...
无题
通过前文的介绍我们知道，Redis 是使用单线程方式执行命令的，Redis 与客户端交互的模式是 Request-Response 模式，也就是：先由客户端发起请求，请求中包含一条 Redis 命令，Redis 执行完这条命令之后，给客户端返回对应的响应。
如果我们使用多条 Redis 命令组合，实现一个较为复杂的流程，在多个客户端同时执行的情况下，就可能会出现并发问题。
举个例子，我们在 Redis 中维护了一个商品的库存个数，现在进行秒杀活动，每个用户限只能下一个订单，每个订单最多可以购买 5 件商品，这里需要业务侧在每次减少库存值时，判断库存值是否已经到达 0 ，如果库存减到 0 了，就给用户返回“库存不足”的提示。如果下单的业务逻辑是先使用 GET 命令获取库存值，然后与订单购买的商品个数进行比较，在库存值大于购买个数的时候，才使用 SET 命令更新库存值的话，就会存在下表的并发问题，例如下表展示的这个并发执行顺序。
时间
Redis 客户端 A
Redis 客户端 B
T1
执行 GET 命令，获得库存量为 100
T2
执行 GET 命令，获得库存量为 ...
无题
上一节，我们详细介绍了 Redis 如何通过 Lua 脚本进行扩展，以及 Redis 底层是如何执行 Lua 脚本的。在 Redis 7 中，引入了 Functions 这种新的扩展方式，之所以引入 Functions 这种扩展方式，因为 Lua 脚本的的一些局限性，例如：
Lua 脚本在发到 Redis 服务端之后，只是暂存在内存中，不会进行持久化。当 Redis 重启或者出现主从切换，Lua 脚本就会丢失，需要客户端重新上传。这样的话，就需要所有的客户端都要保留一份 Lua 脚本，并实现一套上传 Lua 脚本的逻辑。
Lua 脚本进行代码更新的时候，也是同样的逻辑。除了要在 Redis 服务端进行更新，还需要同步全部客户端进行更新，否则，就会出现脚本代码不一致的情况。
另外，Lua 脚本之间是不能相互调用的，这就会造成许多代码重复，从开发和维护角度来说，都不是一件好事。
Functions 基本使用下面我们开始介绍一下 Redis Functions 的基本使用。
Redis Functions 目前只支持 Lua 脚本，所以我们先来定义 check_key()、my_hset ...
无题
小伙伴们，大家好，通过本小册的学习，相信小伙伴们已经对 Redis 的底层原理有非常全面、非常深刻的理解。这些知识非常重要，活学活用、与实战结合、最终服务业务，才是我们花费大力气来学习这些知识的最终目的，这才算真正点亮了 Redis 技能树。
在小册的最后，我就带领小伙伴们一起，来看一个我在实际工作中遇到的问题 —— Redis 热 Key 问题，以及解决这个问题的多种方案。当然，这个案例本身的价值有限，但是解决问题的思路，非常值得总结：
1分析问题本质 -> 如何感知/发现问题 -> 应用基础知识设计多套方案 -> 思考方案优劣势 -> 选择合适的方案
分析问题本质：热 Key 的场景介绍有的小伙伴可能会很疑惑，为什么 Redis 已经是纯内存的存储了，出现了热 Key 还扛不住吗？在解释这个问题之前，我们通过几个例子来说明热 Key 问题的本质。
假设我们有一个电商项目，用 Redis 缓存了商品的信息，然后在双十一大促的时候，会有很多商家各种限时抢购，开启抢购的一瞬间，就会有非常大的流量来查看某件促销产品的信息，流量会大到 Redis 扛不住，也就是我 ...
无题
通过上一节的分析我们知道，主从建连之后会一系列握手操作，这里面最关键的一步就是从库向主库发送 PSYNC 命令，其中会携带从库当前的 Replication ID 和 Replication Offset。这里紧接上文，继续介绍从库对 PSYNC 响应的处理。
当主库返回 +CONTINUE 响应的时候，表示进行部分同步，从库会直接进入 REPL_STATE_CONNECTED 状态，主从握手的流程也就结束了，后续会进入正常的主从复制流程。
当主库返回 +FULLRESYNC 响应时，从库就要准备与主库进行全量同步了，下面是从库需要做的准备工作。
从库首先会创建一个名为 temp-{秒级时间戳}.{进程ID}.rdb 的临时 RDB 文件，然后将这个文件名称以及对应的文件描述符记录到 redisServer.repl_transfer_tmpfile 字段和 repl_transfer_fd 字段中。
监听主从连接上的可读事件，等待主库发送 RDB 数据，相应的回调为 readSyncBulkPayload() 函数。
最后，从库会将 re ...
无题
在前面的章节中，我们已经详细介绍了 Redis 主从复制的核心原理，以及从库视角下主从复制的核心实现。从本节开始，我将和小伙伴们一起，分析一下主库视角下的主从复制，这样整个主从复制的实现就完整了。
在从库发起建连操作时，主库是无法立刻识别出该建连请求是来自从库的，会将其作为一个普通客户端进行处理，为其创建对应的 client 实例。这里注意 client 中的 replstate 字段，它记录了该从库状态的变更。在下图中，展示了主库与从库进行握手的核心流程，最右侧就是从库对应的 client->replstate 状态的变化流程：
在从库与主库建立连接之后，从库会向主库发送 PING 和 AUTH 命令进行探活和鉴权，此时从库在主库眼中与普通客户端无异，主库会正常地进行鉴权和响应。
接下来，从库会连续发送三条 REPLCONF 命令，将从库的 ip、port 以及从库支持的能力告知主库，在主库侧会根据 REPLCONF 命令的参数更新不同的字段，例如：
主库会将从库端口号记录到 client->slave_listening_port 字段中；
主库会将从库的 ip 记 ...
无题
在上一节中，我们已经详细介绍了复制缓冲区的设计演进过程以及主库视角下部分同步的核心。在这一节，我们继续来分析一下主库视角下全量同步实现。
全量同步通过上一节的分析我们知道，如果主从之间能进行部分同步，需要检查 Replication ID、Replication Offset 等一系列条件是否成立，如果部分同步的条件不成立，就会进入全量同步的逻辑。在进行全量同步的时候，主库首先执行与部分同步类似的状态更新操作：
将 client->replstate 状态为 WAIT_BGSAVE_START，表示主库要为全量同步执行一次 RDB 持久化。
向 client->flags 中设置 CLIENT_SLAVE 标记，标识这是一个从库 client 实例。
将 client 添加到 server.slaves 列表中。
如果当前主库之前的 backlog 缓冲区一直为空，那从库必然只能进行全量同步，此时会初始化 replBacklog、在 redisServer.replid 字段中填充新生成的 Replication ID 、清空 Secondary ID 和 Second ...