redis使用及运维课件.ppt

对比分析 快照易丢失数据，AOF模式较为安全，但日志重写时磁盘io开销大，容易导致服务器性能严重下降，并且需要足够的物理内存，这个比较危险，所以在高性能服务器上一般是用主从复制来进行持久化。 Redis持久化 特点 master可以有多个slave。 除了多个slave连到相同的master外，slave也可以连接其他slave形成图状结构。 主从复制不会阻塞master。也就是说当一个或多个slave与master进行初次同步数据时，master可以继续处理client发来的请求。相反slave在初次同步数据时则会阻塞不能处理client的请求。 主从复制可以用来提高系统的可伸缩性,我们可以用多个slave 专门用于client的读请求，比如sort操作可以使用slave来处理。也可以用来做简单的数据冗余。 可以在master禁用数据持久化，只需要注释掉master 配置文件中的所有save配置，然后只在slave上配置数据持久化。 Redis主从复制 配置 slaveof 8359，指定master的ip和端口。 问题 slave从库在连接Master主库时，Master会进行内存快照，然后把整个快照文件发给Slave，也就是没有象MySQL那样有复制位置的概念，即无增量复制，这会给整个集群搭建带来较多问题。 Redis主从复制 client client client master master master slave slave slave CONSISTENT HASH / 定容 read write 同步数据 slave 主从架构示例 Redis主从复制 主从复制过程 Slave端在配置文件中添加了slave of指令，于是Slave启动时读取配置文件，初始状态为REDIS_REPL_CONNECT。 Slave端在定时任务serverCron(Redis内部的定时器触发事件)中连接Master，发送sync命令，然后阻塞等待master发送回其内存快照文件(最新版的Redis已经不需要让Slave阻塞)。 Master端收到sync命令简单判断是否有正在进行的内存快照子进程，没有则立即开始内存快照，有则等待其结束，当快照完成后会将该文件发送给Slave端。 Slave端接收Master发来的内存快照文件，保存到本地，待接收完成后，清空内存表，重新读取Master发来的内存快照文件，重建整个内存表数据结构，并最终状态置位为 REDIS_REPL_CONNECTED状态，Slave状态机流转完成。 Master端在发送快照文件过程中，接收的任何会改变数据集的命令都会暂时先保存在Slave网络连接的发送缓存队列里（list数据结构），待快照完成后，依次发给Slave,之后收到的命令相同处理，并将状态置位为 REDIS_REPL_ONLINE。 Redis主从复制 主从复制过程 Redis主从复制 部署 客户端 Redis运维 架构示例 下载安装 mkdir -p /root/install ; cd /root/install; wget -c /store/redis/redis-2.4.16.tar.gz tar zxvf redis-2.4.16.tar.gz cd /root/install/redis-2.4.16 make mkdir -p /opt/soft/redis2.4.16 rm -f /opt/soft/redis ; ln -s /opt/soft/redis2.4.16 /opt/soft/redis cp /root/install/redis-2.4.16/src/redis-benchmark /opt/soft/redis2.4.16/ cp /root/install/redis-2.4.16/src/redis-server /opt/soft/redis2.4.16/ cp /root/install/redis-2.4.16/src/redis-cli /opt/soft/redis2.4.16/ cp /root/install/redis-2.4.16/src/redis-check-dump /opt/soft/redis2.4.16/ cp /root/install/redis-2.4.16/src/redis-check-aof /opt/soft/redis2.4.16/ Redis部署 配置 daemonize yes pidfile /dev/shm/redis.pid port 8359 unixsocket /dev/shm/redis.so