redis强化二

Author: xbox1994

MD/数据库-Redis.md

@@ -17,11 +17,13 @@ Redis是一个键值对数据库，数据库中的键值对由字典保存。每
 来源： https://my.oschina.net/zhangxufeng/blog/905611  https://www.cnblogs.com/leeSmall/p/8398401.html
 ### 主从
 ![](https://github.com/xbox1994/2018-Java-Interview/raw/master/images/redis主从.png)
+
 用一个redis实例作为主机，其余的实例作为从机。主机和从机的数据完全一致，主机支持数据的写入和读取等各项操作，而从机则只支持与主机数据的同步和读取。因而可以将写入数据的命令发送给主机执行，而读取数据的命令发送给不同的从机执行，从而达到读写分离的目的。
 
 问题是主从模式如果所连接的redis实例因为故障下线了，没有提供一定的手段通知客户端另外可连接的客户端地址，因而需要手动更改客户端配置重新连接。如果主节点由于故障下线了，那么从节点因为没有主节点而同步中断，因而需要人工进行故障转移工作。为了解决这两个问题，在2.8版本之后redis正式提供了sentinel（哨兵）架构。
 ### 哨兵
 ![](https://github.com/xbox1994/2018-Java-Interview/raw/master/images/redis哨兵.png)
+
 由Sentinel节点定期监控发现主节点是否出现了故障，当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。
 
 ### 集群
@@ -30,16 +32,25 @@ Redis是一个键值对数据库，数据库中的键值对由字典保存。每
 redis集群中数据是和槽（slot）挂钩的，其总共定义了16384个槽，所有的数据根据一致哈希算法会被映射到这16384个槽中的某个槽中；另一方面，这16384个槽是按照设置被分配到不同的redis节点上。由此引发的一致性hash问题可以参看[这里](https://github.com/crossoverJie/JCSprout/blob/master/MD/Consistent-Hash.md)
 
 ### 如何选择
-集群的优势在于高可用，将写操作分开到不同的节点，如果写的操作较多且数据量巨大，且不需要Lua、事务、Pipeline这样的高级功能则可能考虑集群  
-哨兵的优势在于高可用，支持Lua、事务、Pipeline等高级功能，且能在读的操作较多的场景下工作，所以在绝大多数场景中是适合的  
-主从的优势在于支持Lua、事务、Pipeline等高级功能，且能在读的操作较多的场景下工作，但无法保证高可用，不建议在数据要求严格的场景下使用
+
+1. 集群的优势在于高可用，将写操作分开到不同的节点，如果写的操作较多且数据量巨大，且不需要Lua、事务、Pipeline这样的高级功能则可能考虑集群
+2. 哨兵的优势在于高可用，支持Lua、事务、Pipeline等高级功能，且能在读的操作较多的场景下工作，所以在绝大多数场景中是适合的
+3. 主从的优势在于支持Lua、事务、Pipeline等高级功能，且能在读的操作较多的场景下工作，但无法保证高可用，不建议在数据要求严格的场景下使用
 
 ## 使用策略
+### 延迟加载
+读：当读请求到来时，先从缓存读，如果读不到就从数据库读，读完之后同步到缓存且添加过期时间  
+写：当写请求到来时，只写数据库
 
-## 持久化
-RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。  
-AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。  
-Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。
+优点：仅对请求的数据进行一段时间的缓存，没有请求过的数据就不会被缓存，节省缓存空间；节点出现故障并不是致命的，因为可以从数据库中得到  
+缺点：缓存数据不是最新的；【缓存击穿】；【缓存失效】
+
+### 直写
+读：当读请求到来时，只从缓存读  
+写：当写请求到来时，先写数据库然后同步到缓存，设置为永不过期
+
+优点：缓存数据永不过时且为最新  
+缺点：每次写入都需要写缓存导致的性能损失；重启节点或故障会导致缓存数据的丢失直到有写操作同步到缓存；大量数据可能没有被读取的资源浪费
 
 ## 缓存问题
 ### 缓存击穿
@@ -49,10 +60,15 @@ Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下
 ### 缓存失效
 在高并发的环境下，如果此时key对应的缓存失效，此时有多个进程就会去同时去查询DB，然后再去同时设置缓存。这个时候如果这个key是系统中的热点key或者同时失效的数量比较多时，DB访问量会瞬间增大，造成过大的压力。
 
-1. 将系统中key的缓存失效时间均匀地错开　　
-2. 当我们通过key去查询数据时，首先查询缓存，如果此时缓存中查询不到，就通过分布式锁进行加锁
+将系统中key的缓存失效时间均匀地错开　　
 ### 热点key
 缓存中的某些Key(可能对应用与某个促销商品)对应的value存储在集群中一台机器，使得所有流量涌向同一机器，成为系统的瓶颈，该问题的挑战在于它无法通过增加机器容量来解决。
 
 1. 客户端热点key缓存：将热点key对应value并缓存在客户端本地，并且设置一个失效时间。
 2. 将热点key分散为多个子key，然后存储到缓存集群的不同机器上，这些子key对应的value都和热点key是一样的。
+
+## 持久化
+RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。  
+AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。  
+Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。  
+但实际上持久化会对Redis的性能造成非常严重的影响，如果一定需要保存数据，那么数据就不应该依靠缓存来保存，建议使用其他方式如数据库。所以Redis的持久化意义不大。