redis面试题看这一篇就够了

1.mysql redis 数据一致性问题最有效解决方案
数据库变更发布订阅：使用 MySQL 的二进制日志（binlog）功能，将数据库的变更操作记录下来，并通过发布订阅机制将这些变更事件传递给 Redis。Redis 作为一个订阅者，接收到变更事件后，对相应的缓存进行更新或失效操作。这样可以保证 Redis 中的数据与 MySQL 的变更保持一致。
2.上一题中，订阅binlog和发mq的区别
订阅 binlog：

订阅 binlog 是直接从 MySQL 数据库中获取变更事件的方法。
应用程序可以通过读取 binlog 来了解数据库中的数据变更情况，并根据需要更新 Redis 缓存。
订阅 binlog 可以实现实时的数据同步，因为它会立即捕获到数据库的变更操作。
由于直接从 MySQL 获取数据变更，因此订阅 binlog 不需要引入其他组件或服务，减少了系统复杂性。
然而，订阅 binlog 需要开发人员编写代码来解析 binlog，并进行相应的缓存更新操作。这需要一定的开发工作量。
使用消息队列：

使用消息队列是将数据库的变更操作发布到消息队列中，然后订阅者（例如 Redis）从消息队列中消费这些变更事件。
数据库的变更操作会以消息的形式发送到消息队列，Redis 作为消费者从消息队列中获取并处理这些变更事件。
使用消息队列可以实现异步的数据同步，因为变更事件可以在任何时间被消费者处理。
消息队列提供了可靠的消息传递机制，可以处理消息丢失和重试的问题。
使用消息队列需要引入额外的组件和服务，例如 RabbitMQ 或 Apache Kafka。这增加了系统的复杂性，并可能会影响性能。
总体而言，订阅 binlog 和使用消息队列都可以实现 MySQL 和 Redis 数据的一致性。选择哪种方法取决于具体需求和系统架构。如果需要实时同步数据，并且希望简化系统架构，可以选择订阅 binlog。如果对实时性要求不高，但更关注可靠性和异步处理，可以选择使用消息队列。

3.redis 缓存删除策略
1）惰性删除（Lazy Expiration）：
又细分了七种，默认第一种，缓存不足找到设置了有效时间的key过期删除
1 volatile-ttl：这是 Redis 的默认过期策略。当键设置了 TTL（Time To Live，生存时间）时，Redis 会将其视为 volatile 键（易失键），并在过期后自动删除。

2 allkeys-ttl：与 volatile-ttl 类似，但它适用于所有的键，无论是否设置了 TTL。当键过期后，Redis 会自动删除它们。

3 volatile-lru：当内存空间不足以容纳新写入的数据时，Redis 会优先删除具有 TTL 的键中最近最少使用（Least Recently Used，LRU）的键，然后再删除其他键。

4 allkeys-lru：与 volatile-lru 类似，但它适用于所有的键，而非仅限于设置了 TTL 的键。Redis 会优先删除最近最少使用（LRU）的键来释放空间。

5 volatile-random：当内存空间不足以容纳新写入的数据时，Redis 会从具有 TTL 的键中随机选择一个进行删除，并释放空间。

6 allkeys-random：与 volatile-random 类似，但它适用于所有的键，而非仅限于设置了 TTL 的键。Redis 会从所有键中随机选择一个进行删除来释放空间。

7 noeviction：这是一种特殊的过期策略，表示当内存空间不足以容纳新写入的数据时，Redis 不会删除任何键，而是返回错误。

2）定期删除（TTL-based Expire）：
hz: 该配置指定了 serverCron 函数的执行频率，默认为 10，每秒运行 10 次。
maxmemory-samples: 该配置指定了每次 serverCron 运行时，从过期键中随机选取的样本数量，默认为 5。
这些配置项可以通过修改 Redis 的配置文件（redis.conf）进行设置，或者在启动 Redis 时通过命令行参数进行配置。

maxmemory-policy allkeys-lru
hz 20
maxmemory-samples 10

4.详细说下redis的各个存储结构应用场景
Redis 提供了多种数据结构，每种结构都有其独特的特性和适用场景。以下是 Redis 中主要的数据结构及其应用场景：

字符串（String）：

适合存储单个值、计数器、缓存等。
可以设置过期时间，支持各种字符串操作。
哈希表（Hash）：

适合存储对象的属性集合，如用户信息、商品属性等。
比起字符串更灵活地存储和访问结构化数据。
列表（List）：

适合实现消息队列、发布/订阅模型等。
支持从两端插入和删除元素，可以按索引或范围进行访问。
集合（Set）：

适合存储唯一无序的元素，如标签、好友列表等。
支持集合运算，如交集、并集、差集等。
有序集合（Sorted Set）：

适合存储具有分值的元素，如排行榜、优先级队列等。
元素按照分值排序，支持根据分值范围获取元素。
位图（Bitmap）：

适合存储大规模的位操作数据，如在线用户标记、统计信息等。
支持位级别的操作，如并、或、异或等

5.redis集群槽转移策略
在 Redis 集群中，槽转移（Slot Resharding）是一种策略，用于在集群中添加或移除节点时重新分配数据槽。以下是 Redis 集群中的槽转移策略：

哈希槽（Hash Slot）：

Redis 将数据分为 16384 个哈希槽（0-16383）。
每个键通过哈希算法计算得到一个槽号，并根据槽号将键值对分布到不同的节点上。
节点握手（Node Handshake）：

当一个新的节点加入集群时，它会与已存在的节点进行握手。
新节点会接管部分哈希槽，并成为集群的一部分。
槽迁移（Slot Migration）：

当集群添加或移除节点时，需要对槽进行重新分配。
Redis 使用自动槽迁移来实现这一过程，保证数据的平衡和一致性。
槽转移策略：

在槽迁移期间，Redis 采用以下策略来转移槽：
原始节点（Source Node）：负责将槽的数据迁移到目标节点。
目标节点（Destination Node）：接收从原始节点迁移而来的槽数据。
迁移过程中，原始节点和目标节点之间进行数据同步，保证数据的一致性。
集群状态更新：

在完成槽迁移后，Redis 更新集群状态，并将新的槽分配信息广播给所有节点。
客户端可以通过集群管理命令查看各个节点和槽的分布情况。
槽转移策略确保了 Redis 集群在添加或移除节点时的高可用性和数据平衡性。通过自动槽迁移，Redis 实现了节点的水平扩展和故障恢复能力，同时保持数据的一致性和性能。需要注意的是，在进行槽迁移时，可能会对集群产生一定的网络和计算负载，因此在设计和操作集群时要考虑到这些因素。

补充：https://www.cnblogs.com/monkey-xuan/p/15864052.html