SpringCloud-高级篇（十）

（1）单节点Redis问题

缓存大家都不陌生，在企业里面只要做缓存都会用到Redis，我们在使用的时候都是做的单节点部署，单节点部署是存在一些问题的，分布式缓存正是Redis的集群，正是为了解决单节点部署的问题的

单节点Redis存在的问题：

Redis是基于内存存储，并发能力非常强但是毕竟单节点，到了618等节日电商场景，还是无法满足高并发场景

业务对Redis的依赖非常多，不仅仅把它做为缓存，有时候还把它作为分布式Session 等等，Redis应用场景如此的多，一旦它出现故障，对整个微服务影响范围也很大，我们得保证Redis集群是持续可用的，一旦集群中任何一个服务出现故障，不能够影响其他服务的使用，必须保证在运行的过程中去修复故障的节点实现在线边运行边修复的效果，单节点Redis做不到

主从集群，从节点有很多个，多个从节点之间就是负载均衡，主从之间做读写分离，应对数据库中读写的互斥，做了读写的分离，读和写之间就不会有影响了，并发能力也就更强了，也满足高可用的效果，因为主宕机了还有从顶上去，进一步避免宕机导致的数据丢失，虽然书从节点很多但是一直挂下去总有一天会挂完，所以不仅人多做主从，还要保证一旦有人挂了要把它扶起来，故障恢复，就要靠哨兵机制了

我们做了主从集群，存储上限还是单个节点的存储上限，我们可以学习ES，在ES中我们把数据分片保存在不同的节点上，存储更多的数据，Redis搭建分片集群利用插槽机制实现数据分散还可以动态扩容

（2）Redis持久化-RDB

启动：

Redis客户端建立连接：

Redis在停机是自动执行Save：存储数据快照

按Ctrl +C：关机的时候执行的Save（同步）

数据快照默认保存在运行目录

重新启动Redis：会读取RDB快照文件

数据还在：

数据持久化都是停机后执行的，那么突然宕机了，没有做持久化，我们需要没隔一段时间，就做一下持久化，RDB默认就开启了，RDB是bgsave（异步）：

修改了快照名称，当启动Redis的时候并没有数据恢复的日志：因为没有这个快照，有的话就会显示

此时再获取数据就没有了，因为快照名称修改了：

重新添加一个key：

看到Redis的日志：进行了持久化

Redis如果设置策略时间太长，中间的这一段时间做了数据的写入没有持久化就会导致数据丢失，如果调短一些设置为1s，行不，不行的如果你的时间调的非常短，RDB执行的频率就会过高，每一秒执行一次，数据量小还好，如果数据量很大，10G写入磁盘，1秒执行一次根本忙不过来，因此来说时间也不能做的太短，也不能太长，使用默认的就可以了，如果在默认的时间内出现了数据丢失，怎么办呢？后面会学习其他的持久化方案AOF，对RDB进行一个弥补

（3）RDB异步持久化原理-Bgsave

bgsage开始fork主进程是得到子进程的时候，是阻塞的，此时主进程只能干这件事，为了加快速度完成这件事，主进程尽快的去处理用户的请求避免阻塞时间过久，fork底层是怎么实现的呢？

之后是异步的

物理内存可以理解计算机的内存条，主进程实现对Redis的读写，肯定是在内存中操作，在Linux系统中所有的进程都没有办法直接操作物理内存而是由操作系统给每个进程分配一个虚拟内存主进程只能操作虚拟内存，操作系统会维护一个虚拟内存与物理内存之间的映射表称为页表，主进程操作虚拟内存，虚拟内存基于页表的映射关系，到物理内存中真正的存储位置，就能实现对物理内存数据的读写了

在fork的时候并不是把内存数据做拷贝，而是把页表做拷贝，子进程在操作虚拟内存时，根据页表跟主进程一样，一定能映射到相同的物理内存区域就可以实现子进程跟主进程的内存共享了，这样无需拷贝内存中的数据而实现内存共享这样速度就会非常的快，阻塞的时间也就非常的短了