Redis的主从复制

参考网站:http://www.litrin.net/2011/12/20/redis%E7%9A%84%E4%B8%BB%E4%BB%8E%E5%A4%8D%E5%88%B6/

作为MySQL对于Web应用的优化之一，主从复制（Master-slaver）是普遍被接受的，Redis作为当下一个no-sql的解决方案，很自然的将这个特性引入。同时将“操作便捷”作为一大目标，Redis的主从复制更为简单，甚至不需要额外的操作，完全可以在两台热机之间进行。

首先，准备2套Redis主机，本例192.168.0.1为主，192.168.0.2为从。为了保障不会出现稀奇古怪的毛病，要求2台主机配置文件中

databases ，dbs数量，决定了select命令的最大数（分块数量）
maxmemory，最大内存使用，决定了整个系统的容量

两个参数的配置要一致，系统版本尽量保证一致（我测试过不一致的版本也可以同步，但不保证所有的情况下都可以同步）其余的数据不强制要求一致。

用客户端连接slaver主机的redis并操作

redis-cli -h 192.168.0.2

redis 192.168.0.2:6379> slaveof 192.168.0.1 6379

OK

就这么方便！

这时，可以在输入info命令，查看master_host的配置：

redis 192.168.0.2:6379>info

…

master_host:192.168.0.1

…

为保证主机每次启动都保持slave的状态，则可以在redis.conf中增加一行slaveof 192.168.0.1 6379 即可，也非常简单。

作为redis这类nosql来说，并发的压力并不像MySQL那样迫切，何况数据没有关联，一旦出现并发的瓶颈，可以很方便的将数据拆分成多个主机。那对于标准的web应用，主从的意义是什么？

个人理解：

解决Redis内存回写磁盘一瞬间的阻塞问题。

Redis 是内存数据库，数据都在内存中，仅在改变时才会回写。但在磁盘回写的时候，由于需要拷贝内存镜像，整个处于阻塞状态，服务器不会做任何相应，在数据少的情况下阻塞时间也很少，可以忽略。但数据达到G这个级别之后的阻塞绝对是致命的。而且这个阻塞由Redis特性决定，无法彻底解决。

通过主从这种方式对任务进行分工，主机负责写入，通过配置文件中的save选项，减少回写甚至直接取消数据回写，将数据持久化的任务交由slaver主机进行。一旦宕机，由slaver主机上的数据恢复出master。
数据热迁移。

这个很好理解了，数据迁移示意图

redis 数据迁移实例:http://www.litrin.net/wp-content/uploads/2011/12/redis_data.pdf