复制repliction

 

作用

扩展平台以适应高负载，从服务器可以用于处理读取请求。

当数据量太大的时候执行操作话费时间可能需要以秒计算，而不是毫秒或者微秒。

如：SUNIONSTORE命令的性能，作为Redis性能的参考，主频2.4GHz 英特尔酷睿2处理器，对两个包含 10000 个元素的集合执行SUNIONSTORE命令，并产生一个包含20000个元素集合，话费7,8毫秒时间。 此时一秒也只能执行100多个此类命令。

 

复制相关选项配置

dir和dbfilename选项的权限设置为对reids可写

从服务器配置 slaveof host port

 

Redis复制启动过程

步骤	主服务器操作	从服务器操作
1	（等待命令进入）	连接（或重新连接）主服务器，发送SYNC命令
2	开始BGSAVE，并在缓冲区记录BASAVE之后的写命令	根据配置决定是否继续使用现有数据（如果有的话）处理客户端请求，还是返回错误
3	BGSVAE执行完毕，发送快照文件，缓冲区继续记录执行的写命令	丢弃旧数据（如果有的话），开始载入主服务器发来的快照文件
4	发送快照完毕，发送缓冲区中的写命令	完成快照文件的解释操作，开始接受命令请求(若从服务器有从服务器此时他会断开和自己的从服务器的连接，导致重新连接重新同步)
5	缓冲区写命令发送完毕；以后每执行一个写操作，向从服务器发送同样数据	执行所有主服务器发来的所有缓冲区里的写命令；并开始执行主服务器传来的每个写命令

 

可能发生性能瓶颈的原因

1.主从数据库之间网络带宽不足，同步多个从服务器所占用的带宽可能会使得其他命令请求难以传递给主服务器

2.主服务器没有足够的内存创建子进程和创建记录命令的缓冲区。

所以实际中应让主服务器只是用50~65%的内存 ，留下 30%~45的内存执行BGSAVE命令和创建记录写命令的缓冲区。

主从链

解决什么问题？

负载上升到一定程度，主服务器无法快速更新所有的从服务器，或者因为重新连接和重新同步从服务器导致系统超载。此时加入中间夹层分担主服务器的复制工作。

通过同时使用复制和AOF持久化，增强redis对系统奔溃的抵抗能力。

检查硬盘写入

在写入真数据后，写入一个唯一的虚构值，检查虚构值是否存在从服务器判断数据是否到达从服务器。使用aof_pending_bio_fsync属性的值是否为0，是的话则已知的所有数据都保存到硬盘里面了。（P73）