开发者学堂课程【Redis 入门实战演练： Redis 主从同步及实现（二）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/653/detail/10839
Redis 主从同步及实现（二）
搜索 requirepass，找到对应的密码就是 linux39。
重新启动，输入语句systemctl restart redis，把101 重启，确定密码就是linux39，，在102上通过命令语句：redis
-cli -h 172.31.7.101 -p 6379 -a linux39
之后再输入 info 语句，再重复上述步骤输入语句：#ping 172.31.7.101^C、redis-cli、AUTH linux39、SLAVEOF 172.31.7.101 6379、CONFIG SET masterauth linux39
配置好之后查看7.102的日志，输入语句tail -f /apps/redis/logs/redis_6379.log,日志内容结果如下。
刚刚已经配置了这两行内容，一行是：slaveof 172.31.7.101；还有一行是 master 的认证密码，这个密码是通过 config set masterauth linux39 密码；这两行通常会加到配置文件中去。
在下面图中鼠标选中所在行的内容是可以确定主从同步的，就是密码没问题。之后的 Full resync 开头的语句是首次的全部同步，后面的 master 以及它的 id，id 是自动生成的。
Master 的 id 查找，在7.101的窗口上输入语句redis -cli、AUTH 123456、AUTH linux39、info
输入的格式如下图：
之后运行后会得到 master 的 id，结果如下图，是鼠标选中的内容：
Master 的 id 如何在 slave 上查看？
可以看到在他的 info 界面上 id 是下图选中的内容，它的 Replication 上显示变成了 slave，它的主节点是7.101，master 的端口是6379、状态是 up、是几秒之前检查的，最主要的就是它的 slaveid，所以一旦某个结点成为 slave 之后，它的角色就会变为slave，也会标出它对应得 master replid。在后面还有一个 master replid2，这个是当发生 master 得切换时 master replid 的内容会下移动至 master replid2 上，新的 master 会放置在 master replid 上。
如何切换的 id，是在主从结构上，备份2的结点先连到主的上去，之后主结点挂掉之后，master 会换成另一个，这个过程可能会出现多个 replid。如下图所示。
第一次进行完全同步就是要确定 master 的 id 是多少，之后的内容就是从 master 中接受数据，从 master 到 slave 开始同步，同步结束后会接收到176个数据，接着 Flushing old data 会以当前的数据为准把数据全部清空格式化，就是之前讲的一旦某个 Slave 成为一个 master 的 slave，Redis Slave服务会清空当前 redis 服务器上的所有数据并将master的数据 导入到自己的内存，但是断开同步关系后不会删除当前已经同步过的数据。Loading DB in memory 就是把最开始接收到的数据全部保存到内存中，这个数据就导入完成了，后面会打开 background 文件。
那么如何测验同步是否正常？是在哪些库里创建的数据？看看数据有没有同步到 slave 上？
先通过语句 redis-cli、AUTH linux39、info、KEYS * 进入查看0号数据，会发现是空的。
之后在 SET key1 value1，这是在 master 类里写了一个数据 key，还要进行同步数据，这个比 MySQL 要简单，是不用导入数据、账号密码，直接是 slave 加上 config set masterauth 就可以
测试 master 上的数据是不是可以同步成功是非常重要的，如果可以同步成功，那就没问题；同步不成功，就要检查到底是哪里出现问题。
slave 是只读，到目前为止是不可以写数据的，原因是在 master 的配置中加入了slave 是 read only，是只读的，输入语句vim /apps/redis/etc/redis.conf,运行后查找 read 既可查看到slave是被设置为可读，打开之后 slave 就不能书写，也就是说在 slave 上 set 数据是不成功的。
比如书写一个 key3，语句为SET key3 value3，会书写失败，提示 slave 是只读的，不能够书写数据。
三、主从同步过程
不管是之后讲的 RDB 还是 AOF、或是集群、redis cluster、哨兵都是依赖这个模式
Redis支持主从复制分为全量同步和增量同步，首次同步是全量同步，主从同步可以让从服务器从主服务器备份数一据，而且从服务器还可与有从服务器，即另外一台 redis 服务器可以从一台从服务器进行数据同步，redis 的主从同步是非阻塞的， masten 收到从服务器的 sync(2.8版本之前是 PSYNC)命令会 fork 一个子进程在后台执行 bgsave 命令，并将新写入的数据写入到一个缓冲区里面，bgave 执行完成之后并生成的将 RDB 文件发送给客户端，客户端将收到后的 RDB 文件载入自己的内存，然后 redis master 再将缓冲区的内容在全部发送给 redisslave，之后的同步slave服务器会发送一个 offset 的位置(等同于 My SQL 的 binlog 的位置)给主服务器，主服务器检查后位置没有错误将此位置之后的数据包括写在缓冲区的积压数据发送给 redis 从服务器（就是主服务器检查 slave 的 offset 位置，如果没有问题，就会把位置的数据发给 slave 服务器），从服务器将主服务器发送的挤压数据写入内存，这样一次完整的数据同步（到这是完成的全量同步），再之后再同步的时候从服务器只要发送当前的 offset 位置给主服务器，然后主服务器根据相应的位置将之后的数据发送给从服务器保存到其内存即可（这些是进行后期的增量同步）。
Redis 的数据量很大并不能每一次都进行全量同步，全量同步如果一个 redis 有四个数据，就要同步四个 G，所以说 redis 的同步不会经常同步。
（1）Redis 全量复制一般发生在 Slave 首次初始化阶段，这时 Slave 需要将 Master 上的所有数据都复制一份。具体主从同步骤如下：
1.从服务器连接主服务器，发送 SYNC 命令；
2.主服务器接收到 SYNC 命名后，开始执行 BGSAVE 命令生成 RDB 快照文件并使用城冲区记录此后执行的所有写命令(就是后面的写的命令会寄存到缓冲区，等待一会发给 slave)；
3.主服务器 BGSAVE 执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；在 RDB 文件发送之前，redis 还是在接受用户客户命令端的写操作，所以此时还能够进行写数据，这些数据在 RDB 文件发送之前还会一点点寄存到缓冲区，一直到 RDB 文件发送完成。
4.从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
5.主题务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；就是 RDB 文件发送完后,缓冲去记录了从 RDB 文件到 master 文件发送完之后，中间的一系列应用信息，会发送 slave 服务器
6.从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；
7.后期同步会先发送自己 slave _ reply offset 位置，只同步新增加的数据，不再全量同步；到这一步说明前面的全量同步已经完成，后期就执行增量同步，只有第一次是全量同步。
如何查看全量同步？在第一次的日志中，输入语句vim /apps/redis/logs/redis_6379.log,可以看到第一次还报的是0错误、之后带*的就是开始同步。第一个执行的叫Full resync from master，就是全量同步，这就意味着第一次就要把 master 的 main 数据全部 slave 同步。
在 mysql 中如果有多个服务器还需要打开 binlog，但是 redis 是不需要的。
新写入的数据写入到一个缓冲区里面。这个概念就是一个 master 和一个 slave 在同步数据的时候，无论是通过 slave 的配置文件还是 slave 的命令行窗口去配置 slave masterauth、或是配置文件指定。一旦配置文件配置好，就会同步数据，由于是第一次同步数据，所以 slave 上是没有之前的数据，这是要进行的全量同步。而 master 会执行一个子进程，主进程会继续执行外部的对外请求，继续对外做增删改查，主进程一旦接收到 salve 的同步请求，会生成一个子进程，由子进程负责做 RDB，也就是从当前的进程就拍照，把快照文件发给 slave。一旦这个快照文件开始，并且这个文件快传输完之前，redis 还是会接受外部的请求。当然，这个内存区域，对于主进程来说是可以读写的，对于子进程文件是只读的，这个子进程会在磁盘上生成一个 RDB 文件，在主从同步上使用的 RDB 文件。就是由子进程把内存区域放置到磁盘上，给 slave 发磁盘文件。此时 redis 服务器还在接受外部的请求，还会在产生新的数据，一旦产生 RDB，这个文件就会放到一个区域，这个区域叫做缓冲区。当 slave 文件向 RDB 文件发送完毕后，这个子进程会在向 RDB 文件给 slave 发过去，那么这一次就做了一个完整的同步数据，此时 slave 就是 master 的全部数据，后期再有数据就是 mysql 一样的增量过程。
为什么会有增量过程？可以看命令行中的 info 中有一个 slave_repl_offset，这个就是同步数据的位置，它在 MySQL 中叫做 position，可以知道上一次同步数据的位置。Change master to 是给 salve 设置数据的时 master 的地址，而这个是 MySQL 主从同步建立之后，slave 向 master 发布请求同步数据的时候要发送的位置。
Position 在同步数据的时候，后期会发送一个 position 位置，这个就是当前主从同步到的位置，简称是 pos，这是 mysql 同步的最关键的地方。
redis 中的这个同步数据的位置是叫 offset，所以说在后期主从同步的时候，master拿到这个位置，就会从从这个位置之后进行数据同步，所以在后期的（增量同步数据）来说就是比较简单的。
细化地说这个全量同步过程如下图示意，第一步是发送同步请求；第二步是收到slave 请求并执行 BGSAVE 生成当前快照并记录此后的写命令；第三部是 redis master 发送快照给 slave 服务器；第四步是slave收到数据并加载快照数据，在这一步前面还有一个 Flushing 步骤是用来清空之前的数据；第五步是主服务器发送快照后内存缓冲区的写命令；第六步是在 slave 载入缓存区写命令，到这就完成了全量同步。后期只进行部分同步，第一是发送 slave_repl_offset 位置请求同步；第二是执行 BGSAVE，发送 offset 后的写命令；第三是载入写命令，等待下一次增量同步。
主从同步后期是比较简单，类似于 MySQL，只用进行一次全量同步，后期只用进行增量同步，可以查看一下增量同步的日志，先退出来使用语句 tail -f /apps/redis/logs/redis_6379.log。然后想办法在 master 上写入一些数据，通过redis命令来写（如果有脚本的话可以用脚本来批量写一些数据），语句为SET key4 value4、AUTH linux39、SET key4 value4，示意图如下。
