Redis简介二（一篇读懂主从复制）
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了Redis简介二（一篇读懂主从复制），小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含8733字，纯文字阅读大概需要13分钟。
内容图文
集群版一
在上一篇我们简单介绍了下Redis的使用，下面介绍集群环境下的Redis。
集群的意义
Redis集群的出现势必是为了解决单机不可解决的问题，有哪些问题呢，简单总结如下：
- 在单机环境下，如果某一个Redis实例不可用，或者所有实例不可用，Redis无论是作为缓存还是作为数据库使用，都必然对业务造成很大影响，单点机器出现故障的概率还是很高的。
- Redis作为一个纯内存操作的应用，受OS限制，内存不可能无限扩大，如果我们需要同时缓存几十上百G的数据，单机环境无法提供支持
- 单机在机器性能非常好的情况下，QPS官方是在10-15w，但是考虑到有很多子线程任务，一般应该会低于10w，单机无法支持高并发环境。
CAP原则
也称CAP定理，即在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。举个例子，强一致性与可用性是一对冤家，无法共存，下面会有介绍。Redis集群实现的是AP。
集群实现方案
1.解决单点故障问题
既然一台机器不可靠，那就多搞几台嘛。水平扩展Redis服务器不是就解决了问题嘛，同时还能顺带着解决下性能问题：
一台Master外挂n台salve，每个salve理论上持有Master的全量数据，相当于Master有n个镜像，当Master down了之后，slave仍旧可以持有完整数据对外提供服务，还能支持读写分离，想想还有点小激动呢。
首先解释两个名词：
- 主从
简单理解就是，client即可以与主机连接，还可以和从机连接 - 主备
备，即备份机，client是无法与备机进行连接，只有主机down了之后，备机替代主机功能才可以连接
一般主机可以读写，从机只能读。
附带出现的新问题
一致性问题
先冷静一下，该如何让每个slave持有完整的数据呢？数据一致性的问题就这么出现了，下面换个简化图示例：
client向Matser写入一条数据，然后Master向两台slave同步数据。假设现在slave1接收到同步请求，并完成数据同步，slave2因网络波动，根本就美欧收到请求，或者接收到轻轻，但是数据同步期间发生错误，实际没有完成同步操作，那么现在就出现了这么一种情况，Master和slave1数据时最新的，但是slave2压根儿就没有这条数据。假设当前突发状况，Master和slave1都down了，只剩下了slave2可以对外提供服务，此时，这笔新插入的数据就这么丢失了。
既然水平扩展出现了一些问题，那就撸起袖子往下干吧。大致有这么几种方案（下面内容属于延伸扩展）：
强一致性
很好理解，要么三台机器全部成功，要么全部失败。现在client给Master发送一条写指令，Master写入成功了，下面给两台slave同步数据，因为Redis是单进程的，为了实现强一致性，Master只能是阻塞等待两台slave同步的结果，如果两台都回复Master成功，ok，一次写入完成。如果slave1通知同步完成，slave2通知失败，或者半天过去了，都没给出同步结果，那Master只能认为此次同步失败了，为了强一致性，要么重试，要么将已经成功的数据撤销。但是不论是撤销数据，还是重试（此时线程还阻塞着呢），对于client来讲相当于是服务不可用。由此可见，愿景很美好，但是代价实在是太大了，严重破坏可用性。
弱一致性
既然可用性怎么娇气，那肯定不能使用同步阻塞了，哎，那就换成异步通知呗。当client数据到达Master之后，Master成功就行，然后Master异步通知两个slave进行数据同步，但是无法保证两个slave的数据能完全和Master一致。
最终一致性
假若有一个可靠的第三方，Master将数据同步提交（响应必须足够快），获得第三方回执后即可认为数据同步成功，slave1，slave2的具体同步操作，由第三方异步的去更新，保证最终两台从机都能update。
数据读取问题
Redis读写分离后，假设Master已经更新数据，但是slave还没有来得及完成更新。现有两个client，一个从Master读取数据，一个从slave读取数据，一个读出了新数据，另一个读的是老数据。
Master单点问题
无论是主从还是主备，都离不开一个主机Master，问题来了，这个Master本身，还是一台单点机器，问题又回到原点了…
Redis是如何实现的呢？
解决Master单点问题
想象一下如果是一个人，如何判断一台Master是否可用呢？很简单，与Master建立通信，判断Master是否可以提供服务。下面，可以给大家介绍下哨兵（Sentinel）了：
相信聪明的你一定注意到了上面哨兵我画了3个，为什么不是1个，也不是两个呢？
首先我们要明确哨兵存在的意义，是为了解决Master的单点问题，说直白一点，就是监控当前的Master是否存活，是否可以提供服务。
假设现在一个Master只有一个哨兵监控，如果某一个时间点哨兵与Master之间出现网络波动，哨兵认为Master down了，启动灾备，将一台slave切换成了新Master，其实老Master好好的，这便出现了典型的网络分区问题，一部分连接仍旧和老Master保持联系，一部分新连接则和新Master进行交互，产生不一致。
既然只有一个哨兵不可行，再加一个哨兵会怎么样呢？假使在某一时刻一个哨兵连接出现问题，判定Master出现问题，而另外一个哨兵与Master保持着正常连接，判断Master好好的，一个认为down了，一个认为没问题，到底该听谁的呢？很明显，仅仅两个哨兵也不可行。
至少需要三个哨兵去监控一个Master，当超过其中一半数+1的哨兵认为Master down了，即投票数大于当前哨兵的一半，才可以认为Master是真的down了，应该启动灾备了。
关于哨兵这块，本章节不扩展开来讲了，后续有专门章节详解哨兵是如果工作，如何发起救援的。
Redis的实现
下面我们以一个简单的小demo来看下Redis是如何实现数据同步的：
环境：mac os
工具：shell，docker(本人比较懒，不想配置一大堆东西，使用docker容器的默认配置)
说明：本demo使用Redis使用默认配置，修改配置后的结果，与本demo会有些许不一样。
1.首先，我们在本机模拟建立一个Redis集群环境。首先启动4个空白shell：
2.从左到右的4个shell中，分别输入如下命令(为了演示效果，我们让Redis实例进行前端阻塞运行)：
左上：
docker run --name master -p 6379:6379 redis
右上：
docker run --name slave1 -p 6380:6380 redis
左下：
docker exec -ti master redis-cli
右下：
docker exec -ti slave1 redis-cli
效果如图：
我们顺利的启动了两台Redis实例，一个是6379，一个是6380，
同时启动了两个客户端，一个连接实例6379，一个连接实例6380
同时，由于docker的沙箱机制，两个容器之间是不能通信的，我们下面建立一个网桥用于实例之间的双向通信：
docker network create -d bridge myBridge
docker network connect myBridge master
docker network connect myBridge slave1
ok，至此，我们的准备工作都已经全部完成。
3.为了演示，我们现在6379中添加部分key：
4.将6380设置为6379的slave
在连接6380的客户端中使用跟随命令：
replicaof 172.17.0.2 6379
ok，执行完毕，我们现在来看下4个shell的显示界面
在Master的shell中，我们可以看到Master在slave成功连接之后，进行了这么几件事情：使用copy-on-write方式，新起了一个后台线程23执行bgsave（即生成当前Master中全量RDB文件），完成之后，将RDB文件用SYNC命令发送给了slave。
在slave的shell中，我们可以看到，与Master建立连接之后，开始建立SYNC通道，发送ping到Master验证连接是否通畅，在接收到Master发送过来的RDB数据之后，首先清空了自己的老数据，然后加载RDB数据进入内存。
我们来看下效果：
至此，Master与slave之间，完成了一次全量数据的同步。
5.增量数据同步：
我们在Master中再新增一个key11，然后去slave中查看，可以看到key11已经同步到了slave中
下面我们总结下Redis的主从复制逻辑：
- 全量数据同步：
一般使用场景为slave新连接进Master，或者slave down很长时间，恢复之后重新与Master建立连接。
全量同步，是需要使用RDB文件的，默认是先将生成的RDB文件保存在磁盘上，等RDB文件全部生成完毕之后，再发送给slave。所以性能会受到磁盘速度的限制，可以在conf中添加配置：repl-diskless-sync no，将生成的RDB文件不落磁盘，直接通过网络形式发送给slave。
至于数据同步过程，上面的demo中已经有了详细过程，这里就不做过多说明了。
另外，说明一点，在slave删除自身旧数据，加载新数据的过程中，默认是阻塞进行的，可以在conf中配置异步进行，在这段时间内，slave仍响应请求，同时以旧数据返回，但是加载新数据集的操作只能是在主线程中，会阻塞salve。 - 增量同步：
增量同步相较于全量同步，会稍微复杂一些。
我们先看下Master和slave下都有哪些信息：
输入"info replication"
我们可以看到，在Master中，有当前自己的replication ID，以及自己的数据偏移量offset，而在slave中，不仅有自己的replication ID，还有Master的replid以及Master的offset，这些便是最近一次Master同步数据的信息。
Master将自身的复制流传给slave时，发送多少字节的数据，自身的偏移量offset就会增加多少，目的是当有新的操作修改自己的数据集时，它可以用offset去更新slave的状态。基本上每一对replication ID和offset，可以确定一个确切的数据版本。
当salve连接到Master之后，使用PSYNC命令发送他们记录的旧的master replicationID和它们至今为止处理的offset，这样Masetr便可以知道，应该从哪个数据开始，将其后续的数据同步给slave
假设这样一个问题，如果slave最近的同步时间是一小时前，在这1小时内，Master已经更新4G的数据，当slave再次进行同步的时候，是否还是这样同步呢？答案不是。
从上面的图中，我们可以看到一个叫"repl_backlog_size"的信息，这个便是Master的操作命令缓冲区，大小时可以配置的，为了便于理解，可以将它想象成一个环状的内存空间：
从index=0开始，来一条指令，往环内填入数据，直到填满整个环状内存，后续再来一条命令，将之前index=0的地方开始，将老的指令替换为新的指令。
当slave携带offset信息过来之后，Master会根据这个offset，去指令缓冲区内寻找相应的偏移量，如果在缓冲区内找到了，则将其后续指令同步给slave，如果在缓冲区内没有找到相应的偏移量，则进行RDB全量数据同步。
slave默认是只读模式，可以通过conf调整为读写模式。
主从模式下，Redis由于是异步复制，所以无法确保每个slave都收到了数据，总会有数据丢失的可能，这需要看具体的使用场景是否能够容忍，考研网络分区的容忍度。
另外，Redis支持部分一致性，通过配置：
min-replicas-to-write xxx
min-replicas-max-lag xxx
设置最小的slave写入成功的数据，以及相互之间通信的最大超时时间。比如xxx配置为3，只有当最少3台salve都写入成功了，这条数据才会认为写入成功，最终进入Redis数据集。
2.解决Redis容量问题
篇幅有限，在后续的Redis分区章节进行讲解，敬请期待。
内容总结
以上是互联网集市为您收集整理的Redis简介二（一篇读懂主从复制）全部内容，希望文章能够帮你解决Redis简介二（一篇读懂主从复制）所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。