Redis相关问题以及讲解

刺骨的言语ヽ痛彻心扉 2022-12-16 15:24 133阅读 0赞

**Redis持久化**  
Redis 提供了两种数据持久化的方式，一种是 RDB，另一种是 AOF。默认情况下，Redis 使用的是 RDB 持久化。  
RDB持久化文件体积较小，但是保存数据的频率一般较低，可靠性差，容易丢失数据。另外RDB写数据时会采用Fork函数拷贝主进程，可能有额外的内存消耗，文件压缩也会有额外的CPU消耗。  
AOF持久化可以做到每秒钟持久化一次，可靠性高。但是持久化文件体积较大，导致数据恢复时读取文件时间较长，效率略低。

**Redis集群**  
Redis集群可以分为**主从集群**和**分片集群**两类。

**主从集群**一般一主多从，主库用来写数据，从库用来读数据。结合哨兵，可以再主库宕机时从新选主，**目的是保证Redis的高可用**。

**分片集群**是数据分片，我们会让多个Redis节点组成集群，并将16383个插槽分到不同的节点上。存储数据时利用对key做hash运算，得到插槽值后存储到对应的节点即可。因为存储数据面向的是插槽而非节点本身，因此可以做到集群动态伸缩。**目的是让Redis能存储更多数据。**

1）主从集群

主从集群，也是读写分离集群。一般都是一主多从方式。

Redis 的复制（replication）功能允许用户根据一个 Redis 服务器来创建任意多个该服务器的复制品，其中被复制的服务器为主服务器（master），而通过复制创建出来的服务器复制品则为从服务器（slave）。

只要主从服务器之间的网络连接正常，主从服务器两者会具有相同的数据，主服务器就会一直将发生在自己身上的数据更新同步 给从服务器，从而一直保证主从服务器的数据相同。

*  写数据时只能通过主节点完成
 *  读数据可以从任何节点完成
 *  如果配置了`哨兵节点`，当master宕机时，哨兵会从salve节点选出一个新的主。

主从集群分两种：![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl81MTI5MTQ4Mw_size_16_color_FFFFFF_t_70_pic_center]  
带有哨兵的集群：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl81MTI5MTQ4Mw_size_16_color_FFFFFF_t_70_pic_center 1]  
2）分片集群

主从集群中，每个节点都要保存所有信息，容易形成木桶效应。并且当数据量较大时，单个机器无法满足需求。此时我们就要使用分片集群了。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl81MTI5MTQ4Mw_size_16_color_FFFFFF_t_70_pic_center 2]  
集群特征：

*  每个节点都保存不同数据
 *  所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽.
 *  节点的fail是通过集群中超过半数的节点检测失效时才生效.
 *  客户端与redis节点直连,不需要中间proxy层连接集群中任何一个可用节点都可以访问到数据
 *  redis-cluster把所有的物理节点映射到\[0-16383\]slot（插槽）上，实现动态伸缩

为了保证Redis中每个节点的高可用，我们还可以给每个节点创建replication（slave节点），如图：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl81MTI5MTQ4Mw_size_16_color_FFFFFF_t_70_pic_center 3]  
出现故障时，主从可以及时切换：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl81MTI5MTQ4Mw_size_16_color_FFFFFF_t_70_pic_center 4]

**Redis的常用数据类型有哪些？**  
支持多种类型的数据结构，主要区别是value存储的数据格式不同：  
string：最基本的数据类型，二进制安全的字符串，最大512M。  
list：按照添加顺序保持顺序的字符串列表。  
set：无序的字符串集合，不存在重复的元素。  
sorted set：已排序的字符串集合。  
hash：key-value对格式。

**Redis事务**  
Redis事务其实是把一系列Redis命令放入队列，然后批量执行，执行过程中不会有其它事务来打断。不过与关系型数据库的事务不同，Redis事务不支持回滚操作，事务中某个命令执行失败，其它命令依然会执行。  
为了弥补不能回滚的问题，Redis会在事务入队时就检查命令，如果命令异常则会放弃整个事务。  
因此，只要程序员编程是正确的，理论上说Redis会正确执行所有事务，无需回滚。

**如果事务执行一半的时候Redis宕机怎么办？**  
Redis有持久化机制，因为可靠性问题，我们一般使用AOF持久化。事务的所有命令也会写入AOF文件，但是如果在执行EXEC命令之前，Redis已经宕机，则AOF文件中事务不完整。使用 redis-check-aof 程序可以移除 AOF 文件中不完整事务的信息，确保服务器可以顺利启动。

**Redis过期策略**  
Redis过期策略包含定期删除和惰性删除两部分。定期删除是在Redis内部有一个定时任务，会定期删除一些过期的key。惰性删除是当用户查询某个Key时，会检查这个Key是否已经过期，如果没过期则返回用户，如果过期则删除。  
但是这两个策略都无法保证过期key一定删除，漏网之鱼越来越多，还可能导致内存溢出。当发生内存不足问题时，Redis还会做内存回收。内存回收采用LRU策略，就是最近最少使用。其原理就是记录每个Key的最近使用时间，内存回收时，随机抽取一些Key，比较其使用时间，把最老的几个删除。  
Redis的逻辑是：最近使用过的，很可能再次被使用

**Redis在项目中的哪些地方有用到?**  
（1）共享session  
在分布式系统下，服务会部署在不同的tomcat，因此多个tomcat的session无法共享，以前存储在session中的数据无法实现共享，可以用redis代替session，解决分布式系统间数据共享问题。  
（2）数据缓存  
Redis采用内存存储，读写效率较高。我们可以把数据库的访问频率高的热点数据存储到redis中，这样用户请求时优先从redis中读取，减少数据库压力，提高并发能力。  
（3）异步队列  
Reids在内存存储引擎领域的一大优点是提供 list 和 set 操作，这使得Redis能作为一个很好的消息队列平台来使用。而且Redis中还有pub/sub这样的专用结构，用于1对N的消息通信模式。  
（4）分布式锁  
Redis中的乐观锁机制，可以帮助我们实现分布式锁的效果，用于解决分布式系统下的多线程安全问题

**Redis实现分布式锁**  
分布式锁要满足的条件：  
多进程互斥：同一时刻，只有一个进程可以获取锁  
保证锁可以释放：任务结束或出现异常，锁一定要释放，避免死锁  
阻塞锁（可选）：获取锁失败时可否重试  
重入锁（可选）：获取锁的代码递归调用时，依然可以获取锁

**缓存穿透及解决方案**  
缓存穿透有两种解决方案：其一是把不存在的key设置null值到缓存中。其二是使用布隆过滤器，在查询缓存前先通过布隆过滤器判断key是否存在，存在再去查询缓存。  
设置null值可能被恶意针对，攻击者使用大量不存在的不重复key ，那么方案一就会缓存大量不存在key数据。此时我们还可以对Key规定格式模板，然后对不存在的key做正则规范匹配，如果完全不符合就不用存null值到redis，而是直接返回错误。

**缓存击穿及解决方案**  
缓存击穿主要担心的是某个Key过期，更新缓存时引起对数据库的突发高并发访问。因此我们可以在更新缓存时采用互斥锁控制，只允许一个线程去更新缓存，其它线程等待并重新读取缓存。例如Redis的setnx命令就能实现互斥效果。

**缓存雪崩及解决方案**  
解决缓存雪崩问题的关键是让缓存Key的过期时间分散。因此我们可以把数据按照业务分类，然后设置不同过期时间。相同业务类型的key，设置固定时长加随机数。尽可能保证每个Key的过期时间都不相同。  
另外，Redis宕机也可能导致缓存雪崩，因此我们还要搭建Redis主从集群及哨兵监控，保证Redis的高可用。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl81MTI5MTQ4Mw_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/c2bff4f2fe6243b793938329c605c753.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl81MTI5MTQ4Mw_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221123/a369ffae47c24b3ca13695fbb363626f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl81MTI5MTQ4Mw_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221123/88639b9406a948d1ae77c8b1678b1849.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl81MTI5MTQ4Mw_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221123/5f42be5e57214be08c4bd273a076810c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl81MTI5MTQ4Mw_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221123/e6c0fb460f6b47aaa79290d43ee24ec0.png