redis部分机制
Redis的持久化机制
RDB：在指定的时间间隔内将内存的中的数据集快照写入磁盘，实际操作过程是fork一个子进程，现将数据集写入临时文件，写入成功以后，再替换之前的文件，使用二进制压缩存储。Redis 重启时，会读取 dump.rdb 文件恢复数据。
优点：
1.整个Redis数据库只包含一个文件dump.rdb，方便持久化。
2.容灾性好，方便备份。
3.性能好，fork子进程来完成写操作，主进程可以继续处理命令，保证IO最大化，保证高性能。
4.相对于数据集大时候，比AOF的启动效率高。
缺点：
1.数据安全性低。RDB是间隔一段时间进行持久化，持久化之间发生故障，数据会丢失。
2.由于是fork一个子进程来协助完成数据持久化，因此在数据集较大的时候会导致服务器停止服务几百毫秒。
AOF： Append Only File，以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录。
优点：
1.数据安全，提供三种同步策略，即每秒同步、每修改同步、和不同步。事实上，每秒同步是异步完成的，其效率也是非常高，所差的是一旦系统出现宕机现象，那么这一秒之内的修改的数据将会丢失。每修改同步，可以视为同步持久化，每次发生数据变化都会被立即记录到磁盘中。
2.通过append模式写文件，即使服务器宕机也不会破坏已经存在的内容，可以通过redis-check-aof工具解决数据一致性的问题。
3.AOF机制的rewrite模式。定期对AOF文件进行重写，以达到压缩的目的。
缺点：
1.AOF文件比RDB文件大，且文件恢复速度慢。
2.数据集大的时候，比rdb启动效率低。
3.运行效率没有RDB高。
小结：AOF文件比RDb更新频率高，优先使用AOF还原数据，AOF比RDB更安全但也更大，两个都配置了优先加载AOF。
redis的延迟双删策略
什么是延迟双删
这个策略的基本思想是：在更新数据库后，不是立即删除Redis中的旧值，而是等待一段时间（比如几百毫秒）后再删除。这样做的目的是为了让那些读取了旧值并准备放入Redis的线程或进程有时间完成它们的操作。等待一段时间后，我们再删除Redis中的旧值，这样就可以确保Redis中的数据是最新的。
为什么要用延迟双删
先从Redis中查询数据，如果Redis中没有，则去数据库中查询，并将查询结果放入Redis中，以便下次可以直接从Redis中获取。但是，在这个过程中，可能会存在数据不一致的问题。
具体来说，假设有一个数据A，它在数据库中的值是1，但在Redis中的值是2。当我们要更新这个数据A的值时，首先会更新数据库中的值，然后再删除Redis中的旧值。但是，如果在删除Redis中的旧值之前，有其他线程或进程读取了这个旧值并放入了Redis中，那么Redis中的数据就还是旧的，这就导致了数据不一致的问题。
小结：延迟双删用来保证数据存储和缓存数据一致性的常用策略，需要注意的是，延迟双删并不能完全解决数据不一致的问题。它只能在一定程度上减少数据不一致的可能性。在实际应用中，我们还需要结合其他策略（如消息队列、分布式锁等）来确保数据的一致性。
redis如何保证高可用
- 数据持久化：Redis提供了两种主要的数据持久化方式，即上述的RDB和AOF。RDB通过定期生成数据快照并保存到磁盘上来实现数据的持久化。而AOF则记录所有对Redis的写操作，当Redis重启时，可以重新执行这些写操作来恢复数据。这两种方式都可以帮助在Redis崩溃或服务器故障时恢复数据，从而保证服务的高可用性。
- 主从复制：主从复制是实现Redis高可用性的重要手段。在这种配置中，有一个主节点（Master）负责处理写请求，而一个或多个从节点（Slave）负责复制主节点的数据并处理读请求。当主节点出现故障时，从节点可以接管主节点的工作，保证服务的连续性。此外，读写分离读写请求也可以提高系统的吞吐量和性能。
- 哨兵模式：哨兵（Sentinel）用于监控主从节点的状态。当主节点出现故障时，哨兵会自动将从节点提升为主节点，实现自动故障转移，保证服务的连续性。哨兵模式与主从复制结合，可以大大提高Redis的高可用性。
主从模式如何选举出主节点
当主节点出现故障时，就需要一种机制来自动选择一个从节点提升为主节点，以保证服务的连续性。这通常是通过哨兵模式来实现的。哨兵会监控主节点的状态，一旦检测到主节点不可用，就会开始从从节点中选择一个新的主节点。
在选择新的主节点时，哨兵会考虑一些因素，如从节点的优先级、数据同步情况等。具体来说，哨兵会按照以下步骤进行选举：
- 优先级选择：首先，哨兵会查看所有从节点的优先级配置。优先级是可以通过配置来设置的，优先级越高的从节点越有可能被选为新的主节点。如果没有设置优先级，那么所有从节点的优先级默认为100。
- 数据同步情况：如果多个从节点的优先级相同，哨兵会进一步检查它们的数据同步情况。具体来说，它会比较从节点的复制偏移量（replication offset），也就是从节点已经复制了多少主节点的数据。复制偏移量越大的从节点，说明它的数据越新，越有可能被选为新的主节点。
- 运行ID比较：如果以上两个条件都相同，那么哨兵会最后比较从节点的运行ID。运行ID是一个唯一标识Redis节点的字符串，用于在集群中区分不同的节点。哨兵会选择一个运行ID较小的从节点作为新的主节点。
redis与MySQL如何让保持数据一致性
比如上述的延迟双删，但是面对大数据量下的读写超时还是有可能读到脏数据。除此以外还可以尝试以下几种方式：
- 双写一致性：
- 最直接的方法是在业务代码中同时对MySQL和Redis进行更新。这确保了数据在两者之间的即时同步，但可能会影响性能，特别是在高并发的场景下。
- 异步更新：
- 引入消息队列（如RabbitMQ）来异步更新Redis。当MySQL中的数据发生变化时，通过消息队列通知Redis进行更新。这种方法降低了数据不一致的风险，但仍然存在因消息丢失而导致的不一致问题。
- 基于binlog的更新：
- 使用MySQL的binlog来监听数据变更，并据此更新Redis。这是一种更为可靠的方法，因为它直接基于MySQL的数据变更日志进行操作。
- 定时同步：
- 应用程序可以定期将MySQL中的数据同步到Redis中。这种方法实现简单，但可能导致数据不一致，因为数据在同步的过程中可能会被修改。
- 并发控制：
- 在高并发的场景下，需要特别注意并发更新可能导致的数据不一致问题。可以使用分布式锁或其他并发控制机制来确保数据的一致性。
- 监控与报警：
- 实施监控策略，定期检查MySQL和Redis之间的数据一致性。设置报警机制，当检测到数据不一致时及时通知相关人员进行处理。
- 事务与回滚：
- 在可能的情况下，使用事务来确保MySQL和Redis的更新操作要么全部成功，要么全部失败。这样，即使发生错误，也可以回滚到一致的状态。
redis过期key的删除策略
定时过期：每个设置过期时间的key都需要创建⼀个定时器，到过期时间就会⽴即清除。该策略可以立即清除过期的数据，对内存很友好；但是会占⽤⼤量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量
惰性过期：只有当访问⼀个key时，才会判断该key是否已过期，过期则清除。该策略可以最⼤化地节省CPU资源，但是很消耗内存、许多的过期数据都还存在内存中。极端情况可能出现⼤量的过期，分布式系统中常⽤的缓存⽅案有哪些 key没有 再次被访问，从⽽不会被清除，占⽤⼤量内存。
定期过期：每隔⼀定的时间，会扫描⼀定数量的数据库的expires字典中⼀定数量的key（是随机 的）， 并清除其中已过期的key。该策略是定时过期和惰性过期的折中⽅案。通过调整定时扫描的 时间间隔和 每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。
分桶策略：定期过期的优化，将过期时间点相近的key放在⼀起，按时间扫描分桶。