压缩列表（ziplist）本质上就是一个字节数组，是 Redis 为了节约内存而设计的一种线性 数据结构，可以包含多个元素，每个元素可以是一个字节数组或一个整数。 跳跃表（skiplist）是一种有序数据结构，它通过在每个节点中维持多个指向其他节点的指 针，从而达到快速访问节点的目的。跳跃表支持平均
发布于 2024-04-24
Redis实例最多可以存放的keys数量受到多个因素的限制，包括Redis版本、可用内存大小、系统架构和其他配置参数等。 根据Redis的设计和实现，它的keys存储在一个由Hashtable组成的hash表中。根据Redis的源代码，目前Redis默认使用了214个哈希表槽位（默认情况下，可以通过
发布于 2024-04-24
在Redis中，主从同步是通过以下步骤来实现的： 建立连接：从服务器（从节点）通过向主服务器（主节点）发送SYNC命令来与主服务器建立连接。 快照同步：主服务器在收到SYNC命令后，会执行BGSAVE命令生成一个RDB持久化文件，并将该文件发送给从服务器进行全量复制。从服务器在接收到RDB文件后，会
发布于 2024-04-24
Redis 的操作是原子性的，这是因为 Redis 的每个命令都是以单线程的方式执行的，整个命令的执行过程是不可中断的，要么全部执行成功，要么全部执行失败。 在 Redis 中，每个命令都会被转换成一个或多个底层操作，这些操作会基于数据结构的特定实现来执行。比如，对于字符串类型，获取一个键值对、设置
发布于 2024-04-23
热 Key 问题是指在缓存系统中，某些特定的缓存key受到高频访问，导致对这些热门数据的读取/写入操作集中在少数几个缓存节点上，使得这些节点的负载过高，而其他节点负载较轻甚至空闲。这会造成系统性能不均衡，可能导致部分请求响应变慢或服务不可用。 解决热 Key 问题有这些方案： 缓存预热：在系统启动或
发布于 2024-04-23
缓存双写不一致是指在使用缓存的架构中，当数据更新时，由于缓存和数据库的写操作没有同步进行，导致数据在缓存和数据库之间出现不一致的情况。 以下是对缓存双写不一致的一般理解： 更新顺序问题：当应用程序更新了数据库中的数据，但在更新缓存之前发生了错误或异常，导致缓存中的数据仍然是旧值。这种情况下，数据库中
发布于 2024-04-23
缓存双写不一致是指在使用缓存的架构中，当数据更新时，由于缓存和数据库的写操作没有同步进行，导致数据在缓存和数据库之间出现不一致的情况。 以下是对缓存双写不一致的一般理解： 更新顺序问题：当应用程序更新了数据库中的数据，但在更新缓存之前发生了错误或异常，导致缓存中的数据仍然是旧值。这种情况下，数据库中
发布于 2024-04-23
Redis 哨兵是一种用于高可用性的解决方案，它可以监控 Redis 主从复制模式下的主节点和从节点，发现节点故障，并自动进行故障转移，保证 Redis 系统的稳定性和可靠性。 Redis 哨兵机制由多个相互独立的进程组成，这些进程使用 TCP/IP 协议相互通信，实现 Redis 节点的监控和故障
发布于 2024-04-23
为什么需要哨兵机制？ Redis的主从复制主要用于实现数据的冗余备份和读分担，并不是为了提供高可用性。因此在系统高可用方面，单纯的主从架构无法很好的保证整个系统高可用。比如说：
发布于 2024-04-23
