12.复习-Redis
12.复习-Redis
咸鱼Redis
1、完全基于内存的，C语言编写
2、采用单线程，避免不必要的上下文切换可竞争条件
3、使用多路I/O复用模型，非阻塞IO
I/O多路复用模型
- I/O多路复用是指利用单个线程来同时监听多个Socket ，并在某个Socket可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。
- 目前的I/O多路复用都是采用的epoll模式实现，它会在通知用户进程Socket就绪的同时，把已就绪的Socket写入用户空间，不需要挨个遍历Socket来判断是否就绪，提升了性能。
- 其中Redis的网络模型就是使用I/O多路复用结合事件的处理器来应对多个Socket请求，比如，提供了连接应答处理器、命令回复处理器，命令请求处理器；
- 在Redis6.0之后，为了提升更好的性能，在命令回复处理器使用了多线程来处理回复事件，在命令请求处理器中，将命令的转换使用了多线程，增加命令转换速度，在命令执行的时候，依然是单线程
缓存穿透
缓存穿透是指查询一个一定不存在的数据，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到 DB 去查询，可能导致 DB 挂掉。这种情况大概率是遭到了攻击。
通常都会用布隆过滤器来解决它，布隆过滤器主要是用于检索一个元素是否在一个集合中。
布隆过滤器
布隆过滤器的底层主要是先去初始化一个比较大数组，里面存放的二进制0或1。在一开始都是0，当一个key来了之后经过3次hash计算，模于数组长度找到数据的下标然后把数组中原来的0改为1，这样的话，三个数组的位置就能标明一个key的存在。查找的过程也是一样的。
当然是有缺点的，布隆过滤器有可能会产生一定的误判，我们一般可以设置这个误判率，大概不会超过5%，其实这个误判是必然存在的，要不就得增加数组的长度，其实5%以内的误判率一般的项目也能接受，不至于高并发下压倒数据库。
缓存击穿
缓存击穿的意思是对于设置了过期时间的key，缓存在某个时间点过期的时候，恰好这时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端 DB 加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把 DB 压垮。
解决方案有两种方式：
第一、可以使用互斥锁：当缓存失效时，不立即去load db，先使用如 Redis 的 setnx 去设置一个互斥锁，当操作成功返回时再进行 load db的操作并回设缓存，否则重试get缓存的方法
第二、种方案可以设置当前key逻辑过期，大概是思路如下：
①：在设置key的时候，设置一个过期时间字段一块存入缓存中，不给当前key设置过期时间
②：当查询的时候，从redis取出数据后判断时间是否过期
③：如果过期则开通另外一个线程进行数据同步，当前线程正常返回数据，这个数据不是最新
当然两种方案各有利弊：
如果选择数据的强一致性，建议使用分布式锁的方案，性能上可能没那么高，锁需要等，也有可能产生死锁的问题
如果选择key的逻辑删除，则优先考虑的高可用性，性能比较高，但是数据同步这块做不到强一致。
缓存雪崩
缓存雪崩意思是设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB 瞬时压力过重雪崩。与缓存击穿的区别：雪崩是很多key，击穿是某一个key缓存。
解决方案主要是可以将缓存失效时间分散开，比如可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。
双写一致性
mysql的数据与redis进行同步
如果需要让数据库与redis高度保持一致，要求时效性比较高，可以采用读写锁保证的强一致性。
读写锁：
- 在读的时候添加共享锁，可以保证读读不互斥，读写互斥。
- 当我们更新数据的时候添加排他锁，它是读写，读读都互斥
- 这样就能保证在写数据的同时是不会让其他线程读数据的，避免了脏数据。这里面需要注意的是读方法和写方法上需要使用同一把锁才行。
Redis中实现排他锁
实现分布式排他锁的过程可以分为以下几个步骤：
尝试获取锁：
当一个客户端需要对某个资源进行独占访问时，它会通过执行SETNX命令尝试设置一个具有唯一标识符的键。例如：1
SETNX lock_key unique_value
如果
lock_key不存在（即没有其他客户端持有该锁），那么SETNX命令会原子性地将lock_key设置为unique_value并返回1，表示成功获取了锁。添加超时机制（防止死锁）：
仅仅依靠SETNX命令不足以防止死锁，因为如果获取锁的客户端发生意外崩溃或网络中断，这个锁可能会永远无法释放。为了确保锁最终能够被释放，通常还需要给锁设置一个过期时间，可以通过额外的EXPIRE命令来完成：1
EXPIRE lock_key lock_ttl_seconds
这样，即使获取锁的客户端未能主动释放锁，锁也会在
lock_ttl_seconds秒后自动删除。业务逻辑处理：
获取到锁之后，客户端可以安全地执行与该资源相关的业务逻辑。释放锁：
在业务逻辑处理完毕后，客户端应负责释放锁，这可以通过DEL命令删除代表锁的键来实现：1
DEL lock_key
可重入性和公平性的优化：
要实现更完善的分布式锁，可能需要增加可重入性和公平性支持。简单来说，可重入意味着同一个客户端在已经持有锁的情况下，仍然可以再次请求并获得锁；而公平性则要求锁按照请求的顺序分配给客户端。这些特性往往通过自定义的数据结构和逻辑实现，比如使用有序集合（Sorted Set）、字符串记录锁的所有者和计数等。
现代的Redis客户端库如Redisson提供了高级封装，直接支持分布式锁，并且具备上述提到的可重入、超时、公平性等特点，简化了开发者直接使用Redis原生命令实现分布式锁的工作量和复杂度。
延时双删
延迟双删，如果是写操作，我们先把缓存中的数据删除，然后更新数据库，最后再延时删除缓存中的数据，其中这个延时多久不太好确定，在延时的过程中可能会出现脏数据，并不能保证强一致性。
1 | 延时双删开始 |
mysql的数据与redis进行同步
MySQL数据与Redis进行同步，以实现缓存一致性，通常有以下几种常见方法：
1、应用程序双写：
在应用层面上，每次对MySQL数据库进行写操作时，同时将变更的数据更新到Redis缓存中。这是最直接的方法，需要在业务代码中添加额外的逻辑来保证数据库和缓存的一致性。
2、触发器同步：
可以在MySQL中为特定表创建触发器（如AFTER INSERT, UPDATE, DELETE），当数据库发生相应操作时，触发器会执行相应的逻辑，通过调用脚本或函数将更改同步至Redis。
但是这种方法可能增加数据库负载，且对于分布式场景下的复杂数据模型和事务支持有限。
3、基于binlog同步：
利用MySQL的binlog日志，可以通过监听并解析binlog中的事件变化，然后将这些变更应用到Redis中。
Canal、Maxwell、Debezium等工具可以用于消费MySQL的binlog，并将变更同步至Redis或其他存储系统。
Redis关于数据的持久化
在Redis中提供了两种数据持久化的方式：1、RDB 2、AOF
RDB是一个快照文件，它是把redis内存存储的数据写到磁盘上，当redis实例宕机恢复数据的时候，方便从RDB的快照文件中恢复数据。
AOF的含义是追加文件，当redis操作写命令的时候，都会存储这个文件中，当redis实例宕机恢复数据的时候，会从这个文件中再次执行一遍命令来恢复数据
RDB因为是二进制文件，在保存的时候体积也是比较小的，它恢复的比较快，但是它有可能会丢数据，我们通常在项目中也会使用AOF来恢复数据，虽然AOF恢复的速度慢一些，但是它丢数据的风险要小很多，在AOF文件中可以设置刷盘策略，可以设置每秒批量写入一次命令
Redis的数据过期策略
在redis中提供了两种数据过期删除策略
第一种是惰性删除，在设置该key过期时间后，我们不去管它，当需要该key时，我们在检查其是否过期，如果过期，我们就删掉它，反之返回该key。
第二种是 定期删除，就是说每隔一段时间，我们就对一些key进行检查，删除里面过期的key
定期清理的两种模式：
- SLOW模式是定时任务，执行频率默认为10hz，每次不超过25ms，以通过修改配置文件redis.conf 的 hz 选项来调整这个次数
- FAST模式执行频率不固定，每次事件循环会尝试执行，但两次间隔不低于2ms，每次耗时不超过1ms
Redis的过期删除策略：惰性删除 + 定期删除两种策略进行配合使用。
Redis的数据淘汰策略
这个在redis中提供了很多种，默认是noeviction，不删除任何数据，内部不足直接报错
是可以在redis的配置文件中进行设置的，里面有两个非常重要的概念，一个是LRU，另外一个是LFU
LRU（least recently used）的意思就是最少最近使用，用当前时间减去最后一次访问时间，这个值越大则淘汰优先级越高。
LFU（Least Frequently Used）的意思是最少频率使用。会统计每个key的访问频率，值越小淘汰优先级越高
