Redis 必备知识总结（基础知识 架构 调优和监控知识及难点解决）.docx
LRedis概览Redis和memcache的区别，Redis支持的数据类型应用场景redis支持的数据结构更丰富（String,hash,list,set,zset）omemcache只支持key-value的存储；redis原生支持集群，memcache没有原生的集群模式。2 .Redis单线程模型redis单线程处理请求流程redis采用IO多路复用机制来处理请求，采用reactorl模型，处理流程如下:首先接收到客户端的socket请求，多路复用器将socket转给连接应答处理器；连接应答处理器将AE-READABLE事件与命令请求处理器关联（这里是把socket事件放入一个队列）；命令请求处理器从SOCket中读到指令,再内存中执行,并将AE_WRITEABLE事件与命令回复处理器关联；命令回复处理器将结果返回给SOCke3并解除关联。redis单线程效率高的原因非阻塞IO复用（上图流程），1/0多路复用分派事件，事件处理器处理事件（这个可以理解为注册的一段函数，定义了事件发生的时候应该执行的动作），这里分派事件和处理事件其实都是同一个线程；纯内存操作效率高；单线程反而避免了多线程切换。3 .Redis过期策略对key设置有效期，redis的删除策略:定期删除+惰性删除。定期删除指的是redis默认每100ms就随机抽取一些设置了过期事件的key,检查是否过期，如果过期就删除。如果redis设置了10万个key都设置了过期时间，每隔几百亳秒就要检查10万个key那CPU负载就很高了，所以redis并不会每隔IOomS就检查所有的key,而是随机抽取一些key来检查。但这样会导致有些key过期了并没有被删除，所以采取了惰性删除。意思是在获取某个key的时候发现过期了，如果key过期了就删除掉不会返回。这两个策略结合起来保证过期的key一定会被删除。最大内存淘汰（maxmemory-policy）如果redis内存占用太多，就会进行内存淘汰。有如下策略：noeviction:如果内存不足以写入数据，新写入操作直接报错；Wkeys-Iru:内存不足以写入数据，移除最近最少使用的key（最常用的策略）；allkeys-random:内存不足随机移除几个key；Volatilelru:在设置了过期时间的key中，移除最近最少使用；Volatile-random:设置了过期的时间的key中，随机移除几个。4 .Redis主从模式保证高并发和高可用（哨兵模式）读写分离单机的Redis的QPS大概就在上万到几万不等，无法承受更高的并发。读写分离保证高并发（IOW+QPS）：对于缓存来说一般都是支撑高并发读，写请求都是比较少的。采用读写分离的架构（一主多从），master负责接收写请求，数据同步到slave上提供读服务，如果遇到瓶颈只需要增加slave机器就可以水平扩容。主从复制机制redisreplication机制：redis采取异步复制到SlaVe节点；slave节点做复制操作的时候是不会block自己的，它会使用旧的数据集来提供服务，复制。完成后，删除旧的数据集，加载新的数据集，这个时候会暂停服务（时间很短暂）;如果采用了主从架构，master需要开启持久化。如果master没有开启持久化（rdb和aof都关闭了）。master宕机重启后数据是空的，然后经过复制就把所有slave的数据也弄丢了。即使采用高可用的的哨兵机制，可能sentinal还没有检测到masterfailure,master就自动重启了，还是会导致SlaVe清空故障。主从同步流程当slave启动时会发送一个psync命令给master；如果是重新连接master,则masternode会复制给slave缺少的那部分数据；如果是slave第一次连接master,则会触发一次全量复制（fullresynchronization）o开始fullresynchronization的时候,master会生成一份rdb快照，同时将客户端命令缓存在内存，rdb生成完后，就发送给slave,slave先写入磁盘在加载到内存。然后master将缓存的命令发送给slave。replead哨兵（SentinaI）模式介绍哨兵是redis集群架构的一个重要组件，主要提供如下功能:集群监控：负责监控master和SlaVe是否正常工作；消息通知：如果某个redis实例有故障，哨兵负责发消息通知管理员；故障转移:如果masternode发生故障，会自动切换到slave；配置中心：如果故障转移发生了，通知客户端新的master地址。哨兵的核心知识：哨兵至少三个，保证自己的高可用；哨兵+主从的部署架构是用来保证redis集群高可用的，并非保证数据不丢失；哨兵(SentineI)需要通过不断的测试和观察才能保证高可用。为什么哨兵只有两个节点无法正常工作假设哨兵集群只部署了2个哨兵实例，quorum=Kmaster宕机的时候，si和s2只要有一个哨兵认为master宕机j就可以进行切换，并且会从Sl和s2中选取一个来进行故障转移。这个时候是需要满足majority,也就是大多数哨兵是运行的，2个哨兵的majority是2,如果2个哨兵都运行着就允许执行故障转移。如果Ml所在的机器宕机了，那么Sl哨兵也就挂了，只剩s2一个，没有majority1来允许执行故障转移，虽然集群还有一台机器Rl,但是故障转移也不会执行。如果是经典的三哨兵集群，如下：此时majority也是2,就算Ml所在的机器宕机了，哨兵还是剩下两个s2和s3,它们满足majority就可以允许故障转移执行。哨兵核心底层原理sdown和OdoWn两种失败状态；SdOWn是主观宕机，就是一个哨兵觉得master宕机了，达成条件是如果一个哨兵pingmaster超过了is-master-down-after-milliseconds指定的亳秒数后就认为主观宕机；odown是客观宕机，如果一个哨兵在指定时间内收到了majority(大多数)数量的哨兵也认为那个master宕机了，就是客观宕机。哨兵之间的互相发现：哨兵是通过redis的pub/sub实现的。5 .Redis数据的恢复(RediS的持久化)RDBRDB原理RDB(RedisDataBase)是将某一个时刻的内存快照(Snapshot),以二进制的方式写入磁盘的过程。RDB有两种方式save和bgsave:save:执行就会触发RediS的持久化，但同时也是使RediS处于阻塞状态，直到RDB持久化完成，才会响应其他客户端发来的命令；bgsave:bgsave会fork()一个子进程来执行持久化，整个过程中只有在fork()子进程时有短暂的阻塞，当子进程被创建之后，Redis的主进程就可以响应其他客户端的请求了。RDB配置除了使用save和bgsave命令触发之外，RDB支持自动触发。自动触发策略可配置RediS在指定的时间内，数据发生了多少次变化时，会自动执行bgsave命令。在redis配置文件中配置：在时间m秒内，如果Redis数据至少发生了n次变化，那么就自动执行BGSAVE命令。savemnRDB优缺点RDB的优点RDB会定时生成多个数据文件，每个数据文件都代表了某个时刻的redis全量数据，适合做冷备，可以将这个文件上传到一个远程的安全存储中，以预定好的策略来定期备份redis中的数据；RDB对redis对外提供读写服务的影响非常小，redis是通过fork主进程的一个子进程操作磁盘IO来进行持久化的；相对于AoF,直接基于RDB来恢复reids数据更快。RDB的缺点：如果使用RDB来恢复数据，会丢失一部分数据，因为RDB是定时生成的快照文件；RDb'每次来fork出子进程的时候，如果数据文件特别大，可能会影响对外提供服务，暂停数秒（主进程需要拷贝自己的内存表给子进程，实例很大的时候这个拷贝过程会很长）。IatesJforkjisec代表fork导致的延时；Redis上执行INFO命令查看IateSt_fork_usec；当RDB比较大的时候，应该在SIaVe节点执行备份，并在低峰期执行。AOFAOF原理redis对每条写入命令进行日志记录，以append-only的方式写入一个日志文件，redis重启的时候通过重放日志文件来恢复数据集。（由于运行久了AoF文件会越来越大，redis提供一种rewrite机制，基于当前内存中的数据集，来构建一个更小的AOF文件，将旧的庞大的AoF文件删除）。rewrite即把日志文件压缩，通过bgrewriteaof触发重写。AOFrewrite后台执行的方式和RDB有类似的地方，fork一个子进程，主进程仍进行服务，子进程执行AOF持久化，数据被dump到磁盘上。与RDB不同的是，后台子进程持久化过程中，主进程会记录期间的所有数据变更（主进程还在服务），并存储在server.aof_rewrite_buf_blocks中；后台子进程结束后，Redis更新缓存追加到AoF文件中，是RDB殍久化所不具备的。AOF的工作流程如下：RediS执行写命令后，把这个命令写入到AOF文件内存中（Write系统调用）；Redis根据配置的AoF刷盘策略，把AOF内存数据刷到磁盘上（fsync系统调用）;根据rewrite相关的配置触发rewrite流程。AOF配置即PendonIy:是否启用AOF（yesno）;appendfsync:刷盘的机制：always：主线程每次执行写操作后立即刷盘，此方案会占用比较大的磁盘IO资源，但数据安全性最高；everysec：主线程每次写操作只写内存就返回，然后由后台线程每隔1秒执行一次刷盘操作（触发fsync系统调用）,此方案对性能影响相对较小，但当Redis宕机时会丢失1秒的数据；no：主线程每次写操作只写内存就返回，内存数据什么时候刷到磁盘，交由操作系统决定，此方案对性能影响最小，但数据安全性也最低，RediS宕机时丢失的数据取决于操作系统刷盘时机。auto-aof-rewrite-percentage:当aof文件相较于上一版本的aof文件大小的百分比达到多少时触发AOF重写。举个例子，auto-aof-rewrite-percentage选项配置为100,上一版本的aof文件大小为100M,那么当我们的aof文件达到200M的时候，触发AOF重写；auto-aof-rewite-min-size：最小能容忍aof文件大小，超过这个大小必须进行AOF重写；no-appendfsync-on-rewrite:设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中，等rewrite完成后再写入，默认为no。AOF优缺点AOF的优点：可以更好的保证数据不丢失，一般AOF每隔Is通过一个后台线程来执行fsync（强制刷新磁盘页缓存），最多丢失Is的数据；AOF以append-only的方式写入（顺序追加），没有磁盘寻址开销，性能很高;AOF即使文件很大，触发后台rewrite的操作的时候一般也不会影响客户端的读写，（rewrite的时候会对其中指令进行压缩，创建出一份恢复需要的最小日志出来）。在创建新的日志文件的时候，老的文件还是照常写入，当新的文件创建完成后再交换新老日志。但是还是有可能会影响到主线程的写入，如：当磁盘的IO负载很高，那这个后台线程在执行AoFfSynC刷盘操作（fsync系统调用）时就会被阻塞住，紧接着,
