redis集群三种方式_<redis>学完redis的三种集群部署后，工资又涨了1000！！<1.主从复制>...

​1：前言

说起redis应该没有人会陌生了吧，作为开发中最最最最最最最常用的nosql之一，它的重要性已经体现在上文中了，自从我工作开始，就没有逃离过redis的魔爪，接下来的内容可以说的redis 的核心内容了，这“1000”块赚起来可没有那么轻松，gogogo，搞起搞起～～～～～

(本文其实是我写在微信公众号的，所以排版有点不堪，大家可以搜索 哪儿来的moon 关注我的公众号)

2：正文

主从复制

通过持久化的功能，redis可以保证就算是服务宕机重启了，也只有少量的数据会丢失。但是在真实的使用场景当中，如果真的只有一台服务器，并且恰好宕机了，那么就会导致整个服务都不可用，因此redis提供了集群的方式来部署，可以避免这种问题，今天我们就来讲讲其中之一，主从复制，当其中一台服务器更新之后，服务器会自动的将这台更新的数据同步到另外一台服务器上。

在主从复制这种集群部署模式中，我们会将数据库分为两类，第一种称为主数据库(master)，另一种称为从数据库(slave)。主数据库会负责我们整个系统中的读写操作，从数据库会负责我们整个数据库中的读操作。其中在职场开发中的真实情况是，我们会让主数据库只负责写操作，让从数据库只负责读操作，就是为了读写分离，减轻服务器的压力。但是我在实际开发中会遇到一种情况，该数据是个热点数据，我们知道，数据同步一定是会耗时的，那么当一个热点数据进入master中，而slave没有来得及更新，再去读这个数据就会造成数据不一致现象，所以当时我的方案就是直接去读master节点，这个逻辑同样适用于mysql主从中出现的问题。

上图就是一个主从复制的模型，master节点只能有一个，但是可以拥有多个slave节点。

主从同步原理

这里我给大家讲一下大致的流程，具体的可以通过传送门了解详细内容(redis持久化传送门-----现在居然还有不知道持久化的......出门右拐不送！！！)

当一个从数据库启动时，它会向主数据库发送一个SYNC命令，master收到后，在后台保存快照，也就是我们说的RDB持久化，当然保存快照是需要消耗时间的，并且redis是单线程的(redis后面也支持了多线程，这里我们先不讲)，在保存快照期间redis受到的命令会缓存起来，快照完成后会将缓存的命令以及快照一起打包发给slave节点，从而保证主从数据库的一致性。从数据库接受到快照以及缓存的命令后会将这部分数据写入到硬盘上的临时文件当中，写入完成后会用这份文件去替换掉RDB快照文件，当然，这个操作是不会阻塞的，可以继续接收命令执行，具体原因其实就是fork了一个子进程，用子进程去完成了这些功能。

因为不会阻塞，所以，这部分初始化完成后，当主数据库执行了改变数据的命令后，会异步的给slave，这也就是我们说的复制同步阶段，这个阶段会贯穿在整个中从同步的过程中，知道主从同步结束后，复制同步才会终止。

那么我上文提到的数据不一致的现象又是怎么回事呢？

是因为redis采用了乐观复制的策略，容忍一定时间内主从数据库的数据是不一致的，但是会保证最终的结果一致，所以当主从复制发生时，正常情况下的命令都会在主数据库完成，然后直接反回给客户端，这样我们的性能就不会受到影响了，因为这里是主数据库先完成命令，那么就会产生其他问题。

我们再来说个极端情况，假如现在有1个master，6个slave，现在只有两个slave完成了同步，master写了新命令，在master准备将此命令传输给其他slave时，此刻其他的slave断电了，那么就会造成数据不一致的现象发生。所以redis针对这种情况作了两个配置

min-slaves-to-write 2 (只有2个及以上的从数据库连接到了主数据库时，master库才是可写的)
min-slaves-max-lag 10 (10秒slave没有和master进行交互就认为丢失链接)

无硬盘复制

我们刚刚说了主从之间是通过RDB快照来交互的，虽然看来逻辑很简单，但是还是会存在一些问题，但是会存在着一些问题。

1).master禁用了RDB快照时，发生了主从同步(复制初始化)操作，也会生成RDB快照，但是之后如果master发成了重启，就会用RDB快照去恢复数据，这份数据可能已经很久了，中间就会丢失数据

2).在这种一主多从的结构中，master每次和slave同步数据都要进行一次快照，从而在硬盘中生成RDB文件，会影响性能

为了解决这种问题，redis在后续的更新中也加入了无硬盘复制功能，也就是说直接通过网络发送给slave，避免了和硬盘交互，但是也是有io消耗的

增量复制

刚刚我们说了复制的原理，但是他的缺点是很明显的，就是在断开主从链接后，及时你只发生了一条数据变化，也需要将所有的数据通过SYNC命令用RDB将所有的数据同步给slave，但是其实并不需要同步所有的数据，只需要将改变的这小部分数据同步给slave就好了

所以为了解决这个问题，redis就有了增量复制

这个原理其实是很简单的，学过kafka 的小伙伴应该知道，kafka消费是通过偏移量来计算的，redis的增量复制也是如此。

master会记下每个slave的id，在复制期间，如果有新消息，会将新消息(其实是新的命令，当然只包括让数据放生变动的命令，如 set 这种 )存放在一个固定大小的循环队列中(这个让我想起了mysql中的redolog，后期mysql的文章我再写出来吧)，这个大小是可以配置的，当然这时候发送的就是PSYNC命令了，然后master会在复制完成后将这部分数据发送给slave，这样就在很大程度上保证了数据一致性

3：结语

这次我跟大家聊了一下redis的主从原理，当然这只是mysql部署方式其中之一，它的缺点也是很明显的，一主多从的情况下，master负责写，slave负责读，所以写的数据上线全都被master限制死了，我们没有办法去在这种结构上扩容它的写上线，并且，如果master挂了，那么我们的整个redis服务都没有办法再写入新的数据了，只能等待master活过来

当然了，也有解决这些问题的方法，那就请大家期待moon后续的文章吧，下次见~~

最后祝大家

国庆节快乐