Ⅰ mysql读写分离和用Redis做缓存，这两种方案有什么异同
1.mysql读写分离 是指mysql的数据读取操作和数据更新操作分开 这样在大并发的情况下 数据库不会出现长时间锁边的情况
2.redis做缓存是把数据库数据缓存在内存中 当同一个数据请求过来，会直接读取内存中的缓存数据而不会再向数据库请求数据 降低数据库的压力
Ⅱ redis缓存原理
redis缓存原理是sql语句时key值，查询结果resultSet是value，当同一个查询语句访问时（select * from t_proct），只要曾经查询过，调用缓存直接返回resultSet，节省了数据库读取磁盘数据的时间。
redis的存储分为内存存储、磁盘存储和log文件三部分，配置文件中有三个参数对其进行配置。
save seconds updates，save配置，指出在多长时间内，有多少次更新操作，就将数据同步到数据文件。这个可以多个条件配合，比如默认配置文件中的设置，就设置了三个条件。
appendonly yes/no ，appendonly配置，指出是否在每次更新操作后进行日志记录，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为redis本身同步数据文件是按上面的save条件来同步的，所以有的数据会在一段时间内只存在于内存中。
(2)主从分离跟redis缓存区别扩展阅读
redis的出现，很大程度补偿了memcached这类key/value存储的不足，在部 分场合可以对关系数据库起到很好的补充作用。它提供了Java，C/C++，C#，PHP，JavaScript，Perl，Object-C，Python，Ruby，Erlang等客户端，使用很方便。
Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。
存盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。
redis的官网地址，redis.io。（域名后缀io属于国家域名，是british Indian Ocean territory，即英属印度洋领地）
Ⅲ Redis早期的主从架构原理分析，早期如何实现读写分离的
基于主从复制架构，实现读写分离，redis slave node节点只读，默认开启配置：slave-read-only yes。开启了只读的节点redis slave node，会拒绝所有写操作，这样可以强制搭建成读写分离的架构。
（1）redis采用异步方式复制数据到slave节点。
（2）一个master node是可以配置多个slave node的。
（3）slave node也可以连接其他的slave node。
（4）slave node做复制的时候，是不会block master node的正常工作的。
（5）slave node在做复制的时候，也不会block对自己的查询操作，它会用旧的数据集来提供服务; 但是复制完成的时候，需要删除旧数据集，加载新数据集，这个时候就会暂停对外服务了。
（6）slave node主要用来进行横向扩容，做读写分离，扩容的slave node可以提高读的吞吐量。
如果采用了主从架构，那么建议必须开启master node的持久化！不建议用slave node作为master node的数据热备，因为那样的话，如果你关掉master的持久化，可能在master宕机重启的时候数据是空的，然后可能一经过复制，salve node数据也丢了。
（1）当启动一个slave node的时候，它会发送一个 PSYNC 命令给master node。
（2）如果这是slave node 重新连接 master node，那么master node仅仅会 复制给slave部分缺少的数据 ，否则如果是slave node 第一次连接 master node，那么会触发一次 full resynchronization ，master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端收到的所有写命令 缓存在内存中 。RDB文件生成完毕之后，master会先将这个RDB发送给slave，slave会先写入本地磁盘，然后再从本地磁盘加载到内存中。然后master会将内存中 缓存的写命令 发送给slave，slave也会同步这些数据。
（3）slave node如果跟master node有网络故障，断开了连接，会自动重连。master如果发现有多个slave node都来重新连接，仅仅会启动一个rdb save操作，用一份数据服务所有slave node。
从redis 2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的地方，继续复制下去，而不是从头开始复制。master node会在内存中建一个 backlog ，master和slave都会保存一个 replica offset 还有一个 master id（run id） ，offset就是保存在backlog中的。如果master和slave网络连接断掉了，slave会让master从上次的replica offset开始继续复制，但是如果没有找到对应的offset，那么就会执行一次full resynchronization全量同步。
master在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了。
repl-diskless-sync no 改为开启就可以了
repl-diskless-sync-delay，等待一定时长再开始复制，因为要等更多slave重新连接过来，用一分数据提供服务。
slave node不会过期key，只会等待master过期key。如果master过期了一个key，或者通过LRU淘汰了一个key，那么会模拟一条del命令发送给slave。
（1）slave node启动，仅仅保存master node的信息，包括master node的host和ip，但是复制流程没开始。master host和ip是从哪儿来的？redis.conf里面的slaveof配置的。
（2）slave node内部有个定时任务，每秒检查是否有新的master node要连接和复制，如果发现，就跟master node建立socket网络连接。
（3）slave node发送ping命令给master node。
（4）口令认证，如果master设置了requirepass（master上启用安全认证配置，requirepass 自己取名 ），那么salve node必须发送masterauth的口令过去进行认证（masterauth 自己取名 ）
（5）master node第一次执行全量复制，将所有数据发给slave node。
（6）master node后续持续将写命令，增量异步复制给slave node。
指的就是第一次slave连接msater的时候，执行的全量复制，这个过程里面的一些细节的机制
（1）master和slave都会维护一个offset
master会在自身不断累加offset，slave也会在自身不断累加offset。slave每秒都会上报自己的offset给master，同时master也会保存每个slave的offset。这个倒不是说特定就用在全量复制的，主要是master和slave都要知道各自的数据的offset，才能知道互相之间的数据不一致的情况。
（2）backlog
master node有一个backlog，默认是1MB大小，master node给slave node复制数据时，也会将数据在backlog中同步写一份。backlog主要是用来做全量复制中断后的增量复制的。
（3）master run id
info server命令，可以看到master run id。如果根据host+ip定位master node，是不靠谱的，如果master node重启或者数据出现了变化，那么slave node应该根据不同的run id区分，run id不同就做全量复制。如果需要不更改run id重启redis，可以使用redis-cli debug reload命令。
（4）psync
从节点使用psync从master node进行复制psync runid offset。master node会根据自身的情况返回响应信息，可能是FULLRESYNC runid offset触发全量复制，可能是继续触发增量复制。
（1）master执行bgsave，在本地生成一份rdb快照文件。
（2）master node将rdb快照文件发送给salve node，如果rdb复制时间超过60秒（repl-timeout），那么slave node就会认为复制失败，可以适当调节大这个参数。
（3）对于千兆网卡的机器，一般每秒传输100MB，6G文件，很可能超过60s。
（4）master node在生成rdb时，会将所有新的写命令缓存在内存中，在salve node保存了rdb之后，再将新的写命令复制给salve node。
（5）client-output-buffer-limit slave 256MB 64MB 60，如果在复制期间，内存缓冲区持续消耗超过64MB，或者一次性超过256MB，或复制时间超过60秒，那么停止复制，复制失败。
（6）slave node接收到rdb之后，然后重新加载rdb到自己的内存中，同时基于旧的数据版本对外提供服务，写入后，清空自己的旧数据，用新的对外提供读服务。
（7）如果slave node开启了AOF，那么会立即执行BGREWRITEAOF，重写AOF。在这个过程中，rdb生成、rdb通过网络拷贝、slave旧数据的清理、slave node aof rewrite，很耗费时间的。
（1）如果全量复制过程中，master-slave网络连接断掉，那么salve重新连接master时，会触发增量复制。
（2）master直接从自己的backlog中获取部分丢失的数据，发送给slave node，默认backlog就是1MB。
（3）master就是根据slave发送的psync中的offset来从backlog中获取数据的。
下节讲解哨兵架构，在讲之前，你能否处理下面两个问题呢？
1、异步复制导致的数据丢失
哨兵可以解决主从架构下，因master宕机后不能接收写请求而进行选举salve为新的master，达到高可用的效果。
因为master -> slave的复制是异步的，所以可能有部分数据还没复制到slave，master就宕机了，此时这些部分数据就丢失了，此时应该怎么处理？
2、脑裂导致的数据丢失
脑裂，也就是说，某个master所在机器突然脱离了正常的网络，跟其他slave机器不能连接，但是实际上master还运行着。
此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master这个时候，集群里就会有两个master，也就是所谓的脑裂。
此时虽然某个slave被切换成了master，但是可能client还没来得及切换到新的master，还继续写向旧master的数据可能也丢失了，因此旧master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会清空，重新从新的master复制数据，导致数据丢失，怎么处理脑裂导致的数据丢失呢？
先考虑一下，我们下节进行讲解。
Ⅳ redis缓存原理
1、Redis是一种内存高速cache，如果使用redis缓存，那经常被访问的内容会被缓存在内存中，需要使用的时候直接从内存调取，不知道比硬盘调取快了多少倍，并且支持复杂的数据结构，应用于许多高并发的场景中。
2、Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。存盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。zset是set的一个升级版本，他在set的基础上增加了一个顺序属性，这一属性在添加修改元素的时候可以指定，每次指定后，zset会自动重新按新的值调整顺序。可以理解了有两列的mysql表，一列存value，一列存顺序。操作中key理解为zset的名字。
更多关于redis缓存原理，进入：https://www.abcgonglue.com/ask/66eab61616100681.html?zd查看更多内容
Ⅳ redis主从配置与分片是一回事吗
分片(partitioning)就是将你的数据拆分到多个 Redis 实例的过程，这样每个实例将只包含所有键的子集。
主从复制则是一个master可以拥有多个slave，而一个slave又可以拥有多个slave，如此下去，形成了强大的多级服务器集群架构
所以不一样
Ⅵ redis和memcached的区别
如果简单地比较Redis与Memcached的区别，大多数都会得到以下观点：
1 Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，hash等数据结构的存储。
2 Redis支持数据的备份，即master-slave模式的数据备份。
3 Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。
在Redis中，并不是所有的数据都一直存储在内存中的。这是和Memcached相比一个最大的区别（我个人是这么认为的）。
Redis只会缓存所有的key的信息，如果Redis发现内存的使用量超过了某一个阀值，将触发swap的操作，Redis根据“swappability = age*log(size_in_memory)”计算出哪些key对应的value需要swap到磁盘。然后再将这些key对应的value持久化到磁盘中，同时在内存中清除。这种特性使得Redis可以保持超过其机器本身内存大小的数据。当然，机器本身的内存必须要能够保持所有的key，毕竟这些数据是不会进行swap操作的。
同时由于Redis将内存中的数据swap到磁盘中的时候，提供服务的主线程和进行swap操作的子线程会共享这部分内存，所以如果更新需要swap的数据，Redis将阻塞这个操作，直到子线程完成swap操作后才可以进行修改。
可以参考使用Redis特有内存模型前后的情况对比：
VM off: 300k keys, 4096 bytes values: 1.3G used
VM on: 300k keys, 4096 bytes values: 73M used
VM off: 1 million keys, 256 bytes values: 430.12M used
VM on: 1 million keys, 256 bytes values: 160.09M used
VM on: 1 million keys, values as large as you want, still: 160.09M used
当从Redis中读取数据的时候，如果读取的key对应的value不在内存中，那么Redis就需要从swap文件中加载相应数据，然后再返回给请求方。这里就存在一个I/O线程池的问题。在默认的情况下，Redis会出现阻塞，即完成所有的swap文件加载后才会相应。这种策略在客户端的数量较小，进行批量操作的时候比较合适。但是如果将Redis应用在一个大型的网站应用程序中，这显然是无法满足大并发的情况的。所以Redis运行我们设置I/O线程池的大小，对需要从swap文件中加载相应数据的读取请求进行并发操作，减少阻塞的时间。
redis、memcache、mongoDB 对比
从以下几个维度，对redis、memcache、mongoDB 做了对比，欢迎拍砖
1、性能
都比较高，性能对我们来说应该都不是瓶颈
总体来讲，TPS方面redis和memcache差不多，要大于mongodb
2、操作的便利性
memcache数据结构单一
redis丰富一些，数据操作方面，redis更好一些，较少的网络IO次数
mongodb支持丰富的数据表达，索引，最类似关系型数据库，支持的查询语言非常丰富
3、内存空间的大小和数据量的大小
redis在2.0版本后增加了自己的VM特性，突破物理内存的限制；可以对key value设置过期时间（类似memcache）
memcache可以修改最大可用内存,采用LRU算法
mongoDB适合大数据量的存储，依赖操作系统VM做内存管理，吃内存也比较厉害，服务不要和别的服务在一起
4、可用性（单点问题）
对于单点问题，
redis，依赖客户端来实现分布式读写；主从复制时，每次从节点重新连接主节点都要依赖整个快照,无增量复制，因性能和效率问题，
所以单点问题比较复杂；不支持自动sharding,需要依赖程序设定一致hash 机制。
一种替代方案是，不用redis本身的复制机制，采用自己做主动复制（多份存储），或者改成增量复制的方式（需要自己实现），一致性问题和性能的权衡
Memcache本身没有数据冗余机制，也没必要；对于故障预防，采用依赖成熟的hash或者环状的算法，解决单点故障引起的抖动问题。
mongoDB支持master-slave,replicaset（内部采用paxos选举算法，自动故障恢复）,auto sharding机制，对客户端屏蔽了故障转移和切分机制。
5、可靠性（持久化）
对于数据持久化和数据恢复，
redis支持（快照、AOF）：依赖快照进行持久化，aof增强了可靠性的同时，对性能有所影响
memcache不支持，通常用在做缓存,提升性能；
MongoDB从1.8版本开始采用binlog方式支持持久化的可靠性
6、数据一致性（事务支持）
Memcache 在并发场景下，用cas保证一致性
redis事务支持比较弱，只能保证事务中的每个操作连续执行
mongoDB不支持事务
7、数据分析
mongoDB内置了数据分析的功能(maprece),其他不支持
8、应用场景
redis：数据量较小的更性能操作和运算上
memcache：用于在动态系统中减少数据库负载，提升性能;做缓存，提高性能（适合读多写少，对于数据量比较大，可以采用sharding）
MongoDB:主要解决海量数据的访问效率问题
Ⅶ Redis和Memcache的区别总结
区别：
1、存储方式不同
memecache 把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小；redis有部份存在硬盘上，这样能保证数据的持久性，支持数据的持久化（笔者注：有快照和AOF日志两种持久化方式，在实际应用的时候，要特别注意配置文件快照参数，要不就很有可能服务器频繁满载做mp）。
2、数据支持类型不同
redis在数据支持上要比memecache多的多。
3、使用底层模型不同
新版本的redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。
4、运行环境不同
redis目前官方只支持LINUX 上去行，从而省去了对于其它系统的支持，这样的话可以更好的把精力用于本系统 环境上的优化，虽然后来微软有一个小组为其写了补丁。但是没有放到主干上。
(7)主从分离跟redis缓存区别扩展阅读
注意事项
1、 Redis和Memcache都是将数据存放在内存中，都是内存数据库。不过memcache还可用于缓存其他东西，例如图片、视频等等。
2、Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，hash等数据结构的存储。
3、虚拟内存–Redis当物理内存用完时，可以将一些很久没用到的value 交换到磁盘 。
4、过期策略–memcache在set时就指定，例如set key1 0 0 8,即永不过期。Redis可以通过例如expire 设定，例如expire name 10 。
5、分布式–设定memcache集群，利用magent做一主多从;redis可以做一主多从。都可以一主一，存储数据安全–memcache挂掉后，数据没了；redis可以定期保存到磁盘（持久化） 。
Ⅷ 详解Redis 主从复制及主从复制原理
Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。从2010年3月15日起，Redis的开发工作由VMware主持。从2013年5月开始，Redis的开发由Pivotal赞助。
概述
在现有企业中80%公司大部分使用的是redis单机服务，在实际的场景当中单一节点的redis容易面临风险。
2、容量瓶颈。 当我们有需求需要扩容 Redis 内存时，从 16G 的内存升到 64G，单机肯定是满足不了。当然，你可以重新买个 128G 的新机器。
解决办法
要实现分布式数据库的更大的存储容量和承受高并发访问量，我们会将原来集中式数据库的数据分别存储到其他多个网络节点上。
Redis 为了解决这个单一节点的问题，也会把数据复制多个副本部署到其他节点上进行复制，实现 Redis的高可用，实现对数据的冗余备份，从而保证数据和服务的高可用。
主从复制
什么是主从复制
主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)，数据的复制是单向的，只能由主节点到从节点。
默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。
主从复制的作用
1、数据冗余： 主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
2、故障恢复： 当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
3、负载均衡： 在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
4、读写分离： 可以用于实现读写分离，主库写、从库读，读写分离不仅可以提高服务器的负载能力，同时可根据需求的变化，改变从库的数量。
5、高可用基石： 除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。
主从复制启用
从节点开启主从复制，有3种方式：
1、配置文件： 在从服务器的配置文件中加入 slaveof<masterip><masterport>。
2、启动命令： redis-server启动命令后加入 --slaveof<masterip><masterport>。
3、客户端命令： Redis服务器启动后，直接通过客户端执行命令 slaveof<masterip><masterport>，则该Redis实例成为从节点。
通过 info replication 命令可以看到复制的一些信息。
主从复制原理
主从复制过程大体可以分为3个阶段：连接建立阶段（即准备阶段）、数据同步阶段、命令传播阶段。
在从节点执行 slaveof 命令后，复制过程便开始运作，下面图示可以看出复制过程大致分为6个过程。
主从配置之后的日志记录也可以看出这个流程。
1、保存主节点（master）信息
执行 slaveof 后 Redis 会打印如下日志：
2、从节点与主节点建立网络连接
从节点（slave）内部通过每秒运行的定时任务维护复制相关逻辑，当定时任务发现存在新的主节点后，会尝试与该节点建立网络连接。
从节点与主节点建立网络连接。
从节点会建立一个 socket 套接字，从节点建立了一个端口为51234的套接字，专门用于接受主节点发送的复制命令。从节点连接成功后打印如下日志：
如果从节点无法建立连接，定时任务会无限重试直到连接成功或者执行 slaveofnoone 取消复制。
关于连接失败，可以在从节点执行 info replication 查看 master_link_down_since_seconds 指标，它会记录与主节点连接失败的系统时间。从节点连接主节点失败时也会每秒打印如下日志，方便发现问题：
3、发送 ping 命令
连接建立成功后从节点发送 ping 请求进行首次通信， ping 请求主要目的如下：
如果发送 ping 命令后，从节点没有收到主节点的 pong 回复或者超时，比如网络超时或者主节点正在阻塞无法响应命令，从节点会断开复制连接，下次定时任务会发起重连。
从节点发送的 ping 命令成功返回，Redis 打印如下日志，并继续后续复制流程：
4、权限验证
如果主节点设置了 requirepass 参数，则需要密码验证，从节点必须配置 masterauth 参数保证与主节点相同的密码才能通过验证。如果验证失败复制将终止，从节点重新发起复制流程。
5、同步数据集
主从复制连接正常通信后，对于首次建立复制的场景，主节点会把持有的数据全部发送给从节点，这部分操作是耗时最长的步骤。
6、命令持续复制
当主节点把当前的数据同步给从节点后，便完成了复制的建立流程。接下来主节点会持续地把写命令发送给从节点，保证主从数据一致性。
作者：LoyaltyLu
链接：https://segmentfault.com/a/1190000018268350
Ⅸ 浅谈Redis主从复制[转载]
浅谈Redis主从复制
2013.09.27 11:27:00 来源: 京东 作者:张成远 ( 0 条评论 )
Redis是一个开源的，遵守BSD许可协议的key/value缓存系统，并由其高效的响应速度以及丰富的数据结构而闻名。Redis在京东的使用也是非常普遍的，包括很多关键业务上的使用，由于Redis官方集群还未发布，在使用Redis的过程中需要面对Redis的单点问题，京东采用的是一种比较通用的解决方案即由主从备份再加相应的主从切换（在一些场景下可能进行读写分离），使主Redis出现失效的时候可以快速的切换到从Redis上。但Redis目前存在的一个问题是主从复制在遇到网络不稳定的情况下，Slave和Master断开（包括闪断）会导致Master需要将内存中的数据全部重新生成rdb文件（快照文件），然后传输给Slave。Slave接收完Master传递过来的rdb文件以后会将自身的内存清空，把rdb文件重新加载到内存中。这种方式效率比较低下，尤其是在数据量大的情况下，毕竟网络闪断未必丢数据或者说丢的数据只是少部分，但却要为此付出将整个内存数据都重新传输一次的代价。如果能够将闪断过程的更新数据传递给Slave，那么就不需要将Master内存中的所有数据都传递给Slave了。Redis作者在2.8的候选版（以下简称Redis2.8）中已经将这个部分复制的思路实现了。
那么Redis2.4.16的全量复制与Redis2.8的部分复制是如何实现的呢?如下图所示,这5个状态是Slave在主从复制过程涉及到的几个状态，其中REDIS_REPL_NONE是Redis启动时候默认的状态。图1-2所示的四个状态表示站在Master的角度来看，Slave所处于的状态，因为Slave在Master端看来就是一个特殊的client（同理Master在Slave端看来也是一个特殊的client）。
/* Slave replication state – Slave side */
Slave自身的状态
Master端的Slave状态
Redis在接收到“slaveof ip port”命令以后，首先会将自身的状态置为REDIS_REPL_CONNECT，表示需要与自己的Master连接，此时Slave并没有与Master做连接。Redis每隔100ms会调用serverCron()函数一次，每10次serverCron()的调用会调用replicationCron()一次，即每1s会调用一次replication()函数。在replication()函数中，会检查Slave的状态，如果是处于REDIS_REPL_CONNECT状态，就会建立syncWithMaster()的事件处理函数，并将Slave的状态改成REDIS_REPL_CONNECTING。syncWithMaster()函数主要是向Master发送sync命令，当该事件处理函数被触发以后会将Slave的状态改成REDIS_REPL_TRANSFER，表示Slave已经准备就绪要接收Master生成的rdb文件。
回到Master的角色，Master发现有一个Slave连接上来，如果此时的Master一个Slave都没有且没有后台快照进程，则启动一个后台进程将当前内存中的数据生成一个rdb文件，同时将Slave的状态置为REDIS_REPL_WAIT_BGSAVE_END状态，表示该Slave等待Master的快照进程结束。在后台进行生成rdb文件的时候，如果有对redis的更新命令，Master会将这些更新命令存到该Slave的buffer中，如果buffer满了会另外开辟list来存储这些更新命令。当后台快照进程结束，Master会将该Slave的状态改为REDIS_REPL_SEND_BULK，同时注册sendBulkToSlave()事件处理函数用于将生成的rdb文件传输给Slave。等rdb传输结束以后，sendBulkToSlave()事件函数会被删除，Slave的状态会被更改为REDIS_REPL_ONLINE，另外再注册sendReplyToClient()事件函数，将Master在快照内过程中的所有更新操作（Slave的buffer里存的命令）发给Slave。
再回到Slave的角色，当Master向Slave传输完rdb文件以后，Slave自身会将状态改为REDIS_REPL_CONNECTED，表示复制已完成，处于与Master保持实时同步的状态。
上述描述的状态转换如图1-3所示，由图中可知，站在Slave角色看，当出现网络中断的时候不管Slave本身是处于REDIS_REPL_CONNECTING、REDIS_REPL_REPL_TRANSFER还是REDIS_REPL_CONNECTED，都会调用相应的处理函数使Slave进入REDIS_REPL_CONNECT状态，这就意味着Slave需要重新向Master发送sync命令，重新进行一次全量同步过程。图中的REDIS_REPL_WAIT_BGSAVE_START状态是在Slave连接上Master的时候（站在Master的角色看），当时Master刚好后台有快照进程且该快照进程生成的rdb不适合直接传给该Slave时出现的状态，则将Slave的状态置为REDIS_REPL_WAIT_BGSAVE_START。如果此时有快照进程且找到了另外的发起快照进程的Slave，只需要将另外的Slave的buffer内容拷贝到该Slave的buffer中，然后直接进入REDIS_REPL_WAIT_BGSAVE_END状态。如果此时没有后台快照进程，Slave直接进入REDIS_REPL_WAIT_BGSAVE_END状态，同时启动一个后台快照进程。