Redis

Redis事务介绍

sql'事务的四大特性

原子性，将所有SQL作为原子工作单元执行，要么全部执行，要么全部不执行

一致性，事务完成后，所有数据的状态都是一致的，即A账户只要减去了100，B账户则必定加上了100；

隔离性，如果有多个事务并发执行，每个事务作出的修改必须与其他事务隔离

持久性，即事务完成后，对数据库数据的修改被持久化存储。

Redis的事务的三大特性

Redis事务是一组命令的集合，一个事务中的所有命令都将被序列化，按照一次性、顺序性、排他性的执行一系列的命令。

单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断

没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，也就不存在”事务内的查询要看到事务里的更新，在事务外查询不能看到”

不保证原子性：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚

Redis 的事务执行的三个阶段

事务从输入Multi命令开始，输入的命令都会依次压入命令缓冲队列中，并不会执行，直到输入Exec后，Redis会将之前的命令缓冲队列中的命令依次执行。组队过程中，可以通过discard来放弃组队。

Redis 主从复制

实际的场景当中单一节点的redis容易面临风险  比如 机器故障，容量瓶颈。

解决的方法   要实现分布式数据库的更大的存储容量和承受高并发访问量，我们会将原来集中式数据库的数据分别存储到其他多个网络节点上

主从复制

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点，后者称为从节点,数据的复制是单向的，只能由主节点到从节点。

作用

1. 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。

2. 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。

3. 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务 （即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。

4. 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

主从复制可以分为3个阶段

• 连接建立阶段（即准备阶段）

• 数据同步阶段

• 命令传播阶

6个过程：

1. 保存主节点（master）信息。

2. 从节点（slave）内部通过每秒运行的定时任务维护复制相关逻辑，当定时任务发现存在新的主节点后，会尝试与该节点建立网络连接

3. 节点与主节点建立网络连接  

从节点会建立一个 socket 套接字，从节点建立了一个端口为51234的套接字，专门用于接受主节点发送的复制命令

4. 发送ping命令

作用：

• 检测主从之间网络套接字是否可用

• 检测主节点当前是否可以接受命令

5.权限验证。如果主节点设置了 requirepass 参数，则需要密码验证，从节点必须配置 masterauth 参数保证与主节点相同的密码才能通过验证；如果验证失败复制将终止，从节点重新发起复制流程。

6.同步数据集。主从复制连接正常通信后，对于首次建立复制的场景，主节点会把持有的数据全部发送给从节点，这部分操作是耗时最长的步骤。

7.主从同步策略  主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。 redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。

Redis 哨兵监控

主从复制的缺点：当主机 Master 宕机以后，我们需要人工解决切换 ，重新选取主节点。手动设置主从关系。

哨兵概述

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

哨兵作用

1. 集群监控：负责监控redis master和slave进程是否正常工作

2. 消息通知：如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员

3. 故障转移：如果master node挂掉了，会自动转移到slave node上

4. 配置中心：如果故障转移发生了，通知client客户端新的master地址

哨兵原理

监控阶段

通知阶段

sentinel不断的向master和slave发起通知，收集信息。

故障转移阶段

通知阶段sentinel发送的通知没得到master的回应，就会把master标记为SRI_S_DOWN,并且把master的状态发给各个sentinel，其他sentinel听到master挂了，说我不信，我也去看看，并把结果共享给各个sentinel，当有一半的sentinel都认为master挂了的时候，就会把master标记为SRI_0_DOWN。

投票阶段

方式： 自己最先接到哪个sentinel的竞选通知就会把票投给它。

剔除一些情况：

1. 不在线的

2. 响应慢的

3. 与原来master断开时间久的

4. 优先级原则

Redis Cluster

Redis有三种集群模式

• 主从模式

• Sentinel模式

• Cluster模式

哨兵模式的缺点

缺点：

1. 当master挂掉的时候，sentinel 会选举出来一个 master，选举的时候是没有办法去访问Redis的，会存在访问瞬断的情况；

2. 哨兵模式，对外只有master节点可以写，slave节点只能用于读。尽管Redis单节点最多支持10W的QPS，但是在电商大促的时候，写数据的压力全部在master上。

3. Redis的单节点内存不能设置过大，若数据过大在主从同步将会很慢；在节点启动的时候，时间特别长；

Redis Cluster概述

Redis集群是一个由多个主从节点群组成的分布式服务集群，它具有复制、高可用和分片特性。

Redis集群的优点

• Redis集群有多个master，可以减小访问瞬断问题的影响

• Redis集群有多个master，可以提供更高的并发量　

• Redis集群可以分片存储，这样就可以存储更多的数据

Redis Cluster模式搭建

Redis常见问题

Redis脑裂问题

因为网络问题，导致Redis Master节点跟Redis slave节点和Sentinel集群处于不同的网络分区，此时因为sentinel集群无法感知到master的存在，所以将slave节点提升为master节点

集群脑裂问题中，如果客户端还在基于原来的master节点 继续写入数据，那么新的Master节点将无法同步这些数据，当网络问题解决之后，sentinel集群将原先的Master节点降为slave节点，此时再从新的master中同步数据，将会造成大量的数据丢失.

解决方案

min-replicas-to-write 1
min-replicas-max-lag 5


- 第一个参数表示最少的slave节点为1个 
- 第二个参数表示数据复制和同步的延迟不能超过5秒

Redis 缓存预热问题

缓存冷启动

问题因为缓存中没有数据，由于缓存冷启动一点数据都没有，如果直接就对外提供服务了，那么并发量上来Mysql就裸奔挂掉了

冷启动的场景

新启动的系统没有任何缓存数据，在缓存重建数据的过程中，系统性能和数据库负载都不太好，所以最好是在系统上线之前就把要缓存的热点数据加载到缓存中，这种缓存预加载手段就是缓存预热。

• 提前给redis中灌入部分数据，再提供服务

• 如果数据量非常大，就不可能将所有数据都写入redis，因为数据量太大了，第一是因为耗费的时间太长了，第二根本redis容纳不下所有的数据

• 需要根据当天的具体访问情况，实时统计出访问频率较高的热数据

• 然后将访问频率较高的热数据写入redis中，肯定是热数据也比较多，我们也得多个服务并行读取数据去写，并行的分布式的缓存预热

如何解决缓存冷启动问题？

冷启动是指服务器缓存中没有数据直接启动，访问量有比较大，mysql直接裸机运行。通过缓存预热解决，通过storm实时计算出热点数据，然后定时将热点数据写入缓存。

Redis缓存穿透问题

缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大。

缓存穿透是指用户查询数据，在数据库没有，自然在缓存中也不会有。这样就导致用户查询的时候，在缓存中找不到，每次都要去数据库再查询一遍，然后返回空（相当于进行了两次无用的查询）。这样请求就绕过缓存直接查数据库，这也是经常提的缓存命中率问题。

布隆过滤器

布隆过滤器是一种数据结构，比较巧妙的概率型数据结构，特点是高效地插入和查询，可以用来告诉你 “某样东西一定不存在或者可能存在”。

布隆说不存在一定不存在，布隆说存在，它也可能不存在。

结论

如何解决缓存穿透问题？

第一种方案 查询一个redis和mysql肯定都不存在的数据是缓存穿透，例如查询id为-1的数据，多半为认为恶意攻击。解决方案：去数据库查不存在在redis存null,并且设置过期时间5分钟。

第二种方案 用布隆过器解决：布隆过滤器是一个bitMap数组，它说不存在的元素一定不存在，他说存在的未必存在

Redis 缓存击穿问题

产生的问题

某一个热点 key，在缓存过期的一瞬间，同时有大量的请求打进来，由于此时缓存过期了，所以请求最终都会走到数据库，造成瞬时数据库请求量大、压力骤增，甚至可能打垮数据库。

思路：

• 互斥锁：在并发的多个请求中，只有第一个请求线程能拿到锁并执行数据库查询操作，其他的线程拿不到锁就阻塞等着，等到第一个线程将数据写入缓存后，其他线程直接查询缓存。

• 热点数据不过期：直接将缓存设置为不过期，然后由定时任务去异步加载数据，更新缓存（不咋靠谱）

Redis缓存雪崩问题

缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。

思路

• 过期时间打散：既然是大量缓存集中失效，那最容易想到就是让他们不集中生效。可以给缓存的过期时间时加上一个随机值时间，使得每个 key 的过期时间分布开来，不会集中在同一时刻失效。

• 热点数据不过期：该方式和缓存击穿一样，也是要着重考虑刷新的时间间隔和数据异常如何处理的情况。

• 加互斥锁: 该方式和缓存击穿一样，按 key 维度加锁，对于同一个 key，只允许一个线程去计算，其他线程原地阻塞等待第一个线程的计算结果，然后直接走缓存即可

结论：如何解决缓存雪崩问题

答：大量缓存同时失效，数据库被击垮问题。解决思路不让缓存同时失效，比如加给缓存过期时间加随机数，但是当缓存数据足够大时，这个效果不那么明显了，可以通过二级缓存技术实现。