（1）搭建Redis-主从架构

前面我们实现了Redis的持久化，解决了数据安全问题，但是还有需要解决的问题，下面学习Redis的主从集群，解决Redis的并发能力的问题

Redis的集群往往是主从集群，Redsi为什么做成主从的集群，而不做成传统负载均衡的集群呢？因为Redis应用当中往往都是读多写少的场景，查询比较多，增删改比较少，我们更多应对的是读的压力，做读写分离，一主多从，多个从节点共同承担读的请求，并发能力能够做到很大的提升，这就是为啥搭建主从集群

需要保证客户端无论访问那个从节点都要拿到相同的结果

修改每个配置文件

修改数据保存目录：默认是当前目录：

一个一个配置文件改比较麻烦可以使用一个命令：

s表示替换：把6379替换成7001 g是全局  把dir .替换成、tmp\7001

 

1a:表示在第一行的后面追加一行

7002设置为7001的从节点： 

此时7001会有日志产生：来自7002的请求数据同步

把7003设置为7001的从节点：replicaod跟slaveof命令效果一致

此时7001会有日志产生：来自7003的请求数据同步

查看7001的状态信息：从属关系

主节点： 

从节点 

从节点不能够写： 

就实现了主节点做些操作，从节点做读操作

（2）数据同步原理

数据同步的底层是如何做到的

全量同步：有一个RDB的过程，会把内存形成快照，整体发送给slave，是比较消耗性能的，生成RDB的速度比较慢，全量拷贝

Redis全量同步

第二次来，就可以根据offset来判断你的进度了，可以基于它做增量同步

查看我们的日志

7002日志：连接    sync同步

第一次7002请求尝试做局部的同步：增量同步，它会传过去id 和offset：1

7001主节点：主节点接口到增量同步，判断id不一样，就拒绝增量同步

拒绝之后做全量同步： 

7002只能做全量同步：

Reids增量同步

在什么情况下无法做增量同步：

offset底层是一个数组，

当slave宕机后，master在一直接收新数据，一直走，当它超多slave的宕机处，走了一环还在走，

slave欠的太多了一环没有记下，又多了一部分

这部分的数据被覆盖了，就消失了只能去master的内存中去找，只能去做全量同步了

（3）主从同步的优化

从两个方面：

1.尽可能的减少全量同步，全量同步的性能比较差嘛

2.优化全量同步的性能

   在配置文件中做无磁盘复制：正常的复制要生成RDB文件，比如说内存有10g，要在磁盘写10g，然后在把磁盘的文件通过网络发送给我们slave，磁盘的读写是比较慢的导致了，同步复制的效率比较低，无磁盘复制就是，当要写RDB文件时，就是io流，不去把它写入磁盘的io流，直接网络中，直接发给slave，减少了磁盘读写

在什么时候可以用呢？当磁盘很慢，网路很快，如果网络带宽不够快，会导致网络阻塞，一定要增加网络带宽

全量同步可以这样优化 

尽可能避免全量同步