程序员-杨胡广的博客

胡广假设A哨兵的配置是10000毫秒、B哨兵是50000毫秒，但此时Redis实例要在20000毫秒才响应，像这种情况就会发生A哨兵判断Redis实例下线，但B哨兵判断Redis实例仍然存活的情况。：默认情况Sentinel会每隔 1 s向Redis主、从服务器发送PING命令，通过PING命令返回的信息来判断Redis主从服务器的下线状态。，删除所有处于下线或者断线状态的、删除最近五秒内没有回复过领头Sentinel命令的、删除与已下线主服务器连接断开超过10毫秒的。

像上文的Redis集群的A、B、C三个节点，主从模型可以为这每一个主节点添加一个副本节点。Redis集群重新分片可以将任意数量已指派给某个节点的槽改为指派给另一个节点，而相关槽所属的键值对也会从源节点被移动到目标节点。Redis 集群将数据自动分片到多个 Redis 节点，Redis 集群还在分区期间提供一定程度的可用性，当某些节点发生故障或无法通信时，Redis集群能够继续运行。Redis集群的主从模型选举主节点和Redis哨兵选举出主节点非常相似，但大家不要搞混了，Redis集群中并没有哨兵的概念。

和上文提交的哈希对象不是同一个级别的产物，字典是Redis内部的数据结构，而哈希对象是提供给外部使用的。所以Redis内部会对有序集合采用字典和跳跃表两种实现，当使用对应不同场景时，就采用对应的不同数据结构来高效操作有序集合。跳跃表的查询效率是比较快的，可以和平衡二叉树相媲美，同时跳跃表相比平衡树的实现更加的简单。哈希键如果只包含少量的键值对，同时键、值都是类似小整数、短字符串类型的，会采用压缩列表的底层实现。列表键里如果包含的都是类似小整数、短字符串类型的，会采用压缩列表的底层实现。

每隔一段时间检查数据库中一部分的键，删除其中的过期键，该策略可以设置删除操作的执行时长和频率。过期的键不管，直到每次获取键，如果发现键过期了，才会释放出键内存。我们可以把Redis的数据库和MySQL的数据库理解成同一个东西，不同数据库之间都是相互隔离的，在一个数据库中定义的键对其他数据库。例如我们在Redis的数据库1设置键值对，在数据库1可以查询出来，而在数据库2中是查询不出来的。键空间的概念图如下，dict字典存储了所有键，每个键的指针指向值的引用地址。定时删除策略会为设置过期时间的键。

Redis本身是一个基于内存的数据库，它提供了RDB持久化、AOF持久化两种方式，用来将存储在内存中的数据库状态保存到磁盘中。前者是保存了整个Redis。AOF文件是AOF持久化的产物，AOF持久化通过保存服务器所有执行的写命令来记录数据库状态。对于一个键值对，AOF旧的文件会保存数十条对该键值对的修改命令，这样浪费了大量内存空间。现有的AOF文件，新旧两个AOF文件所保存的数据库状态相同，但新AOF文件。到新AOF文件的末尾，从而保证两个新旧AOF文件状态一致。的冗余命令，使得新的AOF文件体积很小。

从服务器使用SYNC进行初次数据同步后，主、从服务器的数据库状态并不是每时每刻都保持一致的，这种情况反而是常态。向主服务器发送心跳检测命令，如果主服务器超过1s没有收到replconf命令，说明主从服务器的网络连接有问题了。这种情况Redis主服务器会将造成主从服务器数据不一致的写命令，即最近执行的写命令，发送给从服务器执行。在心跳检测时的过程中，如果主服务器发现他们的复制偏移量不一致，就会通过该偏移量找到从服务器。后，主从服务器的偏移量就会 + N。从服务器执行命令后，主、从服务器的数据也就同步了。

好了，总结一下。这篇文章，我们主要探讨了基于 Redis 实现的分布式锁，究竟是否安全这个问题。从最简单分布式锁的实现，到处理各种异常场景，再到引出 Redlock，以及两个分布式专家的辩论，得出了 Redlock 的适用场景。最后，我们还对比了 Zookeeper 在做分布式锁时，可能会遇到的问题，以及与 Redis 的差异。这里我把这些内容总结成了思维导图，方便你理解。