● redis的数据结构有哪些？
● redis的数据类型有5大类，string \List\set\zset\Hash
● string 适用于键值对存储，可用于存储业务数据缓存 ，或者用于计数。
● List 可以用户实现消息队列的功能，适用于任务调度系统或异步处理流程。
● set 可以用于去重元素
● zset 根据分数做排名
● Hash 对象存储
redis的淘汰策略
noeviction：不淘汰任何数据。当内存超限时，写操作会返回错误，而读操作正常执行。适用于数据量不大，作为DB存储使用的情况
volatile-lru：最近最少使用算法。适用于带有过期时间的键，淘汰设置了过期时间的键中最久未使用的键。
volatile-lfu：最近最不经常使用算法。适用于带有过期时间的键，淘汰设置了过期时间的键中一段时间内使用次数最少的键。
volatile-ttl：淘汰最早要过期的键。适用于按时间区分冷热数据的情况，优先淘汰那些TTL（Time To Live）最早接近到期的键。
volatile-random：随机淘汰设置了过期时间的键。适用于不确定数据访问模式或希望简单随机淘汰的情况。
allkeys-lru：淘汰最久未使用的键。适用于所有键，基于LRU算法淘汰最久未被访问的键。
allkeys-lfu：淘汰访问频次最小的键。适用于所有键，基于LFU算法淘汰访问频次最小的键。
allkeys-random：随机淘汰所有键。适用于所有键的随机访问。
● redis的发布和订阅
● 什么是redis的发布订阅？
● 发布订阅是一种消息模式，Redis 发布订阅 (pub/sub) 是一种消息通信模式：发送者 (pub) 发送消息，订阅者 (sub) 接收消息。
● 首先通过命令订阅一个频道。然后给该平台发送消息。
● redis的新数据类型有哪些
● Bitmaps
● 是一种特殊的数据结构,用于处理位图信息，而是基于 String 类型的一种特殊用法。它允许你在 Redis 中将字符串看作是位数组（bit array），每个字符由8位组成，因此可以对字符串中的每一个位进行操作
● HyperLogLog
● 是一种用于估计集合基数，HyperLogLog 的主要优势在于其能够在非常小的空间内（通常小于16KB）提供对大量数据集基数的近似计算。
● Geospatial
● 自3.2版本开始支持地理空间（Geospatial）数据类型，这使得它能够有效地存储、查询地理位置信息。
● redis的事务操作
● redis的事务是如何实现的？
● 首先，redis的事务是根据队列实现的。通过 命令 Multi开始，所有的操作都会进入到队列，通过执行Exec进行 执行进入队列的命令。组队过程中通过discard来放弃组队。
● 事务出错怎么办？
● 事务出错则会导致，没有成功的命令不会执行，其他的都会执行，不会回滚。
● 可以通过监视器来解决该问题，通过watch key 可以监视一个或多个Key，如果事务在执行之前这个(这些)key 被其他命令所改动，那么事务将被打断。
● unwatch 该命令取消对所有的key监控
● redis的事务特性有哪些？
● 单独的隔离操作
● 没有隔离级别的概念
● 不保证原子性
● redis持久化
● redis持久化 RDB
● 在指定的时间间隔内将内存中的数据集快照写入磁盘中，也就是快照，恢复时 是将快照文件直接读到内存里。
● rdb如何执行的
● Rdis会单独创建一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
● 在文件中配置dbfilename.rdb的名称， 配置文件路劲，配置快照save 时间 修改次数。通过bgsve 执行后，父进程会for一个子进程，for子进程时将副父进程的数据拷贝了一份，然后写入到文件中。
● rdb的恢复流程？
● 1. 先通过 config get dir 查询rdb文件目录，2.将 *.rdb的文件拷贝到别的地方，3.关闭redis ，先把备份的文件拷贝到工作目录下，cp dump2.rdb dump.rdb
● 4.启动redis ，备份数据会直接加载。
● rdb的优势和劣势
● 适合大规模的数据恢复，对数据完整性和一致性要求不高更适合使用
● 节省磁盘空间 ，恢复速度快。
● redis持久化 AOF
● AOF 以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
● AOF持久化流程
● 1.客户端请求的写命令被追加到AOF缓冲区内； 2.AOF缓冲区跟AOF持久化策略【always everysec no】将操作sync 同步到此盘的AOF文件中。
● 3.AOF文件大小超过重写策略或手动重写时，会对AOF文件 rewite重写，压缩AOF文件容量。
● 4.Redis 服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的。
● AOF和rdb同时开启 ，redis听谁的？
● AOF和RDB同时开启，系统默认取AOF。
● AOF默认不开启，AOF的文件保存路径同RDB的路径一致。
● AOF的启动和恢复
● AOF的启动和恢复和RDB一样，正常恢复，将修改默认的appendonly no，改为yes。
● AOF同步频率设置
● appendfsync always
● 始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好
● appendfsync everysec
● 每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
● appendfsync no
● redis不主动进行同步，把同步时机交给操作系统。
● RDB 和AOF的优势和劣势
● RDB恢复速度快，数据恢复的不完整。
● AOF恢复速度慢，数据保存的完整，但占用更多空间。
● redis的主一主两从复制
● 什么是主从复制？
● 主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master写为主，Slaver以读为主。
● 主从复制的好处有哪些?
● 读写分离，性能扩展。
● 容灾快速恢复。
● 主从配置的流程有哪些？
● 1.启动REDIS的主节点 2. 在从节点中设置 如下命令 slaveof <masterip> <masterport> 主节点IP 及端口号。
● 主从配置的问题
● 主机宕机了，从机是上位还是原地待命？
● 主机宕机了，从机会原地等待，不会成为主机，直到原来的主节点恢复运行并再次建立连接。
● 主机上线后，从机能顺利复制吗？
● 是的，只要主从之间的连接恢复正常，并且没有发生严重的不一致错误，从节点应该能够继续跟踪主节点的变化并同步最新的数据更新。
● 从机宕机了，从机的数据是如何保持复制的？
● 一台从机节点宕机后，会尝试进行部分同步，如果宕机期间丢失的数据超出了复制挤压的范围，或者该缓冲区已被覆盖，那么它必须执行全量复制来重新获取完整数据集。
● redis的哨兵模式
● 什么是哨兵模式？
● 哨兵模式主要用于监控redis主节点的服务情况，选举从节点成为主节点。保持高可用的一种方案。
● 哨兵模式根据后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。
● 哨兵模式如何配置？
● 配置主节点的监听端口和密码 2.配置从节点slaveof <master-ip> <master-port> 到主节点的IP 及端口和密码
● 3.配置Redis Sentinel 文件，
● sentinel monitor mymaster <master-ip> <master-port> <quorum>sentinel down-after-milliseconds mymaster 5000sentinel failover-timeout mymaster 60000sentinel parallel-syncs mymaster 1
●
● 哨兵模式下，主节点宕机又上线了怎么处理？
● 主节点宕机后在上线，默认成为了从节点，若保持通信成功，数据将继续保持同步。
● 主节点重新上线后的角色
● 默认行为：
● 当原来的主节点重新上线时，Sentinel会将其降级为从节点，并让它开始复制新的主节点的数据。
● 这意味着原来的主节点不会立即恢复为主节点的角色，而是作为新主节点的一个从节点运行，直到再次发生故障转移或手动干预改变其状态。
● 数据同步：
● 由于原主节点可能包含一些未同步到其他从节点的数据（即在它宕机之前尚未完全同步的数据），因此在成为从节点后，它需要与新的主节点进行数据同步，以确保数据的一致性。
● 如果原主节点和新主节点之间的数据差异较小，可以通过部分重同步（partial resynchronization）快速同步；如果差异较大，则可能需要全量同步。
● 特殊情况处理：
● 在某些情况下，如果管理员希望让原来的主节点重新成为主节点，可以通过手动方式调整Sentinel的配置或者直接操作Redis实例来实现这一点。但是，在正常情况下，推荐让Sentinel自动管理主从关系，以避免人为错误导致的数据不一致或其他问题
● 优先级设置 (slave-priority)：可以在每个从节点的配置文件中指定slave-priority参数，值越低表示优先级越高。在故障转移过程中，Sentinel倾向于选择优先级较高的从节点作为新的主节点。如果你希望某个特定的节点（包括原先的主节点）在恢复后更容易被选为主节点，可以调整其优先级
● 如何避免 Sentinel 的脑裂问题？
● 为了避免或最小化Sentinel环境中的脑裂问题，可以采取以下几种策略和最佳实践：
● 1. 合理设置 Quorum 值
● Quorum 是指认为一个主节点不可达所需的最少投票数。通常建议将 quorum 设置为总 Sentinel 实例数的一半加一（N/2 + 1），这有助于确保在网络分区情况下，只有当大多数Sentinel实例同意某个主节点不可达时，才会触发故障转移。
● 这种设置可以在一定程度上防止因少数Sentinel实例误判而导致的不必要的故障转移。
● 2. 使用奇数个 Sentinel 实例
● 部署奇数个 Sentinel 实例可以帮助更有效地达成共识，减少出现平票的可能性，从而降低脑裂的风险。
● 推荐至少部署3个Sentinel实例，并且最好分布在不同的物理位置或网络区域以提高容错能力。
● 3. 网络分区处理策略
● 优先考虑一致性而非可用性：在设计系统时，如果数据一致性比服务的高可用性更重要，则可以在检测到网络分区后主动停止部分服务，直到网络恢复。
● 使用强一致性的协调机制：虽然Redis Sentinel本身并不直接提供解决脑裂的机制，但在某些场景下可以结合外部工具或机制来增强一致性保障，例如使用Paxos算法实现的协调服务。
● redis的集群模式
● redis集群的数据分配？
● Redis集群模式下，数据分布是通过哈希槽机制来实现的。整个键空间被划分为16384个哈希槽，这些哈希槽均匀分布在集群的所有主节点上
● redis的集群模式，数据是如何分配的？
● 当你向集群写入一个键"user:100"时，Redis会执行以下步骤：
● 使用CRC16算法计算"user:100"的哈希值。
● 将该哈希值对16384取模得到哈希槽编号。
● 根据哈希槽编号确定负责该槽的节点（在这个例子中可能是节点A、B或C中的一个）。
● 客户端直接与相应的节点通信以执行读写操作。
● 通过这种方式，Redis集群实现了高效的数据分布和负载均衡，同时也保证了系统的高可用性和可扩展性。
● CRC16的优势
● 高效性：CRC16计算速度快，适合用于实时系统中快速的数据完整性检查。
● 可靠性：尽管CRC16不如更长的CRC（如CRC32或CRC64）那样能提供更高的准确性，但对于许多应用场景来说已经足够，并且由于其较短的长度，在某些场景下反而更有优势。
● 分布均匀性：在Redis集群中，使用CRC16可以帮助确保键能够较为均匀地分布在各个哈希槽之间，进而均衡负载于不同节点上。
● Redis集群的高可用性有如下
● 1.自动分片 2.高可用性 3.水平扩展 4.自动故障祝转移
●
● 缓存穿透
● 什么是缓存穿透？
● 缓存穿透是查询一个不存在的key，使得大量的请求到db中，导致系统奔溃。
● 如何解决缓存穿透？
● 对空值进行缓存
● 使用布隆过滤器判断该元素是否在集合中
● 实时监控和限流
● 缓存击穿
● 什么是缓存击穿？
● 缓存击穿是指，一个热门的key过期后，大量的请求发送到DB，从而使系统变慢，
● 如何解决？
● 设置锁，当查询来了以后，加上一个互斥锁，确保同一时刻只有一个线程可以操作。
● 设置永不过期策略。
● 设置分级缓存，如在应用服务器也存储一份。
● 缓存雪崩
● 什么是缓存雪崩？
● 缓存雪崩是指在同一时刻大量的key同时过期，导致请求直接打到后端存储。
● 如何解决？
● 缓存设置时间随机，给每个缓存项设置一个略微不同的过期时间。
● 限流操作：在API网关层面对请求进行限流
● 缓存预热： 在系统启动或维护之后，预先加载一些重要的缓存数据。
● 设置缓存永不过期。
● 分布式锁
●