参考网站: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。 - 数据热迁移。
这个很好理解了,数据迁移示意图