redis数据的同步问题

修改redis.conf配置文件

vi redis.conf

在编辑模式下 输入 /slaveof 来搜索

将slaveof启用 即 将#删除

依次配置所有 slave 并将进程 kill 掉 重启


查看主从信息

redis 集群主从同步的简单原理

Redis的复制功能是基于内存快照的持久化策略基础上的，也就是说无论你的持久化策略选择的是什么，只要用到了Redis的复制功能，就一定会有内存快照发生。

当Slave启动并连接到Master之后，它将主动发送一个SYNC命令( 首先Master会启动一个后台进程，将数据快照保存到文件中[rdb文件] Master 会给Slave 发送一个

Ping命令来判断Slave的存活状态 当存活时 Master会将数据文件发送给Slave 并将所有写命令发送到Slave )。

Slave首先会将数据文件保存到本地 之后再将 数据 加载到内存中。当第一次链接 或者是 故障后 重新连接 都会先判断Slave的存活状态 在做全部数据的同步 ， 之后只会同步Master的写操作(将命令发送给Slave)

问题：

当 Master 同步数据时 若数据量较大 而Master本身只会启用一个后台进程 来对多个Slave进行同步 ， 这样Master就会压力过大 ， 而且Slave 恢复的时间也会很慢！

redis 主从复制的优点：
(1)在一个Redis集群中，master负责写请求，slave负责读请求，这么做一方面通过将读请求分散到其他机器从而大大减少了master服务器的压力，另一方面slave专注于提供读服务从而提高了响应和读取速度。
(2)在一个Redis集群中，如果master宕机，slave可以介入并取代master的位置，因此对于整个Redis服务来说不至于提供不了服务，这样使得整个Redis服务足够安全。
(3)水平增加Slave机器可以提高性能
Slave 默认是只读的更改：
　　Master 可以 读写（Write and Read） 而 Slave只可以读（read only默认情况）也可以更改 {但是开启后Slave数据不会向上同步}
　　
　　Redis的主从架构的两种方式:
1.主从架构:

2.主从从架构:

备注:
　　因为Slave断连，重连后仍然会全部同步数据，所以redis2.8版本后，增加了增量复制来解决宕机后重新链接仍然会全部同步！
Master会维护一个环形队列：
　队列内存储：1》：slave连接master的id值 2》:slave上一次同步的最后一个命令这样当断开重连后就不会全部同步，而只会在最后一个命令同步数据！
　当你看到这些感到redis很好,有一点你要你记住,redis是基于内存的,内存是很珍贵的,公司不会花费大量的资源只为了让你玩这个架构,同时推荐memcached,这个成本就比较低了,因为它是基于磁盘的,当然效率就会比基于内存的redis低,同时也有和redis同样设计风格的非关系型数据库SSDB就比较友善了。
　
　SSDB和Redis的优缺点比较:
redis是内存数据库，ssdb是面向硬盘的存储，二者在存储格式和读写方式上有着根本的不同。前面回答里提到的zrevrange 和 zrevrangebyscore慢，而zrange 和 zrangebyscore 还能接受，其实就是说逆序遍历比顺序遍历慢得多，其根本原因就在于逆序遍历的时候，会多一个“记录头部”定位的过程，需要不断尝试去定位到两条记录的“分界点”，而顺序遍历的时候则不需要，因为读完一条记录直接就到了下一条记录的“分界点”，并且像rocksdb之类的存储引擎都会把数据长度保存在记录的元信息里，只需要按长度读取数据就可以了。redis则不存在类似问题，因为它是完全基于指针和偏移量在内存中进行寻址来读取数据的，寻址效率高了好多个数量级。ssdb貌似就是一个个人项目，但代码质量还是不错的，整个设计思想比较简洁。ssdb的主从复制效率很低。binlog和数据是分开存储的，日志冗余较多，由于ssdb本身要在多线程条件下才能发挥出更好的性能，为了使多个线程在写入binlog时能保证操作顺序和原子性，ssdb的binlog数据结构上用了一把全局锁，可想而知，这里的锁竞争会很影响性能。另外，ssdb默认也没有集群管理的支持。ssdb的好处，和swapdb一样，都可以省钱。如果有需要，可以尝试swapdb，它结合了redis和ssdb的优点，实现了基于LFU的热度统计和冷热交换，做到了低成本和高性能的高平衡。redis的好处，那就多了。缺点就是纯内存，比用SSD花钱。