4.1 Redis主从复制

这是一个从无到有，从简到繁的过程。
首先为了保证热点数据的高频访问，我们引入了缓存数据库redis。那么，我们使用一个redis实例。暂时性的解决了或少眉毛的问题。但是单个实例有以下几个弊端：
1、故障容忍问题。在产品中如果这个实例发生故障不能为业务提供支持，这对于已经上线的产品来讲是一个巨大的boom。等同于瘫痪，因为我们在redis中做的不仅仅是数据缓存，还会在redis中分布式场景下的session共享也可以称之为数据共享；分布式场景下的锁，分布式场景下的事务等等；
2、数据吞吐量问题。redis性能方面毋庸置疑的，但是我们有几句俗话—好虎架不住群狼，双拳难敌四手。我们还有几句俗话—三个臭皮匠顶个诸葛亮。这里其实是讲的量变引起质变的过程。访问量超过redis的临界值时，那么该怎么办呢？

万能的程序员对以上这些问题提供了解决方案----Redis集群。
上图：

那么集群模式下会遇到这样几个问题：
1、当master挂掉以后两个slave怎么顶替master继续提供服务呢？
2、数据一致性问题，既然slave要被降大任，那么它就必须要持有master的所有数据，否则那他就不堪重任了。

清楚上述两个问题以后我们先迈出第一步----让他们形成主从关系。
方法也是相当的简单。
在redis.conf这个文件当中有这样一个项配置：
#slaveof
在这一行的下面我们写上自己的配置：
slaveof 121.47.0.1 6379 （这是一个slave的配置)(当然这个我信口开河的一个ip 别当真 我是不会告诉你我自己的ip信息的）
对于master 我们不需要做什么，直接重启slave就可以。在slave节点进入redis客户端 输入info replication 命令就可以看到主从信息了。里面的内容也是相当简单，知道点英语的人都可以看懂。所以我想讲一个我自己遇到的问题？
我在输入info replication 命令以后遇到了这样一个问题。显示 master_link_status:down ;这个down让我很难受表示slave没有跟master联系上。
请检查两个地方：
1、在master节点redis.conf 里的 protected-mode 这个的值是不是 no 如果不是则改过来
2、使用 telnet ip port 来访问master主节点 如果连接不上 则到主节点的redis.conf 里修改bind 把它注释掉 并重启
3、如果你做了以上几个事情仍然是down 则可以考虑关闭master节点的防火墙

做了以上几件事情以后，再到slave里去info replication master_link_status:up 这个up才是我想要的

---

接下来我们要做的是数据的同步，使得slave和master的数据是一致的。
我先说过程在解释同步的原理是怎样的。
过程：过程也是相当的简单的，只要在master中set数据，那么在slave当中get数据是可以拿到相应的数据的。
原理 ：原理才是重中之重。
redsi的复制方式有三种：
1、全量复制
2、增量复制
3、无磁盘复制
全量复制的使用场景，在初始化的时候。即新增了一个slave节点，这个节点会把master的数据都复制过来。那么全量复制的过程是这样的，slave启动以后会向master发送SYNC命令，告诉master我是来做数据同步的；master在收到命令以后会使用bgsave命令来生成一个快照（这个快照是本地磁盘，会影响性能），把快照发送给salve；salve拿到快照以后就会做数据恢复load。
上图

那么这里有一个问题，主节点生成快照以后的命令什么时候同步呢？
master生成快照之后产生的命令会存在缓存之中，这些命令会发送给slave。这个过程类似于增量复制。这里是以命令的方式。
全量复制完成以后就开始做增量复制。

在这里我们应该注意到一个问题。
这个问题可能会发生在这样一个场景下：快照通过网络进行传输。那么如果由于网络的原因，或者其他的原因导致我们的salve没有能够把数据同步过来怎么办呢？更要命的是master是不知道他自己有几个slave的。
这里依然有解决方案：
min-slaves-to-write 3
这个表示只有当指定数量的slave节点连做了数据同步以后 master才是可写的；在此之前master会阻塞，不接收外部的请求，意思就是说：既然master不知道自己有几个salve那么我人工告诉他有几个slave，这总可以了吧。
那么还有一个配置：min-slave-max-lag 10
这个配置的意思是，允许slave最长失联多长时间，因为master-slave之间是维持这一个心跳包的。这样符合做事留余地，来日好相聚的逻辑了----一个容错空间

下面开始讲增量复制 这是redis2.8之后才有的哦
增量复制–顾名思义，当master数据发生改变，slave也会跟着同步数据。
那么这里就有一个问题master-slave他们两个是怎样知道，数据是从哪里开始复制的呢？
master会在内存当中创建一个backlog。backlog类似于日志，可以简单的这样理解一下。
在master客户端输入 info replication ，在众多的参数当中有这样两个信息：
slave_repl_offset:1049(这个数据仅仅是样品)
repl_backlog_active:1(这个数据依然是样品)
slave_repl_offset表示当前数据同步的位置，他是保存在backlog里的。
当slave和master重新恢复连接以后，slave会从自己的backlog当中获取offset数据到master中的这个位置开始恢复（也叫同步）数据

下面讲无磁盘复制
在增量复制的时候，会生成快照文件。众所周知的是生成快照文件是会影响性能的。那么有没有精益求精的方式呢？
有呀。在redis2.8之后提供了无磁盘复制。
使用起来也是相当的简单。
在master的redis.conf里有repl-diskless-sync no 这个配置 的意思是让redis不生成磁盘快照。那么问题来了–不生成磁盘快照的话怎么来实现数据同步呢？
在内存里创建rdb数据（其实也是快照文件），直接发送，而不是使用本地磁盘（全量复制是本地磁盘）。

下面开始讲redis选主
经过以上内容我们解决了redis集群主从之间数据的同步问题。这只是迈出了万里长征的第一步，那么我们依然有问题需要解决。这个问题就是：当master节点挂掉以后，集群怎样继续为应用提供服务。

这个问题也是相当的简单，为了保证系列文章的完整性，我还是决定分享。
redis自身并没有互相感知这个功能。万能的程序员提供了解决方案。
sentinel–哨兵
这个是redis官方提供的高可用解决方案。欢呼吧，既然是官方提供的，说明有很好的用户体验，也就是说不需要我们另外做什么了。
我们公司比较大条。单独搞了一个主机运行一个redis实例，这个实例的主要目的就是开启redis的sentinel功能。其实我感觉不用这么做的。我可以在redis实例A上来监控redis实例B，redis实例B上监控C ，C上监控A。意思就是说sentinel不能自己监控自己。为了高可用。那么sentinel也要做集群，万一单个sentinel挂掉了，那岂不是相当于没有？！

我们不需要配置哨兵之间的关系，他们通过共同监控的master而互相感知。就是类似于QQ好友，欧阳斧子 和 诸葛铁锤 通过他们的共同好友 尉迟榔头 而成为铁哥们儿。 sentinel之间通过与master节点的pub/sub 而互相感知，
那么sentinel是怎么知道slave的呢？
当然也是通过订阅master而知道的，其过程我不明白我只知道是这样一个过程，事实上我也没必要去研究这个东西。
那么sentinel是怎么选举他们的队长的呢？
原理我略懂一下，其内部经过一个复杂的算法进行选举，这个算法叫raft算法。给一个连接吧更有利于理解raft算法-----thesecretlivesofdata.com/raft
那么sentinel是怎么选出redis集群的master的呢？
sentinel通过raft算法在内部选举出队长，再由这个队长直接进行主节点的任命
接下来我来说怎么使用？
soooooooo easy!!!
通过配置的方式进行启动。
就是加压目录里有一个sentinel.conf ，这是一个示例文件，里面是对使用sentinel的配置的样板。我们可以直接用这个文件来启动，也可以使用它的复制品来启动。无所谓都一样。
在这个文件里会找到这样一段串串：
sentinel monitor mymaster 127.0.0.1 6379 2
这就是sentinel的配置，它的意思就是监控 127.0.0.1 机器上 运行在6379端口的程序；这个2的意思是：如果当前master挂掉了需要多少个sentinel判定master挂了才断定他真的挂了 -----这是一个相当民主的过程 还是做个比喻吧：
说尉迟榔头躺在病床上呼出了榔生的最后一口气。这个细节被欧阳斧子看到了，但是它不敢确定，就问诸葛铁锤：老兄，你觉得榔头是真的凉了吗？如果诸葛铁锤说：是，我也觉得凉了。那么他们两个才认为榔头是真的凉了。 -----------这是保证主观和客观的公正性
在bin目录下 输入 ./redis-sentinel sentinel.conf 回车
这样就启动了

那么这里还有一个细节，
如果一个master挂了，队长会等他一段时间（事实上是几秒钟，可以自己配置）----呃。。。类似于 欧阳斧子 和 诸葛铁锤 会给 尉迟榔头 摆灵三天，三天内他活过来了就皆大欢喜，如果没有那就埋了。
当master在指定的时间内没有和队长回复通讯，这个队长就会触发failover机制从salve中间挑选一个作为新的master。
以下是我们常用的两个配置：
sentinel dwon-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 15000
第一行就是摆灵的那三天（5000） 时间是毫秒
第二行就是 ，当选举过程开始以后，如果队长不作为（可能是偷懒，也可能是其他原因总之他没有做任何事情），那么当前节点就认为这次的failover是失败的，则重新推举一个队长。事实上，队长是受队员监督的。

那么如果master经过修复重新回到集群当中呢？
这时master就相当于尉迟榔头重新投胎做人了，他以slave的角色加入到集群当中，进行数据的全量复制，增量复制等等等等。从而进入下一个朝代（redis中的epoch概念）。
结束了--------------------------------------------------------------------