《Redis 必备知识总结（基础知识 架构 调优和监控知识及难点解决）.docx》由会员分享，可在线阅读，更多相关《Redis 必备知识总结（基础知识 架构 调优和监控知识及难点解决）.docx（21页珍藏版）》请在三一办公上搜索。
1、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事件放入一个队列）；命
2、令请求处理器从SOCket中读到指令,再内存中执行,并将AE_WRITEABLE事件与命令回复处理器关联；命令回复处理器将结果返回给SOCke3并解除关联。redis单线程效率高的原因非阻塞IO复用（上图流程），1/0多路复用分派事件，事件处理器处理事件（这个可以理解为注册的一段函数，定义了事件发生的时候应该执行的动作），这里分派事件和处理事件其实都是同一个线程；纯内存操作效率高；单线程反而避免了多线程切换。3 .Redis过期策略对key设置有效期，redis的删除策略:定期删除+惰性删除。定期删除指的是redis默认每100ms就随机抽取一些设置了过期事件的key,检查是否过期，如果过期就
3、删除。如果redis设置了10万个key都设置了过期时间，每隔几百亳秒就要检查10万个key那CPU负载就很高了，所以redis并不会每隔IOomS就检查所有的key,而是随机抽取一些key来检查。但这样会导致有些key过期了并没有被删除，所以采取了惰性删除。意思是在获取某个key的时候发现过期了，如果key过期了就删除掉不会返回。这两个策略结合起来保证过期的key一定会被删除。最大内存淘汰（maxmemory-policy）如果redis内存占用太多，就会进行内存淘汰。有如下策略：noeviction:如果内存不足以写入数据，新写入操作直接报错；Wkeys-Iru:内存不足以写入数据，移除最
4、近最少使用的key（最常用的策略）；allkeys-random:内存不足随机移除几个key；Volatilelru:在设置了过期时间的key中，移除最近最少使用；Volatile-random:设置了过期的时间的key中，随机移除几个。4 .Redis主从模式保证高并发和高可用（哨兵模式）读写分离单机的Redis的QPS大概就在上万到几万不等，无法承受更高的并发。读写分离保证高并发（IOW+QPS）：对于缓存来说一般都是支撑高并发读，写请求都是比较少的。采用读写分离的架构（一主多从），master负责接收写请求，数据同步到slave上提供读服务，如果遇到瓶颈只需要增加slave机器就可以水平
5、扩容。主从复制机制redisreplication机制：redis采取异步复制到SlaVe节点；slave节点做复制操作的时候是不会block自己的，它会使用旧的数据集来提供服务，复制。完成后，删除旧的数据集，加载新的数据集，这个时候会暂停服务（时间很短暂）;如果采用了主从架构，master需要开启持久化。如果master没有开启持久化（rdb和aof都关闭了）。master宕机重启后数据是空的，然后经过复制就把所有slave的数据也弄丢了。即使采用高可用的的哨兵机制，可能sentinal还没有检测到masterfailure,master就自动重启了，还是会导致SlaVe清空故障。主从同步流
6、程当slave启动时会发送一个psync命令给master；如果是重新连接master,则masternode会复制给slave缺少的那部分数据；如果是slave第一次连接master,则会触发一次全量复制（fullresynchronization）o开始fullresynchronization的时候,master会生成一份rdb快照，同时将客户端命令缓存在内存，rdb生成完后，就发送给slave,slave先写入磁盘在加载到内存。然后master将缓存的命令发送给slave。replead哨兵（SentinaI）模式介绍哨兵是redis集群架构的一个重要组件，主要提供如下功能:集群监控：
7、负责监控master和SlaVe是否正常工作；消息通知：如果某个redis实例有故障，哨兵负责发消息通知管理员；故障转移:如果masternode发生故障，会自动切换到slave；配置中心：如果故障转移发生了，通知客户端新的master地址。哨兵的核心知识：哨兵至少三个，保证自己的高可用；哨兵+主从的部署架构是用来保证redis集群高可用的，并非保证数据不丢失；哨兵(SentineI)需要通过不断的测试和观察才能保证高可用。为什么哨兵只有两个节点无法正常工作假设哨兵集群只部署了2个哨兵实例，quorum=Kmaster宕机的时候，si和s2只要有一个哨兵认为master宕机j就可以进行切换，并
8、且会从Sl和s2中选取一个来进行故障转移。这个时候是需要满足majority,也就是大多数哨兵是运行的，2个哨兵的majority是2,如果2个哨兵都运行着就允许执行故障转移。如果Ml所在的机器宕机了，那么Sl哨兵也就挂了，只剩s2一个，没有majority1来允许执行故障转移，虽然集群还有一台机器Rl,但是故障转移也不会执行。如果是经典的三哨兵集群，如下：此时majority也是2,就算Ml所在的机器宕机了，哨兵还是剩下两个s2和s3,它们满足majority就可以允许故障转移执行。哨兵核心底层原理sdown和OdoWn两种失败状态；SdOWn是主观宕机，就是一个哨兵觉得master宕机了，
9、达成条件是如果一个哨兵pingmaster超过了is-master-down-after-milliseconds指定的亳秒数后就认为主观宕机；odown是客观宕机，如果一个哨兵在指定时间内收到了majority(大多数)数量的哨兵也认为那个master宕机了，就是客观宕机。哨兵之间的互相发现：哨兵是通过redis的pub/sub实现的。5 .Redis数据的恢复(RediS的持久化)RDBRDB原理RDB(RedisDataBase)是将某一个时刻的内存快照(Snapshot),以二进制的方式写入磁盘的过程。RDB有两种方式save和bgsave:save:执行就会触发RediS的持久化，但
10、同时也是使RediS处于阻塞状态，直到RDB持久化完成，才会响应其他客户端发来的命令；bgsave:bgsave会fork()一个子进程来执行持久化，整个过程中只有在fork()子进程时有短暂的阻塞，当子进程被创建之后，Redis的主进程就可以响应其他客户端的请求了。RDB配置除了使用save和bgsave命令触发之外，RDB支持自动触发。自动触发策略可配置RediS在指定的时间内，数据发生了多少次变化时，会自动执行bgsave命令。在redis配置文件中配置：在时间m秒内，如果Redis数据至少发生了n次变化，那么就自动执行BGSAVE命令。savemnRDB优缺点RDB的优点RDB会定时生
11、成多个数据文件，每个数据文件都代表了某个时刻的redis全量数据，适合做冷备，可以将这个文件上传到一个远程的安全存储中，以预定好的策略来定期备份redis中的数据；RDB对redis对外提供读写服务的影响非常小，redis是通过fork主进程的一个子进程操作磁盘IO来进行持久化的；相对于AoF,直接基于RDB来恢复reids数据更快。RDB的缺点：如果使用RDB来恢复数据，会丢失一部分数据，因为RDB是定时生成的快照文件；RDb每次来fork出子进程的时候，如果数据文件特别大，可能会影响对外提供服务，暂停数秒（主进程需要拷贝自己的内存表给子进程，实例很大的时候这个拷贝过程会很长）。IatesJ
12、forkjisec代表fork导致的延时；Redis上执行INFO命令查看IateSt_fork_usec；当RDB比较大的时候，应该在SIaVe节点执行备份，并在低峰期执行。AOFAOF原理redis对每条写入命令进行日志记录，以append-only的方式写入一个日志文件，redis重启的时候通过重放日志文件来恢复数据集。（由于运行久了AoF文件会越来越大，redis提供一种rewrite机制，基于当前内存中的数据集，来构建一个更小的AOF文件，将旧的庞大的AoF文件删除）。rewrite即把日志文件压缩，通过bgrewriteaof触发重写。AOFrewrite后台执行的方式和RDB有类
13、似的地方，fork一个子进程，主进程仍进行服务，子进程执行AOF持久化，数据被dump到磁盘上。与RDB不同的是，后台子进程持久化过程中，主进程会记录期间的所有数据变更（主进程还在服务），并存储在server.aof_rewrite_buf_blocks中；后台子进程结束后，Redis更新缓存追加到AoF文件中，是RDB殍久化所不具备的。AOF的工作流程如下：RediS执行写命令后，把这个命令写入到AOF文件内存中（Write系统调用）；Redis根据配置的AoF刷盘策略，把AOF内存数据刷到磁盘上（fsync系统调用）;根据rewrite相关的配置触发rewrite流程。AOF配置即Pend
14、onIy:是否启用AOF（yesno）;appendfsync:刷盘的机制：always：主线程每次执行写操作后立即刷盘，此方案会占用比较大的磁盘IO资源，但数据安全性最高；everysec：主线程每次写操作只写内存就返回，然后由后台线程每隔1秒执行一次刷盘操作（触发fsync系统调用）,此方案对性能影响相对较小，但当Redis宕机时会丢失1秒的数据；no：主线程每次写操作只写内存就返回，内存数据什么时候刷到磁盘，交由操作系统决定，此方案对性能影响最小，但数据安全性也最低，RediS宕机时丢失的数据取决于操作系统刷盘时机。auto-aof-rewrite-percentage:当aof文件相较
15、于上一版本的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通过一个后台线程来
16、执行fsync（强制刷新磁盘页缓存），最多丢失Is的数据；AOF以append-only的方式写入（顺序追加），没有磁盘寻址开销，性能很高;AOF即使文件很大，触发后台rewrite的操作的时候一般也不会影响客户端的读写，（rewrite的时候会对其中指令进行压缩，创建出一份恢复需要的最小日志出来）。在创建新的日志文件的时候，老的文件还是照常写入，当新的文件创建完成后再交换新老日志。但是还是有可能会影响到主线程的写入，如：当磁盘的IO负载很高，那这个后台线程在执行AoFfSynC刷盘操作（fsync系统调用）时就会被阻塞住，紧接着,主线程又需要把数据写到文件内存中（Write系统调用），但此时
17、的后台子线程由于磁盘负载过高，导致fsync发生阻塞，迟迟不能返回，那主线程在执行Write系统调用时，也会被阻塞住，直到后台线程fsync执行完成后，主线程执行Write才能成功返回。这时候主线程就无法响应客户端的请求，可能会导致客户端请求redis超时。AOF日志文件通过非常可读的方式进行记录，这个特性适合做灾难性的误操作的紧急恢复，比如不小心使用flushall清空了所有数据，只要rewrite没有发生，就可以立即拷贝AOF,将最后一条flushall命令删除，再回放AoF恢复数据。AoF的缺点：同一份数据，因为AOF记录的命令会比RDB快照文件更大;AOF开启后，支持写的QPS会比RD
18、B支持写的QPS要低，毕竟AoF有写磁盘的操作。总结总结AOF和RDB该如何选择：两者综合使用，将AOF配置成每秒fsync一次。RDB作为冷备，AoF用来保证数据不丢失的恢复第一选择，当AOF文件损坏或不可用的时候还可以使用RDB来快速恢复。6 .Redis集群模式（rediscluster）在主从部署模式上，虽然实现了一定程度的高并发，并保证了高可用，但是有如下限制：master数据和SIaVe数据模样，master的数据量就是集群的限制瓶颈；redis集群的写能力也受到了master节点的单机限制。在高版本的Redis已经原生支持集群（CIUSter）模式，可以多master多slave
19、部署，横向扩展Redis集群的能力。RedisCluster支持N个masternode,每个masternode可以挂载多个Slavenodeorediscluster介绍自动将数据切片，每个master上放一部分数据；提供内置的高可用支持，部分master不可用时还是能够工作；rediscluster模式下，每个redis要开放两个端口：6379和100O0+以后的端口（如16379）o16379是用来节点之间通信的,使用的是clusterbus集群总线。CIUSterbUS用来做故障检测，配置更新，故障转移授权。rediscluster负载均衡rediscluster采用一致性hash+
20、虚拟节点来负载均衡。rediscluster有固定的16384个slot（2八14）,对每个key做CRCl6值计算，然后对16384mod.可以获取每个key的slotorediscluster每个master都会持有部分slot,比如三个master那么每个master就会持有5000多个slotohashslot让node的添加和删除变得很简单，增加一个master,就将其他master的slot移动部分过去，减少一个就分给其他master,这样让集群扩容的成本变得很低。cluster基础通信原理（gossip协议）与集中式不同（如使用zookeeper进行分布式协调注册），redisc
21、luster使用的是gossip协议进行通信。并不是将集群元数据存储在某个节点上，而是不断的互相通信，保持整个集群的元数据是完整的。g。SSiP协议所有节点都持有一份元数据，不同节点的元数据发生了变更，就不断的将元数据发送给其他节点，让其他节点也进行元数据的变更。集中式的好处：元数据的读取和更新时效性很好，一旦元数据变化就更新到集中式存储，缺点就是元数据都在一个地方，可能导致元数据的存储压力。对于gossip来说：元数据的更新会有延时，会降低元数据的压力，缺点是操作是元数据更新可能会导致集群的操作有一些滞后。rediscluster主备切换与高可用判断节点宕机：如果有一个节点认为另外一个节点宕
22、机，那就是pfail,主观宕机。如果多个节点认为一个节点宕机，那就是fail,客观宕机。跟哨兵的原理一样；对宕机的master,从其所有的slave中选取一个切换成masternode,再次之前会进行一次过滤，检查每个slave与master的断开时间，如果超过了cluster-node-timeout*cluster-slave-validity-factor就没有资格切换成master；从节点选取：每个从节点都会根据从master复制数据的OffSet,来设置一个选举时间,offset越大的从节点，选举时间越靠前，masternode开始给slave选举投票,如果大部分master（n2+
23、l）都投给了某个slave,那么选举通过（与zk有点像，选举时间类似于epochid）；整个流程与哨兵类似，可以说rediscluster集成了哨兵的功能，更加的强大；RediS集群部署相关问题redis机器的配置，多少台机器，能达到多少qps?机器标准:8核+32G集群:5主+5从（每个master都挂一个slave）效果:每台机器最高峰每秒大概5W,5台机器最多就是25W,每个master都有一个从节点，任何一个节点挂了都有备份可切换成主节点进行故障转移脑裂问题哨兵模式下：master下挂载了3个slave,如果master由于网络抖动被哨兵认为宕机了，执行了故障转移，从slave里面选取
24、了一个作为新的master,这个时候老的master又恢复了，刚好又有CIient连的还是老的master,就会产生脑裂，数据也会不一致，比如incr全局id也会重复。redis对此的解决方案是：min-slaves-to-write1至少有一个slave连接min-slaves-max-lag1Oslave与master主从复制延迟时间如果连接到master的slave数小于最少SIaVe的数量，并且主从复制延迟时间超过配置时间，master就拒绝写入12oclient连接redis多tcp连接的考量首先Fedisserver虽然是单线程来处理请求，但是他是多路复用的，单tcp连接肯定是没有
25、多tcp连接性能好，多路复用一个i。周期得到的就绪i。事件越多，处理的就越多。这也不是绝对的，如果使用pipeline的方式传输，单连接会比多连接性能好，因为每一个pipeline的单次请求过多也会导致单周期到的命令太多，性能下降多少个连接比较合适这个问题，rediscluser控制在每个节点100个连接以内。本文包括：30个RediS基础知识；10个RediS架构和运维必懂的知识；Redis调优、监控知识和10个具体应用难点。30个Redis基础知识1、RediS支持哪几种数据类型？StringList、SetSortedSethashes2、RediS主要消耗什么物理资源？Redis是一种
26、基于内存高性能的数据库一主要依赖于内存3、RediS有哪几种数据淘汰策略？noeviction：返回错误当内存限制达到并且客户端尝试执行会让更多内存被使用的命令（大部分的写入指令，但DEL和几个例外）allkeys-lru：尝试回收最少使用的键（LRU）,使得新添加的数据有空间存放。volatile-ku：尝试回收最少使用的键（LRU）,但仅限于在过期集合的键,使得新添加的数据有空间存放。allkeys-random：回收随机的键使得新添加的数据有空间存放。volatile-random：回收随机的键使得新添加的数据有空间存放，但仅限于在过期集合的键。volatile-tt：回收在过期集合的键
27、，并且优先回收存活时间（TTL）较短的键,使得新添加的数据有空间存放。4、为什么Redis需要把所有数据放到内存中？Redis为了达到最快的读写速度将数据都读到内存中，并通过异步的方式将数据写入磁盘。所以redis具有快速和数据持久化的特征。如果不将数据放在内存中，磁盘I/O速度为严重影响redis的性能。在内存越来越便宜的今天，redis将会越来越受欢迎。如果设置了最大使用的内存，则数据已有记录数达到内存限值后不能继续插入新值。5、RediS集群方案应该怎么做？都有哪些方案？1.twemproxy,大概概念是，它类似于一个代理方式，使用方法和普通redis无任何区别，设置好它下属的多个red
28、is实例后，使用时在本需要连接redis的地方改为连接twemproxy,它会以一个代理的身份接收请求并使用一致性hash算法，将请求转接到具体redis,将结果再返回twemproxy。使用方式简便（相对redis只需修改连接端口），对旧项目扩展的首选。问题：twemproxy自身单端口实例的压力，使用一致性hash后，对redis节点数量改变时候的计算值的改变，数据无法自动移动到新的节点。2 .codis,目前用的最多的集群方案，基本和twemproxy一致的效果，但它支持在节点数量改变情况下，旧节点数据可恢复到新hash节点。3 .rediscluster3.0自带的集群，特点在于他的分
29、布式算法不是一致性hash,而是hash槽的概念，以及自身支持节点设置从节点。具体看官方文档介绍。4.在业务代码层实现，起几个毫无关联的redis实例，在代码层，对key进行hash计算，然后去对应的redis实例操作数据。这种方式对hash层代码要求比较高，考虑部分包括，节点失效后的替代算法方案，数据震荡后的自动脚本恢复，实例的监控，等等。6、RediS集群方案什么情况下会导致整个集群不可用？有A,B,C三个节点的集群,在没有复制模型的情况下,如果节点B失败了，那么整个集群就会以为缺少5501-11000这个范围的槽而不可用。7、RediS如何设置密码及验证密码？设置密码：授权密码：8、说说
30、RediS哈希槽的概念？Redis集群没有使用一致性hash,而是引入了哈希槽的概念，Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。9、RediS集群的主从复制模型是怎样的？为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群使用了主从复制模型,每个节点都会有N-I个复制品.10、RediS集群会有写操作丢失吗？为什么？Redis并不能保证数据的强一致性，这意味着在实际中集群在特定的条件下可能会丢失写操作。11、RediS集群之间是如何复制的？异步复制12、怎么理解RediS事务？事务
31、是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。13、RediS事务相关的命令有哪几个？MULTkEXEC、DISCARD、WATCH14、Rediskey的过期时间和永久有效分别怎么设置？EXPIRE和PERSIST命令。15、RediS如何做内存优化？尽可能使用散列表（hashes）,散列表（是说散列表里面存储的数少）使用的内存非常小，所以你应该尽可能的将你的数据模型抽象到一个散列表里面。比如你的web系统中有一个用户对象，不要为这个用户的名称，姓氏
32、，邮箱，密码设置单独的key,而是应该把这个用户的所有信息存储到一张散列表里面。16Redis回收进程如何工作的？一个客户端运行了新的命令，添加了新的数据。Redi检查内存使用情况，如果大于maxmemory的限制,则根据设定好的策略进行回收。一个新的命令被执行，等等。所以我们不断地穿越内存限制的边界，通过不断达到边界然后不断地回收回到边界以下。如果一个命令的结果导致大量内存被使用（例如很大的集合的交集保存到一个新的键），不用多久内存限制就会被这个内存使用量超越。17、RediS回收使用的是什么算法？1.RU算法18、RediS如何做大量数据插入？Redis2.6开始redis-cli支持一种
33、新的被称之为pipemode的新模式用于执行大量数据插入工作。19、为什么要做RediS分区？分区可以让RediS管理更大的内存，RediS将可以使用所有机器的内存。如果没有分区，你最多只能使用一台机器的内存。分区使RediS的计算能力通过简单地增加计算机得到成倍提升,Redis的网络带宽也会随着计算机和网卡的增加而成倍增长。20、RediS持久化数据和缓存怎么做扩容？如果Redis被当做缓存使用，使用一致性哈希实现动态扩容缩容。如果Redis被当做一个持久化存储使用，必须使用固定的keys-to-nodes映射关系，节点的数量一旦确定不能变化。否则的话（即Redis节点需要动态变化的情况），
34、必须使用可以在运行时进行数据再平衡的一套系统，而当前只有Redis集群可以做到这样。21、分布式RediS是前期做还是后期规模上来了再做好？为什么？既然RediS是如此的轻量（单实例只使用IM内存），为防止以后的扩容，最好的办法就是一开始就启动较多实例。即便你只有一台服务器，你也可以一开始就让RediS以分布式的方式运行，使用分区，在同一台服务器上启动多个实例。一开始就多设置几个RediS实例，例如32或者64个实例，对大多数用户来说这操作起来可能比较麻烦，但是从长久来看做这点牺牲是值得的。这样的话，当你的数据不断增长，需要更多的RediS服务器时，你需要做的就是仅仅将Redis实例从一台服务
35、迁移到另外一台服务器而已（而不用考虑重新分区的问题）。一旦你添加了另一台服务器，你需要将你一半的Redis实例从第一台机器迁移到第二台机器。22、都有哪些办法可以降低Redis的内存使用情况呢？如果你使用的是32位的Redis实例，可以好好利用Hash,list,sortedset,set等集合类型数据，因为通常情况下很多小的Key-Vakle可以用更紧凑的方式存放到一起。23、查看RediS使用情况及状态信息用什么命令？Info24、RediS的内存用完了会发生什么？如果达到设置的上限，Redis的写命令会返回错误信息(但是读命令还可以正常返回。)或者你可以将Redis当缓存来使用配置淘汰机
36、制，当Redis达到内存上限时会冲刷掉旧的内容。25RediS是单线程的，如何提高多核CPU的利用率？可以在同一个服务器部署多个RediS的实例，并把他们当作不同的服务器来使用，在某些时候，无论如何一个服务器是不够的，所以，如果你想使用多个CPU,你可以考虑一下分片(shard)o26一个RediS实例最多能存放多少的keys?ListSetSOrtedSet他们最多能存放多少元素？理论上RediS可以处理多达232的keys,并且在实际中进行了测试，每个实例至少存放了2亿5千万的keyso我们正在测试一些较大的值。任何listset、和Sortedset都可以放232个元素。换句话说，Red
37、iS的存储极限是系统中的可用内存值。27、RediS常见性能问题和解决方案？(I)Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件(2)如果数据比较重要，某个SIaVe开启AoF备份数据，策略设置为每秒同步一次(3)为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内(4)尽量避免在压力很大的主库上增加从库(5)主从复制不要用图状结构，用单向链表结构更为稳定，即：Master-Slave1-Slave2如何选择合适的持久化方式？一般来说，如果想达到足以媲美PostgreSQL的数据安全性，你应该同时使用两种持久化功能。如果你非常关心你的数据，但仍
38、然可以承受数分钟以内的数据丢失，那么你可以只使用RDB持久化。有很多用户都只使用AOF持久化,但并不推荐这种方式:因为定时生成RDB快照（SnaPShot）非常便于进行数据库备份，并且RDB恢复数据集的速度也要比AOF恢复的速度要快，除此之外，使用RDB还可以避免之前提到的AOF程序的bugo30、修改配置不重启Redis会实时生效吗？针对运行实例，有许多配置选项可以通过CoNFlGSET命令进行修改，而无需执行任何形式的重启。从Redis2.2开始，可以从AOF切换到RDB的快照持久性或其他方式而不需要重启Rediso检索Configget,命令获取更多信息。但偶尔重新启动是必须的，如为升级
39、RediS程序到新的版本，或者当你需要修改某些目前CoNFlG命令还不支持的配置参数的时候。10个Redis架构和运维必懂的知识一、高可用相关1、RediS常用高可用架构有哪些？RediS高可用架构如下：RedisSentinel集群+内网DNS+自定义脚本RedisSentinel集群+VIP+自定义脚本封装客户端直连RedisSentinel端口JedisSentinelPool,适合JaVaPHP基于phpredis自行封装RedisSentinel集群+Keepalived/HaProXyRedisM/S+KeepalivedRedisClusterTwemproxyCodis2、Re
40、diS高可用架构优劣对比？一RedisSentinel集群+内网DNS+自定义脚本优点：秒级切换脚本自定义，架构可控对应用透明缺点：维护成本略高依赖DNS,存在解析延时Sentinel模式存在短时间的服务不可用一RedisSentinel集群+VIP+自定义脚本优点：秒级切换脚本自定义，架构可控对应用透明缺点：维护成本略高Sentinel模式存在短时间的服务不可用一封装客户端直连RedisSentinel端口优点：服务探测故障及时DBA维护成本低缺点：依赖客户端支持SentinelSentinel服务器需要开放访问权限对应用有侵入性一RedisSentinel集群+Keepalived/HaP
41、roXy优点：秒级切换对应用透明缺点：维护成本高存在脑裂Sentinel模式存在短时间的服务不可用一RedisM/S+Keepalived优点：秒级切换对应用透明部署简单，维护成本低缺点：需要脚本实现切换功能存在脑裂（RedisClusterTwemproxyCOdiS优劣对比见下个问题）3、常见的RediS集群方案有哪些优缺点？Twemproxy:多个同构TWemProXy（配置相同）同时工作，接受客户端的请求，根据hash算法，转发给对应的Redis。优点：开发简单，对应用几乎透明历史悠久，方案成熟缺点：代理影响性能1.VS和Twemproxy会有节点性能瓶颈Redis扩容非常麻烦TWit
42、ter内部已放弃使用该方案，新使用的架构未开源Codis:ZooKeeper存放路由表和代理节点元数据分发Codis-Config的命令Codis-Config集成管理工具，有web界面Codis-Proxy无状态代理，兼容RediS协议对业务透明Codis-Redis基于2.8版本，二次开发加入slot支持和迁移命令优点：开发简单，对应用几乎透明性能比Twemproxy好有图形化界面，扩容容易，运维方便缺点：代理依旧影响性能组件过多，需要很多机器资源修改了RediS代码，导致和官方无法同步，新特性跟进缓慢开发团队准备主推基于Redis改造的rebomdbRedisCluster:P2P模式，
43、无中心化。把key分成16384个slot,每个实例负责一部分slot。客户端请求若不在连接的实例，该实例会转发给对应的实例。通过Gossip协议同步节点信息。优点：组件a11-in-box,部署简单，节约机器资源性能比proxy模式好自动故障转移、SIOt迁移中数据可用官方原生集群方案，更新与支持有保障缺点：架构比较新，最佳实践较少多键操作支持有限（驱动可以曲线救国）为了性能提升，客户端需要缓存路由表信息节点发现、reshard操作不够自动化二、RediS通用1、RediS相对MySQL、PoStgreSQL这些关系型数据库，有什么优缺点？观点一：RediS主要是用来做缓存，它有持久化，但也
44、只是为了缓存的可靠而己。优点是数据全放内存，速度快。缺点就是，数据大小不能超过内存大小。两个用在不同业务场景，RediS无法取代传统关系型数据库。观点二：RediS首先它是一种内存数据库，最大的优势在于效率高。尤其在某些特定场合下，例如热点数据量非常大，而数据从内存和磁盘之间的换入换出代价比较高的情况下，RediS就会体现它的价值。传统关系型数据库在于它对数据的一致性保障，它的数据模型范式是遵循严格事务规则的结构化数据，由于其数据的高度抽象化，它调度到内存的数据一般场合下不会占用很大的内存空间。总的来说，两种数据库各有各的优点和缺点。不同的业务场合有特定的追求目标，redis首要的是效率，适用
45、的是一些单纯二维结构化数据无法表达的数据模型，而关系型数据库处理的是可以用范式模型表达的二维数据，追求的是数据的高度一致性。随着IT的发展，每一类型的数据库都会在其特定的场合内发挥出无可比拟的优势，最终的趋势是大家趋于平衡，没有最好，只有最适合。观点三：记住一句话：任何数据库都有自己的应用场景，应该关注数据流、数据属性。个人的经验来说，RediS不可能取代MySQL或者PG。2、RediS有哪些应用场景？RediS是一个高性能的缓存，一般应用在SeSSiOn缓存、队列、排行榜、计数器、最近最热文章、最近最热评论、发布订阅等。更多应用场景，可以参考此处。可以这样讲，RediS适用于数据实时性要求
46、高、数据存储有过期和淘汰特征的、不需要持久化或者只需要保证弱一致性、逻辑简单的场景。3、新接手一个复杂的RediS集群（Sentinel模式），如何了解它刚刚接手一套RediS集群，想要了解这套集群的相关配置。应该如何入手。难道只能通过info命令去查看各个配置吗？这是笔者的建议：通读Sentinel官方文档GOOgIe搜索RedisSentinel,找几篇中英文的文章看看进入Sentinel集群后，使用info查看集群信息查看Sentinel配置文件，配合文档搞清楚每个参数的含义使用几台虚拟机模拟线上环境，然后做测试，在实践中深入理解思考当前SentineI集群是否有不合理的地方，如有，提出并改进三、Redis故障排查1、RediS实例中，存在大量的FIN_WAI
